Check "Complete delivery" interrupt on the screenshots I provided above.
The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Moderator: ickputzdirwech
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Thank you very much for your contribution, Hares. I will take a closer look at it. Do you also have the station setup with the Circuit Network or a blueprint? It would make testing easier.Hares wrote: ↑Tue Jan 07, 2025 12:22 pm All of these I can safely call the "bad design" and not "lack of proper system feedback".
...
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:
...
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Edit: Here it is
Slightly modified version of train stops even worked for Gleba -----
That's why I use filter inserters on all train stops. Not because I'm afraid of the train with wrong cargo arriving but mostly because I'm afriaid of random coal or stone appears on the belt (happened even in 2.0 even though destroyed rocks no longer drop stone). I.e., when you change recipe, all unsupported items drop to the assembler trash slots, potentially wasting the belt.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?
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Wow, I completely overlooked that, but now I see it! The section "Complete delivery," second line, "Cargo X > 0," right? At first glance, this looks like the safety mechanism I’ve been searching for, and honestly, I haven’t seen it anywhere else before. Plus, I even missed it just now—if you hadn’t pointed it out!Hares wrote: ↑Tue Jan 07, 2025 1:23 pmThat's why I use filter inserters on all train stops. Not because I'm afraid of the train with wrong cargo arriving but mostly because I'm afriaid of random coal or stone appears on the belt (happened even in 2.0 even though destroyed rocks no longer drop stone). I.e., when you change recipe, all unsupported items drop to the assembler trash slots, potentially wasting the belt.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’ll need a few days to take a proper look at the blueprint and verify it. In any case, I really like this a lot. Thanks so much!
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Certainly I see where you're going. However, you don't see where I'm going with this. You want the game engine modified to support a concept it currently doesn't support well. I didn't see the issue in the video because I'm genius (I'm not), instead I was able to see it, because I encountered exactly the same issue myself. But I didn't complain. I monitored and researched the reason of misbehavior, than tackled these reasons. I posted the reason and the solution in my post above. Didn't you see this? In its core, this is about balancing the unloading process. Surprisingly, this hasn't directly to do with the rail system and schedules, but it cannot be separated from it. Balance lane, belt, wagon. With balance comes equal unloading of the wagons, with equal unloading of the wagons comes all wagons getting empty in the same moment, with this comes the train will always leave empty, and with this comes a simple implementation of the interrupt system.raven2cz wrote: ↑Tue Jan 07, 2025 1:08 pm 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 benefit of balanced unloading also means trains are used most efficiently, because a train never takes a part of its content back to from where it came, and downstream production lines never starve for items from empty chests and wagons, while the neighboring chest is still full and preventing the train to leave.
I'm sure you encountered issues with balancing train unloading yourself. This is one of the oldest and most generic non-trivial challenges of Factorio. There are a few good solutions, with varying quality and complexity. This is not trivial, but there are solutions. I posted the approach I use. Some people cheat and use mods that use some kind of "loader" to pull the content of a whole wagon. Not required, they cheat.
The safety mechanism in this case is the "empty cargo" condition. No timeout. Instead "empty cargo". And if a train doesn't become empty, improve the unloading so trains are guaranteed to become empty. And if a train is guaranteed to be either full (after loading) or empty (after unloading), the whole train control becomes vastly more simple. The unloading is more sophisticated, but better divide complexity between 2 systems instead of putting double of it into one and the same system. Divide et impera.
Use the green wildcards with interrupts. They can be used whenever interrupts trigger: when a train is at a station and its waiting condition just became true so it's about to leave a station. In this moment the interrupt conditions are checked, and here the train "knows" its cargo. It's the green wildcards visible in Hares' screenshots, but also presented in fff-395.
It's a mechanism to balance chests being loaded or unloaded equally by computing the average chest content and enable the inserters whose chest content is above or equal to the average and disable the inserters whose chest content is lower than the average. Requires just 1 combinator per station.
See https://wiki.factorio.com/Tutorial:Circ ... est_insert
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Ah. I used it when I played tutorial. Prefer to balance the belts instead as it's more optimized (UPS-wise) and faster if your load at high throughput.Tertius wrote: ↑Tue Jan 07, 2025 3:43 pmIt's a mechanism to balance chests being loaded or unloaded equally by computing the average chest content and enable the inserters whose chest content is above or equal to the average and disable the inserters whose chest content is lower than the average. Requires just 1 combinator per station.
See https://wiki.factorio.com/Tutorial:Circ ... est_insert
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Hares,
I’m looking at the blueprint, and there’s one thing I don’t understand. Who assigns the value to the train’s interrupt signal? For example, I’ve been using the depot station to assign it, but now that I’m looking at your blueprint, there’s a logic circuit that doesn’t seem to do anything. I don’t see where the main logic for assigning tasks to the train is being handled.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
There are a few things the system should have in order to improve things for better usability, and they likely have code in engine already that could be used to solve them:
Cargo (Any Wagon)
Cargo (All Wagons)
This is similar to the Fuel count difference and critical for more complex networks. Simply taking the average doesn't solve the underlying issue of if a given wagon is missing a needed item, it's a useless wagon. I needed to solve this with inventory checks in boxes\machines, but having it in the train scheduling would be overwhelmingly better, especially because it could create dispatch batches when using filtered wagons and multiple target stations
Station signal: Train Demand
Outputting a Cargo signal (preferably in negative) of the train's reason for stopping would be immensely useful and after working with LTN and Cybersyn so long, I was shocked this wasn't in the game engine by default
Detector Rails
Having either a special, circuit enabled rail segment, or an update to the Rail or Chain (or both) Signal to output information about the occupying wagon or locomotive directly above it, preferably only when docked (activated similarly to when the wagon doors open when arriving, or inserters status of 'waiting for train') would allow for proper loading circuits to be made that were smart and reliable. Again, solutions with average have always failed me in the end, true, live data from individual wagons is critical
Non train related but still vital: Selection to control insterter stack size on signal strength (EACH)
Now that the selector combinator is in game, two combinators from any loader circuit could be removed if the inserters were able to respect the item signal being sent as a filter _and_ simply pick up the amount of items corresponding to the signal strength.
Cargo (Any Wagon)
Cargo (All Wagons)
This is similar to the Fuel count difference and critical for more complex networks. Simply taking the average doesn't solve the underlying issue of if a given wagon is missing a needed item, it's a useless wagon. I needed to solve this with inventory checks in boxes\machines, but having it in the train scheduling would be overwhelmingly better, especially because it could create dispatch batches when using filtered wagons and multiple target stations
Station signal: Train Demand
Outputting a Cargo signal (preferably in negative) of the train's reason for stopping would be immensely useful and after working with LTN and Cybersyn so long, I was shocked this wasn't in the game engine by default
Detector Rails
Having either a special, circuit enabled rail segment, or an update to the Rail or Chain (or both) Signal to output information about the occupying wagon or locomotive directly above it, preferably only when docked (activated similarly to when the wagon doors open when arriving, or inserters status of 'waiting for train') would allow for proper loading circuits to be made that were smart and reliable. Again, solutions with average have always failed me in the end, true, live data from individual wagons is critical
Non train related but still vital: Selection to control insterter stack size on signal strength (EACH)
Now that the selector combinator is in game, two combinators from any loader circuit could be removed if the inserters were able to respect the item signal being sent as a filter _and_ simply pick up the amount of items corresponding to the signal strength.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Yes, I understood your post, and once again, I completely agree with everything you’re saying. This will definitely help with many issues, and just a few weeks ago, I was dealing with the unloading problem you described. I’ve improved a lot of things around it, but from your explanation, there’s still much more that can be done better.Tertius wrote: ↑Tue Jan 07, 2025 3:43 pmCertainly I see where you're going. However, you don't see where I'm going with this. You want the game engine modified to support a concept it currently doesn't support well. I didn't see the issue in the video because I'm genius (I'm not), instead I was able to see it, because I encountered exactly the same issue myself. But I didn't complain. I monitored and researched the reason of misbehavior, than tackled these reasons. I posted the reason and the solution in my post above. Didn't you see this? In its core, this is about balancing the unloading process. Surprisingly, this hasn't directly to do with the rail system and schedules, but it cannot be separated from it. Balance lane, belt, wagon. With balance comes equal unloading of the wagons, with equal unloading of the wagons comes all wagons getting empty in the same moment, with this comes the train will always leave empty, and with this comes a simple implementation of the interrupt system.raven2cz wrote: ↑Tue Jan 07, 2025 1:08 pm 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?
When I look at your technical approach—not focusing on unloading now but rather on addressing specific issues as they arise—you approach each problem as a technician and resolve it. A second problem arises, and you solve it too. However, the issue I raised in this thread wasn’t meant to target a specific technical problem but rather to address the broader issue of using interrupts in a way that minimizes the dozens of potential errors that designers can make. These errors often lead to disappointment much later when everything seems to be working fine, sometimes for a week or more.
Overall, the system is very fragile and prone to basic errors, which, from my perspective, makes it a poor design. That’s why I wanted to highlight the fundamental issue I see: the lack of adequate feedback to verify the status of a train’s delivery. That’s the entire point.
I’m really glad for the additional contributions that have appeared here because, for instance, the cargo condition is something I simply overlooked and hadn’t seen in other approaches. It’s so critical that it should practically be flashing red! However, there are also new posts discussing a cargo signal, which, as others have pointed out, doesn’t currently exist. Yet, some people on Reddit are now saying that train cargo can be read, so I’m a bit unsure where the truth lies.
How should I proceed from here? I think I’ll now take a detailed look at Hares’ post and try to understand some of his ideas that I’ve noticed there. However, I’m currently stuck on figuring out how the interrupt signal value is propagated to the train in his approach. That’s where I’m currently blocked.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
It's set in two different places, for different purposes.raven2cz wrote: ↑Tue Jan 07, 2025 4:42 pm Hares,
I’m looking at the blueprint, and there’s one thing I don’t understand. Who assigns the value to the train’s interrupt signal? For example, I’ve been using the depot station to assign it, but now that I’m looking at your blueprint, there’s a logic circuit that doesn’t seem to do anything. I don’t see where the main logic for assigning tasks to the train is being handled.
- One is set on the depot, for trains awaiting new task assignment -- it holds list of all cargo/fluid types available on the current surface. In blueprint, there's constant comb for that purpose, but (a) it requires manual surface selection (no global radar) and (b) its wiring may be broken as I sent you as-is version, and selector comb is definitely not needed there (was needed before this bug was fixed: 117778: [2.0.11] Interrupt condition "X is not full" flickering)
- The other is set on the requester end for re-deliveries if the demand is not covered (to skip "go to depot" step)
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
I made my current train system by first thoroughly studying then shamelessly copying the stuff that was presented in fff-389 and fff-395.
The general idea and interrupt layout is in #389. Then in #395 the refinement with the green wildcards that replace explicit selecting of all the cargo to expect with just 1 wildcarded interrupt.
It's according to a German proverb: "besser gut geklaut als schlecht selbstgemacht" or as English translation "Better well stolen than poorly homemade".
I use 2-4 trains [overengineered, 1-4 would be sufficient]
All loading stations get the same name no matter the material they load. All unloading stations get the material they want to receive in their station name.
In addition to that, I gave all my stations static train limits of 2, and I supplied a big enough waiting area.
The loading stations are expected to always have a train on them: either full or currently being loaded. If a full train departs, the next train can immediately move in, so I don't build the loading stations with any buffer chests. Material directly goes into the train. This is ups-friendly and avoids buffered material.
The unloading stations have a well-known setup with 4 buffer chests per wagon. That's more than necessary, because since there is already a train waiting in front of each station, as soon as an empty train leaves the station the next one moves in immediately with minimum latency - just a few seconds. This is because of the push system - the waiting area is always full. If it isn't full, it's a sign I need to build more loading stations or there is a traffic jam. I group multiple unloading stations, so I'm able to combine the waiting areas, so it's much less space required for the waiting area. Trains wait in the waiting area by correct usage of chain signals.
Unloading area at base and schedule: Interrupts: Unloading station layout: Loading station layout: The one combinator you see at the unloading stations is for madzuri-style balancing the filling of the buffer chests from the wagon.
The one combinator you see at the loading station is for raising the priority from 50 to 51 if there is just one train reserving the station. This way all stations first get 1 train, and if all trains have 1 train, the second train will address them. This way far away stations will also get their trains.
Both circuits are one of the small combinator optimizations that improve a working system even further, but it will also work without.
I built this general setup on Nauvis before I started exploring the planets. I built 1-2 more mining outposts than necessary to avoid running out while I was away. I upgraded it with the fruits of exploration, and it never ever failed while I was away. It just worked silently. It always transported what it's supposed to transport.
The general idea and interrupt layout is in #389. Then in #395 the refinement with the green wildcards that replace explicit selecting of all the cargo to expect with just 1 wildcarded interrupt.
It's according to a German proverb: "besser gut geklaut als schlecht selbstgemacht" or as English translation "Better well stolen than poorly homemade".
I use 2-4 trains [overengineered, 1-4 would be sufficient]
All loading stations get the same name no matter the material they load. All unloading stations get the material they want to receive in their station name.
In addition to that, I gave all my stations static train limits of 2, and I supplied a big enough waiting area.
The loading stations are expected to always have a train on them: either full or currently being loaded. If a full train departs, the next train can immediately move in, so I don't build the loading stations with any buffer chests. Material directly goes into the train. This is ups-friendly and avoids buffered material.
The unloading stations have a well-known setup with 4 buffer chests per wagon. That's more than necessary, because since there is already a train waiting in front of each station, as soon as an empty train leaves the station the next one moves in immediately with minimum latency - just a few seconds. This is because of the push system - the waiting area is always full. If it isn't full, it's a sign I need to build more loading stations or there is a traffic jam. I group multiple unloading stations, so I'm able to combine the waiting areas, so it's much less space required for the waiting area. Trains wait in the waiting area by correct usage of chain signals.
Unloading area at base and schedule: Interrupts: Unloading station layout: Loading station layout: The one combinator you see at the unloading stations is for madzuri-style balancing the filling of the buffer chests from the wagon.
The one combinator you see at the loading station is for raising the priority from 50 to 51 if there is just one train reserving the station. This way all stations first get 1 train, and if all trains have 1 train, the second train will address them. This way far away stations will also get their trains.
Both circuits are one of the small combinator optimizations that improve a working system even further, but it will also work without.
I built this general setup on Nauvis before I started exploring the planets. I built 1-2 more mining outposts than necessary to avoid running out while I was away. I upgraded it with the fruits of exploration, and it never ever failed while I was away. It just worked silently. It always transported what it's supposed to transport.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
It is possible for your system to clock up with the same item if your production is currently-idle. It will probably not happen but it's possible.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Not if you use enough trains. I encountered the issue and investigated. You need to add the train limits of the loading stations and the train limits of the unloading stations. That many trains need to be deployed. That's a whole lot of it. This way every loading station gets trains even if the unloading stations don't produce empty trains.
The depot needs as many entries as there are unloading stations. This will prevent unloading stations from being occupied by empty trains. (the depot in my example is too small, and I deployed not enough trains - it's always growing and you never grow everything correctly)
If material isn't consumed, first the unloading stations get full with trains (2 per station). Then the corresponding loading stations as well (2 per station). At this moment no more trains (no more than 4) can be occupied by some material, because there are no free slots at the corresponding loading stations where they could get cargo.
If everything stops, and you have as many trains as I wrote above, every single station has all its slots occupied. Every station has a train and another one in its waiting area (if you use train limit 2 everywhere). But trains with some given material will not accumulate without limit. It's limited by the train limits of the stations.
The depot needs as many entries as there are unloading stations. This will prevent unloading stations from being occupied by empty trains. (the depot in my example is too small, and I deployed not enough trains - it's always growing and you never grow everything correctly)
If material isn't consumed, first the unloading stations get full with trains (2 per station). Then the corresponding loading stations as well (2 per station). At this moment no more trains (no more than 4) can be occupied by some material, because there are no free slots at the corresponding loading stations where they could get cargo.
If everything stops, and you have as many trains as I wrote above, every single station has all its slots occupied. Every station has a train and another one in its waiting area (if you use train limit 2 everywhere). But trains with some given material will not accumulate without limit. It's limited by the train limits of the stations.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
I know I’m being annoying, but I consider the depot calculation to be the core of the entire system, and if I don’t know exactly how it works in your setup, the entire system I assemble for testing will be different.Hares wrote: ↑Tue Jan 07, 2025 6:33 pmIt's set in two different places, for different purposes.raven2cz wrote: ↑Tue Jan 07, 2025 4:42 pm Hares,
I’m looking at the blueprint, and there’s one thing I don’t understand. Who assigns the value to the train’s interrupt signal? For example, I’ve been using the depot station to assign it, but now that I’m looking at your blueprint, there’s a logic circuit that doesn’t seem to do anything. I don’t see where the main logic for assigning tasks to the train is being handled.
- One is set on the depot, for trains awaiting new task assignment -- it holds list of all cargo/fluid types available on the current surface. In blueprint, there's constant comb for that purpose, but (a) it requires manual surface selection (no global radar) and (b) its wiring may be broken as I sent you as-is version, and selector comb is definitely not needed there (was needed before this bug was fixed: 117778: [2.0.11] Interrupt condition "X is not full" flickering)
- The other is set on the requester end for re-deliveries if the demand is not covered (to skip "go to depot" step)
I could take the approach of incorporating it from my own depot solution, but then the test will be different, and if the system fails, it won’t be a test of your system.
I don’t know if you’re aware, but the depot calculation is completely missing in that blueprint.
For depot calculation and management, I use a modified experimental part defined here:
[https://steamcommunity.com/sharedfiles/ ... eview=true](https://steamcommunity.com/sharedfiles/ ... eview=true)
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
On our server in Nauvis, we essentially maintain three main groups of trains:Tertius wrote: ↑Tue Jan 07, 2025 6:40 pm I made my current train system by first thoroughly studying then shamelessly copying the stuff that was presented in fff-389 and fff-395.
The general idea and interrupt layout is in #389. Then in #395 the refinement with the green wildcards that replace explicit selecting of all the cargo to expect with just 1 wildcarded interrupt.
It's according to a German proverb: "besser gut geklaut als schlecht selbstgemacht" or as English translation "Better well stolen than poorly homemade".
...
- First group: 1-2-0
This group is used for managing internal transportation between intermediate production facilities within the mega city. There isn’t enough space for larger trains in this setup. - Second group: 1-4-1
We don’t use 2-4-0 because, with nuclear fuel and maximum train acceleration, we prefer 1-4-1 setups. These significantly simplify space management for loading/unloading stations, especially now that elevated rails can be used, further reducing the required space. This group transports semi-processed materials from mid-range and long-distance hubs. For example, we almost no longer transport raw ores but process them directly at designated sub-centers. - Third group: Special-purpose balancing trains
This group is separate and serves for internal special balancing cases, where delivery shortages occur. These trains essentially provide buffering and ad hoc deliveries of resources.
This has been particularly useful recently during the production of legendary-quality modules, where copper demand surprisingly outpaced iron demand, which I hadn’t anticipated.
For unloading, we’ve started adopting a different style, which is defined here:
https://youtu.be/CCfKZDCbxh4?si=fbDY7Z_MVAeedlKu
However, I also had another video showcasing a variation from Nilaus, but because there are so many videos, I can’t recall which one it is right now—it was something defined in Gleba videos.
Attached here is the current working version of the 1-4-1 train unloading station design.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
You can easily read train cargo using a train stop with "read train content". Also interrupts are allowed to triggered based on train content, which makes it another way to do.raven2cz wrote: ↑Tue Jan 07, 2025 5:31 pm I’m really glad for the additional contributions that have appeared here because, for instance, the cargo condition is something I simply overlooked and hadn’t seen in other approaches. It’s so critical that it should practically be flashing red! However, there are also new posts discussing a cargo signal, which, as others have pointed out, doesn’t currently exist. Yet, some people on Reddit are now saying that train cargo can be read, so I’m a bit unsure where the truth lies.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Exactly, I found it there yesterday as well after those posts. This is the right approach. Let me once again highlight the basic principle of the problem. If something goes wrong—and believe me, in a mega-city, something will always go wrong—there absolutely must be safety protocols to get the train out of trouble. The state of the system should be carried by the train itself; if it does anything else, it's just distributing the state, and such a system will be unstable in the long term. That's why the information must come directly from the train, ideally evaluated onboard—i.e., interrupts. However, I can also imagine additional processing at the depot, such as safety measures or optimization procedures during unloading, where a new plan is implemented, or another safety mechanism is activated.mmmPI wrote: ↑Wed Jan 08, 2025 7:15 amYou can easily read train cargo using a train stop with "read train content". Also interrupts are allowed to triggered based on train content, which makes it another way to do.raven2cz wrote: ↑Tue Jan 07, 2025 5:31 pm I’m really glad for the additional contributions that have appeared here because, for instance, the cargo condition is something I simply overlooked and hadn’t seen in other approaches. It’s so critical that it should practically be flashing red! However, there are also new posts discussing a cargo signal, which, as others have pointed out, doesn’t currently exist. Yet, some people on Reddit are now saying that train cargo can be read, so I’m a bit unsure where the truth lies.
Interestingly, so far, I’ve only seen this approach in one example that was shared here. I simply haven’t seen it or discovered it in the others. But well, with Factorio, I always discover new things—often very well-hidden, though.
However, if any of you already have a good solution for error handling, I’d love to see it. It would certainly save a lot of work and development time.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
I'm surprised you'd say that LTN does it right and vanilla Factorio does it wrong.
I like LTN, but one terrible OOTB setting it has is to assume a train is "lost" after a certain amount of time with no delivery. That's how you end up with mixed belts.
In vanilla Factorio you just use Empty cargo. The worst that can happen is a major stall, but that's much more easily fixable than belt contamination.
I like LTN, but one terrible OOTB setting it has is to assume a train is "lost" after a certain amount of time with no delivery. That's how you end up with mixed belts.
In vanilla Factorio you just use Empty cargo. The worst that can happen is a major stall, but that's much more easily fixable than belt contamination.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
With LTN, I wasn’t focusing on overall functionality but rather on transmitting cargo information to ensure feedback loops that can be measured accurately. This would allow the system to take corrective action and perform error handling. That is, if an error occurs, it could detect the error, take corrective measures, or at least stop the train. However, after the discussions here, it’s clear that at least the basics of error handling do exist in vanilla. I just couldn’t find them, either on my own or in the tested systems, where they weren’t implemented in a way that would function correctly.Kyralessa wrote: ↑Wed Jan 08, 2025 8:50 am I'm surprised you'd say that LTN does it right and vanilla Factorio does it wrong.
I like LTN, but one terrible OOTB setting it has is to assume a train is "lost" after a certain amount of time with no delivery. That's how you end up with mixed belts.
In vanilla Factorio you just use Empty cargo. The worst that can happen is a major stall, but that's much more easily fixable than belt contamination.
I think it would be great if this thread continued with direct solutions for error handling and approaches to it. I’ll also proceed in this direction from now on.
Re: The Train System Lacks Proper System Feedback – Leading to Ongoing Frustration
Of course you can't find any depot calculation in my BPs because there's none. The system works on the train stops on both ends being open -- that's why it has such complicated rulings in the main delivery interrupt.raven2cz wrote: ↑Wed Jan 08, 2025 5:49 am
I know I’m being annoying, but I consider the depot calculation to be the core of the entire system, and if I don’t know exactly how it works in your setup, the entire system I assemble for testing will be different.
I could take the approach of incorporating it from my own depot solution, but then the test will be different, and if the system fails, it won’t be a test of your system.
I don’t know if you’re aware, but the depot calculation is completely missing in that blueprint.
- Train sits on the depot with empty cargo
- Every 5s, it checks for all signals connected to that train stop (i.e., ore types) to match conditions:
- That item provider is open (# of approaching trains < dynamically configured limit, most of the time 0 or 1)
- That item requestor is open (same rules)
- If all rules are satisfied, the delivery task is assigned:
- Go to that item provider and sit there until inventory is full
- Go to that item requestor and sit there until inventory is empty
- If you find the requestor being full while also having cargo, go to the depot first and wait until it opens again
- Upon completing the delivery, if the exact same route can be performed again, it does
- Trains that finish their current task while having cargo will try to finish the delivery
- Trains that can't reach their target by either reason will sit on depots
- Trains that are low on fuel are ordered to refuel
- Every potentially-deliverable item type must be manually configured
- Train stops are required to "validate" train content so no garbage ever put to the train
- If a previously-closed requester opens for one train while that item is being oversupplied by providers, more than one train will depart
- This can potentially clock the system if it does not have enough trains
- In case of there being enough trains, the system is clock-safe as at least one of the departed trains is guaranteed to finish its delivery
- Requires careful setup of rail signals
- After I stopped encountering schedule bugs (i.e., 117778: [2.0.11] Interrupt condition "X is not full" flickering), 99% of train system incidents (one leading to a complete disaster & blackout on Gleba, and one similar on Nauvis) were rail signals (many minors, only two majors)
- Read more: Discord @DocJade #space-age -- Nauvis disaster (2024-12-13)
- Read more: Discord @DocJade #space-age -- Gleba disaster (2024-12-13 -- yes, both on the same day)