[0.17.7] Every third stack inserter misses items from blue belt

[malventano]

From a thread on Reddit, I did some more investigation and found that every third stack inserter is unable to consistently pick up items from a belt.

2019-03-06-19-42-27.png (487.18 KiB) Viewed 5477 times

In the above image, the left inserter lays down a group of 12 iron plates. The stack inserter right next to it can pick up all plates, but the second one over misses a few. This is a repeating pattern, with the 'missing' inserters indicated by the inserters that I have pointed downward in the image (locations 2, 5, 8, 11).

Slower belts have no issue here, but this bug may amplify when faster mod belts are used as well.

[malventano]

I did some more investigation watching at reduced game speeds. The inserters that miss items appear to be hunting wildly while those that don't stay mostly still while picking up the items. This seems to be a timing issue meshing poorly with inserter speed not being fast enough to handle the blue belt item speed. I didn't go back to check but the issue might have existed since 0.17.0 (with the increased belt items/s).

[Blooper]

I took recordings of a few of the inserters in the test setup here: https://imgur.com/a/fLFsfsf

[Jon8RFC]

I wonder how this factors in, which won't be fixed:
viewtopic.php?t=61131

From the testing I did one day, I was under the impression that it had to do with when certain sections of the map were processed each tick since not every underground belt had the issue, and only one reliably had the issue, of many underground belts. Then I read the above thread, and just gave up. From this new report and reddit thread breathing new life into the problem, it has me thinking it actually might get fixed and end up fixing the underground problem as well, since obviously these aren't underground belts.

[malventano]

I wonder how this factors in, which won't be fixed:
viewtopic.php?t=61131

From the testing I did one day, I was under the impression that it had to do with when certain sections of the map were processed each tick since not every underground belt had the issue, and only one reliably had the issue, of many underground belts. Then I read the above thread, and just gave up. From this new report and reddit thread breathing new life into the problem, it has me thinking it actually might get fixed and end up fixing the underground problem as well, since obviously these aren't underground belts.

I understand in the case of that post, where the underground is obscuring half of the belt area, but in this case, an inserter would see reduced throughput from every third belt tile, where all belts are the same. Behavior should be consistent regardless of which tile given that the contents, belt type, and inserter type are all the same.

[exi2163]

This is actually not a bug but more of a side effect.
One Tile in Factorio is 32px wide. The transport speed of an express belt is 3px per tick.
If you start with an item that is aligned at the border to the next tile so it is exactly 0 pixels away from the next tile it will be 3pixels in at the next tick. After that is has 29px to go up to the border but we move at 3px per tick so we end up 2px away from the border (9 ticks = 27px). At the next tick we are then exactly 1px inside the next tile. 31px to go we travel 10 Ticks (30px) and now are 1px away from the border. The next tick we are now 2px inside the next tile. 30px to go, ten ticks and exactly back at step one with 0pixels away.
This pattern repeats infinite. Mathematically you can just calculate <tile number>*32 MOD 3.

Why does this affect the inserter? Well, it only starts moving once the item enters its tile so item will end up at a different position once the arm has reached it. It is propably off by only one pixel for those 3 items. Also keep in mind that item spacing is now 8px so all items on the belt will be shifted by 1px every tile.

So this is an explainable but rather unexpected effect. Speeding up the stack inserter very slightly should fix it but might cause more problems on other places.

[Rseding91]

Thanks or the report but as others have stated: this isn't a bug.

[voddan]

Thanks or the report but as others have stated: this isn't a bug.

So, just to clarify, will this problem be fixed or not?

Call it a bug or a usability problem, but it is an unintended behaviour which is caused by internal imperfections of the simulator.

It has been mentioned that it could be mitigated by speeding up the inserters.

As it has been mentioned this effect could be mitigated by speeding up the inserters.

[Optera]

If inserters are capable of grabbing all plates on position x, y but not on x, y+1 I would certainly call that inconsistent and a bug.
Unless you now want to sell inconsistencies as feature.

[Jon8RFC]

Don't shoot the messenger.

viewtopic.php?f=48&t=61345&p=393024&hil ... ck#p393024

[exi2163]

While not a bug it might be reconsidered for balancing as belt thoughput has been increased by 12.5% in 0.17 but inserters did not change. So if a mod/dev should stil read this put it on the list and think about it once the bug reports for 0.17 become longer (my hypothesis about the stability of factorio is that the longer the bug descriptions are the more stable the code is).

[malventano]

Don't shoot the messenger.

viewtopic.php?f=48&t=61345&p=393024&hil ... ck#p393024

From that other thread:

Thanks for the report however that's simply how it is at the moment. Because "management" wants inserters to chase items on belts this is always going to be a possibility: the item out-running the inserter.

So, until I'm allowed to remove that mechanic (which I doubt I ever will be) inserters are doomed to be broken in weird setups like this.

...so here's the thing. This is not a 'weird' setup, or some funky underground thing. It's literally picking up items from a straight section of belt, and if that belt happens to be one more tile away, the behavior is completely different. This is a problem any way you slice it. If an assembler had less throughput if it was shifted one tile over, that would be deemed a bug, but this isn't? Also, smelters were adjusted to compensate for the increased belt throughput but inserters were not. Why not? Clearly it's causing an issue here...

Further, this did not happen in 0.16 and does happen now in 0.17, so intended behavior or not, it is clearly a regression in that behavior that should be corrected.

[Yijare]

just a tought on this... maybe the Inserters are fast enough in 0.16 because the belts were slower, so the inserter can't grab all, because the belt moves to fast.

the solution to this has been stated multiple times.
and i'd call that unintended behavior

[malventano]

just a tought on this... maybe the Inserters are fast enough in 0.16 because the belts were slower, so the inserter can't grab all, because the belt moves to fast.

the solution to this has been stated multiple times.
and i'd call that unintended behavior

Yes, faster belt throughput is the cause of the issue here, but where do you draw the line? The fastest inserter in the game should be able to pick up from the fastest belt in the game. As it is now, the inserter picking up from every third tile has significantly less throughput than from the other two tiles.

[invisus]

Yeah, I think this is the same as was was described in viewtopic.php?f=23&t=66973