Separate signals to/from red and green wires

[Impatient]

TL;DR

Signals can be distinguished by the wire color they are transmitted on.

What ?

In an entity generating or processing signals to or from the circuit network, these signals can be distinguished by the color of the wire they are sent to or are received from. Additionally it is possible to send a signal to both wires in a generating entity or unify the signals from both wires in a receiving entity.

Examples
In a constant combinator it is possible to set the values for coal red and coal green separately. If no color is chosen, the signal is sent to both wires.

In a decider or arithmetic combinator it is possible to select coal red or coal green as the input signal. If no color is chosen, the values from the coal signal received over the red wire and the green wire are combined (added together) and then used for the further calculations, as it is done now.

How would it look like in the UI?

When selecting the symbol for a signal, the user also has the choice to select the wire color or no color via a 3 choices radio button.

For clarification the choice for no color is labeled differently, depending on whether the signal is sent or received. When the signal is sent the choices are labeled "red, green, both". When the signal is received the choices are labeled "red, green, combined".

Visually the signal icons have a red, green or no (like now) background color once the color is selected.

How does this blend in with the current implementation of the circuit network?
It blends in very nicely. If "both" and "combined" are the default values for the signal color, then nothing changes at all for the user. But the user can chose to make use of the extended capabilities by actively "coloring" the signals.

Does this also work for the pseudo signals everything, anything and each?
Yes it does. The colored versions of the pseudo signals work fine (Eg everything from the red wire, anything from the red wire, each from the red wire and everything to the red wire). The uncolored versions work of course, because they work like they do now.

Remark for further debate: Though seasoned users of the circuit network might remark at this point, that it might add further possibilities, if the uncolored pseudo signals treat the colored versions of a signal like separate signals and not combine their values.Or if there is some choice for how they behave.

Some mokups

Picking output signal

Picking input signal

Constant combinator

Decider Combinator

Why ?

* Because it adds to the possibilities in the game AND at the same time simplifies things.
* Eg: No more need for signal conversion before processing two signals of the same type from the two different wires! At last I can read the coal value from a chest and compare it with the coal value set in a constant combinator by using only a decider combinator: coal green < coal red ?

... and a lot more awesome possibilities and simplifications!

[boggis2]

and also read requester chest on green and set the request number on red.

[Oktokolo]

+1

[mrvn]

+1

I don't see other way to implement "each red / each green" any other way, unlike "each red * each green" which can be emulated by a couple of combinators.

[Vegemeister]

+1

I don't see other way to implement "each red / each green" any other way, unlike "each red * each green" which can be emulated by a couple of combinators.

If you can do each red * each green, you can do division too, because division is inverse multiplication. Takes some fixed point hoodoo though.

((65536 / each green) * each red ) / 65536

[mrvn]

+1

I don't see other way to implement "each red / each green" any other way, unlike "each red * each green" which can be emulated by a couple of combinators.

If you can do each red * each green, you can do division too, because division is inverse multiplication. Takes some fixed point hoodoo though.

((65536 / each green) * each red ) / 65536

1) That easily overflows or is widely inaccurate, only works for small numbers. You have to pick the right constant for every case. For example if green contains the contents of my warehouses there could be 300000 iron plate. And red contains the free buffer space for all the iron plate using train stations, or 3000000.

3000000 / 300000 = 10
((65536 / 300000) * 3000000) / 65536 = (0 * 3000000) / 65536 = 0 / 65536 = 0

On the other hand if I have only 1 iron plate in the warehouses it overflows.

2) Iirc you can't do "65536 / each" with an arithmetic combinator.

[Impatient]

+1
I don't see other way to implement "each red / each green" any other way, unlike "each red * each green" which can be emulated by a couple of combinators.

I never thought through the possibilities of colored pseudo signals. Would "each red * each green" like you picture it, do {coal red * coal green, stone red * stone green, pistol red * pistol green, etc ...}?

[mrvn]

+1
I don't see other way to implement "each red / each green" any other way, unlike "each red * each green" which can be emulated by a couple of combinators.

I never thought through the possibilities of colored pseudo signals. Would "each red * each green" like you picture it, do {coal red * coal green, stone red * stone green, pistol red * pistol green, etc ...}?

Yes, that would be the idea. You can use the following little trick:

Code: Select all

(a+b)^2 - (a-b)^2 = a^2 + 2ab + b^2 - (a^2 - 2ab + b^2) = 4ab

[Skeletpiece]

+10

[Caine]

-(i²)

[McDuff]

and also read requester chest on green and set the request number on red.

+1 on separate read/write channels.

I'm trying to do something at the moment where I'm filtering the signal to set the filter of an inserter based on what the other inserters in the line have in their hands.

i.e. filter signal is iron plate, iron gear, green circuit.
First inserter picks up iron, multiply the signal by -1, subtract from filter signal.
Next inserter picks up gear, multiply that by -1, subtract from filter signal.
...and so on down the line.

I've worked out a way to do it but it's combinator heavy and increases in complexity as you increase the size of the inserter line.
Being able to keep the output of the inserter's "read hand contents" line separate from the input to the "set filter" line would simplify things a lot.

[golfmiketango]

and also read requester chest on green and set the request number on red.

+1 on separate read/write channels.

I'm trying to do something at the moment where I'm filtering the signal to set the filter of an inserter based on what the other inserters in the line have in their hands.

i.e. filter signal is iron plate, iron gear, green circuit.
First inserter picks up iron, multiply the signal by -1, subtract from filter signal.
Next inserter picks up gear, multiply that by -1, subtract from filter signal.
...and so on down the line.

I've worked out a way to do it but it's combinator heavy and increases in complexity as you increase the size of the inserter line.
Being able to keep the output of the inserter's "read hand contents" line separate from the input to the "set filter" line would simplify things a lot.

Yep... you are basically implementing this idea using combinators... I wind up doing this too sometimes (formulating that post really helped me get it all clear in my head). Even more confusingly, if the inserter needs this, to prevent that wire from consuming its own output, I find I typically have to pull a second wire from the inserter... but now, the inserter is eating its own outputs /twice/ so I have to put "EACH * -2" there. pretty confusing.

[Impatient]

Thinking of making two appendices to the OP. ...

Appendix 1: Use cases for original suggestion

Appendix 2: Follow up ideas

Would this help to structure this topic and the discussion?

[McDuff]

I think the suggestions I made in this thread fit. viewtopic.php?f=6&t=57668

Extra colour wires for channels and a multicore cable.

Combine this with picking in/out and you can set up signal "busses" to keep track of stock and other signals.

I think this is a useful expansion of the existing circuit mechanics.

[mrvn]

Thinking of making two appendices to the OP. ...

Appendix 1: Use cases for original suggestion

Appendix 2: Follow up ideas

Would this help to structure this topic and the discussion?

The original post already has examples in the mock ups. Other use cases are computing red - green without overflowing at 65536 or red / green which afaik can't be done without an arithmetic combinator per signal.

[rldml]

I don't see the problem - it's not that complicated to add a simple combinator to transform one signal to be able to multiply both. The signals arrives already separated, even if they run along the same electric poles. As long you send them about different wires.

Additionally you would get a bunch of problems: when the outout is connected to a green and a red wire, have you to configure which wire you want to send out the signal? What happens, if you just need a simple sum of the same signal type, that came along red and green wire (how it works now) for some reasons? What happens (interesting for modders) if you send stuff over a third wiretype (like wireless, or another wire color)? Would it be possible to send a red virtual signal type over a green wire? If no, why not (at least, they are just two different subtypes of a virtual signaltype)?

All of this for the simple fact you want to set one combinator less for the rare case you want to multiply two virtual signals of the same type coming along two wires?

Greetings, Ronny

[mrvn]

Firstly because you can't transform "each" to "a different each". That makes computing the difference or product of red and green hard and division impossible.

Secondly, if you read the proposal again, the default is that nothing changes. Signals still go out on all wires and come in from all wires just like now. Only when you specifically ask for a color you get a difference.

Signals them self have no color. It's the wire they come in on that makes the color. So any virtual signal that comes in on the green wire can be selected in a combinator as green virtual signal. Or just virtual signal if you don't care about which wire it came from.

[McDuff]

All of this for the simple fact you want to set one combinator less for the rare case you want to multiply two virtual signals of the same type coming along two wires?

Trust me, it's not "one combinator" fewer. If you're trying to do feedback loops and comparisons of different stock levels in different parts of your system to set supply and demand, you end up using an awful lot of buffers and temp counters which you then have to filter out. To get a filter insterter to pick up an arbitary item from a belt you need to use 3 combinators per inserter. If you could just pick up an isolated signal from a wire you could get that down to 2, which across a system with hundreds of inserters is, obviously, hundreds of arithmetic combinators. And that's just one part of a signal path!

Also there are some things you just can't do at the moment. For instance, you can't set a requester chest, you can only read from it. If you could separate the signals you can do more things, full stop. Simple operations become simpler, and more complicated operations become doable.

[McDuff]

Another thing: this idea not doable with current implementation, easily done with separate outputs. viewtopic.php?f=6&t=57820

[mrvn]

I don't see the problem - it's not that complicated to add a simple combinator to transform one signal to be able to multiply both. The signals arrives already separated, even if they run along the same electric poles. As long you send them about different wires.

I just noticed that you said "transform one signal". Maybe there is the misunderstanding.

The biggest challenge is to do this for many or all signals. In most cases you need one combinator per signal to transform the input so the two wires don't simply add up.

Here is another use case for the decider combinator: if green wood > 1000 then output red each. Currently you have to first transform the green wood into a signal not present on the red wire, possibly add another combinator to delay the red signals to match the timing. Then use the transformed signal in the decider combinator. And if you want a clean output signals you need another 2 combinators to remove the transformed signal from the output again. That's a total of 5 combinators and 3 ticks signal length.