pandorabox-io / in-game

Random code and stuff for in-game things
MIT License
3 stars 0 forks source link

CLU and Digiline updates on machines #81

Open Klaranth opened 3 years ago

Klaranth commented 3 years ago

orekart Make second CLU in grinder (other machines too) "stackwise" and keep single CLU "itemwise"; reasoning is that two CLU upgrades do not keep up with production on grinder and so to workaround the upgrades are not used and instead stackwise injector is used to keep things going.

int_ua I can imagine this change breaking a couple of designs but I'd love that anyway, great idea, orekart

yeah IMO if you go a little wilder with the idea there could be a digiline upgrade

stick in a digiline chest, monitor the contents of the grinder with digilines yes :) would a digiline chest allow to change permissions (shared, private, protected) from programming code? or is that a different node to do perms if daring to go towards the digiline chest upgrade thought, may want to review which subsection/intersection/union of digiline chest and technic mithril chest features would make sense does Mithril chest do anything more than Gold? digilines instead of colors interesting! is that a testing feature, or will that be upstream and added to the documentation?
Klaranth commented 3 years ago

SX: This idea of making machines "better" by making everything simpler and speeding up everything without need to do anything yourself keeps coming up every now and then. Idea has been discussed multiple times before and idea seems to be bad, it is like how kids that get to blow up one tnt in game have to blow up 10 next time, then 100 and so on until you hit world borders.

eshattow commented 3 years ago

Same logic (idea seems to be bad) just use stackwise or itemwise (or digiline) injector blocks always. The CLU upgrades can always be ignored, and should be removed as a feature then because they are a bad idea.

If you want to keep CLU upgrades then please fix the behavior by rejecting double CLU or making double CLU change mode to stackwise. The purpose of CLU upgrades is to be simpler and speed up everything as a performance upgrade, but it is confusingly somewhere between itemwise and stackwise injector blocks. Not enough of an upgrade to be useful and doesn't change modes to have any utility.

I don't think it is any problem to say that CLU + Microcontroller (for digiline upgrade) would be able to select itemwise or stackwise if you allow double CLU to be stackwise. That just makes more sense it would be configurable, and to have it emit events.

That upgrade capability could be over-powered but for the near-term the discussion can be limited to double CLU upgrade if it should be stackwise. I think it certainly should be stackwise, it makes sense and brings it into parity with existing mechanisms. You still need injector nodes it doesn't remove the need for them, and we do have digiline injector nodes so is that overpowered?

I don't see the problem here making double CLU behavior change to stackwise.

S-S-X commented 3 years ago

Problem is not upgrade itself, problem is that it obsoletes many use cases for other things and basically removes little advantages that MV machines still have. If you want to make HV machines better it cannot be just "make it faster and better than MV" thing, make it different enough so that player has to think a bit when making decision between MV and HV.

Klaranth commented 3 years ago

orekart Is there an open issue for "2nd Control Logic Unit upgrade makes ejection stackwise instead of itemwise" ? Seems like issue #81.

Node-breaker and node-deployer to speak digiline, would that be bad?

dennisjenkins75 commented 3 years ago

I would very much like to see the node-breaker and node-deployer capable to speaking digiline. Its cumbersome to have an almost pure-digiline machine that needs digiline<->mesecons interface to use these machines.

S-S-X commented 3 years ago

Node-breaker and node-deployer to speak digiline, would that be bad?

In my opinion adding digiline interface for devices that currently accept mesecons signal (for basic on/off control) would be fine if digiline control allows exactly same binary functions like "enable", "disable" and possibly "activate" (last one being similar to mesecons on/off pulse action, maybe there's better word for that...).

If adding more advanced functionality than what mesecons can practically provide with binary input then it depends on actual functionality added, there's no generic "one size fits all" answer. In this case it should be separate discussion for each device.

S-S-X commented 3 years ago

Linking few issues that mostly aim to include shortcuts for speeding up game, reducing required space for machines, making mining or processing simply faster as main goal without providing much anything else: #164 #159 #136 #118 #114 #108 #106