Decider with OR condition not becoming 'true'

[feng]

grafik.png (133.41 KiB) Viewed 539 times

No signals on input, yet the first condition is not becoming true. When I remove the linked AND conditions it works.

Am I experiencing a bug or what is my mistake?

[robot256]

I expect this is behaving as intended. Read the descriptions for the "Anything" versus "Everything" wildcard signals. They differ in how they react to no signals being present/nonzero.

[feng]

I know those details. 'Everything' does react as true when no signals are present. And as I said, the condition is working when I remove the other 2 'AND" conditions. So the 1st condition should work because it is an 'OR' condition.

[boskid]

119467

[Tertius]

You want an output, if green has no signal or if red has no signal and green has some signal > 0. So use EVERYTHING=0 to check for 0, and ANY for check for > 0.

EACH=0 is invalid and never returns anything, because zero-valued signals are not iterated over, and non-zero-values aren't matching. The same with ANY=0, it's also never returning true.

So use this: (essentially, replace one EACH with ANY, and the invalid one with ALL)

11-03-2024, 17-24-19.png (161.13 KiB) Viewed 480 times

Can be directly read as "If EVERYTHING(green)=0 OR EVERYTHING(red)=0 AND ANY(green)>0 Then ...". If you call the EVERYTHING wildcard ALL instead (as I do), it's even more understandable. "If ALL(green)=0 OR ALL(red)=0 AND ANY(green)>0 Then ..."

[feng]

119467

I didnt know about those "normal" and "each" modes of the deciders. And tbh it is very confusing. I would expect that every 'OR' condition would treated as a separate decider mode.

I would expect that the 1st condition becomes true as it is not using 'each' inputs.
The 2nd combined 'AND' condition surely becomes false because of no input signals.

So, if every condition works on its own (like only 1 condition per decider) then it should also work as an 'OR' condition with the new 2.0 deciders.

Everything else feels just fiddly and not intuitive.

As workaround I will use Tertius suggestion to stay in normal mode and use just 'anything' inputs as the wires uses anyway only a single signal.

[boskid]

So, if every condition works on its own (like only 1 condition per decider) then it should also work as an 'OR' condition with the new 2.0 deciders.

Primary issue with such loose interpretation is that it is hard to make it into anything useful.

Lets imagine decider combinator with following settings:
[Everything] < 10 OR [Each] < 50 output [X]=1.

In case of inputs [iron-plate]=3, [copper-plate]=4, [plastic]=5, using your interpretation the output of the decider combinator should be [X]=1 since the decider passed on the first condition and everything else is irrelevant. If we would however provide [iron-plate]=20, [copper-plate]=4, [plastic]=5 then first condition is no longer true however second condition now passes for all signals. General rule of thumb when [each] signal is present then decider should behave as if there was a stack of decider combinators one on top of another with [each] being substituted with every signal that is present on inputs and has value of non-zero. Since there were 3 signals present and for each of them the second condition passes, that means now the output should be [X]=3. That now means just by increasing value of one signal the output now changed from [X}=1 up to [X]=3. That is unusable.

Lets imagine the same conditions but slightly altered:
[Each] < 50 OR [Everything] < 10 output [X]=1.

With your logic now the evaluation should go top to bottom, in case of [iron-plate]=3, [copper-plate]=4, [plastic]=5 the output would be [X]=3 (since first condition passed for each of them) and in case of [iron-plate]=20, [copper-plate]=4, [plastic]=5 the output would be also [X]=3 since again, first condition passed for each of the 3 signals on the input so output is sent 3 times.

In all of those cases, by mixing [Each] with [Everything] (or [Each] with [Anything]) and changing the order of conditions you would influence amount of passing signals so the output value would be useless: it would break the "stack of decider combinators" principle because depending which condition passed, it would either behave as 1 decider or as stack of deciders.


If you do not accept the "stack of decider combinators" interpretation when [each] signal is used, then what would be the purpose of [each] signal? If you would be saying "[each] < 10 should evaluate true if everything is < 10" then there is a different signal for this, [Everything] and you should not be using [each] at all.

[feng]

If you do not accept the "stack of decider combinators" interpretation when [each] signal is used, then what would be the purpose of [each] signal? If you would be saying "[each] < 10 should evaluate true if everything is < 10" then there is a different signal for this, [Everything] and you should not be using [each] at all.

That is what im considering more now after your clarifications. It's just an important information about the 'each' and 'normal' mode, as there are already false bug reports about it on the forums, and who knows how many people just get confused without looking into the forums. So I would like to see it somewhere in wiki or tooltip info sometimes.

I just used 'each' in my case because in 1.x it was not important, because it just worked. And in my case I only use just 1 signal on wires anyway. So it was more like a bad habbit Instead of 'each' I use 'Anything' now and it is working.

Thanks for your effort to explain it.