Factorio Forums

TL;DR

Even after all the improvements and tweaks, the train system continues to bring a high dose of frustration to everyone I’ve seen, read, or heard from lately. From my perspective, it’s a system without feedback, and such a system will never function properly.

What?

Factorio is a brilliant game, especially for technically minded people. Optimization, searching for new solutions, solving problems, and above all creating automated systems with fine-tuned error handling—or at least minimizing them.

Many approaches are excellent, and in version 2.0 they’ve been perfected. Of course, there’s always more to work on. However, I’d like to emphasize here that the generally defined train system is not designed correctly. Additional tweaks you make still won’t fix the main issue, which is the lack of system feedback. Such a system might seem like it works, but it will always be very fragile and eventually fall apart.

For literally several weeks now, I’ve been going through the solutions of various people and approaches, and they all essentially end in failure. It may look fine at first glance, even at second, but if you try using it for at least a week, you’ll discover it crumbles like a house of cards. Here are just a few examples of different enthusiastic approaches that end up failing due to the very same issue mentioned:

Frustration 1

* https://youtu.be/M3i-Ba3Wxvk?si=OvLSKr5tkRZ8ZH9p (enthusiasm)
* https://youtu.be/WL9pMEY-3IA?si=mnVXN7Id9RUVN-3H (frustration)

Frustration 2

* https://steamcommunity.com/sharedfiles/ ... eview=true

10 Books Full of Rails v2.21.2 (Frustration 3)

* https://factorioprints.com/view/-MFIYLSH60wmZ-pNvcL_
* https://github.com/Opinionated-Blueprin ... ils/issues (frustration 3)

At first glance it looks good, and even at second glance as well, but try using it for at least a week and you’ll see it fall apart...

Why?

Why? Because the fundamental design is simply wrong. Why does the LTN mod system work while the vanilla system falls apart? How do you handle feedback in the system? You need to do a deeper analysis of the problem. The only thing I can say so far is that trains simply end up with the wrong cargo in the wrong place, or all of a sudden decide to go somewhere else entirely. I could go on and on.

The core problem is that the system lacks system feedback to verify that when something is being controlled, it’s actually doing what it’s supposed to. In other words, you can determine whether the state of the system is where it’s expected to be, and measure that it is indeed there. So far, I haven’t seen anywhere that this is allowed or significantly simplified for players.

One way to handle this is to ensure trains “know” what cargo they are carrying, which is measurable. The relevant circuits could then evaluate whether the control is actually happening correctly. Interrupts are nice, but without this, the entire system is pointless.

I can’t give you a simple solution. I’m just pointing out where the error is and what’s wrong. It might mean coming up with some new circuit or its parameters. God, but don’t make it too complicated, otherwise people won’t understand it and won’t want to use it. I’ve seen a million times that no one understands the circuits, but then they want to use trains and end up with some half-baked solution. This is far from perfect or efficient.

It has to be simple and clear.

With the caveat that I havnt looked at the videos, you say 'system feedback' is missing, you evidently have issues getting it to do what you want? Could you expand a bit on what you think is missing, or what it is you are trying to do but having issues with and maybe what approaches have been tried? A TLDR on this would help.

I ask because in general I dont really have any issues with trains. That said, I do use circuit to controls them (dynamic limits and dynamic priorities). I have tried LTN back in the Factorio 1.0 days and ditched it mainly because taming it at the time seemed to me to need alot of circuits and I seemed to often end up with corrupted trains full of random mix of stuff. Probably my fault. Then Factorio 1.1 came along with dynamic limits and I made a mod to do basically what people are doing today with depots and interrupts and the core of what many did with LTN, so with factorio 2.0, all I had to do was ditch my mod, and keep the circuits I was already using and switch over to using interrupts for the 99% use case. There are special cases of mixed good where I need to do something a bit more fancy, but basically it seems OK if you don't mind using circuits to gain some more precise control.

I think LTN is just wrong thing to do with how trains designed in game. They are very good at being one thing they have been in 1.1: a chest on rails that travels from point A to point B. With more updates it just becomes more easy to multiplex that one "chest" to go (or not to go) multiple places.

There is frustration if a player tries to force a setup the game doesn't support. If you employ a setup the game supports, everything will run exceptionally well.

Before building something bigger, I investigated how the game handles trains and what approaches work well and what approaches don't. I didn't just thought: "I'm going to make THIS train system", then tried to build that and tried to force the game to run it. Instead I tried several approaches, monitored how they behave, and what problems arise with each of them. Tried fixes and workarounds, and evaluated the required complexity or simplicity.

Finally, I found a way that satisfied me completely. It just works. From all of my ideas, just this survived. It's both simple as well as sophisticated, because a few parameters must fit together and not arbitrarily chosen. If they fit, it just runs unattended, balanced, perfectly. It's not complex at the end and no circuits required, although with a few circuits at certain places it runs even better.

I don't know if there are alternatives that work just as well, or if what I worked out is the only efficient approach. However, there is a solution that works, so the game is not lacking a working train solution. As far as I see it afterwards, it's probably the approach the devs envisioned and using themselves.

May be the game lacks variety in train solution, but this is for the devs to decide. I also cannot decide if the game doesn't communicate the supported approaches well, and I don't know how thoroughly players will inspect the train mechanics.

So my recommendation: Investigate train mechanics better and find a working solution. If what you tried so far doesn't work, abandon it and find a different approach. Don't force it.

The essence from what I found out:
Demand driven approaches don't work. You detect some demand, then dispatch a train to satisfy this demand. A far as I understand from descriptions, LTN was such an approach (I never used LTN). The logistics network mostly work like this, but the train system not. The train system works bad, if there is more demand than supply. There are people who try to force balancing the distribution of items, because they artificially (or actually) create not more supply than there is demand, and this simply doesn't work, because the stations are too loosely coupled. To overcome this, people try to wire everything and make everything communicate, and this doesn't work in the end, or works inferior, or produces too much edge cases and errors, because it's to big and fragile and everything depending on everything.

The train system, as the game engine supports it best, is a push approach, a supply driven approach. As soon as you ensure there is always more supply than demand, everything works totally smooth, because items eventually flow everywhere after they create a backlog at the places that are supplied first. You don't need any active logic, because like water items flow everywhere without active control and management. At this point you also have your feedback: as soon as an unloading station runs empty, you have not enough supply and have to build more supply. That's a very direct and very useful feedback with a very simple solution.

raven2cz wrote: ↑Mon Jan 06, 2025 5:50 pm One way to handle this is to ensure trains “know” what cargo they are carrying, which is measurable. The relevant circuits could then evaluate whether the control is actually happening correctly. Interrupts are nice, but without this, the entire system is pointless.

I don't understand why you seem to think you can't do this with interrupts. If item count (copper ore) > 0 then go to copper ore dropoff, etc. In fact, my understanding (I haven't tried it) is that you can use variables and carefully-named stations to avoid having to create per-item schedules. This is described here:

https://www.factorio.com/blog/post/fff-395

Thank you for the initial feedback. First of all, I need to emphasize that I am not really concerned with the LTN system as such. I only wanted to highlight the LTN system because, in its own way, it solves one of the fundamental feedback issues, which I claim is not addressed in vanilla with the new interrupts! The multiplex doesn’t affect it in any way, since it obviously still has to be handled through feedback information.

I would like to pause for a moment on Tertius’s important conclusion: “Demand driven approaches don’t work.” Exactly, and that is precisely due to the lack of feedback. I would add that such an approach may appear to work, and might indeed function for several days, but then the whole thing collapses.

I don’t want to delve deeply into cybernetics system theory or the basics of logistics here, but I will present at least the necessary foundation.

**Summary of logistics principles:**

- **Push (tlačení):**
- Production and supply are based on estimates and forecasts.
- Products are “pushed” into the system without waiting for a specific demand.
- There is a risk of surpluses or shortages due to inaccurate estimates.

- **Pull (tahání):**
- Production and supply respond to current demand.
- Products are “pulled” according to actual orders.
- Requires precise coordination, minimizes redundant stock.

A push system will never be optimal and efficient, which is the approach Tertius describes. If you delve deeper into logistics, you’ll eventually see that it’s very clumsy, your resources will always feel insufficient, and you’ll deal with massive resource waste. Factorio is intended to focus heavily on efficiency and solving logistics problems, which naturally leads one later to a pull approach and, of course, the fundamental economic principle of balancing supply and demand.

The links I provided are just a small fraction of what’s out there on YouTube, forums, Discord, etc. I could list many more, but I suspect no one will study all of that for a single issue. What I mainly need here is for the game’s developers to read this issue, think about the fundamental problem they have introduced, and refine the concept of interrupts.

In Factorio 2.0, an interrupt system was introduced using three variables (exclude fuelling):

[Factorio Friday Facts #395](https://factorio.com/blog/post/fff-395)
[Factorio Wiki - Railway, “Wildcard Interrupts” chapter](https://wiki.factorio.com/Railway)

And I am plainly stating that this introduced system will always be insufficient and unsustainable in the long run, because it lacks feedback. It adds intelligence to trains without feedback on the actual contents the train is providing. At first glance, this might look solvable, but if you study cybernetics long enough, you know that measuring the state of the train (in this case, the train’s cargo—that is, content multiplexing) is the only way to ensure feedback. If the Factorio “framework” simply does not allow this, you will constantly encounter situations where the train either remains in the depot with loaded cargo and has no idea where to deliver it, or it arrives at a station with the wrong cargo, or—third scenario—it waits at or near a station and suddenly “realizes” it needs to go elsewhere, resulting in a deadlock.

There can be many systems for handling the producer–consumer relationship. I posted links to quite a few promising control systems, each different, each very sophisticated, and one is arguably the most popular in blueprint rankings. Yet all these systems eventually break down after some time for exactly the reason I am trying to describe.

Moreover, it was pointed out (even in those previous posts) that getting to a functional system is very complex, and the word “fragile” was used. It ends up like Edison trying to invent the light bulb.

That is why I appeal to the developers once again to put their heads together, understand what I am writing about, study cybernetics and the approaches people are taking, and come up with a feedback loop that is simple, multiplex, and supports the idea of Schedule Interrupts—which is correct, but only halfway there.

raven2cz wrote: ↑Tue Jan 07, 2025 8:01 am Technobabble

You don't actually make any suggestions or provide any concrete criticism. You just fluff about with jargon.

To boot, there are plenty of people running perfectly fine train systems without even touching interrupts, so it's not even clear what the goal is you're claiming them to be insufficient for.

I apologize if I have touched on your experience. However, my insights are based on the current 7 solutions I have seen and tested, which I am describing here. I stand by my conclusions; otherwise, I wouldn’t have written them here. You are also not providing specific details at all.

If you do have a solution like the one you describe as "perfectly fine train systems," I would be glad to see its blueprint so that I can evaluate it. Thank you.

I would also really prefer that no one calls this technical nonsense because it took a lot of effort to test and, especially, to write down. The issue of feedback is not a technical absurdity. The newly introduced interrupts lead to this, and I reiterate that no solution I’ve seen, tested, or modified so far avoids triggering feedback issues as described in the examples I have already provided.

The reason for introducing "train intelligence" in the form of interrupts lacks the transfer of information about the cargo the train is carrying. If there is any place where feedback information is needed, it’s the train itself, whether through the ability to read this data on existing Circuit Network circuits or by introducing new Circuit module, simplified ones specifically for train transport.

In the end, it’s simple. The added interrupts are a great tool, but they need to be refined so that it’s possible to implement proper control for handling requests correctly and removing emerging errors. That’s all. It’s a critique from my side that I see without requiring a mod to be created.

If I am mistaken and it is indeed that simple to create a stable (I emphasize stable) train system, please provide the solution here. I repeat, using interrupts, which is the main topic of this discussion. I would very much appreciate it if further discussion remains focused on this specific topic and stays relevant.

raven2cz wrote: ↑Tue Jan 07, 2025 10:33 am I apologize if I have touched on your experience. However, my insights are based on the current 7 solutions I have seen and tested, which I am describing here. I stand by my conclusions; otherwise, I wouldn’t have written them here. You are also not providing specific details at all.

Nobody can help you because nobody knows what problem you're having. You're describing it in generalities. Try concrete specifics. What exactly goes wrong with your train system? The most I've seen from everything you've typed is:

raven2cz wrote: ↑Tue Jan 07, 2025 8:01 am ...the train either remains in the depot with loaded cargo and has no idea where to deliver it, or it arrives at a station with the wrong cargo, or—third scenario—it waits at or near a station and suddenly “realizes” it needs to go elsewhere, resulting in a deadlock.

Are these your actual problems?

If you try describing exactly what cargo failed to go where it was supposed to, or exactly what wrong cargo arrived at a station, and where it was supposed to arrive, and what wrong station it was, or exactly what the deadlock looked like (screen shots would help a lot), then people could give more specific help.

@raven2cz Could you please elaborate on why exactly you see a supply driven system a "massive resource waste" and "very clumsy"? Please refer to Factorio, since it's Factorio we're dealing with. We don't deal with university concepts about logistics, because most of it isn't applicable to Factorio. For example, in Factorio starting and stopping a production line has zero cost and zero delay, while in the real world, the cost and delay can be significant.

With the reasoning you give it is certainly possible to work on some misunderstandings or even prejudices.

Without reasoning it appears as if you did what I mentioned in my 1st post: insisting and forcing a concept that actually doesn't work instead of trying alternative approaches that work.

Keep in mind there are 3 major different use cases for train transport, each of them requiring different approaches. The first one is transporting ore from far away resource patches to the smelters in one central base. The second one is transporting intermediates from somewhere in the base or vicinity to somewhere else in the base or vicinity. The third one is transporting a collection of different items in one train to provide support for building and maintaining outposts and defensive installations far away from the base.
If you speak of some failure, you need to mention with what use case it fails, because as I said all 3 use cases need more or less different approaches. The 3rd one definitely.

The OP post is not well-organized, you made a typical mistake of putting feedback/criticism but not suggesting a solution. TL;DR is supposed to be 1-2 sentences of the proposed solution, and WHAT? is meant to be longread of technical details to that proposal. Currently, all 3 chapters in your post are different kind of WHY? If there's a proposal, my apologies, but i haven't seen one.

Thus, I suggest either of two options:

• You propose a solution (or make it clear in TL;DR)
• We move this post to general discussion

P.S.
This forum uses BB-codes and not Markdown, feel free to edit your post to fix formatting.

Tertius wrote: ↑Tue Jan 07, 2025 11:15 am @raven2cz Could you please elaborate on why exactly you see a supply driven system a "massive resource waste" and "very clumsy"? Please refer to Factorio, since it's Factorio we're dealing with. We don't deal with university concepts about logistics, because most of it isn't applicable to Factorio.

With the reasoning you give it is certainly possible to work on some misunderstandings or even prejudices.

Keep in mind there are 3 major different use cases for train transport, each of them requiring different approaches. The first one is transporting ore from far away resource patches to the smelters in one central base. The second one is transporting intermediates from somewhere in the base or vicinity to somewhere else in the base or vicinity. The third one is transporting a collection of different items in one train to provide support for building and maintaining outposts and defensive installations far away from the base.
If you speak of some failure, you need to mention with what use case it fails, because as I said all 3 use cases need more or less different approaches. The 3rd one definitely.

I usually have a 4th one just because it is marginally more complex than my regular trains - nuclear power service trains - provide fuel, remove spent cells - it is usually my only mutli-product automated train with load and unload at all stops. Moving ore around and moving cargo around for my is identical. I dont really have remote ore patches as if I claim a zone I wall it up and make it part of the internal rail network grid.

P.P.S.
Examples of well-written, organised, and reasonable changes to the train system:

• 119104: Train Station reservation option by interrupts
• 117220: Additional train interrupt conditions

Tertius wrote: ↑Tue Jan 07, 2025 11:15 am @raven2cz Could you please elaborate on why exactly you see a supply driven system a "massive resource waste" and "very clumsy"? Please refer to Factorio, since it's Factorio we're dealing with. We don't deal with university concepts about logistics, because most of it isn't applicable to Factorio. For example, in Factorio starting and stopping a production line has zero cost and zero delay, while in the real world, the cost and delay can be significant....

This concerns the resolution of issues in **use case 1 and 2**. I know that the third use case is complex and requires an individual approach, so I won’t analyze it here for simplicity.

The first two cases, however, can be addressed with a similar system. While I use different train setups for these, I understand where you’re coming from.

First, let’s start more generally. For example, here’s a video I watched yesterday:
[https://youtu.be/ks9dP8YuyOY?si=ztDwMCNcDGmLXA2C](https://youtu.be/ks9dP8YuyOY?si=ztDwMCNcDGmLXA2C)

Take a look at the video and jump to the timestamp **11:17**, where the feature "20s of inactivity" is mentioned. This is exactly what caused the disaster that happened during the stream. It’s immediately obvious what will happen when you watch further in the video. And that’s just the tip of the iceberg, showing a basic interrupt approach. For far more complex systems, like **10-Books-Full-of-Rails**, these problems repeatedly occur:

[https://github.com/Opinionated-Blueprin ... issues/110](https://github.com/Opinionated-Blueprin ... issues/110)

(The second issue described there, not the first one.)

These cases use the **"Item" interrupt**.

When we consider another possibility, the use of the **"Signal" interrupt**, I have a pretty neat solution for this:

[https://steamcommunity.com/sharedfiles/ ... eview=true](https://steamcommunity.com/sharedfiles/ ... eview=true)

However, even here, simply adding a new requester eventually leads to the problem where a fully loaded train arrives at the depot. That train was originally supposed to serve another destination, and now you can’t do anything about it. You have to resolve it manually, because there’s no longer any information about what it actually contains.

Hares wrote: ↑Tue Jan 07, 2025 11:40 am This forum uses BB-codes and not Markdown, feel free to edit your post to fix formatting.

I'm going to highlight this again for raven2cz's benefit, because I think he missed it.

All of these I can safely call the "bad design" and not "lack of proper system feedback".
This is, for example, my generic train system: It's extremely robust train system that can clock up in exactly one scenario I'm aware of -- when a requester with limit=1 opens, and there's no trains with that item in depots, and provider with limit>1 is open, the max number of trains will depart to provider, then entering depot. Solvable by having more trains than providers-trains (sum of limits on providers). However, for me it works well with less than that amount: P.S.
And here's my multi-item one-route train:

P.P.S.
It's not frustration, it's normal engineering process. A design iteration, if you wish.
Trust me, I'm an engineer.

raven2cz wrote: ↑Tue Jan 07, 2025 12:00 pm First, let’s start more generally. For example, here’s a video I watched yesterday:
[https://youtu.be/ks9dP8YuyOY?si=ztDwMCNcDGmLXA2C](https://youtu.be/ks9dP8YuyOY?si=ztDwMCNcDGmLXA2C)

Take a look at the video and jump to the timestamp **11:17**, where the feature "20s of inactivity" is mentioned. This is exactly what caused the disaster that happened during the stream.

I didn't want to spend all my time watching the video up to the end, but it's immediately clear what 20s inactivity means in an interrupt driven setup with a universal loading station. It can make trains leave their unloading station with cargo. If such a train goes to the loading station, it can happen it's being loaded with a different kind of cargo, and the "cargo full" condition will never trigger, making this station stall. Depending on the actual interrupt setup it can be made so that incomplete trains will again go to an unloading station until they're empty. In this case, the inactivity part is redundant, since the train will just return to that station.

So don't do this! Don't allow a train at the unloading station leave with any cargo. This is one of the required parameters I mentioned above. This requires proper unloading station setup of course. It requires non-blocking balancing of the buffer chests, so it cannot happen one wagon gets empty and so do the buffer chests, while another wagon stays filled, since their downstream production line doesn't currently consume anything. Balancing the unloading chests with the madzuri method can provoke this even earlier. That's another parameter you need to do right.
The solution at the unloading stations is to always use a belt balancer behind the station that only covers this station. Optionally use mazuri to balance the chests, if one lane+chest is emptied much faster than the other. Both combined will balance wagons. Balancing lanes works automatically as long as the buffer chests eventually get completely filled during a train visit, which automatically takes place on supply driven systems. If you don't implement sufficient wagon, lane and belt balancing, you will end up with one wagon and chests being empty prematurely and other wagons and chests not. Overfilling is one of the crucial keys to avoid and even out inbalancing.

With the rest of your points, could you please explain your points in your post here? I will not do lengthy investigations in your references to find out myself to find out what you might refer to. Please give your points here.

One comment on the "**10-Books-Full-of-Rails**": that's against the KISS principle (keep it simple, stupid). It's too convoluted. It tries to give a pattern for every situation you might encounter. If you reduce you blueprints to a fraction and cut many of the diagonal and elevated blueprints, it would be much easier to use, and at the same time the danger of deadlocks due to improper signaling is vastly reduced.

Tertius wrote: ↑Tue Jan 07, 2025 12:34 pm

raven2cz wrote: ↑Tue Jan 07, 2025 12:00 pm First, let’s start more generally. For example, here’s a video I watched yesterday:
[https://youtu.be/ks9dP8YuyOY?si=ztDwMCNcDGmLXA2C](https://youtu.be/ks9dP8YuyOY?si=ztDwMCNcDGmLXA2C)

Take a look at the video and jump to the timestamp **11:17**, where the feature "20s of inactivity" is mentioned. This is exactly what caused the disaster that happened during the stream.

I didn't want to spend all my time watching the video up to the end, but it's immediately clear what 20s inactivity means in an interrupt driven setup with a universal loading station. It can make trains leave their unloading station with cargo. If such a train goes to the loading station, it can happen it's being loaded with a different kind of cargo, and the "cargo full" condition will never trigger, making this station stall. Depending on the actual interrupt setup it can be made so that incomplete trains will again go to an unloading station until they're empty. In this case, the inactivity part is redundant, since the train will just return to that station.
...

Exactly, you described it perfectly. The moment I saw it, I realized it immediately as well, and how it failed exactly a few minutes later at the end was really funny—it happened so quickly. The best part is that he was trying to solve another emerging problem, where perhaps the delivery takes too long, or something is wrong, and the train simply has to leave the location to be reassigned to something else. You can notice that he started testing this condition due to other significant issues that arose during his testing of the entire system. While it’s not something he should be doing, he was trying to avoid another error he had found—a very, very simple oversight.

If there were a way for the train to know its cargo or, for example, to return to the depot where the current cargo is identified, then it could never leave with the wrong cargo. Do you see where I’m going with this? The vulnerability and fragility of such systems with these kinds of declarations? The system is simply missing a safety mechanism. Imagine in real life sending a train somewhere else without such a mechanism. There’s not even protection on the inserters, so everything would mix together—and you wouldn’t want to clean the entire base of coal mixed with iron, right?

I personally liked the idea much better in the second example I sent. That’s where signal interrupts come in. The train is in the depot, the circuit detects a demand, identifies shortages, and assigns the specific request to the train. This is something vanilla already supports: the train plots its route and performs the required task. However, if there’s an issue, it returns to the depot. But from there, it can no longer leave if there’s a problem.

Is there any way to read its cargo or not? I couldn’t find such an option. It’s about addressing these key edge conditions where even the smallest error can lead to disaster.

Tertius wrote: ↑Tue Jan 07, 2025 12:34 pm Balancing the unloading chests with the madzuri method can provoke this even earlier. <...> Optionally use mazuri to balance the chests, if one lane+chest is emptied much faster than the other. Both combined will balance wagons.

What is madzuri? Can you share a link?