[2.0.20-3] Decider combinator set to 'Each (red) = 0, output input (green) each' outputs nothing

[macdjord]

Example:

Code: Select all

0eNrdldtuwjAMht/F1wHR07ZW2l4EoSptDURrky5NYQj13eeknAYMxrYLNPXGceL/tz8p6RqyssVaC2kgWYPIlWwgGa+hETPJS5uTvEJIoMBcFKgHuaoyIblRGjoGQhb4DonXsTMlVsxwac7X+N2EAUojjMDe0y1WqWyrDDWJsktCDGrVUK2S1pH0BsGTN4wYrCCJR+EwIqdCaMz7IyGzKkarMs1wzheCJKiu6febzzH1sh2MwVSUBvVx1qxq29lCaNPS0LtWewgDjzJvtEHzUFIqXblD1H/Ntes/gWeXaC15x2/L5aq4f6v4hL7OWhwR9n9BOPrPhIO/IhywC/fnHODRjXg3sintFWIH+nBFUKdCNybd388r0yPP5/ainox7qJNKNEulX52fxgISo1tkMNOI1O6Ulw129oqr1tStOX5VvtnCiYnT3blYy+4L9OFP0Yf3hv7lvtGT0ZJgWZuxxzwWMG/CXBS6yGc+5fxNFFJEFcJgRZ77vw+DBb0Bjnf04MdhHEfhY+CPgqjrPgCP8D6r

Two decider combinators, each receiving signals [1] and [2] on red and [1] and [3] on green. The first combinator is set to condition [Each] (red input only) > 0 and output [Each] input count (green input only). The second is the same, except the condition is '= 0' instead of '> 0'.

My expectation is that the first combinator should output signal [1], which is nonzero on both inputs, and the second combinator should output [3], which is zero on red and non-zero on green.

Instead, the second combinator outputs nothing at all.

I can see the logic of how this happens. If I have a combinator set to [Each] < 5, output [Each] = 1, I probably don't want it to output a 1-value on each of the several thousand potential signals that aren't being used at all. And with the 1.0 combinators, it didn't matter; since there was no way to separate red and green inputs, [Each] = 0 output [Each] input count would produce nothing anyway.

The best solution I see would be to keep the 'ignore 0 input' logic for [Each] = 1 outputs, but disable it for [Each] input count outputs.

[LCStark]

So, I've checked your BP and this is what I got:

c1.png (40.55 KiB) Viewed 370 times

c2.png (34.77 KiB) Viewed 370 times

Since the first one works as expected, I'll skip it and focus on the second one.

second combinator should output [3], which is zero on red and non-zero on green.

Instead, the second combinator outputs nothing at all.

You've set it to only read the red wire for condition checks, so it definitely won't do that. When you use "Each" mode, think of it as the combinator switching to a vector mode and evaluating the conditions for every input signal separately. In this case, since you've selected to evaluate only red inputs, you're getting 2 separate combinators checking the condition "input = 0" for input signals [1] and [2]. Both are non-zero, so they don't meet the condition and output nothing.

c3.png (22.43 KiB) Viewed 370 times

Edit
This is how your combinator should look like to get the output you expect:

c4.png (40.7 KiB) Viewed 368 times

[IsaacOscar]

I think the second condition should be each = each (or something else trivially true), in case the green wire has negative numbers on it.
(I don't know what the purpose of the circuit contraption is, so I might be wrong)

[IsaacOscar]

Also this is not a bug. I've been noticing a regular streem of bug reports about "each" with decider combinators, and they're all people misunderstanding how they're supposed to work...

I wonder if that means the semantics of decider combinators should be altered to make it less confusing, more explanation should be provided to the user, change the UI to make it clear what's going on, or just delete the feature. (please no, I find it quite useful, even if I have to add weird conditions like "each = each").

[boskid]

Thanks for the report however this is intentional behavior of decider combinators to keep compatibility with how deciders work in 1.1: In 1.1 if you would have a decider with [Each] < 3 condition, if you provide iron-plate(red) = 1 and iron-plate(green) = -1 then even if both signals are present, they decider sees only value of 0 as the Each substitute and as such does not evaluate that signal. This logic was extended onto 2.0 deciders with their circuit network selection to keep backward compatibilty: signals are evaluated as each substitute only if they appered somewhere on conditions side as non zero value. This specifically means that if you have conditions set to "Each[R] = 0", it only evaluates conditions for signals which on red wire have non zero value, and given the condition they all evaluate to false. If you want decider to also evaluate conditions for signals that are only present on green wire, you need to also have Each[G] or Each[R+G] appear anywhere on conditions side so the substitute appears as non zero value on conditions side.

[macdjord]

You've set it to only read the red wire for condition checks, so it definitely won't do that. When you use "Each" mode, think of it as the combinator switching to a vector mode and evaluating the conditions for every input signal separately. In this case, since you've selected to evaluate only red inputs, you're getting 2 separate combinators checking the condition "input = 0" for input signals [1] and [2]. Both are non-zero, so they don't meet the condition and output nothing.

Yes, signals 1 and 2 fail the condition. However, signal 3 is 0 on the red wire, so it should pass the condition and output the green-wire value.

Edit
This is how your combinator should look like to get the output you expect:

c4.png

That is an acceptable workaround in this particular case, yes.

Also this is not a bug. I've been noticing a regular streem of bug reports about "each" with decider combinators, and they're all people misunderstanding how they're supposed to work...

I wonder if that means the semantics of decider combinators should be altered to make it less confusing, more explanation should be provided to the user, change the UI to make it clear what's going on, or just delete the feature. (please no, I find it quite useful, even if I have to add weird conditions like "each = each").

'When signal = 0' not triggering on a signal which is equal to 0 feels pretty damn bug-like to me. It may not be a case of the code is not doing what the developer intended, but 'the button that says Do X does not actually do X' is a bug, too.

Thanks for the report however this is intentional behavior of decider combinators to keep compatibility with how deciders work in 1.1: In 1.1 if you would have a decider with [Each] < 3 condition, if you provide iron-plate(red) = 1 and iron-plate(green) = -1 then even if both signals are present, they decider sees only value of 0 as the Each substitute and as such does not evaluate that signal. This logic was extended onto 2.0 deciders with their circuit network selection to keep backward compatibilty: signals are evaluated as each substitute only if they appered somewhere on conditions side as non zero value. This specifically means that if you have conditions set to "Each[R] = 0", it only evaluates conditions for signals which on red wire have non zero value, and given the condition they all evaluate to false. If you want decider to also evaluate conditions for signals that are only present on green wire, you need to also have Each[G] or Each[R+G] appear anywhere on conditions side so the substitute appears as non zero value on conditions side.

And the 'ignore signals equal to 0' logic made perfect sense in 1.1. Since the value used for evaluating the condition was always exactly the same as the value output by 'input value', ignoring zero inputs never caused an unexpected result - and, as I mentioned before, this behaviour is good and helpful when using the 'constant 1' output option.

But we're not on 1.1 anymore, combinators can have different values in the evaluation and output steps, and 'Each = 0 doesn't actually trigger for signals that are 0' is surprising and confusing behaviour.

If you want to maintain backwards compatibility, how about making the implicit 'Each != 0' condition this logic enforces and explicit one? Combinators can have multiple logical test conditions now, so, as part of the process for importing old saves, find any existing combinators which use an [Each] condition and 'input value' output and add 'AND Each != 0' to the test condition. Thus the old combinators will continue to work as before, but new designs can just not include that condition if the alternative behaviour would be more useful.

[IsaacOscar]

The problem with getting rid of the "ignore zero signals" thing is that it would be very easy to create a decider combinator that outputs a 1 to every signal in the game, and there are quite a lot of them... causing who knows what memory and performance problems (however, most of those signals will be output with a 1, so it would be possible to implement this efficiently if the developers have the time, which they probably don't)

[boskid]

Both approaches are solvable with extra stuff on conditions side.

If decider would evaluate all signals present on any input (variant not backward compatible with 1.1), then it would be possible to add "AND Each[R+G] != 0" (assuming other conditions use [R+G] composition) to ignore signals that were evaluated but should not be.
If decider would not evaluate signals when it appears as 0 on inputs (variant backward compatible with 1.1) then it would be possible to add "OR Each[G] != Each[G]" (assuming other conditions use [R] composition or [R+G] composition) to make all signal processed even if they sum to 0 in some cases.

Right now deciders follow the second approach and you are suggesting they should be following the first approach. Well, first approach is more annoying because it needs AND condition so if there is a complex structure of conditions you would need to add this condition into every group of conditions that is split with ORs. Second approach just needs one condition anywhere with a different circuit network composition to go into the modern way and process all signals. I am not going to change this, it was about 3 days of hard discussion about corner cases and current behavior was considered to be better of the two. Not a bug.