Using trains to transport resources that are getting low?

[obuw]

The changes to trains in the last few patches have made them pretty useful and I have started using them a lot more often, especially when playing with RSO. However, there is one problem; I don't know how to automate the process of altering a train's schedule based on how much resources you have in stock.

For instance, I'd like the train to only go to the iron mine when I'm low on iron, and only go for copper when I'm low on copper, etc. I guess this is not possible with a single train, and I need a separate train for each resource? Then I need to "park" them somewhere in the base after unloading their contents, and wait for a signal from the logistics network to tell it to start moving again? (Is that even possible without connecting every single chest to a circuit network?)

Either way, this is rather problematic when playing with mods since you have a lot more than 4 resources to transport around. I'd have to build a gigantic train station to accomodate 20+ resources being brought in by trains, and then a chain signal nightmare to make sure they don't crash into each other. (I still have no idea how those work, and the tutorials are pretty confusing).

So what are some of the clever solutions you guys have come up with when it comes to automated transportation?

My usual setup is a single train, a bunch of stations, wait until full or 5 seconds of inactivity, then return to base and wait until empty, repeat. If I'm not lazy about it I connect the train stop and the chest feeding the wagon together with a circuit cable, and set the train to also head back to base if the chest contents is below 10. (Is there an easier way to do this?)

I also wouldn't be averse to installing a mod that helps with these problems, if you have any suggestions.

[steinio]

This awesome mod does it for you: https://mods.factorio.com/mods/Optera/L ... ainNetwork

[Yoyobuae]

Then I need to "park" them somewhere in the base after unloading their contents, and wait for a signal from the logistics network to tell it to start moving again? (Is that even possible without connecting every single chest to a circuit network?)

Connect a roboport to circuit network to read the entire contents of the logistics network.

[Bushdoctor]

Keep in mind that connecting a roboport to the circuit network requires you to use appropriate chests for storage. Chests that can be read by the logistics network.
It could work very well though.

It looks like that mod does the things you need, but if you want to do it manually you were definitely on the right track.
You connect one or more chests to the circuit network to read their contents (I usually pick a single 'representative' chest), and you connect that wire to the Waiting Station of the train. Not the delivery station.

You program your train to pick up a full load or ores and then go to its designated waiting station. Each resource gets its own waiting station. One for copper, one for iron, etc.
You want to design that waiting station so that more than one train can fit there and park behind the one that's actually at the train stop. (Use regular signals for that).
When the chest drops below a certain amount, the first train will get into action to deliver its goods and repeat the cycle.
The second train will probably also be triggered to start its delivery unless you force it to wait X amount of seconds so that the first train can make its delivery and fills up your chests.
That way you can work with a single delivery station if you want, and have multiple trains waiting to be triggered to drop their goods there.

The whole signal thing is quite easy when you get the hang of them.
A regular signal will look at the section ahead and block access if there's a train in that section.
A chain signal will look at the Signal ahead and basically copy its state.

It is good practice to use a chain signal in front of a junction and a regular signal after that junction.
This prevents your trains from standing still on junctions, blocking others.

Hope that helped.

[reallyLost]

Then I need to "park" them somewhere in the base after unloading their contents

The simple answer is to "park" them at the unloading station with a condition to stay until they are empty. As long as you don't need that resource then the station should be backed up and they can't unload. When they can unload it means that you do need that resource so that's when you want them to go collect more.

[obuw]

@Bushdoctor I usually put active provider chests at the unloading station, and store the contents in storage chests, so I think just connecting the roboport could work pretty well.

I think I'm getting a more clear picture now of how it can be done. However, I still find it very much not worth it to set up a separate waiting station for 20+ different resources. I think I'll just keep doing it manually, and maybe look into that logistic trains mod. The vanilla system clearly isn't meant to be used with more than a handful of resources.

@reallyLost A separate unloading station for each resource? That's even worse! I may as well just use conveyors at that stage, would probably be more efficient.

[TI-89]

This can be done using vanilla logistics. Or at least kind of; I'm trying to figure it out still. The biggest limitation, as you've noted, is that you need a separate train line for each resource. I use same name stations for mines, so I can adjust how many trains I have going to all iron/copper mines simply (these are my 'train lines').
The plan is to automatically dynamically scale with demand, but I'm not quite there yet. So far all I've done is stone, as I currently find iron and copper supply bottleneck my production and there's no real need. Or at least not until I scale significantly larger. And I think 0.15 allows circuit setting of train schedule, which will make things much easier. Without this I haven't figured out a way to avoid separate waiting depots for each resource.

Oh, I'm also experimenting with global logistics networks, which is why I do it this way, but you can do it with just two networks if you connect them by circuit wire. Or with no roboport network if you also wire up all yours chests manually.
Anyway here's what I did:

1) At my sorting station (or wherever you're keeping these resources) I have a dedicated logistics network. One tile off from this is my "Main Bus" lognet. Here is the interface between them:
Basically, if you want more stone, request one piece.

2) At the stone mine lognet, I request one stone per trainfull that is available in storage**, and insert (one at a time) into passive provider in Bus* lognet. If it gets picked up, send train to unloading. When empty the train will return to the mine, fill, and wait for signal. Pic:

* BONUS) This is not actually my main Bus network, but a separated one. Each perimeter wall I have also gets a dedicated network, and so the request has to be routed through. Fortunately this is also fairly straightforward:
Basically: place item in chest only if there's not one already there. I'm pretty sure this caused some extra trains to be sent during my initial set up, but a surplus of stone is a non-issue at my sorting station (at least in quantities of a few L-CC-L trains)

This is essentially how you would route the request through non-lognet zones as well: put a chest at the end of your network, connect it to circuit network, and run wire wherever you need it to go.

** - this doesn't really work correctly, and my combinator design is unnecessarily complicated I think. But the train requesting works.

[obuw]

~snip~

While impressive, I don't see why all this is necessary, what does it actually accomplish? If you're still going to have separate train lines for each resource, then you may as well just store them in the station and have the train go retrieve more when its wagon is empty?

[Bushdoctor]

If you're still going to have separate train lines for each resource, then you may as well just store them in the station and have the train go retrieve more when its wagon is empty?

That is indeed how most people play the game. Especially once production expands and increases, the furnaces keep demanding more ores and there won't be a lot of situations where you want to stop your trains from hauling.

[TI-89]

While impressive, I don't see why all this is necessary, what does it actually accomplish? If you're still going to have separate train lines for each resource, then you may as well just store them in the station and have the train go retrieve more when its wagon is empty?

None of this is necessary. But if we've decided that this game should only have those features which are necessary to achieve the end goal, there are going to be a lot of cool things taken out.

As I said, my goal was to not have a dedicated line for each resource. Or rather, have a set of trains at a train depot which are capable of being assigned to either line. This way the number of trains out and about in the train network can be controlled and avoid congestion, but will scale up to meet peak demand. Also, with my current solution trains are a bit unpredictable -- I'd rather avoid trains running out of fuel by circling between two stations which do not have a need for a train. With circuit addressable train logic though I can send trains out from depot only when there is at least one station ready to have ore picked up -- this scales much more nicely because it's possible to avoid micromanaging stations for each mine. Instead you have to manage the number of physical trains which are available to be assigned to each virtual 'train line'. In addition, poorly located depots will lead to long delay and unnecessary rail congestion, leading to more interesting optimization problems.

Again, the game doesn't require any of this be done. But I'm working on this as part of my (currently very early stage) mega base; the main goal of which is to show how the tools the game makes available are far more powerful than required by the problems it asks the player to solve. If this is primarily a sandbox game, this is not an issue. But many of the choices the player faces (in particular, train car optimization - # of cars vs engines, etc) simply do not matter until you have reached a scale far beyond what most players achieve. I don't think that scale in itself should be a goal of the game, rather the goal of designing game mechanics should be to maximize the meaningful choices available to the player in terms of the trade offs between different modes of transport. In particular I want to show how ore can efficiently be gathered with small trains, brought to local smeltery, and transported to main manufacturing centers with larger trains. Ore trains are L-CC-L for flexibility and dynamism with respect to gathering from mines, then plate trains can be (I'm not this far, I've had the game for like 3 months) LL-CCCC or longer. Different resources flow at differing speeds, but it doesn't matter how you move things that much until you attempt to in quantities much larger than those required for a single rocket.

As far as what I've used this for, my current base is at almost 1000 hours (mostly afk -- hard to find rare failures without a long running game). I've consumed 155M iron ore, 86M copper ore, and 7M stone. Of the stone, I think most has been decentralized production of walls and some landfill. All it's used for on main bus (which this system fills) is walls (less and less as I produce locally), train tracks, and furnaces. While I've set up probably two dozen mines for each iron and copper (I do a lot of mixing and sorting so hard to say precisely) this is still my initial stone mine. When it finally runs dry I can put a new one, wherever I'd like to, and use the same system, so long as I properly route the request.

[obuw]

Oh don't get me wrong, I'm not questioning why you are doing something complicated, this is a sandbox game after all, overcomplication is the goal of the game.

I was just trying to figure out a "tldr" of what your setup accomplishes (compared to a one-stop-per-train setup). I think my wording was a bit off.



Edit: Okay, I've messed around with trains for quite a bit yesterday and decided to go make a train hub to figure out how it can be done. Here's what I've got:

http://imgur.com/a/O32m1

Got it a lot more compact than I originally imagined. Works pretty well so far!

[TI-89]

Yeah that's much more compact than I had imagined as well. Short trains, but as I said I only want to do four cars so not all that much bigger.

And sorry, I'm really good at walls of text.

Basically it allows precise control of resource flow from all mines to which you connect the logistics signal. In vanilla you don't need this too much, like I said I found it useful in place of storing large quantities of stone. Then train sat at the station until requested again. But in e.g. Bob's, there are a higher number of resources required in varying quantities.

Although actually it isn't that precise. But it kinda abstracts the logistic request into a message passing system between separate logistics networks, so I guess I think it's interesting for that reason too. One of the other things I'd like to use it for, though I'm not sure how to accomplish it yet, is sharing of things like repair packs and ammunition between my defense networks. Each would advertise it's supply and load or unload from a circling train according to other messages. I try to make resilience a design goal as well, so if production were shut down one wall wouldn't die while the other stockpiled supplies. Basically the possibilities are endless, but I don't know of many that the game really justifies using at this point.

[SyncViews]

Personally in my own games I have either tended to just let the trains look pointlessly if need be (have a condition to not wait at the unload more then say 30 seconds), since even if too many trains arrive at the unload, it keeps the system moving and from locking up (be sure to design the tracks such that a waiting train cant block a leaving train).

Or I have the condition to wait until fully unloaded, then put a suitable holding area just before the unload station(s) so that if the unload station already has a train, they wait in that holding area. This solution, like that circuit solution previosuly mentioned requires that the holding area is large enough to hold all the trains for that unload station, else they may back up onto a main line, and because of the wait until unloaded condition, stay there a long time.

Both of these should work for any train length, although you have to be careful if you mix train lengths for a single unload in the design of the holding area, so that you cant have a long train try to wait behind a short train and end up blocking the line.


For trains with a single pickup location (generally for me ore and supply trains distributing repair packs, etc. but not oil, since oil output falls so low once train can visit many oil fields and not be full) there is also the wait until fully loaded conditions, meaning that incoming trains will always be fully loaded, and helping to reduce congestion. It also means when the ore field runs dry the train will stay parked there until retasked instead of running around empty.


A more advanced idea I have not got round to trying and not sure on the viability, is to route a circuit from the unload station to the loading station, then prevent a train from even leaving the loading station if the unload station is not ready to fully unload the train. Other than the need to run all those circuit wires, the main problem to figure out is how to deal with multiple trains/loading stations serving a single unload. e.g. its no good if as soon as there is unload capacity for just 1 train it signals 10 delivery trains to come, since then 9 of them cant unload. The other consideration is with long lines and mega bases for common goods like iron and copper, is many wagon loads may be consumed in the time it simply takes the train to travel.

...is sharing of things like repair packs and ammunition between my defense networks...

For things like repair packs (and replacement turrets and other stuff biters like destroying) the best solution I really came up with is a supply train (filter the wagon slots so each wagon can carry many different items in desired quantities) that fills up with all such items at the manufacturing center, then visits each each other logistic zone (the unloading stations keep passive provider chests stocked with specific items and quantities via filter inserters) in some order with a "wait for inactivity" condition at each unload stop. Unfortunately in practice this means the train spends a lot of time visiting outposts to unload pretty much nothing, while taking a long time to get around all of them.

I'd rather avoid trains running out of fuel by circling between two stations which do not have a need for a train.

I assume from the train not waiting long enough at the station providing fuel? Should be a simple matter of adding an extra minimum wait condition to that station (I generally assume there is coal available to load, since trains use it so slowly that stuff like plastic breaks a long time before).

As I said, my goal was to not have a dedicated line for each resource.

Really don't think that is possible in the base game, there are some mods that can help with that a bit but not personally tried them. For ore generally a mine produces more than enough to justify dedicated trains, so the main nice to have for me would just be auto tasking trains when a mine depletes or I build a new one which is simple enough. Simple mods can also deal with optimising oil trains so a single oil train can service many oil fields without simply looping through them all.

Keeping outposts supplied with the large number of items required (repair packs, ammo, replacement walls, turrets, gates, anything else biters might kill) is a lot harder. Ive considered it in nearly every play through, but coming from a software developers point of view generally ended up with something more complex than is feasible in game (like how to have a single supply train, pickups and drop offs for dozens of different items and dynamically route the trains to fullfill such demands).

[Deadly-Bagel]

Why not hold the trains at their outposts? Yes you'll need to run them all along your existing rail network but once you add it to the blueprint it doesn't change anything (doesn't even consume wire when placed via blueprint).

I did this in a Bob's Mods game with a sorted unloading bay, was very tidy. Had a system that when an ore fell below a threshold it sent that ore as a signal across the network which would trigger any trains picking up that ore.

[TI-89]

A more advanced idea I have not got round to trying and not sure on the viability, is to route a circuit from the unload station to the loading station, then prevent a train from even leaving the loading station if the unload station is not ready to fully unload the train. Other than the need to run all those circuit wires, the main problem to figure out is how to deal with multiple trains/loading stations serving a single unload. e.g. its no good if as soon as there is unload capacity for just 1 train it signals 10 delivery trains to come, since then 9 of them cant unload. The other consideration is with long lines and mega bases for common goods like iron and copper, is many wagon loads may be consumed in the time it simply takes the train to travel.

This is precisely the problem that my train requests solve. Basically exploits the difference between circuit and lognet (point to point vs broadcast) to get the bots to select which train runs 'invisibly'. Also basically sets things up as collaboration between autonomous agents. I can change local logic however I want/need to; placement of stone into a 'bus' lognet serves as an advertisement of a train that's ready to send. Though as I said mine doesn't quite work properly, for stone it's fine because it's so infrequently requested, but for more in demand resources my current implementation would break.

But basically, all mines for a particular resource have the same name (e.g. 'stone'). I also wire up the chests and use circuit network to close the signal leading into the station until there is enough resources to fill a train (all of my trains have two cargo wagons, but adjusting just a matter of changing signal condition -- also train car size is invisible to request system). Currently my system advertises availability based on amount in chests but this logic is faulty. My plan is to also read signal and advertise once signal turns red (with maybe a delay to ensure train has time to fill). But the train for stone will go to stone station, fill, and sit there until sorting requests stone.

A request is detected when a bot picks up the stone placed to advertise train availability. This has a few implications: request propagation has the potential to be almost instantaneous, but things like routing through a subnet as I have done incur a penalty. In addition, it doesn't matter how many stations I have advertising that particular research, the number of trains requested is controlled by the request size at the sorter. Because I request one stone, there will only be one logistics pick up, thus only one train will be sent. Now, although the request gets to the train very quickly, it can take some time for the stone to get back to sorting through logistic network. But no more requests will be sent until that stone is delivered. Only after that request is filled will sorting compare to the threshold again and possibly request another train.

The number of trains which can be in transit is (fairly) precisely controlled by the request size at the receiving station. Honestly I'm not sure how fine grained of control is possible. With an average consumption of ~100 stone/min, 20k is a fairly large buffer. Each request brings 4k, which takes 40min to be used. Sorting system could easily handle a surplus of even 100 times my threshold of 20k, so really I just wanted 'enough' stone to be delivered, without having to keep an eye on my stockpile all the time.

But with current system I could set up 20 stone mines, all serviced by 1 train car, and essentially never have to worry ab stone again. The train will go to the nearest reachable station, and the logistics system will grab the nearest available stone. When a mine dies it will just stop opening signal and life will go on; eventually I'll notice and tear it down. Also note that trashed stone floating around will interfere with message passing. Again this is a non-issue for my form of approximate control. Even requesting one delivery at a time, logistics seems to drain surplus stone long before my buffer is exhausted. Eventually the stone at the mine will be the closest available in the system, and a train will be sent.

[obuw]

Why not hold the trains at their outposts? Yes you'll need to run them all along your existing rail network but once you add it to the blueprint it doesn't change anything (doesn't even consume wire when placed via blueprint).

I did this in a Bob's Mods game with a sorted unloading bay, was very tidy. Had a system that when an ore fell below a threshold it sent that ore as a signal across the network which would trigger any trains picking up that ore.

You mean run red cable all the way across the map to the mining outposts? That's crazy!

Didn't notice that it doesn't consume wires when placed via blueprint. But either way it would make rail laying a much slower process, which is otherwise just point and click thanks to the new rail placement system in the game. Or maybe there is a quick rail placement method I don't know of involving blueprints?

Also, don't you need like a billion poles to carry along the signal then? Or do you use something else to connect the cables? Oh wait, you can actually connect the cables to the rails themselves, right? Because I don't use poles to carry around electricity to my outposts, as biters keep tearing them down. Each of my outposts has their own solars+accumulator setup.

Either way I quite like my setup now. Each train fills up in advance, and then comes to their holding station waiting for the system to run below 10k of their resource. Then they go to the unloading area, empty their inventory, then go to their mining station, fill back up, and come back to their holding station. Working like clockwork. But making the trains wait in their mining outposts is also an intriguing option if there is an easy way to carry a network signal across vast distances (I usually play with RSO and all ore rarities set to very low, because I hate myself.)

[TI-89]

You mean run red cable all the way across the map to the mining outposts? That's crazy!

As I said I'm playing with some pretty hardcore logistics coverage. But I'm working on semi automated expansion essentially by having robots lay my "highways" (two one way rails with roboports in between tracks, surrounded by walls and filled with turrets. The idea is somewhat strategic expansion based on landscape features. I place highway where there's room for a long straight stretch. When I need to expand I find a place with the resources that I need that I can wall off with minimum possible effort (aka narrow gaps between large lakes). Clear nests with flamethrower, then run back to defenses and watch the biter waves break against my walls. Then place a train stop, name it to one of my existing lines, and connect mines. Eventually I plan to split off dedicated resource handling but right now I can mix anything at loading station because it all gets sorted.

I've been expanding logistics pretty extensively, trying to push the system to its limits (they are well beyond what had been deemed its 'valid' use cases). But the thought is that the train line networks can be used to route the request, and you can link up to it however you see fit. If you want to have fully global logistics, it's easy. But you could also just connect the mine to the station with wire, or even a transport belt linked to a provider inside the train network.
What I've been building is a proof of concept, and is really very rudimentary. But the concept itself is extremely versatile, offering customized management of hugely separated outposts for a bit of infrastructure cost. Tweaks to the balancing of roboports could make this cheaper to achieve in essence, but much more difficult to use to the extent that I have done. I think I could also achieve the same thing with much less investment, but I'll have to start over to find out, and I'm just not ready to do that yet. I still haven't really worked out a blueprint system, there's a lot to learn about this game.

[SyncViews]

This is precisely the problem that my train requests solve. Basically exploits the difference between circuit and lognet (point to point vs broadcast) to get the bots to select which train runs 'invisibly'. Also basically sets things up as collaboration between autonomous agents. I can change local logic however I want/need to; placement of stone into a 'bus' lognet serves as an advertisement of a train that's ready to send. Though as I said mine doesn't quite work properly, for stone it's fine because it's so infrequently requested, but for more in demand resources my current implementation would break.

Using just vanilla game? You got a diagram of how exactly you set that up so can scale?

A counter of incoming trains (using either circuit or an item in a logistics network) could work for many trains actually thinking about it (trains still need a fixed route with 1 load and 1 unload station, and should wait until fully loaded since AFAIK lognet/circuit cant detect the actual contents of wagons). But then you still need some logic to stop 2 trains coming at the exact same time.
The condition being something like:

Code: Select all

if train_capacity < target_stored_quantity - current_stored_quantity - inbound_train_capacity

Which can be done with circuits, but then when decide thats true and should send a train, how to ensure only 1 train leaves the outpost before the inbound_train_capacity updates (potentially making the check false).

Differing train sizes is possible, if a given loading station always serves trains of the same length (so can check and update the counter appropriately for actual capacity).

Within the limits of the circuit system, I also don't think can avoid it breaking the "state" if a train is lost in transit somehow.


This should work for stone, coal, ore, and other bulk items (maybe taking from a smelting factory to an assembly plant or such on large distributed setups?), but still isnt an improvement over what I described doing in practice for oil or supply distribution (assuming you want less than 1 train per station that sits mostly idle). Would still love a way to deal with those better in Vanilla, but cant see even a partial solution (while a complete solution would almost certainly need some new modding, which is tempting but not got time right now).

[TI-89]

Yes, using just vanilla. Or essentially vanilla; a few helper mods.
The secret is to not reason about the trains directly. This is what I mean when I say it's set up as autonomous agents (https://en.wikipedia.org/wiki/Agent-based_model) passing messages (https://en.wikipedia.org/wiki/Message_passing). I apologize if jargon ever makes me hard to understand, I only use these words because I don't know how else to say it concisely.
It's essentially just an abstraction that allows me to request resources without respect for how they are actually transported. Circuit logic is used locally, to control what is placed in the logistics network, and how to respond when an item is picked up.
I haven't really worked out scaling yet, the hardest problem is knowing where to send the resources once they've been requested. I haven't worked out a way to do it that doesn't involve central sorting. But that essentially goes with my 'train lines' concept. What I'm working towards is it not mattering where it's sent. Trains are all scheduled "waiting zone" -> circuit signal -> "pick up" -> inventory full -> "drop off". Waiting zones would be where trains will stack, circuit signal would release trains when a pick up is requested. Drop off stations only open when they need resources. But this would be non-deterministic in which train ends up in which drop off... And that's where my solution is at for the whole thing. I think some of this might be possible in 0.15 depending of what kind of extra circuit control of trains there is. Maybe something like unload with filter inserters, go to next drop off if nothing is removed from train? This would also help with things like ammo supply lines, to have a train circle until below some threshold, then look for a refill station.

As far as requesting a single resource, things are much easier. I have one train which goes to stone station -> circuit signal -> drop-off for sorting. Circuit only releases train when stone is removed from the provider chest. Sorting only requests one piece of stone at a time, so another will not get picked up until the first is delivered. Given how my sorting system works, it's entirely possible that a second train could be requested while the stone from the first is on it's way. But this is good enough for my current purposes. There are certainly workarounds for scaling, I just haven't gotten quite that far yet. Some of my thoughts include having only one provider per resource type, and dedicated lognets for routing requests from differing stations/zones, possibly combined with running cable to route through one thing or another. I'm trying to come up with something relatively simple though, that doesn't require separate networks just for message passing, but works around the noise in the main network. There's also a lot that could be done to reduce this noise as far as how I move things through my networks.

[TI-89]

Diagram would be something like this I guess? http://i.imgur.com/38MV9kO.jpg
That's essentially how mine works, though the bus ins't all one network. But the request can propagate through the other networks (this does incur a bit of delay). Like I said I've just got the one mine as a provider at the moment, but because logistics will grab the nearest one available, the same idea works with an arbitrary number of stations. It just might take some tweaking to get all the way there.
It supports any number of train sizes as well, because the logistics system doesn't know or care about where the train is going. It just delivers its one piece of stone. The logic is all encapsulated within the mine/train system. So I can have train station names according to the train lengths, but all the circuit network has to know is 1) is there enough resource to fill the train that will come here (if so open signal) then 2) if the train is here (allow time for it to fill and then) advertise that a train is ready by providing one stone, and 3) if the stone has been picked up for delivery, send the train.
Like the whole logistics network, it's easy to break if mismanaged. But once set up correctly, it operates consistently and is resilient to failures (like when my train system deadlocks). You might get a few more resources than you requested sometimes, but by not attempting to control individual resources it allows a margin for error. And things will always go wrong.