Friday Facts #384 - Combinators 2.0

[Kadet123]

I would like to get a specific tick (morning perhaps) on this surface. I made combinator based calculation of how much power does my anti-meteor defence need until morning and checked that the accumulators will last. This is based on number of ticks in a day, solar power multiplier, ammount of solar panels and ammount of accumulators.

Detecting when the morning starts for the first time reminds as a annoying problem left to solve and the solution is... not nice (after first morning the next arrives after certain number of ticks). I don't care if it is morning, sunset, sunrise, middle of the night, but give me something. Also, not Nautilus time but this surface time.

Wouldn't you be able to do this with an isolated solar panel, accumulator, and something with a small constant power draw? Once set up and charged, whenever the accumulator's charge is >= 99 its "morning", over the night the charge dips < 99. These 2 conditions could be set/reset conditions for logic (search for "RS Latch").

[vark111]

I'd like to +1 the requests to add an R/S and/or S/R latch to the Selector Combinator. I know we can do these with existing combinators, I do it all the time. Still a pain in the butt every time, though. A nice Latch section where you define a Set value, a Reset value, and an output signal would make a ton of circuits a lot easier.

[Freddy404]

Selector should have a feature to modify Logic Groups (TM).

This would effectively be a wireless transmitter, with constant combinators as receivers. While I'd like wireless communication (esp. some kind of connection across space, or at least planet to orbit), I think those should be their own structures, probably larger and more expensive.

The "Index" function in the new combiner orders the signals according to their size (ascending or descending).

I would prefer to be able to determine the order by myself. That would make some of my more complex circuits so much easier.

This is nice and all... but does this FINALLY give us a way to 'sanitize' our inputs?

Related question: can the new decider do something like Each@Red != 0 -> Each = Signal Value@Green

That's a dynamic whitelist. With the inverse condition, it's a blacklist. With a clocked selector over constants on the red input, this iterates in a custom order.
Of course, a simple whitelist is just a decider with a true condition and the appropriate outputs

if you have some ideas (for the Selector combinator) we would welcome them

How about some kind of unique-ID mechanism? That would be really handy in multiplexing signals from different parts of a mega-base, and is currently tricky to do. (The best way I know of is to leave a locomotive permanently parked at a train stop!)

Seconded, that's a missing piece that's hard to construct from existing (or announced) stuff in a fail-safe way.
Although the locomotive workaround is better than anything I came up with, and possibly fail-safe, just expensive in both space and resources. EDIT: and not fully automatable.

I'm also going to echo the demands for improved arithmetic, custom constant outputs and train composition readout

[Arch-kain]

Exited to play with these all new stuffs ♥

I would like to have a proper filter combinator too

Just place a Constant combinator with a -1,000,000 signal of every blacklisted item. = Blacklist.

Or place a Constant combinator with a +1,000,000 signal of every whitelisted item, connect to an arithmetic combinator with input "each", subtract by -1,000,000, output "each". = Whitelist.

This kind of thing works well for me, but signals have values limits (like 2.3G or something like that), so it sometimes prevent me to filter some signals

+ with the name "selector combinator" I think it's a good opportunity to have a proper way to do it ^^

[grandexar]

I love the new combinator design! I hardly ever use combinators though, I prefer the simplest solution. Most probablems in the game have simple solutions like filtered splitters, naming all train stations by hand, or just improving production levels to meet demand.

That being said, I’m interested to test out the new system!

I wonder if this will improve the experience of working with the nuclear reactor

[Philip017]

gonna have to see if i can turn a single decider into a RS-Latch right now it requires 4 deciders for me to get it to work, and i use those RS-Latches a bunch.

[TOGoS]

without having to close the GUI and hunt for the information in a nearby power pole tooltip.

Now that you mention it, that was some unnecessary friction.

Decider combinator 2.0

I may still pine for Mindustry-esque programmable computers, but this maybe accomplishes about the same thing, and with more immediate feedback. But wow, what a lot of parameters crammed into the GUI! Hopefully nobody goes and adds two more wire colors.

Arithmetic combinator

Now do arithmetic expression trees on that one.

Actually I always felt like the distinction between arithmetic and decider combinators was a bit arbitrary. They just have different sets of operators.

And this kind of thinking is how you get a programmable expression-based terrain generator.

The Selector combinator

Might need some contrived scenario to force me to learn to use it. At a glance it's not obvious how it works or why I would want it to.

Anyway, kudos on the improvements! The new FFFs have definitely re-sparked my interest in Factorio.

[Majiir]

This will probably be an unpopular opinion, but: I hope you will reconsider the logical changes to the decider combinator.

Combinator circuits are a huge part of how I play Factorio. My bases are littered with circuits for restocking outposts, routing trains, managing power usage, balancing production across the factory, and more. I've created awesome contraptions like Combinator Ethernet, a packet-based communications system for combinator circuits, or my train logistics system that creates the illusion of items instantly teleporting from one station to another, without ever deadlocking. (That one is amazing for Seablock.) I've easily spent 2000 hours just tinkering with combinators, and they hugely enrich the game.

The decider combinator changes absolutely make them a more powerful tool. In my opinion, they also make combinators worse as a game.

The fun of combinators is that they are a puzzle game. The puzzle pieces are simple, while the problems can be as simple or complex as you want to challenge yourself. Making a single combinator hold an arbitrary number of conditions removes two crucial constraints that make this puzzle game fun:

• More circuit complexity requires more space. The challenge of fitting designs into small spaces is a big part of what makes Factorio fun in general.
• More circuit complexity requires more (in-game) computation time. When you get beyond simple circuits, much of the fun is about optimizing your design so that your circuit can work in fewer ticks.

It would be similar to saying: A lot of players had trouble with moving resources around with belts, so we're making belts move items instantly and have no throughput limit. Now, belts are so much more useful and powerful! But they are less fun, because they are less of a puzzle.

Moreover, combinators already feel slightly detached from the rest of the challenges in the game. If anything, combinators should be made more entangled with the rest of the game puzzle; for example, by making combinators much more expensive, so that optimizing circuit designs can have a resource efficiency benefit for the factory as well; or by making them use much more electric power.

I usually just quietly enjoy the FFF posts, so let me just say Wube is my all-time favorite game developer, Factorio is my favorite game, and I love what you do and what you have built. You are masters of your craft. The UI changes here look great. My feedback to you on the combinator design is: You got it right the first time!

[EndOfHistory]

All of this looks amazing. There have already been several good suggestions here.

Is there a reason that we have n-ary decider combinators but only binary arithmetic combinators? The argument for n-ary combinators seem to apply for both.

... and another wish... red and green wires are really tough for the colour blind among us, which is around five percent of your male user base. There are mods for this, but I can dream.

[JAetherwing]

For me as a combinator enthusiast, this is by far the best FFF in a while (and all of them on Factorio 2.0 have been phenomenal so far). I cannot wait!
The documentation feature is such a good quality of life addition!

I have one remaining question about the selector combinator and that is how the sorting treats equal values. Are they sorted by item name instead or is it nondeterministic?

Since the FFF also asked for further options for the selector combinator, I'd like to offer a few more ideas:
- Selecting a signal by type (i.e. send stone=1 on the red wire and get at the output whatever the value of stone is on the green wire) You can currently do that for positive signals only with a subcircuit of four combinators and some integer overflow dark magic, so having the option to use a single combinator with built-in functionality for that would be amazing.
- Select the smaller or larger signal from the same type passed in on red and green (i.e. applying "smaller" to A=3 B=-3 on red and B=3 C=-3 on green would output A=0 B=-3 C=-3)
- Select from a list of signals sorted by type, not by value in order to be able to make lookup tables easily
- Does Stack Size work with the EACH selector? If not, that would be a great addition. Send in any set of signals and the output is the stack size of each of those values. Or alternatively (with a UI option) have the output be how many stacks the input would occupy.

In general with the red/green differentiation: it would be cool if arithmetic combinators could perform an operation on EACH from red and EACH from green individually, e.g. if input with A=1 B=3 C=2 on red and B=2 C=4 on green, a multiply combinator set to do this would output B=6 C=8 (since x*0=0 for A) This would also then be a substitute for the select by type combinator I suggested above. I guess it can be debated which combinator it fits better.

I hope some of those suggestions can be considered, but in any case I am already super happy with the changes announced!
Thanks to the amazing devs!

[pleegwat]

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 makes sense, particularly filtering properties like "Is an item signal", "Is a fluid signal", "Is a virtual signal". Though in this specific usecase, it would also expect filter inserters to simply ignore non-item signals.

[pleegwat]

It has some specific uses and modes (which is still subject to change):

a) Output the signal at the given index (sorted from biggest to smallest or vice versa).
b) Output the count of input signals.
c) Output a random signal from the inputs (with a custom update interval).
d) Output the stack size of the input item.
e) Output the rocket capacity of the input item (useful for Space Age logistics).
f) Transfer the quality of an input signal (more on that another day perhaps).

There is definitely a difference here between a-c and d-f.

a-c are actual selection operations. They take the entire set of input signals, and select a single one based on some criterium.

d and e are function calls. They're not operators in the sense of the arithmetic operator (since they return properties of the signal type, rather than operating on the signal values). Still I think it would be clearer to split them off to a separate combinator type. f may be in this category as well.

If an advanced arithmetic combinator becomes reality, then d and e should probably be included in it.

[Elbrac]

Love in the new combinators! I think one cool thing as well would be to have the power consumption increase with the more logic functions that are used

[<NO_NAME>]

[...] The second thing I'd like most is the ability to select certain properties from red or green only.. stuff like everything * everything would be a lot more useful if you could say "red everything * green everything".

YES. Vector operations, would perform out := green <OP> red for each channel at the same time. Yup. So many times I wanted to have this in the game...

Not you alone viewtopic.php?f=6&t=56890
It wouldn't be a bad idea to not limit this to just decider combinators but add it to all of them.

[Dagonfry]

Since the FFF also asked for further options for the selector combinator, I'd like to offer a few more ideas:
- Selecting a signal by type (i.e. send stone=1 on the red wire and get at the output whatever the value of stone is on the green wire) You can currently do that for positive signals only with a subcircuit of four combinators and some integer overflow dark magic, so having the option to use a single combinator with built-in functionality for that would be amazing.

If I understand it correctly, this FFF allows the decider combinator to be used as a "filter combinator"?

INPUT each > 0 (red wire only)
OUTPUT each input count (green wire only)

The red wire is the filter (any signal > 0 gets included) and the green wire get filtered. That will be an extremely useful construction.

[Ext3h]

What exactly is it supposed to mean when I check both "G" and "R" checkboxes on an input in the first place?

It it: The sum, the minimum, the maximum or a random choice I get as a signal?

For real, this not intuitive to grasp when the default is to implicitly perform a sum operation over different signal networks (a functionality belonging into the arithmetic block...)

That's also a catch with the input- and output signal selection dialogues. You act as if there was only 1 signal network - but there are 2. And all the counts you give as "ballpark estimates" are off if you already mix them up.

And also 2 output networks, so why not just double up on the output side and allow the configuration per output network?

You may now realize it's kind of counter intuitive to have 2 networks connected to the output side of any of the blocks. And so is the distinction between "red" and "green" networks when any of the more complex networks actually expect to have any count of networks in the same area, and being limited to red/green is a major pain point.

So why stick with this red/green scheme? Allow me to color a network, and allow me to name a network. Then allow me to connect any number of networks via a single electric pole, but restrict me to connect only two arbitrary ones to the same logic/arithmetic combinator. And then let me switch from the combinator dialogue which networks I'm using for in- and output, from the connected pole.

For all its worth, force me to select the network I want to extend when drawing logic wires, and make accidental network merges an explicit operation.

Visible connections should only follow networks, but not be defined by it.

[Daandriks]

Love this post. Circuit network is really hard to grasp for me. I did try but with this it is a lot more fun to use. And better to read. I hope they add the picker for red and green wires everywhere. So also on a inserter so that you can read the content on the red wire and to turn it off on the green wire. So that you can always pick on which wire you want it to send or use it from. Then it would be complete.

[mms92]

When ?
just when are we gonna be able to play with all this ?

super hyped by everything, can't wait !
GIVE IT TO ME

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

This is nice and all... but does this FINALLY give us a way to 'sanitize' our inputs?

It is already possible, with a constant amount of combinators.

when value in the slot is over 1000 it (I assume ) shows shortened version. Like 14k of Stones.
Can you make an mouse_over_tooltip which shows the exact number like 14 237 ?

Agree!

Add the possibility to output any other constant other than "1" and "Input count". How many times I have wanted to output a number other than 1, and had to restort to many signal-transposing shenanigans, and this would still be required with this magic new combinator...

This could be useful. But what about multiple output values? Doing it with additional combinators, same way it is done now, might still the best way. Doesn't mean that the feature is useless, just that it is worth considering that you might have to do a multiply after for many cases anyways because as described it is not as powerful.

I cannot wait to finally build myself a turing complete computer, maybe a lisp machine, compilers etc.
Tinkering around with optional stuff and all the options you have to your goal makes factorio the amazing game that it is.

There are few games that tell you so much about the personality of the player by only looking at their savegames.
Building a factory is a way of expressing yourself, like music, dancing, craftsmanship. It is ART

I'm writing an assembler for Factorio combinators v1.0 now. If you have the ability to do that then, just start now and enjoy the way they work now as well.

And please show us your creations when you do start

I'd like to see something like fCPU.
It's strange that there are automated trains and rockets, but one can't construct any FPGA =(
One has to work with a large pile of elementary “boxes”.

I'll release the prototype of my assembler soon

how about a roundrobin mode? while I don't really know how this can be useful, you certainly cannot miss round robin mode when you have a random mode

Can be done with the selector combinator and a signal that cycles through the indexes. Cycling through signals when you have indexing is trivial, randomness is not.

It is a useful way to output signals (like cycling through colors for a blinking lamp), but I'm not convinced it is that useful to be added as a mode inside the combinator since it can be done anyways. But doing it at a slower rate than once per tick would maybe motivate adding it?

There is just one feature I'm still missing for the Arithmetic combinator:
The Modulo operation
With the current operators it's just not possible to get the correct Modulo, as rounding causes it to behave weirdly.

Wrong! % is modulo.

Operations like Floor and Ceil might be useful to instead of rounding, but I personally don't have a Use Case for them yet

How do you floor, ceil and round integers? To other larger intervals? Or for other rounding modes when doing division than floor? It's not clear what you are requesting.

I will give you 8000 blue circuits if you make a tutorial series for the combinators for us noobs who have problems using them and would like to learn.

The wiki has combinator tutorial. Are you asking for an in-game tutorial?

The "Index" function in the new combiner orders the signals according to their size (ascending or descending).

I would prefer to be able to determine the order by myself. That would make some of my more complex circuits so much easier.

If you filter out the signals you want from the order definition (signals with different values), then select the smallest/largest, force that to 1 and do another selection then you will achieve this with a handful of combinators v2.0 as described already in the FFF.

The thing I'd like most from the circuit network is not having to worry about UPS for constant uses. For example, using an arithmetic combinator to negate the contents of a constant combinator. This heavily disencentivises clean separation of circuit logic and nerfs blueprintability.

The second thing I'd like most is the ability to select certain properties from red or green only.. stuff like everything * everything would be a lot more useful if you could say "red everything * green everything".

These would both be useful. I have some big combinator creations. I wish a million combinators wouldn't constantly compute the same value over and over when the inputs are fixed. Any combinator performance update would be better than any other feature added (though features that add more capabilities can improve performance by reducing combinators) so that you can actually use them.

And each on green wire multiplied (or other operation) with each corresponding value on red seem like the first feature to add if you want more capable combinators.

if you have some ideas (for the Selector combinator) we would welcome them

How about some kind of unique-ID mechanism? That would be really handy in multiplexing signals from different parts of a mega-base, and is currently tricky to do. (The best way I know of is to leave a locomotive permanently parked at a train stop!)

Constant combinators can with logistics groups share the same value to all other constant combinators. If the logistics group can also be influenced by input signals then we have global variables which can be incremented to generate new unique IDs. And the random mode of the selector combinator can be used to resolve ID conflicts, deciding which circuit should pick a new ID and which one should keep it. But I don't know if logistic groups can get input signals or if they are limited to values set in GUI on the constant combinators. That seems likely from how it has been written. And constant combinators storing constants instead of variables seems obvious from the name.

I would like to get a specific tick (morning perhaps) on this surface. I made combinator based calculation of how much power does my anti-meteor defence need until morning and checked that the accumulators will last. This is based on number of ticks in a day, solar power multiplier, ammount of solar panels and ammount of accumulators.

Detecting when the morning starts for the first time reminds as a annoying problem left to solve and the solution is... not nice (after first morning the next arrives after certain number of ticks). I don't care if it is morning, sunset, sunrise, middle of the night, but give me something. Also, not Nautilus time but this surface time.

If the selector could give surface nychthemeron tick length and solar panel efficiency then I could make a accumulator that blacks out at tick 0 (when light starts increasing). So to me that seems more useful, then I get the ability to get both. But I guess you could get the surface stats with the numbers you requested as well. Maybe both are useful.

I would like to have a proper filter combinator too

Just place a Constant combinator with a -1,000,000 signal of every blacklisted item. = Blacklist.

Or place a Constant combinator with a +1,000,000 signal of every whitelisted item, connect to an arithmetic combinator with input "each", subtract by -1,000,000, output "each". = Whitelist.

This kind of thing works well for me, but signals have values limits (like 2.3G or something like that), so it sometimes prevent me to filter some signals

+ with the name "selector combinator" I think it's a good opportunity to have a proper way to do it ^^

Use 2^31-1 instead of 10^6 then, so it works for all values. Don't pick X and then complain that it doesn't work for values larger than X, the specific value you picked. If X is largest value possible then the issue you created is removed, because there are then no values larger than X.

I have one remaining question about the selector combinator and that is how the sorting treats equal values. Are they sorted by item name instead or is it nondeterministic?

Deterministic, of course.
It will fall back to the [virtual-signal=signal-anything] decider output behavior. That's not item name, it's signal selection menu "order" property, and internal hidden property.

[Molay]

Considering I'm a programmer, I really don't use combinators unless I really need them for a specific use case. I always found it very cumbersome. I don't write conditions like I'm trying to solder them on a circuit board when I work, so I found combinators hard to wrap my head around. Looks like now I can use complex conditions to do what I want without causing an aneurysm, I'm very grateful for that. Thanks for thinking of the dumb-dumb programmers that don't have a doctorate in microelectronics.

I really, really wish I had this feature right now for my SE playthrough. I've been on it for hours trying to sort arcospheres... lol