Friday Facts #384 - Combinators 2.0

[mmmPI]

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 >_<

went back to read the FFF quote and the previous lines too

Given the "base" of 2kg per ore, that seem a correct order of magnitude for an item made of 6.5 or 7 ore as it would mean 13 to 14 kg roughly for the product as 73*13<1000 but 74*13>1000

But then it doesn't mean the item isn't weighting 13.52857142 kg or 13.66666 kg as it would also yield 73 for a perfect count one shouldn't use a prime number, but would mean the item is 13.698630137... kg But in such case, i would assume one could just make it 13.6 kg, and use 13600 grams or even 13698 grams as the internal value to display on circuits for players that are interested in those math; i thought. If you could somehow measure the number in 1000 rockets it would yield imprecision but otherwise no, the truncation happening for circuit would be the same as the truncation happening for number of item in a rocket since those have to be integers if the rocket is not 1000 kg but 999.954 kg filled, it's still fine imo as the numbers you can use to math your factory ratio are the 73 and the 1000 kg, you'd lose 460 grams of payload every time that's still a good rocket effiency.

That lead to other consideration, an ore as 2kg , so a plate too maybe since the ratio is 1=1 without modules, meaning 460 grams or 0.460 kg is less than the expected weight of a copper cable at 500 grams or 1/2 kg otherwise adding 1 could have been a way to increase even more rocket payload efficency that's the game no ?

Also that green circuits should weight around 2.5 kg. that would mean one can put 2 stacks in a rocket without adjustment. or 400 circuits. If that is number one can read with circuit, which seems likely, then you could math out the gravity on different planet. Because then if the gravity is twice as strong, supposedly you can only put 200 circuits, or lift half the weight.

I think the math we will be allowed to do without mods will be those anyway, as if you receive 73 as information, you could deduce the 13698 grams. Same as if you only receive 100 or 200 or 75, you could math the weight of an item and consider it doesn't matter if it's not an integers doing 1000000/73 or even 1G/73 to have the ""weight"" in milligram.

It make more sense for gameplay reason to know how many item you can fit than the actual weight though that's my opinion after a little discussion. While on parallel knowing stacksize allow player to know how many slot or train are required to fill in the rocket based on the integer quantity of item possible to fit in a rocket.( or how many rockets are required to send a train content to space). The weight itself doesn't have to be integer. But if there was some rounding off to make the weight 13650 grams because many of them are handpicked anyway like modules or science pack, then it could also make sense to have a combinator that act like a scale to weight items individually, but i'm fine with mathing it out if weight are not exposed directly, i realized that's the kind of puzzle combinator i like, and there it is in the expansion already

[Qon]

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.

Decent enough example, I think I agree.

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.

You don't get feedback if the signals are different for output and input. Or the combinators and other entities could just subtract their own output from their input to get rid of the feedback.

[TheRaph]

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

That is not true.
Just look at graphic shown in FFF
.
Conditions are on the left side top.
Outputs are on the right side.

Now Imagine to have behind each output two check-boxes: "to red" and "to green", booth of them checked by default.
No more.

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.

Thank you for that ..

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

No I do not ask for that, because there is only one set of conditions which could either be TRUE ore FALSE but not booth.

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,

No - Just different outputs to different channels if ONE set of conditions is TRUE.
For special outputs in Case of FALSE you need indeed a second combinator.

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.

That is for me (as non English native) hard to understand.
If I read it right you don't like the feature because of someone might copy it in a place where it doesn't fit?
That's true for everything else: If you copy a combinator set up for copper in a place where it should control iron, it won't work.

And the rest of the problem might depend of you imagination of a dual combinator what's I already have stated wasn't my intention.

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.

I just asked for directing outputs

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.

Yes I agree with you, that it comes to 4 possible "is my logic wrong"-cases. But this will allways happen if you need two different outputs.

Imagine you have NOT done it the way I suggest.
What you need to do is to build two different combinators for each channel.

Every time you have to change or tune something on the conditions, you need to remember to do the exact thing in booth combinators.

If you (or someone else on MP) has change a setting only in one combinator and forgot in the other one, it could get very complicated.
Due to the fact that devs are already on the way to add more complex logic to "conditions" you would be happy to check if combinator outputting to red has exactly the same conditions a the combinator outputting to green.

So you need to swap between those two combinators GUIs to compare. Or you copy-paste settings and reconfigure the output (because that is what is different).

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

Its easier to debug booth logic and output as to debug two complex logics in having no differences.

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}

That is again hard to read for me.
But as far as I see, you will able to do that with new combinators. Because on the left side you will have equations to perform if conditions are true.
An there are multiple lines which implies that multiple equations are welcome.
The only thing whats currently not available is to select the direction of output - whats my suggestion.

[Qon]

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,

No - Just different outputs to different channels if ONE set of conditions is TRUE.
For special outputs in Case of FALSE you need indeed a second combinator.

Yeah first I thought you wanted different conditions on the different wires. Now that I know that isn't the case, I don't object as strongly. It might even be a good idea, if I spend some more time considering it and the implications fully.

Imagine you have NOT done it the way I suggest.
What you need to do is to build two different combinators for each channel.

Every time you have to change or tune something on the conditions, you need to remember to do the exact thing in booth combinators.

If you (or someone else on MP) has change a setting only in one combinator and forgot in the other one, it could get very complicated.
Due to the fact that devs are already on the way to add more complex logic to "conditions" you would be happy to check if combinator outputting to red has exactly the same conditions a the combinator outputting to green.

The conditions being exactly the same kind of implies it should be in 1 combinator, yeah, so that it is configured once in one place.

[ElderAxe]

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.

You don't get feedback if the signals are different for output and input. Or the combinators and other entities could just subtract their own output from their input to get rid of the feedback.

Think of a series of requester chests for train loading. You want to read the content of current chests and set requests for missing item amounts.
Currently this is only doable by setting the requests on requester chest, transfering all the items from requester chests to a steel chests and use that steel chest to read the existing contents.

If they allow us to select multiple modes at the same time, that means you can read the content and set the content on one chest. And it can work for one chest only. To read the total contents of multiple requester chests, you will connect them with the same wire. Then their signals will mix with each other and with every item existing on a requester chest, the others will request more of that item.
To solve that you would need 2 combinators per requester chest to make the signals move one way only for both input and output signals which is worse than current solution of using steel chests to read the contents.

Being able to select the wire for the action solves this unexpected behavior in a nice and easy way.
Set requests with the signals on red wire.
Output chest contents to green wire.

[toxicc]

Feature request:

Can we please have it so we can type basic math operations into the number box for circuts. E.g. If I'm setting a circuit condition and click into the number box and start typing a specific number into the number field I would like to type 8*40*200 and then press enter and have it automatically register as 64000. Blender (which I believe Wube use for assets already) has this feature in every numeric field and it's awesome! If that creates a problem for division creating decimals, it could simply be rounded to the nearest whole number.



This would prevent having to do the operation in a seperate calculator mod or app and then type in the number into the circuit UI, and is really useful when dealing with high quantities such as 8 wagon train, 40 stacks perchest and that stacks to 200.

[computeraddict]

You don't get feedback if the signals are different for output and input.

We're talking about boxes. They have "request all incoming signals" or "output all contents as signals" for modes. There is no configuration that allows those to look at the same network without feedback.

[JohnyDL]

Now Imagine to have behind each output two check-boxes: "to red" and "to green", booth of them checked by default.
No more.
...
No - Just different outputs to different channels if ONE set of conditions is TRUE.

Okay so set of conditions are true you send some things to red some things to green some things to both.... okay that does make sense

But no you still make problems...

That is for me (as non English native) hard to understand.
If I read it right you don't like the feature because of someone might copy it in a place where it doesn't fit?
That's true for everything else: If you copy a combinator set up for copper in a place where it should control iron, it won't work.

Yeah and this is still the place why I think it causes problems. My suggestion wasn't about utilising the wrong logic it was about using the right logic and it behaving weirdly.... You copy a combinator that does all the logic for copper control to a place where you need to copper control inside something more complicated but you cannot trust the logic, right now if a combinator does the thing it does the thing it doesn't matter if you connect a green or red wire up to it, you get the same output no matter what.

You can't trust the logic because Green output may be different from Red output and it's not at all obvious why or when that might happen and if you barely understand it you're not encouraged to learn anything it just randomly works when you connect the copied comparitor with red wire but doesn't if you use the green... okay so the lesson learned is "never use the green wire" not "oh there's this weird setting"

You're also adding two lots of R/G check boxes for each output field that's not at all confusing and no one will ever mix up the two.

Yes I agree with you, that it comes to 4 possible "is my logic wrong"-cases. But this will always happen if you need two different outputs.

Not really if you have 2 separate combinators you only have 2x as much logic checking not 4x, You are certain where the Red and Green wires are connected, you are certain then that whatever output settings exist will go out on the single wire connected no matter the colour, and so the only thing you need to check is the logic on the input side but you might need to check it in two places...

Having a set of keybinds that let you copy and paste only the input logic or only the output logic could be useful to address your issue. Shift click is copy paste but maybe alt shift click will only copy/paste to the side of the combinator you're actively selecting, this would let you copy complex input logic from one combinator to another while not having to reconfigure the outputs

Imagine you have NOT done it the way I suggest.
What you need to do is to build two different combinators for each channel.

Every time you have to change or tune something on the conditions, you need to remember to do the exact thing in booth combinators.

Yes you would, and that's not necessarily a bad thing, and there are ways around it

• Have the logic that creates the true signal in one combinator and another that detects the true signal to convert into all the relevant outputs.
• Put all the signals out on both lines and have them filtered with another decider.
• Adding an output signal that's just there to trigger a second set of outputs to another location on another wire.
• Consolidating everything into one set of outputs and thinking about the problem differently

The reason you want the signals on different wires is that you want to do different things with each set of signals right?... it's possible to build in the logic for ignoring the signals you don't want into the combinators now too.

If you (or someone else on MP) has change a setting only in one combinator and forgot in the other one, it could get very complicated.
Due to the fact that devs are already on the way to add more complex logic to "conditions" you would be happy to check if combinator outputting to red has exactly the same conditions a the combinator outputting to green.

So you need to swap between those two combinators GUIs to compare. Or you copy-paste settings and reconfigure the output (because that is what is different).

Yes if I wanted different signals on different lines even if your idea was implemented I'd prefer to have separate combinators and ignore the feature because having the ability to reuse a combinator and not have to double-check the order of the wire outputs saves me time and mental energy.

Though I don't see any reason why I'd want to do that and couldn't get around it in some other way.

What's more I'm not even sure what you're asking for is even possible without completely rewriting the engine, the reason (to my knowledge) that combinators are 2 wide is because the combinators treat both sets of wires attached to the same entity in the same way, so the input and output sides of combinators are treated like separate entities with separate connections... I think it works this way because of something I saw with LTN but it was a long long time ago... I know they just added an ability to separate out red/green input signals but it'd make sense if that was done by tagging the data origin as red/green as it enters the combinator not actually separating the logic for green and red wires attached to the same entity. I might be wrong.

That is again hard to read for me.
But as far as I see, you will able to do that with new combinators. Because on the left side you will have equations to perform if conditions are true.
An there are multiple lines which implies that multiple equations are welcome.
The only thing whats currently not available is to select the direction of output - whats my suggestion.

Sorry it's hard to parse, I'm not always the best communicator. But we don't know anything about what they plan to do with new Arithmetic combinators other than the GUI update (I hope they do more)

What I suggested as far as we have had confirmed will not be possible, this is from the FFF



My suggestion is that you have new rows for additional math and lock some of the conditions in place....

AC.png (132.64 KiB) Viewed 1948 times

In this case the A in the left input and the Multiply are static. If you change one they all update to be the same thing... though I doubt it should look like this it's just an example

[Freddy404]

Feature request:

Can we please have it so we can type basic math operations into the number box for circuts. E.g. If I'm setting a circuit condition and click into the number box and start typing a specific number into the number field I would like to type 8*40*200 and then press enter and have it automatically register as 64000. Blender (which I believe Wube use for assets already) has this feature in every numeric field and it's awesome! If that creates a problem for division creating decimals, it could simply be rounded to the nearest whole number.



This would prevent having to do the operation in a seperate calculator mod or app and then type in the number into the circuit UI, and is really useful when dealing with high quantities such as 8 wagon train, 40 stacks perchest and that stacks to 200.

I like this. Also, while we're at it, can we get Hex input please, so bit fields are easier to set?

[Koub]

Feature request:
[...]

Feel free to make a dedicated suggestion here : Ideas and Suggestions

[TheRaph]

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.

You don't get feedback if the signals are different for output and input. Or the combinators and other entities could just subtract their own output from their input to get rid of the feedback.

Think of a series of requester chests for train loading. You want to read the content of current chests and set requests for missing item amounts.
Currently this is only doable by setting the requests on requester chest, transfering all the items from requester chests to a steel chests and use that steel chest to read the existing contents.

If they allow us to select multiple modes at the same time, that means you can read the content and set the content on one chest. And it can work for one chest only. To read the total contents of multiple requester chests, you will connect them with the same wire. Then their signals will mix with each other and with every item existing on a requester chest, the others will request more of that item.
To solve that you would need 2 combinators per requester chest to make the signals move one way only for both input and output signals which is worse than current solution of using steel chests to read the contents.

Being able to select the wire for the action solves this unexpected behavior in a nice and easy way.
Set requests with the signals on red wire.
Output chest contents to green wire.

This touches my suggestion. They are able to distinguish between wire-colors on input in current state of development.
So this should easily be applicable to requester chests.
If the also manged to separate the outputs it would be possible to have requester chest like you described it (and also select output for combinators).
Then you need a way to select input color and output color - in it would wore fine.

But you should have in mind, that selecting wire color could be result in problems when people doing copy-past actions and have the color-issue not inn mind (as JohnyDL stated above).

Yeah and this is still the place why I think it causes problems. My suggestion wasn't about utilising the wrong logic it was about using the right logic and it behaving weirdly....

Now I got it ...
But in my mind that little bit of mistakes possible doesn't overrule the advance of having less combinators to maintain - and therefore having less points of error in that place. But this is a very subjective meaning - so I accept that there might exist many different opinions who are not discuss-able on an objetive way (may the devs decide ).

My suggestion is that you have new rows for additional math and lock some of the conditions in place....

I think I now get the point. You like to have a formula with an variable "X" (like [input]*x), where x is different for each channel to output to.
So you like the possibility to change that formula once but keep the different x-es the same.
In my eyes it would be usefull in some cases. But on the other hand I believe most players did have problems with circuitry and that will make it worse.
But for those who got it, it will be a powerful tool.

[Feathowl]

A bit late to the posting party perhaps, but only got round to reading last weeks FFF post. But when reading about the selector combinator, my mind immediately went to odd places. The sudden thought of playing Wintergarten's "Marble Machine" music in Factorio using programmable speakers, programmed by items loaded onto belts by inserters sprang to mind. I have no idea how to make that work, but that Selector combinator at least seems to make indexing notes and delays in some 'song code' to load up a conveyor rather more feasible anyway. I look forwards to having fun with them!

[Qon]

A bit late to the posting party perhaps, but only got round to reading last weeks FFF post. But when reading about the selector combinator, my mind immediately went to odd places. The sudden thought of playing Wintergarten's "Marble Machine" music in Factorio using programmable speakers, programmed by items loaded onto belts by inserters sprang to mind. I have no idea how to make that work, but that Selector combinator at least seems to make indexing notes and delays in some 'song code' to load up a conveyor rather more feasible anyway. I look forwards to having fun with them!

You are not late at all!

You should make it!
Easiest way I think would be one belt for each tone, manually placing the items to compose the song and use items that don't trigger a note to play to play to maintain the space between the actual notes. It wouldn't require much combinators at all but could be a good intro to learning combinators for more advanced projects and feature additions later

[ThePiachu]

Would be nice if with Combinators 2.0 we'd get some logic latch - viewtopic.php?f=6&t=109813

[DarkShadow44]

Feature request:

Can we please have it so we can type basic math operations into the number box for circuts. E.g. If I'm setting a circuit condition and click into the number box and start typing a specific number into the number field I would like to type 8*40*200 and then press enter and have it automatically register as 64000. Blender (which I believe Wube use for assets already) has this feature in every numeric field and it's awesome! If that creates a problem for division creating decimals, it could simply be rounded to the nearest whole number.



This would prevent having to do the operation in a seperate calculator mod or app and then type in the number into the circuit UI, and is really useful when dealing with high quantities such as 8 wagon train, 40 stacks perchest and that stacks to 200.

I like this. Also, while we're at it, can we get Hex input please, so bit fields are easier to set?

Since no-one did it yet, I made a suggestion: Combinators: Allow more way to input numbers.

[Qon]

You don't get feedback if the signals are different for output and input.

We're talking about boxes. They have "request all incoming signals" or "output all contents as signals" for modes. There is no configuration that allows those to look at the same network without feedback.

True. But that was one example that wouldn't work for boxes but does work for most other things already.
The other examples, like feedback being made impossible on the same wire connection point, would work for boxes as well.
But it does make sense that boxes would have the same input wire selection feature that combinators 2.0 already have. And if feedback to same port is removed then output wire selector wouldn't actually be necessary.

[Koub]

[Koub] a section of this thread about combinator complexity was split off, and can be found here : viewtopic.php?f=5&t=XXXXXX and trashed.
[Edit : the split off part was trashed]

[DarkShadow44]

@Koub I only get "You are not authorised to read this forum."

[FuryoftheStars]

@Koub I only get "You are not authorised to read this forum."

That's because it got deleted shortly after (I'm guessing).

[Loewchen]

@Koub I only get "You are not authorised to read this forum."

It's trashed.