Decider combinator using the everything signal is used with no signal output will be true. See first picture.
If you add a secondary condition with the each signal even if the first statement is correct, you will not get an output. See second picture.
[2.0.9] Decider combinator bug
Re: [2.0.9] Decider combinator bug
Happen to me with Anything signal, the config was "Anything > 0 output Anything" and my output signal was a negative number.
Re: [2.0.9] Decider combinator bug
This is not a bug.
First case is decider working in "normal" mode, condition is true so output is true. Second case is decider working in "each" mode where it will send outputs once for each signal that was substituted under each signal and evalueated as true, however there were no substitutes so the output is sent 0 times.
First case is decider working in "normal" mode, condition is true so output is true. Second case is decider working in "each" mode where it will send outputs once for each signal that was substituted under each signal and evalueated as true, however there were no substitutes so the output is sent 0 times.
Re: [2.0.9] Decider combinator bug
What about my case? i will upload a screenshoot later if you need itboskid wrote: ↑Thu Oct 24, 2024 3:54 pm This is not a bug.
First case is decider working in "normal" mode, condition is true so output is true. Second case is decider working in "each" mode where it will send outputs once for each signal that was substituted under each signal and evalueated as true, however there were no substitutes so the output is sent 0 times.
EDIT: Screenshot
Re: [2.0.9] Decider combinator bug
Not a bug. Decider is in "normal" mode, anything on the left is true so it goes to the outputs, and "anything" selects any signal from the input. "anything" has nothing to do between sides because it would create a conflict what should be selected if there would be "anything > 10 OR anything < -10" -> would the "anything" output need to select signal that passed first anything or second anything? What if there would be "anything > 10 AND x=1 or anything < -10 AND x=2", would the output have to know if the condition was true due to first anything or second anything?
Re: [2.0.9] Decider combinator bug
Then the description is misleading, mentioning signal that matched the conditions.
Re: [2.0.9] Decider combinator bug
I'm very confused for how "anything" would work now. As wiki https://wiki.factorio.com/Decider_combinator#Function tells - for decider combinator "anything" output should forward one signal, but only one that passed the test. Imagine - we need do simple thing - filter signals that greater than zero, and return "anything" of them. In 1.x you need for this only 1 decider combinator, configured as "anything" on input is greater then 0, "anything" on output. In 2.x you need decider combinator PLUS SELECTOR combinator (which cost as 5 decider). And you get same result. And i can't really understand how to use the 2.x "anything" now if it just peaks one random signal from input, not related to conditions at all. This is counter intuitive in my opinion, at least when using decider combinator.boskid wrote: ↑Thu Oct 24, 2024 4:30 pm Not a bug. Decider is in "normal" mode, anything on the left is true so it goes to the outputs, and "anything" selects any signal from the input. "anything" has nothing to do between sides because it would create a conflict what should be selected if there would be "anything > 10 OR anything < -10" -> would the "anything" output need to select signal that passed first anything or second anything? What if there would be "anything > 10 AND x=1 or anything < -10 AND x=2", would the output have to know if the condition was true due to first anything or second anything?
I can understand confusion of new people not familiar with programming having several conditions with "or" operator. But it's the same in Boolean arithmetic - the whole condition is true when all of the parts are true, so if you for the god knows why creating combinator with "*>10 OR *<20" condition (which is TRUE for every single game number) it will always output you return signal, and it should be literally anything from input.
The same is when it comes to adding specific signal to conditions - if we have "anything" on input - this is the signal which is already taken from input at the start of whole test iteration no mater how much of conditions can be in combinator. And it should not change during evaluation of the single condition and evaluating output result.
I think "anything" with decider combinator is completely broken now and counter intuitive. And make harder to do simple things.
upd: finally, i found the way how to get to behavior of 1.x and use only 1 decider combinator: you should set condition to EACH signal, but output to ANYTHING.
And i'm still sure that description for "anything" signal in 2.x is completely confusing and incorrect
- Attachments
-
- decider_combinator_2x_anything.png (65.74 KiB) Viewed 387 times
Last edited by hairintd on Tue Oct 29, 2024 10:17 pm, edited 2 times in total.
Re: [2.0.9] Decider combinator bug
I was going to prove there was no behavior change by showing screenshot from 1.1.x with the related setup, however that shows there was indeed a behavior change:
That being said, i am not seeing any possibilities to keep the 1.1.x behavior because it was tightly bound to the decider having only 1 condition while in 2.0 a decider could have multiple conditions. If this behavior is really such confusing i can remove ability of selecting "anything" on the output side.- BlueTemplar
- Smart Inserter
- Posts: 3204
- Joined: Fri Jun 08, 2018 2:16 pm
- Contact:
Re: [2.0.9] Decider combinator bug
As a reminder, anything / everything correspond to the existential / universal quantifiers ∃ / ∀ :
https://en.wikipedia.org/wiki/Quantifier_(logic)
viewtopic.php?f=6&t=70143
https://en.wikipedia.org/wiki/Quantifier_(logic)
viewtopic.php?f=6&t=70143
BobDiggity (mod-scenario-pack)
Re: [2.0.9] Decider combinator bug
yeah, exactly. I personally thought that these special signals also define how signals do pass through combinators. But it applicable only to one condition, that's true. I think without some additional work it could not be "fixed", probably it would require combinators to have some sort of "intermediate" outputs for special signals result or something.
Please, don't! It still have use. Would be great to make description more specific about this case