0.16.36 Decider Combinator sometimes loses its constant

[zOldBulldog]

Scenario:

- I have a decider combinator that I had set with Parameters "Green > 2" and Output "Green 1".
- I noticed it was not working as expected. It was giving a green output with input signals 1 red and 1 green.
- I opened the UI of the decider combinator and it was indeed showing parameters "Green > 2", output Green 1.
- Then I clicked the "2" and surprise... the value in "Or set a constant" was 0.
- I re-entered the value of 2, hit Set, and now it all works.

Reproducing the bug:
- Simply placing a decider combinator and setting it to its values DOES NOT reproduce the bug.
- Blueprinting and copying also does not reproduce the bug.
- I am not sure what triggers the bug. There must be a sequence of events that triggers it. I experienced a similar issue placing requester chests (loss of a constant and mysterious reset to 0), where after some unknown sequence of events they would show 0 as the quantity for the requested item even though I had most definitely accepted the default value (50 I think?).

Screenshots:
- ss1 shows on the left how it should output "green 1" when the input has "green > 2". On the right it shows how the input only has 2 greens and thus it should not generate an output... and yet it shows a "green 1" output.
- ss2 shows what displays when I click on the "2" of the condition... the constant is really a "0". So, although it displays 2 in the condition, the real value it contains and behaves as is 0.
- ss3 shows the correct value after re-entering it as a 2, hitting Set, exiting and re-entering the combinator. Once fixed, it seems to stay fixed.

Conclusions:
- There is a bug, although I do not know how to reproduce it.
- A band-aid when it happens is to re-enter the combinator UI, re-enter the constant value and hit Set.

I hope this information helps. If I ever figure out a repeatable sequence of events that causes the problem every time I'll update this report.

(apologies for the screenshots - the upload tool seems to have inserted them in reverse order)

[Loewchen]

Post the save please.

[Loewchen]

You do not compare for >2. As seen by the screenshot as well, you compare for > signal #2, which, since there is no such signal is true for any value > 0. NaB.

[zOldBulldog]

You do not compare for >2. As seen by the screenshot as well, you compare for > signal #2, which, since there is no such signal is true for any value > 0. NaB.

Thanks, you are right. It is a very easy to make mistake with the current UI design but definitely not a bug.

No wonder it got fixed when I "re-entered" (at least that is what I was thinking) the constant value.