Trains unlock in Tier 5, from a Merchant Quest.

Trains are slightly slower than unburdened Hauling Sparks and slightly faster than a regular unburdened spark (and faster than either carrying items), each wagon can carry 5 stacks. Their supports take up one tile. Tracks can collide with buildings and block them, but this only happens in the lowest elevation or with particularly tall buildings. Despite massive clipping, tracks at different elevations can cross each other fine. This does not account for the transitional heights that trains cover when changing elevation.

Train Stations take up 3x5 tiles, they allow loading fuel into the cabin. Wagon loaders take up 3x3 tiles, they allow loading items into Wagons. Train stations will stop trains until their condition is met (Time/Load/Unload). The condition applies to all wagons on a Wagon Loader at the time of the train stoppage. Wagons not physically on a loader (but part of the train), do not count towards the condition. Additionally the cabin fuel does not count towards the condition either. When a train is stopped their wagons sitting on a wagon loader can be loaded and unloaded. Wagon Loaders need not be physically touching the train station, they only care if a wagon is sitting on their tile. You have to manually connect discontinuous wagon loader tiles with track. The track between loaders is pass through, so you can do some pretty interesting things by leaving intentional holes for sparks to pass through them as long as you either align things properly, or have a gap no bigger than 2 tiles through the entire station.


Trains entering a station wait at the junction previous to the last wagon loader touched by the train on a station unless the station is longer then the train. In that case they will barge into the station as the last wagon loader touched by the train will not be the last wagon loader on the station and as a result it will attempt to wait on the next wagon loader available. This can have unintended consequences on load conditions, capacity sensors, loading order and unloading order. As of the latest patch, trains can only be unloaded if their cabin is sitting at the station, making this situation a non-issue.


You can only split or join tracks at train poles. Building track into a pole that already has track going in front and behind creates a junction. You can only have one junction per pole, meaning you can only join another piece of track OR (exclusive or) split from it (the game doesn't make a difference, tracks are bidirectional), the piece of track that joins in is considered the "alternate path" that must meet the junction trigger to be taken. If you delete the main track of a junction, the "alternate path" remains the alternative, extending that piece of track will continue "the main track". If you need to join many lines into a central one, you will have a peppering of poles within 2 tiles in between each other for each join to happen. Similarly if you intend to split a lot of lines from one.

Junction conditions are partial matches. If the train has ANY ITEM on the junction ID, it will take the junction (its not an exact match it will match ANY of the junction items with ANY of its own train ID items).

You will want to have supply chests to start buiilding trains. You don't need hundreds of them, one per resource type set up in a buffer suffices (for the game in general).


More concerning is some of the resources involved. The Train Stop requires Dowsing Stones, the Locomotive and Wagon require Stone Wheels. You are going to want to automate this, and you should take the chance to automate Hauling Sparks as well. They complement trains, they very much are not replaced by them (in fact they have some unique interactions related to their ability to move entire stacks at once.

Below are the maximum efficiency setups for Stone Wheels. 2 Stone Workshops for Stone Wheels at full efficiency require 3 drills feeding them (2 for stone, 1 for sandstone) and its a particularly common configuration to find in the mountains.


I list the other train resources for completeness sake.






Dowsing Stones are the most painful there. They require a mix of Logger and Drill resources and they basically can be built with the scrap from other production chains, but you need to siphon them into a separate biome. Getting lucky with drill and logger spawns close to each other is not guaranteed and you probably want to use them for some of the sparks chains. However its not CATASTROPHICALLY bad. Scouty Sparks (which require Dowsing Stones) are a requirement for Capacity Sensors so there's some silver lining (its not anywhere close to good though) and, you can always use the overflow, or use splitters to thin out the output so the dowsing stones production is taking the bare minimum.

The only variable in a train design is its size. Trains (normally) will match their loading and unloading stations. A train with more wagons than its loader just travels with them empty. A train with more wagons than its unloader will never empty its load. How long you make stations depends on available real estate. HOWEVER, consider that for most situations, you can get away with having MORE TRAINS rather than LONGER TRAINS. Space is VERY expensive, specially later into the game, while fuel becomes increasingly cheaper. We discuss fuels on the next section. Let it inform your decision on train length, remember that design decisions tend to snowball so selecting 4 wagons today may mean you are forced into uncomfortably and unnecessarily long stations tomorrow. While a longer train might save you the fuel cost of a train (1/7th of the Wood Log output of a logger if fed with Wood Log or 1/14th of the Coal output of a logger if fed with Coal), most often the increased frequency in travel (buffer size requirements go down) as well as collateral properties that prevent unbalanced unload/loads strongly outweigh the downsides.

You will also want to start looking at coal. Coal has been MASSIVELY buffed. It is, bar nothing, the best fuel in the game by miles. Its 6 times as storage efficient as wooden logs or leaves and its nearly twice as efficient as wooden logs and leaves in terms of how many objects it allows a single logger to feed.




The logger output calculation assumes you feed the coal it makes back to the furnace (this is actually more resource efficient than feeding it wooden logs). This means that technically its fueling 15 objects, 14 + the furnace that makes it (which is how it perfectly doubles the wooden log's efficiency).

================================================================
Coal [1u / 8s] - Furnace [Coal]
--------------------------------
3/4 Logger [Wooden Log]
1/12 Furnace (Self) [Coal]
================================================================

Because of how fueling works, you either want to have a single coal furnace and doing something else with the remaining 1/4th of the output of the logger or wait for 3 trees to be available and build 4 furnaces for them. Given that fueling 56 objects already covers 10 teleporters and 46 trains, you probably won't need to make more coal, basically ever, if you have a centralized coal distribution system. At least until you need the Alchemy Lab production chain but those can (and probably should because of the volumes involved) make their own locally or have their own dedicated distribution network.

Your main concern with furnaces is going to be actually building them since they require the Terron Shell. With the introduction of the Spark Thrower, this is a non-issue. Do not be like me and manually farm 114 Rock Terrons for your Alchemy Lab setup (those small vials and big vials volumes will decimate your supply of rock terron shells). Build a Farm instead and let it run.


30 Rocky Sparks, positioned so they land to the sides and behind the Rock Terron is sufficient for minimal to no casualties. You can even use the byproducts of the Rock Terron to create more rocky sparks. Or you can use a semi-automated setup, where you have logic monitoring the supply of spare Rockies and when it dips you stop it and use a signpost so that the icon appears in your map (using logic on a sign makes it show on the minimap only when its input is True). This semi-automated setup can be executed VERY early and should be so that you don't have to fret about building furnaces later on (more time for the farm to run). Do be careful that they land around the Rock Terron spawn and to check on what orientation it spawns (it will be consistent) to ensure that you are landing your sparks behind and to the sides of him.


You do not NEED coal, but you will very likely want it desperately. You should be preparing for that from early, and while you will likely be running your trains on wooden logs for a while, its good to be ready for that inevitable transition (and also have a stock for building Furnaces for Alchemy Labs).

The obvious immediate use of trains is to simply connect two stations. An impulse you should VERY MUCH CHOOSE TO IGNORE, is to try to make it a monorail and "reuse" track on the way there to also come back. While the train can't have two cabins facing different ways, you can make a "loop" on one end that reconnects and reuses the track. Don't do this. In general, even when using Point to Point design, you should have tracks going one-way. You can use a standard (such as right hand rule, all tracks operate clockwise), or just remember what direction tracks go, but make the proper full loop with two sides for the sake of your own sanity.

Trains that are going the opposite direction of another train will simply stop. This is fine when your network is simple and you can manually disassemble the train and reassemble it later. You think you might be able to solve it with switchers and parallel avoider tracks on certain sections but you will spend 10 times the effort and time then just doing the second track for the other way round.

The upside of Point-to-Point is that you don't have to deal with junctions and train IDs. This is something you will sorely miss in other network types.

The downside is that you quickly have a lot of "redundant track" and that you can't reuse track without HEAVILY having to re-engineer things since you have to start tracking junctions that way. It very much leads to spaghetti looking train tracks, but its somewhat easy to parse where they come from and where they go.


Overall it has its uses, and even after you have other types of networks, having one of this occasionally to not deal with intersections or when you are on disconnected areas from your other networks is very convenient. Its simple, it works, its basically converts your train into a SUPER HAULING SPARK in a sense.

This is the design choice that will nearly immediately come to mind when you start trying to maximize track reuse. You build along major axis, maybe rings around the map on the biome borders, or through major traffic areas and start routing things there. Junctions quickly become an issue because the ID matching is not suited for this and you risk running out of ID objects. Its hard to tell at a glance where things go or where they came from.

Some people have proposed combining it with a full resource distribution system, where you just load goods and junctions simply indicate that a resource train should pass by that branch before returning to its central line. This is equivalent to a map-wide manifold.

While it is VERY convenient in terms of track reuse, junctions will be overloaded in places where multiple things have to join or leave. Junction IDs quickly become something you have to manually track yourself on a separate document. Train failures due to fuel or routing also can have catastrophic map-wide consequences. An unintuitive effect of the junction system is that a train cannot cross a piece of track twice on the same round trip (otherwise it will revisit the location it did the first time around), this might not seem severe but you will forget about this at some point and have a train stuck looping as a result.

Debugging this thing visually on the minimap is painful. And routing is a hassle as you continue adding trains.


There is a single colossal loop into which all resources are thrown. Areas use Ids to identify what resources they push/pull but there is no proper routing, trains stop at all entries where their relevant resource is bound. Trains have a single resource and use the id of said resource. It makes routing trivial, and ID management a breeze. It also has catastrophic scaling. The single loop has finite capacity and increasing a resource throughput means that down the line, it will compete with other resources for track space. You can't "just send more trains" because it competes with every other resource and might actually LOWER throughput because of traffic. The design scales in terms of junction management but not in terms of resource management since you are fundamentally setting a global shared throughput cap.


You zone out regions of the map and use junction IDs to identify entry to them. You can have central and perimeter lines connecting them but trains do not exit from this lines but only once on a district itself. This lets you combine some of the benefits of central lines with Point-to-Point routing. They also look very clean on the map. They alleviate SOME of the pain of junction IDs (though you still need to keep track if an internal ID is repeating between two districts). Ideally you never have trains that go to more than 2 and you could even keep inter-district trains STRICTLY separated in a pseudo-central station for each district. But this obviously has high space costs as a result.

More elements of networks than actual designs. Refueling Stations allow you to supply multiple trains with fuel without having to merge their paths additionally, the yard itself can be remote from its source of fuel, with a fuel train whose entire job is taking the fuel to the refueling station.


A capacity sensor aimed at the train station will read the fuel level and can be used to dispatch trains when they are full or above certain percentage, though the image above does not incorporate this feature instead using timers to stagger successive trains on the same line. Something to be careful with is that trains can only change fuels manually. A train on wooden logs will not take coal until it is empty (and thus immobile and blocking a train line) for instance. Thus make sure all the trains on a yard are compatible with the fuel of choice (or use both sides to ensure they ARE getting fuel, though ideally you should always aim to transition to a single fuel choice (coal).


This train line provides fuel for multiple fuel dependent buildings such as teleporters, similarly acting as a distribution mechanism for fuel.

Trains can be classified based on the content of their wagons.

A train is called homogeneous if all of its wagons have the same contents. Homogeneous trains are the ideal and what you should normally be using. One of the strongest reasons to use them is because of how loading and unloading work.


Namely that a train can unload or load whenever its stopped and its wagons are on a Wagon Loader. Notice that the train doesn't have to be on the station proper for this to be true. If the train in front leaves the station but is held up at a junction, then a train can partially enter the station without going all the way and wagons near the front will be unloaded by the Wagon Loaders near the back. If you are assuming the nth wagon has item of type N, then this will completely screw you over. Without filters or escapement/sink mechanisms DESIGNED INTO THE UNLOAD AREA, this sort of issue can rapidly just completely clog one of your production lines.


In the image above, this is nearly guaranteed to happen during loading. Trains wait on the junction previous to the last occupied Wagon Loader. That junction is VERY close to the station, furthermore the station immediately leads to a junction shared with another station. This basically begs Stones to be loaded into carriages expecting Stone Spikes. If the receiver expects Stone Spikes on the first carriage and does not have the allowance to have Stones circulating on that side of the production line, it'd be a catastrophic issue that would be hard to debug unless you knew ahead of time of this sort of risk.

Edit: As of the Hot and Cold Update. This is no longer the case. Trains can only be unloaded or loaded when they are stopped at a station proper, and only the train that is on the station will be operated on. This means that heterogeneous trains with fixed carriage types are now significantly easier to handle (and while there's still administrative risks in terms of guaranteeing wagon purity) and their advantages can now be reaped without having to set up fully heterogeneous receivers to handle slippage.

[Hm] entirely avoid this, all of their contents are the same item. Loading them out of order only has implications if you make assumptions on your capacity sensors.

A Carriage Heterogeneous Train is the catastrophic case described before. It has the same type of item within a carriage but can have different items on each carriage. This is one of the most dangerous types of train. When receiving them you should instead treat them as fully heterogeneous, because of the before mentioned VERY HIGH RISKS of cross-carriage contamination.

One of the even bigger issues is when, during contamination, an incomplete stack is placed in an earlier wagon. The result is that said wagon can NEVER be filled because the items of its kind are not part of its loading lane.


Even if the receiver is ready to take them, the sender might never emit them because of said contamination, which is something you will have to accommodate with logic or by keeping the vicinity of the station clear of other trains (such as having it on a sufficiently long line where its the only train). In general they might seem like a good idea but generally lead to lots of issues down the line to the point multiple homogeneous trains on different stations or treating it as a fully heterogeneous train are just less risky. They basically require hauling sparks while loading to ensure that even in the case of cross-contamination loading is not completely halted (or logic abuse to set time limits), as well as great care on the receiver to be able to deal with contamination cases.

A fully Heterogeneous Train can have any assortment of stacks within its carriages. Keep in mind that this train type fundamentally REQUIRES Hauling sparks to avoid catastrophe or VERY VERY heavy use of logic and controls. The reason is that the before mentioned problem of incomplete stacks. If all slots except one are filled, the loading sparks can all fill up with other items and be unable to ever supply the missing items to the incomplete spark. Time limits alleviate this but it still not a desirable situation.


An example of a heterogeneous train loading station. Notice the stack size filters that ensure that only full stacks are allowed to flow into the loading bays.

Receiving heterogeneous train requires filtering as well as escapements/sinks to avoid deadlocks similar to the issues that arise when implementing a spark central bus since multiple items share carriers and path.


There is a hierarchy of admissibility within the train classes. A station designed for Heterogeneous Trains [Ht] can accept any type of train, namely [CHt] and [Hm]. A station designed for [CHt] can accept [Hm] trains (as long as their contents are the same as the one it expects, meaning it has to be shorter than the [CHt]. For example a station expecting a CHt with 2 coal wagons and 2 stumpie wagons can instead receive a [Hm] with only 2 coal wagons or 2 empty wagons followed by 2 stumpie wagons. It should be clear that the [CHt] border on aberrant with their lack of flexibility despite being a weaker class than [Hm] (any [Hm] is TECHNICALLY a [CHt] where all of the carriages have the same contents, we always refer to the strongest class a train have when giving them a type). A station expecting [Hm] cannot receive other types of trains without careful sink construction or filtering for its expected resource type (which would make them [Ht] compatible at that point).

When possible [Hm] should be the design of choice used when dispatching and [Ht] the assumption when receiving. This ensures that even in case of mishaps from mis-routing, or catastrophic edge cases on loading production lines are not affected. However this has space considerations. [Ht] admitting stations require more space (filtering and sinks have to be implemented), and they have buffer considerations.


Observe that the top left station can receive up to 25 stacks (5 per wagon, 5 wagons), however there's only 16 stacks of buffer before the cannons. Trains of full size arriving can potentially overflow the buffer because of the cannon firing speed if the loaders are too quick. This means items that are viable will be sent to the sink. In this particular case the trains for valuable items are all 3 wagons long, ensuring that the buffer can always receive it unless the entire downstream is already overflowed as well. The one item that DOES arrive with 25 stacks is being overproduced so it is not a problem for it to be sent to the sink from cannon overload. However this are the sort of mental calculations that have to be constantly present when designing [Ht] receivers due to the necessity of sinks to avoid deadlocks.

Just like how trains can be classified based on the content of their wagons, stations can be classified based on the uniformity of the trains they expect. This can in turn be classified based on the size of the trains they expect as well as the content of the trains they expect.

A static station expects trains of any length. For [Hm] and [Ht] trains this doesn't normally require special considerations. [CHt] trains however make assumptions on size that can be destructive. You ideally match the platform size to the train size. If there's a mismatch, while optimization says the platform should be longer, look at the next section to understand why that has some dangerous pitfalls that require covering, because of the NaN problem.

While you can standardize size map-wide, in most cases you will try to build the longest station space allows on the sender, and the receiver simply conforms to that. The converse would be pointless.


Dynamic Stations make no assumption on size. There are several dangerous cases one must be able to handle. If you are employing logic and capacity sensors you risk running into the NaN Problem. This is detailed in the next section. The other issue is that trains wait on the next available junction when a station ahead is occupied. They select the next available junction based on the last occupied Wagon Loader. Wagon Loaders count as junctions. If a station is longer than the train its servicing then the train behind it will immediately barge in and sit parked halfway through (and as a result also be subjected to sensors, the station condition of load/unload works fine and only detects the front train). As illustrated below, the train will barge in and be loaded halfway through. This is fine for [Hm] and [Ht] trains but catastrophic for [CHt]. Keep in mind that the note on [Ht] Loading still applies, namely that there's a risk of partial stack filling. Therefore Dynamic stations also must account for this in the [Ht] case, even if they otherwise would have good front and back clearance.


Simply put, when there's no wagon on a Wagon Loader that's being capacity sensed, the sensor will simply not produce a signal. This is an issue both for loading and unloading.
The image above illustrates the problem for an unloader. Despite all of the carriages being fully unloaded, the sensors for the wagon loaders without wagons will never light up. There's two approaches, one is explicit NaN detection. Using a capacity sensor for the inverse of the condition and the sensor for the condition in tandem, if both are false then it means that its a NaN. For example if our goal condition C is (<= 0%), and its inverse condition ~C is (>=1) then we would need to make a system (C || ~(C or ~C)) for each sensor pair. This takes up considerable space, and is instead better served by using De Morgan's law to check on the inverse of our condition.


Here we simply OR all of the outputs of capacity sensors set to ~C and then negate the result of that. This is equivalent to an AND of the original conditions C, with the caveat that it also works for the NaN case (since we are now treating the NaN as if it was "True by default").

Stations classified by the type of train they expect can be denoted by hyphenating the station class with the train class they expect. For example a Heterogeneous Station with Homogeneous Trains would be a [HmS-Ht]. In general a Station-Train Type's design is set by the weaker of the two (the less restrictive one), therefore a [HmS-Ht] is conceptually almost identical to a [HtS-Ht]. In further sections, a station design will simply specify the strongest of the two as its class for simplicity sake. While there's cases utilizing logic where there MIGHT be design differences, at the time I have yet to see counterexamples.

A homogeneous station expects the same train on every arrival. A [HmS] expecting a [Hm] ([HmS-Hm]) is the most restrictive kind of station and makes VERY strong assumptions, it is not expected such design to have much, if any tolerance for failure. A [HmS-Ht] in contrast is almost identical to a [HtS-Ht] as outlined before.

A [HmS-Hm]:

A [HmS-CHt]:

A [HmS-Ht]:

A heterogeneous station expects different trains on every arrival. A [HtS] expecting [Hm]s means that while there might be several different resources arriving, within each train the resource is singular. Using logic it's possible to use this information to forgo certain design constraints that an [HtS] would otherwise have, such as being able to forego spark filters and instead route contents according to current stock of a resource, and so on. However this cases (and their need) have yet to surface on the fora or on my play experience. A [HtS] expecting [HtS] needs consideration for sinks to avoid deadlock, counterbalanced by buffer depth on the different inputs to avoid waste due to over-unloading or production imbalances.

A [HtS-Hm]:
A [HtS-Ht]:

Broadly speaking there's two load/unload patterns. Same as when feeding machines, Manifold and Splitter. Splitter takes significantly more space and in the case of trains outside of [CHt] its unnecessary as which wagons are filled first is irrelevant.

A manifold can be filled on a per wagon basis (fastest) or a whole train basis (most stable). This applies both to loading and unloading.

Per wagon loading is generally the fastest as it has the least travel time between the container the spark draws from and the train carriage. This setup risks unbalanced consumption. If a train is set to the unload condition, there's the risk that a single wagon holds up the train departing. On a single train setup this can be catastrophic, if multiple trains service the same resource and we are at a [Hm] situation we can simply dispatch the train whenever there's a new arrivals using a pressure plate to identify a train arriving behind or using a pole (pole's unlike junctions, signal when a train matches their ID, a pole without ID items will signal whenever any train passes over it).


Our non-contiguous unloader system actually loops at the top end to feed the other side. There are 3 trains. That means an unbalanced supply consumption will be forcefully dislodged. As its noticeable in the image this setup also has unbalanced sides. while the left is saturated, the right is nearly depleted except the first carriage which is holding the whole train back. When the next shipment arrives, the left train will be dislodged, and it will dislodge the right train in turn.


An alternative is to add a circulator system. The last loader unit first tries to load the train carriage, but if it fails to do so, it sends it all the way to the first. All loaders first try to load the train and then pass it on if they can't. Keep in mind Hauling Sparks cannot drop an item on the tile it picked it up, or drop an item into two containers on the same tile (partial fulfillment). This impose some space limitations when using them both for loading and unloading. An analogous system is trivial to consider on an unloader system. A circulator system trades space for the guarantee of stability on unloading (the operation does not stop unless the train departs or ALL the buffers can no longer perform their work (empty in the case of loading, or full in the case of unloading).


Another design is combining per wagon unload into buffers bigger than a single train wagon, which is then followed up by a manifold. This combines the gains of unload speed with manifold stability at the cost of space.


Manifold can be as simple as a loop that directly faces the production building (not recommended).
As seen in this image. In this case the buffer is the train itself as this system uses multiples trains, the risk in discontinuity has been calculated to be nil, as the next train will arrive before this one is fully emptied. The system uses 3 trains and has been designed to guarantee one remains here as a buffer, one is in travel (coming or going) and one is being loaded. This sort of delicate balancing is prone to breaking and is therefore not recommended. It also requires careful calibration. Having inactive buffers induces inefficiency and the buffer here is kept by a brittle numeric relationship not a more robust mechanism.

Or they can be more elaborate, using explicit buffering. Buffers provide safety on the continuity of operations. They allow train travel time to be less of a concern. While the buffers are active, the production chain is not affected, as they will be flushed or filled when the train arrives. For the unload case a buffer is active if it is non-empty, in the load case a buffer is active if it is non-full. If buffers are going inactive, either the buffer size has to be increased or the train length or frequency has to be increased.
An active buffer is a happy buffer. This station is overserved by the available trains.

This setup requires logic, and could instead simply be two stations in parallel, one for loading and one for unloading. It serves as a showcase of what one can do with logic. Additionally logic is much more plastic to placement than train stations, as a result there are few (but not none) situations where this sort of design is applicable. In red are the SR Latches, green is for OR, lilac for AND, cyan for NOT, white is poles and orange is capacity sensors.



The system uses two poles to determine if the incoming train should be loaded or unloaded. If the train should be loaded it will only leave when its full and only loaders will be dispatched. On the converse if the train should be unloaded only unloaders will be dispatched and it will only leave when empty.

A pole after the station is used to remove the loaders and unloaders from the active area. An additional train station is required (only the station) to prevent trains from tripping the poles during an unload process.

This design can be improved, it should be possible to forgo this additional station by storing the input of this poles when there's already a train present, and only using it once the current train leaves (and remembering that there's still a train in waiting when it crosses the exit pole).

Additionally the release of the loader-unloaders should be filtered (delayed) so that they only come out when the train is fully parked to avoid out-of-order fulfilment (5 sparks or more can induce a race condition where they empty the monitored carriage before the others). Similarly the GO signal to the station behind should be delayed as well to ensure the loader/unloaders can fully return to their storage before the next train arrives.

The converse of this system is a sequential system which first unloads the contents of the train and then loads new contents into it. The system is built on the same principles. Similarly it fills a small niche where the space available nearby is very limited but there is a location nearby where the logic system can be dropped and then connected to the station infraestructure.


Similarly it can be improved using filters (delays) to ensure the area is clear before the next train comes in and that no unloader or loader is allowed to be in the active area before the train has stopped (this fit just before the GO station on the leftmost side and after the ANDs but before the NOT that feed the one way traps for the Hauling Sparks.

Longer trains and more trains both respond to the same situation (buffers becoming inactive). However they have different costs and tradeoff. Longer trains has heavy space demands. On the converse more trains has more fuel requirements. However as analyzed before, fuel is cheap (one tree can feed 14 trains). While there's an efficiency situation of the train station fixed cost in space vs the variable wagon loader count, in practice trains of size 3 and 4 are almost always ideal. While the inner Isambard Kingdom Brunel in all of us demands that we build Snowpiercers, in practice longer trains can be replaced by multiple of smaller trains. Smaller trains are more stable on unload and load, they provide a more consistent stream of input and act as mobile buffers as well as escape mechanisms for unbalanced setups.

This is covered in Train Station Patterns. This problem is particularly insidious if you have [D] stations and are using capacity sensors. Its very hard to identify and some solutions are FAR more optimal than others (and the obvious one is not optimal).

Central Line design tends towards Junction IDs becoming scarce. Because routing is done manually by hand this design style has a heavy cost on human memory. You need to remember what IDs are taken and which ones can be reused on separate sections of the same line. There's no real way around this fully. A hierarchy based on using items to identify access to areas can help but its not a full fix either as an area that comes into contact with another basically restrict each other choice of sub-items to identify the exact facility within an area.

Trains can run out of fuel if they do not spend sufficient time on their refueling points. This might be due to loading being significantly faster than the refueling. Alternatively, the train might have missed junctions and has misrouted. Additionally if the refueling is of an incompatible type the train will not take the new fuel type. Its possible to check train fuel type on the minimap. Fuel type transitions are easier with a Refueling Station setup as all stations can be deactivated (click on it on kbm or press the use button on controller) so that trains are stuck on them. Manually remove the old fuel source and replace it with the new one. Alternatively, a capacity sensor on the refueling station will eventually catch trains that can never leave since they cannot be refueled with the new fuel type.

A production chain that feeds a train should never backup to the point the buildings go inoperative. Conversely, a chain fed by a train should never empty its intermediate storage between the train and the production buildings. If the ratios are properly matched this situations reflect insufficient buffering. Either the buffers have to be expanded, more trains should service the connection, or the train servicing the connection must be bigger and thus have larger capacity. Take note that larger and more frequent trains induce buffer expansions on the receiver regardless.

[D] and [CHt] Loading are susceptible to partially incomplete stacks due to train to station misalignment. [Ht] are susceptible to partially incomplete stacks at all points in time. This last case requires Hauling sparks and amount filters. The first case for the [D] station requires having a stopper station to stop other trains from arriving while a train is being serviced, and for [CHt] either caution on station and pole placement or guarantees using a stopper station are necessary.

When unloading [Ht] there's a risk that all of the unloaders become occupied with an item of a type that is oversaturated on the system. The machines however are lacking an alternate item. As a result they will never be able to unload the train because they cannot rid themselves of the item that there is already too much of. This is why sinks are discussed. When using a manifold with filters for [Ht] its important to have the last check be attempting to dump the item to a sink to ensure that oversaturation of one item does not deadlock the entire system. This has to be balanced against the buffering depth before oversaturation.

When unloading or loading, if loaders do not have a circulator or a whole train manifold, there's a risk that carriages completely saturated (are filled or emptied) while others take VERY long, massively delaying the train and impacting efficiency. Solution to this problem are covered in the section on Loading and Unloading.

While tempting in Point-to-Point designs, avoid using the same segment of rail in two directions. Not only does it not scale (you cannot run multiple trains on the same line), but it means that anything that might want to use that stretch of road very much can't. Its very tempting early on, but its one of the first things you will run against not much later as your train operations scale up. This situation is briefly mentioned on the discussion of Train Networks.