Output R/G settings for buildings

[Karto]

+1 for 2.1

[Rodonies]

+1, I was actually looking for a way to do this. I also suggest adding an R/G channel selector for inputs like "Set Recipe"

[perahoky]

i need this feature too.

wwhen i connect a ssembler to red and green and use set recipee and read ingrdients, it sets the recipe from the read ingredients.

i want to build multiple asemblers which get their recipe from circuit network and send their ingredients to another network.

i need to select R / G like in combinators for assemblers to differentiate signals from "circuit network assembler feature" like set recipes / read ingredients.

in my opinion this ia a bug because it renders the feature unusable when used both.

[thedoh]

instead of making a new post, I will add on my take on this, I made a graphic

Assembler Circuit Connection.png

This is great, though I would offer one minor suggestion for UI/UX: Just like how the circuit / logistic network connection information are hidden until you explicitly connect a wire or configure the logistic network stuff, the red/green wire could be a hidden UI element until both a red and a green wire are connected. This could avoid overwhelming the screen until you need it.

[macdjord]

instead of making a new post, I will add on my take on this, I made a graphic

Assembler Circuit Connection.png

This is great, though I would offer one minor suggestion for UI/UX: Just like how the circuit / logistic network connection information are hidden until you explicitly connect a wire or configure the logistic network stuff, the red/green wire could be a hidden UI element until both a red and a green wire are connected. This could avoid overwhelming the screen until you need it.

I'd suggest doing it the same way decider and arithmetic combinators do: it always shows both checkboxes, but if a wire of the given colour is not connected then that checkbox is greyed out.

[gdubrocks]

Bump for 2.1

[boskid]

Bump for 2.1

Would you like to add anything to this bump given that a 2.1 experimental was released in the meantime?

[gdubrocks]

Would you like to add anything to this bump given that a 2.1 experimental was released in the meantime?

Yeah, I am on the 2.1 experimental patch, and the new wire features are great but they still leave me wanting.

For example the reason that many people wanted multiple wires in the first place was to do two separate outputs from the same machine. A very common use case is on assemblers where you need to know how many materials are still needed to complete a receipe. This is a very useful behaviour on spaceships with limited belt space, on automall designs, and for sushi of all types. It's possible to achieve it now, but is extremely clunky and requires multiple machines, or multiple combinators which are manually set for each assembler.

If you read the previous comments on this thread, almost every single person is asking for the same functionality I am mentioning, and the new split wire feature implementation doesn't make it any easier.

The current wires cannot output two different colors from an output, but there is another way to achieve the same functionality if you don't want to allow two outputs from the same machine on different wires.

See viewtopic.php?t=134720 for more details.

[GN89]

Maybe we could add an option to the Selector Combinator to output ingredients based on the selected recipe? Or, if an item signal is passed as an input, it could output its ingredients in binary format (for alternative recipes), where each bit position represents one of the recipes? Of course, this would require adding a detailed tooltip explanation.

While this can already be achieved via circuitry, it requires manually building extensive lookup tables. However, this might be slightly off-topic here, so maybe it's better to move this to a new "Ideas and Suggestions" thread.

[GN89]

Maybe we could add an option to the Selector Combinator to output ingredients based on the selected recipe? Or, if an item signal is passed as an input, it could output its ingredients in binary format (for alternative recipes), where each bit position represents one of the recipes? Of course, this would require adding a detailed tooltip explanation.

While this can already be achieved via circuitry, it requires manually building extensive lookup tables. However, this might be slightly off-topic here, so maybe it's better to move this to a new "Ideas and Suggestions" thread.

Actually, I might have rushed that a bit in my previous post — a binary bitmask would only give us a list of required ingredients (as flags), but not their actual quantities.

To expand on this idea, we could split the functionality using the dual outputs of the combinator:
* Red output: Outputs the binary bitmask of the required ingredients (as mentioned before).
* Green output: Outputs the exact quantities of those ingredients based on an input index signal.

This approach needs more refining, especially for cases where an item signal is passed as an input instead of a specific recipe, but it is definitely a direction worth digging into for advanced circuitry.

[nzer]

Bumping as well because I thought this is how the 2.1 changes were going to work, and it isn't. The fact that it's still impossible to send both contents and ingredients out of a machine at the same time in any useful way is an enormous oversight, in my opinion.

I mean isn't this the exact thing that prompted requests for better control over R/G wires in the first place? Being able to send inputs and outputs to certain wire colors is... fine, I guess, but all it really does is occasionally remove the need for a diode. It doesn't enable anything new the way being able to separate specific outputs would.

[macdjord]

Bumping as well because I thought this is how the 2.1 changes were going to work, and it isn't. The fact that it's still impossible to send both contents and ingredients out of a machine at the same time in any useful way is an enormous oversight, in my opinion.

I mean isn't this the exact thing that prompted requests for better control over R/G wires in the first place? Being able to send inputs and outputs to certain wire colors is... fine, I guess, but all it really does is occasionally remove the need for a diode. It doesn't enable anything new the way being able to separate specific outputs would.

Splitting input and output does allow a bunch of stuff that was simply impossible before. For instance, you can both read the contents of a requester chest and set its requests at the same time, or read the hand contents of an inserted without affecting its filters. Neither of these were possible before, even with an isolating combinatorial, since it was a device being affected by its own signal.

That said, allowing selection per wire is how I expected it to work myself, and it would enable even more options that are not yet possible.

[DOSorDIE]

I think the easiest way to get what the machine need is to have
"Read Contents" as minus
So ingredients - read contents = what the machine want
OR
No overfilling (so that the machine that want 10 iron ony get 10 iron and not filling it to 20+)

[worph]

Separating input from output is great.

But please let me select red/green for each output individually.

• OutputA -- [X] red | [ ] green
• OutputB -- [X] red | [X] green
• OutputC -- [ ] red | [ ] green
• OutputD -- [ ] red | [X] green
• etc.

[forint]

Was going to make another thread but this covers everything I would want.

Outputs of Decider combinators having an option of choosing the channel would be so fantastic. IE, if true, pass constant 1 signal to green and input value to red. In a space platform, the constant signal could be used to filter grab astroid chunks for example while the input value signal on red could be used to do further computation to figure out astroid reprocessing.

Hell, I'd even like constants to be able to output different values to different channels. Example, min values on red, max values on green. Just feels really clean.

It would allow for more compact builds and increase readability.

[worph]

Just noticed how they didn't change the rocket silo at all for 2.1.
The fact that this building (one of the most important ones in the entire DLC) has only radio buttons to either:
- read content
or
- read orbital requests
really highlights how important a change like this is. And how ridiculous the game is without it.
You frequently want to read both at the same time, but you also need them separated. I cannot wrap my head around this.


It should really receive an award how how bad it's circuit interface is:

grafik.png (34.03 KiB) Viewed 168 times

[macdjord]

Just noticed how they didn't change the rocket silo at all for 2.1.
The fact that this building (one of the most important ones in the entire DLC) has only radio buttons to either:
- read content
or
- read orbital requests
really highlights how important a change like this is. And how ridiculous the game is without it.
You frequently want to read both at the same time, but you also need them separated. I cannot wrap my head around this.


It should really receive an award how how bad it's circuit interface is:
grafik.png

Honestly, the rocket silo is the one place where this doesn't matter very much, because 'Read orbital requests' is a global value; all silos on a given world will output the same value for it. If you need to know both a given silo's contents and the current orbital requests, you can just read the contents of that silo and get the requests from another one. Being able to get both from the same silo would occasionally be convenient, but it doesn't enable anything that isn't already possible.

[worph]

Honestly, the rocket silo is the one place where this doesn't matter very much, because 'Read orbital requests' is a global value; all silos on a given world will output the same value for it. If you need to know both a given silo's contents and the current orbital requests, you can just read the contents of that silo and get the requests from another one. Being able to get both from the same silo would occasionally be convenient, but it doesn't enable anything that isn't already possible.

If we were talking about an additional constant combinator or something similar, I would agree.
But especially in the earlier situations on Gleba for example it's not only expensive to build additional rocket silos, it's also incredibly huge and clunky, just to read orbital requests.
I suggested in another thread move reading those informations to the radar dish. This might work here, too. Which would make separating R/G yet more useful.

[macdjord]

If we were talking about an additional constant combinator or something similar, I would agree.
But especially in the earlier situations on Gleba for example it's not only expensive to build additional rocket silos, it's also incredibly huge and clunky, just to read orbital requests.
I suggested in another thread move reading those informations to the radar dish. This might work here, too. Which would make separating R/G yet more useful.

If you only have one rocket silo in your entire base, what are you doing with it where reading its contents is actually useful?

• The obvious thing to do if you only have one silo is to enable automatic bot-based loading, in which case you don't need to know the contents since the bots handle all that
• If you are only exporting one item, you could load it with inserters. In which case, again, you don't need to know the contents, since you can just fill the silo until full, at which point the inserter stops automatically.
• If you are exporting a small number of different items, you could load them with inserters, using circuit logic to enable them based on orbital requests. In which case, once more, you don't need to read the contents, since you can just fill the silo until it launches, and use an inserter with a blacklist filter to remove anything left over from a previous launch.

Frankly, I can only see a couple scenarios where reading silo contents is useful:

• If you have multiple inserter-loaded silos dedicated to launching the same item, then reading their contents would let you know how many of them are fully loaded and ready to launch.
• If you want to build some sort of circuit-controlled inserter-based loading system for launching mixed-cargo rockets, reading the current content is obviously vital.

Neither of these is something that is going to happen in a small base with only a single silo.

[worph]

Bots don't respect freshness/spoilage.
With one rocket silo for agricultural science you want to know:
a) when a ship rolls around to pick it up, only then do you want to load it using inserters with fresh first.
b) that same rocketsilo can do different things, too, like send up bioflux. But I like to program some circuit logic to make sure there is nothing else in the silo, or different types of things at the same time, whatever.
Your suggestions was to build another rocket silo, I don't think that is reasonable.

There are ways around it, but I wouldn't consider that a good argument for why I can't read both informations from the same giant entity. Especially seeing how we can separate r/g on in/out now. It should be easy to separate read content/read orbital requests into R/G on rocket silos in a similar fashion.