Friday Facts #384 - Combinators 2.0

[SLB]

Please don't ignore the box
The blue and green boxes also need to be input or output between the red and green lines.
This will allow the blue and green boxes to simultaneously circuit setup requirements and output their storage signals

[KeithFromCanada]

It is amazing to see how far Factorio has come!

That being said, while I love adding in the rail system's Boolean logic to circuitry, there is one (current) issue with it that desperately needs to be addressed: players can't choose the hierarchy of the Boolean logic. I've lost track of how many times I've tried to set up trains but found that I could use X AND (Y OR Z) but not (X AND Y) OR Z, which is what I actually needed. (...or vice versa. I forget which one isn't possible.) PLEASE allow setting the Boolean hierarchy directly for each logic gate, so we can set everything up exactly as we want it without frustration or complication. (The interface could be as simple as adding arrows to the left margin.)

...and, while you are at it, please also include all of the logic gates. Options like XNOR may not be needed often, but having it handy could really help simplify some edge cases.

Cheers!

[coppercoil]

I need constant combinator that can give one value by index signal, like an array.
Please.

[JohnyDL]

Yes , i tend to think it would be a fun puzzle Give us access to raw value like stack size, number of slot, weight of one item, and then we could do the math with combinator, it's not super advanced maths, ideally when the research is done it auto-update the value, but there is room for different level of automation/complexity.

While I and you might agree on that to varying degrees, I don't think that's true of the general player base. And even if I could math it out I'd rather be told the exact number(s) if that's an option.

if you try something like division to know how many rocket you can load or how many rocket you need for certain amount of material to be delivered, if you have enough material to load say 1.5 rockets it's part of the challenge to round up or down depending on your build i would say. But maybe it is not a fun challenge for other players and more like a source of endless pain

You can actually work that out. You get the division (which floors to 1) and then you can do the Modulus which if it's >0 then you get a partially full rocket, you can even find out the % by doing the math as Modulus*100 then /Rocket Capacity. Order matters when it truncates, and not everyone will be familar with that concept.

Fluids are not integer in train wagon you can have 6.7 fluid, the "read train content" will truncate to 6 for the circuit, unless it's between 0 and 1 in case it will round up so that 0.2 fluid don't show as 0 and mess logic.

I hadn't noticed this... but it does show that Factorio works with decimals it's just circuits that do not.

"at worse" 0.5 or 0.2 but not 0.33333333. If the weight is 1.3333333 kg, it will yield imprecision anyway if you have 1 plate in the rocket and try to know anything about the load level ( or how many you can fit) , same as you mention with 1 item that could represent 0.5% load, i think it could be made manageable but i may be wrong.

The FFF says :

Output the rocket capacity of the input item (useful for Space Age logistics).

It could be because weights were made so that you can always put a integer number of 1 item in a rocket and fill it entirely. I understood this as you send "steel plate" and it tells you how many steel plate you can put into 1 rocket. In my mind you can already "math" how much weight a steel plate, if you consider the rocket can carry 1 ton it's a division which will yield a number that may be truncated, but one could then build to "weight" one stack of steel plate, in order to know how many iron plate you can put if you only fill the rocket half with steel plate. I was under the impression that this was how i'm supposed to use the "rocket capacity" function of the selector. Since by default it only tell you information on a rocket filled with 1 item to the max capacity.

unless it's /2^n then it'll be a continued fraction in binary with rounding errors eventually 0.2 isn't any more precise than 1/3 in that regard. The error is just so small that it's practically ignorable (and most implementations have more precision in binary and round off for decimal since that's what most people use).

Your suggestion of limiting weight to 1 Decimal place kg means that you can only have 1, 2, 4, 5, 8, 10, 16, 20, 25, 40, 50, 80, 100, 125, 200, 250, 400, 500, 625, 1000, 1250, 2000, 2500, 5000, and 10000 items in a rocket. It doesn't make sense to me that you couldn't have 750 items which is the 1.3333... item weight I mentioned, let alone a number like 70, which would be 14.2857142857... or any of the other 9975 possible whole number of items in a rocket (in this range) it skips 3, 6, 7, 9, 30, 60, 70, 90, 300, 600, 700, 800, 900, 3000, 4000, 6000, 7000, 8000 and 9000 which I'd consider round numbers of items relative to 16, 25, 125, 250, 625, 1250 and 2500.

You can calculate the mass but there's no guarantee it's gonna be a nice number, I'd multiply it by a million so I got some precision out of it in many cases but there's a limit cause 32bit integer.

We agree there will always be some level of imprecision in using the weight (and other stats... is gravity gonna be nice? Earth is 9.81... or Volume? Assemblers are 3x3xXm in volume is it gonna be 1000m^3 for 50 Assemblers giving us an estimated height for the assembler of 2.22222m) to manually determine the rocket cargo capacity with circuit networks, a fun challenge for people of engineering, math and programming backgrounds but not generally fun for a general audience, while internally the game can actually just tell you the right answer because the exact same logic that's used to come to that answer and determine the actual limit of the rocket can be accessed by the combinator logic. So why not let it just tell you the number?

And if we do actually define all these physical properties.... What does that mean for inventories? we can handwave away carrying a lot of weight... the space suit could have some level of assist for lifting heavy objects, but if the player can magically compress all this mass and volume into their pockets why aren't they using that technology for the space launches XD

This is beyond my ability to suggest a fix ! The rocket was shown having 1 metric ton of payload capacity. If you use other units, it WILL create imprecision considering the circuit truncate decimals. Even in real life it happened The rocket itself would need to be of a different payload capacity and the weights of all item reworked. I think it's not going to happen.

My solution (and point) was "we don't need to worry about it" it doesn't matter if the Rocket has 345289 flugalcadences as the capacity and the weight of the item is 645038 prakens, the same cargo capacity limit can be output because it is a dimensionless number.

These are good points! The engineer in me always wants to reduce solutions down to their simplest, most general building blocks. But, I agree that in the contex of Space Age, it probably makes more sense to just report the quantity that most people will want directly - i.e. how many items will fit into a rocket, given a potentially large set of external constraints like mass/volume/gravity/etc.

*nod nod* Simplicity is better, it's just how you interpret 'simplicity' is the issue, for me it feels like simplicity is being told the answer not told all the most basic information possible

I trust that the developers know what they're doing - and if they think "rocket capacity" is the best property to expose, I can support that.

Me too in most cases

Agreed, I wouldn't mind seeing more metadata/stats/etc exposed via a special combinator.

If the player can know it and make decisions based upon data then it'd be nice if the Circuit network could have access to that same data to also make decisions. After all that seems to be the whole point of Circuit networks for me. It can do a lot of amazing and powerful stuff too but that's a side effect of why it exists in the game.

Hah - as an American engineer that much prefers working in metric, I sincerely hope Factorio sticks to metric everywhere!

I prefer metric too but some people will complain "I don't understand KG" and "what is a meter anyway" if you give them the opportunity

A separate mode makes more sense to me, though; overloading the meaning of Everything could be confusing, and certainly isn't very discoverable.

Agreed the number of niche combinator things I've found out by reading this thread is mind-bending. Adding more hidden features maybe isn't useful.

"Each" would be even better! Maybe even just a separate mode/checkbox for "set stack size from filters", so it is more discoverable.

[Henry Loenwind]

"Circuit slots show the values"

To be honest, I hate how this is implemented. You're mixing up configuration data and live data in the same field. This makes those conditions really hard to read. The same is true for the green background to a lesser extent.

For the combinators, the input count isn't needed. They already list the input signals at the bottom. Sure, if there are many inputs, this may be hard to read. But for that, split the input list at the bottom into inputs that are used by the formulas above and those that are not (in the form of "A B C | d e f" with A, B and C the used ones).

And for the circuit control GUI, add an input/output list. This could even leave out unused inputs to save space.

And please, add a list of current inputs in the signal selection GUI. That's where we want to select an existing input 90% of the time. (Hint: Snapshot of the moment the selection GUI was opened is fine. Easier to click one if they don't flicker wildly.) And when the other input selection of a formula already has a signal set, show that signal's value and put the freaking cursor into the number field!

---



Even knowing full well that it's not the case, every time I look at this, my brain thinks that decider will output a fixed value of "check 1, red circuit 8" when it's on.



And, tbh, this is just a mess. I really have to concentrate hard to read that. It's way too busy and overloaded with conflicting information.

First, get rid of the green background. Instead, make the "AND"/"OR" buttons narrower so they can be in their own columns and add the missing connection lines. Colour those connection lines instead.

Then, get rid of the R/G checkboxes. Instead, make the signal box 50% wider and add a half-sized red or green wire icon in front of the signal icon. Just one, if it's set to either leave it out to reduce clutter.

Third, make the ">"/"="/etc. texts as big as the signal icon. At the moment, they are tiny and are overshadowed even by the drop-down triangle. I would even try to get rid of that triangle---it's clearly a button already, so it's clear that pressing it will do something. Add a small "..." into the lower right corner if you want. That's the symbol for "will show a sub-menu" since CUA1987, so it fits.

Here, this is much more readable: (yes, it's not the same logic, but I had to change it for the colours anyway)



And hey, even though the AND and OR or are now in their own column, this is narrower than the original (oops, I should have expanded the ||||-bar instead of making it narrower. Too late now.)

EDIT:

Looking at that, I changed my mind about the state indicators. Here, this is better:

[mmmPI]

You can actually work that out. You get the division (which floors to 1) and then you can do the Modulus which if it's >0 then you get a partially full rocket, you can even find out the % by doing the math as Modulus*100 then /Rocket Capacity. Order matters when it truncates, and not everyone will be familar with that concept.
[...]
I hadn't noticed this... but it does show that Factorio works with decimals it's just circuits that do not.
[...]
unless it's /2^n then it'll be a continued fraction in binary with rounding errors eventually 0.2 isn't any more precise than 1/3 in that regard. The error is just so small that it's practically ignorable (and most implementations have more precision in binary and round off for decimal since that's what most people use).

In my mind i thought that if the fraction was finite in decimal, it is possible to show player say 1/1000 of the value, and do not use fraction in binary, just display truncated value.
So if the weight is 0.2 really it would be 2 or 20 or 2000 in the internal. ( no kilogram but gram or milligram )something simple so as to work with integers because i have no knowledge of continued fractions in binary and what you are telling me there. 0.1 could be for specific stack size that end in 0 or 0.4 too if the stack size end in a 5 ; 0.2 is not really good if you want to change the 0 and try to get a 1000 at the end with multiplication.

But if that was the case that the numbers have finite fraction in decimal, then it would be that number displayed in the circuit. duh

Your suggestion of limiting weight to 1 Decimal place kg means that you can only have 1, 2, 4, 5, 8, 10, 16, 20, 25, 40, 50, 80, 100, 125, 200, 250, 400, 500, 625, 1000, 1250, 2000, 2500, 5000, and 10000 items in a rocket. It doesn't make sense to me that you couldn't have 750 items which is the 1.3333... item weight I mentioned, let alone a number like 70, which would be 14.2857142857... or any of the other 9975 possible whole number of items in a rocket (in this range) it skips 3, 6, 7, 9, 30, 60, 70, 90, 300, 600, 700, 800, 900, 3000, 4000, 6000, 7000, 8000 and 9000 which I'd consider round numbers of items relative to 16, 25, 125, 250, 625, 1250 and 2500.

You can calculate the mass but there's no guarantee it's gonna be a nice number, I'd multiply it by a million so I got some precision out of it in many cases but there's a limit cause 32bit integer.

Well i don't think it's too far away from how many item you can put into a train wagon, because depending on stack size, to fill it entirely there is only some number multiple of them with number of slot that would be "valid". If you want 750 items that's 2x3x5x5x5. There is a 3 inside it shouldn't be used, same as 70 because you could only reach 1000 kilogram with a weight that is a infinite fraction. 1/3 or 1/7. Some ancient greeks been doing math this way for centuries before learning about the egyptian continuous fraction

Also if we extend decimal to finite fraction not just 1 place 800 could be achieved or 4000, only those you mention that have a 3 or a 7 are "bad numbers" because then 1000 kilogram can't be achieved with finite fraction. It would mean for 800 items stack size of 100 and weight of 0.125 and you can only put 8 slot. but yea in such case the number from the circuit would be 125 gram and not 0.125 kilogram that was obvious for you maybe. I am going to calculate the mass if given opportunity maybe it will be a round number if multiplied by 1000 or a million. At this point it's more speculation that suggestion or even hypothesis from me.

We agree there will always be some level of imprecision in using the weight (and other stats... is gravity gonna be nice? Earth is 9.81... or Volume? Assemblers are 3x3xXm in volume is it gonna be 1000m^3 for 50 Assemblers giving us an estimated height for the assembler of 2.22222m) to manually determine the rocket cargo capacity with circuit networks, a fun challenge for people of engineering, math and programming backgrounds but not generally fun for a general audience, while internally the game can actually just tell you the right answer because the exact same logic that's used to come to that answer and determine the actual limit of the rocket can be accessed by the combinator logic. So why not let it just tell you the number?

And if we do actually define all these physical properties.... What does that mean for inventories? we can handwave away carrying a lot of weight... the space suit could have some level of assist for lifting heavy objects, but if the player can magically compress all this mass and volume into their pockets why aren't they using that technology for the space launches XD

Gravity on Nauvis is shown at 9.98 m/s2 in the FFF 380 Will the circuit tell us 998 ? Seems unlikely though. Also the unit is shown as using the metric system, 9.81 m/s2 is also 9.81 N/kg, so if we were to math things in combinator it would be easier to use metric i suppose x).

The weirdness for inventory is one of the point that make me feel inconfortable about the notion of weight, if it's only interacting with gameplay for rocket capacity. feel like a missed opportunity that appeal to more interactions, but was added as necessity to balance the rockets. But i can pretend there is a mininiaturization technology that is unstable at the speed required to leave the gravity of a planet, hence why the player can't have anything in its inventory when taking the rocket. You don't want some decompression accident

My solution (and point) was "we don't need to worry about it" it doesn't matter if the Rocket has 345289 flugalcadences as the capacity and the weight of the item is 645038 prakens, the same cargo capacity limit can be output because it is a dimensionless number.

But then the gravity should be expressed in some flugalprakadence or something so that the payload capacity match in propotionality in other planets no ?

I can understand the idea of dimensionless number for the rocket capacity that would be akin to mass or volume whichever is the limiting factor for filling a rocket for gameplay reason. But it was explained about the recycling that should make sense in "weight", so at this point i thought it's not possible anymore that in game the number would be dimensionless.

The more we discuss about it though, the more i'm convinced you are right, it would be outside of the scope of the expansion to do all those math for the general player base.

I'm curious to see how Wube manage to create a puzzle from that

[Koub]

Hah - as an American engineer that much prefers working in metric, I sincerely hope Factorio sticks to metric everywhere!

I prefer metric too but some people will complain "I don't understand KG" and "what is a meter anyway" if you give them the opportunity

I'm OK with 1 "tile" as the unit of length, and 1 "mass unit" as unit of mass. Like that, even those who don't speak metric won't find anything to complain about

[JohnyDL]

Even knowing full well that it's not the case, every time I look at this, my brain thinks that decider will output a fixed value of "check 1, red circuit 8" when it's on.

That's an intereting take, and I can see how you read it that way, for me it's saying it will output with the current inputs if it's outputting. I think it might be more obvious that some things are variable and some things are static when the inputs are variable (and varying occasionally) in game rather than a static picture. Perhaps the way of denoting variable vs fixed number is putting variables in (#####) saying "this is just an example" vs without meaning "it'll always be this way" or some other way of denoting a variable vs a static.

The live data isn't necessarily the same as the displayed inputs, it is if you only select Red or Green inputs, but selecting both means the live input shows you the sum of red and green and I'm assuming that if you select neither it'll show 0 for the live data, this lets players double check they're doing the logic they think they're doing. If they think they're comparing a 1 or a 0 and the live data says it's a 37 then they know they've got the setting wrong. If they have to infer and work it out for themselves they might struggle more with debugging especially when they're new to combinators.

And, tbh, this is just a mess. I really have to concentrate hard to read that. It's way too busy and overloaded with conflicting information.

First, get rid of the green background. Instead, make the "AND"/"OR" buttons narrower so they can be in their own columns and add the missing connection lines. Colour those connection lines instead.

Then, get rid of the R/G checkboxes. Instead, make the signal box 50% wider and add a half-sized red or green wire icon in front of the signal icon. Just one, if it's set to either leave it out to reduce clutter.

I don't see it as conflicting the Green tells you if the given expression is true... so

• Green Circuits (currently 8) > 0 is True so the background is green
• Red Circuits (currently 8) = 0 is False so the background is black
• Electric Furnaces (currently 4) > A (currently 0) is True so the background is green

The Checkboxes then tell you where the current live values come from (if you aren't seeing what you expect to see from the live values) but you can mostly look past them and they're Greyed out when the value is static. Someone else suggested moving them outside of the logical expression so you get the order Tickboxes Value Operator Value Tickboxes, and I might go a little further and make the tickboxes completely even more greyed out than current.

Looking at that, I changed my mind about the state indicators. Here, this is better:

Consistancy .... Green vs Black Background and the way the and/or look is how the game already works for Train conditions, people are familiar with it and it works really well, changing it too much from what exists already is probably not smart or you're asking for train conditions GUI to be changed too.
Learning Curve .... what happens if all the conditions are the same colour Green or Red or making it that small is that the useful debugging information looks just like a style choice and a player could become easily blind to any small change making it much harder for them to understand and learn how the things work. It being in your face and seeming to change everything is a good thing for making it easier to learn.
Colour Blind People... Green vs Black is easy to distinguish Green vs Red is hard to distinguish, you're arguing to take away an accessibility feature. This is also why R and G are better than red and green wire symbols, Some people suggested making the colour of R and G Red and Green which wouldn't change accessibility because the letters are there but making them just a spiral of indistinguishable colour isn't as helpful to some people as you'd imagine.

I do like the larger operation symbols though you don't even need the menu ... at the bottom if it's clear it's a button (like the AND/OR are buttons) and every other place that shade of grey is used in factorio. I think the drop-down is only there cause legacy that's a really nice catch

In my mind i thought that if the fraction was finite in decimal, it is possible to show player say 1/1000 of the value, and do not use fraction in binary, just display truncated value.
So if the weight is 0.2 really it would be 2 or 20 or 2000 in the internal. ( no kilogram but gram or milligram )something simple so as to work with integers because i have no knowledge of continued fractions in binary and what you are telling me there. 0.1 could be for specific stack size that end in 0 or 0.4 too if the stack size end in a 5 ; 0.2 is not really good if you want to change the 0 and try to get a 1000 at the end with multiplication.

But if that was the case that the numbers have finite fraction in decimal, then it would be that number displayed in the circuit. duh

So in Binary 0.1 is actually 0.0011001100110011001100110011.... and my point was for the internal logic of the game this is no more difficult to handle in the C coding than 1/3 which is 0.0101010101010101010101010101.... Because in the C portion of the code they can use floating point as much as they want, they aren't limited to only doing integer operations (as we see with fluids... I think this is why occasionally we lose a tiny tiny fraction from a sealed system (that's the floating point error building up over time))

Copper Wire is 2/3 the weight of Copper plate if we're assuming lossless manufacturing. There are a few recipies where we get 5/2 or 13/4 or some other number, I bet yellow science is a really awkward number if you actually do all the math on it you get 261/3 for solids and 897.683../3 for fluids (and that's before taking into account productivity) assuming lossless conversion.

Well i don't think it's too far away from how many item you can put into a train wagon, because depending on stack size, to fill it entirely there is only some number multiple of them with number of slot that would be "valid". If you want 750 items that's 2x3x5x5x5. There is a 3 inside it shouldn't be used, same as 70 because you could only reach 1000 kilogram with a weight that is a infinite fraction. 1/3 or 1/7. Some ancient greeks been doing math this way for centuries before learning about the egyptian continuous fraction

Also if we extend decimal to finite fraction not just 1 place 800 could be achieved or 4000, only those you mention that have a 3 or a 7 are "bad numbers" because then 1000 kilogram can't be achieved with finite fraction. It would mean for 800 items stack size of 100 and weight of 0.125 and you can only put 8 slot. but yea in such case the number from the circuit would be 125 gram and not 0.125 kilogram that was obvious for you maybe. I am going to calculate the mass if given opportunity maybe it will be a round number if multiplied by 1000 or a million. At this point it's more speculation that suggestion or even hypothesis from me.

So 5 is a bad number in binary, at least for fractions 1/5 is 0.0110011001100110011001100110.... by assuming the math will be easy in combinator logic, it has to be a nice finite fraction in decimal that we'll be able to manipulate easily we're limiting what the devs can do... Maybe Assemblers, level 1 you can launch 50, level 2 it's 30, and level 3 it's 20 because that's a good balance of effort to put things in space vs production speed in space vs not being optimal to recycle them (if you could launch 50 of any type of assembler you could launch assembler 3s and then recycle them back into assembler 1s (you might want to build with) getting in effect items for free in space).

We don't know, we can't know right now what numbers they will or might want to pick and do we want to limit people making mods?... They said "round numbers" for vanilla launches which to me means that it has 1 significant figure and as many 0s as they'd like. There's nothing in what they said that prevents them from wanting to have some item be by the 30 or 60 or 70 or 90 and so nothing stopping really awful fractions for the purposes of Combinators.

Gravity on Nauvis is shown at 9.98 m/s2 in the FFF 380 Will the circuit tell us 998 ? Seems unlikely though. Also the unit is shown as using the metric system, 9.81 m/s2 is also 9.81 N/kg, so if we were to math things in combinator it would be easier to use metric i suppose x).

That's cool I hadn't spotted that detail, I don't know the answer though ^_^ maybe, depends on what they want to give us access to directly in-game.

The weirdness for inventory is one of the point that make me feel inconfortable about the notion of weight, if it's only interacting with gameplay for rocket capacity. feel like a missed opportunity that appeal to more interactions, but was added as necessity to balance the rockets. But i can pretend there is a mininiaturization technology that is unstable at the speed required to leave the gravity of a planet, hence why the player can't have anything in its inventory when taking the rocket. You don't want some decompression accident

But then the gravity should be expressed in some flugalprakadence or something so that the payload capacity match in propotionality in other planets no ?

I can understand the idea of dimensionless number for the rocket capacity that would be akin to mass or volume whichever is the limiting factor for filling a rocket for gameplay reason. But it was explained about the recycling that should make sense in "weight", so at this point i thought it's not possible anymore that in game the number would be dimensionless.

The more we discuss about it though, the more i'm convinced you are right, it would be outside of the scope of the expansion to do all those math for the general player base.

I think Koub said it best ^_^ for me it doesn't actually matter what the units are called, Wube has used Metric (so far) and so I asked you about localization because it helped to prove a point more than it genuinely mattering for the purposes of the game. The point being there's no good explicit reason for strict adherence to finite decimal representations of any measurement values.... except that it makes Combinator math easy, and if they're not planning to ever let us interact with those numbers using combinator math because it can be done by the C portion of the code it doesn't matter how whacky their number choices are it effectively comes out to being flavour text.

I'm OK with 1 "tile" as the unit of length, and 1 "mass unit" as unit of mass. Like that, even those who don't speak metric won't find anything to complain about

I'm curious to see how Wube manage to create a puzzle from that

Me too! I hope we're helping them with all this discussion XD

[ElderAxe]

"Circuit slots show the values"

To be honest, I hate how this is implemented. You're mixing up configuration data and live data in the same field. This makes those conditions really hard to read. The same is true for the green background to a lesser extent.

For the combinators, the input count isn't needed. They already list the input signals at the bottom. Sure, if there are many inputs, this may be hard to read. But for that, split the input list at the bottom into inputs that are used by the formulas above and those that are not (in the form of "A B C | d e f" with A, B and C the used ones).

And for the circuit control GUI, add an input/output list. This could even leave out unused inputs to save space.

And please, add a list of current inputs in the signal selection GUI. That's where we want to select an existing input 90% of the time. (Hint: Snapshot of the moment the selection GUI was opened is fine. Easier to click one if they don't flicker wildly.) And when the other input selection of a formula already has a signal set, show that signal's value and put the freaking cursor into the number field!

---



Even knowing full well that it's not the case, every time I look at this, my brain thinks that decider will output a fixed value of "check 1, red circuit 8" when it's on.



And, tbh, this is just a mess. I really have to concentrate hard to read that. It's way too busy and overloaded with conflicting information.

First, get rid of the green background. Instead, make the "AND"/"OR" buttons narrower so they can be in their own columns and add the missing connection lines. Colour those connection lines instead.

Then, get rid of the R/G checkboxes. Instead, make the signal box 50% wider and add a half-sized red or green wire icon in front of the signal icon. Just one, if it's set to either leave it out to reduce clutter.

Third, make the ">"/"="/etc. texts as big as the signal icon. At the moment, they are tiny and are overshadowed even by the drop-down triangle. I would even try to get rid of that triangle---it's clearly a button already, so it's clear that pressing it will do something. Add a small "..." into the lower right corner if you want. That's the symbol for "will show a sub-menu" since CUA1987, so it fits.

Here, this is much more readable: (yes, it's not the same logic, but I had to change it for the colours anyway)



And hey, even though the AND and OR or are now in their own column, this is narrower than the original (oops, I should have expanded the ||||-bar instead of making it narrower. Too late now.)

EDIT:

Looking at that, I changed my mind about the state indicators. Here, this is better:

I loved all these suggestions. The new configuration screen is too much cluttered.

One thing I can add is;
- We don't need to change the wire color from the main screen. The wires that will be listened to can easily be configured from the "Select a signal" modal which you need to open anyway to choose the input and output signals.

cable selector.jpg (110.83 KiB) Viewed 3066 times

[Qon]

Some time ago I was thinking about how to enumerate all non-zero signals in a circuit. I thought that I didn’t have enough knowledge about combinators, but it turned out that this is now almost impossible. But at least it will be like this until version 2.0

I'm curious what you mean by "enumerate" here? You can count the non-zero input signals with 1 combinator, and perform the same computations for all non-zero input signals easily enough. I guess I'm struggling to understand the usecase for this new combinator, if there even is one in 1.1.

I think what IForgotMyName was going for with Enumerate is that say there are signals of A, B, C, D, E on one wire then some complex of logic assigns A = 1, B = 2, C = 3, D = 4, E = 5 to some other wire (perhaps even sorted), this would be incredibly difficult to do in any reasonable time in the current version, make a memory cell -> identify the maximum(s) and filter them out one by one while populating an enumeration buffer eventually you have a sorted list but it might have problems/conflicts if two signals have the same value, there's no easy way to separate them, you can't pick one at random, you could manually separate them out with a LOT of logic but it'd be tedious to set up and might not work very effectively.... However with the Selector it'd be easy, Sort Each => Output INDEX => Decider Each > 1 then Each = 1 => Arithmetic Each * INDEX = Each.

For uses maybe you want to load the thing with the most number of items onto a train first? not sure

It's not impossible

0eNrtXM2Oo0YQfhWLY2QmdDcYsJJIqz3lNMnu3lYrC5seu7U2WNDMZjTyA+QtcsmL5UnSGC8/Nj9V2B5mduay2sF00dRXVV31dTWP2nyd8G0kAqlNHzWfx4tIbKUIA22q3SZym8h4FAajSCxXchPGcrQNv/FoG655fDP65H3lsboSCynu+SgWy8Bb7++XKz5a8zt5M/rAYy5H34Rc7S/+kcSreSJlGNxoY00swiDWpp8ftWxsOgf5sOXq4fcikom6MtYCb5NeyO7QP2o7NS7w+V/alOzGiJG3pZEUNfJDaSRDjfxUGmnuvow1HkilLJ699P6Ph1mQbOY8Uq+Tj/b5Qvg80hfhZi4CT4aRkpzpOUXmUVPi3BtrrD1oU52a6hm+iPgi+9Uca0qtMgrXszlfefdCjd5ju5c5U7/5ezlxevVORLGcgd+He4tV+kopbtJLjcZI/9hsvWg/y6n239//qFHh3nT6yN0+qBkmgZzdReFmJgIlRpvKKOG77LFB9pr7yZP0n4j7ZWUKP9OAiBaJkPs/ye6LGkubbqand+9SkI/Qofmct7kNn6JCzAKWG2tXD8WdWEseIQ3fD2WmoSRVOzFKXqDsSsSzdA53yv84XFEM9uosn4sXKUfecCkWrbZJJhUdlIyT1mukkHsZ+4x5KmZWmKnyrXDLlZFmoU3vbaMIM6QpMMuI86BD77TdQE9AgkltQtNEhRliv8WZJoDJscLH7ShXf7YwUYqBrYAA45mFMgPK3swAvNxUcSZ2I9D1AFowACc4ALEh+SIALlZ88fUaCJYEoyEEaZ12oGQ3oGLnM/3+yu2w2NfKF0oaSg4rYJEwYDQzaQ9jDsxaHWwOwYyBcohccYckAh1VnjzRMMmJ7Y6brbZ5kSFOA3guOgE8YEePsZtcF7uPfXB7fwzazz1Ae4dCjBBMBkgJzMfSogCxJLADSAwI0rNe0t+3LAZZVdQfnfbUrA7LWnRIL3Toj4DOxwsm3UZ7ukVRxZXbkbsZQGwprqhymsC9ZjKWMwhN2P7aZ7G659GDXIlgeUEHZBPogma2JyfHxVC7MRB26SKLoKkTaiBN4+rUiX7Enfz0FCkNDjhmAt0Ux31QOoSbekHZn562bEI7qo1aKYGVLUFyE+briqbYBdOEBlOrI5haKJ90oI89NYtxWwHaaDUTdKx1Boq1xyXmZYPtQTqmgDRQOybQpMjGuXGxo8XeKMbPQK64PiuCFowFK7Phvkg2Ol+r2UTKb9It3pqihBYYfaerIPN3aixGPZqL5WoeJntqi7hf6mbo9p8hxczQJIApOnVTpAaO8tNJPkMCjDutBKCQfFOY37cw9HmQxoC4vF/oGB275lUpIgpPZdA0zWrdQK8KidXre0uuK418bRDDgHNZrD1fXybBPPQqM5qk1V6+v94tK/LEWj/cU4ixGc2lWAApW6EulvdijUK7E8B4qaYR6Eo925IUZhYMrQ18lfIkCqU6MGwCrs+VH1U4YjsX4gKErL3AV6a5rthZSRfEAAjJbFsXQcwj9Z+SLLOYDQEZbY0Ia1LivSFGm6h7o2Wkhvv6nK8re+5KWiEMYrrzJAoa3o2xwnIJxHTvvFjWSapq3Grk9s/gFSmOuSLI6HbRdRxL/r7LVFlZ7/8dfL132zNxahxdMFHlMgV2ClCK3rQ5QG9cJqGuJGW9kD13LwZH69cpFg7DCco2ECbWFybyXDgmo4rU7Ycn6c8hHfqn52wDkA5pJ08zgWjjOCxriGB8TQqrKvsSwRa3Y0CtRiKDApkKaiGLGvuoYoC+mNld0zCjtqZBcyn2ZSP/8wgpe44P1UZSp/K2Sh0c43FciotE4zIpWIW8xC7XOZ/6DCnU09gNDQEdsQTYPEPR3TOE/Ij+iF/i7Y5F10UlbB1pOYPWU25vOMkzSKwPnnpuat0aXIHOAnetJpKaGci1mLB+izEDEIzUqluMGbL8ZkME/xeW8jmorazjchvejW0CtzxZzwYSYwiOpcDXPML3l8GZE8aaz0ec2VNwZAMW+FwGsFmEMdxGApnkkci46lkjQOdwnQKhr232M33y1jsFOI3QlaO0HFIyz+mdOnku7fvcRrtBdokYQ4TMF9MlggyOQKaDTfph9MZWNQOF6sI5bVQcdzZw1QJp9+ucI8PmJ8/y1GDHeTE2OafNqhFAp19P3WsA8NyuR4rqejxZGV0ggmjWID/zN/A+D74v7sn7jRmqIKzrl6s9ao07kEOdt6jZGDUnHVHTRflkx6FGaAOdiTzTY7yu2gV7kNoAtwzbOPzarcHpOATkNtM7UDuhfc5+Eecpz369nIb2DuwZ+PAQPfMUJlBuo1WgGzcspGFccxtguOPOKGICDAaOhrKHcNHupfq34b+GYYHdD/UFFBP6eRsL61Tuq3Oqet6tK67iPqtVy+KlX6pKu1qnpe/OjbW1N+fqpbTfU5Z5FIeR5H7+Nbn5w+jP/Ze21EoSZ7mSQ0zbpbZjMNM1zd3uf7OeA+w=

Copy blueprint

[Henry Loenwind]

...

I loved all these suggestions. The new configuration screen is too much cluttered.

One thing I can add is;
- We don't need to change the wire color from the main screen. The wires that will be listened to can easily be configured from the "Select a signal" modal which you need to open anyway to choose the input and output signals.
cable selector.jpg

Um, yes, that was my intention; I just forgot to write it down explicitly. Good catch.

---

And, tbh, this is just a mess. I really have to concentrate hard to read that. It's way too busy and overloaded with conflicting information.

I don't see it as conflicting the Green tells you if the given expression is true... so

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. You It's have like to every consciously second ignore word half belongs of to what a you're different seeing sentence.

Looking at that, I changed my mind about the state indicators. Here, this is better:

Consistancy .... Green vs Black Background and the way the and/or look is how the game already works for Train conditions, people are familiar with it and it works really well, changing it too much from what exists already is probably not smart or you're asking for train conditions GUI to be changed too.

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.

Colour Blind People... Green vs Black is easy to distinguish Green vs Red is hard to distinguish, you're arguing to take away an accessibility feature. This is also why R and G are better than red and green wire symbols,

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.)

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.

I do like the larger operation symbols though you don't even need the menu ... at the bottom if it's clear it's a button (like the AND/OR are buttons) and every other place that shade of grey is used in factorio. I think the drop-down is only there cause legacy that's a really nice catch

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.

[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?

[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.

[FuryoftheStars]

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.

The only reason I can think of is to have different outputs going to two different places with the same set of conditions, but yeah, this can be solved by just popping in a second combinator, duplicating the conditions, and then changing the output and wire. :/

[mmmPI]

So in Binary 0.1 is actually 0.0011001100110011001100110011.... and my point was for the internal logic of the game this is no more difficult to handle in the C coding than 1/3 which is 0.0101010101010101010101010101....
So 5 is a bad number in binary, at least for fractions 1/5 is 0.0110011001100110011001100110.... by assuming the math will be easy in combinator logic, it has to be a nice finite fraction in decimal that we'll be able to manipulate easily we're limiting what the devs can do...
Copper Wire is 2/3 the weight of Copper plate if we're assuming lossless manufacturing. There are a few recipies where we get 5/2 or 13/4 or some other number, I bet yellow science is a really awkward number if you actually do all the math on it you get 261/3 for solids and 897.683../3 for fluids (and that's before taking into account productivity) assuming lossless conversion.

I documented a little and it's horrible, i would have never thought, in my mind it wasn't fraction at all, only large integers shown divided by 1000 or 1000000 and truncated for display unless it's for the circuit as it would have been integer weight in grams or milligram on the internal and not fractions of kg. I thought also that after all it's ok if the rocket is not 100% filled, if you reach 999.948 kg of payload it's ok if there is a little "waste". It's not counpounding. Regarding your point of helping WUBE with that discussion i have no idea, but at least you're helping me making more informed suggestion

I wasn't assuming lossless manufacturing, similar to recycling that yield only a % of item back, it would be "lossy". Otherwise you would recycle circuit made with productivity module for a net positive loop. I wasn't considering productivity module either though. That's really going to make tracking the weight of things funny if they are not exposed individually. The recycling loop i expect it to reduce the weight of things since recycling a lot will void everything eventually. So manufacturing with productivity module i expect it to yield "heavier" product than materials. Which sounds weird, but many things act like that when it react in the atmosphere because it gain oxygen or carbon or nitrogren that wouldn't be weighted in as ingredient.
I thought those margin of adjustment are where all the hard work of setting the weight to items retrospectively after the production chain were drawn went. Which would indeed have made harder for modders / limited them and the devs.

We don't know, we can't know right now what numbers they will or might want to pick and do we want to limit people making mods?... They said "round numbers" for vanilla launches which to me means that it has 1 significant figure and as many 0s as they'd like. There's nothing in what they said that prevents them from wanting to have some item be by the 30 or 60 or 70 or 90 and so nothing stopping really awful fractions for the purposes of Combinators.

Agreed we can't know. But it still show that some hypothesis ( taking only integers for weight ) have implications that makes them unlikely, if that is necessary for some functionnality such as suggesting things on rocket capacity in the selector combinator, then such suggestion are also unlikely. ( can't ask the weight of 1 item in the network if the item weight is not integer, nor the weight of a stack ). You made many good points.

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. But considering productivity module even if some integers were found to match the receipes in a plausible approximation for weight it wouldn't work anymore with +50% or even +100% productivity as is possible with high quality productivity module. It's making me curious even more to make table with how many item you can put in a rocket to know their relative weight. In real life i would see productivty as reducing waste, but here if it's yielding twice the weight in copper wire than you had in copper plate it's beyond the weight gain due to external reaction with atmospheric thing. Maybe it's better not to overthink it

I think Koub said it best ^_^ for me it doesn't actually matter what the units are called, Wube has used Metric (so far) and so I asked you about localization because it helped to prove a point more than it genuinely mattering for the purposes of the game. The point being there's no good explicit reason for strict adherence to finite decimal representations of any measurement values.... except that it makes Combinator math easy, and if they're not planning to ever let us interact with those numbers using combinator math because it can be done by the C portion of the code it doesn't matter how whacky their number choices are it effectively comes out to being flavour text.

I'm OK with 1 "tile" as the unit of length, and 1 "mass unit" as unit of mass. Like that, even those who don't speak metric won't find anything to complain about

But trains speed are shown in km/h, the tile is 1 meter long even if the internal are "tile per tick" ! I understand you could just write mph instead of km/h and pretend the tile is 5.28 feet or 1.76 yards or 0.008 furlong ? but that would mean the train is 1.609344 faster. It will matter for the energy conversion of fuel value and engine efficiency of trains if the train is not going 200km/h but 200 mph instead it can mean the engine is producing more cinetic energy than it is consuming fuel if efficency was above 62% it would bump it above 100%.

I understand for trains fuel consumption it is not game-breaking unlike say nuclear or steam engine if the unit system yield inconsistent result for dimension. But the expansion with the gravity and pressure value made me intrigued, In space exploration you need to provide fuel to the rocket for it to take off and the quantity is not the same if you want to go from Nauvis to Nauvis's orbit or the opposite, supposedly because leaving the orbit to go to the planet require less energy to escape gravity than leaving the planet to go to orbit, even if the distance is the same. In game you know the fuel value of things in J so you can convert in Newton and Kilogram and meter and second, the energy needed to accelerate a mass to a certain distance per second in a certain time, so the weight of the rocket and the fuel amount you need to give it and the gravity are all related. Although it's done in a way where the player doesn't need to math it out, it's just providing different written value of fuel that you need to fulfill and could estimate, it's logical/intuitive that you need more fuel to leave a larger planet with more gravity than a small moon( or go to a further distance). It's good for gameplay i found, it yield implications for distance and possible strategy for planning, and it help giving a distinctive personnality to the different planet. ( in space exploration you don't need more fuel is the rocket is more loaded but that could become an expectation if things have weight )

There is the "pressure stat" that was shown in the FFF 380 alongside gravity, it may have some gameplay implications, and my guess are for the temperature for steam. Maybe i'm wrong, it's speculations . Nuclear power plant are one place where combinators shine, and back-up steam power generator too. Alongside the suggestions for more stats/ functions of the selector combinator, related to the sensor idea, getting to known the constant of a planet such as gravity or pressure could be interesting. The unit may matter in such case. Too bad i'm learning doing those math for weight seem unlikely given that "weight" may be more a theorical concept used only to limit rocket launch. But maybe not, maybe pressure isn't. As it was mentionned if those have gameplay inplications, so that the player do different thing because of those value, then it's a wish to have access to them in combinator so that dealing with their consequences can be part of the design goal of the machine player make.

I only mind the units for this purpose, for nuclear power plant, it is possible to predict the temperature of the reactor when counting the fuel cell going on a belt and counting their Joules. It is possible to math out when a train will run out of fuel, what is the maximum distance it can go and so on. The simplification over real life are subtle enough for me to not notice them. I think it's also part of the beauty in factorio that items are simulated individually, they are like integers, the illusion when they are put in chest is perfect. I think it is one thing that enable combinator math, you are not reading "+12.4 copper plate" unless it's in the production stats otherwise there is nothing like 0.4 plate . I agree that " there's no good explicit reason for strict adherence to finite decimal representations of any measurement values". it's more an non-explicit feeling that non-strict adherence to integers when possible is pleasing and can yield minipuzzle/ combinator-math-opportunity which i wish are added in the expansion, but also realizing some of my wish come froms lack of knowledge.

[SLB]

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.

[Tnarg]

The Selector combinator has options for:

Output the stack size of the input item.
Output the rocket capacity of the input item (useful for Space Age logistics).

It would be nice if these would combinded in to one 'Output the size of container' with options both stack, rocket or any type of chest.
Would be nice (but not a must have) if you could select a number of chests for example 6 steel chest if your makeing a train unloader.

Edit
also Train wagons,
And tanks for fluids.
so if you ask for the size of chest for water you would get 0 but if you ask size of tank for water you would get 25,000.

[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.

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, but I'm pretty sure that you don't either.

I was responding to someone asking for selecting output wire. Output, not input.

Also the names of everything you mentioned is wrong and doesn't make sense after reading it many times. Logistics chests are not combinators.

[SupplyDepoo]

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.

[FuryoftheStars]

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, but I'm pretty sure that you don't either.

I was responding to someone asking for selecting output wire. Output, not input.

Also the names of everything you mentioned is wrong and doesn't make sense after reading it many times. Logistics chests are not combinators.

I think what they were trying to say is have a combinator that passes through the signal(s) from one wire only based on the condition(s) of the signal(s) from the opposite wire.
(Edit: This can probably also be accomplished (mind you, I'm guessing; haven't verified in game) by having an extra arithmetic combinator. Feed your "conditions" wire to the input, then Each * -1 -> Each, and connect the output of the arithmetic combinator to the output of the decider with the same color wire you're outputting from the decider.)

Otherwise, yeah, the rest doesn't make sense to me, either. They said it one time earlier in the thread, too.