Friday Facts #384 - Combinators 2.0

[Qon]

I was wondering actually, since the wire connection logic has been rewritten, do combinators keep their connections when 'cut & pasted'

The behavior of red/green wires when pasted will not change. Obviously the connections within a blueprint are kept, now and then.

Is this confirmed somewhere?

My confirmation is good enough.

Combinators losing logic wires from blueprints just because they rewrote the engine code that handles electric wires is beyond silly. Why would they introduce game corrupting bugs on purpose!?!? Are you trolling?
Do you think the 2.0 update will remove all inserters from your blueprints as well? Have you confirmed this to not be the case? Will you make sure inserters aren't removed from you blueprint library before updating?

Oh, I thought the question was if wire connections between combinators that are cut and other entities that are not cut would be restored when pasted.

I specified "within" a blueprint, and you responded to me. But the post I responded to was unclear.

Wires lost when cutting being restored would be a neat feature though, if it was easy to not get that behavior. But if it only happened on cut and not other blueprinting action (like create blueprint or copy) then keeping wires to outside entities if with reach when placed would be an awesome feature. Would finally be possible to move entities around then in vanilla, and even multiple entities at once which picker dollies can't.

[吴言_wwuyan]

Here it is! (beep boop)

https://factorio.com/blog/post/fff-384

Since the solver has a custom text area for blueprint users to understand its purpose.Can the conveyor belt also have the same function to mark the input and output of the conveyor belt in the blueprint?

(Machine translation may have errors, please forgive me)

[TheRaph]

I would like to have an option not only to select different outputs but also choose the channel (red or green) to output to.

This seems pretty pointless. Why would you want this?
If you don't want signals on green wire, just don't connect it.
If you want other data on green wire than red wire, make a separate combinator.

You've answered your question yourself.
"make a separate combinator" - to avoid this is what this update is about.

Most of the things (except for indexer) could currently be done, just by adding one or two or twenty-five of combinators. But too many combinators get messy very quick.
So I see a tendency of devs to compress overcomplicated multi-combinator-layouts to just a few combinators. Each of them are more capable than current combinators.
They also add option to set multiple outputs (in past you have to set an extra combinator for each).
So why should they not add an easy feature because you could fix it by adding a second combinator?

[epr]

Improving the combinators is great and all, but I still think they are not a good game mechanic. When you attempt to do anything a bit more complex, especially with recursive blueprints, it feels like trying to program in assembly. Just too tedious to even bother.

[Qon]

I would like to have an option not only to select different outputs but also choose the channel (red or green) to output to.

This seems pretty pointless. Why would you want this?
If you don't want signals on green wire, just don't connect it.
If you want other data on green wire than red wire, make a separate combinator.

You've answered your question yourself.
"make a separate combinator" - to avoid this is what this update is about.

Most of the things (except for indexer) could currently be done, just by adding one or two or twenty-five of combinators. But too many combinators get messy very quick.
So I see a tendency of devs to compress overcomplicated multi-combinator-layouts to just a few combinators. Each of them are more capable than current combinators.
They also add option to set multiple outputs (in past you have to set an extra combinator for each).
So why should they not add an easy feature because you could fix it by adding a second combinator?

No, I disagree. The update is not about making a combinator perform the actions of several combinator entities. The point is to add more powerful and easier to use features and interface. Less powerful combinators are also able to perform any computation, they are also Turing complete. But with a simpler feature set you need more of them. But a more powerful feature set is different from combining the entities, the new features don't require you to know how to do something with many simple v1.0 combinators to now do it in a few v2.0 combinators. We are getting somewhat higher level abstraction. But the entity count reduction isn't the primary goal, it's a side effect of making them more user friendly.

Having a combinator being made into something that invisibly (from overview) performs the operations of two unrelated combinators (but still both arithmetic, decider xor selector?) just makes the combinator network harder to read.

The gains are too minor also. I could get behind combining multiple combinators into one, I've asked for this with native support for Factorissimo-style combinators. But stopping at 2 is the worst of both worlds. You don't get any real benefit, you become too limited and you are now second guessing every combinator with two inputs and outputs wired, which is a big cost. And doing this to regular combinators makes this feature invisible unless you open the gui, unlike factorissimo-combinators which are a separate distinct entity that are clearly always a combination of combinators.

[Selvek]

Beautiful! I've always hated how non-intuitive it is to build something as simple as a basic logic gate. This is so much cleaner! And thank you for adding COMMENTS, CompSci101 teachers everywhere thank you.

One final improvement please - remove the extraneous red and green wires from the combinator sprites! It adds so much visual clutter that makes it harder to see where the *real* red and green wires are going.

[computeraddict]

Improving the combinators is great and all, but I still think they are not a good game mechanic. When you attempt to do anything a bit more complex, especially with recursive blueprints, it feels like trying to program in assembly. Just too tedious to even bother.

It's not programming in assembly, it's "programming" in souped up HDL. Combinators handily knock down most simple tasks if you know how to set up a truth table and reduce it. And complex tasks are just a bunch of simple tasks in close formation.

[Sad_Brother]

As we speak about Combinators and constants...
Sometime we need to know current value of game constants to tune factory better. The best example seems to be the stack inserter item limit. It increase with proper research and so we cannot hardcore it.
Please add some ability to use current value of such limits in combinators setup.

Best wishes!

[computeraddict]

As we speak about Combinators and constants...
Sometime we need to know current value of game constants to tune factory better. The best example seems to be the stack inserter item limit. It increase with proper research and so we cannot hardcore it.
Please add some ability to use current value of such limits in combinators setup.

Best wishes!

It wouldn't be global but you could build a do-nothing apparatus fairly easily that continuously tests it and outputs the result

[dstroth]

I would like to have an option not only to select different outputs but also choose the channel (red or green) to output to.

This seems pretty pointless. Why would you want this?
If you don't want signals on green wire, just don't connect it.
If you want other data on green wire than red wire, make a separate combinator.

Select to input data from the green line
and output data from the red line
This helps one-compartment entities like the blue and green boxes simultaneously perform circuit setup requirements and read their stores
This makes for a perfect drone unloading station, or circuit-controlled cache of green boxes.

I have no idea what you are talking about

They want to be able to simultaneously set the requests and read the contents of individual logistics chests ("blue and green boxes").

I've also wanted this capability before. This wouldn't necessarily require the ability to select the input and output color channels, but that is a likely solution. Another possible solution would be to give the logistics chests separate input and output ports, though there is currently no vanilla precedent for a 1x1 entity with separate inputs and outputs.

This could also apply to the new rocket silo (in manual mode), where we might have 3 different things we want to do via the circuit network:

1. read what is currently being requested by the orbiting space platform
2. read what items are currently loaded into the rocket
3. set what items the silo is requesting from the logistics network

(if this is actually supported, this would almost certainly require multiple circuit network connection points on the silo)

I agree that it isn't beneficial to be able to select the output color channel on any entity that already has separate input and output ports (like all combinators).

Improving the combinators is great and all, but I still think they are not a good game mechanic. When you attempt to do anything a bit more complex, especially with recursive blueprints, it feels like trying to program in assembly. Just too tedious to even bother.

It's not programming in assembly, it's "programming" in souped up HDL. Combinators handily knock down most simple tasks if you know how to set up a truth table and reduce it. And complex tasks are just a bunch of simple tasks in close formation.

Some of us rather enjoy programming in assembly and HDLs!

Yeah, combinators are much closer to HDLs like Verilog or VHDL than they are to assembly - though they are certainly all at a low level of abstraction.

It is interesting to me (as an electrical engineer) how many parallels there are in Factorio to real-world EE tasks, despite the devs not actually being EEs themselves. Laying out factories is very much like PCB layout - especially cheap 1-layer ones, where you only get jumper links to cross over other traces. Designing with combinators is extremely similar to synchronous digital logic design, albeit without all the helpful design tools - like simulators, waveform viewers, and automatic place-and-route tools.

[Feather]

I was wondering actually, since the wire connection logic has been rewritten, do combinators keep their connections when 'cut & pasted'

The behavior of red/green wires when pasted will not change. Obviously the connections within a blueprint are kept, now and then.

Is this confirmed somewhere?

My confirmation is good enough.

Combinators losing logic wires from blueprints just because they rewrote the engine code that handles electric wires is beyond silly. Why would they introduce game corrupting bugs on purpose!?!? Are you trolling?
Do you think the 2.0 update will remove all inserters from your blueprints as well? Have you confirmed this to not be the case? Will you make sure inserters aren't removed from you blueprint library before updating?

Oh, I thought the question was if wire connections between combinators that are cut and other entities that are not cut would be restored when pasted.

Because it was, in my mind CTRL+X CTRL+V has nothing to do with blueprints(I know it does, but ignore it for the sake of the use case), I was just working on some 'more annoying/complicated' logic, and I was getting annoyed that every time I wanted to reposition something I had to rewire it again

[mmmPI]

Because it was, in my mind CTRL+X CTRL+V has nothing to do with blueprints(I know it does, but ignore it for the sake of the use case), I was just working on some 'more annoying/complicated' logic, and I was getting annoyed that every time I wanted to reposition something I had to rewire it again

https://mods.factorio.com/mod/PickerDollies

Shift + arrow !

[Qon]

They want to be able to simultaneously set the requests and read the contents of individual logistics chests ("blue and green boxes").

I've also wanted this capability before. This wouldn't necessarily require the ability to select the input and output color channels, but that is a likely solution. Another possible solution would be to give the logistics chests separate input and output ports, though there is currently no vanilla precedent for a 1x1 entity with separate inputs and outputs.

I want that too. But you don't need separate input and output wire colors or ports. For the ability to send and receive at the same time the GUI just has to support enabling both modes at the same time.

It doesn't really matter if the box sends output on both wire colors, just don't wire the same color to anything else's input port. You can even read the output from the same wire color if you just filter away your signals that you sent in, or use the other wire color. Use different signal types for different operation and then there's no "mode collision".

Plenty of mods does it this way. Yes it's a bit janky, but it's better than not being able to do both reads and writes on the same entity.

[computeraddict]

It doesn't really matter if the box sends output on both wire colors, just don't wire the same color to anything else's input port. You can even read the output from the same wire color if you just filter away your signals that you sent in, or use the other wire color. Use different signal types for different operation and then there's no "mode collision".

The way the boxes' modes work you would always have the output feeding into the input unless you forced the input and output onto different colored networks. You couldn't have input nor output on both channels without feedback.

[dorthak]

Maybe this was addressed in the 13 pages of comments, but I couldn't find it.

For the selector combinator, "index" is a numerical value, right? If so, that's great, but not what I really want out of a selector combinator. Maybe there's one other mode that could be added to it? Something that takes one wire, with a whole bunch of signals on it (like the listing of a logistics network), and one (or more) signals on a second wire, and outputs the values of just those signals from the first wire.

Yes, this can currently be done, but it requires at least three combinators, and is kind of clunky (Add a huge number, like 1 million, to the second wire, use a comparator to select out signals over 1 million, subtract 1 million).

I think this is a common enough use case, and seems like it "belongs" in a selector combinator.

[TheRaph]

Having a combinator being made into something that invisibly (from overview) performs the operations of two unrelated combinators (but still both arithmetic, decider xor selector?) just makes the combinator network harder to read.

That is a definition based on your point of view.
Having a arithmetic combinator multiply "coal" by 3 and sending solution to red channel on "A" and to green channel on "coal", could be defined as one task or as two.
I can not spot the difference of the example in FFF: Sending "check-mark" = 1 AND "red-circuit" = input-count. This are also two tasks, which could be separated into two combinators.
Same as in my example but different outcome.

... , you become too limited and you are now second guessing every combinator with two inputs and outputs wired, which is a big cost. And doing this to regular combinators makes this feature invisible unless you open the gui, unlike factorissimo-combinators which are a separate distinct entity that are clearly always a combination of combinators.

This was and will be.
I also don't spot the difference. How will you know (with respect to that example mentioned above) if a combinator has only one output or two or three? In case of transmitting a signal you will see it when hovering over it - that would be complete the same if my suggestion comes true: To know whats happen you have to open the gui. To know what is transmitting you can hover over it. Channel may have background color.

And this feature would not be mandatory to use. If you like to have different combinators for different channels you are free to do so - but I would like to have selectable outputs.

[Tertius]

For the selector combinator, "index" is a numerical value, right? If so, that's great, but not what I really want out of a selector combinator. Maybe there's one other mode that could be added to it? Something that takes one wire, with a whole bunch of signals on it (like the listing of a logistics network), and one (or more) signals on a second wire, and outputs the values of just those signals from the first wire.

Currently with 1.1, selecting/filtering works with the EACH operator, both at input and output. The input EACH operator specifies the condition and the output EACH tells to output each signal where the condition was true.

With the new decider, it may be your intended filtering is already working with a single decider. Look at the condition: You can specify which input (red or green) is used to check the condition. If you have your signal values on red and your selector value on green, you would check G for the EACH operator as condition to filter on the selector value. This creates true for every signal that's matching the condition, depending on the selector value.

Now, the EACH operator at the output is also having this red and green check. If you check R at the output EACH operator, it is outputting all values from R, i. e. the real values, where the condition (checked with G) was true, and this the perfect filtering. I hope the condition matching is working this way. I don't see why not, as long as the condition storage within the combinator loses the knowledge from which input the condition was checked and just stores true or false for each signal.

[epr]

And complex tasks are just a bunch of simple tasks in close formation.

I didn't say it's impossible, just too time intensive to bother, as is evidenced by only a handful of people ever making a self building factory over the years.
The toolset is powerful but not really efficient enough for what was at least at some point the end goal, full automation.

[dorthak]

For the selector combinator, "index" is a numerical value, right? If so, that's great, but not what I really want out of a selector combinator. Maybe there's one other mode that could be added to it? Something that takes one wire, with a whole bunch of signals on it (like the listing of a logistics network), and one (or more) signals on a second wire, and outputs the values of just those signals from the first wire.

...
With the new decider, it may be your intended filtering is already working with a single decider.
...

Huh. You may well be right. We'll have to see if it works the way you are describe it.

[JohnyDL]

To me round number meant integers as opposed to decimal as is often used in comon langage and i thought it for the weights of item.

The quote from #382 is

This created some kind of rough base for testing, and we then modified many things a lot. Most non-intermediate utility stuff was cut to be at most 1 stack per rocket, many things were rounded up, etc. In some cases, we bent things a lot, science packs are expensive, but they can't be recycled, so we allowed 1,000 to fit in a rocket. Modules are expensive, but a whole stack can fit a rocket, because recycling modules is just silly.

To me the rounding refers to rounding up the number of items in the rocket, not the weight, you might be right that they rounded up to a whole number not one that's 1 sig fig and all 0s, so there might be 73 items in a rocket >_<

That is a definition based on your point of view.
Having a arithmetic combinator multiply "coal" by 3 and sending solution to red channel on "A" and to green channel on "coal", could be defined as one task or as two.
I can not spot the difference of the example in FFF: Sending "check-mark" = 1 AND "red-circuit" = input-count. This are also two tasks, which could be separated into two combinators.
Same as in my example but different outcome.

I'm with Qon you're asking for a combinator to perform two completely different bits of logic and have two completely different outputs on each wire this causes a number of problems with teaching people how combinators work, it could make some combinator logic more compact in some ways but it also causes an explosion of issues.

Since you cannot see the difference between what is being proposed and what you're suggesting I'm going to go through every variation I can think of and build up to why I believe Qon is arguing against this idea.

In the simplest case if you're asking Green to output something when the logic is true and Red to output something else when the logic is false this is doable several ways, you can copy and invert the logic to a second combinator, something necessary if the timing is critical or output an extraneous control signal and then invert it with the desired outputs with a second combinator. I would actually be okay with having both a True and a False set of outputs within a decider combinator but they shouldn't go to different wires. All outputs go out on all connected output wires in my opinion and I know that's what you're proposing to change, there are good reasons for that rule.

However, it feels like what you're asking for is different results on each wire with different logic leading to each wire not simply inverted logic, an example might be (if x > y then green x = x) + (if y > z then red z = 1) + (if x > y AND y > x then y both = y) within the same combinator, the bits of logic (especially x and z outputs) might have nothing to do with each other, I'm going to call these dual combinators

The biggest issue I see comes when you're copying and pasting the value of a dual combinator from one build into another (because we're lazy people and copy-paste is easier than setting up a huge complex array of logic a second time) you run into problems, maybe because of something else going on in the new circuit you have/need the red and green output wires swapped compared to the donating circuit. A newbie might copy and paste expecting the same functionality from a dual combinator but might get something broken half the time... with the proposed decider combinators having dozens or hundreds of conditions with AND and OR logic between them (if not other operators like XOR and NAND as requested on the thread) a newbie or even an experienced person might not be able to tell at a glance if the 'broken circuit' is because some set of signals in among the 100s of settings that were copied and pasted is doing things not quite intended or if the two outputs of a dual combinator were relatively swapped, and most people are going to look at the logic first not to check if the outputs are in the right places.

"It's broken I must have wrong logic" is always going to be an easier thought than "it's broken I must have connected the colours backwards" because one is "I didn't understand something when I started the process" [excitement to learn] and the other is "I'm a complete moron and need to go back to preschool and learn my colours" [frustration borne exclusively of dual combinators]

It's less of a problem if you play single-player all the time and you're the only person who has had any input in how the combinators in your world(s) work and you have a perfect memory for how each combinator is set up... but if you use community blueprints, or work on multiplayer or follow tutorials on youtube or are just plain forgetful you may not fully understand every nuance about what you're copying any more than most people understand how some minecraft redstone builds work, so when you copy parts of it you will expect it to act the same as a component as when it's in it's the original location. You might be able to understand it with a little work but it might not be entirely intuitive. But Dual Combinators have 2 sets of logic so if you're copying one because you've tracked down and are expecting it to contain Function A and you get Function B instead that's going to be annoying and a barrier to you learning how things actually work, yes you're getting exactly what you copied but if you don't understand it enough to know that's what you copied that's just going to stop you trying to learn more... if you're trying to filter liquids for example and the decider puts all Liquids on Green and all Items on Red... you've only ever connected the Red side by chance cause it's something you've taken from other places but this time you need it on green that's going to severely annoy and confuse you.... And it might not be trivial to swap the behaviour either. If each input is checked individually and sent to an output separately that could be 100s of operations to change or hundreds of signals to reassign from Red to Green and/or Green to Red (or use an extra combinator to invert the signal but that's the thing your suggestion is trying to avoid)

I agree with you that the FFF is suggesting compressing the logic of several combinators into one and compressing several combinators doing the exact same logic into one. This is not really equivalent to what you're asking for.

Why you and I think this (and Qon doesn't) might be the way we are looking at it.... The current proposed solution can pretty much be spread out into two arrays of combinators (as well as red each*-1 => green and green each*-1 => red, and other delays/filters), one array of decider combinators to come up with a single true/false signal (you can do every comparison between any values on red/green with each other or with constants) and a second array of arithmetic combinators (that multiplies each desired output signal(s) by the true/false value). This would do everything that the FFF384 Decider combinator can do, it might take a lot more time to set up and more ticks to process but it would give you the same outputs (even isolating Red/Green inputs/outputs in 99% of cases)

And what you're asking for might seem kind of related, I actually think you're asking for the ability to reuse the intermediate logic steps, so if Block of logic A then X on Red and if Block A and/or Block B then Y on Green, you could do this relatively easily with the current combinators so it almost feels like you're losing that option. In fact, with the full layout, you can do a lot more and wouldn't be limited to just 2 wire outputs from intermediate steps so it might feel like the new logic is more restrictive. But as you point out yourself with

this feature would not be mandatory to use. If you like to have different combinators for different channels you are free to do so - but I would like to have selectable outputs.

the expanded ways of doing things will still exist, there's nothing I see in the new implementation that stops people from building as though using current/legacy combinators. But what Qon is arguing I believe (and what I'm saying for certain) is that by implementing your suggestion you make them a more powerful tool but also a much more complicated one to learn and use. You're adding 1 more setting that feels small and only impacts how the combinator behaves in a tiny way but you're in effect multiplying the possible problems each combinator can cause within any system by at minimum 4, for every "is my logic wrong" step you also have to ask "am I outputting the right things onto the correct wire(s)" which has 4 answers (for each output in the combinator -> Red, Green, Both, Neither [which you can use for internal debugging]). Right now all the outputs of all places that have outputs are 'tied together' whatever is being output is being put onto all connected wires, this is true on belts, boxes, inserters as well as combinators.

Having two separate combinators doing similar very complex logic might be annoying given how powerful the new combinators appear to be, but it's also easier to understand and debug especially as you get into playing with more complicated combinator systems... Yes, you're still going to have to debug but you won't have to debug both the logic and the outputs in concert with one another... And you can always separate out those common logic blocks so you don't have to recreate them, even though that comes with a slight processing delay.

And this comes from someone who has asked for Arithmetic combinators to do "multiple things" in this thread. I'd like for Arithmetic combinators to do the logic
A*X => Q, A*Y => P, A*Z => R... I could set up several combinators to do them separately I totally agree, but the combinator is providing the same logic on the left side (in my opinion) and the right side outputs are put onto all wires.... why do I say A*X the same logic as A*Y? well if we say A is blue science signal and X, Y, and Z are constants for how many red circuits, Engines and Sulphur are in each blue science, the logic is "calculate the components necessary to make the inputs", and while I would like this (and it has many other applications) I don't necessarily need it, and while it is 'more complex logic' and 'combining combinators' when anyone copies these setting from one place to another it's still going to work exactly the same in the new location regardless of which wires any player chooses to connect, the logic might still be wrong but it's all going to be wrong in the same place(s) as if it were expanded. My suggestion has limitations too as whatever A and the operator are they must always be the same things for all equations in that arithmetic combinator, you can't do 2 completely different operations like A * X and B + Y, I think this is right in line with how the proposed Decider works, after all from the expanded way I explained above it does that same math of True * {selected outputs} which is so close to A * {selected Variables}

It is conflicting because data about how the condition is set up and data about what the combinator is doing is mixed together. That may be ok when checking why a combinator is misbehaving, but when trying to read how it is set up, it is confusing.

I really don't see it that way. It starts black, you put in all your code it updates green/black letting you know if it's behaving correctly you move on. The colour makes practically no difference to what you're inputting unless you find white on green a difficult set of colours to read.... though all the interactive elements, numbers, checkmarks and signal variables seem to be on a black background anyway.

You It's have like to every consciously second ignore word half belongs of to what a you're different seeing sentence.

THAT'S NOT WHAT'S HAPPENING WITH THE COLOURING IT'S MORE LIKE THIS WHERE I'M TELLING YOU I'M SHOUTING BY USING ALL CAPS AND RED TEXT AT THE SAME TIME AS TELLING YOU MY POINT, IT'S ADDITIONAL INFORMATION THAT GIVES CONTEXT TO THE SENTENCE NOT TWO SEPARATE SENTENCES GOING ON AT THE SAME TIME.

not that I'm mad really

What you're arguing for by moving/getting rid of the green is more like getting rid of/changing the grammar. You still want the information available to you but not in quite that location... you can get used to new grammar I promise

You want every statement to go "TRUE: X * Y = Z" or "FALSE: X * Y = Z" when what's being shown is X * Y = Z is true cause all caps and x * y = z is false because no caps. Except it's not even modifying the letters maybe 'X' * 'Y' = 'Z' vs ,X, * ,Y, = ,Z, is actually a better analogy. Not that it matters because after you use it a little bit you can get used to either one.

I didn't particularly like it with the train configuration either, but there a major difference is that you usually configure a train when it is stopped and doesn't show the green background.

That's fair, but the way I see it is that they have to make both look the same... and having done that it actually makes the train station settings a tutorial for combinators. They have to change both or change neither and I think they'll have a whole lot of pushback changing the trains again and very few people actually have a problem with actually using that UI, there may be conceptional/intellectual reasons to dislike it, but it's entirely usable and functional, even people who had issues with it to begin with got used to it.

That's more an issue with the wire icons than with my suggestion. But icons are one of the easiest things for a mod to change, and there are a couple of colourblind mods out there already. (PS: Although, I'm a bit disappointed the game doesn't use slightly different icons already. I understand that for plates and tiered machines, where it would be visual clutter that'd make it harder to see what are variants of the same, but wires easily allow for same-looking but different icons by simply changing which corner the wire end is in.)

I've asked for more colours in this thread and while I see it might be easy enough to change the symbols for 2 colours it might not be so easy with more, and that only solves the issue with the icons, it doesn't solve the issue with Red/Green Wires in the overview, yes it lets you easily identify Red vs Green symbols but if you can't tell if the signal wire carrying the signal in the first place is Red or Green knowing which symbol isn't as useful.... And I know mods which do fix it but it shouldn't be down to mods to make a game accessible IMO

And for the status indicators, black/green works for them, too. Or filled and solid circle. or X and checkbox. (BTW: I made them a bit small in my picture. They should be a bit bigger and have more horizontal room.) A circle is just the quickest thing to add in an image editor.

This is true but it's the same thing, the less obvious the change the more it feels like a style choice, having it be a black to green dot in some ways might look like the configuration is not filled in vs is filled in as much as the current configuration is true vs false... or the black might not be obvious on the black background

TBH, after making the image, I tend to like the "..." indicator better than my original suggestion of nothing. It makes it clearer that that's not a button that does something but one that brings up a dialogue. There's a reason the File menu has "Save", "Save as..." and "Recent >" with different symbols at the end.

While I agree in principle, it works that way on Windows, Linux and Mac, I disagree in Factorio, they don't use the ... model anywhere else in the game the add description I'd assume opens up a text box modal so I don't see it as necessary to indicate how the button does what it does especially given it's not a complex menus of options, menus have One Click Actions (nothing), Multi Click Actions (often ...), and Display Sub Menu ( > ) knowing how the items behave before you click them is super important because navigating to the same point in the menu tree might not be straight forward, the Multi Click Actions ... I often see it as telling you "this is too complicated to do within the structure" rather than 'this opens another modal' which is why it can be used on mobile phones to indicate the location of a menu