[kovarex] [0.16.17] Priority splitter can stop unblocked lane

[pib]

In my testing, this is very specific to this location, so I'm not sure what is going on. I can remove the splitter and all the belts, and set it up the same as it is now, and the bug persists. By this i mean red belt input - red splitter-> (Left) red belt output + (Right) curved yellow belt (priority output). See the image.

when the yellow belt is not moving, there is no output on the red belt. If i change things slightly (yellow belt is straight, or red, or not priority), things work normally. It might also be only be happening to the green circuit belt.

[erkle]

Got the same problem here. It will sometimes let one lane through. It looks like it might be that the items on the prioritized output line might be a few pixels out of the splitter, preventing it from detecting them.

[boskid]

Confirm. it is most likely to happen when priority lane is deconstructed by hand after first priority output belt. This may be related to rebuilding of internal structure representing belt not notifying spliter or something like this.

In attachment my save with extracted problem. 40x40 map, 42 seconds of replay data. When priority output belt is cut, input will stall even if there is alternate output. It is highly reliable way to reproduce bug.

[jmurrayufo]

I can reproduce this on blue belts without destroying anything, so I don't think it's that. I can create a loop on one side, and a stub on the other to test and the loop will often go once around before reaching it's error state.

[padman]

Priority splitter bug in practice: https://gfycat.com/GrimyOblongCaterpillar

And: https://gfycat.com/FearlessDamagedDogwoodtwigborer

[TruePikachu]

This is probably related to the bug with regular splitters sometimes not compressing or working at full throughput, but far more apparent because of how the priority splitting works.

[kitcat]

If you switch on show-transport-lines (in the F4 menu), you’ll see what happens. Whenever a belt near the splitter is modified, the transport lines are re-calculated and under certain conditions, output lanes stop and never continue. Lanes only stop if the backed-up item count on a priority lane is even. You can check this by hovering over the splitter and looking at the info box. If there is no item shown on the priority lane, the item count is even and the corresponding non-prioritized lane might stop. If there is an item, the item count is uneven and the lane might stop. That’s why the length and direction of the prioritized output matters. The order in which the belts are placed also seems to matter somewhat.

Attached is probably the easiest way to reproduce the problem. Savegame with replay and the scenario from which it was started. Make sure to enable show-transport-lines beforehand.

[Philip017]

i posted a similar bug report in another bug report i think all these are related
viewtopic.php?f=7&t=56968&p=337247#p337247

[boskid]

As per [0.16.20] this bug still exists despite some changes to splitters mentioned in changelog

[impetus maximus]

As per [0.16.20] this bug still exists despite some changes to splitters mentioned in changelog

it's in the 'Assigned' section, so i'm sure they will work on it.

[Impatient]

I assume this bug is a result of the belt optimizations in conjunction with the new priority splitters. The lanes on the optimized belts do treat compressed items on them not individually but each sequence of compressed items as one "sequence". There is one calculation per sequence and not one per item anymore. This is how i understood the big belt optimization in 0.16.
I assume there is a bug that shows when a sequence spans from the end of the belt back to the splitter. The gif above, that shows that the priority splitter acts differently depending on the length of the belt and/or if there is a turn would fit that assumption. Maybe the splitter does not recognize that the sequence spans back into the splitter if its "center" is some pixel off +-, which happens when the lane makes an inner or outer turn. or maybe it is a rounding problem in calculations including item "length" on the lane , lane length on multiples of straight belt tiles or bent belt tiles and the length of a sequence.

@devs: post the cause of the bug here please, when you fixed it. i wonder if my guesswork and my assumptions are anywhere near the truth.

[kovarex]

Fixed for the next release.

@Impatient, sorry but your assumption is not correct

[Philip017]

its working much better now thanks!

[impetus maximus]

its working much better now thanks!

+1 many thanks.