[0.16.25] Belt decompresses after double splitter.

[xeneonic]

Hello, I tried finding other bug reports regarding belt decompression but they were pre-16.25 so I assume this is a new one?

https://i.imgur.com/pFaXFJQ.png

I understand that the method provided in this screenshot doesn't make any sense for it to be there - it was a multiplayer server and I was trying to find out why plastic wasn't compressing onto the belt and stumbled across this. There's no priority put on any of these 3 splitters, you can see the alt toggle is enabled because of the yellow icon from the inserter below.

So before I solved the problem (useless splitters) I decided to post it here because while useless, it shouldn't have a detrimental effect on compression this way.

[Engimage]

Related
viewtopic.php?f=7&t=58031

[Zavian]

To me that image looks like it is working as intended. Starting with the splitter on the right hand side, and working right to left, the first splitter balances the belts. The second splitter sends half a belt out the top belt and the other half a belt into the third splitter. The third splitter merges that half a belt of plastic into the bottom belt. Leaving you with one and a half belts of plastic.

[Engimage]

To me that image looks like it is working as intended. Starting with the splitter on the right hand side, and working right to left, the first splitter balances the belts. The second splitter sends half a belt out the top belt and the other half a belt into the third splitter. The third splitter merges that half a belt of plastic into the bottom belt. Leaving you with one and a half belts of plastic.

Actually yes you are right Zavian. This is intended behaviour in this particular case.
It should work fine if bottom splitter had input priority set to left lane. As it is now bottom splitter backs up bottom lane cause it has to take some input from right as well.

[Jon8RFC]

On the final splitter, set the input priority to left.

[xeneonic]

To me that image looks like it is working as intended. Starting with the splitter on the right hand side, and working right to left, the first splitter balances the belts. The second splitter sends half a belt out the top belt and the other half a belt into the third splitter. The third splitter merges that half a belt of plastic into the bottom belt. Leaving you with one and a half belts of plastic.

Actually yes you are right Zavian. This is intended behaviour in this particular case.
It should work fine if bottom splitter had input priority set to left lane. As it is now bottom splitter backs up bottom lane cause it has to take some input from right as well.

Wait, how is this behavior considered correct? I understand your logic (The second splitter is trying to split one belt in half) but the original rule should override that:

80 items-per-second in over two lanes should therefore always result in 80-items-per-second out over two lanes. The second splitter can't cram items to the lower belt because it already is receiving 40/ps, unless the second splitter gets priority over the initial throughput? Is that the logic behind it? If so that seems more of a detrimental rule than a positive rule to me?

[Bilka]

To me that image looks like it is working as intended. Starting with the splitter on the right hand side, and working right to left, the first splitter balances the belts. The second splitter sends half a belt out the top belt and the other half a belt into the third splitter. The third splitter merges that half a belt of plastic into the bottom belt. Leaving you with one and a half belts of plastic.

Actually yes you are right Zavian. This is intended behaviour in this particular case.
It should work fine if bottom splitter had input priority set to left lane. As it is now bottom splitter backs up bottom lane cause it has to take some input from right as well.

Wait, how is this behavior considered correct? I understand your logic (The second splitter is trying to split one belt in half) but the original rule should override that:

80 items-per-second in over two lanes should therefore always result in 80-items-per-second out over two lanes. The second splitter can't cram items to the lower belt because it already is receiving 40/ps, unless the second splitter gets priority over the initial throughput? Is that the logic behind it? If so that seems more of a detrimental rule than a positive rule to me?

The the most bottom left splitter takes half of it's input from the top and half from the bottom, so half a belt each. This is because the splitters always take the same amount of items from each input belt. This means the splitter just before it feeds half a belt of it from the top belt, and the other half to the other belt.

pFaXFJQ.png (496.65 KiB) Viewed 5197 times

[boskid]

spliters use simple logic to determine from where to get items - with default settings, spliter with two inputs and one output is forced to take items alternating between two input belts. This is what happend in your setup with third spliter. This behavior makes lower belt (from first spliter to third) work at half throughput, so in you setup total throughput is limited to 1.5 blue belt. Implementing what you are expecting (something that goes like "there is available path to ensure 2 blue belts, make it work with two full belts") would impact game performance as searching all belt paths would be hard. Solution here is to set input priority on third spliter so it would take items from left belt.

[TheOnefinn]

Splitters cant feed information back up the production line, your logic is that since there is only output for one belt, then the bottom splitter should use the entirety of the bottom belt and let the top one "spill out", how does it know which of the 2 belts its supposed to take from?

You could flip this vertically and it would have to have the opposite behaviour.

All the bottom splitter sees is that its got items in both inputs and only gets free slots to output to on one output, it has no priority set so must alternate taking from each input. So long as that bottom splitter keeps taking from the right input then the top splitter is going to keep feeding it items from its one feed.

Your expectation is for multiple splitters placed together to work as one "logical block" and look at all the inputs and outputs together and best decide where to distribute items and they just dont do that, each splitter only "knows" about the items waiting to go in and which outputs it has spaces to output to,

[xeneonic]

I am assuming you're correct in the way the logic is handled like that (And thus this is the expected behavior) But this makes more sense:



The 0's are there because it has nothing to put there. The left-most 0 is because there's nothing in front of that splitter - it can't push forward - therefore, doesn't it make sense that anything behind that can't push forward either? (It's backed up).

The left-most splitter is already receiving 40/s to which it can distribute its items, meaning that there's nothing to split. Instead, it becomes a merger but there's nothing to merge because, it is receiving 40/s.


Anyway, I guess I'll drop my case since this is just not the way the logic is handled and this is how the game accepts it.

[Mimos]

The left-most 0 is because there's nothing in front of that splitter - it can't push forward - therefore, doesn't it make sense that anything behind that can't push forward either? (It's backed up).

You are just looking at one input and one output in this consideration but you have to look at both at the same time because they have the same priority. Both outputs are connected to both inputs in the same way, it doesn't matter if they are on the same side or on the other.

[TheOnefinn]

The left-most splitter is already receiving 40/s to which it can distribute its items, meaning that there's nothing to split. Instead, it becomes a merger but there's nothing to merge because, it is receiving 40/s.

Its not receiving 40 items/s it's receiving 60 (although it doesnt know that, all it knows is that whenever a space appears on its output, both of its inputs have items waiting)

Take each splitter one at a time and look at its inputs and outputs alone with no other information about the system.


The top splitter has items on one of its inputs, and spaces to put items on both outputs, so long as it gets spaces on both outputs it will keep distributing its inputs on both outputs, The only time it wont put an item on that output is when there are no spaces to put in in because the belt has backed up.

Now look at the bottom splitter, it has items on both inputs, and only ever sees spaces on one of its outputs, every time it sees a space open up on its output it sees items on both inputs, there is no preference given to inputs and outputs being on the same side of a splitter (it would break using splitters to merge 2 belts if it did so), so all it can do is keep alternating between its inputs.

So you have the bottom splitter merging its two saturated inputs, pulling 20 items/s from each belt to give it 40 items/sec output. As long as that bottom splitter keeps pulling 20 items/s the top splitter will keep supplying it, leaving only 20 items on the top belt.

The thing is there is already a gameplay feature to solve this. When you set an input priority on the bottom splitter you tell it to always use the bottom belt, so long as there are items on that belt whenever a slot appears on the output belt it will keep pulling from the prioritised lane, since it never pulls any items from the top splitters left output that belt is permanently backed up, no outputs appearing on its left output means that splitter is forced to put everything on the right, and you get your 40 items/s out on each belt.

Your only mechanism for stopping that top splitter outputing to its left (without setting its output priority I mean) and thus losing overall throughput is backpressure, if that splitter *cant* output left it wont, but if it can it will, and any item taken from that belt is one less that will come out of the top output.

[kovarex]

It is not a bug.