[0.17.15] Inserters fail to unload when assembler straddles/abuts coordinate axes

[emlun]

What did you do? What happened?

This:







These are all plain inserters, assemblers and chests with no circuit- or logistic conditions. The concrete tile in the middle of the cross is the origin - the tile whose top-left corner has coordinate (0, 0).

When the assemblers run, some of the inserters remain idle "Waiting for source items" even though they should be operating.

What did you expect to happen instead?

All inserters would operate and distribute the pipes evenly between all the chests:

What else I've discovered

• The result seems perfectly deterministic (save file and blueprint below).
• This happens with both basic (yellow) and fast (blue) inserters, and all three levels of assemblers.
• This seems to happen whenever not all inserters connected to an assembler are in the same coordinate quadrant, even if the assembler itself is fully within one quadrant.
• This happens all along the coordinate axes, not only around the origin.
• This does not seem to happen when the source is a chest, roboport or train wagon instead of an assembler.
• 0.14.23 does not seem to have the bug (but the inserters don't attempt to balance themselves).
• 0.15.40 has the bug, but the exact behaviour for the edge cases seems to be slightly different (with the assembler center on the origin, only one inserter operates).
• 0.16.51 has the bug, and the one sample I took was not obviously different.

Resources / How to reproduce

• Load this save file: https://emlun.se/resources/factorio/ins ... 0debug.zip
• Or build this blueprint on (0, 0): https://emlun.se/resources/factorio/ins ... eprint.txt
• Log: https://emlun.se/resources/factorio/ins ... urrent.log
• Save file, blueprint, log and 10 more example screenshots: https://emlun.se/resources/factorio/inserter-bug/

[robot256]

AFAIK, multiple inserters unloading one assembler have never had any defined behavior other than an arbitrary deterministic one. They don't round robin at all, and the only way to make sure they all get some is by balancing the demand to the production. It's interesting that you exposed some of how that arbitrary priority behaves, but not a bug unless there's an inserter that won't grab anything even if there assembler is backed up with items available.

[emlun]

I believe they do since 0.15: It seems like inserters take turns - in the order they were constructed, it seems - to grab items from the assembler.

I discovered this precisely because my inserter factory flat out refused to move backed-up gear wheels into the stack inserter assembler to the right, while happily moving gears from the same assembler (which turned out to be straddling the X axis) up into the yellow inserter assembler. I became convinced it's probably a bug when the same setup magically started working if I moved the rightward inserter up two tiles.

[TruePikachu]

This particular behaviour is officially defined as undefined, deterministic behaviour, and almost certainly NaB.

[emlun]

Ok. Where is that statement? I wasn't able to find it.

[Hoefnix]

As far as I understand the game updates mostly in a chunkwise fashion. A chunk is a 32x32 tile square. By placing your machines and inserters exactly on the grid axes you have neatly managed to place your builds in multiple chunks.
Basically your picture shows 4 chunks: top left, top right, bottom left and bottom right.
The inconsistencies come from either the machine updating before the inserters or the other way around. So some inserters will always see an empty machine because the machine hasn't produced yet, but by the next update the inserters in the other chunk have already emptied it.

It's how the game works, I wouldn't say this is a bug.

[emlun]

Oh, turns out the inoperative inserters do actually spring to life once the others back up. I thought I had tested that but apparently I didn't.

Sorry for the noise.

[TruePikachu]

Ok. Where is that statement? I wasn't able to find it.

Here (NaB)

[emlun]

Thanks!