default circuit network signal (max or sum) makes the concept easier to pickup, more resiliant, and a new poweruser tool

[osndok]

I've been musing on how I see people use circuit networks:
1. They are usually point to point
2. They have to manually select the target value, even though there is "logically only one"
3. They often select the wrong signal (like 'oil barrells' or 'heavy oil' instead of 'crude oil', or the wrong type of barrelled fluid)
4. Having the wrong signal configured for listening is often the cause for breakage (e.g. copy-paste-modify one forgets to reconfigure signal specs)

I think we can add one small feature that would make this a better user experience, and I don't think it would be much work or risk breakage.

Idea:
1. When computing circuit network values, add a 'sum' or 'max' signal (or both); where 'sum' would be the numerical addition of all signals on the wire, and/or 'max' would simply be the numeric value of the strongest signal.
2. When initially forming a wire connection, have that signal (sum-or-max) be the default, pre-selected, filter.

In this way, I imagine that:
1. Beginners don't have to worry about picking the right signal ("it just works" until they need advanced/combined signals), they only need to select the value, decreasing the initial learning curve & complexity, and increasing fun.
2. Copypasta of common setups (like "limit this chest to N items") are safer by default, since it does not matter *what* is in the chest/barrell/fluid-tank, just the quantity.
3. For non-beginners, this extra "wildcard" signal might eliminate several combinators in complex circuits (and the frustration/debugging-time therewith)

[ssilk]

Generally having a sum or max is A good idea. But I have strong feelings about making something like that the default. They belong from “useless cpu usage” over “what if you forget to change the default?” to “what if the max signal works under one condition, but not in the other? Wouldn’t beginners be much more irritated than yet?”.

And couldn’t that also be achieved by the “anything” signal? And isn’t that their fault if they forget to change signals?

[BaggyK]

And couldn’t that also be achieved by the “anything” signal? And isn’t that their fault if they forget to change signals?

If I recall correctly, using anything breaks if the chest is ever empty. I think the logic goes as zero is no signal, the condition "anything < X" returns false if there is no signals. You could use a constant combinator to offset the value, but that is an extra building, and somewhere else you have to set the correct signal.

Being able to filter the signals when setting a signal on a combinator to only show the signal that are currently on connected network would be very nice.

[Sopel]

I like the idea, but I would modify it slightly. There is no need for the max/sum signal to be always calculated. They could work just like "anything" or "everything" works now - we already have 2 aggregating signals, why not have more?. Max/min/sum/average could all be useful and they are hard to make using existing combinator infrastracture in a generic way.

[ssilk]

Don’t you think the devs had no reason against implementation of such A more or less iterating functions?
Once you feed the roboport output into such a combinator this will really eat CPU. The calculation is not longer O(N), but more like O(N²).

[Ajedi32]

And couldn’t that also be achieved by the “anything” signal? And isn’t that their fault if they forget to change signals?

If I recall correctly, using anything breaks if the chest is ever empty. I think the logic goes as zero is no signal, the condition "anything < X" returns false if there is no signals. You could use a constant combinator to offset the value, but that is an extra building, and somewhere else you have to set the correct signal.

Being able to filter the signals when setting a signal on a combinator to only show the signal that are currently on connected network would be very nice.

So maybe chose "everything" as the default instead? Though I guess that has the opposite problem of returning false if no signals are present.

Ideally there would be a way to distinguish "0" from "no signal", but I can think of a lot of situations where there's not really a meaningful distinction between the two. (Like the example you gave of measuring the contents of a chest.)

Maybe it'd be best to introduce a new signal: "Something" which is like "Anything" but gets treated as 0 for the purpose of conditionals when no signals are present, rather than just being always false. That'd be a pretty intuitive default for most people I suspect.

[Ajedi32]

Don’t you think the devs had no reason against implementation of such A more or less iterating functions?
Once you feed the roboport output into such a combinator this will really eat CPU. The calculation is not longer O(N), but more like O(N²).

I can't imagine what kind of bizarro min/max/sum/average algorithms would require O(N²) to compute. Besides, you can already do sum using the "Each" option with a combinator. Most likely the devs just never thought of any good use-cases for other set operations.

[ssilk]

Sorry, mixed it up. I did mean O(1) vs something more like O(N) . You can do some optimizations to avoid those calculations - of course. But you cannot always optimize, and the effort for optimization is very high.