TL;DR
Enable the selector combinator to select several signals by enabling it to use multiple indices..
What ?
The selector combinator should receive a couple new options.1. You should be able to choose which wire(s) gets considered for index, and separately, which wire(s) should be selected from (like in the reworked decider combinator GUI).
2. You should be able to choose, what signal will be output. Similar to the other combinators, where you can choose to to output any specific signal, or "Each".
3. You should be able to choose "Each" as the index.
. (crude GUI concept to show the idea)
If index and output are both set to "Each": the selector combinator should look at each signal on the wire(s) chosen as index and, for each of them, select a signal of the wire(s) chosen as the array. For each index signal, take the value of the selected signal, and output it with the signal of the index. The signals that are output should not be the ones of the array, since they would just add up in the output, if the signals were selected more then once.
For example, red wire is the index selecting from the green wire: .
Additionally, setting the output to "Each" for "Stack size" could return the stack sizes of each of the different items in a chest.
Why ?
It is currently impossible to have the selector combinator output more then a single signal. That is fine for small builds with a consistent number of selections, but very restrictive for larger or more complex builds.In preparation for the upcoming changes to lamps and the introduction of the selector combinator I have been busy designing a full color display that works with GIFs. For every pixel I need to select a value from an array of up to 256 colors. I stopped building on that project when my creative world started lagging, despite only having a comparatively tiny 32 by 40 pixels display.
Currently, if you wanted to select 100 different values from the same array, you would need at least 100 selector combinators, one for every index.
Since the index signal may interfere with the values or the order of the array, you may need another arithmetic combinator, for every selector combinator, doubling the number of parts required.
Additionally, since you may need to output the selected value as a specific signal, so that they can be combined on the same wire again or to be read by the correct lamp, you will need another combinator for every index. So now its 3 combinators, per pixel.
Finally, this build would only work with a static number of inputs, and if all inputs use the same signals. Anything more complex would be even more bulky and require lengthy signal swapping.
. (Here the index was carefully seperated from the color array to "only" have to build 2 combinators per pixel.)
You have to set thousands of combinator options by hand, even if all they do is change one signal to another.
. .
This would be a hassle to build, extremly big and laggy.
It would be much better if the selector combinator would instead do multiple selections and simplify this problem down to a single combinator. This is also the only reasonable way I could see it to work with inconsistent array lengths and inconsistent signals.