Version 0.16.25

[bobingabout]

Also, items don't "move backwards" on the belt, they overstack which then evens out when the belt moves.

That's the intended behaviour, I've actually seen videos where items on a belt move backwards when something obstructs the belt... and they don't "Move backwards" they appear to move backwards because they stop moving when they're not supposed to.

[Deadly-Bagel]

Changes

• Inserters and belt sideloading can now squash item on belt even when the gap isn't big enough. The squashed gap is extended to normal size once the front of the belt starts to move again. This means, that inserter rows and side loading can produce fully compressed belts without the usage of splitters.

I assume Mining Drills still don't compress items? I don't really mind as you tend to merge several lanes anyway, just clarifying.

[Engimage]

Changes

• Inserters and belt sideloading can now squash item on belt even when the gap isn't big enough. The squashed gap is extended to normal size once the front of the belt starts to move again. This means, that inserter rows and side loading can produce fully compressed belts without the usage of splitters.

I assume Mining Drills still don't compress items? I don't really mind as you tend to merge several lanes anyway, just clarifying.

Mining drills are compressing as well using sideloading mechanics.
However they are bugged as well as other compression tools.
But when fixed they will compress

[impetus maximus]

I assume Mining Drills still don't compress items? I don't really mind as you tend to merge several lanes anyway, just clarifying.

miner_compression.png (402.49 KiB) Viewed 6360 times

not OCD compressed, but certainly compressed enough for me.

[mathturtle]

I'm sure everyone else has already said this, but thank you for belt compression!

[vanatteveldt]

I assume Mining Drills still don't compress items? I don't really mind as you tend to merge several lanes anyway, just clarifying.

miner_compression.png

not OCD compressed, but certainly compressed enough for me.

Yeah, I noticed those gaps. We can't allow that!

Actually, it seems that the general issue is that sideloading does not 100% compress a belt. A solution for the miners is to use an UG belt to bypass the last two miners and then merge these in to fill the gaps.

The picture below shows three setups: default, UG plus merge, and UG plus sideload. As you can see, only UG plus merge fully compresses the belt:



UG plus merge has the full 2400 items/minute, while the other to are somewhere around 2340.

[Gaps are evil! Must fill all the gaps!]

[kovarex]

I spent some time with the compression fixes. I fixed few corner cases for 0.16.26 and as far as I can tell, it should be 100% now.

[Bilka]

I spent some time with the compression fixes. I fixed few corner cases for 0.16.26 and as far as I can tell, it should be 100% now.

58046 still isn't fixed which sometimes prevents compression because gaps arent closing when they should. Otherwise looking very good, thanks :)

[vanatteveldt]

I spent some time with the compression fixes. I fixed few corner cases for 0.16.26 and as far as I can tell, it should be 100% now.

58046 still isn't fixed which sometimes prevents compression because gaps arent closing when they should. Otherwise looking very good, thanks

You might have to wait until .26 is released

[Bilka]

I spent some time with the compression fixes. I fixed few corner cases for 0.16.26 and as far as I can tell, it should be 100% now.

58046 still isn't fixed which sometimes prevents compression because gaps arent closing when they should. Otherwise looking very good, thanks

You might have to wait until .26 is released

I might have source access and might have already tried 0.16.26 I might have even posted a save from that version in bug report thread I linked

[Jap2.0]

I spent some time with the compression fixes. I fixed few corner cases for 0.16.26 and as far as I can tell, it should be 100% now.

58046 still isn't fixed which sometimes prevents compression because gaps arent closing when they should. Otherwise looking very good, thanks

You might have to wait until .26 is released

I might have source access and might have already tried 0.16.26 I might have even posted a save from that version in bug report thread I linked

When are they just going to make you a moderator? You practiacally are on here already .

[DrFluffeh]

My belts are not achieving full compression with inserters

[Oktokolo]

I tested belt compression by inserters on yellow belts using my old smelter column setup and it just works. I enabled show-transport-lines and saw, that my streight belts get automatically segmented into 3-tile chunks after inserters put some items on them (belt was one segment before adding the inserters). So the game seems to optimize segment lengths on the fly.
When i change the smelter column, so that the inserters insert on 1-tile belts sideloading to the common output belt, compression is broken because the sideloading mechanics ignores the smaller gaps.

I now have seen the moving gaps in realgame too. But i also have seen inserters taking stuff from the middle of a lane segment and other inserters putting stuff onto the middle of a lane segment splitting single gaps into two or reducing gap lengths.
So the belt compression logic could very well scan for gaps further up the segment and reduce them instead of moving them too. Segments tend to get optimized to be shorter when they experience much insertation or removal of items, so performance-wise a bit of additional gap-handling logic should be fine.