[2.0.55] Assembler ingredient signals take 2 ticks to get calculated after the recipe is set by a signal

[CodeMaker_4]

I am working on an automatic crafting system. It needs to be able to detect when one of the items it wants to craft cannot be crafted due to a lack of ingredients. I take the list of things we might want to craft, use the selector to select a random signal every tick, set a dummy assembler (which doesn't actually do any crafting, but is only there to provide ingredient data) to that recipe, and check that all of the ingredients are present in the logistics network. If one of the ingredients is not present, I am adding the offending recipe to a ban list. For this, I need to sync up the timing of the processing time of the logic (assembler setting + ingredient checking) to a delayed signal of the crafting recipe. However, this system did not work, and after suspecting timing issues I jumped to a test world, and found the following unexpected behavior:

What did I do?
Load this save file to skip to the last step:

assembler ingredients signal delay bug.zip

The save file from the screenshot, open in editor mode for tick stepping

(1.38 MiB) Downloaded 5 times

1. Make a test world with cheats enabled, and make a powered area with a substation and some cheated electricity
2. Place a constant combinator on the left, with a random item with a recipe set, like an iron chest for example
3. Place an assembling machine 2 to the right of the constant combinator, and an arithmetic combinator below the assembler.
4. Connect constant -> assembler with green, constant -> arithmetic with red, assembler -> substation with red, and arithmetic -> substation with green. (The substation is so we can easily read the output signals, and the wires are alternating colors to prevent the recipe signal from leaking through the assembler and combinator)

   

   The setup

   Screenshot 2025-07-08 231309.png (725.88 KiB) Viewed 392 times

5. Set the assembler to set the recipe, and read the ingredients

   

   Assembler

   Screenshot 2025-07-08 231529.png (237.2 KiB) Viewed 392 times

6. Set the arithmetic combinator to add 0 to each, this is just a passthrough for the recipe signal to simulate the delay I expect

   

   The delaying combinator

   Screenshot 2025-07-08 231624.png (53.73 KiB) Viewed 392 times

7. Pause the game and tick step it, whilst turning on/off the constant combinator. Observe how long it takes for the signals to reach the substation by hovering the mouse cursor over the substation.

What happened?
When the recipe is changed (say, from nothing to an iron chest), the newly created recipe signal (chest) reaches the substation 1 tick before the ingredients list (iron plates), despite both signals going through one building. It seems that the assembler needed one tick to set the recipe, and then another to calculate/output the actual ingredient list.

What did I expect to happen?
I expected both the recipe signal going through the delaying arithmetic contaminator, and the calculated ingredient list to arrive at the substation at the same time, because they are both passing through one building / operation.

When does this happen?
The 2 tick delay in the assembler is consistent. Both when just turning on the recipe and letting it play out a few ticks, or when changing the recipe every tick.

Further notes
I think the root cause has to do with it first taking a tick to set the recipe, and then taking another to output the ingredients. If you have alt mode enabled, you can see that it takes a tick for the assembler to take the recipe, and then another before it starts outputting the ingredients.

For my purposes it is not an actual problem: I can just add another delay combinator to account for the 2-tick assembler delay. This bug report is made because the 2 tick delay is unexpected from my knowledge about combinators: converting a recipe signal to an ingredient signal feels like a single operation, just like turing a signal into the 5x of that signal when put through an arithmetic combinator.

Also, to fix this, either the recipe setting or the ingredient calculation would have to become instantanious. It would make the assembler more logical in the above described signal-processing sense, but making one of these instant might make other situations less logical. I cannot think of any with practical implications though.

Finally, I did not test this for other assemblers, or other machines with similar recipe setting and ingredient reading functionality. It is getting late and I need to do stuff tomorrow...

[cyx2020f]

I don't see any problem here. There are actually 2 steps for the assembler:
1. Set recipe according to the signal on the green wire
2. Read the ingredients of the current recipe and output to both wire.

For the combinator, there is only 1 step:
1. Add everything by 0 and output.

If you want to make it calculate in 1 tick, at leat one step must be calculated immediately, so you might expect this:
1. Change the signal on the constant combinator will change the recipe of the assembler immediately, even if you pause the game.
2. Change the recipe on the assembler will change the ingredient output immediately, even if you pause the game.

Both are catastrophic changes and breaks the deterministicy of the game. The game is supposed to be that next_state = f(current_state, user_input), not that next_state = f(next_state, current_state, user_input)

[Rseding91]

Thanks for the report however the current behavior is correct and I don’t believe we will be changing it.