Separate signals to/from red and green wires

[Jap2.0]

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.

Can't you just put a green wire into the combinator, set to output each if wood > 1000, and then take a red wire out?

[pleegwat]

Only if you know in advance you're not going to receive red wood.

[Jap2.0]

Only if you know in advance you're not going to receive red wood.

Why would that matter?

[McDuff]

They're two different signals. We're not talking about outputting each from the wire with 1000 wood on it. We're talking about measuring a signal on one wire and using it to make decisions about signals on another wire. In order to do that at present you need isolating buffers and chains of combinators.

[Jap2.0]

They're two different signals. We're not talking about outputting each from the wire with 1000 wood on it. We're talking about measuring a signal on one wire and using it to make decisions about signals on another wire. In order to do that at present you need isolating buffers and chains of combinators.

Sorry - I forgot about the each part. That makes sense.

[MeduSalem]

When I first argued that it is a mistake to automatically combine all input signals from red and green wires even before the Circuit Network update came out... I remember people said "but there is no need to seperate green/red signals for inputs".

Now this thread after all the time.

...

8pRK6sW.jpg (129.09 KiB) Viewed 5984 times

That said... +1

[steinio]

Just don't mix red and green signals before working with it.

State of the art is to use red for requests and green for provider in the main power lines. Necessary signals can be split of or transmitted on the cables with combinators.

Honestly i don't see a reason to implement this.

[mrvn]

Just don't mix red and green signals before working with it.

State of the art is to use red for requests and green for provider in the main power lines. Necessary signals can be split of or transmitted on the cables with combinators.

Honestly i don't see a reason to implement this.

Simple. You want to know how many requests are not covered by provides. So you want each red - each green.

[<NO_NAME>]

Just don't mix red and green signals before working with it.

State of the art is to use red for requests and green for provider in the main power lines. Necessary signals can be split of or transmitted on the cables with combinators.

Honestly i don't see a reason to implement this.

You know, not everyone use circuit network in the way you are. I for example have so many different signals that I had to build multiplexer/demultiplexer to handle that.

I would like so much to be able to do

Code: Select all

100 * all-green / all-red

where green are amounts of items I have and red is capacitance of my magazines.

[McDuff]

Lots of people have explained why this kind of change a) opens up new ways of working, b) makes certain common tasks doable without having to resort to multi-combinator setups. "I can do what I want already" doesn't really answer this.

[steinio]

Lots of people have explained why this kind of change a) opens up new ways of working, b) makes certain common tasks doable without having to resort to multi-combinator setups. "I can do what I want already" doesn't really answer this.

Yes this was a bit egocentric :p

The question is, do we need a new combinator because it's currently impossible or is this all possible now, but needs more effort or space or components?

If this suggestion get's implemented i would probably use it, but so far i would look for a vanilla solution.

[mrvn]

Lots of people have explained why this kind of change a) opens up new ways of working, b) makes certain common tasks doable without having to resort to multi-combinator setups. "I can do what I want already" doesn't really answer this.

Yes this was a bit egocentric :p

The question is, do we need a new combinator because it's currently impossible or is this all possible now, but needs more effort or space or components?

If this suggestion get's implemented i would probably use it, but so far i would look for a vanilla solution.

It is impossible to do each green / each red except with one combinator per signal that you specifically program for that signal. Which a) makes it impossible to create a generic circuit that is reusable or keeps working when signals are added and b) who wants to put down 200 combinators and program each of them for a different signal?

Yes, we do need a new combinator. The sad thing is that the game engine already perfectly supports all this. The circuit connection interface has separate red and green wires in and out. It would be a trivial change in the c++ code to add each green and each red meta signals even if you don't want to change the GUI for full blown color filtering.

[bushbaby1234]

+1

[Illiander42]

When working with things like LTN, where you have a large number of different signals on the same wire, sometimes you want to filter out a selection of signals.

What I think would be a really simple (and powerful) way of doing this would be to have a way for arithmetic and decider combinators to say "compare each signal on the red input, to each signal on the green input".

For instance: Multiply each signal on the red input by each signal on the green input: What this would do is allow you to filter in only the signals you want from one input, by only inputing them on the other input (because non-existent signals are treated as zero). It would also let you convert a count of stacks into a count of items, by feeding in all the item stack sizes on one input, and the stack counts of the things you want on the other input.

I could probably think of lots more uses for this feature. Currently this is only possible with arrays of combinators, and only because there are a finite number of signals.

[Impatient]

Come on over

viewtopic.php?f=6&t=56890

[Koub]

[Koub] Merged new topic into older topic with same suggestion.

[Sad_Brother]

Would we have any dev's opinion about this?

[mrvn]

When working with things like LTN, where you have a large number of different signals on the same wire, sometimes you want to filter out a selection of signals.

What I think would be a really simple (and powerful) way of doing this would be to have a way for arithmetic and decider combinators to say "compare each signal on the red input, to each signal on the green input".

For instance: Multiply each signal on the red input by each signal on the green input: What this would do is allow you to filter in only the signals you want from one input, by only inputing them on the other input (because non-existent signals are treated as zero). It would also let you convert a count of stacks into a count of items, by feeding in all the item stack sizes on one input, and the stack counts of the things you want on the other input.

I could probably think of lots more uses for this feature. Currently this is only possible with arrays of combinators, and only because there are a finite number of signals.

As a note: you can multiply red * green with a few combinators. But not red / green or others.

[Illiander42]

When working with things like LTN, where you have a large number of different signals on the same wire, sometimes you want to filter out a selection of signals.

What I think would be a really simple (and powerful) way of doing this would be to have a way for arithmetic and decider combinators to say "compare each signal on the red input, to each signal on the green input".

For instance: Multiply each signal on the red input by each signal on the green input: What this would do is allow you to filter in only the signals you want from one input, by only inputing them on the other input (because non-existent signals are treated as zero). It would also let you convert a count of stacks into a count of items, by feeding in all the item stack sizes on one input, and the stack counts of the things you want on the other input.

I could probably think of lots more uses for this feature. Currently this is only possible with arrays of combinators, and only because there are a finite number of signals.

As a note: you can multiply red * green with a few combinators. But not red / green or others.

Can you provide a blueprint for that? Honestly curious how you do it without needing a combinator for each signal.

[mrvn]

When working with things like LTN, where you have a large number of different signals on the same wire, sometimes you want to filter out a selection of signals.

What I think would be a really simple (and powerful) way of doing this would be to have a way for arithmetic and decider combinators to say "compare each signal on the red input, to each signal on the green input".

For instance: Multiply each signal on the red input by each signal on the green input: What this would do is allow you to filter in only the signals you want from one input, by only inputing them on the other input (because non-existent signals are treated as zero). It would also let you convert a count of stacks into a count of items, by feeding in all the item stack sizes on one input, and the stack counts of the things you want on the other input.

I could probably think of lots more uses for this feature. Currently this is only possible with arrays of combinators, and only because there are a finite number of signals.

As a note: you can multiply red * green with a few combinators. But not red / green or others.

Can you provide a blueprint for that? Honestly curious how you do it without needing a combinator for each signal.

For example pairwise multiply using squares: viewtopic.php?f=193&t=61490

It's limited by range though. Not suitable for large numbers.