In this post I will show you the principles behind building rail networks in Factorio, so that you understand what you’re doing before you do it, you understand the problems when they appear, and, if no mistakes occur, you create networks that never jam ever.
“Contributors are instructed: “Wikipedia is an encyclopedic reference, not an instruction manual, guidebook, or textbook. Wikipedia articles should not read like … instruction manuals. ”
When I look something up related to computer science, it is normally because I am working on a project, and need to know how to do something, so I need something that reads like an instruction manual, guidebook, or textbook. Further, anyone who knows computer science stuff is usually an engineer, so is apt to write like a textbook or instruction manual. The effect and application of the not-a-manual rule is to prohibit contributions from people who actually do stuff, which contributions they intend to share with other people who actually do stuff, in favor of contributions by people who do not do stuff, and are incapable of doing stuff – which is to say, in favor of academic knowledge.”
- Game version: 0.15.37
- Current number of hours played: 89
- Longest game in hours: 30
- Total games played: 1 regular, 2 deathworld
- Total games completed: 0
- Time spent figuring out rail theory in hours: 6
- Amount of notes: 1 8.5×11″, 2 5000x5000px
- Number of perfect rail networks made: 1
I am writing this because all other explanations I’ve found were insufficient.
They’re either video tutorials, which are too long and too slow so they don’t matter, or they’re image and text guides, in which case all the ones I’ve seen had their priorities completely backwards. Like a bad and uninteresting class they spend all their time going over jargon and then straight into generic concepts everyone could’ve figured out beforehand, and none at all on basic principles and thus are not applicable to truly useful examples. They even provide you with blueprint strings so you’ll be even more sure you’re right while being even more confused if something goes wrong.
It’s confidence in the wrong place. Which leads to the expected result, results you may have seen: big-time youtubers with blueprint books of huge pre-planned intersections and stations, all auto-built with construction robots, only to run into a jam that they run halfway across the map to fix manually. And they’ll do it again. And again. Every handful of minutes.
The problem with these guides is they emphasize signals. They’re trying to properly signal intersections. All their planning and corrections are based off of placing signals correctly.
They’re not trying to build a rail network.
This isn’t a matter of being pedantic: “If all you have is a hammer, everything looks like a nail”. The point of a rail network is to have trains running properly, not to have signals running properly. The signals will always run properly. The question is do they run in such a way that your network runs properly. It is about the rail network’s purpose first, then about rail placement, and only at the end do signals come into play. Things must be thought about in that order: Network first, rails second, finally signals.
Approaching rail networks with that mindset clears all obstacles.
> Let’s Look at Networks
> Think in Blocks, not Signals
> What a Signal Means
> When, or Why to Upgrade to Dual Rails
> General Principles, Summarized
> Specific Applications
> — Intersections (3-way, 4-way)
> — Train Stations
> — Personal Trains
> The Blue Signal, Revisited
> References / Other Rulesets
This is probably pretty close your first encounter with rails.
You have a resource vein somewhere that you want to bring to base, and it’s too far to bother belting all the way back. Or you like trains. Reducing all unnecessary complexity leaves you with single rail-line, a station at each end, and a double-headed train which goes back and forth between them. No signals are required. No signal added anywhere will change anything.
Your next expansion to this network will either be due to 1) increasing throughput, or 2) adding another type of resource, which correlates to either 1) adding another train to this stop, or 2) adding another train and another route. What changes are required to make these work?
There’s a lot of complexity that appears at this point. Even just visually it can be overwhelming: a bunch of green or white boxes on either side of the rails, rail curvature is now more than just about getting around trees, and the signals of tantamount importance are both tiny and not very bright. So we will simplify, and look at things symbolically for the time being. This also brings us closer to what the trains themselves see. Trains don’t care if it’s your main station, a long stretch in the middle of a desert, or if there’s another train right in front of them – they only care about whether or not there’s rails, stops, or signals.
These are the minimum required rail changes for the first expansion.
Signals are also now required for the first time, so it is time to properly introduce their definitions. Trains read signals on the right hand side of the rail relative to their direction of travel; they ignore everything on their left. They also only read the next signal, and only read them when it’s within their stopping distance.
Rail Signal (“Regular signal” or “Regular”)
- Splits a rail-line into two Blocks: one before it, one after it.
- Shows colors based on the state of the Block after it, in this priority:
- Red: Block has a train in it. Tells train to stop.
- Orange: Another train will be in the Block soon. Tells train to stop.
- Green: Block has no train in it. Tells train to go.
Chain Signal (“Chain”)
- Splits a rail-line into two Blocks: one before it, one after it.
- Shows colors based on the state of the Block or the Signal after it, in this priority:
- State of the Block has a higher priority than the Signal after it.
- Red: A Block ahead has a train in it. Tells train to stop.
- Blue: A Block ahead has a train in it. Tells train to go.
- Orange: Another train will be in a Block ahead soon. Tells train to stop.
- Green: All Blocks ahead have no trains in them. Tells train to go.
The most important concept here are not the colors, of which there are effectively just two (“go” and “stop”), but the Block. In our “network first, rails second, signals last” mindset, “network” means Blocks. It is a network’s most fundamental division.
Simply, each Block can only have one train in it. Alternatively: each Block can hold one train. By default, any rails which are connected or cross in any way are defined as a single block. Each signal placed will add a block to the network (1 splits to 2, 2 with a split becomes 3, etc.). When placed properly, you should be able to trace a complete shape around every block.
The other important concept is that trains basically always stop in time for their signal. In other words: Time can safely be ignored in designing a rail network. Maybe once in a blue moon something will happen so that two trains happen to start going into the same block at the same game tick (1/60th of a second). But basically it won’t happen. Trains symbolically are equivalent to checker pieces: checker pieces are either in this square or the next; trains are either in this block or the next. As long as you make your blocks large enough to fit your largest train, that is. Which is easy since the signals will tell you how many segments can fit in its block when you place it. I suppose it’s possible to cause crashes if you put a regular signal right in front of another one so the trains will never see the other one in time, but if you’re doing such a thing you’re asking for trouble anyways.
Back to expanding our network.
Enough blocks must exist to contain the trains, and the blocks must be arranged such that traffic is not impeded. 2 trains means 3 blocks – one to allow movement (think: sliding puzzle). So long as 3 blocks exist, the trains will never create a deadlock. Since we would be using a double-headed train, we’d need to make sure to add rail to create a bypass on one of them.
The question then becomes: what type of signal to use where?
Guides usually talk about signals with respect to intersections, which makes sense since that’s what’s true in real life. But there are no chain signals in real life, and Factorio signals are for completely automated trains, so signals should be thought about with respect to Blocks. Throwing away the nonsense about colors, the two signals are:
- A Regular signal conveys information only about its own Block.
- A Chain signal conveys information about the next Block, so long as its own Block doesn’t have information of higher priority.
Translating all this to useful logic:
- Use a Regular signal when you want that block to be able to store a train.
- Use a Chain signal when you don’t want that block to be able store a train.
Which blocks are we okay with storing trains in?
Well, in our newly expanded network: all of them. So all of them are regular signals.
Though, more realistically, you probably want your trains to be waiting near the station rather than out in a bypass in the middle of nowhere. It’d increase the number of blocks but the principle is the same:
Where you’re okay storing trains, use Regular signals, where you’re not, use Chain.
For the other regular initial expansion of 2 trains on 2 separate routes, the total number of blocks is 5: 2 trains (which are also 2 stations), plus 2 stations, plus 1 intersection. We don’t want to store things in the intersection. Therefore, regular signals go everywhere except those that talk about the intersection.
For both of the above types of networks you could use chain signals everywhere instead of regular signals because there’s no real difference in the information that’s being carried. But it’s bad practice. Chain signals and regular signals aren’t replacements for each other either way. One is for storing trains, the other one is for not storing trains.
The signals exist so that we can see what the train sees.
So. What about bigger networks?
1 route n trains can still be done on one rail, with an additional bypass for each train.
The multi-route multi-train limit for a single rail-line network is at 2 routes 3 trains. Any number above this basically requires switching to dual rail-line.
Deadlocks appear because the necessary information for multiple trains moving back and forth on the same rail-line, namely, whether a bypass is clear, gets obfuscated in the intersection.
Intersections are built with chain signals, and chain signals which would previously be red (stop) would now read blue (go) thanks to the intersection, meaning they’ll continue through the intersection until they see red (stop), which, eventually, will be at the nose of the other train trying to go the other way.
You “can” change intersections to be regular signals instead, but that just increases your likelihood of a deadlock in the intersection because you are now saying “it’s okay to store a train in the intersection”. Such an intersection with a regular signal will simply be green instead of blue. It bears repeating again: as far as the train is concerned, signals only have two colors: “go” and “stop”.
The only solution to the intersection problem is to reduce the number of directions a train can do on a rail-line from two to one. If done everywhere, or at least properly in enough places, it turns the network from trains going back-and-forth on what’s effectively a really long line, to trains going around in a big loop and simply waiting their turn at intersections, stops, bypasses, etc. Deadlocks become impossible.
“At least properly in enough places” means, specifically:
No intersection blocks anywhere along a rail-line which serves trains both ways.
Every rail block which allows trains going both ways must split into two lines again before you define the end of the block. These bi-directional paths can’t have trains waiting in them either, so: they are defined with chain signals only.
This means that technically you can run n routes n double-headed trains on a single rail-line. They just have to all share the same intersection block.
Generally speaking it means switching to dual rail-line and single-headed trains. Which is appealing anyways because the networks are prettier, and single-headed trains are faster and/or smaller than any equivalent load double-headed train.
Dual rail-line stations and networks are bigger and more rail needs to be placed overall, but they are scalable and have no headache problems.
Single rail-line stations and networks means either 1) your far-flung trains will wait all the way over there until the entire way back is clear, or 2) you have a huge mess of intersections before your main station.
Okay so what does this mean? Give me something I can easily memorize or reference.
Principles for a Perfectly Deadlock-Free Rail Network
– Think of the network first, then rails, then signals, in that order. Know what you want to accomplish, fill in the details accordingly.
– Trains always stop in time if they’re told to stop. This means you can accurately test your creations simply by plopping a train section from your inventory onto any stretch of rail.
– See the network as the train sees it. Ignore trees, desert, etc, look only at where a train can go and what the signal ahead tells the train to do.
– Single rail-line networks are simply lines.
– Dual rail-line networks are simply loops.
– Signals have two colors: “go” and “stop”.
– Signals are colors, but represent blocks.
– Any rails connecting or intersecting in any way with no signals inbetween is one block.
– One block can hold one train.
– Minimum number of blocks for a system to allow movement is ((trains) + 1).
– A block starting with a regular signal means “a train may be stored here”.
– A block starting with a chain signal means “trains can only pass by here”.
– This means the primary question in designing a rail network is how to place rails so that they create blocks which accurately reflect each block’s intended role. Signals are placed only well after each block’s role – either “trains can be stored here” or “trains can’t be stored here” – is decided.
The Cause of Deadlocks:
– Intersection blocks kill feasibility of single rail-line networks – that is, a single rail serving trains going both ways – because they kill the necessary information for the network to function. A signal that would’ve previously been red (“stop, a train is coming towards you”) becomes blue (“go”) because there is another exit. The information is true, but useless to the network as a whole.
– Single rail-line network is feasible up until 1 route n trains or 2 routes 2 trains. If the network has >2 routes and >2 trains, dual rail-lines are effectively required.
– Any rail block which serves trains going in both directions must end, on both ends, in two single-direction blocks. Alternatively: No intersection blocks are allowed between any two bi-directional single-rail blocks.
No no I meant I wanted actual in-game screenshots of stuff I can use so I know what you’re talking about actually works and isn’t just fluff.
I design my intersection blocks on the following additional principles:
- The number of tracks and spaces used should be minimized.
- A train should know as soon as possible whether its specific path is clear.
If possible, I want to signal this to a train before it enters the intersection at all.
Is this possible in Factorio?
But, for 3- and 4-way intersections, you can get pretty close. Close enough that it might as well be true that it didn’t enter the intersection. All while using the minimum amount of space, and the minimum amount of work needed to change between intersection types.
Important here is how Factorio sizes its tracks and where it allows signals.
There are two fundamental shapes of rail in Factorio: A straight rail, and a curved rail. The curved rail is always the same curvature, namely 1/8th of a circle, so a 90 degree turn will have 2 curved sections in it somewhere. Controlling what section you get is a little bit fiddly. Just remember you’re playing a 2D game – when planning or placing rail, your options aren’t “somewhere that works”, “somewhere that doesn’t work”, or “somewhere that makes it look stupid”; it’s “move mouse in-line with rail to extend it” or “move mouse orthogonal to rail direction to make curved sections appear/disappear”.
These curved sections have different spots for signals to appear than straight sections do. A straight horizontal or vertical section has 2 signal spots at regular intervals along its length. A curved section has 2 as well, but only at the beginning and the end. (A diagonal has 1). The beginning spot is part of the marge/split, so a chain there doesn’t actually tell us what we want to know. So we are left to the next one.
Signal spots do not appear at all if they are occupied by rail. If you have some huge mess of rails laying on top of each other, there will be no way separate that into multiple blocks.
Therefore, if we want a train to know as soon as possible whether its own path is clear (specifically: its block after the intersection), we need to make sure that each rail splitting off separates as far from the other rails as soon as possible.
Since there’s only one type of curved rail, we only really have the ability to do 45 degree splits in either direction off at the same point on the rail. But it also means maximizing split “rate” is easy: just split them off at the same spot.
The smallest “turn” in an intersection would be a right-hand turn. This defines the minimum size an intersection can be. In Factorio, this comes out to a radius of 9 (Alternatively: 6 rail spaces non-inclusive). That’s the number you want to go for if you want to place the rails correctly the first time and not fiddle with the planner.
What about the other direction? Where should the other two lines be spaced, so that it’s symmetrical (because looking nice is important), and that we still have the information we want as soon as possible?
The correct spacing for this happens to be 6. Alternatively: 3 rail-spaces.
All signal slots are preserved when expanding to 4-way.
On the inner spots you may encounter trouble placing the signal on the right side of the track you intend rather than the left side of some other one. If that occurs, press R to rotate the signal.
We don’t want to a train to be stored inside the intersection, we want trains to know whether or not their desired route beyond the intersection is clear before it. This means the intersection block must be defined by all chain signals.
These are technically complete. No train will ever stop inside either of them, and trains will always stop before the intersection if their destination path is not clear.
That second quality is not true of all dual rail-line intersections. To use a semi-official example:
“You can use chain signals to protect any kind of crossing, for example this big one. Only one train can enter the crossing at any time.”
This is a true statement about that example.
It’s also true that a train’s not going to know anything about its destination path until it’s almost there, at which point it’s already inside the intersection block, thus clogging up the block for any other train coming from any other direction.
I like to put storage blocks both before and after an intersection just in case there’s something else going on somewhere. If something does happen, then all the non-problem trains are isolated to near intersections, where I know the problem doesn’t exist.
As an aside: since diagonal tracks exist, the theoretical maximum for an “intersection” is actually an 8 way. But it’s impossible to signal in the way I want without expanding the spacing of the tracks beyond 6. Even at 6 it’s already pretty ridiculously large already thanks to the acute right-hand turns.
I also don’t see a point in making an 8 way because I can simply designate holding blocks before the intersection. Intersections almost always have long stretches of empty rails either before or after them, leading to or from the base. Just stick a few regular signals here and there to accommodate the number of maximum trains that’d be on that route, problem solved.
A single rail-line network necessitates double-headed trains. A dual rail-line allows single-headed trains. A double-headed train can run into any station, a single-headed train can only successfully come back from a station that has a looparound.
This means you can keep your old resource train stations as single rail-line while only upgrading your main to dual (i.e. it loops around) to accomodate future improvements. It also means you can keep building small single rail-line stations – so long as you remember to put a double-headed train on it.
A lot of videos I’ve seen on railworld settings have these gigantic bypass/waiting areas before even bigger stations. But this doesn’t have to be the case – as far as the trains are concerned, anyways. If the rest of the network is set up correctly, deadlocks won’t happen. Maybe traffic will, but not deadlocks.
The main benefit is that it looks pretty. But it also costs a lot of space. I personally prefer things that take less space over using up that much space, and working around trees rather than burning them down. That and I’m on deathworld right now, evolution is at .88, and Laxeris and I don’t have behemoth defenses up yet.
So what I’ve done is merge the bypass into the station.
Make all the stops not specific to any resource, and even out the trains between all available stops. Make each stop’s rail-line long enough for multiple trains, so that even if a train is waiting to get to the station, its contents are still being exported. This requires sorting out the exported resources somewhere else down the line, but it reduces the number of total amount of space required overall, and increases the space’s efficiency. A train waiting to get somewhere to export stuff while exporting its stuff is better than a train waiting somewhere and doing nothing.
If you don’t have a personal train stop for where you are going, things will get backed up.
If you don’t obey either signals or traffic flow, (i.e. turning into a left-handed rail) there will be a crash sooner or later. It won’t cause deadlocks.
If you do however do both, no problems will arise anywhere.
And that’s it.
I recommend taking out some paper and copying some examples, the ones shown here or others (some can be found below in References), just to get a feel for doing it yourself before doing it in-game. Drawing symbolic diagrams is both much quicker and clearer than placing actual tracks down in-game, and more conducive to absorbing the information than placing down tracks and just “testing” i.e. fiddling things out because you are forced to simulate it in your mind first and have a confident expected result beforehand.
Speaking of confident expected results…
I was completely sure that Blue on a chain signal meant “go”. In my post-writing research I’ve found people saying Blue really means “whatever color is relevant on the next block that’s on this train’s path”. So if the train’s next block is occupied, “Blue” actually means “stop”. Now that I’ve read each word closely again on the official definition
While normal signal prevents train from entering the occupied block, chain signal prevents train from entering the block also when the exit isn’t free. When more exits exist, the one relevant to the train path is taken into account.
such an interpretation reveals itself to me. I’ve now tested it and it appears to be true.
But as far as I’m concerned the presentation of the wiki page and all the material I’ve seen on the chain signal in or out of the game up to this point has been a deliberate hiding of this information. I’m not a believer in Hanlon’s Razor, especially not when there’s all these people running around claiming either through their actions or through their words that they’re experts and you should listen to them, and this is a really complicated game so you should keep listening to them; remember to hit like and subscribe!
Why would it be termed “at least one exit is free”?
Does the train think it means “at least one exit is free”? Is that really the best way to put it? If it’s a bypass then it’s accurate. If it’s an intersection, i.e., if it’s at the most likely place of all places for a deadlock to occur, the most important problem about rails that everyone’s trying to solve, then no, it goddamn fucking isn’t.
Calling blue “at least one exit is free” effectively amounts to lying. If you’re trying to get out of a building and you ask for directions, and you’re told beyond that door over there, “at least one exit is free”, do you understand that answer as a “go for that door” or “don’t go for that door”? Because that’s the actual decision that’s going on. Additionally, it means blue is the one signal color out of the four which is completely useless to the player. “At least one exit is free” well golly gee thanks, because I don’t have eyeballs to see. What I want to know when I’m looking at a signal is what the train sees. If blue really does mean “it tells the train what it wants to know without telling the player what he wants to know”, why fucking bother with signals at all? Just make them run by themselves why don’t you, and I’m not being sarcastic on that one; a game about automation or not you can’t start completely changing things up for one instance.
“Hey I’d like to know how to get out of here?”
“Sure. At least one exit is through that door.”
“No there isn’t.”
“Oh. You’re right.”
“Hey there, I overheard your conversation.
What exactly did he mean by “No there isn’t”?
And what did you mean by “Oh you’re right”?”
Well whatever. All my rules and designs still work.
This does mean that the designs are less efficient; the intersections I designed actually use more rails, space, and signals than they need to. And the 1 route n trains / 2 routes 2 trains limit on single rail-line networks isn’t actually the limit because the important information really is passed through an intersection… I think dual rail lines with queues are still more efficient, but I’m too bothered by this revelation to bother any further.
But thankfully, and most importantly, it also means that I’ll basically always know what’s going on if I ever make a mistake.
Because none of the signals I place will ever lie to me.
The principles of “know about the specific route as soon as possible” and “place signals only after you’ve decided where blocks must exist and what types of blocks they are” simply prevented this from becoming a problem. They just so happened to be logically equivalent to “never place a chain signal where it can read more than one route”… but saying I did it “because” of that would be false. I really did believe blue meant “go”, that it’d be a regularly appearing color that meant “at least one exit is free”. But it didn’t matter, because I did all my thinking around the colors of “go” and “stop” instead. I just thought in the generally correct direction, and the minor problems parted a way for me.
I had to write this addendum, and I probably should’ve rewritten the whole thing. Nevertheless, this is the optimal scenario to be wrong in. It could’ve been the results were wrong too, and the spectre of random unknowable deadlocks still haunting my networks.
But it isn’t. It’s dead. And I killed it, at the low low price on being wrong about some inconsequential color, and the extra materials it takes to buy dual rail-lines and honest signals.
References / Other Rulesets
NSVDW’s “Train Signal Tutorial”
Good clear examples to copy from, overall easy to understand.
Incomplete but doesn’t lead you in wrong directions.
gliph’s “Trouble with trains? Here’s three simple rules to simplify your train network.”
CircularRoot’s “Train signal rules to prevent deadlocks”
Causes a deadlock in your brain.
lolnololnonono’s “Fuck 40-minute tutorial videos, fuck chain signals: Start using Trains today!”
Pretty complete and overall correct. Shouldn’t cause any deadlocks.
As good as it can get without actually understanding what’s going on.
Grays42’s “Factorio Train Automation”
Useful for all the example images because they focus around blocks. Seems to be correct.
Couldn’t be bothered to read all the text though. Too many color and location changes.
Factorio Official Wiki’s “Rail Chain Signal”
Lying sack of shit.
Factorio Official Wiki’s “Railway Signal Tutorial”
Misleading about chain signal functionality. Problems probably won’t arise if you follow this becase it’s approximately correct, but if they do, you won’t be in the mindset to clearly approach them. “It doesn’t matter what you know, it matters what you can think of in time”.
Wall-Nut’s “Rails Signaling for Dummies”
It has one rule and the rule is wrong.
There’s a lot of good rail (read: not signal) designs in there though.
Anyone’s “Complete Video Tutorial”
You don’t learn things by watching videos or reading posts.
You learn by doing them in your head before you do them for real.