[0.17.66] Splitters taking items from inputs in unpredictable way

[NikonTheThird]

Check out this video I made on my PC. (I also made a Reddit thread here)

There is no input or output priority set, and the splitter is taking items from the inputs in an unpredictable way.

Load the attached save file Train_2 to see the behavior. This is the autosave that happens during the video.

[Bilka]

Could you further explain what you think is a bug, please.

Edit: Apparently I didn't watch the video properly the first time, most likely the reported issues is that the input seems to stall one of the belts sometimes, instead of taking equally from both.

[NikonTheThird]

Yes exactly. Both left lanes of both input belts are full, so I would expect a splitter to take items uniformly from both left lanes.

However, this does not happen here. It looks like input priority is randomly switching on and off.

[boskid]

Most likely "Duplicate" of 74273

In above mentioned topic, issue is that spliter fails to grab items from lane that happens to be performing item gap reduction. This would fit to this case in exactly same way. This can be easily tested: if you change spliter into fast spliter, then you will force transport lanes to be split, there will be less of gap reduction further in transport line (since transport line will be at most 1 tile in length) and so issue should vanish immediately. For proper solution we will have to wait.

[NikonTheThird]

Using a red splitter fixes the problem, thank you!

But I noticed another thing: You can trigger the splitter misbehavior by using the F key to grab items from the lane in front of the splitter. If you do that, the splitter stops working until you release F. Doing that with a red splitter does not trigger the misbehavior.

[boskid]

But I noticed another thing: You can trigger the splitter misbehavior by using the F key to grab items from the lane in front of the splitter. If you do that, the splitter stops working until you release F. Doing that with a red splitter does not trigger the misbehavior.

No. This is exactly same issue. Look at this (using "show-transport-lines" debug option):

75114-how-long-is-transport-line.png (198.01 KiB) Viewed 2732 times

Here you may see how long this transport line is. On left there are new items going and they trigger this "gap reduction" because they are not moving entire belt content, only items from some point. This is how far is gap reduction from splitter that is affected. If you pick up items using F, you are doing exactly same thing: you create gap, items going away from you stay still because of spliter that fails to get items from transport line because of gap reduction happening, gap reduction is happening because you just created gap by picking items and items from left are moving due to gap reduction because items right from you are not moving (you are standing on gap that shrinks). As soon as there will be no items to the left from you (that is: up to transport line begin), gap reduction will stop and spliter will work again.

[NikonTheThird]

Thank you for that detailed explanation. This "gap reduction" feature is part of the 0.17 belt optimizations I presume? Something to do with not tracking items but the gaps between them?

I never appreciated how complex splitters have to be internally, from a user perspective they appear to do a simple job...

[boskid]

For more details look on how belts work internally check this:
https://www.factorio.com/blog/post/fff-176


Spliter complex? I guess yes (because they most likely handle a lot of wait objects in between itself and each input/output line and work with many corner cases of items incoming not in sync). This is however offtopic.

For now could you please check your problem against 74273 to tell if you feel convinced that it is duplicate? Or something needs more explanation?

[NikonTheThird]

Yes I agree this is a duplicate of 74273.