[0.17.74] Fully compressed belt decompresses

[billyboy999]

I've noticed my fully compressed belts decompressing. It seems to happen at transport line boundaries, as well as on the output of a splitter. Obviously a fully compressed line should not decompress, but I believe the way I'm using the splitter should not result in output gaps (more explanation below).

Video:
https://www.youtube.com/watch?v=bXwDYIvPc-I

Screenshot with annotations


Save file (I think it is too big to attach):
https://drive.google.com/file/d/1Z0eKs2 ... sp=sharing

Here are most of the instances of decompression I caught:
0:06 - two decompressions at Splitter
0:19-0:20 - two decompressions at Splitter
0:22 - decompression at 2nd Lane
0:28-0:29 - two decompressions at Splitter, two decompressions at Top Lane
0:37 - decompression at Top Lane
0:39 - decompression at Splitter
0:40 - decompression at 2nd Lane


I've loaded and watched this save file run a few times, and the same events happen every single time, so this seems to be deterministic.

Regarding the lanes decompressing: It seems to happen when the starts back up after a halt, but not always. It also seems to happen at internal transport lane boundaries.

Regarding the splitter - I'm using them to generate fully compressed lanes from a few uncompressed lanes. The splitter in question prioritizes the upper input, but always has a fully compressed belt into the lower input, which acts as a "buffer" when there is nothing in the upper input. The upper output is priority, so as long as the buffer is full, there should never be gaps in the upper output. The lower output is "overflow", when the combined input exceeds one belt's capacity.

The splitter gaps are not dependent on the output halting, but they happen when it's "processing" items from both inputs.

[valneq]

I might be mistaken, but this kind of looks like a duplicate of minor issue #65493: [kovarex] [0.17.1] Item jumping forward on belt.
The major difference is: here it is about fully compressed belts, there it is about a fairly empty belt.

[billyboy999]

I saw that issue. It could be related, but I did not see any items jumping ahead when I stepped through my video frame by frame. What I saw was the items behind the transport line boundary pause for one frame while the items after the boundary continued, resulting in a small gap.

I would also like to make the case that a belt decompressing is a big deal. Consider this design:


This design relies on the iron belt being fully compressed at all times. If there is ever a gap in the iron, copper will sneak in from the filter splitter's bottom output, and mess things up for the green circuit input belt.

[mmmPI]

You can prevent the copper plate to jump on the iron plate lane if you replace couple belts from the vertical iron one with an undergound belt so that the exit is next to the splitter.

Or you can use 'side loading' for compression instead of splitters.

It doesn't answer "why" the belts decompress, i vaguely remember reading on the forum that the splitters were changed at some point. ( maybe when filter were added ? around this period : viewtopic.php?f=11&t=55645). And that this resulted in those not being good at compressing belts anymore.

[billyboy999]

You can prevent the copper plate to jump on the iron plate lane if you replace couple belts from the vertical iron one with an undergound belt so that the exit is next to the splitter.

Oh yeah, you're right about that. That was just a simple example, but if you have more complex spaghetti going on, it is possible that you don't have room for an undergrounds.

Regarding splitters - I think splitters only have this issue when both outputs are used.

[mmmPI]

That's like when you tell the doctor " it hurts when i do this" and the doctor answer " then don't do it".

I was just suggesting alternative design in case this is considered minor problem.

The designs that relies on fully compressed belts at all time from experience can create problems, when you have biters eating belts obviously, but also power shortages can lead to compression loss, miner depleting or even subtle mistakes like rotating one piece somewhere pressing R, or removing one piece too many somewhere cutting a belt for a few second. The more complex the spaghetti and the more unexpected places reacts to the belt contamination. And then that's a lot of clean up.

All those are risks avoided by designing differently, maybe this could explain why it seems to be be considered a problem but minor.

If anything changes i would try to pick up a new habit for designing using the benefit of the newer mechanics, but for now i'm trying to find room for those underground belts when i need

[disentius]

there is room.png (1001.87 KiB) Viewed 2878 times

[boskid]

Minor issue, may be related to 65493