Factorio Forums

Items "squeeze" themselves onto a backed up belt when sideloading while other items travel down the side belt.


(Blueprint: https://pastebin.com/4G4wkzeN)

How to reproduce:
1: Place blueprint
2: Fill up line with iron (or any other item) as seen in image until its backed up. There should be some gaps between the two splitters though
3. Insert Items from the top belt
4. The result seems to vary a bit. But in my experience some items always slip through.

What whould I expect to happen instead?
Since the iron lane is backed up no items should be allowed to enter the belt via sideloading

Notes:
- Sometimes the slip only occures when the item reaches the end of the chain
- Removing the top belt in the very left column seems to make the slips less predictable and less often
- Slips also occur when a completely different items travels towards the uranium
- Bug also happens when adding items via inserter
- Tested on yellow and red belts
- Also tested unmodded

It's interesting. A fake gap is created when an item is placed on the belt, as evident by the transport-lines-gap debug setting. It's not always the same length gap, and the gap isn't always in the right place at the right time.

I put in some blues to ensure that things were forcibly compressed:
https://youtu.be/pHW78URv7D4

played around with it a bit, found that the gaps were being generated by the transport line segmenting at the corner like the fuel line in the attachment, without the segmentation at the corner it doesn't get the gaps, the original BP seems to segment the line on the corner quite readily

watching it further, it almost looks like the update order of the transport lines is getting jostled since the gaps show up in my test save at the time the fuel that slips through comes back around and crosses to the segment that has the rest of the fuel waiting

edit: just reopened the file and noticed that gaps are forming both before and after the segment that would receive the sideloaded fuel at the time noted above

You are right, that this is related to the update order of belts (it is even a debug info that can be inspected).
The problem is a direct result of the belt logic fundament. Belts always try to update the output first before updating itself, to keep all the compression and shit. The problem arises, when there is a circle. In a circle, you can't always update your output first for obvious reasons. In this case, when the order of the first belt updated is changed, the gap of the circle can emerge at the wrong place and create the gaps. There is no easy way around it, and if you really need this particular setup to do reliably what you expect, the only way is to break the belt loop by using inserters.

still feels off, but that just means it is time to try breaking it without looped transport belts