Factorio Forums

did a quick search, didn't find it, so question:
is this behavior intended?

- set priority to left lane
- set filter
- one would expect the items to go through when the right lane is saturated?!?

There is no info on hover, or otherwise on how the filter will behave in the GUI.
If this is intended then " PRIORITY " might not be the best description.

so either filter or gui bug

That’s intended behavior. The “priority” in the option name might be a misnomer in this case, though.

I think "filter" means _all_ of that item goes to that lane. "Priority" only applies when the splitter's given a choice. That makes what you want to do take three splitters (one to filter, one to priority-split, one to merge back) but I think it makes real filter splitters possible, where none of the filtered item is put on the other output.

It is working as intended, but I'll assign this to kovarex, so he knows the gui is confusing and generates bug reports.
If you set filter, the filtered item will ever be sent to output priority lane and every other item to the other lane.

Thanks!

Just out of curiosity, what is the reasoning for not letting filtered items through when the other belt is saturated?
It kind-off creates the belt equivalent of a train gridlock when you don't have enough waiting bays.

I mean, now I need to make these kind of contraptions to semi prevent it:

If it let filtered items through when backed up it would be much harder to make sorters.

Splitters are consistent with any other way of filtering.
Letting items overflow through the unfiltered side would render it useless for filtering.

Your Contraption will also lock down once the inner belts are filled up. Set the inflow belt to only work while the circular belts have free space.

Have a better usage: Your contraption is exactly the same as the upper one of these two if the the input belt has more than two types of items, and equivalent to the lower one if the input belt has only two types of items. As it blocks once one of the output belts is full.

And as others already said, if the filter leaked onto the other side it would be useless. I kinda like the simplicity of the current GUI. And yea, using the word "filter" to mean "exclusive" is consistent. Maybe the other lane should just show something like "everything else".

the "contraption" was just an example, if you have multiple items on a belt (say 5 for argument sake) and a filter splitter set, a full priority belt will stop everything downstream.
This has major implications and current GUI does not hint at it at all. I like it simple, but it should be correct and clear what the options are.

If it leaked on the not priority lane it would not be useless, you have defined an OUTPUT filter for the priority lane, if it leaked on the not priority lane it would still do what you set it to do. (filter prio output lane). But apparently you also set a not priority filter in the process. (all but --)
Even the graphics show a filter on the prio lane and nothing on the other, suggesting all will go through on that side

You can still create your filters with a feedbackloop if it leaked.

It felt so unnatural to me that I instantly lost the urge to play with it...

Optera wrote:Splitters are consistent with any other way of filtering.

example? if you use filter inserters, to take items from a belt the "filtered" item will go through if your output is full, exactly as I'd expect these splitters to work.

I was also kind of surprised to find out that this is not a researchable tech but all splitters have these options.

I would love to read your thoughts Kovarex

I just noticed this behaviour too.

In my case I'd like a slightly different behaviour as an option, what I'd like is the priority output for one resource to be in one direction, and the priority output for the other to be the opposite.

My reason is I''m trying to build a "robust" bus design, as in one that is more readily expandable by just sticking some blue prints down for more lane and they'd automatically sort themselves out.

This is my current tests, it looks impressive but it needs quite careful fine tuning as to the "depth" of the green chip filters, if green chips start going into the back of one of the filter splitters then it all starts backing up.

For me this is new functionality, but IMO a filter splitter that doesnt have a single belt throughput limitation would have far more possibilities I'd like to play with.

TheOnefinn wrote:In my case I'd like a slightly different behaviour as an option, what I'd like is the priority output for one resource to be in one direction, and the priority output for the other to be the opposite.

For an input that has exactly two different kinds of items this is exactly how it already behaves though. And a spliter only has two outputs, so more than two item types wouldn't work. So how is that different? Your screenshot doesn't seem to show anything new.

eradicator wrote:

TheOnefinn wrote:In my case I'd like a slightly different behaviour as an option, what I'd like is the priority output for one resource to be in one direction, and the priority output for the other to be the opposite.

For an input that has exactly two different kinds of items this is exactly how it already behaves though. And a spliter only has two outputs, so more than two item types wouldn't work. So how is that different? Your screenshot doesn't seem to show anything new.

The current splitter is throughout limited To a maximum 40/s for any single item type, if you feed it more than one belts worth of a single resource type it jams up. What I’d like is a filter that doesn’t have that limitation, if you give it 2 belts of the same type and it can’t output that to one belt it uses 2, it doesn’t jam up.

To put it another way, currently a filter splitters maximum throughput requires a 50% mix on items 1:1 on sorted to non sorted, I’d like a splitter whose throughput is always 80 items/s, even if given all one type, maintaining throughput is more important than keeping the output belts exclusive.

The point of my screenshot is to show the use case. Currently filters can only be used to filter up to one belt of output at a time and they provide a 100% guarantee that all of that input in either input stream goes to the filtered out, however that’s not what I need for my use case, I don’t actually care if any of the green chip filters leak, so long as the overall trend is to filter green chips down and steel plates Up then that is good enough for my use case, what’s more important is that max throughout for any resource type remains 2 belts so that it doesn’t jam up when given more than 40 chips/s.

I've attached a screenshot showing what I'd expect the outputs to be for the given inputs for a splitter set to prioritise copper right, although this design can fail in practice due to different latencies between the copper and iron lanes, something that shouldnt affect an in built splitter.

Yes, it was obviously always intended, that the filter is blocking, it would be borderline useless otherwise.
We have a plan how to make it more understandable in the gui update.

Thanks! Looking forward to GUI changes