Factorio Forums

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

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.

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

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

Harkonnen wrote: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.

Harkonnen wrote: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!

Harkonnen wrote:this problem is gone

\o/

Loewchen wrote:We should create a "Resolved for 0.16" directory for this.

Exciting times.

Harkonnen wrote: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?

Harkonnen wrote: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.

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".

canidae
Yes, that problem is fixed there as well.