Here we are, the last of my promised posts from the end of last month. It took me a while to get here but it’s for the best, since every week along the way I’ve learned something new about dealing with trains in the Satisfactory game.

Thank goodness this is just a game, especially one where pesky issues like “gravity” and “structural integrity” don’t entirely matter to what you build.

I got into two new “saves” at roughly the same time: A co-op game with the kids where we started out in the desert (a new starting biome for all of us), and a new solo game focused specifically on using trains as much as possible. Since I was heavily “into” trains in my personal save, I ended up doing a lot of similar rail work in the game with the kids as well. In both cases my goal is the pursuit of a fully integrated rail network. Previously I’d only ever made point-to-point rail lines, most often in the ‘push-pull’ configuration (after some misguided efforts involving looped endpoints).

Armed with knowledge gleaned from watching a couple of YouTube videos, however, I figured I was ready to proceed. So, what have I really learned and how is it working out overall?

The Core Inside Loop

I’ve had the most luck with centering the network on one main “there and back again” loop of rail. At no point should two trains ever be facing one another on the same piece of track. There are three key principles to keep in mind:

  1. The game will always calculate the shortest possible route from station to station. (We’re ignoring Path Signals right now.) This can, and does, mean that if a station is located “inside” of your “main loop” the game will simply route everything through said station rather than along the (uncluttered and available, but longer) outside loop. To keep things tight and quick, build your stations “out” from the main loop as often as you possibly can. This has the side benefit of slightly reducing the transit time for trains just passing through on their way elsewhere.
  2. If you think you have enough Block Signals… double-check anyway. Sprinkling these along your route, both the “main loop” and subsidiary loops for pickup & delivery stations, will do wonders for keeping traffic flowing. Once, in the game with the kids, I’d added a new drop-off station but forgot to put a Block Signal at the exit… so trains that wanted to go past that station while it was in use couldn’t because that chunk of rail was marked as “occupied.” Any connected set of rail pieces (such as a straight rail line with a ‘Y’ junction curving off) is considered occupied (or not) based on whether it has a train on it, and the boundaries of that connected set are defined by Block Signals.
  3. Right-hand drive is best for this particular game. This has nothing to do with nationality and everything to do with the design of the Block Signal, which sits off to the right of the track join on which it’s placed. (Signals can only be placed on the “breaks” where one placed piece of rail meets the next.) If you face it the other way (on the “left side”) it will only affect trains going the other way. Which isn’t terribly useful. Trying for a left-hand drive arrangement will mean that you can have Block Signals that are superimposed on one another “inside” of two side-by-side chunks of rail, making readability something of a challenge. They’ll still work, of course, but it’s kind of janky, isn’t it?
When you see a traffic jam like this, partly you feel relief that there weren’t any collisions but mostly you realize that something needs reworking. In this case, that loop-return off to the left had to be completely redesigned.

One nice thing about the game is that even if a train has picked up considerable speed by going down a (relatively) steep slope such as the one you see at the top of this post, it will stop if a Block Signal says to. On the other hand, you’ll also notice once you have a few train lines running that you might need to add some Block Signals along some of the more desolate stretches of long-haul track. The game will happily designate a several-kilometer run as “occupied” when the next train ahead is most of that distance away. Remember the 2nd principle above.

Don’t Cross The Streams

Related to the routing and Block Signal issues is a rule I’ve made for myself because the two times I’ve tried to do it the easy way it’s gone badly. The rule? “Always place route loops over or under the the main loop.” Or, more succinctly, “Don’t cross the streams.”

In the screenshot above, four trains are queued up waiting for a fifth to clear a bit of track. Because the return loop it’s using crosses both the outbound and inbound track pieces, the Block Signal system marks both directions as one segment, blocking any movement through it until whatever train is on that segment gets out of the way.

(The experts among you will now be asking, “Why not just use a Path Signal?” And yes, that would help a bit in this particular case. Unfortunately those are more expensive and I don’t make that many Computers yet. Rest assured that Path Signals will be part of my future since they also resolve the case of mergers where two trains are waiting and get the “go” signal at the same time. Until I get more hands-on experience with them, however, I can’t really talk about how best to use them.)

I’ve had Block Signals go into an error state and trains just collectively decide not to go anywhere anymore when these crossed tracks show up. It’ll work just fine for a while… until it doesn’t.

This screenshot was taken before I’d added signals, but trust me: This never ever worked as intended. Despite looking like it SHOULD have. The solution to this specific problem instance will appear at the end of this post.

So, I get a lot of use out of the Z-axis. It’s certainly more visually interesting, if also logistically more challenging.

(As a side note: It’s a good idea to periodically sprinkle “return loops” along the main loop route. Otherwise your trains have to go the entire length of your main loop to get “back” to a station way off in the other direction. Letting trains exiting stations re-enter the main loop heading in its ideal direction is preferred, of course, but that isn’t always practical to build out.)

The Pros And Cons Of Blueprinting

With the game Update released late last year we received The Blueprint Designer (aka The Blooprinter) and all the wonderful prefab joy it brings. There’s nothing quite like slapping down an entire pre-designed chunk of material & equipment right where you want it with a single mouse-click, is there?

And that’s great, but it’s of limited use to the train builder. Don’t get me wrong, though, it’s certainly an improvement over the other best method for running rails: Zooping (the game term for rapid-building up to 10 of something in a straight line) hundreds of foundation tiles out over empty space and dropping rail lines on top. Which is, you’ll note, the method used for almost everything seen in the above screenshots.

How does blueprinting improve on this? You can make in the Designer a prefab block of rail with (purely cosmetic) supports that’s (just shy of) four foundation tiles long, save it as blueprint entry, which you can place as needed and then snap rail segments between to join them up.

This is something of a prototype. In the game with the kids I did more with the beams, but the basic result is functionally the same.

What I’ve done, and you probably will want to change this up for your aesthetic and practical purposes, is made something I can stack on a pile of foundations (or just plunk right down on the ground, if appropriate). I then delete the pile of foundations (if present) and extend concrete pillars down to the ground from my new block of supported, sparsely decorated rail stuff. After that it’s just a matter of hoping I built it at the correct distance and height to make a smooth, working connection by running a rail piece from one of these blueprinted sections to another. (And yes, I’ve misjudged the distance a few times. D’oh.)

I have a couple of tricks to recommend here.

  • Make two versions, a two-track and single-track design, so you have something to use when you’re making return loops and such. Trust me, having to delete half of all the fiddly bits every time you need a single-track version of this is a giant pain in the rear.
  • When it comes to placing rail, actual foundation tiles are ideal because rails snap to various points on them, which they don’t do on other surfaces (such as pillars). I hate wavy track on my blueprinted design that I will be using several dozens of times (or more) during the game. My technique, roughly, is to place pillars in the middle and at each “end” of the structure (you can’t hang rail out over empty space), place foundations on top of each (half-size foundations for the ones at the edges of the Designer space), delete the uppermost pillars, place foundations just underneath the previously placed foundations, delete the now-topmost foundations, then use the remaining foundations (which are at the “correct height” now) to snap your rail lines into nice tidy place. Then you can get rid of the foundations and re-add the “support” pillars. (And delete the “outside” pillars since you don’t need them anymore, now that the rails are in place.)
  • Build four pieces of rail on your dual-track design (and two on your single-track design), starting from the pillars and going out to the “ends” of the structure. This allows you to place Block or Path Signals right there at the pillars, which aesthetically looks much better than having them off-kilter at one of the “end” joins. (Side benefit? You now have three snap points for splits and mergers instead of just two. Hey, it could come in handy, you never know.)
The entire reason I made the rail segments on the blueprinted designs as long as the Designer would allow is to reduce the amount of “rollercoaster” effect by relying on the game’s tendency to “smooth out” the joining rail lines.

There are a couple of downsides to keep in mind, however. For starters, you can’t simply blueprint a replacement “support structure” to hang off the bottom of existing rail lines. Trying to place a blueprinted design on a chunk of rail results in the game placing it on top of the rail instead of attaching underneath (like you can when simply building a pillar). Believe me, I really hoped this would work. Alas.

(I’ll just hang simple pillars underneath the existing rail lines. It’s something to do when I’m waiting for something else to finish.)

Also, you can’t simply string a bunch of these designs directly snapped together and have the rail parts actually connect. If you come up with a continuous rail “roadbed” design (a fancy improvement over what I’ve done so far) what you’ll need to do is make two versions, one with the rail pieces in place similar to my design above, and one with no rail pieces at all. Then, place them in something like a 1, 2, 2, 1, 2, 2, 1 sequence and string rail lines between the “ones” along the “twos.” It’s a bit tedious, but it’ll get the job done.

Supply And Demand

There are a few things you may want to know about the actual use of the trains and stations, so I’ll cover what I can think of here:

By clicking the “gear” icon for a given station in your train’s itinerary, you can limit what it will pick up or drop off. This allows you to send different trains to one particular station without all of them grabbing other stuff you didn’t actually want.

On a related note, make sure you keep track (as it were) of what’s in which position at each source and destination station. It seems obvious, but when you find yourself hiking (or riding a train) from one end of your domain to the other just to remind yourself as to whether the HMFs were in the front or the back platform… well, let’s just say I’ve done this more than once myself. Learn from my mistakes, friends. You probably already have a spreadsheet for factory math, go ahead and use that (or some other note-taking system) for tracking station logistics as well.

There’s nothing stopping you from sending two trains on the same route to double your “bandwidth,” nor from telling one train to pick up from Source A, deliver to Destination Z, pick up from Source A again, deliver to Destination Y, then lather rinse repeat.

If you’re going to be busy at a build site out in the far reaches of your growing domain and don’t want to hoof it back and forth for supplies all the time, consider a taxi train. Just build a no-freight-car train and a station for it to live in next to your Hub or other main storage area, then once you have a station built at the project site (you did account for the location of your supplies and goods train stations before you started building out the project, right?) just program your taxi to loop between a station at your project site and your “taxi home station.” Sure, if the project’s at a very remote site you may wait a couple of minutes for your ride, but count that against the time saved from having to hoof it on your Blade Runners (assisted by Jetpack or not) all the way back and forth. Think of the wait as a break for your tired mousing hand, if nothing else. You can turn off the auto-driving once you get “home” so the train will be waiting for you when it’s time to return to the build after you’re loaded up again.

Toot Your Horn

Months of intensely focusing on train-related stuff in Satisfactory hasn’t dulled my enthusiasm for it hardly at all. It’s more of a headache than doing it the point-to-point way, but it’s also vastly satisfying when you have trains going all over the place, making sure the machinery all gets what it needs, greasing the wheels of industry, and so forth.

I can’t wait to build even more and learn even more.

Doesn’t this look nicer than that flat criss-cross intersection anyway?

And that about wraps it up. If you have questions or ideas or what-have-you, drop me a note!