Combinators 101

[BlakeMW]

The devs keep saying that they want combinators for "simple" factory automation, and that they were never made to create "complicated" circuits, even though that's possible.

Unfortunately, by saying that they ignore the fact that nobody uses combinators to make simple circuits. The players who use them to make anything actually useful in the game build very complicated machines, i.e. they use them for things they weren't "made for". There's a huge gap between "toy applications" and "circuits that enhance the factory". Crossing that gap is next to impossible unless you devote a LOT of time to it.

I have to quibble with this. There are some simple uses for combinators such as making a rate-limited smart inserter by linking it to a clock with a condition A = 1. A rate limited inserter can be used for some genuinely useful things and some stupid tricks.

Some pretty simple uses I've come up with is dividing the contents of a tank by 25 to get a %age full number. An example of when I use this is when using steam power I usually have a storage tank inline to buffer demand spikes. I convert the tank quantity to a Yellow signal 0-100 then run that signal to the main factory and feed it into some lights which give a visual indicator of the power plant status, it might also be used to fire up backup oil power. For that use I don't even need to use a arithmetic combinator because I could just send the water signal - but I prefer to convert it to a yellow signal because my convention is Yellow means power quality, also Nucular mod uses Steam instead of Water.

I don't disagree though, that it the circuit network is full of weirdness. Just for a start calling it the "circuit network" is a misnomer - it's more like a scripting language than an electronic circuit. You have a bunch of variables and can compare them and perform arithmetic on them and there's even function type things roughly equivalent to reduce, map, any, every. It's a very weird scripting language, but that's what it seems most like to me.

[siggboy]

Well, of course there are some very clever setups that don't constitute proper circuits. I was deliberately exaggerating (a little) to make a point.

To the examples I might add the "chest balancer", that only requires one arithmetic combinator (divide by negative chest count), and maybe also the cases where you want to create simple compound conditions ("IF this AND that THEN foo").

I think "circuit" is supposed to describe the "wire circuit", after all it was in the game before the combinators where added. Also they use the name "combinator", which is a made-up word, and probably deliberately chosen as not to invoke expectations that we're dealing with real-world electronic circuits.

You've used the term "scripting language", I'm not so sure if that's a fitting analogy. It's really hard to classify the "combinators", they're some strange mixture of actual digital computer and simple electronic circuit, following their own laws (for example there are no "short circuits", just feedback loops).

[madtulip]

Thanks for the very usefull information!

There is a typo in a relevant part at the end.:
"... it would be 60*60 = 3600 and 2597." should read
"... it would be 60*60 = 3600 and 3597." instead if understood that correctly.

[DemiPixel]

Any idea how to do an integer OR? Ideally I don't want to do all 32 bits in separate combinators

EDIT: Proof that I tried

Code: Select all

H4sIAAAAAAAA/92X4W6bOhiGb6Xi5xkcYWPAUcek7TamKXLASayBjYzpGqHc+zEJEHoSHExaTduftqnt1/5e3u/BycRTLlKSP62ThnLFFKNV0jScFDRxMpqy
jEovFcWGcaKEdNxSVHqS4EnzmnjQPegf/4ZHNxWc07Qd0Mu/O8D5kTSSZlrqpHpYsywJ3ZTJtGaq/QCPx6P73YG3JsL/TzzpZ6yT746VNFsmK7Wu2I6TPGnU
odRnfmFS1SR33HMJ50GPknTvnFQqRbhKfP1nURLZ1pQ4nx1X1KqsLbXKwzoVNVfrrRTFmnEtkDhbklfUaY8810RgZSKaayJ4O9EdDQXjIfCX++sP9mZMnt1t
TZxh9VUMp6yO391Pwg9qz/hu2tMvdp6+UDlSnOcskUztC6pYeie8/iICgDeZXM3lwbW/l3MuiGxFW6lZK77p6aKk+gG01Tv/LEi1pbvQyl007S7w55Li99n7
9V3tvYcFu+DG0zAFwGAt/oNJq2RtiwN/MNWWtcFc1kYfGNbBVA8CFCMcRAiPI/npwzveruEj8z3pvb2Ix154E14wRYtecUMqXauShFelkMrb0Fy9caTfxPx+
gYvw126zZbmisr3QGg5ZS645wXhFpZ58Kl23QgIC4MfQZTyjryea3qvzSgFG2jrUKUCjQi74ztsTPTO71gkhghh3OoFRZ0sqdaMUH+EwjjoFZFSoCiJvSEB/
FYOwtyM0SuyIosNCBFYo8HsXIvPeSnDq/SJ5PizHAcaR3xcf31kuCdvtlad/XRRAFMcxBH312CiR1vJFP4I3AkEQhggFfe0r84PUz9ArGL8YEMXA1zX0Dug3
sWl9WwL3tBHlKIgIAl1CbwIwh7E9u3ceHiURoyBEYW8CuJNGsrmEL4hw7K/A0AnmAEqR/qRK75+LUfziIEYAw8EDcwTTPS2Y/k7qldpNdSniwuROJrRCCZyP
knA+SqbvMl3xaBIh07fMLngDOizK9OdXeeNV+hAwowBPFzuDlxis4OO0RP4qeoCV0B/ytQiUwB9ibkHJcOgva0LCoasX0XHAij0YB6bZInFg6QIYRsspiO3p
h5ZTDz4EOzBm3NFl6amRm+6frulCqbfrmsid/CqkNZ8lVbqTn9bPlGf/AatE/uEHFAAA

Usually works as expected (for some reason larger numbers don't but I feel like that's insignificant at this point, a minor flaw). Way larger than I'd like, however.

[stellatedHex]

Any idea how to do an integer OR? Ideally I don't want to do all 32 bits in separate combinators

Pretty sure your choices are doing all 32 bits in separate combinators and doing each bit 1 after the other, which would be finicky to create and take a long time (in combinator terms. a couple of ticks per bit, so 1-2 seconds.). I suppose you could also do a hybrid approach, where you have, say, 4 copies of the latter, each of which runs 8 of the bits.

[siggboy]

I've thought about that problem, too, before. The problem is that, in some way or another, you have to decode each of the bits in both operands. I don't think there's a shortcut to get to a bitwise OR just with integer operations (well, unless that amounts to decoding everything).

An iterative approach could test for each bit successively by doubling and then testing for negativity (that effectively checks for the most significant bit). Unless both values are positive you output a "1". You double the output along with the input operands. Accumulating could be done in the output register.

Another way might be to check if both operands are even (that means the LSB is zero), and otherwise output a "1". Then you divide the inputs by 2 and double the output. You'd need to do this 32 times for the final result.

So those approaches need a counter, and output buffer, and the combinator to implement the loop condition. Probably just as complex as the solution already proposed, plus it takes 32 ticks because of the looping.

[DemiPixel]

I've thought about that problem, too, before. The problem is that, in some way or another, you have to decode each of the bits in both operands. I don't think there's a shortcut to get to a bitwise OR just with integer operations (well, unless that amounts to decoding everything).

An iterative approach could test for each bit successively by doubling and then testing for negativity (that effectively checks for the most significant bit). Unless both values are positive you output a "1". You double the output along with the input operands. Accumulating could be done in the output register.

Another way might be to check if both operands are even (that means the LSB is zero), and otherwise output a "1". Then you divide the inputs by 2 and double the output. You'd need to do this 32 times for the final result.

So those approaches need a counter, and output buffer, and the combinator to implement the loop condition. Probably just as complex as the solution already proposed, plus it takes 32 ticks because of the looping.

My theory is that the easiest way to display two things on a screen was to int OR them together. For example, if you wanted Tetris playing and you have the data, and then want to put "You Lose" over it, again on wires, you could int OR and that would be like an overlay.

[DaveMcW]

Lamp Anything < 0 performs an OR for you. That is how the advanced digit displays work.

[DemiPixel]

Lamp Anything < 0 performs an OR for you. That is how the advanced digit displays work.

That means any time something turned on in a row/column, everything would turn on in that row/column.

[stellatedHex]

Lamp Anything < 0 performs an OR for you. That is how the advanced digit displays work.

That means any time something turned on in a row/column, everything would turn on in that row/column.

I think that the signal from the other row/column defaults to +something instead of 0?

[programmer]

Hi. Apologies if this has already been asked. I have delved into general complex circuit programming with combinators. Is there any information anywhere about what order combinators are evaluated in? In particular, whenever a circuit is a cyclic graph (outputs somewhere downstream in a circuit feed back into inputs somewhere upstream) then I have no idea how to reason about which order things will happen in. Is this hopeless and I should try to minimize this in my design? Or is it actually defined?

One other issue - it seems like maybe all the combinators do not actually update on every game tick, perhaps they are staggered? In a relatively small circuit (~50 combinators) there seems to be a fuzzy window of about 5 game ticks in which different combinators that should *logically* update simultaneously, actually update anywhere in that 5 tick window. This appears to make it not possible to make tight loops that run at 60hz. A *single* combinator updates reliably at 60hz, but not the whole circuit.

[siggboy]

I have no idea how to reason about which order things will happen in. Is this hopeless and I should try to minimize this in my design? Or is it actually defined?

Every combinator requires 1 tick to calculate the results. This is how everything propagates if you chain combinators.

When this happens, the little blue light on the combinator blinks.

The game only does this when outputs actually change. So if you have a memory or latch that loops back to itself, even though "technically" the output will get recalculated to yield the same result again, this actually does not happen, because the game does not see a change. That's why you don't see a constantly blinking light on a memory cell that holds a value.

One other issue - it seems like maybe all the combinators do not actually update on every game tick, perhaps they are staggered?

That's entirely unlikely, unless it's a bug. None of the complex contraptions, let alone the full blown CPUs that have been built, would work at all if this was the case.

All combinators update every tick, unless they have insufficient energy, then they update more slowly.

[programmer]

Thanks. Let me take another try at understanding based on what you said. So, in a moderately complex circuit there will be chains several combinators long. If the game checks output changes once per ticks, that means that a chain of 2 combinators takes 2 ticks to propagate, a chain of 3 takes 3 ticks, etc. If that's the case, then everything I'm seeing makes sense. It's whole circuits that I wasn't seeing update every tick, not individual combinators. My maximum chain length is probably exactly 5, which would explain why I see those 5 ticks of general latency. If I'm understanding this right, then the update order is deterministic and possible to reason about, and the latency is explained. Does that sound right?

[siggboy]

Yes. I personally hate to reason about tick delays, but the basics of it are very easy. 1 combinator = 1 tick delay.

[Anson]

If I'm understanding this right, then the update order is deterministic

I think that it is deterministic simply because there is no "update order" of combinators and they all work at the same time.

I always imagine that all combinators work in parallel:

• each combinator gets its input values at the start of a tick,
• each combinator does its work "during" the tick,
• and finally each combinator outputs the calculated values at the end of the tick
  (which then can be used as inputs at the start of the next tick)

thus never getting timing conflicts when feeding new output values to other combinators or back into its own inputs. there is also never a problem of "random order" when signals propagate through two combinators (input>A>B>output) depending on whether you built A first or B first.

[orzelek]

If I'm understanding this right, then the update order is deterministic

I think that it is deterministic simply because there is no "update order" of combinators and they all work at the same time.

I always imagine that all combinators work in parallel:

• each combinator gets its input values at the start of a tick,
• each combinator does its work "during" the tick,
• and finally each combinator outputs the calculated values at the end of the tick
  (which then can be used as inputs at the start of the next tick)

thus never getting timing conflicts when feeding new output values to other combinators or back into its own inputs. there is also never a problem of "random order" when signals propagate through two combinators (input>A>B>output) depending on whether you built A first or B first.

You are correct. This is needed to guarantee multiplayer sync - result needs to be deterministic.

[Philip017]

first of all i want to say thank you for your helpful tutorial, i have delved a little into your designs and found a functional design to meet an intermediate need

i have designed a simple timer when condition is met the latch is set,
this activates a timer, when the timer has run it's course, a signal is generated to punch the first condition of the reset,
the input signal is inverted so that i can have it used as the second condition of the reset function, as if i still need something to move, it will stay moving.
i combine the 2 reset signals to actually reset the latch, thus turning off my machine again.

i used this a bit for my power as when i had no accumulators, only steam and solar, i could run my entire base, and continue expanding during the day, but turn off things when the sun went down,
problem i had was i was using a fast inserter putting wood in the box, connected a solar panel, that would cease functioning when it got dark enough, and a normal inserter taking wood out of the box, connected to the main grid, with a track connecting it all together and just enough wood on the track so there would always be 1 wood in the box when the sun was up. but the steam engines would fire up and go full tilt tiring to keep up browning out my entire base not keeping off what i wanted off as the fast inserter would work slowly at sun down and sun up not allowing the power switch to stay off, adding this timer would allow the factory to stay off during sun down and up times.

[steinio]

Hello,

i tried some stuff with combinators and tested the latch from this thread which worked at the end.

Now i have the following 'opportunity':

2 warehouses which should always stay equalized (as the inserter speed allows).
So i thought about 3 inserters pointing in each direction and connect some deciders.

The warehouses are only big chests and circuit network connectable.

There should only the inserter be active which points to the warehouse with the lower value.
What happens if i add a third warehouse which should be synched with the second and so on?

Here i have no clue how this can work because the decider always get two signals with the same item only with different numbers.
Should also not to take much space.

I would be thankfull for help.

Greetings steinio

[afk2minute]

Hello,

i tried some stuff with combinators and tested the latch from this thread which worked at the end.

Now i have the following 'opportunity':

2 warehouses which should always stay equalized (as the inserter speed allows).
So i thought about 3 inserters pointing in each direction and connect some deciders.

The warehouses are only big chests and circuit network connectable.

There should only the inserter be active which points to the warehouse with the lower value.
What happens if i add a third warehouse which should be synched with the second and so on?

Here i have no clue how this can work because the decider always get two signals with the same item only with different numbers.
Should also not to take much space.

I would be thankfull for help.

Greetings steinio

Are items in warehouses are of the same type?

[steinio]

Yes