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

This subforum contains all the issues which we already resolved.
Post Reply
Mimos
Long Handed Inserter
Long Handed Inserter
Posts: 71
Joined: Mon Nov 07, 2016 5:15 pm
Contact:

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

Post by Mimos » Tue Feb 20, 2018 11:18 pm

I noticed that input priority on splitters doesn't work if two outputs are connected.
GIF.gif
GIF.gif (454.08 KiB) Viewed 2904 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
Filter Inserter
Filter Inserter
Posts: 833
Joined: Wed Mar 29, 2017 2:10 am
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by Aeternus » Wed Feb 21, 2018 12:21 am

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.

User avatar
impetus maximus
Smart Inserter
Smart Inserter
Posts: 1299
Joined: Sat Aug 20, 2016 10:07 pm
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by impetus maximus » Wed Feb 21, 2018 2:34 am

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 42 times

PacifyerGrey
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Wed Jun 29, 2016 10:02 am
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by PacifyerGrey » Wed Feb 21, 2018 8:50 am

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
Filter Inserter
Filter Inserter
Posts: 716
Joined: Sun May 08, 2016 9:01 am
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by quyxkh » Wed Feb 21, 2018 2:22 pm

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
snap@T17019938=1152x192+480.5+154.5,z2.jpg
snap@T17019938=1152x192+480.5+154.5,z2.jpg (17.72 KiB) Viewed 2805 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.

User avatar
Jon8RFC
Filter Inserter
Filter Inserter
Posts: 365
Joined: Tue May 10, 2016 3:39 pm
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by Jon8RFC » Wed Feb 21, 2018 3:04 pm

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

Mimos
Long Handed Inserter
Long Handed Inserter
Posts: 71
Joined: Mon Nov 07, 2016 5:15 pm
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by Mimos » Wed Feb 21, 2018 3:31 pm

quyxkh wrote: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
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
Filter Inserter
Filter Inserter
Posts: 716
Joined: Sun May 08, 2016 9:01 am
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by quyxkh » Wed Feb 21, 2018 6:23 pm

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
snap@T662566=1120x224-37.25-1.25,z2.jpg (18 KiB) Viewed 2757 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
Long Handed Inserter
Long Handed Inserter
Posts: 71
Joined: Mon Nov 07, 2016 5:15 pm
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by Mimos » Wed Feb 21, 2018 9:23 pm

quyxkh wrote: 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
not working vs working.PNG (84.49 KiB) Viewed 2733 times
Your setup sadly cannot do what I want to achieve: transfer items from both inputs to both outputs.

quyxkh
Filter Inserter
Filter Inserter
Posts: 716
Joined: Sun May 08, 2016 9:01 am
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by quyxkh » Wed Feb 21, 2018 10:37 pm

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
Long Handed Inserter
Long Handed Inserter
Posts: 71
Joined: Mon Nov 07, 2016 5:15 pm
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by Mimos » Fri Feb 23, 2018 11:58 pm

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
sync.png (65.57 KiB) Viewed 2615 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
Filter Inserter
Filter Inserter
Posts: 716
Joined: Sun May 08, 2016 9:01 am
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by quyxkh » Sat Feb 24, 2018 1:19 am

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
Filter Inserter
Filter Inserter
Posts: 531
Joined: Fri Jan 29, 2016 2:48 am
Contact:

Re: [16.25] Splitter input priority not working with two outputs

Post by golfmiketango » Mon Feb 26, 2018 9:45 am

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.... :twisted:

kovarex
Factorio Staff
Factorio Staff
Posts: 7387
Joined: Wed Feb 06, 2013 12:00 am
Contact:

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

Post by kovarex » Fri Mar 02, 2018 2:33 pm

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

Bilka
Factorio Staff
Factorio Staff
Posts: 1958
Joined: Sat Aug 13, 2016 9:20 am
Contact:

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

Post by Bilka » Fri Mar 02, 2018 2:41 pm

kovarex wrote: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.
I'm an admin over at https://wiki.factorio.com. Feel free to contact me if there's anything wrong (or right) with it.

User avatar
impetus maximus
Smart Inserter
Smart Inserter
Posts: 1299
Joined: Sat Aug 20, 2016 10:07 pm
Contact:

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

Post by impetus maximus » Fri Mar 02, 2018 3:11 pm

is my post with a save example invisible or something? :|

kovarex
Factorio Staff
Factorio Staff
Posts: 7387
Joined: Wed Feb 06, 2013 12:00 am
Contact:

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

Post by kovarex » Sat Mar 10, 2018 8:23 pm

impetus maximus wrote: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.

User avatar
impetus maximus
Smart Inserter
Smart Inserter
Posts: 1299
Joined: Sat Aug 20, 2016 10:07 pm
Contact:

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

Post by impetus maximus » Sun Mar 11, 2018 12:04 am

kovarex wrote: It is not. Ok now i finally understood the problem.
I believe that I fixed it for the next version.
thank you sir. :)

Post Reply

Return to “Resolved Problems and Bugs”

Who is online

Users browsing this forum: No registered users