[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 443 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 443 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.

[boskid]

Thanks for the report however i do not believe there is anything that can be fixed there without doing a full rewrite of the transport lines logic which is not going to happen just because of this bug report alone.

From a quick look this appears to be an update order problem, when splitter changes input or output priority then the transport lines that are part of the splitter become active, the same happens with the downstream belt where if it gets enabled, lines become active. If the update order is unfavorable it may happen that the upstream part updates first, sees congestion downstream so it stops moving but within the same tick the downstream portion them moves away, sees upstream part already updated so it does not propagate the update and a gap opens. I will keep this in mind but i will classify this as Minor issue as it does not appear to have any real impact in the game while any attempts to fix this may have a real performance impact on every save file.

[ospeovedos]

Well, thanks for looking into it. I kind of expected that it would be too much trouble to fix; belt logic changes should not be made lightly.

Ironically enough, I discovered this bug when I added a speaker to warn me when a belt is no longer compressed (and would therefore need more supply). It turned out the reader itself was causing the problem that it was designed to detect!

[redrook]

Reading through FFF-176, it kind of sounds like there are optimizations in the game that assume the invariant "once 2 items compressed, they will never uncompress" holds.

Can this issue mess up item coordination calculation used elsewhere, e.g. for collision detection with splitter bounding boxes, inserters, interaction with belt tiles disabled by circuit network, etc.?

[boskid]

Reading through FFF-176, it kind of sounds like there are optimizations in the game that assume the invariant "once 2 items compressed, they will never uncompress" holds.

This may only hold if 2 items are on the same transport line, however if 2 items are on two consecutive transport lines with the distance such that they cannot move any closer, in order for gap to not open first the downstream transport line needs to update and then the upstream one. One line moving does not move items on other transport line on its own. There are also easily observable cases where this condition simply cannot hold, like when feeding red belt from yellow belt: there is a lot of gaps created because the downstream line moves faster than the upstream line and as such the items are unable to catch up and close the gap.

[redrook]

Thank you for the reply!