Factorio Forums

TL;DR: Allow "each" on both sides of combinator, implement red and green specific each's. Simple additions, explosion of possibilities.

1. Each on both sides

Part of this leads into the 2nd part, but for now: You cannot do `var/each=each`. It must be `each/var=each`. Obviously, if you put "each" on each side, it simply does each item individually. For example, doing `each-each=each` would clear everything because each item would say `myself-myself=myself` or "put 0 into me".

Seems useless in decider combinators, right? Read on.

2. Separate red/green "each"s.

Right now we have an "each" which adds together the red and green wires. Imagine if you could keep them separate!
For example: `re=each`. If items are on both lines, it will output the difference. If only on the red line, it will output the value on the red line. If only on the green line, the inverse of that value as the output. Very intuitive.

In addition, maybe allow decider combinators to have redEverything, greenEverything, redAnything, and greenAnything? More on that below.

But... why?

There are crazy amounts of possibilities

Modding
Doing mod is easier with multiple values if you can do `var/each=each`! This would also make digit displays more compact instead of having to use funky work arounds.

Array memory!
Grab values from memory! This is a super important one. We could make something like arrays. Give an array of data (let's say we're caching in constant combinators powers of 2, so index 1 returns 2, index 2 return 4, index 3 returns 8, etc). We start with an index constant combinator (e.g. 1 transport belt, 2 fast transport belt, 3 express transport belt, 4 randomItem, 5 randomItem, etc). We hook up our input and index cache to a decider combinator so we can get the "item key":

`each=inputIndex=>each` (only 1 of output)

Wait, but can't we already do this? Yes, but here comes the important part:
Our power-of-2 cache (however this could be anything like a memory cell or something that has a range of values on different items) would store matching items to values according to the above index cache. In our example: (2 transport belt, 4 fast transport belt, 8 express transport belt, 16 randomItem, 32 randomItem, etc). Now, if our previous output is on the red wire and this power-of-2 cache is on a green wire...

`redEach*greenEach=each`

Bam! So, if our inputIndex is 3, we would the first combinator would find an item that equals 3... express transport belt! Then, we do each red item, the equivalent green item. Everything on the red wire (output from before) is 0 except our 1 express transport belt! This means if we multiply by everything in the power-of-2 cache, we're left with 8 transport belt, which is 2^3! We actually mapped a value to a key and were able to access it!

Simpler comparisons

At the moment, we can easily do `inputOne*-1=outputOne` then `outputOne+inputTwo=outputTwo` and `outputTwo>0` to check if outputTwo>outputOne (or flip a few things to compare otherwise), however this method compacts it into: `redEach<greenEach=output`. Simpler isn't necessarily better, however since we already have `each` and are able to attach both red and green wires to combinators, it seems intuitive that you would be able to do that.

More

If people suggest other possibilities, or the devs are not convinced, I will be happy to add them!

BUT WHAT ABOUT

* `each/each=each` just gives 1 (for any item that had a value previously)
* In an arithmetic combinator, you cannot output redEach or greenEach, that doesn't make sense. You'd simply output `each`.
* In a decider combinator, there are two options for how outputs work: 1) Keep it `each only` and make it apply to the left side. Since in a decider combinator it's easy to switch the sides since it makes no different (because you can flip sides), you could flip the sides if you needed to. 2) Keep `each` (which adds red + green wires) and allow `redEach` and `greenEach` to only output the value of those wires (if the requirements are met).
* If it's implemented, `redEverything>greenEverything=>each` means "If everything in the red wire is greater than each respective item in the green wire (except values of 0 I suppose?) then output each item.
* `redAnything>greenAnything=>each` means "If anything in the red wire is larger than the same item on the green wire, output each item.
* `redEach>greenEach=>each` means "Each item can pass if they are larger on the red side than the green".
* `redEach>greenEverything` or `greenAnything=redEverything` is a no no! Only the same type of "each" (each, anything, everything).
* More stuff that I probably missed. Will add on.

Why is this so great?

It's a small change to one part of combinators but opens up many possibilities. If someone is not interested in combinators, it's unlikely it will affect them! All of these are type `virtual`.

Please give feedback!

DemiPixel wrote: For example, doing `each-each=each` would clear everything because each item would say `myself-myself=myself` or "put 0 into me".

Wrong. It will calculate each signal witch each signal. So if you have in input signals: A=1, B=3 and B=5 it will calculate A=A-A+A-B+A-C=0+(-2)+(-4)=-6, B=3-1+3-3+3-5=0, C=5-1+5-3+5-5=6.
Finally you get A=-6 and C=6. Look how many calculations require only 3 signals. Now imagine this for 100 signals.

Neotix wrote:Wrong.

That depends on what is implemented (if anything). There is no right or wrong answer at the moment.

Neotix wrote:

DemiPixel wrote: For example, doing `each-each=each` would clear everything because each item would say `myself-myself=myself` or "put 0 into me".

Wrong. It will calculate each signal witch each signal. So if you have in input signals: A=1, B=3 and B=5 it will calculate A=A-A+A-B+A-C=0+(-2)+(-4)=-6, B=3-1+3-3+3-5=0, C=5-1+5-3+5-5=6.
Finally you get A=-6 and C=6. Look how many calculations require only 3 signals. Now imagine this for 100 signals.

Wrong? I'm suggesting a feature. My way would still be powerful. I understand it might seem like "each" and "each" on both sides would be two loops, but I assure you, this method will still work.

You say that B would be 3-1+3-3+3-5 but it would make sense that it'd be 3-1-3-5, no? If this is your desired effect, then do:
connect input => `each+0=output`
connect input and previous combinator => `each-output=each`

We can already do that without these features! You should continue reading and see what I had planned for these effects. I simply stated the `each-each=each` as an example of a side effect of these new features.

DemiPixel wrote:You say that B would be 3-1+3-3+3-5 but it would make sense that it'd be 3-1-3-5, no?

3-1+3-3+3-5 is each-each calculation for B signal. 3-1-3-5 is each-everything calculation for B signal. You can't jusy change the basic logic of signals because it will become illogical.

Neotix wrote:

DemiPixel wrote:You say that B would be 3-1+3-3+3-5 but it would make sense that it'd be 3-1-3-5, no?

3-1+3-3+3-5 is each-each calculation for B signal. 3-1-3-5 is each-everything calculation for B signal. You can't jusy change the basic logic of signals because it will become illogical.

Each=everything in arithmetic combinators. You can't use everything/anything in them. Also, it doesn't matter, because my point stands that you can still do that right now, and it's completely missing the point of this feature.

Neotix wrote:3-1+3-3+3-5 is each-each calculation for B signal. 3-1-3-5 is each-everything calculation for B signal. You can't just change the basic logic of signals because it will become illogical.

There is no present Each-Each feature - so the "basic logic" of Each-Each is not defined yet. DemiPixel is suggesting they define it pair-wise, and you're suggesting they do something much more complex, but there is no right or wrong answer, or "basic logic," for a non-existent feature.

They're not equal because Each-1 is not the same as Everything-1. If we set Each-1=Each we get all signals decreased by 1 but if we set Everything-1 (we can't set each as result because it would cause null value) we get one signal that will be sum of input signals decreased by 1. They can provide the same results only for specific situation when we choose specific signal on output like Each-1=A.

So your proposition for "each-each=0" is to change logic of "each" signal and make it illogical.

@ silverkitty23 it's not about mechanic for each-each because words have meaning also in mathematics. You can't just ignore it and make your own logic because it will become illogical.


I'm not against entire proposition because some points are interesting but I can't agree with changing logic.

Arguably, because real-world vector addition is defined thus: [ a1, a2, a3, ... , an ] + [ b1, b2, b3, ... , bn ] = [ a1 + b1, a2 + b2, a3 + b3, ... , an + bn ], DemiPixel's suggestion is much more "logical."

It's also more consistent, because at present, you can only get the one "Each", and it actually is the vector sum of red and green signals.

When I got my math degree, I was taught about vector math, but we never had a special mathematics-specific definition of 'each'. Maybe colleges are teaching something different these days, but as far as I know, "each" is just English and thus loosely defined.

This argument would be more interesting if we were talking each*each or each/each because we'd have to figure out if we like dot products or cross products when dealing with our vectors, but there's only the one way to add vectors.

Then again, the game already has made up math: "each - 1" corresponds to no vector operation (vector + scalar is undefined), so the actual case for your definition of each-each (which works like a weird additive version of a cross product) is "as long as we're making up math, anyway..." rather than "it's based on real world math"

I think it is not clear, how this will work in practice. It's interpretable. And it also could not be described in a way, that the game explains this functionality itself.

It's really that simple: Either it explains itself or not. If not, it needs to be changed. But I don't see it possible to change this in that way.

But I'll wait for more arguments, I've popcorn left. Seriously: If someone has an idea how a more than average player could be enabled to understand this functionality from within the game, I'm with it. (This is already difficult with the "each" alone)

ssilk wrote:I think it is not clear, how this will work in practice. It's interpretable. And it also could not be described in a way, that the game explains this functionality itself.

It's really that simple: Either it explains itself or not. If not, it needs to be changed. But I don't see it possible to change this in that way.

But I'll wait for more arguments, I've popcorn left. Seriously: If someone has an idea how a more than average player could be enabled to understand this functionality from within the game, I'm with it. (This is already difficult with the "each" alone)

It's also possible that I described it in a less-than-adequate way. If a player knows about `each`, then `Red Line Each` and `Green Line Each` seems like it would do exactly that: `each` for a line. Hopefully very intuitive. Sure, there would still be things to learn, like how it's a pairing instead of two loops, but everything has its learning curve. As for the first change, that's something that just goes along with the second feature. No explanation would really be needed once a player saw that `each` was available on the right side, and they could try it out to see that it's pair-wise.

Is there any way I could improve my explanation? Or were you just worried about the things I just mentioned?

One problem I've run into a lot is that I'll be doing some arithmetic to some set of signals, and I want to, say, divide each of by some unrelated changeable value X (which I represent with, say, the Blue signal). The way combinators are set up now, you can't avoid passing a value through, so i have to add in another combinator to just to cancel out the 1 Blue that comes from the output. It's much worse with multiplication or multiplication, since I have to use 3 extra combinators (2 of them to get -x*x Blue, and a delay so that it syncs up with Each*Blue). Since I'll almost always have the other signal coming in on the other wire, "red each" and "green each" seem like reasonable ideas to me, even if they make the circuit system slightly less natural-seeming.

I'm less enthusiastic about Each on both sides, just because I don't see it solving as many problems...maybe if there could be a specific red vs green combinator? Actually, that would also help make the "red/green auto-add EXCEPT IN THIS CIRCUMSTANCE" thing seem more natural...

stellatedHex wrote:One problem I've run into a lot is that I'll be doing some arithmetic to some set of signals, and I want to, say, divide each of by some unrelated changeable value X (which I represent with, say, the Blue signal). The way combinators are set up now, you can't avoid passing a value through, so i have to add in another combinator to just to cancel out the 1 Blue that comes from the output. It's much worse with multiplication or multiplication, since I have to use 3 extra combinators (2 of them to get -x*x Blue, and a delay so that it syncs up with Each*Blue). Since I'll almost always have the other signal coming in on the other wire, "red each" and "green each" seem like reasonable ideas to me, even if they make the circuit system slightly less natural-seeming.

I'm less enthusiastic about Each on both sides, just because I don't see it solving as many problems...maybe if there could be a specific red vs green combinator? Actually, that would also help make the "red/green auto-add EXCEPT IN THIS CIRCUMSTANCE" thing seem more natural...

Well, it was mainly to support the red/green thing so people would be convinced it's on one side. The benifit of each on both sides is that we can do var/each or var-each which would be nice.