Please, PLEASE make circuit connection behavior configurable per wire

[HEROgoldmw]

Really like how we can select the G and R wire on combinators. Makes it easy to manage which inputs we want to read or process.

Now imagine we can do that on other entities. For example assembler.

Connect a green and red wire, and the Red wire read's the assemblers recipe ingredients,
and the green wire read's its current contents.
This way its easier to separate and control how we want to handle signals

This could also allow requester chests to both read contents and set requests by having either one on a different wire colour.

Roboports, Reading the logistic network contents, can happen on one wire,
while using the same roboport to read the network requests on the other wire.
Same for the rocket silo.
Would allow for reading the contents, and reading orbital requests at the same time.
One on red, other on green wire.

I've merely given some examples, and my hopes are that this post gives enough insight into the suggestion.

[SauerkrautPudding]

Agree 100%
it would make my engineer-life a lot easier.
Assemblers, belts, inserters. Probably also smelters if they apply the same logic as assemblers (set recipe, trash slots), but I don't know if that destroys current omni-smelter designs...

[Fanatic]

And train stations...

Trying to set limit and/or priority while also sending item requests to the train circuit network condition to tell it to go pick up a specific item took a lot of jury-rigging. If the train gets a L or P as the "item" it needs to pick up it confuses the train and it gets stuck.

[Koub]

[Koub] Merged several threads with similar suggestions.

[Hares]

[Koub] Merged several threads with similar suggestions.

To be honest, Koub, my suggestion was a bit different as it was too specific referring exclusively to selectir comb.

[Koub]

To be honest, Koub, my suggestion was a bit different as it was too specific referring exclusively to selectir comb.

Indeed, but I decided to merge it nonetheless : if the more global suggestion is implemented, yours will inherit the implementation as well.

[Fharkas]

Good to hear this is on the list of future implementation already.
With so many items now having multiple built-in functions that reads and sends, it will be nice to be able to do both!

[DorianTheFactorian]

+1

I am taking everything out of the cargo landing pad into provider chests so I can read how much I have, then doing combinator logic to determine the requests into the cargo landing pad.

[Hares]

I am taking everything out of the cargo landing pad into provider chests so I can read how much I have, then doing combinator logic to determine the requests into the cargo landing pad.

You can read network's content from the roboport. Landing pad pushes its inventory to the network.

[DorianTheFactorian]

I am taking everything out of the cargo landing pad into provider chests so I can read how much I have, then doing combinator logic to determine the requests into the cargo landing pad.

You can read network's content from the roboport. Landing pad pushes its inventory to the network.

Yes, but that requires that you don't have any products stored elsewhere in log-net for an accurate reading.

[spectria.limina]

I'd like to suggest an alternative implementation of the same goal.

Instead of adding red/green UI everywhere, make "red", "green", and into modifiers that apply overtop existing signals, selectable in the signal selection UI, in the same way that you can apply quality overtop an existing signal.

This would mean much less UI, much less UI code work, and no additional maintenance work when new circuit behaviour is added. It would just be built in to everywhere where a signal is selected.