Wire color based signal input selector (for virtual signals)

[phi1010]

And another small suggestion not yet in Circuit network features for 0.14:

Backstory:
Situation: I have a (mod-provided) warehouse, behaving like a chest with many many items. I'd like to use grabbers to remove excess items, using more than x slots. Currently I calculate "EACH - 40k if > 0, else 0", and providing that as filter condition to the inserters. Since some items have different stack sizes, this doesn't work very well, because (in the worst-case-scenario) blueprints might use every single slot. Because of that, I have to define a number of items per item type by hand somewhere.

Current Solution: Place an arithmetic combinator for every single signal type, and subtract the specific fixed value. I don't like this, because it's very time-consuming to reconfigure those combinators, and difficult to find them again, as they currently do not have an item type overlay. Alternativly, I can use the implicit each-addition by adding green values to red values previously multiplied with -1. This won't work anymore, when I want to switch to other logic, like multiplication etc.

Specific suggestion:
Add EACH_RED and EACH_GREEN next to the virtual EACH-Signal, and do the same for EVERY and ANY ("if ANY_RED > 0, pass EVERY_GREEN to the output"). This would allow me to use a constant combinator on the green wire, and define the maximum item count there; then calculating "EACH_RED - EACH_GREEN" in one arithmetic combinator instead of "EACH - FIXED_NUMBER" in many, many arithmetic combinators.
The color selection would only be necessary for "EACH/ANY/EVERY"-Signals; but would triple the amount of virtual signals, not necessarily the best idea if there already are many many items from mods in the list.

Generalized Suggestion:
The current behaviour of implicitly adding the red and the green signal values is useful to build fast and small circuits. When handling many signals, it would be easier to be able to select "red only" or "green only" for input values (and in comparing combinators for the output values taken from corresponding input values) instead of the default "red+green" for every type of signal, removing the need of renaming signals to different names by using "newtype = oldtype+0" (or "newtype = oldtype*1", etc.) as diodes. (Output signal types would stay the same; passing the output value to all wire colors -- why should i connect a <anycolor> wire, if I don't want the output signal on it?)

[terror_gnom]

I did suggested the same thing, but was totaly ignored

[MeduSalem]

I also pointed out multiple times that automatically adding the contents of red/green wire before inputting them to an item/combinator is problematic in many cases... and that I wish for the pre-0.12 behaviour to return where there were seperate conditions for each wire color... and rather have a specific option/item to add up the contents of both wires... and maybe even have AND/OR conjunction between the seperate red and green wire conditions and the logistic network condition.

But well... I guess it is one of the things we probably won't get because the popular demand is not there.

[ssilk]

Sorry to be off-topic.

I did suggested the same thing, but was totaly ignored

Normally I would ignore such posts, but this is the second time you made such a comment. The first
viewtopic.php?f=6&t=25272&p=159155#p159155
looks quite similar.

My idea of my job as a moderator in the suggestions board is, that nobody should be ignored.

So I did make a search about your posts in suggestions and I didn't find them. So maybe you posted it not in Suggestions? Maybe in News? Cause that would explain it.

Would be useful to reply with the link(s) to the posts you mean.

[phi1010]

Some other thought on this after playing a bit with circuits trying to compact and speed up calculations: Finding out the value of a single signal, where the type of the signal is chosen by another signal would be much easier, if one could just multiply all signal values with their corresponding selector values, instead of building a combinator each for every type of signal. Since that would be either a "<value signal> if <control signal> = 1 else 0", or a <value signal> * <control signal>, I don't see a way to get that done by using the implicit addition without implementing really slow counting loops, similar to how a pinwheel calculator works.