[2.0.42] Description clarification issue, circuit input list is always sorted

[brucemalt]

Hey all,

I remembered reading in this topic viewtopic.php?p=666076 about space platform hubs, that description issues are "valid bugs".

I tried searching the forums, but searching for literally "anything" is... I don't trust the results, if it's a duplicate, I apologize.

I just learned that a particular quirk of the "Anything" signal selection is that the input list: That list is always sorted, according to what I assume is an item id? This means that ingredients usually(?) come before products in this input list.

03-27-2025, 22-24-15.png (73.42 KiB) Viewed 141 times

And this is specifically NOT respecting the number of items, even though the number of items does change the sorting in the UI.

03-27-2025, 22-39-30.png (55.85 KiB) Viewed 141 times

This has a few implications on how logic circuits can be set up, because if the signals can be mixed, but the mixed signal is still sorted, and "Anything always picks the first" (by id) it can be un-mixed in a predictable, reliable way. E.g. to produce ingredients before higher tier products automatically. I discovered this on the space platform when thinking about ammo production, that's why the rockets are there.

So if it is a real unintended bug, it's a very useful one (and should be kept, pretty please)!

I would have loved to read this somewhere and not discover it by myself, so I would suggest for the consistent sorting and sorting criteria if it's not "obviously item id" to be added to the description somewhere where it can be reasonably found, either on the factoriopedia or the wiki.

Thanks!

[boskid]

I am not really sure on what exactly you are focusing here, if i am reading this correctly its about adding description that anything output when given multiple passing signals (when in each mode), it selects one with lowest id using internal id order.

Personally i think it was a mistake to keep "anything" option allowed on the output side in 2.0. This feature was originally added in 1.1.13 when decider combinators had only one condition and one output, and the "anything" output had a reasonable meaning: it allowed to output one signal if multiple signals were passing. For me this always felt like a "hack" as it was not possible otherwise to split single signal frame into multiple wires each with single signal. In 2.0 we got selector combinator where you can select a specific signal using an index so this feature is no longer strictly needed. On top of that, this original feature from 1.1 lost one of its property being option to specify "anything > 0 output anything" and having the output part of anything to return only a signal that passed on the conditions side. In 2.0 since there can be multiple conditions, this configuration lost its meaning because conditions in normal mode can only provide one logic value (if conditions passed or not) and anything output has to pick arbitrary signal from the input. Only case where it still remains working is when using Each on conditions side because in this case conditions provide a vector of logic values (one for each input signal that appeared as non zero each somewhere on conditions side). Anything output when decider is using each signal gets also more complicated because the anything signal breaks the "stack of deciders, one for each substitute" analogy because the anything output will produce only one value even if there are multiple signals passing. It would be better to get rid of the "anything" output in 2.0 in favor of using selector combinators. But we are in a point where its rather not likely to happen as it could break existing save files.

"Anything" output selecting lowest id based on internal id order is an implementation detail. In general the only guarantee is that it will return just one signal and if you want to rely on the selected signal being some kind of lowest id makes it risky in case the ordering would change. In theory i could make anything return a random signal (as long it is just one signal) and that is still within the limits of this feature.

I am going to throw this to Not a bug as i do not want to touch description of the anything output trying to describe a behavior that is not even guaranteed behavior but just an implementation detail of a hack that should not be even present in 2.0.

[brucemalt]

Thank you for your answer and the clarification!

In theory i could make anything return a random signal (as long it is just one signal) and that is still within the limits of this feature.

That would be a shame and a nerf, because the selector as an additional part would be required, but I understand.