Page 1 of 1
Signal Filtering
Posted: Sat Nov 09, 2024 12:04 pm
by emphes
TL;DR
Add an option to filter a list of signals to only selected signals at original signal level.
What?
I would imagine the new selector combinator would match best thematically, with an extra option in the drop-down to filter signals. This would give you a filter selection box as evidenced in many places in the game already, and then the input signals could be white/blacklisted in exactly the same way. Given there are no physical items being handled, this would be an infinity expandable list like a logistics request.
It feels like the decider combinator almost has this functionality already, where you can set a list of requirements for a signal and process it for each. However, the 'EACH' output signal type is not available when specifying input signal types.
I see no way to restrict the type of signal without using a separate combinator for each. An alternate solution to the above would be to change the 'each' process, or add an 'EACH' operation to the 'OR' and 'AND' input operators.
Why?
Specifically when using the new space platform hubs or reading a logistics network you end up with large lists of signals to process. The selector combinator already adds the ability to work more effectively with these large signal sets, but I feel like the game is missing this important function.
Re: Signal Filtering
Posted: Sat Nov 09, 2024 1:15 pm
by Tinyboss

- 11-09-2024, 07-16-07.png (184.23 KiB) Viewed 3842 times
Re: Signal Filtering
Posted: Sat Nov 09, 2024 1:23 pm
by Tinyboss

- 11-09-2024, 07-23-56.png (168.41 KiB) Viewed 3840 times
Re: Signal Filtering
Posted: Sat Nov 16, 2024 3:56 pm
by DeathJunkie88
I wanted to chime in with an additional use case, based around bridging the logistics network to the circuit network:
Multipurpose assembler for low-volume items; e.g. a single assembler to make missing logistics chests, combinators, robots, etc. Right now, I use a constant combinator to set desired items, N arithmetic combinators (item + 0) to filter, then a selector combinator to choose the item with the least supply, feeding an assembler configured for "set recipe". This ends up not really saving that much space, due to all the arithmetic combinators. With a filter option in a selector combinator, this could be reduced to just 1 constant combinator and 2 selector combinators (filter, choose input) no matter the number of items to examine.
EDIT: Actually, I was able to find a solution to this problem using only 1 constant combinator and 1 arithmetic combinator. Since you can now choose which color wire is used on each side of an arithmetic expression, and there's an "each item" meta-signal, you can implement a whitelist filter mechanism as follows:
- Connect the constant combinator output to the green input of the arithmetic combinator
- Connect the unfiltered circuit (e.g. roboport) to the red input of the arithmetic combinator
- Set the constant combinator to output the signals you want, quantity 1
- Set the arithmetic combinator to expression <R:each item> <*> <G:each item> and output <each item>
- Now, the output of the arithmetic combinator will have only the desired signals
(I see now that this is likely what is being shown in the screenshots from Tinyboss)
Re: Signal Filtering
Posted: Sat Nov 16, 2024 5:13 pm
by DeathJunkie88
(edited out -- see Olacken's solution below my post, it's superior in every way)
Re: Signal Filtering
Posted: Thu Nov 28, 2024 3:42 pm
by Olacken
For the black list there is a simpler solution :
(In) (CC)
├──┐│
(DC)(AC)
├──┘
With the constant combinator having every item to black list set to -1,
the decider combinator being a pass through (ie: each ≠ 0 => each)
and the arithmetic combinator set to (each G * each R => each).
And it has the added benefit of synchronizing the outputs so there is no "undifined behavior" when the signal changes
Re: Signal Filtering
Posted: Sat Aug 09, 2025 6:49 pm
by Luye
Pardon me if i'm necroing, had the same problem as OP and didnt see an explicit solution anywhere. I took the concept of blacklisting above and turned it into whitelisting using the following connections (even simpler actually). By using only an AC for processing, with all with "each"*"each"="each", and then filtering to red signal on the AC.
(In) (CC)
├ │
(AC)
├
Even better: you can replace the CC component with one you might already have which is used for setting LP requests and filters for inserters, connecting it to an AC with "each"/"each" = "each" (turning any number into 1).
Re: Signal Filtering
Posted: Sat Aug 09, 2025 8:16 pm
by Tertius
Luye wrote: Sat Aug 09, 2025 6:49 pm
Pardon me if i'm necroing, had the same problem as OP and didnt see an explicit solution anywhere.
What's wrong with the 2 equivalent solutions in post #2 and #3 of this thread? They're exactly what the OP wanted, and if your problem is the same as the OP, then these posts are your solutions.
Re: Signal Filtering
Posted: Mon Aug 11, 2025 1:15 am
by Luye
Hmm maybe i misunderstood. I got the sense that the solutions posted where blacklisting, whereas I was after whitelisting. I.e. selecting the items i want to keep stock of, rather than selecting the items i don't want to track
Re: Signal Filtering
Posted: Mon Aug 11, 2025 3:09 pm
by Nidan
The combinators pictured in post 2 and 3 are whitelists: Output the values from the green wire if the signal is also present on the red wire. If you need a blacklist, that's also doable in a single decider combinator.
Each[red] == 0 and Each[green] != 0, output Each[green] input count