Please, PLEASE make circuit connection behavior configurable per wire

[ActionJackson]

With the new combinators we can specify what wires we want to operate on. I would REALLY like to be able to set the "Mode of operation" on a circuit connection PER WIRE

I want to set requests with one wire, and read contents on another. Let me give you a use case that makes sense now with SA...

10-25-2024, 14-59-18.png (313.97 KiB) Viewed 813 times

Here in my Cargo landing pad I have a circuit set to read my network, and set requests based on what it's missing. This is to make sure my platforms aren't sending more than I need, which in turn sends the platform(s) to various planets for things as needed. Easy enough.

Problem is, sometimes they come back with OTHER stuff, like waste, that I want to take and use on Nauvis. This fills up my Landing pad with unnecessary trash that I'd like to put in an active provider chest and figure out a use for. I can use my requester signal as a blacklist for an inserter, but if I have more than 5 signals going to that inserter this idea does not work. If I knew that was in the landing pad, I could compare the signal against what I WANT in the chest, and then remove anything else I don't want, keeping the Landing pad free for maximum use.

With my current limitations I have no way to identify unwanted items in a container and also set the requests. I have 2 wires so that could be able to be set in the GUI. Now that we have control in combinators over what wires should do things I think this is a reasonable request.

My only option is to dump everything out into the network and while that does work, it does not work if I want to keep certain items in a certain container AND ONLY those items. This would be useful for smarter trains or any other application that specific item types and amounts matters.

[Erfar]

That even more important for assemblers where you can have at the same time "read content" and "read ingiridints" but can't separate those signals

[mrvn]

TL;DR

Eliminate the multiple choice options in entities with circuit interface by giving the user a choice of wire color instead and add wire color selection to all enable/disable choices.

What?

With 2.0 the arithmetic and decider combinators have added a wire color choice to their interfaces. This has huge benefits for combinator constructions and allow arithmetic operations that have so far been impossible to do. But all other entities do not share this improvement:

Choice-of-wire-color-2.0.png (3.35 MiB) Viewed 803 times

What I am suggesting is to extend the same idea to all circuit connected entities. This will change four things:

1. (green box) Enable/disable choices use the same mask as the decider combinator allowing more freedom but also allowing one color to be used for the decision and the other for input/output.
2. (red box) Eliminate the multiple choice selection in entites with multiple output or input options by replacing it with a choice of wire color. Conflicting choices could still require different colors are selected for the conflicting options (i.e. Read contens vs. Set request).
3. (red bar) Eliminate several on/off checkmarks as toggling colors on/off already covers that.
4. (red box) Allow constant combinators to output different signals on the red and green wire for each group.

Choice-of-wire-color-suggested.png (3.35 MiB) Viewed 803 times

I also suggest moving the enable/disable box for logistic chests to the top to match every other entity with enable/disable, a purely cosmetic change.

Why?

It's strange that the decider combinator has a more powerful comparison functionality than the enable/disable boxes. This can be dealt with by placing a decider combinator next to the entity and then enable/disable on the output of the decider combinator. For complex decisions with and/or groups of comparisons this should still be the way to go.

But the problem is deeper. In the past I've asked why for example requester chests can't both "Read contents" and "Set request" and one answer I was given was that the read contents would then set requests making this unworkable. I assume the same would be a problem with enable/disable and any option that outputs a signal. By adding the color choice for enable/disable this allows using one color there and the other color to output signals from the entity.

The benefits go even further. Many entities have input/output options where multiple choices are interesting at the same time. In some cases one can simply place two entities, e.g. roboports to read two choices. But that is the exception. By adding a color choice this eliminates the need to select one of many options, eliminating all the radio buttons. Entities can then output each choice on a different color. Or use one color to set an option while simultaneous output signals on the other color without them interfering.

The train stops and interrupts would also benefit from this giving the user more options. The enable/disable option kind of conflicts with "Send to train" as the signals used to enable/disable the stop now also trigger interrupts. By using for example red to enable/disable the stop and sending green to the train there is no risk of accidentally triggering an interrupt in the train.

Things I forgot:

• inserter
• belts
• "Circuit condition" in train schedules and interrupts
• Gates

They follow the same pattern as the rest so use your imagination of how the red/green choices would look there.

PS: The "Read signal" checkmark on signals also disappears in favour or the color selection.

[SakretonTheSecond]

It would be very nice to be able to select which wire to use for input and output signals in circuit connections, like in the new combinators just for machines.

11-01-2024, 15-26-49.png (262.02 KiB) Viewed 842 times

Something like this.

It would be even better if we could choose this everywhere we can use Circuit Connections.

I Created this Post because of an existing Reddit Post
Courtesy to u/NeoVortexUltimate for allowing me to use their image :>

[clarity]

Fwiw I don't recall combinators allowing you to choose which wire to use for output. They allow you to choose which wires to use for inputs. Of course they could be made more useful too..

[LuziferSenpai]

Hey,

it would be awesome if we could get a R/G selection for all the different control behaviours, like in the decider combinator.

It would make building a circuit much easier and cleaner.

Greetz,

Luzifer

[Koub]

[Koub] Merged into an older thread with the same suggestion.

[Viidi]

I want to set filters, for example, with a green wire, and read the contents to red.
This will help a lot if you need to set filters and read multiple inserts in a single group.

Using a combinator for each insert is very expensive, and also gives a delay of 1 tick.

Sorry for my English.

[Disparity]

Hi there!

Many buildings have 2 options to interact with circuits network: read state, receipt, content, etc and control building according to signals from circuits network.

Right now the both ways work with the both networks, it is a little bit inconvinient just because it spoils networks signals and forces to use additional buildings (sometime) to not spoil whole network.
Sometimes it isn't usable, for example you have assembling machine and you want to read current content, and to read recipe components. Right now you cannot do it easily, because signals are the same and mixed.

The proposal is to would be nice to have possibility to choose red or green for each item in circuit network dialog of buildings (assembling machines, inserters, train stops, and everything else that can be connected to circuit network). This has done for decider combinator(for example) and it is very convinient.

Thanks.

[Koub]

[Koub] Merged several threads with the same or very similar suggestions.
Another closely related is here : viewtopic.php?f=6&t=117032 (be allowed to read inputs AND outputs from a machine at the same time, and sent them to Red/Green separately)

[Muche]

From viewtopic.php?p=632506#p632506:

We have an internal proposal to make it configurable almost everywhere from/to which wire you read/write. So you could output to red and read from green for example.

But this is not a trivial change, and because of all the other work we need to do, we are planning to do this for the version 2.1.

[hitzu]

From viewtopic.php?p=632506#p632506:

We have an internal proposal to make it configurable almost everywhere from/to which wire you read/write. So you could output to red and read from green for example.

But this is not a trivial change, and because of all the other work we need to do, we are planning to do this for the version 2.1.

Good news

[danbopes]

From viewtopic.php?p=632506#p632506:

We have an internal proposal to make it configurable almost everywhere from/to which wire you read/write. So you could output to red and read from green for example.

But this is not a trivial change, and because of all the other work we need to do, we are planning to do this for the version 2.1.

Good news

I hope this gets implemented. This was my biggest gripes (Besides spoilage level not being able to be read on circuit networks)

[Hares]

TL;DR

Selector combinator should have checkmarks for which wire to choose from, for all modes, similar to other combinators.

Why?

Currently, if you use non-constant selector for "Select Input" & "Quality transfer" modes of work, the selector signal is reduced from the sources as if it was not there, so you can't get it on the outputs. Also, it's inconsistent with the other combinators.

[hitzu]

From viewtopic.php?p=632506#p632506:

Good news

I hope this gets implemented. This was my biggest gripes (Besides spoilage level not being able to be read on circuit networks)

There's a lot more to improve in circuit network: many machines can't be toggled on/off still, can't read nutrient fuel value in biochambers, temperature value in boilers and heat exchangers, can't read construction robot requests, electricity stats are unavailable too except the charge level, weather effects, enemies around, pollution level and alternate mechanics as well, displays are not flexible enough and require a lot of additional combinators to do such basic things as showing simple numbers like nixie tubes mod, can't connect to splitters and set a negative filter to them etc

[Soul-Burn]

Adding my +1 to this.

I wanted to use the asteroid catcher both for "read contents" to utilize the big buffer on it, and "set filters" to make it stop working when the system is loaded. When using just one catcher, this is easy. When trying to use many, this requires a combinator for input and another for output per catcher, to isolate reading from writing - otherwise one's contents would set the filters on another catcher.

The ability to choose R or G would make this much easier to do.

[mako00]

The alternative that e.g. Space Exploration uses is to have more than one wire connection point on buildings, e.g. one for control inputs and one for readouts (notably the spaceship console).

This feels a bit more tangible and intuitive (Factorio already has enough menuing as it is) imo.

[LeftyRighty]

omgomgomgomg please please please... just spent way to long wrapping my head around how to elimitate unwanted signals with arithmetic inversions and it makes things look so messy when you just need "read contents" on one circuit and "send instructions" on the other

[Sworn]

Yes, +200

Be able to read an inserter or belt, while also setting its condition without interference, since today, it reads and use the value to the condition at the same time, begin able to set which wire will be used for condition/reading, get rid of this issue.

Was annoying as hell before space age, but there was not separation between red/green, now that it was implemented, one would just expect to use it in other places as well

[Xellnix]

beside the named issue, currently you can only use "quality transfer" if you know which signal is going in with the quality, if we had the option to set the input to "red" or "green" we could order the selector to ignore the signal going in and just care about the quality a signal has at one of the connected wires, so that would enable the use for facilitys that not only switch quality while producing, also switch the recipe at all