Let's start with the components of our network:

• Loading stations
  
• Unloading stations
  
• Solid cargo depot
  
• Liquid cargo depot
  
• N number of trains

This guide will provide an overview of creating a vanilla train network, similar to the LTN mod.

Basic LTN Logic:

We have trains that are stationed in the depot, waiting for their turn. Upon receiving a request, the necessary number of trains depart according to a dynamically assembled schedule: loading -> unloading -> depot.

---

Interrupts
Thanks to the new interrupt system, the developers have given us the ability to create train schedules dynamically by configuring certain rules for train activation. This makes our trains versatile, and we no longer need to set each train for a specific type of resource.

---

All stations and depots exchange signals with each other for the proper functioning of the network using radars. If you don't want to run power lines with logic wires all over the factory

We have two logistics networks for trains:

• Trains with solid cargo
  
• Trains with liquid cargo

This is a vanilla game, not LTN, so trains do not know what type of cargo they are carrying or their length. Additionally, the depots are not designed to differentiate based on train length and cargo type.

Therefore, we need at least two depots for different types of cargo, with trains of the same length.

Below are the interruption settings for the train:

Conditions for interruption:

• The train must be standing in the depot to receive a request.
  
• A signal with a request must come to the station where the train is located (DEPOT).
  
• The train must be empty; otherwise, it will not depart.
  
• The requested loading station must be able to accept the train.
  
• The requested unloading station must be able to accept the train.

If all conditions are met, a temporary schedule is assigned to the train, and it departs for the requested stations.

For reference:
This signal is called the "Signal Parameter" and accepts a value that the player can send to the station externally (e.g., from a combinator).

For us, it creates the name of the requested station in the train's schedule.

You can read more about signals and interruptions in other guides. Like that: https://youtu.be/cimm7VK_4fA
Or if u know Russian language: https://gtm.steamproxy.vip/sharedfiles/filedetails/?id=3362592267
If you know other good sources, please post them in the comments

The Unloading Station generates a request signal based on the capacity of the chests or the train limit. It also reduces the request signal if a train is heading to the station. The purpose of this can be read in the section working with request signals.



By default, this design has 6 steel chests, and the station can call a maximum of 7 trains. However, if we limit the train limit, the station will send a request based on this limit.

This station is parameterizable for any train length and number of steel chests.

The Loading Station reduces the request signal when a train is approaching it. You can read about why this was implemented in the section working with request signals.



By default, this blueprint includes 6 steel chests, but the train limit here is influenced by the fill level of the chests, not their quantity. So feel free to add as many as you want, just connect them with wires.
The train limit is set based on the amount of cargo in the chests and the user-defined limit.

This station is universal for trains of any length. The blueprint is parameterized.

In the depot, as you already know, trains are waiting for requests to come in. Each depot is assigned one radar station that processes and filters requests. An important clarification: requests for solid goods are stored in the green network, while requests for liquids are stored in the red. Accordingly, the designs of the radar stations differ depending on which trains are sitting in the depot.

Request filtering is necessary in case you decide to scatter several depots of the same type throughout the factory on the planet. The filtering itself involves distributing requests among radar stations and prohibiting the same request from being sent to multiple depots simultaneously.

• For each radar, we send 1 signal "D" so that the system understands how many depots are scattered across the factory.
  
• Signals from the common network are divided by the number of depots and sent to the trains via a selector combinator.
  
• Next, we calculate the remainder of the division by the number of depots and simultaneously:
  
  • Send this signal to the trains via the selector combinator.
    
  • Prohibit the use of the remainder from being sent to other depots.

Example:

• Two depots in the factory and a request signal for the delivery of 3 copper ore.
  
• According to the scheme, we divide 3 copper ore by 2 depots and receive 1 signal of copper ore for each depot in the system.
  
• We need to somehow distribute the remaining 1 copper ore signal between the depots. For this case, we use the remainder from the division, which will randomly go to one depot and not be duplicated.

IMPORTANT The lower left selector combinator must have a different update interval level to avoid operational errors.

---

Example of request distribution between two depots:

IMPORTANT The request will not be evenly distributed if the signal level is less than the number of depots. Instead, it simply will not be duplicated. An example of this on the screenshot would be the request for coal.

---

The request to the trains is sent through the radar station and processed via combinators and a signal light between the stations.

Principle of signal distribution among trains in the depot:

• An arithmetic combinator subtracts one from the request signal if a train is present at the station.
  
• The signal from the arithmetic combinator goes to the selector and comparator combinators.
  
• The selector combinator acts as a timer, ensuring that all trains in the depot do not take extra requests. This prevents errors if more trains are dispatched than required.
  
• The comparator combinator allows for faster updating of the request signal, as the selector combinator removes the output signal with a delay. The output from the comparator combinator goes to the station with the train.

Example: If we have a request for the delivery of 2 copper ore, we need to send a maximum of two trains on their way;

• A clean request is sent to the first depot station -> 2 ore;
  
• We check with the signal light if there is a train at this station; if there is, we send to the next depot station -> 2 - 1 ore = 1 ore;
  
• If there is no train at the next station, we pass the signal further -> 1 ore;
  
• Thus, two trains will receive their request signal and leave the station regardless of their location in the depot.
  
• The next trains do not receive the request signal as it equals 0, so any extra trains remain stationary.

When a train leaves the depot station, 1 request signal is subtracted from the common network, as a train has already been assigned to fulfill it. How it is subtracted from the common network will be explained later.

---

In my version, trains are also refueled at the depot. If you have a separate refueling station, please refer to the interruption guidelines. https://youtu.be/cimm7VK_4fA
If u know Russian: https://gtm.steamproxy.vip/sharedfiles/filedetails/?id=3353212873

The request signal level indicates how many trains are needed to fulfill it. It changes as follows:
At the loading and unloading stations, we set up a configuration that reads the number of trains heading to the station.
Also, at each station, there is an arithmetic combinator that multiplies signal C by -1 and sends the resource of our request with a negative sign at the output.
The output signal of the arithmetic combinator is sent to the network so that our request signal decreases by the number of trains that are fulfilling this request.

---

Or simply put, when a train goes to fulfill a request, it will hold onto its request signal until it leaves the unloading station.

In conjunction with signal processing at the depot, this eliminates the problem where 2 or more trains could arrive at the loading station for 1 request.

I want to share my developments. I use trains with 4 freight cargo, and sometimes I encounter problems at loading and unloading stations, which cannot always load or unload the train evenly. As a result, trains may stand at the station for a long time doing nothing. You can connect logic to the inserters and control even unloading/loading, but I don't like that because I'm not sure about the positive impact on performance with this method. (Correct me if I'm wrong)

Here’s my solution to the imagined problem: Loading and Unloading Station



Here, there are 4 segments with 12 chests each.

• At the loading station, I calculate the minimally filled segment of chests, and I only allow the train to depart when all 4 segments have resources for at least 1 train.
  
• At the unloading station, I calculate the maximally filled segment of chests, and I only allow the train to depart when all 4 segments have space to unload at least 1 train.

All blueprints will be at the link:

• https://factorioprints.com/view/-OBtba7-FLZ6oEj4WgcT

---

• I have custom parameterized stations for dry and liquid cargo and separate stations for different train lengths with item counts by segments.
  
• Blueprints of trains, depots and radar installations for different types of cargo.

Here it is. No, not everything! Important information: all combinators in the blueprints are labeled, and if you have trouble understanding them, refer to the descriptions of the combinators.
NOW IT'S THE END. This was my first guide, so if something is unclear or the blueprints are not working correctly, please write in the comments, and I will do my best to help.

Thank you to the guys who helped with bug hunting and improving the blueprints:

• Kotbuz
  
• M1A1
  
• Reaper
  
• Maelstrom

---

The guide was translated from Russian, there may be translation inaccuracies

---

Beer support: Boosty[boosty.to]