Factorio Forums

There's been some hubub on the forums of what to do with combinators, so I figured I would post some of my ideas as I think of them.
Since it is difficult to show wire connections and individual combinator conditions with screenshots, some of what I post will
be wiring diagrams, in which I will use a form of shorthand. Here's an example: This example is for a mining drill layout, that sends a signal to your main base when the drills have run dry.
All my diagrams read left to right (left side of a combinator is input, right is output) unless otherwise noted.
In each box, the top line is the input conditions, and the bottom is the output. In the above example, here's what each box is doing:
1 - When iron ore in the box (called "I") = 0, output a Red signal.
2 - When I = 0, output Everything (input count)
3 - When Red > 300, output a Green signal

Together, this setup outputs a green signal when the box has remained empty for more than 5 seconds (aka both drills are dry).
This can then be used to create a available resource bar for the outpost at your main base; a string of lights that start out all lit, and turn off as the outpost runs dry. I will post a picture of the implementation later.

Here's what it looks like in game:
First image shows what it looks when all mining drills are running. In the second i have turned 2 of the drills so the chest is emptied. Representing what happens when the drills run dry. The third is an example of what it might look like at your main base, reporting on 3 separate mining outposts.

This is the first usefull thing i found for the Combinators ...
Great!
... i have believed the are useless for a normal fabric.

This idea is very promising, but it requires a lot of space: 4 cells per each mining drill.
It will be better to measure energy consumption rate for the whole mine, and calculate the number of active drills from it.

or the amount of ore going through a belt.

XKnight wrote:This idea is very promising, but it requires a lot of space: 4 cells per each mining drill.
It will be better to measure energy consumption rate for the whole mine, and calculate the number of active drills from it.

It's 3 combinators per 2 drills, and they are all within the drills mining area. How would you even go about isolating and measuring the energy consumption for an outpost?

Isolating is easy, use accumulators as a bridge between networks.

Measuring needs to wait until 0.13.

Lupoviridae wrote:

XKnight wrote:This idea is very promising, but it requires a lot of space: 4 cells per each mining drill.
It will be better to measure energy consumption rate for the whole mine, and calculate the number of active drills from it.

It's 3 combinators per 2 drills, and they are all within the drills mining area. How would you even go about isolating and measuring the energy consumption for an outpost?

Perhaps, this discussion should be placed in a new topic, but I am too lazy to do it .

The main idea is not to measure energy usage (EU), but measure 300 - EU.
I created some test project:



Here, my outland mine consists of 4 radars, with 4x300 = 1200 kw.
Mine is supplied from main network via "big bridge" and from detector via "small bridge".
Overall there 5 accumulators, and each accumulator provides 1200/5 = 240 kw to mine.
Detector always consists of one steam engine with 510 kw.
Steam engine provides some extra energy that is useless for detector (510 - 240 = 270 kw), this energy is spended for some dummy job (like 9 pumps x 30 kw = 270 kw).
When energy consumption in outland mine falls, free energy appears in detector, and this energy goes to the second priority contour.
Second contour consists of self-increased clock (C1) and some dummy workload. This clock goes faster or slower when there more or less energy.
Also, there exists some clock generator (C2) which creates measurement point for logic unit.
Logic unit is very simple: it remebers two last C1 values at each measurement point and provides C1_[N] - C1_[N-1] to indicator, that is placed on the base.

For the future - if you need a clock than constant combinator with 1 tied to decider with input < amount and loopback you can make a timer counting for arbitrary amount of ticks +/- counter delays.

ratchetfreak wrote:or the amount of ore going through a belt.

I'd love to see a Sensor to measure Belt throughput, but I don't know that the devs have any such plans.

(I also remember that the devs talked about Lamps being able to show different colours, but that appears to not have been implemented in 12.0.)

I'd really like for lights to be able to change color according to the value of a signal.

Peter34 wrote:

ratchetfreak wrote:or the amount of ore going through a belt.

I'd love to see a Sensor to measure Belt throughput, but I don't know that the devs have any such plans.

This can be done with some smart chests, though its a little bulky. You can measure how many pass through the chests in a certain amount of time.

Sander Buruma wrote:I'd really like for lights to be able to change color according to the value of a signal.

This is in the roadmap for 0.13 last I heard.

Came up with a basic register that works without having to break numbers down into binary first, just stores a 32-bit input value directly in a combinator when it gets a write signal.

I included the power poles in the blueprint to make it easier to connect things without having to know and remember which of the 8 combinators do what.

red wire on the right pole is for inputs; two inputs are expected, the value to write, which is currently expected as some number of crude oil barrels, and the write signal, which is on signal '1'. the write will occur the cycle after this changes to 1. It is not a continuous write - changing the input count while holding the write signal at 1 will NOT keep the register updated, the write happens once the moment the write signal goes to 1! For it to work properly as in the blueprint, it is important that the input wire network NOT have any '0' signal on it, as it is used internally and an outside value will break the register.

Output is also in crude oil barrels and is carried on the green wire on the left pole. It's using oil barrels because of the test setup I was using it on, but can be changed to any other item type or signal easily, just open the guis on the four arithmetic combinators and change the types of their input and output from crude oil barrels to whatever you want.

I wanted this to be easily usable as-is, but note that the top-right decider combinator is not, strictly, part of the register; it simply converts the input signal into a normalized signal for the rest of the circuit. You can freely modify that combinator's settings to your situation; whatever condition makes it output 1 will trigger the write when it happens.

if you're trying to work out the wiring to reverse-engineer it, a tip: reversing combinators (hover and 'r') doesn't affect wiring, so it makes it possible to see wires that are too small (as between adjacent combinators) or ambiguous in which they're connected to.

The test rig above the register has a smart chest, containing some number of oil barrels as the input; the constant combinator outputs the signal on '1' that triggers a write.
The green output wire is connected to the smart chest and two inserters on that side. The inserters use a condition "solid fuel < oil barrels" and "solid fuel < oil barrels" and will insert or remove solid fuel so that the amount in the left chest equals the value of the register. This example is not terribly useful - almost the same could be accomplished by just connecting the right chest into the circuit, without any combinators - but it has the benefit of being clocked by the write signal, so the inserters won't just be constantly fiddling with items if the right chest is being used in some system.

As a more practical example, I'm using this system currently on carriages for oil. Here's a screenshot of the test station from when I was developing the system:

(it looks different, as I was still prototyping the register and so didn't have the blueprint yet, but the register is exactly the same)
When a train arrives (as detected using a method based on /u/freetambo's post about combinators and trains on reddit) the smart smart inserter that unloads empties from the station chest back to the factory is disabled (it will be empty at this point unless the station is completely overstuffed) and a register like this one gets a write signal, saving the amount of filled oil barrels in another chest awaiting loading. I pass that value through a pair of arithmetic combinators, which divide by 10, which gives the number of stacks of these full barrels, then multiplies back by 10 to give the number of barrels in stacks. The smart inserter removing from the train is connected to the register's output and it's own chest, and pulls on the condition "empty barrel < crude oil barrel," so it pulls exactly as stacks of empties as there are stacks of full to replace. Loading the full barrels just uses a smart inserter with no conditions.

The result is that each oil outpost using this setup loads only full stacks of oil barrels, and unloads exactly as many empty barrels as necessary to replace the ones going out, so all my outposts maintain a constant number of total barrels, without having to saturate every outpost with barrels or deal with most of the issues that can normally come with managing the supplies of empties and have, in the past, led me to stop trying to keep full and empty barrels in the same carriage.

This is just one possible application, I have no doubt I will come up with others over time; how practical and justified it is as a solution to a relatively minor problem is entirely subjective, of course, but I'm extremely pleased with the results.

I came up with my own register, capable of storing any value for any given items. For example, it could store 512 iron plates, 210 copper, and 123 coal, all in one register. It essentially takes a snapshot of everything currently on the red circuit.
A couple things to keep in mind:
iE means output Everything (input count)
In implementation, the wires labled red and green would all be connected to a main bus. I ommitted this in the diagram to make it easier to read.
Input for each box is on the left, output is on the right.

Here's the wiring diagram: Combinator 6 in the diagram is what does the heavy lifting, and it works by using "pulsed" (single tick length) signals. For this reason I call it a "Pulsed-Value Register" or "PVR".

In this setup, the green wire carries the read ("0") and write ("1") signals as well as the address ("A"), while the red wire carries data.

The first pulse of a green signal to that combinator causes it to remember all current input values. The next clears the memory. This does mean that before it can be used, the register must fist be initialized with a single green pulse, which can be done by disconnecting one of the combinators labeled 4 and performing a dummy write.

Here's the breakdown of what each component does:
1) If the address signal ("A" == 5) and write ("1" == 1) are both enabled, outputs "Blue" == 2

2) If "Blue" == 2, outputs "Red" == 1. This gets added to the constant combinator for a total signal of "Red" == 0 and "Green" == 1.

3) While "Red" == 0, initiates a counter that counts up until "Red" =/= 0, at which point it resets. This is what allows the pulsed signals in the next step

4) When "green" from the counter hits 1 and 2, pulses green signals into the next cell.

5) Passes the input signal from the red wire to the memory component when the green pulses occur.

6) This is the memory component. First green pulse causes it to store all input values into memory. The next green pulse erases memory. Once initialized, this happens in reverse, so when a write occurs, it first erases the old memory, then writes the new values.

8) When the address ("A" == 5) and read ("0" == 1) are both enabled, passes "Blue" == 2 to combinator 7.

9) Filters out the "Blue" == 2 and "Green" == 1 signals from the read output.

7) When "Blue" == 0 (a read occurs), passes the value of combinator 6 onto the red wire.

PS. I will post an in-game picture later.

@lupoviridae: nice! Seems like a rather different approach from mine, particularly in generating the pulses. I've got one that adds addressing somewhere, but haven't gotten it properly tiling yet; I actually needed this one for something in my game, while the addressable memory banks, I have thought of no practical use for, yet. Toying with putting together a basic CPU at some point, though, so will need it for ram at that point.

GopherAtl wrote:@lupoviridae: nice! Seems like a rather different approach from mine, particularly in generating the pulses. I've got one that adds addressing somewhere, but haven't gotten it properly tiling yet; I actually needed this one for something in my game, while the addressable memory banks, I have thought of no practical use for, yet. Toying with putting together a basic CPU at some point, though, so will need it for ram at that point.

I've got huge banks of binary ram that I'm putting up in my world for (eventually), a computer. But I am dreading actually making the CPU. I have no idea where to even begin, besides making an ALU...

I couldn't justify dealing with binary ram at this point, having a good, fast, and seemingly reliable 32-bit memory cell to work with instead. As for the rest of the computer, well, other than memory and the ALU, all that's really left is an instruction decoder, and possibly a bank of ROM for entering the program. How complex the instruction decoder is depends entirely on your instruction set. If you're not sure how to approach it, just with a very simple one. Heck, if you use registers that output "all," a single cell of rom could have the operation, source address, and destination addresses, all thrown on a bus together on separate signals, then you wouldn't need much real decoding at all, just a master clock that directs everything.

GopherAtl wrote:I couldn't justify dealing with binary ram at this point, having a good, fast, and seemingly reliable 32-bit memory cell to work with instead. As for the rest of the computer, well, other than memory and the ALU, all that's really left is an instruction decoder, and possibly a bank of ROM for entering the program. How complex the instruction decoder is depends entirely on your instruction set. If you're not sure how to approach it, just with a very simple one. Heck, if you use registers that output "all," a single cell of rom could have the operation, source address, and destination addresses, all thrown on a bus together on separate signals, then you wouldn't need much real decoding at all, just a master clock that directs everything.

Honestly I only made the binary RAM because I wanted to learn how real computers work. I self-taught myself everything in the past month or two, starting with how individual logic gates work. I figured since I can't build a computer IRL, building one in factorio would be the best way to test my knowledge. Now that I know I can do it, I'm thinking of just dropping the project, and starting again with a more Factorio-friendly layout.

GopherAtl wrote:I couldn't justify dealing with binary ram at this point, having a good, fast, and seemingly reliable 32-bit memory cell to work with instead. As for the rest of the computer, well, other than memory and the ALU, all that's really left is an instruction decoder, and possibly a bank of ROM for entering the program. How complex the instruction decoder is depends entirely on your instruction set. If you're not sure how to approach it, just with a very simple one. Heck, if you use registers that output "all," a single cell of rom could have the operation, source address, and destination addresses, all thrown on a bus together on separate signals, then you wouldn't need much real decoding at all, just a master clock that directs everything.

with the 32 bits you can do just about anything with just a = decider for each instruction type in 1 signal and using a few other signals for the registers (or use divide, multiply, subtract = modulo to extract things)