Friday Facts #384 - Combinators 2.0

[FuryoftheStars]

Will the next version of Factorio be a free update?
If not - how much?
And when will be the release about ?

https://factorio.com/blog/post/fff-367
https://factorio.com/blog/post/fff-373

[Saphira123456]

I will personally never use the circuits as I have found them too complicated to use in-game and the tutorials on them, both in-game and outside it, have all been insufficient. Like one other person, this has led to me building multiple, small, simple, scaleable outpost-style bases for mining and drilling, and connecting them to my larger central hub with trains.

If the circuit network is one-hundred-percent necessary to complete the game in 2.0, then congratulations Wube, you just lost a customer. I will continue to use 1.1.

I wish there was a "circuit network simplified" mod that made the circuit network as simple to use as the train GUI with excruciatingly-simple logic gates - AND, OR, XOR, etcetera. Then I would actually use the network. I'm sure a lot of people will agree.

Honestly, that mod you want is what this FFF is about.

There's some more complicated stuff but it's largely about making Decider Combinators a lot more simple to follow and work like the train network. You get all the ways of comparing numbers =, !=, >, <, >=, and <= plus you can do AND and OR logic within one combinator, it shows you all the actual values you're trying to compare, it lights up green if a condition is met and you build all the other logic you want for a lot of decisions into a single unit.

And while I do enjoy circuits I can acknowledge that circuits currently/legacy are unintuitive and needlessly complex for many things, the Devs said there were conditions it was almost simpler and faster to use the train network to control, and so they made Decider Combinators more intuitive and easier to follow. They might LOOK more complicated but for anyone familiar with setting up train logistic conditions it should be a much easier learning curve.

I understand you don't like them and you won't use them as they exist right now you're welcome to play any way you want and I can think of several ways it might be possible to do the space platform side of 2.0 without circuits at all, especially if you can do the math ahead of time and deal with a little inefficiency, if you know it takes exactly list of resources to make 1000 science in space, you build the rockets to send those resources all at the same time and wait to do it again until you have the exact resources for another 1000 science or screw it send up full rockets and dump stuff you don't need overboard. I don't think there'll be a single aspect of the game that you must use to complete the game that isn't a keystone action, there are only a handful of recipes that require any buildings and you have to put science in a lab to do research and make power with a steam boiler but for everything else you could theoretically hand mine and hand craft your way into science. You can do factorio with some rediculous challenges and there are a few youtubers that're dedicated to exactly that.

I'll make you a deal though, since I plan to buy the game either way, if I cannot beat the entire game and get 100% of the new achievements (probably with different runs) without using a circuit wire or combinator somewhere in that time then I'll let you know so you can save your money if you're honestly going to have a bad time buying the game for that reason I think the devs wouldn't mind losing a single sale.... I wonder if the mods would add no circuits as an achievement just for you though

To be perfectly honest? I don't mind circuits and extremely simple logic. However, I've already beaten 1.1 without using a single circuit.

I don't care about achievements, and I play modded so I don't get achievements anyway.

When you start getting into programming, like with current and future circuits, that's an insurmountable problem for me.

[wild_dog]

First off, LOVE it!

Before, there was no way to select select out a single signal, if there were multiple signals with the same value, and you and no other source telleing you what signal to use. This sounds convoluted, so let me explain:

I had a bunch of random signals, and I wanted to select the smallest of these signals, but only 1 specific signal at a time, which was near impossible.

I had a cirquit that would itteratively find the smallest signal.
It would do: Calculate the average value of the input signals smaller than grey, and output this on grey. If grey = 0, grey = max int.
First itteration, it would calculate the average of all signals.
Seccond itteration, it would remove signals above this average, the new average becomming lower.
This repeats untill the average value = the smallest input signal.

However, if 2 different signals had the same smallest value, this cirquit had no way of only selecting 1 of the 2.

I could combine this with a cirquit made up of 5 combinators that could do: Output the signals in X, with the value from X, that are also in input Y.
Basically a filter cirquit.
But it only worked with positiv signals.
If i wanted it to work with negative signals, I would need 12 combinators (same cirquit for pos and neg, and inverting and back).

This cirquit could take the 2 smallest and output only 1 of them, but then still it required some way of only inputing 1 of the 2 to the Y input, and I had no way of selecting only 1 of a set of input signals, which have the same value, for which I had no other external information.

I managed to get around this by making a self learning item ID ROM: a pretty complex, modular cirquit and chests desin, that would assign a unique index to every item it stores, and also store a single stack of that item.
It would be fed by looking which items are in the logistics network, which didn't have an ID yet, and making sure that an ID is only assigned as soon as a full stack is also stored.

Using these unique indexes, When confronted with 2 signals of equal value, i could disambiguate them either by selecting the one with the largest/smallest ID from the ROM, or just cycling over all items in the ROM.

The 'select index' function saves on THIS ENTIRE GIANT MESS OF CIRQUIT DESIGNS!



Lastly, I'm not sure if this has already been mentioned, but a filter functionality (select from, Red/Green input, all items for which there is a Green/Red imput, or maybe even have the second half a conditional (each >/</=/!= signal/value)) in a single combinator would also be AMAZING!
EDIT: Actually, having the option to either whitelist or blacklist based on the second input would make it even better.

And I can second the request for a delay signal.
That would simplyfy if you have multiple processing lines in paralell but where 1 is (much) faster than the other.
Needing to chain a lot of comparators that do nothing just to synchronize it again is a pain as well.

[JohnyDL]

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

You select WHERE to output by the cable(s) you connect to the combinator
You select WHAT to output by the tick boxes in the combinator menu

If you want to output only from the red input channel you select the red tickbox in the output side of the combinator and not the green checkbox, and if you want to send it to only the green cable you connect a green cable to the combinator but don't connect a red one.

Instead of outputting "1" I would like to have an option to send any number.

I'm actually coming round to this idea more, you can output 2 in effect by outputting the same signal with 1 twice so just turn it into a setable number

I think the reason this was never done historically was because 'if you need to turn it into another number just use an arithmetic combinator and multiply" but if we're somewhat compressing and simplifying Comparators I'm not against it being a number

To be perfectly honest? I don't mind circuits and extremely simple logic. However, I've already beaten 1.1 without using a single circuit.

I don't care about achievements, and I play modded so I don't get achievements anyway.

When you start getting into programming, like with current and future circuits, that's an insurmountable problem for me.

I get you ^_^ I think the circuit networks are mostly there for control signals, you can do crazy stuff with them if you want but they're there so you can turn on or off pumps to balance fluids rather than having massive stockpiles and for turning off sections of the base for various reasons. Maybe you want to stop running science and focus on defense things if you're low on resources, but if you're actively playing then most of this control you do in your head and by just running around disconnecting things when you think it's necessary.

In 2.0 It looks like they're there just to tell your filter inserters what is the most needed thing to launch into space you might need 5 whole combinators to control what you put into a rocket.

• You get the signal telling you what resources your space platforms need. -> Circuit 1
• You wire up all your storage together. -> Circuit 2
• Selector to find out how much of each of those materials will fit in a rocket. Cargo Rocket Limit Each Circuit 1 -> Circuit 3
• Decider if you need more materials than is in a rocket. if Circuit 1 > Circuit 3 then Circuit 3 -> Circuit 4
• Decider if you have more materials than is in a rocket. If Circuit 2 > Circuit 4 then Each 1 -> Circuit 5
• Decider filter the list of required items. If Each Circuit 5 !=0 then Each Circuit 1 -> Circuit 6
• Selector Send the most needed item to the filter insertrs. Circuit 6 Sort Decending Index 0 -> Filter inserters

Or you can do it all manually, cause I doubt they'll make it complex just for the sake of forcing Combinator Usage.

And like I say it'll look and feel a lot more familiar to you since it seems to be doing very similar things to train conditions

[mmmPI]

My question arose mainly from [....]
but how to deal with that depends on implementation details we don't know

Make sense, i'm not using LTN much anymore nor do i use stack size often so it took a little time to process.

This is the argument for why "Rocket Cargo Size" doesn't make sense and it's nonsense IMO

I can see your point , the functionnalities are limited, but on the other hand it makes it simple to understand the purpose of that particular operation that the selector can do.

One way i would look at it could be another "stack size" metric that instead would be "weight" and "weight capacity" as you say. So you could ask how many slot in a steel chest by sending steel chest signal and it would say 40,( send 2 steel chest and it answer 80 in a signal player pick as output) and with stack size of material you know how many you can fit.

And similarly, the other mode would be the selector receiving as input, 1 Rocket, or 1 modded-super-rocket, and it would answer 1000 kg, or 10 000 kg. And you could ask how much mass /weight, for "steel plate" and it would give the answer for the number you send ( 1 for easy math, send 200 and it tells you the weight of a stack ), so player would have the same information available to know how many of "thing" would fit into "other thing" be it slot/stack size as currently for train wagon or chest or "weight" limit for rocket.

Not sure it would be easier to use for simple task though.

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)

Yeah division is currently the one with largest footprint in the design from Nidan i use for pairwise operation (viewtopic.php?t=103567) If it was not so big it could be used in much more places instead of being prohibitive. I don't know if the cost in UPS is a reason to not allow this operation.

Red-Green though one can do using each *-1 on the green wire as input, output in a red wire connected to the other red , this one is easy

Green*Red is not that big, can be done in few combinators for small value, and for the purpose of filtering even less combinators are required, though it start being difficult to understand the circuitry without deeper knowledge about combinators logic. Seems like filtering it will be easier in 2.0

There may be ways to convert whole storage array to number of rocket that could be supplied without having to do the whole pairwise division by using stack size division, and loops iterating list thanks to the selector combinator from 2.0. The pairwise division with constant latency seem much more difficult to reproduce than if you are allowed to launch the calculation say only every 10 second. Especially if you don't have many different signals to work with, iterating through them all may do. That still seem convoluted compared to just (each red)/(each green) but there may be other ways i can't think of. I still kinda wish there were pairwise operation

When you start getting into programming, like with current and future circuits, that's an insurmountable problem for me.

Do not let this discourage you ! This is a feeling one can have for long time before finding it fun just to try something, because you are bored waiting for some material or have a particular thing you want to build, if it's fun to try and solve the problem, it's not so insurmountable, or at least it doesn't matter the same way. It becomes something where there is always something to learn and not a "problem".

Also some players have been learning similar logic for years at school and practice in their job, so it's no surprise it's hard to follow those discussions. But on the forum i received a lot of help to understand combinators which made it easier. If the problem is insurmountable for you but you find a few person to give advice , then it's not just you and the "problem" .

[dstroth]

This might be doable with something comparable to each/every as the index.

Yeah, I could see using Everything to enable a sorted index mode - e.g.:

sort_everything.jpg (8.76 KiB) Viewed 5324 times

If you're already very familiar with the decider combinator's special signals, this seems logical - but it would be hard to discover. (I only just learned about the v1.1.13 decider's Anything output mode! I guess I wasn't playing the game at the time it came out, so I missed it completely - but now that I know about it, I use it everywhere)

if they consider the idea of splitting the Selector into a Sorter and a LookUp

Splitting the selector combinator into 2 different combinators makes a lot of sense to me - it does seem like it has a lot of unrelated things in it right now.

I wonder if the developers experienced in their playtesting to use any index but 0 for the selector combinator's first function. I have a hard time imagining a scenario where you wish to select any other index but 0 after the list has been sorted. I'd suggest simplifying it into a min/max function instead, if there is never a true need for the other index positions. (Of course, if someone else can imagine such a scenario, I'd welcome it.)

You're likely correct that a constant 0 will be the most common use, but I strongly prefer the more flexible option that is shown in this FFF (which supports both different constant indices, and dynamic indices). I know that I'll be using it with non-0 values in my play-throughs.

A likely use-case for different constant indices is a train station that wants to load exact counts of multiple different items into a train: each filter inserter could be fed by a selector with a different index, such that each inserter is always operating on a different item type, so you don't risk multiple inserters jamming after trying to simultaneously insert the same item.

Dynamic indices will let you build circuits that iterate over and individually process each signal on a network. (this won't be a common use-case, sure, but it is a very powerful building block that I would expect to see in many more complex circuit contraptions). It could also be used for statistical selections beyond simple min/max: e.g. select the median signal by dynamically indexing to count/2.

Selector Send the most needed item to the filter insertrs. Circuit 6 Sort Decending Index 0 -> Filter inserters

A related small QoL addition that I'd love to see for filter inserters is the ability to set the stack size via Anything, so you can set both the filter and the stack size from the exact same signal. The semantics would be the same as the decider's anything output mode (just pick the first valid signal and use it as the stack size).

(EDIT: a more powerful option, suggested later by JohnyDL, would be to allow Each for setting the stack size - or possibly an explicit "set stack size from filters" checkbox - so you could set multiple filters each with different stack sizes dynamically via the circuit network)

This would make building count-exact multi-item loading stations simpler. You could feed the output of a Decider (in output = anything mode) or Selector (in select input mode) directly into the filter inserter, then configure the inserter to set filters and set stack size directly from Anything. Without this, you need 2 additional combinators per inserter to set the stack size signal and delay the filter signal (to match the timing of the stack signal).

Here's an example of what a count-exact multi-item train loader could look like with an Anything stack size and the new selector:

inserter_anything_stack_size.jpg (332.86 KiB) Viewed 5324 times

Also, why call it "rocket capacity" and not just "weight"? A rocket's capacity is based on weight (or mass, if you will), and there are likely to be mods to take advantage of this new feature.

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.

"Rocket capacity" seems oddly specific to me too. Item mass seems like the most general property to output. Rocket capacity is tied very specifically to a single vanilla feature, but I imagine mods (like SE!) will start making use of weight/mass in other contexts. Mass makes more sense to me than weight, since it looks like we're going to see planets with different gravity.. so mass would be a constant property of an item, but weight could vary depending on which planet the combinator is built on.

Of course, in order to convert from item mass back to rocket capacity, you'll need to know the rocket's cargo mass capacity (presumably a planet-gravity-specific value), or its weight capacity (presumably a constant) and the gravitational constant for that planet. Perhaps the devs feel that requiring players to perform this conversion themselves with combinators is asking too much (a position that I can completely understand).

[Svip]

Also, why call it "rocket capacity" and not just "weight"? A rocket's capacity is based on weight (or mass, if you will), and there are likely to be mods to take advantage of this new feature.

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.

"Rocket capacity" seems oddly specific to me too. Item mass seems like the most general property to output. Rocket capacity is tied very specifically to a single vanilla feature, but I imagine mods (like SE!) will start making use of weight/mass in other contexts. Mass makes more sense to me than weight, since it looks like we're going to see planets with different gravity.. so mass would be a constant property of an item, but weight could vary depending on which planet the combinator is built on.

Of course, in order to convert from item mass back to rocket capacity, you'll need to know the rocket's cargo mass capacity (presumably a planet-gravity-specific value), or its weight capacity (presumably a constant) and the gravitational constant for that planet. Perhaps the devs feel that requiring players to perform this conversion themselves with combinators is asking too much (a position that I can completely understand).

Perhaps the landing pad could output constant values that are related to the planet's unique traits, like for instance a rocket's cargo mass capacity, meaning the player would only have to compare two values. And perhaps still, the player could build "observation stations" anywhere to output these values. Hell, if WUBE got fancy, they could also output how light it is, pollution in its chunk, etc., basically values that would be neat to have in the current game. It's basically like a constant combinator, except it comes with signals and values, that the player cannot access otherwise.

[Qon]

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'm working on an assembler for a language with similarities to fCPU. Output of the assembler is vanilla v1.0 combinators. I will release a prototype soon.

So one can construct something structured with the combinators.

[SupplyDepoo]

Overall pretty cool changes!

More suggestions:

1. make the wire highlight when hovering over an entity more noticeable -- I often have to squint when trying to figure out how parts are connected
2. when a condition is met, change the text color from white to black to better contrast against the green background
3. add a way to push/nudge a combinator to any adjacent empty tile (not sure how you would do it), OR make it so that when you copy and paste entities, it remembers wire connections to other entities and reconnects them if in range (only as temporary data that is not saved when making a blueprint) -- it can be extremely daunting and error-prone trying to compactify a logic setup without this capability
4. I predict that during design & development of logic circuits, we will sometimes want to temporarily disable sub-conditions in the decider combinator, so there should be an easy way to do that so we won't have to delete and then tediously reconfigure sub-conditions. Perhaps they could be toggled on/off, or at least if you do delete a sub-condition, it is added to the undo stack so you can get it back by pressing CTRL+Z
5. make it possible for GUIs to be pinned similar to OpenTTD so that pressing E/ESC does not apply to them, and you could open additional GUIs of other entities (which could also be pinned) -- a common workflow for me is to use constant combinators to test different inputs (e.g. simulate an accumulator dis-/charging), and it would be practical if I could just keep that constant combinator GUI open while tweaking the logic
6. "I hope the devs add a debug functionality, where it allows us to step through the “ticks” and see why the circuit is not doing what is intended" -- These_Kitchen_5109 on reddit
7. anything else to help with testing/debugging and compactification that you can think of please! maybe a push-button entity for sending 1-tick pulses, which would help with adjusting memory cells and other things?

Currently, Factorio hardly limits blueprint description length, and it can't include fully detailed description with numbers and formulas (when they are needed). Could you increase the allowed length of the text field? Something about 10x times?

+140

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 ?

+1000

An alternate point of view to the combinator UI elements appearing "out of nowhere" is that the behaviour of UI elements appearing only when needed keeps the combinator UI from becoming overly cluttered.

+2

My sketch:
Decider-Combinator-UI.png

That looks better!

Thank you so much for all these fantastic improvements in the recent FFFs. It's unbelievable how much better you make an already incredible game!

Totally, best game devs ever!

The only suggestion I have for all combinators is in the sprites and connection locations: offset the connection locations so that the connection points don't form a straight line.

100%

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?

@kovarex Is this possible with the decider combinator via checking "Each" signal on red wire AND "Each" signal on green wire to filter out signats that exist on both wires?

Something like this?
decider filter mode.jpg

I don't think that's how it should be done. If the second condition was different, for example Each < 0, then I would expect the whole AND to be TRUE when all green signals were positive and all red signals were negative. Your suggestion would either break that or it would be a special case where both the conditions are the same just with different wires and that would be confusing.

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.

I mostly agree with this. The 1.1 combinators are elegantly simple -- a nice middle ground between very primitive logic systems like Minecraft's redstone, and more advanced ones like Stormwork's microcontrollers. I'm a little worried that multiple conditions and outputs will hide too much of the beauty of circuit network inside of cluttered GUIs, instead of boldly showing it in its full glory in the world. I'm not sure though, I'd have to play with it for a bit in order to form a strong opinion. The calls for allowing multiple arithmetic operations inside combinators make me cringe though -- I think that would be too much.

There's a nice satisfaction in solving a problem with combinators, then simplifying the logic, and finally fitting it into a compact footprint. The current balance of expressivity per tile is mostly pretty good. I don't mind if these changes will simpkify certain things that currently take up an enormous amount of space, but I would hate if most of the popular circuits become just the same 3 or 4 combinators (1 constant, 1 decider, 1 arithmetic, and maybe 1 selector) tucked in a corner.

I'm hopeful that won't be the case.

[Impatient]

It is stated that this topic will be covered later as it is not yet implemented and we are deciding how and where do we want to do it.

I am celebrating the implementation of wire selection (on the decider combinator for now). I was in good hope, that you will do this, after having seen what other new features you implemented, as it also makes so much sense. Although the pictures don't show it for the arithmetic combinator, but you say, the whole thing is not finished, I have hope that you will implement it for the arithmetic and the constant combinator as well.

And another question: Will we be able to do mass divisions (and multiplications) in one arithmetic combinator (coal_red/coal_green, stone_red/stone_green, ... etc., combined into each_red/each_green) once the new combinators are fleshed out?

Please recall this age old problem, which in Fv1.1 needs 2 combinators per signal type (one for signal conversion for one of the two inputs and one for the arithmetic operation itself).

[JohnyDL]

"Rocket capacity" seems oddly specific to me too. Item mass seems like the most general property to output. Rocket capacity is tied very specifically to a single vanilla feature, but I imagine mods (like SE!) will start making use of weight/mass in other contexts. Mass makes more sense to me than weight, since it looks like we're going to see planets with different gravity.. so mass would be a constant property of an item, but weight could vary depending on which planet the combinator is built on.

Of course, in order to convert from item mass back to rocket capacity, you'll need to know the rocket's cargo mass capacity (presumably a planet-gravity-specific value), or its weight capacity (presumably a constant) and the gravitational constant for that planet. Perhaps the devs feel that requiring players to perform this conversion themselves with combinators is asking too much (a position that I can completely understand).

This is the argument for why "Rocket Cargo Size" doesn't make sense and it's nonsense IMO

I can see your point , the functionnalities are limited, but on the other hand it makes it simple to understand the purpose of that particular operation that the selector can do.

One way i would look at it could be another "stack size" metric that instead would be "weight" and "weight capacity" as you say. So you could ask how many slot in a steel chest by sending steel chest signal and it would say 40,( send 2 steel chest and it answer 80 in a signal player pick as output) and with stack size of material you know how many you can fit.

And similarly, the other mode would be the selector receiving as input, 1 Rocket, or 1 modded-super-rocket, and it would answer 1000 kg, or 10 000 kg. And you could ask how much mass /weight, for "steel plate" and it would give the answer for the number you send ( 1 for easy math, send 200 and it tells you the weight of a stack ), so player would have the same information available to know how many of "thing" would fit into "other thing" be it slot/stack size as currently for train wagon or chest or "weight" limit for rocket.

Not sure it would be easier to use for simple task though.

But in most ... 99% of cases .... you're just adding steps to the process of getting the numbers that you actually want, in Vanilla do we actually care about the weight/mass of the items? For me the answer is a clear No... yes it's a more fundamental property but it's also not at all useful on its own. We care about how much stuff we can launch into space, I'm not sure that the weight is even always directly tied to rocket capacity size though, we're assuming it is but are we sure? That doesn't appear to be the case from my understanding of #382

What's more if say there's an infinite tech for stronger/bigger rockets this could automatically be factored into a 'rocket cargo limit' in the selector but if you're only told the weight then each time you complete this tech you'd have to reconfigure combinators and recalculate how much a rocket can hold

And it doesn't account for factors other than weight, real rockets (and I'm assuming Factorio rockets might for gameplay reasons) are limited by volume/risk/etc too, and you might end up with some really funky weight numbers if that's the only limit. They even told us that they massaged the numbers around things that could be recycled and trying to get to round numbers. Because Science packs are not recyclable you can launch more of them than their crafting ingredients would lead you to believe. Most industrial processes are a little lossy in terms of material weight but 99%? for yellow science. And will that always be the case in factorio if the devs realise that some things can be efficiently recycled into raw materials if they follow this convention? And didn't they say that there's a maximum of 10 stacks in a rocket too (or 1 stack for non-intermediates), again adding to the combinator complexity of working out exactly how many things actually fit in a given rocket.

What matters in the vast majority of cases is the actual items per unit space that is taken up. In effect asking for the weight of each item (in the context of the unit space of one vanilla rocket) is the same as asking "what % of a stack is a single item?", it doesn't matter if you have 1 item or in some cases 200 items it will take 1 unit of space up in an inventory, it is useful to know what the maximum is before rolling over but how much 1 is? I don't see the point.

You could calculate the stack size if you're told the percent but you're adding a needless step that could make the result less accurate. In the case of 200 items per stack the factorio signals answer to "what % of a stack is a single item?" is 0 (cause 0.5% gets floored)

For Rockets we don't know but it could be that Iron Plates have an effective weight of 1.33333...kg or 1333.33333..grams that's not something you can effectively do signal math on and get the correct answer. You could always round up but then you're losing out on something somewhere and if you're calculating the exact value for the space in a rocket then you obviously care about efficiency. And even if Vanilla is all in Integer values what about Mods? Will they be limited to integer values or could some want to use fractional values?

And that doesn't account for localisation, how many people are going to be confused by metric units and want to do the math in some other system looks at the Americans and will that lead to different mass values being output and different rounding errors with converting a mass into how much cargo will fit in a rocket

That said, if you're arguing for the weight and other stats AS WELL AS what has already been shown yeah I'm for that. I said I'd split up the current Selector into a Sorter with many more sorting related functions; picking the order, enumeration vs outputting a specific index(s), etc... and a LookUp with making many more stats from the game accessible to the player; Item Stats, Recipies, Inventory Size Stats, Surface Stats, Production Stats, etc the list goes on. More stats is more good in that regard

This might be doable with something comparable to each/every as the index.

Yeah, I could see using Everything to enable a sorted index mode - e.g.:
sort_everything.jpg

If you're already very familiar with the decider combinator's special signals, this seems logical - but it would be hard to discover. (I only just learned about the v1.1.13 decider's Anything output mode! I guess I wasn't playing the game at the time it came out, so I missed it completely - but now that I know about it, I use it everywhere)

I'm not sure how to do it, with each and every, as I understand them now, you'd get some really funky behaviour, like you put in the values A=1, B=2, C=3, D=3, E=4, F=5, G=6, H=10 and you use "each" you'd get the result out of B=2, C=3, D=6 (two things indexing D), E=4, F=5 it'd have to be a new special signal as I understand it. (or a new setting See my Sorter/Lookup in this and my other posts)

Selector Send the most needed item to the filter insertrs. Circuit 6 Sort Decending Index 0 -> Filter inserters

A related small QoL addition that I'd love to see for filter inserters is the ability to set the stack size via Anything, so you can set both the filter and the stack size from the exact same signal. The semantics would be the same as the decider's anything output mode (just pick the first valid signal and use it as the stack size).

Or using Each, so you can set the hand size based on what item is being picked up, maybe you only need/want to pick up 1 of some item at a time, but you still want to load other items at full speed.... I'd also like an option of negative numbers emptying full hands back into the input space (if possible)

[crj]

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.

I've made some fairly serious attempts at doing this kind of thing. One large problem you hit is that there's no telling in what order bots will construct a blueprint, which makes any such mechanism intensely fragile.

The least-bad option I've found is to drop one blueprint, then manually drop a second "enable" blueprint once the first is done. I've tried automating that by reading Roboport signals, but it's incredibly fiddly and fragile.

Actually, now I think about it, some kind of mechanism for sensing when a blueprint has been fully constructed would be incredibly useful in niche cases.

[adjl]

I already have a difficult time making one assembling machine's worth of blue science, how is it beneficial to make it more difficult by duplicating the line? It's not like it's going to make it any easier to catch up.

I often have to spend many hours just letting the game run idle as it is, oftentimes overnight, eight hours straight of the game running. Robots would only increase the amount of time I spend not playing the game, instead waiting around for more science packs.

If that's how you like to play, that's fine, since it's your factory and you should play how you want, but you do need to recognize that that's not how most people approach the game. If science production is so slow that it's necessary to afk overnight to produce it the required amount, most players just build more science production, expanding everything upstream from that as needed to supply it. The game is a constant balancing act between being bottlenecked by science production and being bottlenecked by how quickly you can design new subfactories to take advantage of the research you complete. If science production is bottlenecking you that much, build more science production and you'll be able to spend much more time actually playing the game (that is, building solutions to production and logistics puzzles).

I will personally never use the circuits as I have found them too complicated to use in-game and the tutorials on them, both in-game and outside it, have all been insufficient. Like one other person, this has led to me building multiple, small, simple, scaleable outpost-style bases for mining and drilling, and connecting them to my larger central hub with trains.

What's the difficulty you have with circuits? If the tutorials that exist aren't doing the job, both this forum and the Factorio subreddit are quite helpful and may be able to translate the tutorials' information into something that better aligns with your learning style. If nothing else, the approach you're describing of setting up outposts to collect raw resources and train them into a main production area is how the vast majority of people play the game regardless of whether or not they use circuits, so if you think that precludes using circuits you might be fundamentally misunderstanding something about how circuits are useful.

For the absolute simplest example of circuits, consider building something like nuclear reactors: Because they're so expensive and you don't need very many, you don't necessarily want to produce a full stack of 10 (as you would if you just capped a chest). To avoid that, connect one circuit wire from the chest to the inserter, then set the inserter to only work when reactors are <4 (or however many you need for your reactor design). Fundamentally, that's all there is to circuits: Think about what you want to achieve, think about what input signals you have available, then figure how to get from those inputs to the desired output. It's not actually any different from building a factory, at a conceptual level. It's just more abstract.

If the circuit network is one-hundred-percent necessary to complete the game in 2.0, then congratulations Wube, you just lost a customer. I will continue to use 1.1.

I doubt it will be. They've already explicitly made the comparison to Space Exploration (which is designed to need some level of circuit knowledge to beat), indicating that Space Age is going to be designed to be a lot more accessible than SE. By how they've described rockets working, I expect some circuit knowledge will be really helpful to streamline and automate the process, but it probably won't be entirely necessary (or if it is, it'll be in the form of simple applications like limiting chests or controlling pumps).

I wish there was a "circuit network simplified" mod that made the circuit network as simple to use as the train GUI with excruciatingly-simple logic gates - AND, OR, XOR, etcetera. Then I would actually use the network. I'm sure a lot of people will agree.

That's basically what they're doing with the decider combinator update. Rather than needing multiple decider combinators and to think about how to configure their outputs to achieve the logic you want, they're letting you put as many conditions as you want into a single combinator using a similar GUI to the ones trains use. It's still limited to AND and OR, so you'll have to get more creative to pull off other boolean logic, and you'll still need one combinator per set of conditions (so you won't be able to have one combinator output one thing when Iron>100 and something else when Iron<100), but the most basic logic gates have now been rolled up into a single combinator.

[mmmPI]

But in most ... 99% of cases .... you're just adding steps to the process of getting the numbers that you actually want, in Vanilla do we actually care about the weight/mass of the items? For me the answer is a clear No... yes it's a more fundamental property but it's also not at all useful on its own. We care about how much stuff we can launch into space, I'm not sure that the weight is even always directly tied to rocket capacity size though, we're assuming it is but are we sure? That doesn't appear to be the case from my understanding of #382

Yes, it's adding steps in an attempt at being more generic . And yes i assumed weight was the only thing that limit rocket capacity.

What's more if say there's an infinite tech for stronger/bigger rockets this could automatically be factored into a 'rocket cargo limit' in the selector but if you're only told the weight then each time you complete this tech you'd have to reconfigure combinators and recalculate how much a rocket can hold

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.

And it doesn't account for factors other than weight, real rockets (and I'm assuming Factorio rockets might for gameplay reasons) are limited by volume/risk/etc too, and you might end up with some really funky weight numbers if that's the only limit. They even told us that they massaged the numbers around things that could be recycled and trying to get to round numbers.
[...]
For Rockets we don't know but it could be that Iron Plates have an effective weight of 1.33333...kg or 1333.33333..grams that's not something you can effectively do signal math on and get the correct answer. You could always round up but then you're losing out on something somewhere and if you're calculating the exact value for the space in a rocket then you obviously care about efficiency. And even if Vanilla is all in Integer values what about Mods? Will they be limited to integer values or could some want to use fractional values?

I agree with some points, like if weight is not the only limit knowing 1 item mass ( and gravity) and rocket payload capacity wouldn't be enough i would say this leads to adding the other thing that would limit the rocket so it can also be mathed with combinator, i had no precise recommendation for implementation, it's what you wrote that made me think about that. It can yield to much imprecision due to integer number in circuit, but this will be the case anyway 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

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. Its very edge case, but It's why i cut the quote this way. Numbers will be round or not ? I'm enclined to think it will be good enough for circuit processing. Stack size are all even number or multiple of 5 as far as i can tell, so maybe there could be some tweaking so that weight are always making whole number when it's full stack with some weight being "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.

And that doesn't account for localisation, how many people are going to be confused by metric units and want to do the math in some other system looks at the Americans and will that lead to different mass values being output and different rounding errors with converting a mass into how much cargo will fit in a rocket

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.

That said, if you're arguing for the weight and other stats AS WELL AS what has already been shown yeah I'm for that. I said I'd split up the current Selector into a Sorter with many more sorting related functions; picking the order, enumeration vs outputting a specific index(s), etc... and a LookUp with making many more stats from the game accessible to the player; Item Stats, Recipies, Inventory Size Stats, Surface Stats, Production Stats, etc the list goes on. More stats is more good in that regard

Yes ! the "sensor" combinator, i thought it could be a function of the selector, but it could be a stand alone combinator, i've read other people in the thread suggested connecting the landing pad to get access to stats like surface stats. I had in mind, gravity, and weight, i think it's highschool math & physic ( it was for me), not university, so more accessible maybe than when you go specialized in IT. Productions stats, +1, i agree more stats is more good !

I have a biais considering all those "fun" though, that's suited to mod, it's hard to tell for me what would fit in the scope of the expansion.

[Svip]

The "sensor combinator" could even bridge the gap between all the buildings you cannot attach wires to (likely because of all the artwork needed). I'd love to be able to determine whether an assembler is working or not. A sensor combinator could be placed near it, and then "synced" with the assembler, so the sensor - in addition to all the other stuff it outputs - would output information about the assembler. The game also have plenty of signal types to output this information along. I am sure there is probably a mod that already does sensor combinator.

[pleegwat]

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.

"Rocket capacity" seems oddly specific to me too. Item mass seems like the most general property to output. Rocket capacity is tied very specifically to a single vanilla feature, but I imagine mods (like SE!) will start making use of weight/mass in other contexts. Mass makes more sense to me than weight, since it looks like we're going to see planets with different gravity.. so mass would be a constant property of an item, but weight could vary depending on which planet the combinator is built on.

Of course, in order to convert from item mass back to rocket capacity, you'll need to know the rocket's cargo mass capacity (presumably a planet-gravity-specific value), or its weight capacity (presumably a constant) and the gravitational constant for that planet. Perhaps the devs feel that requiring players to perform this conversion themselves with combinators is asking too much (a position that I can completely understand).

Rocket capacity compares to mass as stack size compares to volume. It's more consistent in terms of the maths required to use either rocket capacity and stack size, or mass and volume.

[mmmPI]

The "sensor combinator" could even bridge the gap between all the buildings you cannot attach wires to (likely because of all the artwork needed). I'd love to be able to determine whether an assembler is working or not. A sensor combinator could be placed near it, and then "synced" with the assembler, so the sensor - in addition to all the other stuff it outputs - would output information about the assembler. The game also have plenty of signal types to output this information along. I am sure there is probably a mod that already does sensor combinator.

I remember using those : https://mods.factorio.com/mod/FactorIO and https://mods.factorio.com/mod/Inventory%20Sensor Which allow things like reading the number of empty slot in an inventory ( maybe rocket silo in the future ) or show the amount of time left for a crafting in a machine as you mention.

But not sure how the crafting combinator detect which assembly to sync with without wire when in between 2. I haven't used that mod for a while.

[KorespondentAda]

Great news about disabled interface instead of no interface at all!
Powerful combinators also is absolutely great, but I have a think about selector.

As someone stated before, last three options of selector combinators is not about selection but about information - well, we have item, what we know about it? We know a lot, but to use it we (currently) have to hardcode it in constant combinators, as we do if we need chests/cargo capacity, item stack size, belt throughput, rocket parts count, blueprint items, etc... It seems more convenient to export this functionality (gathering in-game info) to some kind of "info combinator".
I see it more like constant combinator variation, but its constants set not by player from tooltips, but by game itself. It isn't functions or filtering, it's constants.

Also I think about using brand new logic/logistic groups: maybe it's possible to dynamically generate (once, on demand) a some kind of meta logic group with items and it's property values as count - so we can place regular combinator with that group on red and our dynamic signal on green inputs of our great new decider - and we do not need that options in some other combinator.

Yeah, combinator/group with items from blueprint, also would be cool! So, generating of that groups can be useful anyway.

[adam_bise]

To me, combinators are the coolest part of the game. If you still haven't gotten used to them, you might give it another try. Especially now that it is simplified. At least you won't have to make logic gates by hand =P I thought it was fun either way.

[dstroth]

But in most ... 99% of cases .... you're just adding steps to the process of getting the numbers that you actually want, in Vanilla do we actually care about the weight/mass of the items? For me the answer is a clear No... yes it's a more fundamental property but it's also not at all useful on its own. We care about how much stuff we can launch into space, I'm not sure that the weight is even always directly tied to rocket capacity size though, we're assuming it is but are we sure?
<snip>
What matters in the vast majority of cases is the actual items per unit space that is taken up.

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

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.

That said, if you're arguing for the weight and other stats AS WELL AS what has already been shown yeah I'm for that. I said I'd split up the current Selector into a Sorter with many more sorting related functions; picking the order, enumeration vs outputting a specific index(s), etc... and a LookUp with making many more stats from the game accessible to the player; Item Stats, Recipies, Inventory Size Stats, Surface Stats, Production Stats, etc the list goes on. More stats is more good in that regard

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

And that doesn't account for localisation, how many people are going to be confused by metric units and want to do the math in some other system looks at the Americans and will that lead to different mass values being output and different rounding errors with converting a mass into how much cargo will fit in a rocket

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

This might be doable with something comparable to each/every as the index.

Yeah, I could see using Everything to enable a sorted index mode - e.g.:

I'm not sure how to do it, with each and every, as I understand them now, you'd get some really funky behaviour
<snip>
it'd have to be a new special signal as I understand it. (or a new setting See my Sorter/Lookup in this and my other posts)

Ah, I may have misunderstood what you were originally suggesting. I didn't mean to literally use Each or Every signal as an index, but rather to use Everything as a magic signal that would enable my proposed "sorted index" mode. Its behavior wouldn't be the same as Everything on the decider - it would just cause the selector combinator to output the complete sorted list, with each output signal's value representing its position in the sorted list.

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

A related small QoL addition that I'd love to see for filter inserters is the ability to set the stack size via Anything, so you can set both the filter and the stack size from the exact same signal. The semantics would be the same as the decider's anything output mode (just pick the first valid signal and use it as the stack size).

Or using Each, so you can set the hand size based on what item is being picked up, maybe you only need/want to pick up 1 of some item at a time, but you still want to load other items at full speed.... I'd also like an option of negative numbers emptying full hands back into the input space (if possible)

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