[1.1.104] Decider combinator Output input count uses wrong value on Each

[ChakatStormCloud]

Using output "input count" has a completely different behaviour with "Each" than it with any other input setting, making it behave more like an arithmetic combinator.
Specifically when used like this:

image_2024-03-29_003234391.png (23.25 KiB) Viewed 1369 times

while every other setting treats [A] as the value to output if true:

image_2024-03-29_005830810.png (194.03 KiB) Viewed 1369 times

But on each, it completely ignores the value of [A]:

image_2024-03-29_003040126.png (204.41 KiB) Viewed 1369 times

and act's more like an arithmetic combinator, converting the signal to [A] and adding it up.

I would expect Each to always function the exact same as if you had a combinator set for each signal in the wire.
like these should be equivalent:

image_2024-03-29_010815834.png (385.86 KiB) Viewed 1369 times

[boskid]

Most of the stuff you mentioned makes a lot of sense, however i am not sure i am willing to change current behavior.

Current behavior is kind of a mash-up of something that can be implemented explicitly using 2 combinators: first doing [each]>0, output [each] (input count), and second combinator converting [each] into signal-A, however your proposed solution is also something that can be done in game explicitly using 2 combinators: first doing [each]>0, output signal-X(value 1) and second signal-X times signal-A output signal-A.

Using the logic that [each] can be used to substitute a set of N decider combinators where each of them has different signal substituted by [each] makes sense, however for me it fails one important usability aspect: when input signal substitute is the same as output signal then the decider combinator no longer becomes a "select signal conditionally based on different signal" but it turns into "select this signal based on condition" so it makes handling of the signals bundle slightly inconsistent. To fix this when [each] is involved on the input side, non special output signal would have to be excluded from the [each] bundle. Your logic basically means that the correct behavior would be "take value of signal-A and multiply it by amount of signals that passes the condition" however that is annoying because value of signal-A is also being evaluated by the decider combinator in such case. Excluding non special output signals is not something i am willing to add here because of the decider combinators implementation for 2.0 where there will be possible to have multiple output signals.

[Tertius]

The implicit add/multiply of the current 1.1 decider combinator is not very useful with the case in the OP (output=input count), but it's very useful with using output=1, because this way it counts the number of matching signals. This can be used to check an AND combination between an arbitrary number of signals. For example you know you feed 5 signals and require all of them > 10, so in your decider you set EACH > 10 and output C=1. If C=5, you know all signals match the condition. And all this with only 1 combinator and one additional entity that evaluates condition C=5.

According to FFF-384, the new selector combinator is able to count inputs, so it could be a proper replacement for the counting functionality. However I don't see any condition in the screenshot, so it seems a hardcoded condition EACH <> 0, which is just an edge case of the above. That counting function in the selector combinator would be incredibly more useful if one can set some condition with EACH and counts the matching signals. It could free the implicit add functionality in the decider combinator for some slightly different operation that works more intuitively.

[DaveMcW]

Congrats, you are the first person I know of in 9 years to attempt to use decider combinator Each "Output single signal input count".

Can you explain what problem you are using this to solve?

Or are you just pointing out an inconsistency without actually using it?

[Twinsen]

If I understand correctly you want to output signal-A with the input count of signal-A when any condition passes. This is what the Anything special signal does already.
The current behavior is more useful, especially for counting the number of signals that pass.

While inconsistent, not a bug, and useful behavior for circuit network experts.

[ChakatStormCloud]

Congrats, you are the first person I know of in 9 years to attempt to use decider combinator Each "Output single signal input count".

Can you explain what problem you are using this to solve?

Or are you just pointing out an inconsistency without actually using it?

I was actually trying to use it to essentially: detect any item passing through an inserter, output A=30. I did find another way to do it eventually, but the result I got was so completely out of line with what I expected it to do, it broke all the consistencies of how the various setting normally behaved and just... felt really bad... really broken.

If I understand correctly you want to output signal-A with the input count of signal-A when any condition passes. This is what the Anything special signal does already.
The current behavior is more useful, especially for counting the number of signals that pass.

While inconsistent, not a bug, and useful behavior for circuit network experts.

the Anything setting is essentially un-usable with the input count setting, without very special consideration, since it triggers off of the input value itself. Meaning the only thing you can use it for is if the value you want to detect, is never the same value as the output value you want from it. There's a lot of reasons Each is more useful. since you can at least use a second combinator to negate static single trigger (or could if it behaved consistently).

I guess the issue gameplay wise is more with the Anything not excluding the signal set to input count, since if it weren't for that I would never have any reason to use Each output specified signal at input count.


I respect the decision, but I do want to stress, this isn't just an inconsistency, as far as I see it and felt it gameplay wise, it's the combinator randomly and unexpectedly using a completely different behaviour and setting interpretation than it ever has before, it's jarring, confusing, and made me feel like had to go back through every setting combination on both combinators to see if there was anything else that was going to silently throw a massive wrench in what I was trying to do.

It made me distrust the combinators.

[Tertius]

It seems you're not sure how exactly combinators work. There are always two stories. First, there is the short description in the game itself, and you seem to be confident you know everything about how combinators work from here. However, due to space restrictions, they're not telling every detail.

So what a programmer would do if he isn't entirely sure how some tool subroutine or API call exactly works, is looking into the specification and documentation.
So look into the wiki and you will find a nice matrix that exactly explains how input and output will interact: https://wiki.factorio.com/Decider_combinator#Function

There is no room for speculation. The behavior is well defined.

About your task at hand:
It seems you want to check all signals for a condition, and if the condition on some signal matches, you want to forward one specific signal as output, not necessarily the one that matched the condition. The problem with this is that the condition might also match for the signal you intend to forward. So you will need to craft the condition to not match on the signal to forward but on every other signal. Or you require the combinator ignore the signal to output for condition matching. This is an edge case and even less intuitive than the current EACH behavior you're complaining about. Designing a combinator this way to handle this edge case isn't good design, you cannot do this.

I solved such a task with 2 combinators. The first one is a decider that checks the condition with the ANY operator. It outputs some flag, for example M=1. The second one is also a combinator that gets both the output of the previous decider and the signal I intend to forward, if the match is true. It checks condition M=1 and outputs the EVERYTHING wildcard, so it's universal for the signal to forward. This way it will output nothing if no match and both M and the intended signal as output. I wasn't able to completely avoid any side effect like forwarding the M=1. This way you can forward a set of independent signals, if the condition matches.
You can also use the arithmetic combinator as second one and do M * <signal to forward> as operation and some explicit signal as output. This will avoid also forwarding the flag.

[Nidan]

If I understand correctly you want to output signal-A with the input count of signal-A when any condition passes. This is what the Anything special signal does already.
The current behavior is more useful, especially for counting the number of signals that pass.

While inconsistent, not a bug, and useful behavior for circuit network experts.

The request was for "each > 0 -> signal-A input count" to output signal-A multiplied by the number of matching input signals, in the same way that "each > 0 -> signal-A 1" outputs the number of matching input signals (~ 1 multiplied by the number of matching input signals). Using "anything" instead of "each" won't do the multiplication.

boskid already mentioned the workarounds:
requested behavior using today's rules: "each > 0 -> signal-X 1" followed by "signal-X * signal-A -> signal-A"
today's behavior using requested change: "each > 0 -> each input count" followed by "each + 0 -> signal-A"

Using the logic that [each] can be used to substitute a set of N decider combinators where each of them has different signal substituted by [each] makes sense,

I agree, I've been treating "each" as a vectorization operator until now and wasn't aware of the exception until this thread appeared.

however for me it fails one important usability aspect: when input signal substitute is the same as output signal then the decider combinator no longer becomes a "select signal conditionally based on different signal" but it turns into "select this signal based on condition" so it makes handling of the signals bundle slightly inconsistent.

Can you elaborate why you feel that way? None of the other settings make this distinction currently. If you ask for "each > 0 -> signal-A 1" and provide a constant "signal-A 20", you get a minimum output of 1 (which can easily be removed if undesired by e.g. providing a constant "signal-A -1" to the output). Likewise, for an arithmetic combinator "each * signal-A -> signal-A", an input of "signal-A 20" will contribute 400 to the output.

[...]

the Anything setting is essentially un-usable with the input count setting, without very special consideration, since it triggers off of the input value itself. Meaning the only thing you can use it for is if the value you want to detect, is never the same value as the output value you want from it. There's a lot of reasons Each is more useful. since you can at least use a second combinator to negate static single trigger (or could if it behaved consistently).

I guess the issue gameplay wise is more with the Anything not excluding the signal set to input count, since if it weren't for that I would never have any reason to use Each output specified signal at input count.

With 2.0, as per already mentioned FFF 384, the decider combinator will gain the ability to select the input wire(s) that get used for the individual comparisons and in the output; meaning, that as long as you provide your special signals on the other wire, e.g. "anything[red] > 0 -> signal-A[green] input count", will make that setting useful even if the comparison would normally match signal-A.
Considering that, among other reasons (less special cases, principle of least surprise, ease of implementation), anything/everything/each should not make any special exclusions based on the other signals selected in the combinator.