Version 0.16.25

Information about releases and roadmap.
User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 5827
Joined: Fri May 09, 2014 1:01 pm

Re: Version 0.16.25

Post by bobingabout » Fri Feb 23, 2018 9:14 am

Deadly-Bagel wrote: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.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.

User avatar
Deadly-Bagel
Smart Inserter
Smart Inserter
Posts: 1490
Joined: Wed Jul 13, 2016 10:12 am

Re: Version 0.16.25

Post by Deadly-Bagel » Fri Feb 23, 2018 10:07 am

FactorioBot wrote: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.
Money might be the root of all evil, but ignorance is the heart.

PacifyerGrey
Filter Inserter
Filter Inserter
Posts: 958
Joined: Wed Jun 29, 2016 10:02 am

Re: Version 0.16.25

Post by PacifyerGrey » Fri Feb 23, 2018 10:17 am

Deadly-Bagel wrote:
FactorioBot wrote: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 :)

User avatar
impetus maximus
Smart Inserter
Smart Inserter
Posts: 1299
Joined: Sat Aug 20, 2016 10:07 pm

Re: Version 0.16.25

Post by impetus maximus » Fri Feb 23, 2018 10:24 am

Deadly-Bagel wrote: 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
miner_compression.png (402.49 KiB) Viewed 1185 times
not OCD compressed, but certainly compressed enough for me.

mathturtle
Inserter
Inserter
Posts: 38
Joined: Sat Jan 21, 2017 8:19 pm

Re: Version 0.16.25

Post by mathturtle » Fri Feb 23, 2018 12:44 pm

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

vanatteveldt
Filter Inserter
Filter Inserter
Posts: 836
Joined: Wed Nov 25, 2015 11:44 am

Re: Version 0.16.25

Post by vanatteveldt » Fri Feb 23, 2018 3:54 pm

impetus maximus wrote:
Deadly-Bagel wrote: 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:

Image

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
Factorio Staff
Factorio Staff
Posts: 6662
Joined: Wed Feb 06, 2013 12:00 am

Re: Version 0.16.25

Post by kovarex » Fri Feb 23, 2018 10:52 pm

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.

User avatar
Bilka
Factorio Staff
Factorio Staff
Posts: 953
Joined: Sat Aug 13, 2016 9:20 am

Re: Version 0.16.25

Post by Bilka » Fri Feb 23, 2018 11:04 pm

kovarex wrote: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.
https://forums.factorio.com/58046 still isn't fixed which sometimes prevents compression because gaps arent closing when they should. Otherwise looking very good, thanks :)
I'm an admin over at https://wiki.factorio.com. Feel free to contact me if there's anything wrong (or right) with it.

vanatteveldt
Filter Inserter
Filter Inserter
Posts: 836
Joined: Wed Nov 25, 2015 11:44 am

Re: Version 0.16.25

Post by vanatteveldt » Sat Feb 24, 2018 11:13 am

Bilka wrote:
kovarex wrote: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.
https://forums.factorio.com/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 :)

User avatar
Bilka
Factorio Staff
Factorio Staff
Posts: 953
Joined: Sat Aug 13, 2016 9:20 am

Re: Version 0.16.25

Post by Bilka » Sat Feb 24, 2018 12:43 pm

vanatteveldt wrote:
Bilka wrote:
kovarex wrote: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.
https://forums.factorio.com/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 :)
I'm an admin over at https://wiki.factorio.com. Feel free to contact me if there's anything wrong (or right) with it.

Jap2.0
Smart Inserter
Smart Inserter
Posts: 1607
Joined: Tue Jun 20, 2017 12:02 am

Re: Version 0.16.25

Post by Jap2.0 » Sat Feb 24, 2018 3:22 pm

Bilka wrote:
vanatteveldt wrote:
Bilka wrote:
kovarex wrote: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.
https://forums.factorio.com/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 :P .
There are 10 types of people: those who get this joke and those who don't.

DrFluffeh
Burner Inserter
Burner Inserter
Posts: 6
Joined: Wed Aug 10, 2016 3:04 pm

Re: Version 0.16.25

Post by DrFluffeh » Sat Feb 24, 2018 11:13 pm

My belts are not achieving full compression with inserters

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 274
Joined: Wed Jul 12, 2017 5:45 pm

Re: Version 0.16.25

Post by Oktokolo » Sun Feb 25, 2018 2:51 am

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.

Post Reply

Return to “Releases”