LTN - Logistic Train Network

Factorio mod adding "logistic-train-stops" acting as anchor points for building a train-powered logistic network.

It can handle multiple train configurations and will pick the best available train for a delivery.

FAQs

I get error messages: "No station supplying ... found in networks 0x0"

LTN uses "Network Id" to allow creating multiple networks that can act separately. A lot of examples assume that there is only one network ("the LTN network"). When using only a single network, all stations have the same network id. The network id is provided either through a signal sent into the Station Lamp OR as a default setting in LTN. Many "getting started" examples assume that the stations get their station id from that default setting.

Up until 2.2.0, the default network id was "-1" (which actually translates to "all LTN networks"). This is fine, as long as there is only one network.

For more elaborate setups with multiple networks, this default value caused a problem: Any station that is built and that does not get an explicit network signal (e.g. through an LTN Combinator) will show up in "all LTN networks". This especially happens when the LTN combinator is fully configured but then turned off. So trains from all the networks will show up at the station because there was a signal missing. This was hard to reason about and hard to debug.

For that reason, the "default network id" was changed in release 2.2.0 from "-1" to "0". This means that a newly built LTN train stop will not be part of any network unless there is an explicit network id signal sent into the station. OR the default network id is set by the player.

If you run a relatively simple setup (only a single LTN network) and do not have your stations provide an explicit network id, you will encounter the No station supplying ... found in networks 0x0 error message. In that case, go to Settings -> Mod Settings -> Map -> LTN - Logistic Train Network -> "Default network ID" and change the default value from "0" to e.g. "1". You can also use the old default ("-1").

If all your stations have an explicit network id provided (e.g. through LTN Combinators), the default of "0" is correct and will avoid that new stations mess up your train schedule.

I get error messages: "No train to transport from ... to ... in networks ..."

If trains with the right length are available, and they are in the right network, then it is possible that the provider is not accessible from the depot. LTN checks whether it can send a train from the depot to the provider by asking the game to resolve the path. If no path exists, it drops the train.

Starting with 2.8.2, if multiple providers exist, LTN will retry with another provider. However, this still means that it is possible that you have a provider that is never accessed by a train. If this message persists and LTN consistently chooses another provider (especially if it is further away than the "best" provider, has the wrong priority or fewer items), check whether there is a rail signal on the wrong side of the track or a break in the track that leading to the provider. Turn on GPS tags in the settings to quickly navigate to the provider.

I have a personal train that is not supposed to be managed by LTN and it keeps resetting the train schedule every time I send the train to an LTN stop

Note that this only ever happens in two cases:

you sent your train to an LTN depot stop at some point
you hit a bug in LTN 3.4.0 or LTN 3.4.1 by sending the train to any LTN stop. This is fixed in 3.4.2

If you never sent your personal train to an LTN depot and if you run LTN 3.4.2 or later, LTN will not mess with your train's schedule.

LTN keeps track of all "known" trains and checks the delivery schedule whenever a train arrives at an LTN station (depot, provider, requester, fuel-station). If you send your personal train to a depot stop, then LTN assumes you want it to take over managing the train and registers it as "known".

If the train is "known" to LTN and you take over manual control again and send it to any LTN station (provider or requester), LTN will check whether the train is "known" and a delivery exists for it. If LTN can't find a delivery, it assumes that the train had a delivery, and it got somehow lost (timed out, was cancelled etc.), so the train is now running on a schedule for a delivery that no longer exists. In that case, LTN tries to send the train back to a depot without following the route by resetting the schedule.

This can be solved by telling LTN to "forget" that train. Find the train id (if you hover over the train, it is shown in the info box on the right). Then run the console command /ltn-forget-train <the train id>. This removes the train from LTN and it will then no longer touch the train schedule. This is a permanent fix that will last until you send your train to an LTN Depot again.

What is 'Advanced Cross-Surface Delivery'?

If you are not using an expansion that allows trains to travel between surfaces (planets, moons, orbital, etc.) such as Space Exploration and the LTN - Space Exploration mod, this setting is not for you and you should leave it off.

This setting is for games where the train network stretches across multiple surfaces that are connected. This is not true if you e.g. use the same network id on two planets (e.g. Gleba and Nauvis) that are not connected.

If you have a network across multiple surfaces, then normally a train can be dispatched to a provider on the same surface as the depot, go through the space elevator into orbit and deliver to a requester on a different surface, then return back to the depot on the original surface. LTN will not schedule anything else, the provider must be on the same surface as the depot.

With this setting, LTN will schedule trains to go through the space elevator first if necessary to pick up a delivery from a different surface. It may even schedule a delivery where both provider and requester are on a different surface as the depot. The train will still return to its original depot.

I have a really large base with multiple networks, and I see lag-spikes when LTN chooses a train for delivery

Managing performance for LTN boils down to a single thing: Managing the cache that holds the precomputed routes between depot stops and providers. The better the cache hit rate is, the fewer actual route computations LTN has to do. This is a consequence of the 2.x introduction of LuaTrainManager. There are a few settings that are most relevant here:

Dispatcher Updates per tick controls how many trains are scheduled per tick. Each train requires some work, so updating many trains per tick will lead to lags. For a larger base, leave at 1.
Dispatcher Route cache lifetime in minutes controls how long a route is cached. If your network is fairly static (not a lot of changes to the rails), you can crank this up to the maximum (120 minutes). If your network is under construction (adding new routes, removing existing routes, etc.), reduce it (the minimum is 2 minutes). The longer a route is cached, the fewer actual route lookups need to be done.
Limit eligible trains controls how many trains are evaluated to cover a route. This limits the size of the group of trains that can serve a route. Choosing from a subset may lead to slightly suboptimal choices, but in any case, if there is at least one eligible train, it will be chosen. For a large network, limit this to 5-10 trains.

LTN - Space Exploration fully supports this.

If you are using Space Exploration LTN integration, you need to verify that it was updated to support advanced scheduling, otherwise your trains will stall with "No path found".

Train Schedule Interrupts (since 2.3.0)

Factorio 2.x trains support "Train Schedule Interrupts" which trigger under certain conditions. Starting with 2.3.0, LTN will not change any interrupts in the train schedule unless explicitly configured with the ltn-schedule-reset-interrupts setting.

Refueling support (since 2.3.0)

Starting with 2.3.0, LTN supports a new station type: 'Fuel Station'. Fuel station support must be explicitly enabled by setting the ltn-schedule-fuel-station setting.

There is a long section in the MANUAL.md that describes how refueling works.

In a nutshell:

use only a single fuel type for a network
have all fuel stations for that network only serve that fuel
have all fuel stations use the same signals, do not use different fuel signals
make the fuel stations "clean up" the train fuel inventories. Remove all fuel that does not match the "single fuel type" for the network

Depot changing (since 2.3.0)

A train added to the LTN network will return to a depot when it finishes a delivery. If the 'ltn-schedule-reselect-depot' option is disabled, a train will always return to the depot it was assigned to (the depot that it was sent to when it registered with the LTN network).

If this setting turned on and also 'ltn-dispatcher-requester-delivery-reset' is enabled, then LTN will, as soon as the train leaves the requester, select one of the depots that accepts trains in the current network at random. Trains may go to a different depot in that case. This is especially important if a depot serves multiple networks. A train that gets sent to a depot that serves multiple networks becomes eligible to requests in those networks (assuming that capacity, length, etc. also match).

This setting has the potential to pile up trains in depots that are too small to accommodate all trains that are sent there. Use with caution.

Controlling LTN Stops with the circuit network (or logistics network)

LTN stops are managed by the central dispatcher and require some settings that will be enforced. Each LTN stop will always have "Read train contents" and "Send to train" activated, even if no circuit network is connected.

The 'Priority' 'Enable/Disable', 'Read stopped train', 'Read train count' and 'Set priority' fields can be manually changed.

Depot stop train limits [Since 2.7.0]

LTN manages train limits for all stops automatically. For normal operations, it will remove any train limit (and disable setting through the circuit network) as this interferes with the dispatcher. For most stop types (requester, provider and fuel station), this cannot be changed.

The train limit for depot stops can be modified by changing the startup option 'ltn-depot-stop-limit-trains'. There are three possible values:

Reset Train Limit: This is the default. Depot stops behave like all other station types: Any limit is reset and cannot be modified
Set Train Limit to 1: Sets a limit of one train for each depot stop.
Do not modify Train limit: LTN stops managing the train limit setting for depot stops, it needs to be set manually.

Support locomotive types that do not need refueling

Some mods add locomotive types that do not need refueling. LTN now supports excluding such locomotives from refueling by exposing a remote API that is compatible to Automatic Train Refueler or Automatic Train Fuel Stop.

By default, the mod automatically ignores electric locomotives named 'et-electric-locomotive-1', 'et-electric-locomotive-2' and 'et-electric-locomotive-3' which are provided by various mods that add electric trains.

API

LTN Settings Documentation
LTN Console Documentation
LTN API Documentation
LTN additional Documentation

Starting with version 2.1.0, LTN supports quality for requester and provider signals. To support this, there are a few minimal, backwards compatible API changes. If you maintain a mod that uses the LTN remote API, the changes are documented LTN API Documentation

Contact

How you can help

If you maintain an LTN mod and stopped working on it, consider porting it to 2.x!

Legal

The 2.x port is maintained with permission by @hgschmie