[0.16.20] Output priority not working

[ziggyHH]

This is my first post in the forum, so I am not sure if this is the right place to report a bug.
In my test base the output priority of the splitter does not work correctly.

[Kayanor]

Moved from release thread to Bug Reports.
Seeing your setup, the output priority is working as intended, items are moved to the priortized lane first before being moved to the other side.

NaB

[boskid]

Well, why NaB? This is rather interesting case.

There are three blue belts that are 1/3 full (feed by yellow belts) on the right. By using priority spliter, they should merge directly into one blue belt, so two output belts from right should be empty. First from right is empty, but second one is not and this can be called a bug (but is probably caused by items timing causing spliters to think that on one tick there are two full belts so to skip priority rule, and on other tick there are two empty belts).

Case that second belt from left is not full is easy to explain, as belt going from fourth to fifth spliter has throughput of one blue belt instead of required 1+2/3 of blue belt for it to work as intended.

-- edit:
after some time i thought there is explanation for this related to priority output of second spliter being blocked on input of third spliter, but then third spliter should place excess stuff on third right output line not allowing its left input (priority belt from second spliter) to become blocked. So +1 for NOT marking it as NaB

[pleegwat]

I think the splitter has input from both sides synced, so it first outputs to the priority side, then items also come in on the other input belt and it puts it on the non-priority output side, since the priority output side is already outputting.

[ziggyHH]

A slightly different scenario:

2 groups of 3 yellow belts should (each) compress a blue belt. The left group works as expected, the right one does not. This is against my intuition. If this behavior is not corrected then splitter output priority becomes pretty much useless to compress belts.

A sad FACTORIO lover who has spent >1800 hours in your fantastic game...

[Jap2.0]

A slightly different scenario:

2 groups of 3 yellow belts should (each) compress a blue belt. The left group works as expected, the right one does not. This is against my intuition. If this behavior is not corrected then splitter output priority becomes pretty much useless to compress belts.

A sad FACTORIO lover who has spent >1800 hours in your fantastic game...

It appears that the items on the left belts are offset while the ones on the right are not. I'm not sure wheter that's still quite as intended, though.

[Davosaurus]

I have also been having this issue [0.16.22]. If two exactly half-compressed belts are merged into a priority output, it combines them into one fully compressed with no overflow, as expected. But if there is more than half-compression on each input belt, the priority output is not filled and some items get output to the overflow line. I can understand why this happens; my hypothesis is that splitters are confused when presented with items that are given at the same time from different input belts. However, I would like to know whether this is intended (I hope not) and if it is supposed to function as one would expect: priority output gets filled up to 100% compression, then if there is more input (or if priority output is backed up), the other output belt is used.

Image for clarity:

[quyxkh]

Priority splitters aren't buffers don't buffer more than one item per lane.. If presented with inputs from both belts when their output's already busy, they'll deliver to both outputs -- even if that means they'll have to then leave a gap on their priority output later.

The dwiw priority splitter in 16.16+ is a little easier than it was before that (and I think the priority options are needed to make a dwiw belt-stuffing merge practical) but you still need to provide a buffer to hold items ready for the next gap and enough of them to fill it:

16.16+ belt-stuffing merge

snap@T33098=704x240-4.25-7.5,z2.jpg (16 KiB) Viewed 2569 times