Page 1 of 1

Splitter "input priority" is not intuitive

Posted: Sat Jan 27, 2018 2:00 am
by TsBandit
TL;DR
In the 0.16.20 update, the Factorio developers fixed some of the problems with priority splitter throughput, but some problems still remain.

(I suspect that the "input priority" feature is working as intended, which is why I posted this as a Suggestion instead of a Bug Report.)
What ?
I want to be able to build this 5-to-6-belt splitter:
Desired 5 to 6 belt splitter
Desired 5 to 6 belt splitter
factorio_bug.png (141.6 KiB) Viewed 11787 times
Unfortunately, this still doesn't work because of some problems with the "input priority" feature.

To see the problem, let's look at a small example. In the example below, the top belt should not have iron plates leaking onto it:
Picture of undesired behavior
Picture of undesired behavior
factorio_bug.gif (2.28 MiB) Viewed 11787 times
bug_3_1.zip
Save file demonstrating the behavior
(823.69 KiB) Downloaded 123 times
The misbehaving splitter is the splitter on the right. It is receiving two blue belts of input (one iron and one copper). The iron input is prioritized using the "input priority feature". It has two outputs: one blue belt and one YELLOW belt, and therefore it should be that all of the iron plates pass through the splitter. (The yellow belt is just simulating some part of my factory that demands less than a full blue belt of materials.)

However, sometimes the iron fails to pass through the splitter, causing the iron plates to "back up", i.e. they don't have full throughput. To make this more obvious, I have included the splitter on the left (this splitter is working properly :) ). If the iron plates were not backing up, then there would be no leakage onto the top-most belt.
Why ?
I want to use this input priority feature to simplify my main bus. I want to be able to take 5 belts (or however many) of materials and use belts to distribute them among 6 consumers (or however many) without using crazy complicated balancers. The new priority splitters should enable me to do that, but so far, it seems like they don't.

Re: Splitter "input priority" is not intuitive

Posted: Sat Jan 27, 2018 2:44 am
by cyjackx
With the 5 to 6 setup you first describe, I do not understand how you expect anything to come out on the bottom 6th belt. With all the output priorities set as such, shouldn't it be impossible to fill the last belt? All 5 inputs will go to the top 5 outputs.

Re: Splitter "input priority" is not intuitive

Posted: Sat Jan 27, 2018 2:52 am
by TsBandit
Some of the output belts may start to back up, in which case I hope that the excess will flow to the 6th belt.

Re: Splitter "input priority" is not intuitive

Posted: Sat Jan 27, 2018 3:22 am
by pleauser
does this manifest if you use red not yellow belts? and again if you use blue?

Re: Splitter "input priority" is not intuitive

Posted: Sat Jan 27, 2018 3:41 am
by impetus maximus
the priority splitting is new. i don't think it's working as intended.

Image
in the image above (taken from here) the first splitter is suppose to spill over to the upper belt when backed up.
it doesn't do that. furthermore the third splitter from the left (input priority left, output priority right) is suppose to push items back to the filter line.
items seem to pass though rather than halting the filter line.

as i said, they are new. i'm sure they will get improved.

Re: Splitter "input priority" is not intuitive

Posted: Mon Jan 29, 2018 6:14 am
by TsBandit
The same thing can happen when using red belt instead of yellow belt.

I don't think it will happen when using blue belt instead of yellow belt; however, if the belt starts to back up because the downstream machines cannot consume a full blue belt of materials, then this problem will happen. This is the case I'm most worried about, actually.

Re: Splitter "input priority" is not intuitive

Posted: Mon Jan 29, 2018 3:20 pm
by Ram
I think this is a bug, I am glad someone noticed it too. I sometimes have belt backing up slightly (stuttering) even when both outputs are not full.

Re: Splitter "input priority" is not intuitive

Posted: Mon Jan 29, 2018 3:34 pm
by impetus maximus
Kovarex found some issues with priority splitters which are will be fixed in 0.16.21

Re: Splitter "input priority" is not intuitive

Posted: Mon Jan 29, 2018 4:12 pm
by Tekky
impetus maximus wrote:Kovarex found some issues with priority splitters which are will be fixed in 0.16.21
Corresponding bug report threads:
viewtopic.php?f=30&t=56924 [kovarex] [0.16.17] Priority splitter can stop unblocked lane
viewtopic.php?f=30&t=56968 [kovarex] [0.16.17] Prioirty splitters backing up belts

Re: Splitter "input priority" is not intuitive

Posted: Tue Jan 30, 2018 9:16 am
by bobingabout
TsBandit wrote:Image
Shouldn't both of those lower outputs be a mix of iron and copper, rather than each being about 99% of one or the other?

Re: Splitter "input priority" is not intuitive

Posted: Tue Jan 30, 2018 12:21 pm
by mrvn
bobingabout wrote:
TsBandit wrote:Image
Shouldn't both of those lower outputs be a mix of iron and copper, rather than each being about 99% of one or the other?
Actually I would expect the yellow belt to be all iron plates. The blue belt of iron plates is a priority input. So they should be split to the two outputs before any copper is consumed. And the bottom belt is yellow. Only 1/3 blue belt saturates it and 2/3 blue belt of iron ore should go to the top output with 1/3 copper ore mixed in.

Re: Splitter "input priority" is not intuitive

Posted: Fri Feb 02, 2018 7:47 pm
by TheOnefinn
This still seems off on 0.16.22

Image

layout is pairs of identical setups, side by side, the ones on the left have the left lane limited, middle is both lane, the ones on the right the right lane limited, top row is limited by red, bottom row is limited by yellow.

Note that you can often change the output pattern by removing and remaking a belt, although one belt yellow always seems to work consistently, if not as I expected.

Youtube
blueprint