[0.17.74] Fully compressed belt decompresses

Post your bugs and problems so we can fix them.
Post Reply
billyboy999
Manual Inserter
Manual Inserter
Posts: 3
Joined: Thu Nov 14, 2019 5:37 am
Contact:

[0.17.74] Fully compressed belt decompresses

Post by billyboy999 » Thu Nov 14, 2019 6:43 am

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
Image

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.
Attachments
factorio-current.log
(5.08 KiB) Downloaded 5 times

valneq
Fast Inserter
Fast Inserter
Posts: 139
Joined: Fri Jul 12, 2019 7:43 am
Contact:

Re: [0.17.74] Fully compressed belt decompresses

Post by valneq » Thu Nov 14, 2019 4:32 pm

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
Manual Inserter
Manual Inserter
Posts: 3
Joined: Thu Nov 14, 2019 5:37 am
Contact:

Re: [0.17.74] Fully compressed belt decompresses

Post by billyboy999 » Sat Nov 16, 2019 6:40 am

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:
Image

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
Filter Inserter
Filter Inserter
Posts: 363
Joined: Mon Jun 20, 2016 6:10 pm
Contact:

Re: [0.17.74] Fully compressed belt decompresses

Post by mmmPI » Sun Nov 17, 2019 4:19 pm

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
Manual Inserter
Manual Inserter
Posts: 3
Joined: Thu Nov 14, 2019 5:37 am
Contact:

Re: [0.17.74] Fully compressed belt decompresses

Post by billyboy999 » Sun Nov 17, 2019 4:51 pm

mmmPI wrote:
Sun Nov 17, 2019 4:19 pm
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
Filter Inserter
Filter Inserter
Posts: 363
Joined: Mon Jun 20, 2016 6:10 pm
Contact:

Re: [0.17.74] Fully compressed belt decompresses

Post by mmmPI » Sun Nov 17, 2019 5:33 pm

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 :)

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 313
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: [0.17.74] Fully compressed belt decompresses

Post by disentius » Mon Nov 18, 2019 2:57 pm

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

Post Reply

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users