Factorio
27 оценки
Train Logistic Network Based on Interrupts
От Poldnik999
Greetings. In this guide, I will attempt to explain my train logistic system based on interrupts and request logic signals.


UPD 18.11: Fixed a bug when the unloading station was called for 1 train more than necessary and stood for a long time at a full station
UPD 19.11: Updated the liquid request station, added foolproof protection, no more trains are called to the station than the system can handle



If you enjoyed everything and found it clear, you can support the author.
   
Награда
Добавяне към любими
В любими
Премахване от любими
Introduction
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.

Base
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.


New Base
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
Trains
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
Request Stations
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.
Provider Stations
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.
Depot
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 cargo are stored in the green network, while requests for liquids are stored in the red network. Accordingly, the blueprints for radar stations differ depending on the type of trains sitting in the depot.

Sending Requests to the Depot
Filtering requests is necessary in case you decide to spread several depots of the same type throughout the factory on the planet. The filtering itself is about not allowing the same request to be sent to multiple depots simultaneously.

Radar Station:
  • The selector combinator receives a signal from the global network and randomly selects a request signal with an update interval of approximately 100.
  • The selected signal is multiplied by -1 and sent back to the global network; thus, the selector combinator still holds the selected request, but in the global network, this signal is absent or is a negative number.
  • A check is performed in case two depots' selector combinators selected the same request. In this case, there will be a negative signal in the global network, which we convert to a positive for comparison with the request signal.
  • If there is a duplicate request in the system, then no requests will be passed to the trains in the depot.
IMPORTANT: Different update interval levels must be set on the selector combinators; otherwise, all requests will be duplicates, and no signals will be sent to the depots.














Distribution of Requests Among Trains

A request to the train is submitted via a radar installation and processed through combinators between stations and traffic lights.
[Inputs:] We have a request for the delivery of 2 copper ores, meaning we need to send a maximum of two trains on their way;

  • A clean request is sent to the first depot station -> [2 ores];
  • We check the traffic light to see if there is currently a train at this station. If there is, we will send -> [2 - 1 ore = 1 ores] to the next depot station;
  • If there is no train at the next station, then we let the signal pass further. -> [1 ores];
  • In this way, the two trains will receive their request signal and leave the station regardless of their location in the depot.
  • Other trains do not receive the request signal, as it equals 0, so the extra trains remain in place.

When a train leaves the depot station, 1 request signal is subtracted from the overall network, as a train has already been assigned to fulfill it. How it is subtracted from the overall 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
Working with request signals
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.
Other
I Want to Share
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.
Blueprints
All blueprints will be at the link:



  • 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.
End
Here it is. No, not everything! Important information didn't fit in the previous section: 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.
  • Special thanks to Kotbuz for optimizing the combinators at the stations
  • The guide was translated from Russian, there may be translation inaccuracies





Beer support: Boosty[boosty.to]
2 коментара
nathin62 21 ноем. в 13:12 
great guide
LuisBoyokan 18 ноем. в 16:04 
This is awesome. Thank you for the guide