[Harknonnen] [15.28] Back-to-back underground belt causes inserter delay

[traycer]

A stack inserter end-loading to an underground belt is delayed by one tick on the return swing if the other end of the underground belt is in the adjacent tile. This is with a +12 stack bonus and express belts. Tested with north- and south-facing inserters. I have not tested other configurations yet. Bug occurs with side-loading and with all inserter types. Bug does NOT occur if stack size is forced to 1.

https://streamable.com/iuh8t

[traycer]

Upon further testing, it looks like there is more inconsistency than just the length of the underground belt. I'll try to capture video of each scenario and post here.

[traycer]

This video demonstrates end-loading vs side-loading on normal and underground express belts. In both cases, the shortest underground belt suffers a slight performance penalty compared to the longer ones. However, when end-loading, only one of the two inserters depositing directly on an express belt also experiences the same slowdown.

https://streamable.com/ceex3

[Harkonnen]

Thanks for report, but in optimized-belts branch (coming 0.16) this problem is gone

[Loewchen]

Thanks for report, but in optimized-belts branch (coming 0.16) this problem is gone

We should create a "Resolved for 0.16" directory for this.

[dgw]

optimized-belts branch (coming 0.16)

I thought it was part of 0.15. Guess we can look forward to even higher UPS on bases with absurd numbers of belts!

this problem is gone

\o/

We should create a "Resolved for 0.16" directory for this.

Exciting times.

[canidae]

Thanks for report, but in optimized-belts branch (coming 0.16) this problem is gone

There's another issue related to underground belts and compressing output (forum bug report). Can you check if this issue persist in the optimized belts branch?

[traycer]

Thanks for report, but in optimized-belts branch (coming 0.16) this problem is gone

Hooray for the devs! I discovered what might be the same (or perhaps related) bug, which looks like it will also be fixed with belt optimizations. I'll file a separate bug report and hopefully it can be immediately moved into the "Resolved for 0.16" category.

[traycer]

Just to close this off in case anyone else rediscovers this before 0.16: it appears the actual cause of the delay is a discrepancy in where the initial item of a stack is placed on the belt. Normally, items are placed flush against the edge of the belt (closest to the inserter). However, on subsequent loads, inserters depositing on belts with underground distances of greater than 0 drop items a fraction of a tile length further away. This difference allows the first item to clear the loading zone one tick faster than usual, meaning the inserter only waits two ticks instead of the usual three to drop the second item in a stack. Inserters on zero-length underground belts have to wait the usual three ticks.

This item placement gap can be easily monitored with game.player.zoom=4 and game.speed=0.02. This explains why the bug is only seen with stack sizes greater than 1. Curiously, only fast and express underground belts exhibit this difference in behaviour. Regular (yellow) transport belts do not. It may have to do with the speed at which items clear the underground belt's "internal buffer".

[Harkonnen]

canidae
Yes, that problem is fixed there as well.