[Kovarex] [0.16.0] Sideloading works completely different now

[Jap2.0]

The only (half) valid reason for me might be that belt optimization would break at all side loadings. But why does it then work sometimes in the example above and sometimes not.

Because the red belt does not have exact double the throughput of the yellow one I assume.

Yes it does. 13 1/3 vs 26 2/3.

Edit: also visible in the tooltip.

[ospeovedos]

As you will get used to the changes you will see that you will get new solutions to the problem that make it look even better, just be a little patient. As a solution to the missing underground-compression I already suggested making shorter furnace arrays and use balancers to compress the belt. This is way more streamlined and beautiful than before.

Unfortunately, my balancers no longer compress the belt in all cases:

Factorio decompression.png (353.56 KiB) Viewed 7266 times

The lane on the left side of both yellow input belts is completely compressed, meaning there are always enough items to fill the output belt. Unfortunately, whenever the items come along on the right lane, the output gets a gap in it.

As far as I can tell, the only way to make a balancer that compresses in all cases, without using a faster belt speed, is to split off the input to feed two balancers like the one in the picture then combine them with a splitter. It's a big mess.

[golfmiketango]

As you will get used to the changes you will see that you will get new solutions to the problem that make it look even better, just be a little patient. As a solution to the missing underground-compression I already suggested making shorter furnace arrays and use balancers to compress the belt. This is way more streamlined and beautiful than before.

Unfortunately, my balancers no longer compress the belt in all cases:

Factorio decompression.png

The lane on the left side of both yellow input belts is completely compressed, meaning there are always enough items to fill the output belt. Unfortunately, whenever the items come along on the right lane, the output gets a gap in it.

As far as I can tell, the only way to make a balancer that compresses in all cases, without using a faster belt speed, is to split off the input to feed two balancers like the one in the picture then combine them with a splitter. It's a big mess.

Never thought of that but if side-loading won't compress outputs this would seem like the logical result and, pretending for a moment that nothing was going to change from how things are right now, I believe your split -> lane-balance x 2-> join work-around would be the obvious solution. Assuming balancers work, again, probably one could get away with a few less lane-balancers than (number of belts * 2) to lane-balance a bunch of belts (but certainly more than (number of belts * 1)).

[Killcreek2]

Currently there is only one method to compress a belt ~ splitters ~ this is a rather Un-Factorio, imho:
There are alternatives methods to do nearly everything else ingame: move items from A->B, destroy biters, power generation, control circuits, etc. So being forced to use only a single method to compress a belt reduces player choice too far [no choice at all is less fun].

However, making inserters able to compress a belt directly would be a step too far the other way [too easy, no challenge, less fun].
Getting rid of the "insert onto underneathies" exploit is a great change ~ that always felt hacky to me anyway.

But sideloading compression is very useful for other things too: such as a belt-prioritiser. Example:

~ In 0.15, that simple setup worked flawlessly ~ always gave a fully compressed belt output even if mixed, & pulled from the input belts in the right order. Can be built right from the start of the game.
~ In 0.16, that setup still prioritises items correctly, but will NOT give a compressed output if the inputs belts have items spaced apart at specific distances [based on belt speed] ~ at worst case only half-compressed output [just over 50%].
~ Rebuilding this setup to work properly in current 0.16 will require circuit wires & splitters, OR: splitting before, doubling-up on the entire process, & combining with a splitter afterwards. Requiring various research to be completed first. Example:

Yuck, compared to the older method. It gets even worse if you want to do both sides of a belt...


Summary:
Ideal amount of options in vanilla would be twofold: splitter OR sideload. That feels right to me: the player has options to choose from, but still some challenge remaining.

Keep up the great work, Wube!

[Psychofraculator]

This is my first post here and I just don't understand how these changes could have been intentional in the raw logic of things. Making the most basic transport system harder with limited ways to get old functions back feels difficult to newer players.

[rbtcollins]

I very much object to having 'just one way to do it' - that means that we'll end up with exactly one build that newcomers don't know, frustrated newcomers, and less interesting variations.

This is precisely the 0.12 corners bugfix discussion again: in 0.12 anyone using a belt with a corner would lose compression and be mystified; experienced folk had a workaround. Yeuck.

I'll be sad if insert-into-underground stops working, because beaconed furnances in 0.15 were very beautifully compact by making use of that capability. It is a little game-breaking, being such a powerful thing, so sad but not heartbroken. Having Just One Right Answer: heartbroken.

[impetus maximus]

people, the devs are going to do something about it.

"This is something we're aware of and we do plan on making it work nicer. Simply we've got more important issues to fix at the moment but we will get around to this eventually."

try and hang in there while they fix more pressing issues.

[Ubertwink]

I just don't understand how these changes could have been intentional in the raw logic of things.

They are not. Developers have done a ton of belt performance optimizations in 0.16, and this is just an unwanted byproduct. Be patient!

[ThaPear]

I just don't understand how these changes could have been intentional in the raw logic of things.

They are not. Developers have done a ton of belt performance optimizations in 0.16, and this is just an unwanted byproduct. Be patient!

This is not exactly true. Friday Facts #221 tells us that they believe splitters should be the only way to compress belts, which would make a LOT of base designs infeasible and would make building space efficient layouts, as I like to do, impossible.
It remains important to mention these things, as what might seem like an error to us could be a design decision.

[milo christiansen]

A very poorly thought out design decision...

[Philip017]

glad that im not the only one thinking this is something that is broken i hope they address this issue at some point in 16.

feeding a whole yellow belt onto one side of a red belt should be very possible.

15.40 this is the expected way i feel it should work, note the steel

shouldbe.jpg (145.38 KiB) Viewed 7081 times

15.40 functioning as expected

shouldbe.gif (1.81 MiB) Viewed 7081 times

16.4 this is not right.

16.4 something is wrong note the steel.

bug.jpg (198.38 KiB) Viewed 7081 times

16.4 belt bug

bug.gif (1.31 MiB) Viewed 7081 times

this works as a work around until they get this issue worked on

another work around

workaround.jpg (152.81 KiB) Viewed 7074 times

[impetus maximus]

Philip017 that workaround works but at anything below full speed it won't be balanced on the input.
these will be balanced on the input side.

red.side.loading.png (64.96 KiB) Viewed 7061 times

[JareX]

See?

Having to put those complicated workarounds is not "skill", it's just an annoyance.

Sideloading should work automatically, and inserters should compress the belt by themselves.

[milo christiansen]

One thing that no one has mentioned here yet: This change (together with the also ill considered underground belt change) makes bots better. Bots are boring easy mode, and the last thing the game needs is yet another thing making them simpler than belts.

[Philip017]

Philip017 that workaround works but at anything below full speed it won't be balanced on the input.
these will be balanced on the input side.

true the input wont be balanced, but in this case i only need the belt to be fully compressed, and don't need it to be a balanced draw.

i do use balanced draw on some of my inputs that draw huge amounts of plates/ores in uneven amounts per belt side, like the green circuts.

[elypso]

See?

Having to put those complicated workarounds is not "skill", it's just an annoyance.

Sideloading should work automatically, and inserters should compress the belt by themselves.

Exactly my thought.
Factorio is meant to seek for optimization and compression.

Those workarounds looks to me like a big annoyance and a big regression for optimization.

I really hope the devs are coming with a solution

[Twoflower]

I exclusively registered on the forums to report this as well.

For me this change may not be game breaking but heart breaking. It completely makes the game not fun for me, which saddens me a lot.

Same for me.

Compressed belts are important to calculate ratios and make efficient automation. Which this game is all about for me. If anything IMO it should be made easier to have fully compressed belts, not harder.

[bobbravo2]

+1 - We need to make belt compression easier, not harder for new players. Sideloading should work, having to use a splitter is counterintuitive for how it SHOULD work.

As far as having inserters automatically compress belts, I'm mixed on this - although I think it is unintuitive to have idle machines that have an inserter holding materials over it, while a belt goes by with gaps on it. If that's the case, then YES, inserters should compress belts as well.

As others have said, this makes Bots even more attractive, and it is EXACTLY what I'm finding myself doing on my own 16.4 megabase as we speak, my main bus has been made inefffiecient now, so I'm backfilling materials with trains and bots.

[Zavian]

So I've spent the last few days working on belt based layouts. I'm not having any difficulty in getting a compressed belt with a splitter. In most cases I've been able to divert an output belt after it is about half full, tunnel under some inserters then merge it back into another output belt. I have yet to find a design that I can't fix to work with the new mechanics. The new designs aren't as elegant as the old practice of inserting into an underground belt was, but I wouldn't call them hard.

My next task will be experimenting with circuit controlled inserters viewtopic.php?f=5&t=55005 . That looks like an even more elegant solution than undergrounds.

[JareX]

So I've spent the last few days working on belt based layouts. I'm not having any difficulty in getting a compressed belt with a splitter. In most cases I've been able to divert an output belt after it is about half full, tunnel under some inserters then merge it back into another output belt. I have yet to find a design that I can't fix to work with the new mechanics. The new designs aren't as elegant as the old practice of inserting into an underground belt was, but I wouldn't call them hard.

My next task will be experimenting with circuit controlled inserters viewtopic.php?f=5&t=55005 . That looks like an even more elegant solution than undergrounds.

I'm trying to find a word to describe when something wrong is made to seem normal because it is common.... that's what I think is happening here.

Having to "spent the last few days" trying to solve that problem (that shouldn't be a problem, even with a elegant solution) proves that is an unnecesary annoyance, specially for new players that already have a daunting experience with all the factorio features. Every item and asset in the game should work as intended and not to be counterintuitive. The fact that old players are used to those trickery doesnt mean it's normal or the right thing to keep.