Factorio Forums

In the first example inserters will be activated in the same time after 10 ticks from the copper plate signal.
Each inserter will put iron plate on the same position on the belt, and this can be check using leftmost detector (two lamps are active):


*Leftmost detector consist of two belts in the pulse mode and lamps with next conditions: "iron plate > 1" in the first lamp and "iron plate > 0" in the second lamp.
*Rightmost combinator circuit is used to delay pulse signal from the copper plate.

For the second example I changed delay amount from 10 ticks to 18 ticks, and now iron plates are desynchronized (only one lamp is active):


Expected behaviour: iron plate positions should be the same in both experiments.

Blueprint should be used with zero inserter capacity bonus.

If you look carefully, one item is more in front than the other.

This problem is caused by the way Factorio works internally.
The game updates entities in a deterministic pseudo-random order. So in the problematic tick something like this happens:
1. Update belt 1: belt 1 moves items forward(there are no items, so nothing is moved)
2. Update inserter 1: Inserter 1 places item on belt 1.
3. Update inserter 2: Inserter 2 places item on belt 2.
4. Update belt 2: belt 2 moves items forward: The item placed by inserter 2 is moved forward.
--- End of tick ---

So because of this you end up having the items at different positions.
Unfortunately there is no easy way to fix it. I will mark this as minor issue.
This might end up being fixed by the multithreaded inserters(possibly in 0.15.x).

Consider it realism? You should not expect that 2 inserters will end up having identical speed after a long period of time.

Twinsen wrote: This problem is caused by the way Factorio works internally.
The game updates entities in a deterministic pseudo-random order. So in the problematic tick something like this happens:
1. Update belt 1: belt 1 moves items forward(there are no items, so nothing is moved)
2. Update inserter 1: Inserter 1 places item on belt 1.
3. Update inserter 2: Inserter 2 places item on belt 2.
4. Update belt 2: belt 2 moves items forward: The item placed by inserter 2 is moved forward.

Why you can not just update all belts in pseudo-random order and only after that update all inserters (also in pseudo-random order)?
1. Update belt 1
...
2. Update belt N
3. Update inserter 1
...
4. Update inserter N
--- End of tick ---

Twinsen wrote: Consider it realism? You should not expect that 2 inserters will end up having identical speed after a long period of time.

Actually, if two identical inserters have the same direction and the same job (chest-to-belt unloading) during long time, I expect that they will be synchronized during this time.

By the way, I didn't find any case where "pseudo-random order" doesn't reproduce this bug.

Updated:
Inserters are not the cause of this problem, the true flaw is inside current belt mechanics:

XKnight wrote: Why you can not just update all belts in pseudo-random order and only after that update all inserters (also in pseudo-random order)?
1. Update belt 1
...
2. Update belt N
3. Update inserter 1
...
4. Update inserter N
--- End of tick ---

Short answer is: because that's how the game works, for many reasons including performance. I can't change the fundamentals of how the map format works, how the entities are stored and iterated over, possibly breaking many more things, for such a small bug.

XKnight wrote: Updated:
Inserters are not the cause of this problem, the true flaw is inside current belt mechanics:

I assume the same thing is happening here. Instead of the inserter placing the item on the belt, it's the belt.

Twinsen wrote:

XKnight wrote: Why you can not just update all belts in pseudo-random order and only after that update all inserters (also in pseudo-random order)?
1. Update belt 1
...
2. Update belt N
3. Update inserter 1
...
4. Update inserter N
--- End of tick ---

Short answer is: because that's how the game works, for many reasons including performance. I can't change the fundamentals of how the map format works, how the entities are stored and iterated over, possibly breaking many more things, for such a small bug.

Harsh truth, but this is truth. I appreciate your honesty and will wait for this fix in the future.