[Kovarex] [0.16.0] Sideloading works completely different now

[Aidiakapi]

Since 0.16.0 sideloading onto a belt no longer increases its compression, something that was added in 0.13.0.

Video: https://youtu.be/uvBmadktii8

[Loewchen]

This is working as intended. I merged all the side-loading topics, lets see what comes from it.

[mishugashu]

How would you compress a belt in 0.16 then? This is the only way I've ever compressed a belt.

[AntiElitz]

I already know that sideloading isn't supposed to compress a belt anymore and it's not a bug. Even tho i think this is a very bad change and trows us back to 0.12 times, I still consider this being a bug.

[zakurias]

I cant believe that that sideloading bug is working as intended.
You can still sideload compressed, but the build order is important.

If your last belt from the sideloading track is 90 degree to the target track sideloading does not work:




If your last belt from the sideloading belt is 180 degree to the target track sideloading works:




Merged...

[orzelek]

I'd say that this should be moved out from not a bug and re-evaluated again. Pictures above show that something strange is going on... and such inconsistency should be considered a bug.

[Koub]

I'd say that this should be moved out from not a bug and re-evaluated again. Pictures above show that something strange is going on... and such inconsistency should be considered a bug.

[Koub] Agreed. I'm moving this topic back to bug reports because of the inconsistency in result with identical designs differing only by build order.

[yohannc]

I'd say that this should be moved out from not a bug and re-evaluated again. Pictures above show that something strange is going on... and such inconsistency should be considered a bug.

It's because items on inner side of the curve don't go at the same speed as on the outer side. And the way they stack at his red belt depend how his items are aligned on the 2 sides of his yellow belt at the junction with the red one.
So for me it's not a bug.

Merged...

[orzelek]

I'd say that this should be moved out from not a bug and re-evaluated again. Pictures above show that something strange is going on... and such inconsistency should be considered a bug.

It's because items on inner side of the curve don't go at the same speed as on the outer side. And the way they stack at his red belt depend how his items are aligned on the 2 sides of his yellow belt at the junction with the red one.
So for me it's not a bug.

Merged...

Technically items go through same turn just before the merge.
Why would build order of turns before the merge affect it's results?
Both belts are full and compressed yet side loading works differently in those cases and belt setup is identical.

[ichVII]

This is a major change to how the game works. If it is intended by the devs, they should at least explictly tell this in the change log. If not, it should be considered a bug imo.

[tzwaan]

Even when at first it's sideloading everything "correctly" because of the build order, it can still break after a while even though nothing changes.

[Aidiakapi]

This is a major change to how the game works. If it is intended by the devs, they should at least explictly tell this in the change log. If not, it should be considered a bug imo.

I agree, these changes should've been mentioned in the changelog. But afaik in 0.15 there are only 4 ways to fully compress a belt:

1. Insert on underground belts.
2. Sideload.
3. Splitters*
4. Use precisely timed circuit controlled inserter swings. This is also broken due to items creeping forward.

*Xterminator has told me splitters do not fully compress a belt all the time, and actually shouldn't be on this list then. I personally do not know.

So either all, or all but 1 of the methods have been removed.

[Engimage]

I find this a game breaking bug.
This just can't be intended and should be fixed.
It is one of the basics of the belt mechanics.

I have heard that for the same reason underground belts stopped compressing outputs (can't find links now). I think it is as bad thing as well.

[LD100]

Even when at first it's sideloading everything "correctly" because of the build order, it can still break after a while even though nothing changes.

This unpredictable behavior is frustrating. I don't know why side loading should not compress the belt.
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.

Edit: As a work around for me the mixed sideloading works for me all the time if use a splitter right before it.

[Loewchen]

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.

[otobot1]

Whether or not this was an intended change, I think it's a very bad change. Especially as I heard (haven't had time to confirm) that undergrounds no longer fully compress either. Sideloading and compressing with underground belts is a fundamental part of how basically everyone designs their bases. How on earth are we supposed to compress our belts now? Even if I'm wrong about the undergrounds, this change will make a lot of builds well less tidy for no good reason that I can see. Honestly, the inability to compress belts is a good enough reason for me to not update to 0.16. I consider this game-breaking.

[mrvn]

Most side balancers split a belts in two and then side load them back onto a belt. Will that be broken too? Or will it still work right because (usually) the belts are all the same speed in the balancer?

[The Eriksonn]

Could it be this that broke my splitter based sorting furnace? It has been running fine for a few hours at a time Before, but now broke instantly when update happend

I will probebly start a new World anyway becauce of worldgen and such...

[Aidiakapi]

Could it be this that broke my splitter based sorting furnace?

I did test belt based sorters, and they seem fine, so probably not.

[mh_]

SO
This is a bug, but it is not obvious why. I think it is connected to viewtopic.php?f=7&t=54693.
In my test this went all well. This means, that the speed of the yellow belt is exactly half of the red one. When a fully loaded one sided belt drops on a red one there are spaces of 9 (of 32) between each pair of items. The items fall in those spaces perfectly. The posted video

works perfectly.
I think because of item creep the space gets down to 8 places temporarily so that the items cannot drop in there.
I suggest that the devs solve the item creep problem and this one will go away.