Factorio Forums

In the 0.15 circuit network poll there's a suggestion for a 'Selector' combinator supporting operations like 'MAX' and 'MIN'. Personally I think the ability to calculate maximum and minimum values would a great feature, but I'd like to propose a slightly different way of achieving it.

The way I see it operations like 'MAX' and 'MIN' shouldn't be seen as operations that 'select' a signal, but should rather be ways to reduce many signals into one. The reason this is important is that the game already supports such reduction operations. If you use the special 'Each' signal in the arithmetic combinator, but only output 1 signal then the result is the sum of all signals, and in the decider combinator using the special 'Everything' and 'Anything' signals is the same as performing the operations on 'Each' and then AND/OR-ing the results together.

Rather than making the game more complicated than it already is by adding more combinators it would be a lot neater to simply make these 'reduction' operations explicit. What I imagine this might look like is that when you select 'Each' and output anything other than 'Each', there will be some option to select how the signals are combined. Resulting in something like the following:



Well, obviously the UI could use some work, but the general idea is hopefully clear. The Decider combinator should have (at least) an 'AND' and 'OR' reduction operation, to replace the (odd) 'Anything' and 'Everything' signals, and also a 'COUNT'' and 'SUM' to replace the current behaviour when using the 'Each' signal. The Arithmetic combinator should have at least SUM, MAX and MIN operations.

The one minor problem I see is that in the decider combinator selecting 'output 1' or 'input count' don't really make sense when using 'COUNT' and 'SUM' to calculate a result, but compared to the current behaviour where selecting 'Input count' and '1' may or may not actually ouput the signals input count, or 1, it doesn't seem like a particularly big problem.

To be honest I like that more than the current signals with any-/everything "signals", which are too special in my eyes.

I agree that the current totaling functionality of the everything / anything settings is confusing and unintuitive and that summary functions are lacking but also required. First time I saw the totalling behaviour I said "WTF", and I only found it because I had not set up my conditions correctly.

I would still prefer the operation to be it's own combinator. It's an operation that really only applies to a group of signals and has little meaning when you are applying a decider combinator on a single signal and not outputting the value to another signal. Basically I am saying that there are too many invalid combinations of settings if you integrate it as in the OP. When you get into a situation like this you end up forcing the user to do an intermediate value "hop" to get the setting(s) they want to appear.

ssilk wrote:To be honest I like that more than the current signals with any-/everything "signals", which are too special in my eyes

It's not that the anything/everything signals are incorrect or invalid or anything like that, it's the special corner case of having an input of anything/everything/each and outputting it to a single value. You need to have anything/everything or else many current setups won't work. But when you are operating on a set of signals, you should output a set of signals and THEN apply your summary function. It would also mean that the behaviour will be more apparent to new players and easier to understand when looking at someone else's design.

Yeah I don't think the option should be available unless you select 'Each' and output only 1 signal, since that's the only situation where it applies. It would be pointless to show it in any other circumstance. The image is only a rough example to get the idea across.

I agree that applying a summary function afterwards is clearer, but unless you specifically forbid people from selecting 'Each' and outputting only 1 signal (which would break many current setups), you're going to have to reduce a bunch of signals into a single one anyway. So what I'm saying, instead of adding a special 'summary' operator for those summary operations that aren't avaiable yet, why not just allow people to choose which summary function they want to use?

As a a side effect this removes the need for the 'Anything' and 'Everything' inputs, which are basically 'Each'. but with different summary functions applied to it. If done well this would result in a nice uniform way to choose how to combine several signals into 1, rather than the several different ways that are currently available.

Shiandow wrote:As a a side effect this removes the need for the 'Anything' and 'Everything' inputs, which are basically 'Each'.

There is a large difference between "Each", "Everything" and "Anything".

Say you have the input signals {Copper = 10, Iron = 20, Coal = 5}
With a condition of "Each > 5" you get an output signal of {Copper = 10, Iron = 20}
With a condition of "Anything > 5" you get the output signal of {Copper = 10, Iron = 20, Coal = 5}
With a condition of "Everything > 5" you get an output signal of {}.

BenSeidel wrote:

Shiandow wrote:As a a side effect this removes the need for the 'Anything' and 'Everything' inputs, which are basically 'Each'.

<br style="text-align: justify;">There is a large difference between "Each", "Everything" and "Anything".<br style="text-align: justify;"><br style="text-align: justify;">Say you have the input signals {Copper = 10, Iron = 20, Coal = 5}<br style="text-align: justify;">With a condition of "Each > 5" you get an output signal of {Copper = 10, Iron = 20}<br style="text-align: justify;">With a condition of "Anything > 5" you get the output signal of {Copper = 10, Iron = 20, Coal = 5}<br style="text-align: justify;">With a condition of "Everything > 5" you get an output signal of {}.

You can't just ignore the part where I say 'but with different summary functions applied to it.'. Implicitly Anything and Everything still look at each input, they just summarize the result differently. Depending on which output signal you choose Each may choose to summarize the result by giving the number of inputs where the condition is true, the sum of the inputs where the condition is true, or just the inputs where the condition is true.

If you could choose how 'Each' summarizes it's result you wouldn't need the special 'Anything' and 'Everything' signals.

Somehow I still like the Each/Anything/Everything concept more. Seems so much more straight forward for me than the approach you are suggesting, Shiandow. But I guess that's a matter of taste.

Shiandow wrote:If you could choose how 'Each' summarizes it's result you wouldn't need the special 'Anything' and 'Everything' signals.

You are right, you would not NEED the Anything and Everything signals.

But just so I am clear what you intend to introduce to the game by removing them, lets try to build the equivalent functionality with only your modified "Each" -> "Summarise" system.
The first step is to do a count of the output signal of the initial combinator with your each comparison, giving you the count of the number of signals that meet the condition.
Then if you want "Anything" have another combinator whose condition is "count signal > 0".
If you want "Everything" have another combinator count all the original input signals and compare the two counts, ensuring they are equal.
In both cases you can reduce the output to a true/false, so you output that value on say green.

You then combine the original input signals and the new green signal value and output everything if green == true (whatever value you choose as your truth). Now of course you need to remove the green value from your output signals so you put in an arithmetic combinator to negate the value of the green and merge the two signals.

But that is not enough. You will get a green value leakage for one tick, so you need to put in a second combinator in parallel with the negation combinator to delay the input signal one tick.

Is this the system you are proposing?

BenSeidel wrote:

Shiandow wrote:If you could choose how 'Each' summarizes it's result you wouldn't need the special 'Anything' and 'Everything' signals.

You are right, you would not NEED the Anything and Everything signals.

But just so I am clear what you intend to introduce to the game by removing them, lets try to build the equivalent functionality with only your modified "Each" -> "Summarise" system.
The first step is to do a count...

From what I understand, you would use AND, OR reduction instead.

EACH input with AND reduction is equivalent to EVERYTHING as input. First the condition is checked for EACH input. Then the true/false result of the condition is AND'd together. The result of that is then used to control output.

EACH with OR reduction is equivalent to ANYTHING.

One thing that does seem to be missing is a way to output EVERYTHING with either EVERYTHING/ANYTHING as input. Those could be mapped as EACH as input and output with AND or OR reduction. But then a NO REDUCTION option would also be necessary, which would work as EACH -> EACH does currently.

Ok, firstly "And" and "Or" are binary operations acting on boolean values, while "Count" and "Total" are summary functions acting upon all the values of the signals. The main difference here is the question of what occurs when you "Or" the empty set? or a set with one signal. Is "True" or "Null" => True? The current system of "Everything" and "Anything" is more intuitive because it's mathematically correct, your "And" and "Or" is not (unless you program in C).

Yoyobuae wrote:One thing that does seem to be missing is a way to output EVERYTHING with either EVERYTHING/ANYTHING as input.

That is my point. It does not matter the method that you use to get to the answer of "is everything" or "is anything", its the behaviour of the OUTPUTS. There is a functional difference in the OUTPUTS of "Each" vs "Everything" and "Anything" when the output is not a single signal.

So again, my question is, How do you replicate the current behaviour of "Everything" and "Anything" vs "Each"? without having an "Everything" as an output?

Additionally, what are you gaining by removing the "Anything" and "Everything" as inputs? You still need the anything or everything to really get a benefit out of your new interface, otherwise you would need to have two combinators, one to determine if any or all signals meet the condition (using your "And" and "Or"), then one to perform your intended summarisation as in your description you can't "or" them then "total" them in the one combinator. If you are going to require two combinators you should really just have another "summarisation" combinator for the increased clarity of complex designs.

I love the idea, I just think that the removal of "Anything" and "Everything" is unintuitive, confusing and detrimental to the game in general.