Post 0.16 belt compression

[Engimage]

As we already know 0.16 brought some trouble by removing sideloading compression and undergrount belt compression.
This has left us only splitter as a valis lane compression tool which is really complex and ugly. And currently we almost can't (without complex circuit wiry) get a solid inline compression.

So I want to propose some changes on how item insertion on a belt works in general to overcome the sitiation.

As we know belt has much more "slots" for items than it transports. Every item placed in the slot will prevent several slots around from being used by other items which leads to a certain spacing between items. So there should be a gap of a certain amount of slots in a row for a new item to fit in. This is where current problem comes in. Both sideloading and underground belts did allow for an item to squeeze in if a space is smaller than required but larger than full compression.

Currently such mechanic was dropped as it required per-tile belt calculations and the new optimized belt calculations united belts into "blocks" which can't make these per-tile calculations.

I would like to propose a change to item insertion rules which could fix the situation. So.

Suggestion
Item should be inserted on a belt if there is N+1 free slots between items (where N is a full compression spacing). The belt will decompress itself at the end of the block by backing up the line while it creates a required gap.

As I understand tiles with inserters/other inputs do calculate separately (not within blocks) or act as block ends so I think something could be done to fix this.

I do love belts and I consider using bots as a "cheat" tactic. I do try to create belt based designs all around and I find them most satisfying especially when you fit something new it the limited space.
However these compression changes make belts even more problematic and there is a real limit to where it becomes ugly and unsafisfying. Using only splitters for compression will force people to use uncompressed belts for early/mid game and will definitely hit OCD of so many engineers. So I do find this problem being very important to be solved asap.

[ThaPear]

I agree, I already noticed some throughput issues in my factory. I use sideloading and underground belt compression quite a bit and feel that they allow for more efficient (and fun) designs.

[milo christiansen]

Why was this screwed up changed in the first place? The way it was worked fine.

[Deadly-Bagel]

Probably due to the new belt logic that got added to improve performance. However, if Splitters work in the same way they're not reliable either which leaves us with no simple or easy ways of ensuring belt compression.

It's really weird, with some things (like performance) the devs are really on the ball and with others like this they just don't seem to care.

[Tekky]

It's really weird, with some things (like performance) the devs are really on the ball and with others like this they just don't seem to care.

This is an experimental release. Therefore, it was to be expected that certain things may stop working, especially since most of the belt processing logic had to be rewritten for 0.16, as discussed in Factorio Friday Facts #176. That doesn't mean that the developers don't care.

Actually, in this post, one of the developers showed that he indeed does care. However, his priorities right now are on fixing more serious bugs, such as crashes. That is understandable.

[golfmiketango]

Yes, we really have to try to be patient here so the devs don't wind up regretting this early release and vowing never to release again until some elaborate QA rigamarole is performed or something like that. It's just a video game, guys! Wube has a pretty solid track record here. If Rseding says they'll get to it they'll get to it. Also, if we don't let them sleep they'll break our precious game.

Consider this: the whole reason we're habituated to putting undergrounds all over the place is because splitters were broken and belts were computationally expensive. These tricks were always gross hacks and workarounds. We should be more than willing to bid those weird traditions good-riddance in exchange for the core game dynamics being directly addressed and (eventually) fixed in 0.16.

AFAIK, splitters were always the only officially supported means of compressing a belt (even when they didn't). Something roughly like this should do the trick (even if it doesn't ):

https://youtu.be/tfYbjg6xyH8?t=16m37s

or... whatever. In other words, we'll just have to see how it shakes out.

Meanwhile, 0.15 is still the stable factorio and still works the same way it did three days ago.

[mh_]

I am against reintroducing the old changes.
They were done to improve performance and did improve logic!

The sideloading issue is a bug and will be fixed.

Removing the underground-belt compression is a good step, because it is way more natural. There is just no logic in compressing a belt when throwing stuff on it when it's underground. There is no reason an underground belt should behave different to a above-ground belt.

Also there is a simple solution to the compression problem: Just don't build furnace-array of size 18, reduce them to 12. Don't make 4 of those but 6 or even 8. A balancer after that (8 to 8/4) and you end up with a fully compressed perfect 4-belt, no ugliness there.

[BenSeidel]

Hi,
Remember that there are three competing issues for the "optimal" solution:
Casual/New players - The mechanic must be simple and understandable.
Megabase players - The mechanic must run as fast as possible
Speedrunning players - The mechanic must be as small & "simple" as possible. (simple being quick to construct)
Being a megabase player, I don't care that sideloading & compression doesn't work. The size of my individual builds is not my construction metric. Unfortunately it might be impossible to fix without causing someone in each category from being unhappy.

From the way that the algorithm has been described in the past the issue stems from not allowing that distances between items to increase. As this can occur at any stage along the belt when side loading is enabled, I'm not sure it can be fixed without a performance hit. As we already have the desired behaviour in the splitter (increases distance between items), maybe an altered splitter would solve the issue. I'm calling the new theoretical entity a "compressor". It could be a 1x1 entity that takes not only the items dropped onto it (underground belt trick) but also the items that are sideloaded into it and insert them into gaps, pausing it's input. Think of a splitter who's inputs are 3 sides instead of the 2 parallel inputs in the 2x1 splitter.

There are a number of implementations for this new "entity" including both as a mode of operation for belts and a new entity type, but that is not something that I am trying to define. I am only trying to discuss it's functionality.

While this might not be the best solution for the general player, especially when it's a mode of operation, it allows the megabase players to keep their performance gain, while simultaneously giving them control over where they are willing to take the performance hit for better compression.

Likewise the "mode" could be automatically identified and enabled. Unfortunately it will cause a performance hit for sideloading that isn't there for compression but consolidation.

Thanks.

[golfmiketango]

There is just no logic in compressing a belt when throwing stuff on it when it's underground. There is no reason an underground belt should behave different to a above-ground belt.

This! +1.

OK, truth be told, there is a way we can justify this behavior intuitively:

Code: Select all

  X              Y
(0,0)  sky     (5,0)
  v              v
====belt========) n
---ground----- \  \\  ---------
****************\  \\  \*******
*****dirt********\   u \------
******************\   (========
*******************\__^________
****************** (10,-5)
                      Z               

As the belt goes underground, it would have to accelerate, if the goods on it were to emerge at the same "flatland" speed that would have been observed with no underground. Because Pythagoras. I'm not sure if undergrounds are in fact the same speed as belts or not but it'd be trivial to find out experimentally.... anyhow, as can be "seen" above, if the distance |XY| is 5, the distance |YZ| is sqrt(50) which is more like seven.

So, in this model, as your items slid onto the faster diagonal belt segment, one could maybe jam a couple extras items in. If that's how it worked, then I guess they really would get compressed (or more likely cause a belt-jam in RL ) when they were transfered onto the slower horizontal-only belt segments under and above ground.

But that's really a hell of a stretch. I doubt that this model was in anyone's head when this dynamic entered into the game (instead, I suspect it was sort-of an unintended emergent dynamic or at best a work-around for some sort of tricky snarl in the underground-belt item-processing code). But I could certainly be wrong, maybe this was a deliberate decision from the get-go for precisely this reason.

[mh_]

As the belt goes underground, it would have to accelerate, if the goods on it were to emerge at the same "flatland" speed that would have been observed with no underground.

I would say no, because of how I understand the belts are made in real life.
There is something like a chain where the belt elements are attached to. If the chain goes under ground it wont get stretched, but the distance would enlarge. So if the devs want to model it really good a above ground belt has the lenght 32*6 for a length of 6 and doing this via underground would have 32*6+2*d, where d would be the difference between the pytagoras-thing and the length of base of the slope.

The only way you could keep your argument is when you say the things can tumble down the slope. but that would mean for me that they would stay down there. Either way we do not need underground-belt compression.

[golfmiketango]

Either way we do not need underground-belt compression.

Fully agreed, of course.

[mh_]

Hi,
Remember that there are three competing issues for the "optimal" solution:
Casual/New players - The mechanic must be simple and understandable.
Megabase players - The mechanic must run as fast as possible
Speedrunning players - The mechanic must be as small & "simple" as possible. (simple being quick to construct)
Being a megabase player, I don't care that sideloading & compression doesn't work. The size of my individual builds is not my construction metric. Unfortunately it might be impossible to fix without causing someone in each category from being unhappy.

The new solution is optimal:
Casual/New players - Much more logical.
Megabase players - Speed improvement
Speedrunning players - There are very good alternatives to underground-compression. For example switching to 12 furnaces instead of 18 and doing a balancer-reducer afterwards. Being to lazy to adapt to removing "bugs" - as the throwing on undergrounds was - is not an argument.
The side loading issue will probably be fixed.

From the way that the algorithm has been described in the past the issue stems from not allowing that distances between items to increase. As this can occur at any stage along the belt when side loading is enabled, I'm not sure it can be fixed without a performance hit. As we already have the desired behaviour in the splitter (increases distance between items), maybe an altered splitter would solve the issue. I'm calling the new theoretical entity a "compressor". It could be a 1x1 entity that takes not only the items dropped onto it (underground belt trick) but also the items that are sideloaded into it and insert them into gaps, pausing it's input. Think of a splitter who's inputs are 3 sides instead of the 2 parallel inputs in the 2x1 splitter.

Introducing a new balancer-entities changes the gameplay to much imho. If you want that you could get a mod.

[BenSeidel]

Speedrunning players - There are very good alternatives to underground-compression. For example switching to 12 furnaces instead of 18 and doing a balancer-reducer afterwards. Being to lazy to adapt to removing "bugs" - as the throwing on undergrounds was - is not an argument.
The side loading issue will probably be fixed.

The speed running issue is exemplified in the thread viewtopic.php?f=7&t=54627&p=321721#p321721 whereby constructs that allow you to make sushi belts don't function as they used to. This is an extremely advanced mechanic that allowed all sorts of amazing builds that no longer works. There is more at play than just belt compression.

[agmike]

If the underground belt compression is removed, I think inserters should be able to compress belt without any tricks. I see counter-intuitive argument being thrown against UG belt compression, but the compression is not very intuitive topic by itself. It is also not intuitive why sideloading should able to compress, while inserters by themselves can't.

[Koub]

The devs have this issue in mind, and will work on fixing it : viewtopic.php?p=322677#p322677.
There are more game breaking issues to work on first though, so a little patience would be appreciated, thank you .

[Deadly-Bagel]

I'm happy if it's on the cards =)

I'm sorry, it was unfair to say they don't care, but they do stay awfully quiet about some problems before suddenly acknowledging and fixing them. Combat is a really good example, the community got pretty loud about it over months before suddenly it was included in a FFF and implemented a few weeks later. I understand why they do it this way but sometimes a little "it's on the list" would go a long way, as often it's hard to tell whether something is considered a problem or a feature.

[mh_]

The speed running issue is exemplified in the thread viewtopic.php?f=7&t=54627&p=321721#p321721 whereby constructs that allow you to make sushi belts don't function as they used to. This is an extremely advanced mechanic that allowed all sorts of amazing builds that no longer works. There is more at play than just belt compression.

As I said in the quoted thread (and in this one), the sideloading issue is really a bug and should be resolved soon.

If the underground belt compression is removed, I think inserters should be able to compress belt without any tricks. I see counter-intuitive argument being thrown against UG belt compression, but the compression is not very intuitive topic by itself. It is also not intuitive why sideloading should able to compress, while inserters by themselves can't.

There is NO reason an inserter should be able to compress a belt. This is in no way sensible. Compression is a sensible and intuitive thing when thinking about things backing up on the belt, so the belt just moves under the items. Any other thing as an inserter compressing a belt by itself (not to mention the horrendous computational effort) is just plain counterintuitive and wrong.
Sideloading can only compress a belt because more items are input then output, the same thing goes for splitters. If the devs have any decency they won't re-implement such nonsense. It was good the underground-compression got removed.

All in all let's be honest here. There are a ton of factorio players nowadays that just slam down blueprints and reiterate just the same stupid designs over and over again without any thinking. Factorio is not meant to be played as a construction robot, but as an engineer, improving and perfecting your factory. I welcome the challenge to come up with new designs to overcome the changes.

[agmike]

There is NO reason an inserter should be able to compress a belt. This is in no way sensible.

Yes there is, right there in its name. It is inserting an item, why shouldn't it be able to insert an item by shifting the rest, especially considereing that sideloading does this exact thing? Why wouldn't specialised device be able to do what a simple belt dumping items to another's side can?

Compression is a sensible and intuitive thing when thinking about things backing up on the belt, so the belt just moves under the items.

No it is not. Belt physics is an intricate topic, explained in a pretty long wiki page, with absolutely no information or tutorials about it in the game.

not to mention the horrendous computational effort

Lets not assume the performance implication here, given how we both lack knowledge about implementation.

Sideloading can only compress a belt because more items are input then output, the same thing goes for splitters.

So by this logic inserters should compress too, because they add more items...

All in all let's be honest here. There are a ton of factorio players nowadays that just slam down blueprints and reiterate just the same stupid designs over and over again without any thinking. Factorio is not meant to be played as a construction robot, but as an engineer, improving and perfecting your factory. I welcome the challenge to come up with new designs to overcome the changes.

There are as many ways to play this game as are players, different players set different goals and have different playstyles. Especially in a sandbox game. Lets not assert what is right and what is wrong way to play here. This is a bad approach to things.

It is a matter of balance, after all. Underground belt compression was a powerful tool. Removing it makes belt designs weaker compared to other options (cough-bots-cough). Their performance might be better now (which needs testing, because splitters do split those merged belt segments, so using them a lot for compression can actually negate the improvement!), but practically they are still lacking. You have enough challenge fitting all the ingredients into those 2 tiles between assembler and beacon. Compression issues should go away.

[mh_]

Finally...
I refer most of my arguments to https://www.factorio.com/blog/post/fff-176.
In this the devs clearly specify their view on belts and the optimisations that lead to the current problems.

not to mention the horrendous computational effort

Lets not assume the performance implication here, given how we both lack knowledge about implementation.

The devs provide us with a in depth look on implementation and about performance gains from belt optimisations. All the posts in FFF about programming give you a good insight on the inner workings of the game.

There is NO reason an inserter should be able to compress a belt. This is in no way sensible.

Yes there is, right there in its name. It is inserting an item, why shouldn't it be able to insert an item by shifting the rest, especially considering that sideloading does this exact thing? Why wouldn't specialised device be able to do what a simple belt dumping items to another's side can?

First of all thank you for taking the time to take on my arguments, I appreciate that!
I think the term inserter refers to inserting into an assembler/furnace/... but I see your argument.
My basic view on belts (and please challenge that) is that an item should not move relative to the belt, unless the belt is backed up. This is in accordance to the above mentioned post. If you challenge that we have to talk about the implications of a such proposal. When reading fff-176 you will clearly see that interlocking the item positions will affect performance when inserting items on the belt by moving items on the belt. One could for example say that a inserter should back up the belt until they get a hole big enough to insert the item. This is just not how "dropping" something on a belt should work imho.

Compression is a sensible and intuitive thing when thinking about things backing up on the belt, so the belt just moves under the items.

No it is not. Belt physics is an intricate topic, explained in a pretty long wiki page, with absolutely no information or tutorials about it in the game.

Let me mention again here the fff (esp. 176). All my views are also in compliance with the mentioned wiki page https://wiki.factorio.com/Transport_belts/Physics.
The fff-176 tells you that the devs view and implement items backing up on the belt differently then the moving items.

Sideloading can only compress a belt because more items are input then output, the same thing goes for splitters.

So by this logic inserters should compress too, because they add more items...

No, because the sideloading should only work when there is space on the belt, as I said. This is the case with the 2 yellow to 1 red compression. Perhaps I was way to imprecise there in the argumentation.

All in all let's be honest here. There are a ton of factorio players nowadays that just slam down blueprints and reiterate just the same stupid designs over and over again without any thinking. Factorio is not meant to be played as a construction robot, but as an engineer, improving and perfecting your factory. I welcome the challenge to come up with new designs to overcome the changes.

There are as many ways to play this game as are players, different players set different goals and have different playstyles. Especially in a sandbox game. Lets not assert what is right and what is wrong way to play here. This is a bad approach to things.

You are just 100% right here on the point. I was just venting here about my playstyle not being the one of others, which in essence is just my problem.

It is a matter of balance, after all. Underground belt compression was a powerful tool. Removing it makes belt designs weaker compared to other options (cough-bots-cough). Their performance might be better now (which needs testing, because splitters do split those merged belt segments, so using them a lot for compression can actually negate the improvement!), but practically they are still lacking. You have enough challenge fitting all the ingredients into those 2 tiles between assembler and beacon. Compression issues should go away.

Here I got to say that just read the stuff the devs tell us: https://factorio.com/blog/post/fff-209 or https://factorio.com/blog/post/fff-204
They really obsessed with testing this. I trust them fully, that when they say it's an improvement, it really is. It is also in accordance to every post about performance changes after the patch that I read. I did not read a single "game got slower" (yes, there are bugs)
When you say it is a matter of balance we should perhaps just go with "whatever them devs do, it is" then?

Thanks again agmike for your long reply!

[mh_]

Version 0.16.25: 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.

Together with priority/filter splitters, who could have hoped for anything alike?