[0.16.51] Side loading on belt has priority over items on the belt

[AntiElitz]

In the shown case in the video below, the Items from a sideloaded belt block the items on the belt sometimes and gain priority over them.
https://youtu.be/SKax39fYH5E

[steinio]

Use a splitter with priority input if you want another behavior.

[peet1993]

Use a splitter with priority input if you want another behavior.

This is still a bug, as the behaviour isn't consistent as shown in the video. If the sideloaded items always had priority, weird but fine. But it isn't consistent across setups, most of the time the main belt has priority, sometimes it doesn't.

[Loewchen]

Ref.: viewtopic.php?f=7&t=62644

[Rseding91]

Thanks for the report however I'm going to say won't-change and or isn't-broken.

When you have *any* belt side-loading the order things happen is entirely dependent on the update order which can change as items are added or removed from the belt.

There is no simple way that won't impact performance to enforce a specific order because if you do something as simple as feed a belt back onto itself then there is no defined order that will work - some belt has to go first and that one happens to get priority.

[Jap2.0]

There is no simple way that won't impact performance to enforce a specific order because if you do something as simple as feed a belt back onto itself then there is no defined order that will work - some belt has to go first and that one happens to get priority.

Except he isn't feeding a belt onto itself.

[Rseding91]

There is no simple way that won't impact performance to enforce a specific order because if you do something as simple as feed a belt back onto itself then there is no defined order that will work - some belt has to go first and that one happens to get priority.

Except he isn't feeding a belt onto itself.

Read what I said not just the end part

[Jap2.0]

There is no simple way that won't impact performance to enforce a specific order because if you do something as simple as feed a belt back onto itself then there is no defined order that will work - some belt has to go first and that one happens to get priority.

Except he isn't feeding a belt onto itself.

Read what I said not just the end part

Okay, some belt has to get priority. Presumably there's no easy way to set that to say, make that the belt that's going straight?

Next question: how are you getting spaces to side-load into on a fully compressed belt? Are you somehow updating the middle belt, then the upper belt, then the right belt? And if so, how would that happen in any case other than, say, a loop? Wouldn't the entirety of the straight lower belt be one transport line?

Edit: I retract what 2018 me said

[Rseding91]

In the example video he is feeding slow belts onto a faster one. That automatically splits the transport lines since the game can't merge different speed belts. So yes, the fast one updates and makes a gap then one of the 2 slower ones updates and puts an item into that gap.

[cooperfreak]

Bug ist still apparently present in version 2.1.17:

Factorio_2.1.17_sideloading.mp4

(1.68 MiB) Downloaded 36 times

Never seen this behaviour before... Seems as I have to live with it.

[Rseding91]

In your case: simply don't side-load within 3~ belt tiles of an inserter dropping onto the belt.

[Woggle]

Also just noticed this in 2.1.17 for the first time ever in [NaN] years playing. Did something change, or did I just happen to get (un)lucky?

I tend to do side (re)loading of supply belts a decent amount so it's surprising to me that I haven't seen it before.

Save is standing next to the belt actively being weird.

underground.gif (4.19 MiB) Viewed 186 times