General Purpose Train Lines for a Megabase

[Premu]

I've already finished three mega bases (the last one was a 2.7k SPM), and was searching for some good ideas for my next attempt.

In my last base I used the new train limits to connect my suppliers and requesters - i.e. I had a train line for each good (like iron plates) picking those up whereever these were available and delivering those to any station where it was needed. That worked pretty well. And I thought - why not take this one step further.

So - a train might pick up Iron plates and deliver those to a station where it is needed, e.g. to green circuits. Once empty, it would drive to another pick-up station - but not necessarily iron plates. It could drive to my pick up-station for green circuits instead and deliver those to e.g. my blue circuit production instead. I mean - that is how real life logistics work.

Of course, there will be some massiv challenges if trying to implement something like that in Factorio. Somehow I need to make sure:

- loaded trains will go to a station fitting to their cargo.
- trains already on the way to the correct station should not reroute to somewhere else.
- emptied trains will leave the station and not wait for any empty pickup place
- Offloading stations have to be robust against occasional wrong trains arriving
- Both starvation and overloading of stations with trains (both pickup and offload) must be prevented

The first issue looks really tricky, but for that I have an idea. Along my railway lines I'll have a whole network of green and red wires to exchange signals - this is obviously necessary to pull anything like that of. Along that I'll send a "rotating" signal. For one tick I'll send Iron Plates with the value one, in the next tick this value is set to 0, but Copper plates is set to 1, etc. This will go through the whole list of goods I send via train. The condition for leaving a pickup station is set to full cargo and the signal for this good is 1. The train limits for offloading stations is multuplied with the value of the good it receives. So in theory - a train fully loaded with iron plates will only leave the station once it's the turn for iron plate trains to start. At the point only stations which want to offload iron plates are able to receive that train, so it will pick a free one of those.

A potential problem I see here - what happens if all possible offload stations are already fully satsified? As far as I understand the system the train would be already set to have "left" the station even it is standing there, and will start driving off as soon as a station is free. And that might happen in a tick in which a different good is "active". I might solve this by having an additional signal after the station which I only allow to be set to green if the good of the station is the "active" one.

The rerouting while on travel should be not such a big issue as long as my train network is robust enough I think. Trains should only wait for longer time in stackers close to their actual target station. Or would trains parked in stackers already set for a specific station possibly reroute? Or do they stick to their target? I'm not sure about this point.

In case no empty pickup place is available I might just send trains to a waiting station which is inactive normally - this should also be no big issue.

Making offloading stations robust should be straight forward - use filtered stack inserters to unload the wagons and set the leaving condition to expected good in train = 0 - in that case even if somehow a wrong train arrives it should just rush through.

The starvation or overloading issue is the hardest to judge for me. Trains typically prefer targets nearby, so a mining outpost far away could wait ages until a train arrives. In the mean time stations in the center might be overcrowed. I hope this should be prevented by setting clever train limits for both picking up and offloading stations and have the right number of trains. Enough but not too many. But that is something I'll actually have to see if it works...

So my question to the crowd wisdom out here is: Did I oversee something fundamental here? Did someone perhaps even already try something like that and has some experience and hints?

I know it's not the easiest and most straight forward approach, but that's exactly the reason I try to do this challenge.

[torne]

Generally if people want a system where the same trains serve multiple different types of delivery between different stations they use the LTN mod, which provides exactly this: a system for dispatching a pool of trains to fulfil matches between stations that provide and request items.

It's possible to build something that has many of the same properties in vanilla with the kind of circuit logic you're proposing here and people have done it in the past, but I think they're all pretty complex and are likely to have more limitations than LTN. The vanilla train schedule system is very much designed around trains having fixed logical routes ("iron pickup" -> "iron dropoff") even though their physical routes can be pretty dynamic thanks to train limits, disabling stations, etc.

[mmmPI]

The rerouting while on travel should be not such a big issue as long as my train network is robust enough I think. Trains should only wait for longer time in stackers close to their actual target station. Or would trains parked in stackers already set for a specific station possibly reroute? Or do they stick to their target? I'm not sure about this point.

This (imo) is extremly situationnal. The shape of the network, the distance, the fuel used, the size of train, the frequecy of enabling disabling, the number of other train stopped named similarly, the total number of train, the relative position of those thing makes a very high number of parameter that can all have an impact on the result making it difficult to predict. ( for example a train could reroute sometimes but only if 7/8 station are closed, which would only in this case cause a deadlock if the train has at least 5 wagons and is not using wood fuel because that's the only case where it would be fast enough to get priority over another train present in a stacker. That sounds weird, but it is possible to make such system by accident and good luck debugging that.)

I am under the same feeling as torne usually when you don't want your train to possibly reroute to another station that has the same name but a different purpose. Unless using LTN that's different.

Now if you want to make it happen in vanilla because that's your goal to have station named the same using different cargo, you need to precise what you call "robust enough". Because as far as i understand from your description, one routing error could cause a train of copper to unload in an iron furnace train stop that's how bad an accidental rerouting could be right ?

You can mitigate the consequences of such accidental rerouting with many different creative methods Like reading some belt to make sure there is no material contamination or otherwise ringing an alarm and cutting the belt and immobilizing the train. That's not really automated solution so maybe not good enough for your challenge.

If you plan properly all the parameter mentionned above it may never happened and only act as an emergy stop.

You can make it easier for yourself to plan those parameter by having different "train line" with dedicated trains instead of having all your trains available for potentially all station. ( i'm not sure it's still ok with your challenge though) Or similar configuration where you have say 5 similar unit of production. each of those unit served by a multipurpose train. Each train having between x to y possible destination. This would reduce the complexity of the whole network, making it easier to predict, making smaller problem similar to each other and next to each other rather than a giant big mess.

It is also true for signals, it makes it easier to not mess them up if you have several different networks !

And also to go from theory to practice having one little version that function properly, makes it easy to duplicate it 5 times and adapt it each time for the specific need of the unit of production, allowing an organic growth to the network once the first brick is properly layed.

I'm not sure i understand your "rotating signal" idea but on this part it's different, it's possible to predict and design a reliable system to enable disable stations or transmit quantity or material in a simpler way than it is to guarantee the rerouting won't happen or cause trouble (imo).

Then the least of the problem i think is the starvation and overloading of station. This one shouldn't be a problem, trains should have a place to wait when no transportation is required. In your planned system it cannot be at a loading area. Nor can you have trains at waiting area while being full of material. Because the next transportation is of unknown material the loading is decided at the last moment. You can't have all your trains filled with a material in advance. Therefore the waiting areas should be placed after the unload of material, so that empty trains waits for the next material to pick up to be received by stations. ( or trains can wait empty just after unload if you have more unload area than trains provided they don't block another incoming train.).

Then just go for overloading. since the previous point make sure it is handled properly. make sure you don't starve. Also as you said, use the limit system to turn station that no longer need material to 0. This will force/push the trains away from them. so the train will fill up the closest station in the center as you describe, then spill over to the 2nd closest, then spill over to the 3rd closest and so on.

I would say if the rerouting is not a problem ( as it's the 1rst and main factor ) then there is no problem if a train going to the 3rd closest station reroute to go the the 1rst instead midway because it has reopene-ed and your en-route train is still closer to it than to the 3rd far away. Something like it wouldn't even be a problem if your trains are multipurpose but have only 1 unload station, in this case the situation would translate to a train fetching iron is rerouted to fetch copper midway, but that's because the unloading area is requiring iron, and now also copper and copper happens to be easier/closer to deliver for the en-route train.

A naming convention for train station that would illustrate would be A B C D E F are the name of the unloading station for the production unit. And AL BL CL DL EL FL Would be the name of the iron copper coal, plastic , uranium whatever material could be required by each production unit.

So for a green circuit production unit, you could have a train with schedule A => AL; and you have 5 iron patch with a station called AL and also 10 copper patch with a station called AL. The train would wait at A until something is requested by the production unit, then go to the AL station opened, iron or copper , you send the signal, the train go fetch. Rerouting is no longer a problem because happening only if copper OR iron are ok.

This is from experience how i would make general purpose train line to work around the way the game handles the rerouting. Build my system around it to exclude problems by design, segmenting networks in unit inside witch uncontrolled rerouting is not a problem rather than trying to avoid having it happening as this is difficult to do and to predict.

[Premu]

Thanks for your ideas, they were very helpful.

The rerouting while on travel should be not such a big issue as long as my train network is robust enough I think. Trains should only wait for longer time in stackers close to their actual target station. Or would trains parked in stackers already set for a specific station possibly reroute? Or do they stick to their target? I'm not sure about this point.

This (imo) is extremly situationnal. The shape of the network, the distance, the fuel used, the size of train, the frequecy of enabling disabling, the number of other train stopped named similarly, the total number of train, the relative position of those thing makes a very high number of parameter that can all have an impact on the result making it difficult to predict. ( for example a train could reroute sometimes but only if 7/8 station are closed, which would only in this case cause a deadlock if the train has at least 5 wagons and is not using wood fuel because that's the only case where it would be fast enough to get priority over another train present in a stacker. That sounds weird, but it is possible to make such system by accident and good luck debugging that.)

I am under the same feeling as torne usually when you don't want your train to possibly reroute to another station that has the same name but a different purpose. Unless using LTN that's different.

Hm, I had a second thought about the rerouting. Just to clarify - here I mean a train actually selecting another target station, not another way to the same target station.

As far as I understand with the train limit system, a train set to a specific station will stick to it, no matter if other stations with the same name open up which might be nearer. The only reason a train would abandon its target is the target station is disabled (which I won't do, I'll just change the train limit to 0, which means any trains on their way will still go there) or destroyed. The latter might not be impossible as i could get the idea to cruise around in my base with a tank or accidently fire a nuke, but is at least not a regular occurence.

Now if you want to make it happen in vanilla because that's your goal to have station named the same using different cargo, you need to precise what you call "robust enough". Because as far as i understand from your description, one routing error could cause a train of copper to unload in an iron furnace train stop that's how bad an accidental rerouting could be right ?

You can mitigate the consequences of such accidental rerouting with many different creative methods Like reading some belt to make sure there is no material contamination or otherwise ringing an alarm and cutting the belt and immobilizing the train. That's not really automated solution so maybe not good enough for your challenge.

For me "robust enough" means that any deviation does not immediately lead to a "lock down" of the factory, and that it should be a pretty rare occurence. (Although it's hard to actually measure what's rare. I don't really have a metric in mind here.) For unloading, I actually have a simple idea to prevent the mixing - I just use filtered stack inserters to do that, and belts won't accidently mix up materials. I'll end up with a train blocking a station, though - but that could be solved by adding an alarm for every station to check if a train stopped there has anything loaded which should not be offloaded there, so that I can remove the train manually should this happen.

If you plan properly all the parameter mentionned above it may never happened and only act as an emergy stop.

You can make it easier for yourself to plan those parameter by having different "train line" with dedicated trains instead of having all your trains available for potentially all station. ( i'm not sure it's still ok with your challenge though) Or similar configuration where you have say 5 similar unit of production. each of those unit served by a multipurpose train. Each train having between x to y possible destination. This would reduce the complexity of the whole network, making it easier to predict, making smaller problem similar to each other and next to each other rather than a giant big mess.

It is also true for signals, it makes it easier to not mess them up if you have several different networks !

I'll have to have at least four such train lines anyway, as I'll use for different train configurations - two locomotives with four cars for some products and one locomotive with two cars for others. And the same for fluids. Although the trains with four cargo wagons will be the most used type.

Mixing networks is tricky - but as I worked on the idea I see it still as easiest way to use both the red and green network in parallel. I'll just need to be very cautious with connecting my station blueprints to the global network. But I had an idea for that, too - build in automated alarms in the blueprint which will go off only after connecting everything and setting all parameters.

And also to go from theory to practice having one little version that function properly, makes it easy to duplicate it 5 times and adapt it each time for the specific need of the unit of production, allowing an organic growth to the network once the first brick is properly layed.

I'm not sure i understand your "rotating signal" idea but on this part it's different, it's possible to predict and design a reliable system to enable disable stations or transmit quantity or material in a simpler way than it is to guarantee the rerouting won't happen or cause trouble (imo).

Then the least of the problem i think is the starvation and overloading of station. This one shouldn't be a problem, trains should have a place to wait when no transportation is required. In your planned system it cannot be at a loading area. Nor can you have trains at waiting area while being full of material. Because the next transportation is of unknown material the loading is decided at the last moment. You can't have all your trains filled with a material in advance. Therefore the waiting areas should be placed after the unload of material, so that empty trains waits for the next material to pick up to be received by stations. ( or trains can wait empty just after unload if you have more unload area than trains provided they don't block another incoming train.).

Well, I've started to build my new base where I want to implement it, and soon I'll need my first railway lines to get in extra ore. Here I can test my idea in small before trying to roll it out directly in a megabase. That might help to find some oversight.

I changed my first idea a little bit as I thought about it a little bit more, but basically I'll connect the drive-away condition of loading stations as well as setting the train limit of the receiving stations based on a signal which cycles through powers of 2. So a train will only leave a pick-up station if it's full and the loaded good (e.g. iron plates) is on the schedule, while simultaniously the train limits for all stations requesting iron plates is set to their intended value while the train limits of all other receiving stations is set to 0. Additionally I can include a check that there are actually potentially free receiving stations for iron plates - not that all the intended target stations are already at their limit and a train loaded with iron plates will technically "leave" the station with "no target" before picking a station not intended for its cargo.

I can also additionally set the train limit for pick-up stations to 0 if all potential stops of their consumers are already filled up. To prevent potential starvation issues. For that purpose I'll use the red and green networks - the red network will provide how many receiving stations are potentially open for each good (even if the train limit might be 0 at the moment due to the logic from above), the green one how many spots are available for picking up the good.

A tricky part will be to make sure the "signal delay" is the same for both kind of stations. But if I keep that in mind it should be doable. I already prepared a set-up for the central control logic, that was actually surprising simple:



OK, it might look big, but the part on the right is just so big because it circles through 21 different goods.

Then just go for overloading. since the previous point make sure it is handled properly. make sure you don't starve. Also as you said, use the limit system to turn station that no longer need material to 0. This will force/push the trains away from them. so the train will fill up the closest station in the center as you describe, then spill over to the 2nd closest, then spill over to the 3rd closest and so on.

I would say if the rerouting is not a problem ( as it's the 1rst and main factor ) then there is no problem if a train going to the 3rd closest station reroute to go the the 1rst instead midway because it has reopene-ed and your en-route train is still closer to it than to the 3rd far away. Something like it wouldn't even be a problem if your trains are multipurpose but have only 1 unload station, in this case the situation would translate to a train fetching iron is rerouted to fetch copper midway, but that's because the unloading area is requiring iron, and now also copper and copper happens to be easier/closer to deliver for the en-route train.

A naming convention for train station that would illustrate would be A B C D E F are the name of the unloading station for the production unit. And AL BL CL DL EL FL Would be the name of the iron copper coal, plastic , uranium whatever material could be required by each production unit.

So for a green circuit production unit, you could have a train with schedule A => AL; and you have 5 iron patch with a station called AL and also 10 copper patch with a station called AL. The train would wait at A until something is requested by the production unit, then go to the AL station opened, iron or copper , you send the signal, the train go fetch. Rerouting is no longer a problem because happening only if copper OR iron are ok.

This is also an option if the unloading stations are build that way so they can handle this. Although after my last thoughts it might not be necessary at all. Well, I'll see if I can get three different goods (iron ore, copper ore, stone) running with a single line without any issues, or if I've overseen something. To be honest I'm pretty certain I will stumble about something like that, but that's the typical problem any engineer has to deal with.

This is from experience how i would make general purpose train line to work around the way the game handles the rerouting. Build my system around it to exclude problems by design, segmenting networks in unit inside witch uncontrolled rerouting is not a problem rather than trying to avoid having it happening as this is difficult to do and to predict.

That's a good point and I agree here - starvation and overloading are issues which should be prevented by the inherent and robust design.

[mmmPI]

Hm, I had a second thought about the rerouting. Just to clarify - here I mean a train actually selecting another target station, not another way to the same target station.

As far as I understand with the train limit system, a train set to a specific station will stick to it, no matter if other stations with the same name open up which might be nearer. The only reason a train would abandon its target is the target station is disabled (which I won't do, I'll just change the train limit to 0, which means any trains on their way will still go there) or destroyed. The latter might not be impossible as i could get the idea to cruise around in my base with a tank or accidently fire a nuke, but is at least not a regular occurence.

mmmm maybe it need clarifications

A train can have a train stop as destination. A train stop has a name. The name of the train stop i will refer as the train station.

The train can have the same station as destination, but change the train stop. If you call your station "load" and "unload". It is possible that one train set a specific train stop for "load", say one with iron. But on his way to the train stop with iron called "load", this train has to stop at a signal to let another train pass. And when this train is stopped another train stop called "load" but this time with copper opens, making it 2 station/train-stop called "load" open. It is possible that the stopped train will switch to the "load" train stop with copper if it's closer than the original one it took as destination with iron in it.

The train will not stick to its destination if you consider the physical train stop. When rerouting/repathing, it can switch to another one. There is no way to pin a particular train to a particular train stop in vanilla. You can only give as adress a train station and the train will try to be smart and do things you don't want, this even with the limit.

For things to not go this way, you have to plan ahead many parameters that's what i wanted to say. What i described can happen if nothing is done to avoid it such as making sure your rail layout don't allow that, or that no 2 station called the same will ever open at the same time, or if does, then train are not going to possibly switch to a station with a different purpose for other reason that are not "automatic".

I have tested this myself you basically need to make sure none of the 30 reasons for which a train can repath will happen, or make sure that if it does, the repath is not a problem such as having no alternative "wrong" destination reachable.

For me "robust enough" means that any deviation does not immediately lead to a "lock down" of the factory, and that it should be a pretty rare occurence. (Although it's hard to actually measure what's rare. I don't really have a metric in mind here.)

Let's go extreme, the limit is when you take more time to fix something, than the times it takes for something to go wrong. Because then the number of things to fix increases over time forever ! before you reach this limit you go through all kinds of tedious very tedious super tedious, ultra tedious and so on

If you aim at megabasing you need to never have to fix manually something i guess , "theorical" 0 manual debug. But in practice if you have two buttons to click every 100 hours it's fine for my personnal taste.

Also do you have a blueprint of your picture ? it's hard to tell what it is even with your description

This is also an option if the unloading stations are build that way so they can handle this. Although after my last thoughts it might not be necessary at all. Well, I'll see if I can get three different goods (iron ore, copper ore, stone) running with a single line without any issues, or if I've overseen something. To be honest I'm pretty certain I will stumble about something like that, but that's the typical problem any engineer has to deal with.


starvation and overloading are issues which should be prevented by the inherent and robust design.

just to make sure there is no misunderstanding, i meant that the "rerouting problem" should be prevented by the inherent and robust design as much as possible. If you don't try general purpose train line, well it's guaranteed to not cause trouble but also misses the point. If you attempt the multipurpose train, then it should ( imo that was my advice) be as similar as when it's not the case that rerouting is potentially troublesome. Because if it's not it will happens over and over and be very annoying. My example was a train that is multipurpose but still with limits. restricted freedom to a perimeter that is small enough to not create problems that cascade to the whole network.

The opposite would be having only 1 super giant unload station that is where you have ALL your furnaces. If there is a rerouting error here, say a train full of coal unload by error, or even just get stuck because it has coal instead of iron or copper then the whole factory will be impacted. I do not recommand . It is also true when expanding, when you have one central station/brain, whenever you expand, you also modify it, and if you mess up by accident, you've damaged the only brain/central dispatcher. While autonomous units having each their dedicated squad of smart train is safer for your objectives imo. Once you got one working , you make others on a similar model, and if you mess up while trying to adapt it , you only damage one part that is not yet functionning/important.

General purpose trains are real fun i think, there are many ways to potentially tackle the problem given how complex you are ready to make your thing, i'm advocating for the easiest method i can think of