[2.1.11] Programmable priority splitters cause belt decompression at odd points

[ospeovedos]

I have reproduced this on 2.1.11 and 2.0.77.

What did I do?

I have two fully-compressed belts going into a splitter with one output. The output will back up often due to downstream assemblers. The splitter is programmed to select one of the two inputs at different points in time.

What happened?

I noticed that on rare occasions a gap will open up in the output belt at the point of a belt reader between the splitter and the following assemblers. Note that the gap is not created at the splitter, and may be created hundreds of tiles away from anything noteworthy.

What did I expect to happen?

The uninterrupted belt should remain compressed its entire length.

Does it happen always, once, or sometimes?

It seems to be hard to trigger, but the save file I attached has it happen a few times per second.

Details

Upon testing, I realized that the gap only opens up at the point where the reader is, not at the splitter. I also noticed that the gap will also open up if there is a "break" in the belt segment (even with no reader).

gap1.png (403.3 KiB) Viewed 152 times

This shows a simplified version of the issue using Editor Extensions. The splitters are controlled by the combinator on the left which outputs a random signal, causing the splitters to switch input priority. The consumption of the items is simplified to a combinator on the right which stops and starts the belts. The belts on the hazard concrete are the ones that create this issue: the top belt has a reader attached to a speaker, the bottom belt had the same thing but the speaker was deleted before the items started up.

gap2.png (358.01 KiB) Viewed 152 times

The same picture as before, but with the show-transport-lines and show-transport-line-gaps debug options turned on. Note the gap in all four lanes at the left side of the hazard concrete - this is the first tick in which the gap exists. Also note that both the top and bottom belts' segments are split at the hazard concrete. There is one segment consisting of only the hazard tile, one segment to the left of it, and one segment to the right of it. Having multiple segments between the splitter and the intermittent consumer seems to be required to trigger this bug.

Although I was initially hesitant to call this a bug, the fact that it occurs on belt segment boundaries (which, in the case of the bottom belt, have no user-visible reason to exist) means that there could be random points in the system where belts become uncompressed for no apparent reason. This goes against the text in FFF 176 that "whenever a belt compresses - it will stay that way forever".

A few things I noticed on testing:

• It is not necessary for the splitter to be circuit-controlled. Toggling the priority by hand can cause the issue.
• The problem does not seem to happen if the belt is always moving smoothly.
• The issue persists on the bottom belt in the images since it still remembers the circuit conditions when the speaker was connected. This causes a split in the belt segments which persists even through a blueprint and copy/paste.

I attached the save file that created the images, which is paused using Editor Extensions. Hovering over the belts on the hazard concrete line will show times when there are fewer than 8 items on the tile, whereas hovering over any tile to the left of the hazard concrete will not. The save was made in 2.0.77 but can be loaded and shows the same bug on 2.1.11.