Friday Facts #384 - Combinators 2.0

[JohnyDL]

The function is indexing signals to process them one by one in some additional logic.

Is there a problem in 1.1 that the selector combinator would solve? I don't understand what is meant by the above quote. If you want do do the same thing for every input signal, that's straightforward. If you want to do X for the first signal (in the arbitrary signal order), Y for the second, and so on, you can do that today though it takes 3 combinators per signal you separate out. I guess doing that with 1 instead of 3 is nice?

Or does kovarex/Klonan mean something entirely different that I don't understand?

To my knowledge if two values are the same it's very difficult to separate them with Each, Any, Every type operations. You can for sure separate signals out by selecting the exact signal type and dealing with each signal separately, great if you have like 4 signals but it takes a lot of combinators if you're dealing with a list of all items, sorting and taking a single signal out of an arbitrary list of signals is not otherwise easy or fast, if you know how to pick out one signal out of a list of 40 with the same value in a handful of combinators I'd be glad to learn it.

If you want to say have a different train pick up each type of item you want to select each item one at a time, and set filter inserters, you only want to have one item type on each train so you want to have a way of isolating each signal... you may want to do the same thing for each input signal but you need to process them one at a time or you end up with trains containing multiple things.

Alternately you might want to do different things with each item, maybe you want to send each item to a different train station, you want to load the closest with the thing you have the most of the next closest with the thing you have second most of etc.. you want to send the signals in different directions and again you need to only be dealing with one signal at a time and so you need them to be separated out.

The key thing to both these tasks is that you don't know ahead of time what the signals you might have to separate are and any operation you do has to be able to separate signals which carry the same value to send them in different directions and you might only be able to process one thing at a time.

In the expansion, this is necessary for organizing rocket supply launches as they can only have one item in their cargo at a time.

[Phantum]

Are we getting a "wait" feature added into our combinators now?

[protocol_1903]

Underground belts seems can only supply content. I doubt it would be useful to change moving direction.

I meant it like how belts and circuits work, where they can be enabled/disabled and read belt contents. Switching directions seems a bit too niche and out of the way, as it would make more sense to add this to normal belts first/only.

[Nidan]

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

As long as the order is left to the game this won't look too different between 1.1 and 2.0. Since 1.1.13 a decider with output anything will output exactly one matching signal, this matches a selectors select 0, but without the sorting. The main benefits of the selector I see are the builtin sorting and it should be quite a bit easier to get the timings right.

Assuming you filtered interesting signals beforehand (e.g. each > 0 -> each 1):
2.0: latch/memory — select index — index + 1 -> index, connect back to select; each + index -> each — filter out index — output latch. reset once index >= count
1.1: latch/memory — each != 0 -> anything 1 — 0 - each -> each, connect back to latch/memory; each + index -> each — index + 1 -> index, connect back to each + index; filter out index — output latch. reset once input latch/memory is empty



Edit: Some general FFF feedback, since I just wrote it in another thread:
I feel the selectors "rocket capacity" mode is a bit out of place as there will certainly be mods adding higher capacity rockets; I'd have "item weight" instead and a rocket silo could output "maximum cargo weight". "Rocket capacity" is then the division of those two.

[mmmPI]

[*]Fliter/Sanitising Inputs -> If I only care about item data I can sanitise inputs by using the selector, get the stack size, and then a decider, if each stack size (green) is >0 then send each item data (red) to the output, as the stack size on signals I'd assume to be 0, this can also be done in reverse to get only signal data, though I'm not sure what fluids would do without having the ability to test. But you can also use inputs from a constant combinator to get specific outputs too.

That make sense "if i only care about item data", which for the case of removing virtual signal attached to train lengh or composition, ID or limit could work i expect too that signal stack size be 0. But it's still unclear to me if what you describe wouldn't lead to some implicit additions of what's on the green and red wire before it's output. Do we have the possibility to transfer the item data (red) untouched ? Or are we just given the ability to specify the output color for a logic that would be same as 1.1 for the summing of signals quantity ?

In other word , the output will be "EACH", does ticking "red" or "green" for output is going to yield the same result on a different wire, or also a different result ?

Part of the questionning was about the ability to use red as control signal to choose amongst what's in green. In such case, if things work as you say, then for fluids it wouldn't matter that they have no stack size since it would be like using a constant combinators to have that control signal on red, but it feels more interesting to think about the possibilities of having something dynamic here to me

[Upserter]

Indexing and selecting seems like a nice, useful, orthogonal piece of functionality. The rest of the items (like stack size and rocket capacity) seem unrelated. I wonder if you should break those out into a separate “Utility Combinator” that could be the holding pen for miscellaneous combinator functions.

And of course, I’m keeping my fingers crossed for the Lua Combinator.

[blazespinnaker]

should have been a code combinator. just cut to the chase

[Sad_Brother]

On top, you probably didnt think about new players. The new menu looks intimidating right at begining. When new player connect first wire and see massive menu with all the buttons, natural reaction is - run away.

Would you cosider combinatioin of old (minimalistic on start) method AND the new linked_method ?
Start with old small mennu, when one option is checked, then apropriate section popups next to it.

I think it is possible to split Combinators to 1.0 and 2.0 Technology.

First Tech open ability to use Combinators almost as now. With slight changes only.
Tech Combinators 2.0 change Combinator's GUI to new version. Settings converted automatically. So new players would see how it looks in new interface.

Best wishes!

[Freddy404]

On top, you probably didnt think about new players. The new menu looks intimidating right at begining. When new player connect first wire and see massive menu with all the buttons, natural reaction is - run away.

Would you cosider combinatioin of old (minimalistic on start) method AND the new linked_method ?
Start with old small mennu, when one option is checked, then apropriate section popups next to it.

I think it is possible to split Combinators to 1.0 and 2.0 Technology.

First Tech open ability to use Combinators almost as now. With slight changes only.
Tech Combinators 2.0 change Combinator's GUI to new version. Settings converted automatically. So new players would see how it looks in new interface.

Best wishes!

In my opinion, that depends on what the goal is with regards to new players. I see how the new UI can feel more overwhelming than the old. However, I think its better at making actual circuit designs less overwhelming. A player that runs away at the new UI probably wasn't going to get very far with the old UI anyway. So I would also advise against a two step process - just keep the new UI, it should make it far easier to get into complex circuits. It seems an okay tradeoff to make very simple circuits have a slightly heavier UI.
Like, with the current announced state, as soon as you want to check multiple conditions before emitting something, the circuit gets simpler in 2.0. And something similar might happen for arithmetic combinators, i.e. calculations, as well.

[joeykins]

This is nice and all... but does this FINALLY give us a way to 'sanitize' our inputs? Specific case: I was working on making a station using LTN that would allow me to load multiple types of cargo. The problem is that LTN's station, alongside expected cargo, also dump out a whole bunch of other data. And as I was using filter inserters with set filter, this could lead to them trying to set their filter to a signal instead of an item. If I were able to 'sanitize' my input, this would be a lot less cumbersome. Because right now the only way I could would be to add an arithmatic combinator which multiplies the values of all the data I didn´t want by -1. I think a nice feature for the 'selector combinator' would be to specifically filter out either groups of signals (so u can filter out any 'non-entity' signals like letters) or specific values, though a group would be most useful in my specific case.

This is functionality that feels like it's currently missing from the selector combinator. The decider can filter based on the signal values, and an arithmetic combinator can essentially filter based on the signal but it requires 1 combinator per signal. A "filter signals" mode where we can choose which signals to include/exclude regardless of their value definitely feels like something that the selector combinator could and should do.

[JohnyDL]

Oh, that's an illustrative example! Picking the first item (in signal order - the order displayed in the tooltip) just takes one combinator. So if you move all of those to the train, and no more arrive, then that's easy: just repeat.

Just separating them out in signal display order just takes 3 combinators per output signal though, and you don't need to know the potential signals ahead of time, so that's no so bad.

As long as the order is left to the game this won't look too different between 1.1 and 2.0. Since 1.1.13 a decider with output anything will output exactly one matching signal, this matches a selectors select 0, but without the sorting. The main benefits of the selector I see are the builtin sorting and it should be quite a bit easier to get the timings right.

What you said taught me that Anything != 0 => Anything puts out a single (kinda random IMO) signal I didn't know this before but it makes putting out a signal onto different wires O(N) where N is the number of signals with just 1+3(N-1) Combinators, it doesn't sort them but at least it separates them. Good to know

But if you need to cycle through them while they keep changing, yeah, that's rough. But I'm not sure the selector solves that, since the order changes when anything drops to 0, unless it makes a snapshot of it's input (which sounds overly CPU-intensive). Still, I see how it would help.

You can put the list into a memory cell and then cycle 0-N and then when N+1 relatch that's possible with just a handful of 2.0 Combinators, might be as small as 3 but I can't test it right now obviously. But I'm already thinking of like 10 different even smarter ways to handle it too, every one relies on the Selector to provide a sorted list and then you can pick an index out of that list.

Yeah, sorting by signal value is hard today, impractical unless you have a small number of possible signals you care about. Doing that in the straightforward way for N signals takes N^2 combinators. You can do it in O(N*lg(N)) combinators, but it's ... other than straightforward.

In 2.0 filtering will be O(log(N)) because you can filter half the items at a time....

[*]Fliter/Sanitising Inputs -> If I only care about item data I can sanitise inputs by using the selector, get the stack size, and then a decider, if each stack size (green) is >0 then send each item data (red) to the output, as the stack size on signals I'd assume to be 0, this can also be done in reverse to get only signal data, though I'm not sure what fluids would do without having the ability to test. But you can also use inputs from a constant combinator to get specific outputs too.

But why don't you know the potential signal ahead of time? It's your base, after all. But maybe that's a playstyle thing.

For Rockets I understand that you get told what your platforms need. You can 'know' ahead of time what resources you might need to send and have a single silo for the different resources you might need to launch or you might want a dynamic system that can do 30 or 40 or Any different resources with just 2 or 3 rocket silos, and you might want to do the things you can do a Full Load for first... there's a bunch of ways to math those signals to get which rockets need full loads with the Selector combinator providing statistics. For 1.1 though, it's being able to do LTN type stuff with Vanilla (which is already doable but kinda hard), you might 'know' but it might still be every single item type you put into the train network which could be a lot of items.

The reason you 'might not know' is that you might change your mind after the fact, you might start building thinking you know exactly which items you want, and then suddenly discover "Maybe it's more efficient to add Iron Gears to the network rather than Crafting them from Plates every time" but if you hard code the system at the start then adding in a new type of item could be a mess, if it's dynamic then you don't have to worry about adding a new item you just do it and the system automatically adapts

That make sense "if i only care about item data", which for the case of removing virtual signal attached to train lengh or composition, ID or limit could work i expect too that signal stack size be 0. But it's still unclear to me if what you describe wouldn't lead to some implicit additions of what's on the green and red wire before it's output. Do we have the possibility to transfer the item data (red) untouched ? Or are we just given the ability to specify the output color for a logic that would be same as 1.1 for the summing of signals quantity ?

In other word , the output will be "EACH", does ticking "red" or "green" for output is going to yield the same result on a different wire, or also a different result ?

I answered this in that same post, and the answer looks to be a clear YES you can output only what was input on one of the wires with a 2.0 Decider without it being modified by the other wire. I thought that the intent from the pictures on the FFF were clear but others are confused by what the output R/G selectors mean...

• All the new places you see the R/G check boxes refer to the inputs, if Red is selected then it only looks at the inputs on the red wire, if Green is selected it only looks at the signals on the green wire, and if both are selected then it looks at the sum of these two networks (which is the current/legacy behaviour) and I'd assume if neither were selected all signals would be 0.
• When R/G are selected on the output side it means "copy the signals from the [input] R/G network" (with those same input rules [Red/Green/Sum/Neither]) to all connected outputs this is why it's in line with the 'input count' because it's referring to just the input, not where to put the output.
• To control what network is outputted you need to connect either a Red or Green wire to the output, you can already [in current/legacy] select to output only on Red or Green or on Both or on Neither this way. [so you don't need another way to select it inside the combinator]

I think it's obvious because where the signal is outputted is already controlled by what signal wires you connect. Why would you need toggle switches inside the combinators too? Simply disconnect the wire if you don't need that output.... imagine the confusion that could be caused if you connect up only the Red output wire but copied something set to output only on Green within the combinator and didn't spot this mistake.... That'd be extremely clunky UI design that I'm sure the Devs here would catch with their attention to detail (This is why I was confused by the number of people asking for different things to be output from the same combinator onto different wires, it could cause massive unintentional headaches with copy and paste functions, having 2 combinators in that case is simple *with copy/paste of settings* cheap *combinators don't really cost anything* and doesn't cause confusion)

Meanwhile, the utility of getting to select what inputs will be transferred to the outputs is self-explanatory.

Part of the questionning was about the ability to use red as control signal to choose amongst what's in green. In such case, if things work as you say, then for fluids it wouldn't matter that they have no stack size since it would be like using a constant combinators to have that control signal on red, but it feels more interesting to think about the possibilities of having something dynamic here to me

It might matter for fluids depending on how people intend to use the thing, if they have 4 different trains going to the same station and want to control which pumps connect depending on what is already on the train that might require filtering... but you can always set/adjust the filter manually for fluids with a constant combinator whether fluid stack size is default 0 or single pipe capacity or single barrel capacity or tank capacity (since there are so few fluids this isn't really a barrier)

This is functionality that feels like it's currently missing from the selector combinator. The decider can filter based on the signal values, and an arithmetic combinator can essentially filter based on the signal but it requires 1 combinator per signal. A "filter signals" mode where we can choose which signals to include/exclude regardless of their value definitely feels like something that the selector combinator could and should do.

In 2.0 this is possible with the Decider Combinator, Have the Filter signals on one wire the data on the other wire, For Each Select Signal !=0 Output Each Data Siganal (my other self quotes in this post explain in more detail)

[martinito12]

I love it!
Maybe someone posted something similar already but I see two immediate additional (probably easy features) that would be awesome:

• In the decider combinator: Why allows only a constant signal of 1? A small textbox, where I could configure a different constant value would be awesome it just defaults to 1!
• A built in blueprint category, where I can say this is decider of "type A" with description and everything. Changing the template would change every decider of that type. That would adapting circuit networks so easy and would go just nicely together with the constant combinator features introduced in one of the previous fff.

Anyway: Cant wait for playing with the new toys

[Nightmare Sky]

I suggest adding delay combinators. The entire stream of signals that will come to the entrance to this combinator will come out of there only, for example, after 5 (or any other custom value) ticks.

[joeykins]

This is functionality that feels like it's currently missing from the selector combinator. The decider can filter based on the signal values, and an arithmetic combinator can essentially filter based on the signal but it requires 1 combinator per signal. A "filter signals" mode where we can choose which signals to include/exclude regardless of their value definitely feels like something that the selector combinator could and should do.

In 2.0 this is possible with the Decider Combinator, Have the Filter signals on one wire the data on the other wire, For Each Select Signal !=0 Output Each Data Siganal (my other self quotes in this post explain in more detail)

It's great that it's possible, but that workaround feels cumbersome and considering that the new combinator is named the Selector it feels counter-intuitive to be performing an operation like this on the Decider.

[Nightmare Sky]

I suggest adding a filter combinator. This combinator will take as a filter the types of signals from, for example, the green wire and pass these types from the red to the output. Or skip those that are not specified.

[mmmPI]

I answered this in that same post, and the answer looks to be a clear YES you can output only what was input on one of the wires with a 2.0 Decider without it being modified by the other wire. I thought that the intent from the pictures on the FFF were clear but others are confused by what the output R/G selectors mean...

I am guilty of not trying to decipher everything from your long post that i thought had part only adressed to others, i'm one of the confused too ! , a second read rectified that. It's been the third time someone says like you when i expressed my doubt, so i'm more and more enclined to believe what you say is how it's going to be ingame.

Part of the questionning was about the ability to use red as control signal to choose amongst what's in green. In such case, if things work as you say, then for fluids it wouldn't matter that they have no stack size since it would be like using a constant combinators to have that control signal on red, but it feels more interesting to think about the possibilities of having something dynamic here to me

It might matter for fluids depending on how people intend to use the thing, if they have 4 different trains going to the same station and want to control which pumps connect depending on what is already on the train that might require filtering... but you can always set/adjust the filter manually for fluids with a constant combinator whether fluid stack size is default 0 or single pipe capacity or single barrel capacity or tank capacity (since there are so few fluids this isn't really a barrier)

To me the intend could be for modded games with many fluids, the constant combinator in the expansion will have the logistic group thing which allow to modify them all anywhere they are from one location in a few clicks that's powerful even to deal with many fluids (at least for me).

I have hard time finding scenario where it would not be possible to read train content to get signals, then unlock the pump for the most missing fluid if the train has different fluid in its different wagon. I didn't see that as a place where signal contamination with virtual signal would be problematic/ require filtering. But i understand what you say that it may be the intent of some players or a consequence of their build to require such things if the MIN or MAX signal is the train ID or something instead of the expected fluid due to compact wiring then stack size is not working to filter the useful material= fluid + item without virtual signal.

Single pipe capacity considering mods can add new pipes would not work as it wouldn't be linked with the fluid itself, barrel or tank capacity similarly i think , 0 seem a logical hypothesis for what stack size of a fluid will be.

This was related to the ability of doing (red)*(green) for the same purpose of sanitizing/filtering signals in my mind. What you (and others) explained makes it possible to do the filtering in a way that wouldn't require (red)*(green) operations added to the arithmetic combinator for the purpose of filtering. The fact that it wouldn't work with stack size of fluids is not making the method less valid as if you were to use (red)*(green) to have only simple number in the control signal you'd have to find a way to replace what using stack size does for non-fluid anyway.

I'm still under "impressions", but although it seem a good way of filtering, it seem still not as powerfull as pairwise operation on arithmetic combinator for which signal filtering is only one purpose. It will take me some times to learn all the new possibilities people find with the new combinators though, some may include simplification for pairwise operation, or provide an alternative way of achieving the same task that would have required one such as signal filtering and multiplication.

[IcedLance]

Is there a chance that some of these recently teased QoL changes will make it into the base game before the expansion release?

[JohnyDL]

It's great that it's possible, but that workaround feels cumbersome and considering that the new combinator is named the Selector it feels counter-intuitive to be performing an operation like this on the Decider.

You're right I'd split the Selector as is to a Sorter Combinator and a LookUp Combinator, since those are the two functions it seems to have, have the Sorter do the sorting type operation Though if you think of Select as Choosing a single ONE piece of data rather than Selecting ALL data that meets some criteria (which is what Deciders do they decide to let all valid signals pass or make other logical decisions) the Selector/Sorter combinator with "Outputs a single Value from the given inputs put in various orders" count, menu order, random, green by red etc...

The LookUp Combinator would "Look Up Stats about the given inputs" be that stack size, rocket cargo limit, train wagon limit, play-time, Surface Time/Stats or production/usage stats etc...

I am guilty of not trying to decipher everything from your long post that i thought had part only adressed to others, i'm one of the confused too ! , a second read rectified that. It's been the third time someone says like you when i expressed my doubt, so i'm more and more enclined to believe what you say is how it's going to be ingame.

All is good I even self quoted in the middle of the response to you and gave a more specific set of reasoning for why I believe it to be the way I've explained in between the two times I quoted you

To me the intend could be for modded games with many fluids, the constant combinator in the expansion will have the logistic group thing which allow to modify them all anywhere they are from one location in a few clicks that's powerful even to deal with many fluids (at least for me).

My question arose mainly from right now we don't know what the "stack size limit" function would output if you fed in a fluid signal, if it is 0 or if it's something else it might need special handling, we can't know that unless the Devs tell us or we get our hands on these combinators ourselves. I can't answer it. Yes you can handle fluids as hardwired special cases but I couldn't tell you how the filter I proposed will interact with fluid signals from the information we have available.

I can contrive many scenarios but explaining all the ifs and caveats of when each scenario works and with what assumptions about the stack size output is not really worth the time.... I can see that it will matter for the LTN mod, especially with some other overhaul mod like Bobs/Angels which might have a million fluids.... but how to deal with that depends on implementation details we don't know

Single pipe capacity considering mods can add new pipes would not work as it wouldn't be linked with the fluid itself, barrel or tank capacity similarly i think , 0 seem a logical hypothesis for what stack size of a fluid will be.

This is the argument for why "Rocket Cargo Size" doesn't make sense and it's nonsense IMO if a Vanilla X is the standard look-up value then any modded X is going to be some function (likely a simple multiplier) applied to that value, it might be moded things have a capacity that's +10% or 2x or 10x as big but it wouldn't make sense for the each item to just have a fully customised new value in the modded location for every single item it makes things needlessly complicated to mod... you might do it for limited groups of things like maybe you have a speciallised refined resource rocket that can launch plates at 10x and everything else at 0x but going through every single item and going "I want this to be 10000, that to be 2300, another to be 45" one by one probably isn't worth it to the mod developer and would detach the mod experience from the base game. For the Selector Output though so long as it is consistent behaviour for all fluids then it doesn't actually matter what the precise values are you can adjust for them with constant combinators.

This was related to the ability of doing (red)*(green) for the same purpose of sanitizing/filtering signals in my mind. What you (and others) explained makes it possible to do the filtering in a way that wouldn't require (red)*(green) operations added to the arithmetic combinator for the purpose of filtering. The fact that it wouldn't work with stack size of fluids is not making the method less valid as if you were to use (red)*(green) to have only simple number in the control signal you'd have to find a way to replace what using stack size does for non-fluid anyway.

I'm still under "impressions", but although it seem a good way of filtering, it seem still not as powerfull as pairwise operation on arithmetic combinator for which signal filtering is only one purpose. It will take me some times to learn all the new possibilities people find with the new combinators though, some may include simplification for pairwise operation, or provide an alternative way of achieving the same task that would have required one such as signal filtering and multiplication.

I totally agree there are other ways of doing it especially with pair wise arithmetic combinators, and they have other functions too, like for example converting a whole storage array (or available in the logistic system) to a number of rockets that could be supplied with on-hand materials requires dividing the materials by their respective rocket cargo limit, you can do the same with train stations, you can ensure that when you don't have a 100% load you launch the load with the highest % available. And that's just 2.0 Rockets there's so many more operations you can do like Red-Green in one combinator or multiplying all red by some A on green but not letting the A^2 into the output which would require extra sanitising.... it's a super powerful tool with many more applications, I was just addressing that this one aspect has existing ways to do it (and checking a True False is gonna be faster than doing multiply operation so impact UPS less)

[JohnyDL]

I suggest adding a filter combinator. This combinator will take as a filter the types of signals from, for example, the green wire and pass these types from the red to the output. Or skip those that are not specified.

This is possible with the 2.0 Decider if Control signal on Red != 0 then the Data signal on Green can be sent to the output

[Freddy404]

Something else I realized would be awesome to have in a single combinator: random numbers, possibly with a range.
(Ab)using the random signal selector combinator needs signal input (which limits the range/resolution to the total number of different signals), and possibly folding the different possible signals back into one (if that can't be implicitly handled by whatever circuit this flows to).
For example:

to generate a random 32 bit number on signal 'dot', we could have a pair of constant combinator and selector for each byte (assuming the total number of signal types eclipses 256). Then, a single arithmetic combinator each * 1 -> dot to fold the signals together.

Now a footprint of 14 Tiles is not excessive, but if we're simplifying/shrinking stuff down, this seems like a good candidate.