Combinitors Output (input count)

[Lupoviridae]

Has anyone found a practical use for the output (input count) function of the decider combinator? The only use I can think of is as a diode to separate two circuit networks.

I really think this function would be more useful if it were configured a slightly different way; take the following example.

Input: 30 Red, 1 Green
Set: If Green = 1, output (input count) Red

Currently, this will output a red signal of 1. Basically, if green = 1, output count of green AS red.
As I said, this currently works as a diode:
https://en.wikipedia.org/wiki/Diode

I would love to see this changed to If green = 1, output (input count) OF red.

Reasoning:
It would still work perfectly fine as a diode (if red=30 output input count of Red)
If you want to change a signal to a different one, you can always use a single arithmetic combiner instead.
(input red * 1, output as green)

Most importantly - It would allow the combinator to work as a tri-state buffer.
https://en.wikipedia.org/wiki/Three-state_logic

Basically a signal is only transmitted when ANOTHER condition is met.
This a very, very useful tool when building complex circuits, and I think
it would have a lot of uses in simple base circuits too.

What do you guys think?

[ratchetfreak]

You can use it to loop over several outposts and grab the supplies available in each



Left is at the base, the constant combinator outputs a outpost ID on signal 0 green (place holder). The arithmetic mulitplies signal 0 with -1 and outputs it to red (to neutralize the selector signal if you wish).

on the right is the outpost the constant combinator representing the supply in the outpost. The decider gets intput from green is set to signal 0 == outpost ID and the supply on red. The output is on the red line "everything input count" which is a copy of all the inputs. (and why you will want to neutralize the signal 0 that also end up on the output)

[Lupoviridae]

Right. In your example you are basically using it as a tristate buffer. But what if you do not want to output everything, but only the count of one item? There is currently no way to easily do this. My suggested change would not disallow what you presented, just allow even more possibilities.

[ratchetfreak]

You can filter 1 signal by putting it through a arithmetic combinator with +0 (or another idempotent operation -0, *1, /1)

You can even let it output on another signal that way. For example to pass it into a blueprinted circuit that expects the input to be on the blue signal.

[Lupoviridae]

Thats exactly what I'm trying to say.

Right now I see no good reason why you would want to use a decider to take one input and merely output it as something different. This can already be done with arithmetic combinators as you have said. Rather than having a function that is redundant, I would really like to see it become something that is actually useful. Again, this would not impair any other function of the deciders, merely add MORE potential uses.

[Twinsen]

I have given it some though. The reason why it works this way is that it's (arguably) more intuitive for beginners.
I am considering changing it the way you want since it might have a few more use cases. I'm still looking for opinions.

To get exactly what you want you can use a arithmetic combinator as a filter, so you will use 2 combinators instead of 1, not really a big deal in my opinion.

Depending on your design, another way to make a tri-state switch is:
Parameters:
"Each" > "Signal A"
Output:
"Each" (input count)

It will output all signals that satisfy the condition, except for Signal A.
The problem is that to turn it off you will make signal A = 999999. To turn it on you will make signal A = -999999.

[ratchetfreak]

I have given it some though. The reason why it works this way is that it's (arguably) more intuitive for beginners.
I am considering changing it the way you want since it might have a few more use cases. I'm still looking for opinions.

To get exactly what you want you can use a arithmetic combinator as a filter, so you will use 2 combinators instead of 1, not really a big deal in my opinion.

Depending on your design, another way to make a tri-state switch is:
Parameters:
"Each" > "Signal A"
Output:
"Each" (input count)

It will output all signals that satisfy the condition, except for Signal A.
The problem is that to turn it off you will make signal A = 999999. To turn it on you will make signal A = -999999.

But that requires also another set of combinators to make that signal min int or max int. Filtering out unwanted signals afterwards is simpler in the current implementation.

You could keep inputs green and red separate instead of unconditionally adding them first. This would for example allow using green to signal and red for input but keep the green signal out of the output; you set the input to "each green > 0" and output to "each red output count". This will create a signal filter that will only output the signals coming in on red if the matching signals are >0 on green.

[Lupoviridae]

Depending on your design, another way to make a tri-state switch is:
Parameters:
"Each" > "Signal A"
Output:
"Each" (input count)

It will output all signals that satisfy the condition, except for Signal A.
The problem is that to turn it off you will make signal A = 999999. To turn it on you will make signal A = -999999.

But that requires also another set of combinators to make that signal min int or max int. Filtering out unwanted signals afterwards is simpler in the current implementation.

Ratchet, I believe he is saying this is how it currently works if one uses "each" for a tri-state buffer.
Also, filtering out unwanted signals afterwards WOULD NOT CHANGE.
Actually, the output everything(input count) function would be EXACTLY THE SAME.

I am only suggesting to change the output(input count) function when it pertains to a single item output, such that it outputs the input count OF THAT ITEM. Since changing the signal can already be done with an arithmetic combinator, the current function is redundant.

[ratchetfreak]

I am only suggesting to change the output(input count) function when it pertains to a single item output, such that it outputs the input count OF THAT ITEM. Since changing the signal can already be done with an arithmetic combinator, the current function is redundant.

I have an additional suggestion of keeping red and green inputs separate (and only copying one side for output) to test. Doing the adding internally before the logic is a bit counter-intuitive for the decider.

[Lupoviridae]

I have an additional suggestion of keeping red and green inputs separate (and only copying one side for output) to test. Doing the adding internally before the logic is a bit counter-intuitive for the decider.

Changing this would completely change how the deciders work and would mean they could no longer be used as logic gates (which by their nature use the sum of both inputs). It is also outside the topic of this thread.

[ratchetfreak]

I have an additional suggestion of keeping red and green inputs separate (and only copying one side for output) to test. Doing the adding internally before the logic is a bit counter-intuitive for the decider.

Changing this would completely change how the deciders work and would mean they could no longer be used as logic gates (which by their nature use the sum of both inputs). It is also outside the topic of this thread.

You can get the sum by using a arithmetic combinator to move both sets onto the same wire, or also add the AND and OR to the decider. (or just add the option to do the sum)

[Lupoviridae]

After getting to play around with combinators more, I am still very much in favor of this, as I have found several instances when it would have been useful. Can we get any other opinions besides me and Ratchet?

Again to help clarify, the change I am suggesting would only take effect when the following conditions are met:
1) The input item and output item selections do not match.
2) The input and output item numerical values do not match.
2) The output (input count) option is selected.

From what I have seen so far on the forums, I do not believe this would mess up what anyone has made so far.

[keyboardhack]

Having tried to figure out how combinators worked for a few hours and this behavior was definetly not expected or logical. Either the output should be shown in another way to make it more obvious that this is how it works or the behavior should be changed. I would like to see it changed.

[MeduSalem]

I have an additional suggestion of keeping red and green inputs separate (and only copying one side for output) to test. Doing the adding internally before the logic is a bit counter-intuitive for the decider.

I'd be in favor of ratchet's suggestion.

Adding the contents internally before the logic is done is completely counterproductive. It renders having different wire colors superfluous in most applications because it acts like all the contents are already on ONE wire and if one actually DOES use both wire colors it only causes problems in the output, since one has to filter/negate all the effects from the wire that one doesn't wish to put through.

So my opinion is also that the contents of the red and the green wire should be kept seperate by default and you have the option to either put through the content of the red wire or the green wire, or one signal-channel or the the other if using only one wire. The sum could be perfectly done with the Arithmetik Combiner (ADD).

It's either that or kill off the green wire from the game altogether because of how everything can be emulated with just one wire color using various signals on said wire anyways.

At least having red/green wires and multiple channels on each wire creates a super ridiculous mess currently and I don't really want to look too much into it because I have the feeling that it won't stay this way due to how ugly and unneccessarily complex it is. It's like we should have only one or the other: Either red/green wire OR multiple channels on one wire, but not both at the same time because that's confusing as hell for casual players (especially now that red/green wire and red/green signals are both a thing but are fundamentally not the same thing because of how a red wire might have a green signal and vice versa) and also because it works only "meh"/half-thought-through in some details due to how overly complex it is.

All I really wanted were some basic sensors, some items working on a signal and a comperator item offering Equal/Greater/Less/Equal or Less/Equal or Greater/AND/OR/NOT/XOR/NOR and basically be done with it... Didn't expect it to turn out into such a conceptual mess.

Changing this would completely change how the deciders work and would mean they could no longer be used as logic gates (which by their nature use the sum of both inputs). It is also outside the topic of this thread.

Which is the main reason why I disfavor the current implementation of the deciders in the first place. Don't get me wrong, they are a nice addition etc, but the thing bothering me the most currently is that their usage is non-intuitive for people who aren't that much into programming/electronic industry.

While I perfectly understand how to implement basic logic gates with the deciders currently I'd still favor having native logic operations like AND, OR, NOT, etc instead of "{item} > 1" emulating AND, "{item} > 0" emulating OR, etc. Also native comparisons work with any input value and not only 0/1 binary values, so you wouldn't need arithmetic combiners to do any multiplications/divisions to get into a binary format and back, thereby saving on space.

Doing it the way it is currently implemented is just not really that intuitive for most people. At least "{item} = 1" emulating XOR isn't really that obvious to me at the first glance like the comparison itself being "XOR" would be to me, as would be native comparisons like "AND", "OR", "NOT", etc. And it also requires a lot of additional arithmetic combiners for values that aren't by default binary, which makes me pull my hair out because the simplest contraptions end up wasting a lot of space.

At least I try to avoid creating more sophisticated stuff because of how fundamental the entire thing is implemented currently and therefore hard to reverse engineer as well as to do maintainence on it because after a few days/weeks you won't know what most of the contraptions did without learning your way into it again. I'd prefer a bit more abstraction to make it more user-friendly.

You can get the sum by using a arithmetic combinator to move both sets onto the same wire, or also add the AND and OR to the decider. (or just add the option to do the sum)

Yeah, adding the basic logic operations natively into the Decider itself (without the strange emulation) is what I would have expected them to be anyways long before the Friday Facts ( https://www.factorio.com/blog/post/fff-88 ) revealed that they are using this strange non-casual-player-friendly approach and which is the way I'd do it because most other games that offer similar stuff all have native comparisons in their building blocks because they often lack arithmetic units and therefore can't convert from non-binary into binary and back.

[Twinsen]

That was a big post.
Alright so first of all I agree with the first part of the post, having both red and green wires seems to just complicate things and the way they work is not so well explained by the game.
But, some of the the reasons why red and green wires were kept is because

• Legacy reasons: it was like this this before. Things like poles are made to have 3 wires
• It looks cool. I like it when wires look something like this or this and the crazy wire nets in Lupoviridae's setup.
• In some complex combinator setups(like the factorio sign) it was useful to have 2 independent networks exiting the same combinator

In the second part of the post you say you prefer AND OR XOR instead of emulating them in some complicated way.

their usage is non-intuitive for people who aren't that much into programming/electronic industry.

At least "{item} = 1" emulating XOR isn't really that obvious to me at the first glance

Keep in mind that the combinators were not designed to be able to build Factorio computers and LED signs, they were designed to control your factory, to turn parts of the factory on or off based on simple conditions.
You say XOR is not intuitive by doing {item} = 1. Well, your average player that is not a programmer/electronics engineer will say "I want to turn on these insertes when exactly one of my outposts is out of copper", he will not say "I want to turn on these inserters when a exclusive disjunction logic gate condition is satisfied between the binary input signals".(I exaggerated a bit, but you get the idea)
You have to think in basic game terms, not binary logic gates. That fact that you can make logic gates with combinators is a nice(and helps you make very complex conditions to control your factory) but it's not what combinators were designed to do. Making a 8bit ALU in Factorio is nice and all, but you can just use the arithmetic combinator and you have a 32bit ALU right there.

You say that there should be native binary operations AND OR XOR, etc. The problem is that the circuit network is not binary, having these operations on integer values does not make much sense. Having some new combinators that convert integer values to binary values and having binary channels and integer channels on the same wire(or on different wires?) will make the combinators even more complicated than they already are.

When the combinators will be finished I hope I will get the time to write a proper wiki page explaining the circuit network and combinators very well.

I have derailed this topic a bit. To get back to the small issue, I am still considering changing how "input count" behaves based on Lupoviridae's suggestion.

[MeduSalem]

That was a big post.
Alright so first of all I agree with the first part of the post, having both red and green wires seems to just complicate things and the way they work is not so well explained by the game.
But, some of the the reasons why red and green wires were kept is because

• Legacy reasons: it was like this this before. Things like poles are made to have 3 wires
• It looks cool. I like it when wires look something like this or this and the crazy wire nets in Lupoviridae's setup.
• In some complex combinator setups(like the factorio sign) it was useful to have 2 independent networks exiting the same combinator

Well of course I thought about the legacy reasons and that pole graphics are already made for supporting 3 wires.

One thing I can't agree on is the wire-mess pictures. I just hate that sort of stuff... get me some cable binders and I'd sort that out!

I also appreciate to some degree that having two independent circuit networks may come in handy in some specific situations even if you have dozens of individual channels/signals on a single red wire already... it's just that the interaction between the red wire and green wire isn't really that thought through yet. The combining of all the channels from both networks before inputting it to a decider is just... weird, like ratchetfreak first mentioned. At least it causes more unwanted sideeffects.

If the interaction between them is sorted out or solved in a better way and once it is better explained/differentiated ingame however I think we could live with having two individual circuit networks as well as mulitple channels on each network.

In the second part of the post you say you prefer AND OR XOR instead of emulating them in some complicated way.

Keep in mind that the combinators were not designed to be able to build Factorio computers and LED signs, they were designed to control your factory, to turn parts of the factory on or off based on simple conditions.
You say XOR is not intuitive by doing {item} = 1. Well, your average player that is not a programmer/electronics engineer will say "I want to turn on these insertes when exactly one of my outposts is out of copper", he will not say "I want to turn on these inserters when a exclusive disjunction logic gate condition is satisfied between the binary input signals".(I exaggerated a bit, but you get the idea)
You have to think in basic game terms, not binary logic gates. That fact that you can make logic gates with combinators is a nice(and helps you make very complex conditions to control your factory) but it's not what combinators were designed to do. Making a 8bit ALU in Factorio is nice and all, but you can just use the arithmetic combinator and you have a 32bit ALU right there.

You say that there should be native binary operations AND OR XOR, etc. The problem is that the circuit network is not binary, having these operations on integer values does not make much sense. Having some new combinators that convert integer values to binary values and having binary channels and integer channels on the same wire(or on different wires?) will make the combinators even more complicated than they already are.

Well I think you may have gotten me wrong... I didn't specifically say that I only want to have binary native logic operations.

I thought it was clear that I meant that the native logic operations I would have liked to see should work on any integer value given, or better said they should work by comparing two channels directly with each other and outputting a result based on that.

Maybe I should give better examples with Iron&Copper Plates of what I meant with "native" logic operations:

• Parameters: Iron Plates OR Copper Plates
  Output: "1" or "Iron Plates Amount"/"Copper Plate Amount" (which one gets output could be selected)
  Outputs when: One or both Channels are greater 0. Currently not possible in one step.
• Parameters: Iron Plates AND Copper Plates
  Output: "1" or "Iron Plates Amount"/"Copper Plate Amount" (which one gets output could be selected)
  Outputs when: Both Channels are greater 0. Currently not possible in one step.
• Parameters: Iron Plates XOR Copper Plates
  Output: "1" or "Iron Plates Amount"/"Copper Plate Amount" (which one gets output could be selected)
  Outputs when: One Channel is greater 0, while the other Channel is 0. Currently not possible in one step.

And so on, if one would want to go as far as including more types.

The way the logic gates are emulated currently it takes more effort to accomplish something simple as that, because you have to use a decider to check on each channel individually and then match the outputs of both deciders in a third decider to finally get a comparison between the channels. Which is like three times the effort compared to what I suggest above.

Of course the type of channels available for comparison should make sense. It wouldn't make much sense to make a comparison between a Channel and a set fixed number for example.

Those wouldn't change anything about the existing "logic gates", but rather simplify the overall process of implementing direct logic comparisons between two channels.

When the combinators will be finished I hope I will get the time to write a proper wiki page explaining the circuit network and combinators very well.

I have derailed this topic a bit. To get back to the small issue, I am still considering changing how "input count" behaves based on Lupoviridae's suggestion.

Nah, I think it's good to get Developer opinions as well, because your view is as important, if not more important than any player view. At least it is easier for a player to understand/relate to what developers thought when implementing something in a specific way if they take their time to explain why they did something exactly the way they did and not in an other.

[Lupoviridae]

@Medusalem: Please, what you are talking about is a major overhaul of the combinator system. I think it highly unlikely that this will happen, and this thread is not the place for it. Combinators are Factorio's unique take on discreet logic implementation, just like redstone was for Minecraft. If you want to discuss this further, please take it to another thread.

PS. All three examples you listed can be done in two steps, except for outputting the input count of a specific item, which brings us back on topic!
OR - (Iron + Copper; output as Green) (If green > 0, output 1)
AND - ( Iron * Copper; output as green) (If green > 0, output 1)
XOR - (Iron + Copper; output as green) (If green = iron, output 1)

[MeduSalem]

@Medusalem: Please, what you are talking about is a major overhaul of the combinator system. I think it highly unlikely that this will happen, and this thread is not the place for it. Combinators are Factorio's unique take on discreet logic implementation, just like redstone was for Minecraft. If you want to discuss this further, please take it to another thread.

The first part with the red&green wire is still related to this thread because it is the major reason why the Output "input count" is not working in a useful manner.

The interaction between red&green just isn't fully thought through like I already wrote.



But you are right on the second part with how the logic implementation works itself, I might consider creating a unique thread for that, but maybe silk can do some moderation magic and split off the parts from my posts and Twinsen's to a new thread. At least I PM'd him about it.

PS. All three examples you listed can be done in two steps, except for outputting the input count of a specific item, which brings us back on topic!
OR - (Iron + Copper; output as Green) (If green > 0, output 1)
AND - ( Iron * Copper; output as green) (If green > 0, output 1)
XOR - (Iron + Copper; output as green) (If green = iron, output 1)

And oh well yes, now I saw your edit, didn't consider doing some arithmetic manipulations to skip one step. Well that's what I mean with "not too much into the programming stuff" or "not as obvious to the player", because as I'm technically not that much into that kind of stuff I wouldn't have thought about that and I'd rather have used 3 deciders to do it.

[Twinsen]

Resurrecting this topic.
This change will most probably happen in 0.13(It took a long time, I know).

[piriform]

Has anyone found a practical use for the output (input count) function of the decider combinator?

Actually I use this configuration quite a bit as a (spill) gate. Typically I may have a lot of signals that are gated by a condition specified by two signals (e.g. X=Y: everything=count)

If it's just a matter of buffering then there are already some good options.
For example, a decider, with X=0: everything=count setting will buffer the signals just fine . Any non zero X value will stop the signal transmission.

I'd caution against introducing nuc's at this point. There are already many complex circuits that rely on boundary conditions and undocumented features.

PS OTOH anyone advocating for ^= in a decider has my vote