Page 1 of 6

Combinators 101

Posted: Thu Aug 06, 2015 9:11 am
by GopherAtl
There seems to be a lot of confusion about how combinators work, so I thought I'd put together something of an introduction/tutorial deal. This probably ought to be cleaned up and put on the wiki, but I'm going to start it here to get feedback.

I apologize for this being heavy on words and light on pictures, but honestly, pictures only help so much. I recommend you load up a world and play along, setting up things as I describe them and playing with them, watching the inputs and outputs of your combinators as you do (they're displayed at the bottom of the detail view on the right when they're hovered over, if you've never noticed before). Even if you're following it well enough in your head, it wouldn't hurt to see it in practice.
The sections are in spoilers to prevent this from being unmanagably long. There are a lot more pictures in the practical section towards the end, which those of you who already basically "get" combinators may want to skip down to.

First off, to understand combinators, you have to understand circuit networks. Until now, it was entirely possible to do all the standard, common things with smart chests and inserters without really knowing how the circuit network works, but combinators are a different animal, and it's very helpful to grasp this first.
Circuit Networks - the nitty gritty
Got you head around that? Good. Now on to the actual combinators!

Combinators and Circuit Networks
Combinators work the same way as basic objects like chests and inserters, but are a bit more complicated. Before, everything either sent a signal to the circuit network - like smart chests - or pulled values from it - like smart inserters. Combinators do both, and they have separate contacts for input and output. This means a combinator can actually have two green wires connected - one to input, one to output - without those being automatically joined into one network, and same with red. Still, as before, connecting two green to input or two green to output will combine those into one network. This may seem obvious, but as you make more complex things with combinators, there will be times you will forget and accidentally join two networks without intending to, causing your system to fail in strange and confusing ways. When designing logic systems, you have to think of the networks themselves as entities, because they are.

So, combinators are objects, and update during the object update phase just like everything else. There are three kinds.
Constant Combinators
Decider Combinators
Arithmetic Combinators
Special inputs - Anything, Everything, and Each
Ok, that's the theory. On to some practical stuff!
S-R Latches
Pulse Generators
Clocks and Timers


These practical examples are just one approach; there are no doubt others, possibly even better. Like everything else in factorio, designing is the fun part, so figure out your own approaches, and run with what works for you, and have fun!

Hope this is helpful. Reply with questions or to point out my no doubt many mistakes, typos, etc.

:edit: added a section on clocks and timers, which I realised I forgot about and which are as useful and important as latches.

Re: Combinators 101

Posted: Thu Aug 06, 2015 10:16 am
by ratchetfreak
would you mind if this gets copied/paraphrased to the wiki?

Re: Combinators 101

Posted: Thu Aug 06, 2015 11:07 am
by aka13
The guide is impressive, very nice job!

Although I think you should work better with text structure to make it easier to swallow. Walls of text are always hard to grasp.

Re: Combinators 101

Posted: Thu Aug 06, 2015 11:16 am
by GopherAtl
ratchetfreak wrote:would you mind if this gets copied/paraphrased to the wiki?
Not at all! As I said at the top, it ought to go there, I just posted it here first so it could get some attention and hopefully feedback to help improve it, catch any errors, etc. I just added a section on clocks and timers, which I forgot to include initially, and which are just as useful and important as latches.
aka13 wrote:The guide is impressive, very nice job!

Although I think you should work better with text structure to make it easier to swallow. Walls of text are always hard to grasp.
Thanks. I'm not sure how much more I can do; is the problem just psychological? As in, would more paragraph breaks help, without actually changing the text? I can insert more pictures, but again that'll just break it up visually, there's not much to be added informationally by more pictures. I'm open to suggestions for how to improve it, though!

Re: Combinators 101

Posted: Thu Aug 06, 2015 11:23 am
by aka13
I think that for such a complex topic you did an absolutely great job. No real space for improvement, maybe add some bells and whistles like a short summary to each combinator type. Or mazbe bigger captions for a more divided text.

Re: Combinators 101

Posted: Thu Aug 06, 2015 11:43 am
by -root
this is great! thank you for writing this up. I've been playing around with the RS latch... I'm yet to get it to work. The interface between the pulse generator and the latch are causing me issues XD

I might try some of these abstract ones to try and understand the concept better. I think I understand it. However implementing it is a whole different story.

Re: Combinators 101

Posted: Thu Aug 06, 2015 12:15 pm
by GopherAtl
aka13 wrote:I think that for such a complex topic you did an absolutely great job. No real space for improvement, maybe add some bells and whistles like a short summary to each combinator type. Or mazbe bigger captions for a more divided text.
Thanks; I made some edits, adding headings and breaking up the larger paragraphs into smaller chunks, as well as inserting a couple of pictures into the first section about circuit networks. Let me know if this is an improvement?
-root wrote:this is great! thank you for writing this up. I've been playing around with the RS latch... I'm yet to get it to work. The interface between the pulse generator and the latch are causing me issues XD

I might try some of these abstract ones to try and understand the concept better. I think I understand it. However implementing it is a whole different story.
That's the key, poking around and figuring out how things work. Until you fully understand what's going on, you'll have a hell of a time figuring out what's going wrong - and things will go wrong, they always do XD

A useful tip I keep forgetting to add to the OP: when testing circuits, you can use the game.speed setting in the opposite of the usual manner to slow things down. Setting game.speed to .05 will put it at about 1 update cycle per second - just make sure you're in range of any objects you want to open GUIs for, as it'll take a while to walk around at that setting!

Re: Combinators 101

Posted: Thu Aug 06, 2015 1:18 pm
by aka13
Yes, certainlz. It is now as good as it gets ;)

Re: Combinators 101

Posted: Sat Aug 08, 2015 4:12 am
by Alvin853
GopherAtl wrote: Setting the output to "input count" means that, if the condition is true, the number output on the signal is the same as the input on that signal. So, if you had a combinator test "iron plates > copper plates" and output signal "coal" as "input count", the combinator would output whatever it's total input of coal was. How many iron and copper plates were being input would not be a factor. If there is no coal signal being input, there will be no signal output regardless of the condition! If this seems strange, think of deciders in "input count" mode as a gate. They allow the signal of the type you select to be passed from input to output only if their condition is true.
I believe this is wrong, or it is more complex than this. In my case I was trying to use the decider as a gate, letting my iron count through only when green signal was true (=1), but the output of the decider was just 1 on the iron channel (equal to green signal input), not whatever the input on iron channel was.

Re: Combinators 101

Posted: Sat Aug 08, 2015 4:42 am
by GopherAtl
Alvin853 wrote:
GopherAtl wrote: I believe this is wrong, or it is more complex than this. In my case I was trying to use the decider as a gate, letting my iron count through only when green signal was true (=1), but the output of the decider was just 1 on the iron channel (equal to green signal input), not whatever the input on iron channel was.
Yawp, I was just coming here to fix it after testing it again in response to someone asking for help on reddit. The embarassing thing is that I already had this realization weeks ago.

Will be fixing that directly.

Re: Combinators 101

Posted: Sat Aug 08, 2015 12:52 pm
by Alvin853
You can get the desired effect of passing a signal through only when condition is true by combining it with an arithmetic combinator. The decider outputs 1 when condition is true, 0 otherwise, and arithmetic outputs signal * output of decider.

Also I'm pretty sure your "clock" example is off, the condition on the decider has to be "< 60". You want the 60 to act like a 0, so in the next update you get a value of 1, right now your clock is going "1, 2, ... 60, 61, 1, 2, ..."

Re: Combinators 101

Posted: Sat Aug 08, 2015 12:58 pm
by GopherAtl
Alvin853 wrote:You can get the desired effect of passing a signal through only when condition is true by combining it with an arithmetic combinator. The decider outputs 1 when condition is true, 0 otherwise, and arithmetic outputs signal * output of decider.
You can also output "everything," though that may let more signals through than you want.
Alvin853 wrote: Also I'm pretty sure your "clock" example is off, the condition on the decider has to be "< 60". You want the 60 to act like a 0, so in the next update you get a value of 1, right now your clock is going "1, 2, ... 60, 61, 1, 2, ..."
re: 61, Someone on reddit pointed (/u/khaim) that out already and I just keep forgetting to go fix it, but thanks, I'll stop being lazy and fix it now

Re: Combinators 101

Posted: Sat Aug 08, 2015 1:09 pm
by Alvin853
Nice!

Now we need a guide how to setup PID-controllers :ugeek:
P and I part are actually really easy to do, but making a differential with discrete time and input values doesn't yield the best results, so it may need some fine tuning, like averaging the differential over a couple seconds or so. I'm currently trying this out myself 8-)

Re: Combinators 101

Posted: Sat Aug 08, 2015 1:31 pm
by aka13
What the hell would be the application of a HARDWARE based PID-controller in FACTORIO?! :shock:

Re: Combinators 101

Posted: Sat Aug 08, 2015 1:41 pm
by GopherAtl
aka13 wrote:What the hell would be the application of a HARDWARE based PID-controller in FACTORIO?! :shock:
the same as in a real factory, naturally - to dynamically and automatically balance production to a changing rate of consumption. Though I suspect, limits of working with integers only aside, things tend to change a bit too drastically for it to be that valuable - real-world systems tend to run a bit more steadily to begin with than factorio ones do, and for much longer periods of time.

Re: Combinators 101

Posted: Sat Aug 08, 2015 3:29 pm
by aka13
GopherAtl wrote:
aka13 wrote:What the hell would be the application of a HARDWARE based PID-controller in FACTORIO?! :shock:
the same as in a real factory, naturally - to dynamically and automatically balance production to a changing rate of consumption. Though I suspect, limits of working with integers only aside, things tend to change a bit too drastically for it to be that valuable - real-world systems tend to run a bit more steadily to begin with than factorio ones do, and for much longer periods of time.
I have worked plenty with PID controllers IRL, I know what they are for ;)

The question was rather, since in factorio we do not have problems of "overproduction" and machines are put to a stop as soon as they are not needed, I do not see an application for a dynamic change of anything. Can you help me out and describe a situation where you want to use one?

Re: Combinators 101

Posted: Sat Aug 08, 2015 3:43 pm
by Alvin853
aka13 wrote:
GopherAtl wrote:
aka13 wrote:What the hell would be the application of a HARDWARE based PID-controller in FACTORIO?! :shock:
the same as in a real factory, naturally - to dynamically and automatically balance production to a changing rate of consumption. Though I suspect, limits of working with integers only aside, things tend to change a bit too drastically for it to be that valuable - real-world systems tend to run a bit more steadily to begin with than factorio ones do, and for much longer periods of time.
I have worked plenty with PID controllers IRL, I know what they are for ;)

The question was rather, since in factorio we do not have problems of "overproduction" and machines are put to a stop as soon as they are not needed, I do not see an application for a dynamic change of anything. Can you help me out and describe a situation where you want to use one?
For example I have an unloading station to deliver coal from outposts to my main base. Now I need coal mainly for power production, and to make plastics. Simply splitting is not the best option, because in case of a shortage I would want a higher percentage (or even all my coal) to go to my power plant to make sure I don't run out. I know you can probably do that with other setups, but controllers are fun and we finally have the circuit logic stuff to actually implement them :D

Re: Combinators 101

Posted: Sat Aug 08, 2015 3:55 pm
by aka13
Alvin853 wrote:
aka13 wrote:
GopherAtl wrote:
aka13 wrote:What the hell would be the application of a HARDWARE based PID-controller in FACTORIO?! :shock:
the same as in a real factory, naturally - to dynamically and automatically balance production to a changing rate of consumption. Though I suspect, limits of working with integers only aside, things tend to change a bit too drastically for it to be that valuable - real-world systems tend to run a bit more steadily to begin with than factorio ones do, and for much longer periods of time.
I have worked plenty with PID controllers IRL, I know what they are for ;)

The question was rather, since in factorio we do not have problems of "overproduction" and machines are put to a stop as soon as they are not needed, I do not see an application for a dynamic change of anything. Can you help me out and describe a situation where you want to use one?
For example I have an unloading station to deliver coal from outposts to my main base. Now I need coal mainly for power production, and to make plastics. Simply splitting is not the best option, because in case of a shortage I would want a higher percentage (or even all my coal) to go to my power plant to make sure I don't run out. I know you can probably do that with other setups, but controllers are fun and we finally have the circuit logic stuff to actually implement them :D
Hmmm, I think I would have balanced that with comparators and smart inserter ratios. Low power? Activate more smart inserters to the power production conveyor. A PID controller sounds somewhat overkill :lol: . But if you manage to get one running, do not forget to show it off, please!

Re: Combinators 101

Posted: Sat Aug 15, 2015 11:38 pm
by AndaleTheGreat
aaaaand bookmarked

Re: Combinators 101

Posted: Mon Aug 17, 2015 8:06 pm
by nobodx
Is there a smarter / better way to control your factory storage with less than a single constant combinators (to set the max items) + 2 decider combinators for each items you want to control ?

The way I set them up:

- a Constant combinator (eg. 50 lamps)

- a Storage chest (with lamps)

- a decider combinator
Inputs: lamps > 0
Output: signal 1 & amount of lamps
wires: green from storagechest to input

- another decider
input: signal 1 < lamps
output: lamps & amount of signal 1
wires: green from 1st decider output, red from constant combinator as input

- lamp (or green inserter)
input: lamps = 1
wires: green from 2nd deciders output

I hoped i described the setup well enough.