Surprising splitter behavior

[golfmiketango]

Maybe this is a working-as-designed thing, maybe not. It does not comport with my expectations & if it's working as designed, I'd sure like to understand why.

Here I have chained together a crapload of 4->4 balancers with an extra couple splitters in each into which we can inject some stuff

Very Very Balanced

Boring.png (4.08 MiB) Viewed 3130 times

With all the inserters idle, we can see that from 4 fully compressed inputs we get 4 fully compressed outputs, exactly as expected:

Nothing to see here

StillBoring.png (2.93 MiB) Viewed 3130 times

Now I turn on the inserters so that, at each balancer, a trickle of extra stuff goes into two of the outgoing input-balanced lines:

Inserters Activated

InsertingInterest.png (3.22 MiB) Viewed 3130 times

The end result is quite surprising to me. By adding more stuff to the splitter, I get less output (notice the lines are no longer 100% compressed):

Weird.

Interesting.png (3.52 MiB) Viewed 3130 times

What gives?

Save attached.

[GodricSeer]

I think this is caused by the item from the inserter being out of phase with the compressed items. Note that in the example below, I'm not sure the exact numbers are right, but the concepts should be.

Imagine a lane of a belt has 9 positions that an item can be at, and each item is 4 spaces wide. So a fully compressed lane could have items at location 1, 5, and 9 (with the last item overlapping onto the upstream belt) with lower location numbers being in front. Each tick every item is moved forward 2 locations. This is exactly the same inside a splitter, only there are two input lanes. Now you have the bottom lane that has item A at 1, B at 5, and C at 9, and is fully compressed. On the top input you have a single item D at location 6. Splitters pull evenly from both inputs when they can, so when the item on the top input needs to be output, it will get priority. The splitter can't move an item forward on the belt, because that would make it magically faster than it should. So when it updates, item A goes to location -1 (it moves forward one belt), but now item B and D would overlap on the belt with B at location 3 (taking space back to 6), and D at location 4 (taking space back to 7). Since the splitter has not had many inputs from the top lane, it gives D priority, even though it is technically behind B. So now you have A at -1, D at location 4 (there is now a gap between A and D). B and C are not moved forward and are still on the input lane. A few updates later A is at -5, D is at location 0, B is at 4, and C at 8. There has been a gap injected between A and D, with D-B-C being fully compressed.

If you inject something like copper ore instead of iron, you will likely see that the gaps are directly in front of the injected items.

[golfmiketango]

I think this is caused by the item from the inserter being out of phase with the compressed items. Note that in the example below, I'm not sure the exact numbers are right, but the concepts should be.

Imagine a lane of a belt has 9 positions that an item can be at, and each item is 4 spaces wide. So a fully compressed lane could have items at location 1, 5, and 9 (with the last item overlapping onto the upstream belt) with lower location numbers being in front. Each tick every item is moved forward 2 locations. This is exactly the same inside a splitter, only there are two input lanes. Now you have the bottom lane that has item A at 1, B at 5, and C at 9, and is fully compressed. On the top input you have a single item D at location 6. Splitters pull evenly from both inputs when they can, so when the item on the top input needs to be output, it will get priority. The splitter can't move an item forward on the belt, because that would make it magically faster than it should. So when it updates, item A goes to location -1 (it moves forward one belt), but now item B and D would overlap on the belt with B at location 3 (taking space back to 6), and D at location 4 (taking space back to 7). Since the splitter has not had many inputs from the top lane, it gives D priority, even though it is technically behind B. So now you have A at -1, D at location 4 (there is now a gap between A and D). B and C are not moved forward and are still on the input lane. A few updates later A is at -5, D is at location 0, B is at 4, and C at 8. There has been a gap injected between A and D, with D-B-C being fully compressed.

If you inject something like copper ore instead of iron, you will likely see that the gaps are directly in front of the injected items.

I like your hypothesis but if I put in a different ore it comes out fully compressed. It only seems to happen joining like items with intermittent backpressure. But I'm not sure this disproves your hypothesis -- the idea of mixing item types may be ignoring some subtlety of how splitters make routing decisions on mixed belts (indeed once the injected item-type begins to overwhelm the original item-type and take over the output belts due to back-pressure, the compression-loss returns). I think I can still test your hypothesis with some kind of inserter-timing combinator build, but I'll have to think about it...

[Klonan]

Thanks for the report,

This is probably due to some specific oddities with the update order of all the entities,
It may already be solved with the belts optimizations of 0.16,

So i consider it not worth to fix at this time

[golfmiketango]

Klonan has spoken so perhaps there is little left to say about this, but, for the record, I think this build disproves -- or at least notably fails to support -- Godricseer's hypothesis:

Random

Random.png (3.88 MiB) Viewed 3012 times

Here I have built a combinator-based 1-bit tick-for-tick pseudorandom number generator which randomly activates or does not activate a section of belt with 50% probability (using a Blum Blum Shub generator with p=11 and q=19, for those interested in such things), and then split, and then lane-balanced the outputs and shoved them into splitters which recieve a fully compressed belt input on the other side. The result is fed into a strict compression-loss detector. As can be seen, no compression loss happens, even if we run the thing for a long time. There is something about the way I've daisy-chained those balancers that brings about the issue -- introducing random timing jitter is apparently insufficient to cause the problem.

[mrvn]

I think this is caused by the item from the inserter being out of phase with the compressed items. Note that in the example below, I'm not sure the exact numbers are right, but the concepts should be.

Imagine a lane of a belt has 9 positions that an item can be at, and each item is 4 spaces wide. So a fully compressed lane could have items at location 1, 5, and 9 (with the last item overlapping onto the upstream belt) with lower location numbers being in front. Each tick every item is moved forward 2 locations. This is exactly the same inside a splitter, only there are two input lanes. Now you have the bottom lane that has item A at 1, B at 5, and C at 9, and is fully compressed. On the top input you have a single item D at location 6. Splitters pull evenly from both inputs when they can, so when the item on the top input needs to be output, it will get priority. The splitter can't move an item forward on the belt, because that would make it magically faster than it should. So when it updates, item A goes to location -1 (it moves forward one belt), but now item B and D would overlap on the belt with B at location 3 (taking space back to 6), and D at location 4 (taking space back to 7). Since the splitter has not had many inputs from the top lane, it gives D priority, even though it is technically behind B. So now you have A at -1, D at location 4 (there is now a gap between A and D). B and C are not moved forward and are still on the input lane. A few updates later A is at -5, D is at location 0, B is at 4, and C at 8. There has been a gap injected between A and D, with D-B-C being fully compressed.

If you inject something like copper ore instead of iron, you will likely see that the gaps are directly in front of the injected items.

I like your hypothesis but if I put in a different ore it comes out fully compressed. It only seems to happen joining like items with intermittent backpressure. But I'm not sure this disproves your hypothesis -- the idea of mixing item types may be ignoring some subtlety of how splitters make routing decisions on mixed belts (indeed once the injected item-type begins to overwhelm the original item-type and take over the output belts due to back-pressure, the compression-loss returns). I think I can still test your hypothesis with some kind of inserter-timing combinator build, but I'll have to think about it...

Splitters split per item type. So the iron ore, aparently, will not be blocked by a copper ore on the other lane because iron and copper ore make independent decision which input to use.