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.

Edit: making this a separate thread since it's a new idea.

[Sworn]

+1

It would pair really well with using logic wires with rocket silos, as suggested on this message: viewtopic.php?p=641449#p641449 (Page 2 from Cerberus, if the link doesn't work)

[mrvn]

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.

Edit: making this a separate thread since it's a new idea.

How would that work for "read contents"? There is no signal you pick where you could add a color modifier. It's just a color selection.

For most, if not all, situation where you select a signal I really don't care about the color. By picking a unique signal the color doesn't matter. It's when you have no control over the signal that the color matters.

[rapus]

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.

Edit: making this a separate thread since it's a new idea.

How would that work for "read contents"? There is no signal you pick where you could add a color modifier. It's just a color selection.

For most, if not all, situation where you select a signal I really don't care about the color. By picking a unique signal the color doesn't matter. It's when you have no control over the signal that the color matters.

It indeed would easily be possible! Upgrade the "read"-entries to also filter for channels. Ordinary "read" will become "read everything" which is basically "everything" signal in the read filter, that could be preselected when enabling read. It's even an extension option to make it only read certain items into the appropriate wire! Then, in the signal selection, next to the quality modifiers there could be the channels, again, both selected by default. So the signal selection actually entirely defines the exact signal channel it interacts with. Wire color, quality level, item. Regarding how to show it in the UI, color the background of the item according to the wire color. Or the standard grey if both colors are selected. As there:

11-20-2024, 02-16-07.png (164.79 KiB) Viewed 166 times

Left: Checkboxes for red/green wire channel. Right: read filter dumps "everything" into the "green" cable and, for enabled/disabled, compares "red circuits" from the "red" cable to the "red circuits" from the "green" cable. (Numbers shown don't make much sense, but idea is conveyed anyway I guess)

Shortcuts could be added to change wire or quality selection without even opening the signal config picker. For example using the ordinary quality selection (alt+wheel) on hover. For the circuits, clicking it with the green/red cable selected could toggle the red/green checkboxes without opening the dialog. This approach could perfectly extend to all points where signals are used. Additionally, for the color restricted people, the icons for red/green wire (which resemble r/g since 2.0.20, with r being a folded wire ) could be added to the top left corner (as top right and bottom right are already reserved for trash/request amounts)

[mrvn]

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.

Edit: making this a separate thread since it's a new idea.

How would that work for "read contents"? There is no signal you pick where you could add a color modifier. It's just a color selection.

For most, if not all, situation where you select a signal I really don't care about the color. By picking a unique signal the color doesn't matter. It's when you have no control over the signal that the color matters.

It indeed would easily be possible! Upgrade the "read"-entries to also filter for channels. Ordinary "read" will become "read everything" which is basically "everything" signal in the read filter, that could be preselected when enabling read. It's even an extension option to make it only read certain items into the appropriate wire! Then, in the signal selection, next to the quality modifiers there could be the channels, again, both selected by default. So the signal selection actually entirely defines the exact signal channel it interacts with. Wire color, quality level, item. Regarding how to show it in the UI, color the background of the item according to the wire color. Or the standard grey if both colors are selected. As there:
11-20-2024, 02-16-07.png
Left: Checkboxes for red/green wire channel. Right: read filter dumps "everything" into the "green" cable and, for enabled/disabled, compares "red circuits" from the "red" cable to the "red circuits" from the "green" cable. (Numbers shown don't make much sense, but idea is conveyed anyway I guess)

Shortcuts could be added to change wire or quality selection without even opening the signal config picker. For example using the ordinary quality selection (alt+wheel) on hover. For the circuits, clicking it with the green/red cable selected could toggle the red/green checkboxes without opening the dialog. This approach could perfectly extend to all points where signals are used. Additionally, for the color restricted people, the icons for red/green wire (which resemble r/g since 2.0.20, with r being a folded wire ) could be added to the top left corner (as top right and bottom right are already reserved for trash/request amounts)

That's basically asking for a new feature for read content like option to be able to choose what signals to read as one part. The other part is just cosmetic, to have the R/G checkboxes instead be background color behind the signal and to be selected nested one level deeper. Too much stuff feels to be nested deep now to me so I'm not sure about showing stuff down deeper is a good idea.

Both of that I would consider separate ideas. They modify existing behavior of how signals and signal colors are picked in general and don't really have anything to do with the feature request that you can actually pick a color where now you can't. Feel free to open separate issues for that.

[rapus]

[...]
That's basically asking for a new feature for read content like option to be able to choose what signals to read as one part. The other part is just cosmetic, to have the R/G checkboxes instead be background color behind the signal and to be selected nested one level deeper. Too much stuff feels to be nested deep now to me so I'm not sure about showing stuff down deeper is a good idea.

Both of that I would consider separate ideas. They modify existing behavior of how signals and signal colors are picked in general and don't really have anything to do with the feature request that you can actually pick a color where now you can't. Feel free to open separate issues for that.

I'd rather see it as proposal for a personally preferred UI design for the HERE requested feature. Which shines with extensibility to additional features, if wanted.

Re: deep nesting. By adding shortcuts, like clicking with wire, the configuration doesn't require going deeper. If people don't rely on shortcuts, that's a different story where nesting becomes necessary.

Re: but that's a new feature. If the only possible selection for the read-signal-picker is "everything" then showing that is just of cosmetic nature without any logic implementation or feature changes. Only difference would be that we'd have a generalized concept and place for where to pick the wire colors without having to scatter checkboxes all over the place.

Idea of generalization/abstraction: If every place that interacts with the circuit network should be able to pick the color of the wire, then, from a point of data organization, the color should be picked with the signal within a unified UI instead of seperately everywhere where a signal is picked. If they show up at the same places seperately all the time, move it to a common UI to declutter the top level but keep it accessible through intelligent shortcuts. Basically the same argumentation as for logistic groups. Shows up at multiple places identically? Generalize it and make it easily accessible. (->Matters of UI design quality)

Requesting read-output filtering would be a new feature. Which wasn't the point. UI design was the point. (Even though "filtering channel color" technically also is read-output filtering.)

[mrvn]

Re: deep nesting. By adding shortcuts, like clicking with wire, the configuration doesn't require going deeper. If people don't rely on shortcuts, that's a different story where nesting becomes necessary.

Clicking with a wire to change a signals color seems interesting. But wires themself are items/signals too and clicking a signal selector box with an item picks the corresponding signal. So it would normally change the signal to red/green wire, not change the color of the signal. Selecting a red wire signal on the green wire might be a bit dificult with the "click with a wire" shortcut.

Re: but that's a new feature. If the only possible selection for the read-signal-picker is "everything" then showing that is just of cosmetic nature without any logic implementation or feature changes. Only difference would be that we'd have a generalized concept and place for where to pick the wire colors without having to scatter checkboxes all over the place.

Idea of generalization/abstraction: If every place that interacts with the circuit network should be able to pick the color of the wire, then, from a point of data organization, the color should be picked with the signal within a unified UI instead of seperately everywhere where a signal is picked. If they show up at the same places seperately all the time, move it to a common UI to declutter the top level but keep it accessible through intelligent shortcuts. Basically the same argumentation as for logistic groups. Shows up at multiple places identically? Generalize it and make it easily accessible. (->Matters of UI design quality)

Requesting read-output filtering would be a new feature. Which wasn't the point. UI design was the point. (Even though "filtering channel color" technically also is read-output filtering.)

The R/G checkboxes are a generalized concept. Or rather they are the current UI interface to the concept of picking a wire color. So no, you aren't proposing a new concept but a new UI interface for an existing concept.

My suggestion is that in every place that interacts with the circuit network the wire color should be selectable. The proposed UI was the "R/G" checkboxes used in existing places that have wire color selection. That's unifies the circuit network capabilities which this suggestion is about. That's the generalization/abstraction proposed here.

So yeah, still considering that a different feature request. And I'm not saying your idea is bad. It just is a different idea. Both can be implemented, either no neither. So they should be separate threads in the ideas board. The idea of having a filter for read XYZ selections has merit too. So please do start new threads for them so the ideas don't get lost in this thread.

[SLB]

Since version 1.0, there has been a clear demand for logistic chests in large-scale logistics.
It's surprising that the Space Age update still lacks this feature.