Filter inserters priority list -> Provide a way to prioitize filters

[Aricitic]

TL;DR

Title above, but just in case: the filters on inserters should have a "priority list" OR Provide a way to prioritize filters.

What?

The filter slots should be a priority list - or please provide another means to prioritize filtered items (without a chain of combinators).

Why?

Prioritizing spoilage exists. This was necessary for obvious reasons. But the filter slots, of which we have five, don't provide any means to say: "If this item exists, pick it up first."

If I'm burning nuclear/rocket fuel OR solid fuel OR coal OR carbon I *may* wish to prioritize one over the other. Yes, this is able to be done via combinators, but not every location has unlimited space to use multiple combinators.

A toggle or simply having it on by default if "whitelist" is selected (and off if blacklist is) would resolve this issue. 'sides, if an inserter is smart enough to determine how close an arbitrary item is to "spoiled" then it should be smart enough to do this, right?

I know this is similar to the thread: 113399 but I'm not asking about circuits (because this is already possible).


Post-Script: If more information is requested I'll happily provide it, but I feel the idea is simple enough that the above fully describes it?

[Muche]

As I see it, this topic and 113399 are connected.

This topic being the more foundational (order of filters affects the order the inserter picks items), whereas that one builds on top of this one (signal value determines the order of filters, thus the order the inserter picks items).

[Aricitic]

As I see it, this topic and 113399 are connected.

This topic being the more foundational (order of filters affects the order the inserter picks items), whereas that one builds on top of this one (signal value determines the order of filters, thus the order the inserter picks items).

I mean, yes... and no.

Certainly, I see how you see them as connected, and in a sense they are. If they need to be merged, then, fair enough. But "signal value" doesn't determine the order of appearance (the actual order of appearance does for signals - unless I'm missing something). So, if "both" were to be implemented based on concept, the other would require the order of the signals to be reordered based on the signal's differing values... Or to completely disregard my suggestion.
... .... (Ok, I DID say "or provide a way" so, I guess I'm wrong on that count)



Basically I see it this way:
-- My request:
---> (pseudocode) If <first slot> item exists then pick up <first slot> item; else if <second slot> item exists then pick up <second slot> item; (etc)

-- Their request:
---> (pseudocode) If <signal value> is greater than <second signal value> AND <signal> is an item pick up signal item; else if <second signal value> is greater than <third signal value> and <signal> is an item pick up signal item; (etc)

My request is a simple boolean check, while the other (which I DO like) is a comparator, and then a boolean check. Additionally, my request simply requires the "filter" button to be checked and filters to be active. Their request requires a circuit, and the "set filter's" button to be checked.

So, I guess, what I'm getting at is "levels of complexity"? Maybe... I dunno. I'm still a bit ill from yesterday.


EDIT:
Ok, I thought of another way to compare them.

My idea is as follows: Two+ belts with Three+ inserters -> First* inserter is filtered to <item A> and Second* inserter is filtered to <item B> -> the belt has two different items on it, one for each lane -> As the items reach the First* inserter <Item A> is picked up; as they reach Second* <Item B> is picked up -> both inserters place on the second belt such that <item A> blocks <Item B> until <Item A> runs out. Third Inserter inserts into the desired location.
However, scratch all the above and make it just one inserter with one belt and one item per lane. If the first filter is <Item A> then, so long as <Item A> can be picked up, do so. Otherwise pickup <Item B>.

*(by way of belt's motion)

Honestly, I *DO* like the other idea, but I see it as potentially more complex to implement.