[kovarex] [0.16.7] Multiple splitters can uncompress belts

[jonatkins]

Multiple splitters can uncompress belts.

When everything is flowing at maximum output speed, small gaps form in the output belts, and brief pauses occur on the input belts.

I couldn't reproduce it with a simple pair of belts and a single splitter, so needs to be more complex. Might be splitters directly feeding splitters?

factorio-16-splitter1.png (981.29 KiB) Viewed 17369 times

factorio-16-splitter2.png (905.15 KiB) Viewed 17369 times

factorio-16-splitter3.png (270.51 KiB) Viewed 17369 times

[Linnun]

Can you reproduce this using only two rows of splitters? (Having only one splitter-to-splitter feed per lane)

[Engimage]

These belt issues are progressively depressing.

[JulianSkies]

Are you certain that this kind of mess of splitters is actually a balancer and doesn't have some weird issue wherein the output is slower than the input becuse certain portions of the input don't have sufficient output?

[Engimage]

Are you certain that this kind of mess of splitters is actually a balancer and doesn't have some weird issue wherein the output is slower than the input becuse certain portions of the input don't have sufficient output?

Why should it be a balancer? It should not. This is not any useful contraption however splitters should not alter fully compressed flow in any way

This seams to be related to random decompression issues mentioned by AntiElitz
On the last picture I do see a gap on the rightmost belt right after first splitter. If there were no gaps on input this is really bad.

[hitzu]

It's a limited throughput "balancer" and therefore it can produce gaps by design. For the sake of clear testing try to test it with just one row of splitters, and make another test with additional splitters on the sides instead of solo tile belts.

[Zavian]

Hitzu why should that design limit throughput when it's being fed 6 full belts?

I do understand that it won't balance the belts if one of the belts is empty, but even then, provided none of the output lanes are backed up, it's output items per second should be exactly equal to it's input items per second. Yes in a balancer you do want to handle an output lane/belt being backed up, and this design doesn't do that, but that doesn't explain the stutters visible in the picture.

[Koub]

I'm pretty sure all these, as pointed out by PacifyerGrey, are side effect issues of the hardcore belt optimizations the devs added in 0.16 to allow players to make always bigger factories without having to buy a supercalculator. Once the game-braking bugs will have been fixed, they will have some time to find-out how to solve these random belt compression losses, without having to sacrifice too much the performance optimizations. Until then, fly safe please be patient

[attila]

Can you reproduce this using only two rows of splitters? (Having only one splitter-to-splitter feed per lane)

This is the simplest setup I could reproduce the bug:

f_gaps2.png (340.38 KiB) Viewed 17178 times

More gaps with more splitters:

f_gaps.png (524 KiB) Viewed 17178 times

More visible when it is moving...

Note: sometimes the gaps disappear after a while, sometimes not.

[golfmiketango]

I'm pretty sure all these, as pointed out by PacifyerGrey, are side effect issues of the hardcore belt optimizations the devs added in 0.16 to allow players to make always bigger factories without having to buy a supercalculator. Once the game-braking bugs will have been fixed, they will have some time to find-out how to solve these random belt compression losses, without having to sacrifice too much the performance optimizations. Until then, fly safe please be patient

Probably this is true, however, it is notable that, from an end-user's vantage point, precisely the same type of bugs are observable in 0.15. From our perspective, the existing problem simply got worse in 0.16. In 0.15 this got tabled until 0.16. Now in 0.16, we find ourselves in effectively the same situation seeing as it has been announced that belted logistics require some retooling and have some pretty wacky bugs pertaining to compression and side-loading etc. Oh, well, life is hard. Perhaps we shouldn't have gotten ourselves crash-landed on an alien planet given that the laws of physics had yet to coalesce I guess there really is "no spoon" (oh, wait, sorry, I just dropped it under the table).

[golfmiketango]

Can you reproduce this using only two rows of splitters? (Having only one splitter-to-splitter feed per lane)

This is the simplest setup I could reproduce the bug:

f_gaps2.png

More gaps with more splitters:

f_gaps.png

More visible when it is moving...

Note: sometimes the gaps disappear after a while, sometimes not.

If you have enough steel plate or plastic around to test with those, it's a bit more visually apparent. Or sum up "read-hold" of nine contiguous segments of belt and compare to 64 works pretty good (this can give false positives for a tick or two but never three contiguous ticks). quyxkh has an ongoing effort to find an elegant combinatoric compression loss detector that uses less belt entities; looks like it's proving to be a fun challenge.

[CmdrKeen]

1-2-belt.jpg (162.92 KiB) Viewed 17114 times

EDIT: workaround: increase splitter speed (tested at *1.1), but causes another bug

[golfmiketango]

1-2-belt.jpg

EDIT: workaround: increase splitter speed (tested at *1.1), but causes another bug

Wait, you mean there is some way in lua to change the speed of the vanilla splitters? I guess that's not really surprising now that I think about it... how's that done?

[Jackalope_Gaming]

1-2-belt.jpg

EDIT: workaround: increase splitter speed (tested at *1.1), but causes another bug

Wait, you mean there is some way in lua to change the speed of the vanilla splitters? I guess that's not really surprising now that I think about it... how's that done?

Belts have their own speeds in the game files. For the regular yellow belt the file to look at is Factorio/data/base/prototypes/entity/demo-entities.lua. For the rest of the belts the file to look at is Factorio/data/base/prototypes/entity/entities.lua. Regular yellow belts, undergrounds, and splitters are speed = 0.03125, red belts are speed = 0.0625, and blues are speed = 0.09375.

These don't line up with the 13.33, 26.66, or 40 numbers we usually think of though, but it's pretty clear blues are 3 times as fast as yellow and reds are 2 times as fast as yellow.

[kovarex]

1-2-belt.jpg

EDIT: workaround: increase splitter speed (tested at *1.1), but causes another bug

Wait, you mean there is some way in lua to change the speed of the vanilla splitters? I guess that's not really surprising now that I think about it... how's that done?

Belts have their own speeds in the game files. For the regular yellow belt the file to look at is Factorio/data/base/prototypes/entity/demo-entities.lua. For the rest of the belts the file to look at is Factorio/data/base/prototypes/entity/entities.lua. Regular yellow belts, undergrounds, and splitters are speed = 0.03125, red belts are speed = 0.0625, and blues are speed = 0.09375.

These don't line up with the 13.33, 26.66, or 40 numbers we usually think of though, but it's pretty clear blues are 3 times as fast as yellow and reds are 2 times as fast as yellow.

The speed in the lua file is meters (tiles) per second.
The reason while the numbers are multiplies of 0.03125 is because it is exactly 1 pixel per frame on normal resolution, so the movement looks fluid.

[CmdrKeen]

EDIT: workaround: increase splitter speed (tested at *1.1), but causes another bug

It's not a workaround, actually. :/

[kovarex]

Can you reproduce this using only two rows of splitters? (Having only one splitter-to-splitter feed per lane)

This is the simplest setup I could reproduce the bug:

f_gaps2.png

More gaps with more splitters:

f_gaps.png

More visible when it is moving...

Note: sometimes the gaps disappear after a while, sometimes not.

I'm trying to reproduce it, but without success, could you provide a save file please?

[CmdrKeen]

Full reproduction steps using the saves below:
The save was made in .15 to test existing belt behavior on the bug. As expected, the belt will work as expected. (even under long times at game.speed = 100). Edit: when imported to .16, the belts display the same behavior as .15

- when the input flow is interrupted (such as pressing f to pick up items off the belt) it will trigger the behavior happening within moments of releasing the f key. The behavior will oscillate on and off every few seconds.

[attila]

Can you reproduce this using only two rows of splitters? (Having only one splitter-to-splitter feed per lane)

This is the simplest setup I could reproduce the bug:

The attachment f_gaps2.png is no longer available

More gaps with more splitters:

The attachment f_gaps.png is no longer available

More visible when it is moving...

Note: sometimes the gaps disappear after a while, sometimes not.

I'm trying to reproduce it, but without success, could you provide a save file please?

I've created the save with 0.16.15

The gaps are hard to notice on some zoom levels, try to zoom in/out

splitter_compression_bug.zip

(1.89 MiB) Downloaded 227 times

[kovarex]

Thanks for the save, it helped me to figure out what was causing it, this one was quite hard, but the more happy I was when I solved it
I used variant of it for the automated test that checks that splitters won't uncompress belts this way again.

TL;DR
Fixed for the next release.