Decider combinator with "Anything" output

[ssilk]

+1

Plus: the table above lists situations, where two signals could be outputted, in that case any matching signal should be outputted. Sounds more logical for me...

[slippycheeze]

I'm just gonna throw in another voice asking for this in core. I don't care if it is "emit the first/last/mod-17-th signal based on a stable sort of all possible signals", or "min", "max", or whatever, but some facility to turn "all these signals" into "one of these signals" in a stable way would be extremely valuable to many uses of the extra-strange digital and analog circuit system.

As folks said before, right now it is very hard to make this stable, and what looked like tiny amounts of lua code implementing it per-tick turns out to be shockingly expensive for ... IDK. I guess "implementation reasons" or something, which make any interaction with the circuit network in a mod really expensive.

I'd also add that solving it in-game is not a "good gameplay" design challenge, just a "tedious gameplay" version: it isn't very hard to express the procedural logic of `if a then a else if b then b else if c then c end` in the game, it just involves stringing enough combinators in either parallel or series to do it, without any particular thought involved. You solve it maybe-once, since it is annoying enough to google, and then you can just stamp down the template every time without having to do any thinking at all.

[DaveMcW]

Here is a picture of what I would like. No new graphics or UI design is required.

pick any signal.png (217.33 KiB) Viewed 4990 times

[ichVII]

+1

Plus: the table above lists situations, where two signals could be outputted, in that case any matching signal should be outputted. Sounds more logical for me...

It is really important to distinguish between "any" and "each". If you mean "any", as in just one, I agree. If you mean "each", I disagree, because an important point of this is to split up one single signal from a circuit signal, even if multiple have an equal value. Currently, using just logic, this is only possible, if you provide an explicit order of all signals and then do some more logic. The game internally already has an order of all signals and this is used to set filters, but not used within combinators.

[Twinsen]

Implemented in Version: 1.1.13 by DaveMcW

- Decider combinator can output an Anything signal, which returns exactly one matching signal

It returns the first signal, ordered by in the internal prototype order, same as filter inserters.

[DerGraue]

omg, thank you so much

[aka13]

Holy shit prasie DaveMcW and his magical ways

[Trific]

Oh, Hallelujah!!!!

[knightelite]

Nice work DaveMcW

[Omnifarious]

This is a broader solution to the filter selection problem than the Each option for the stack size idea that I proposed, and therefore a better one. Thank you DaveMcW!

[ElderAxe]

@DaveMcW can you also allow filter inserters to accept "Any" as Set stack size signal?

The use case is, picking up the exact amount of items from a chest or wagon. When there is a tick difference, we can pick up the wrong amount.

When we use the new logic to set filters on inserters, the current logic needs to be like this to match the ticks between filter signal & stack size signal.

currrent.png (171.43 KiB) Viewed 3760 times

One combinator to set the stack size (S signal in this case), another one to delay the original signal for one tick.

If you guys allow Any signal to be used as stack size, this will allow us to get rid of those two combinators and directly use the signal we provide for the stack size.

suggested.png (123.85 KiB) Viewed 3760 times

[Trific]

@DaveMcW can you also allow filter inserters to accept "Any" as Set stack size signal?

If you guys allow Any signal to be used as stack size, this will allow us to get rid of those two combinators and directly use the signal we provide for the stack size.

Under usual use case (constant combinator specifying desired contents of chest differenced with actual contents of chest to provide "amount that needs to move"), you could simply wire that directly to the filter inserter and do away with the new decider combinator altogether. The new decider combinator output already simplifies my train unloading gadget immensely, surely at least *some* challenge should remain?

[ssilk]

You both have seen, that this subject is marked as implemented?

Maybe more useful to start a new subject?!