[2.0.23] Not all circuit inputs simultaneously evaluated with quickly removed item

[Job]

What did you do?
I built a circuit setup to send a signal to a train stop if the amount of items in linked chests went above a certain threshold.

What happened?
The setup unexpectedly evaluates to TRUE when an item in the linked chest is first added and then quickly removed. More specifically, the Stack Size input and Item Count inputs do not appear to stay simultaneously evaluated.

What did you expect to happen instead? It might be obvious to you, but do it anyway!
I expect the circuit condition to not evaluate to TRUE.

Does it happen always, once, or sometimes?
Always and readily reproducible.

Be precise! When i click with the mouse on Quit in the main menu... Not: When I close the game.
If you can reproduce the issue, provide the exact steps!

I have attached a save file and log file, but will do my best to describe.

The purpose of the setup is to evaluate when the number of items in linked chests exceed a certain threshold. The threshold is determined based on the stack size of the item. When TRUE, a signal is sent to a train depot to set the train limit to 1.

High Level Setup.png (3.56 MiB) Viewed 190 times

There are a series of chests linked together by a green wire. The green wire from the chest attaches as an input to a Selector Combinator that has its Mode of Operation set to read Stack Size. The green wire from the chest also attaches as an input to an Arithmetic Combinator, which uses the (yellow) Each symbol and multiplies it by 1. The output is sent via red wire (the intention is to take the count from the chests and convert the count to be sent via a red wire. Note that testing while removing this Arithmetic combinator does not resolve the issue).

The output from the above Selector Combinator outputs to a second Arithmetic Combinator via green wire that multiplies the stack size by 128 (the intent is to determine when 80% of a train's slots could be full). The output is then connected via green wire to a Decider Combinator.

The red wire from the first Arithmetic Combinator (with the item count) also attaches as an input to the same Decider Combinator. The Decider Combinator is TRUE if the red input is greater than the green input (using the Each symbol). The goal is that if the number of items exceeds the equivalent of over 80% filling a train, output to TRUE. If TRUE, the output from the Decider Combinator sends an L (set at 1) as a train limit to the train stop, so a train can show up.

This worked fine when I tested it statically. i.e. When I tested with items just sitting in the chests. But, when adding an item that is then quickly removed, the input flickers, where you don't seem to see red and green input simultaneously. This results in a flicker of the Decider evaluating to True, which calls a train in well before they are intended to.

Recording 2024-12-20 174505.mp4

(575.05 KiB) Downloaded 10 times

In the above example, by removing the inserter that quickly removes the object from the chest, everything seems to work as intended. i.e. The item count is well below the threshold, so nothing is evaluated as TRUE. Put another way, by not removing the first item in the chests quickly, it works as expected.

Static Working.png (183.01 KiB) Viewed 190 times

A practical example is with buffer input chests. The first item is placed into the buffer chest at a train stop, and the next inserter pulls it out to hold while awaiting a train to put it in.

If I add another condition, such as requiring red (item count) to be >0, that does not fix the issue.

Thank you for your time.

I'm playing on vanilla plus Space Age (no external mods).

Logs and save file attached.

[Muche]

This is due to circuit network delay.
That is, each combinator needs one tick to take its inputs, compute some result, and output it.
If an inserter puts an item in a chest and another inserters takes it out, the item is in the chest for exactly one tick.
The branch with selector is 2 combinators long, the other branch is one combinator long.
Due to the delay, one of the signals arrives a tick later, leading to incorrect comparison.

Try making both branches the same length.

124839-circnetdelay.jpg (260.06 KiB) Viewed 160 times

It should be also noted that combinators GUIs don't update every tick.
To get tick-precise values, evaluating values reported on wires with the editor's Tick once speed control might be needed.

[boskid]

I agree it looks like delay related making this Not a bug.

[Job]

OK, that makes sense. Will test that.

Thank you @Muche.