[kovarex] [0.16.25] Splitter input priority not working with two outputs

[Mimos]

I noticed that input priority on splitters doesn't work if two outputs are connected.

GIF.gif (454.08 KiB) Viewed 9147 times

Both inputs are compressed red belts, both outputs are yellow belts.

One workaround ist placing two splitters behind each other with just one belt connecting them. It gets more complicated if the peak throughput is 2 belts instead of one belt.

[Aeternus]

Can you verify that if you cut the top flow (which should be low priority) that the exit belts are both still compressed? I've got this functionality in use in my factory and it is working fine for me... Got a sneaky suspicion the belt feeding the splitter isn't a red.

[impetus maximus]

i was able to reproduce this. populate the belt with the outputs blocked.
select the input priority. finally give the exits somewhere to go.

save showing the condition.

Splitter_input_priority_0.16.25.zip

(908.23 KiB) Downloaded 210 times

[Engimage]

I think this will not reproduce if used with same color belts.
Anyways this is most likely related to low splitter item buffer size. When belt and splitter speeds desync it causes weird issues. And I think it did long before this.
Related:
viewtopic.php?f=7&t=58001
This particular post by MadZuri viewtopic.php?f=11&t=56446#p333242
I am sure this one is related too viewtopic.php?f=7&t=57852
The cause I see is too small inner item buffer for the splitter. The issue arises because on a certain shift in item slots within splitter itself.
I'll give a possible hint here. Say item is moving on internal slots of a red splitter. Splitter has say 20 inner slots and the item is on 19th. So within next tick item should exit the splitter but with both exits blocked the item is moved to 20th slot instead effectively losing 1 slot in speed. Such shifts will lead to possible gaps on output. So there should be an internal splitter buffer for inputs/outputs which will help negate these shifts. Probably there is already such a buffer (like 1 item per lane) but when there is a trouble with one lane (say you have 1 input lane) or speed desync on output lane you will get such problems. So the buffer should probably hold 2 items instead.

[quyxkh]

I think the new item-blind splitters make investigating this simpler than it would have been before, fiddling with output belt types and splitter priorities on this setup

blueprint

Code: Select all

0eNqtl2FvsyAQgP8Ln3HhbLXWv7IsjdXbRqJgAJc1jf99oEu7rF168L6fjILPnSc8p2d27CccjVSO1WcmW60sq5/PzMo31fThmjuNyGomHQ6MM9UM4Qw/R4PWZs40yo7auOyIvWMzZ1J1+MlqmDkZ0uumQ/Pj5nx+4QyVk07ims5ycjqoaTj6mTVcGFK9SuWHsvYdrfPsUVt/m1YhqkdlFWcnf4CFvs49WHROqjcb5hgc9AceJj/WOzTYHUKSfsiZCTlbr65JfIdstX8m7g9TKFohOBt0FwYal/XYLFlcqvAyh0L8Sj//qwS36ZdPxfUBOmmwXUc94rumenLjFEp/E2bz6HXdhtveD3YHvo2HF2R4EQ/fkOFlPDwnw3fxcCDDqxu4HXvp3L2VI1aqeCoec/cX7qNk6YUAEV0JeiEAouH09QF5NJy+bSB+U9K3DWzJYnnsFan+0AoUZPv+k3zvmRPKWPOL/yf+sfdyl212bMzV/yASGgDs4juAiG8AUKVKWhAW2z61vRDguUjtABQ4pHYACjxP7QAU+NUer36dZTRdU8DbRFtT2EWiTynsMrERUNi7RFVT2FW0qUW0qPN9pKhFoqf91/ryZV//+Jvg7MPrc4lQVrscAArYlPP8BT16OA8=

snap@T17019938=1152x192+480.5+154.5,z2.jpg (17.72 KiB) Viewed 9048 times

I didn't find anything I'd want to unreservedly call a bug, I suspect constraining splitter output choices is going to always provoke tradeoffs.

[Jon8RFC]

I wonder if it's the same situation as my bug:
viewtopic.php?f=7&t=58001

[Mimos]

I think the new item-blind splitters make investigating this simpler than it would have been before, fiddling with output belt types and splitter priorities on this setup

blueprint

Code: Select all

0eNqtl2FvsyAQgP8Ln3HhbLXWv7IsjdXbRqJgAJc1jf99oEu7rF168L6fjILPnSc8p2d27CccjVSO1WcmW60sq5/PzMo31fThmjuNyGomHQ6MM9UM4Qw/R4PWZs40yo7auOyIvWMzZ1J1+MlqmDkZ0uumQ/Pj5nx+4QyVk07ims5ycjqoaTj6mTVcGFK9SuWHsvYdrfPsUVt/m1YhqkdlFWcnf4CFvs49WHROqjcb5hgc9AceJj/WOzTYHUKSfsiZCTlbr65JfIdstX8m7g9TKFohOBt0FwYal/XYLFlcqvAyh0L8Sj//qwS36ZdPxfUBOmmwXUc94rumenLjFEp/E2bz6HXdhtveD3YHvo2HF2R4EQ/fkOFlPDwnw3fxcCDDqxu4HXvp3L2VI1aqeCoec/cX7qNk6YUAEV0JeiEAouH09QF5NJy+bSB+U9K3DWzJYnnsFan+0AoUZPv+k3zvmRPKWPOL/yf+sfdyl212bMzV/yASGgDs4juAiG8AUKVKWhAW2z61vRDguUjtABQ4pHYACjxP7QAU+NUer36dZTRdU8DbRFtT2EWiTynsMrERUNi7RFVT2FW0qUW0qPN9pKhFoqf91/ryZV//+Jvg7MPrc4lQVrscAArYlPP8BT16OA8=

snap@T17019938=1152x192+480.5+154.5,z2.jpg

I didn't find anything I'd want to unreservedly call a bug, I suspect constraining splitter output choices is going to always provoke tradeoffs.

Thanks for your nice testing setup.

So you wouldn't call not taking items from the prioritized input despite there being enough a bug? At least your blueprint has no input priority set, but I guess you still tested it, right?

I also got interesting results based on timing. Sometimes the items were sorted perfectly without using any filter. But this probably is just a side effect of the priority working differently than I expect.

[quyxkh]

not taking items from the prioritized input despite there being enough

But consider what you're suggesting: that when two items arrive at the same time the splitter should ignore the lower-priority item even after delivering the high-priority item, even though the low-priority item's scheduled output lane is available. Yes, four or five ticks from now another item will arrive at the high-priority input, but that's a four or five tick gap in an output belt that's already incapable of meeting the demand.

To get absolute priority you can do a priority merge:

snap@T662566=1120x224-37.25-1.25,z2.jpg (18 KiB) Viewed 9000 times

which works because you're not asking any splitter to gratuitously decompress its outputs: the top merge can only place one item per lane per tick, and it always picks the high-priority one..

[Mimos]

in an output belt that's already incapable of meeting the demand.

I'm not 100% sure if we are talking about the same thing here. Both output belts can be filled to maximum compression from just the prioritized input belt (as long as it is also compressed). Which can actually be achieved by just removing the non priority input. So taking items from the non priority input is clearly not necessary.
Or are you just trying to explain what might be happening in the programming of the splitter to cause this issue?


What I'd like to have: Bot the setups in the screenshot below doing the same thing. But they don't: If both input belts are compressed, the bottom version just takes from the prioritized input, the top one takes from both.

not working vs working.PNG (84.49 KiB) Viewed 8976 times

Your setup sadly cannot do what I want to achieve: transfer items from both inputs to both outputs.

[quyxkh]

I'm not 100% sure if we are talking about the same thing here.

I'm talking about splitters that have to decide what to do with their inputs as they arrive, that only know what's at their input ports and what's at their output ports right now and have to decide what to do with it, right now, with no other information. What's going to show up at the splitter's input ports 3, 4, 5 or 9 ticks in the future is available to you at a glance and you can reason about it so easily. I don't think you really mean to be asking for splitters with foresight and reasoning, but you haven't explained how you can get the full behavior you want out of a single splitter in any other way. _You_ know the high-priority belt is compressed. The splitter doesn't. _You_ disconnect the low-priority input belt, and now the splitter, simpleminded creature that it its, puts the inputs it's got on the available output lanes in priority order exactly as requested, and the first high-priority input item comes out a few ticks later on one belt, then 4 or 5 ticks later the next one comes out on the other belt.

Start with empty output belts and slow the game down to 1/30 speed, you'll see that with both inputs connected and available the first decision the splitter makes the way you don't like is whether to deliver a low-priority output item or nothing. It's not until 4 or 5 ticks later that it's going to get the option to deliver a high-priority output item.

[Mimos]

Ok, you are talking about how it is currently implemented and why this is not working without looking ahead for items (which could even be removed by te player before arriving),

Consider this setup:

sync.png (65.57 KiB) Viewed 8858 times

When you enable both belts at exactly the same time, you can see that both output belts are compressed, although they cannot get their items at the same time. So the Splitter has to have some time/room to work with: one belt gets the items early and the other one gets the items a little later but there is no gap -> the splitter is able to move the items forward a little.

So there is one possible implementation which is working "backwards":

Case 1: both outputs full

• do nothing

Case 2: at least one output ready to receive an item

• select the output with the greater gap to the splitter
  Case 2.1: items available at the priority input
  • Put items from priority input to selected output
    restart at the beginning
  Case 2.2: no items available at the priority input
  • Case 2.2.1: one tick later items could still be moved to the output without creating a gap
    • wait one tick
      restart at the beginning
    Case 2.2.1: there would be a gap when moving item in the next tick
    • take item from non-priority input (if available)
      restart at the beginning

So this approach ist not looking ahead at the input and just looking for gaps at the output and moving the items a little which seems to be implemented already, althoug a little differently.

[quyxkh]

although they cannot get their items at the same time

That's a red-belt splitter, items inside it move at red-belt speed. 32 slots per segment, 9 slots per item, red belts move 2 slots per tick, yellow belts 1 per tick, so incoming items should be able to catch up 16 slots, almost two full items worth. Since the lanes are taking alternate items it should be able to catch up easily.

[golfmiketango]

Assuming the diagnosis advanced above and elsewhere about lack of splitter-memory, unbalanced belt speeds, items slots, timings and so on is right (and some other things), the undesirable outcomes portrayed in this thread and some others could be made great again as follows (without reverting any of the recent simplifications to the splitter firmware):

Code: Select all

Allow splitters, like inserters, to output a single hyper-compressed item onto each of its four output lane positions, and with like consequences for backed-up items upstream.

Namely: each hyper-compressed output lane is treated as output-blocked until the hyper-compressed item has enough room to de-hyper-compress into a normal slot on the belt (and to move forward by one additional belt-motion quantuum, if that's how it works for the new inserter-based hyper-compression?), at which point, the splitter may once again emit a new hyper-compressed item onto that lane, and so on.

Just plantin' seeds....

[kovarex]

So much text, and still I don't understand what is the bug.

[Bilka]

So much text, and still I don't understand what is the bug.

The original post shows a red splitter feeding two yellow belts. 1 red belt should be enough to feed both belts, but OP connected 2 and set the priority. Despite that, both belts are used. Expected is that only 1 belt is used.

[impetus maximus]

is my post with a save example invisible or something?

[kovarex]

is my post with a save example invisible or something?

It is not. Ok now i finally understood the problem.
I believe that I fixed it for the next version.

[impetus maximus]

It is not. Ok now i finally understood the problem.
I believe that I fixed it for the next version.

thank you sir.