Using trains to transport resources that are getting low?

[SyncViews]

Ill have to read that fully later

"waiting zone" -> circuit signal -> "pick up" -> inventory full -> "drop off"

The thing here is you have to assume fully loading at "pick up" can be done nearly immediately, which is only going to work if the mine is producing far more than needed, and will jam when the mine depletes?

My idea was to make the "pick up" and "waiting zone" pretty much the same thing (ideally one station, else just put the waiting station a few tiles after) so that trains will wait out of the way at their loading sites, and the system can immediately know there is a full inbound train. As opposed to my normal simple solution of having a large holding area just before the drop off station (which for mega factories needs to be pretty large to avoid a traffic jam if too many trains come).

Will try and make a functional version but cant until after work. Did you have a save showing in action?

[TI-89]

The station is closed when there is not enough to fill a train, using circuit controlled rail signal. If the mine depletes, and there are no other mines of the same name, the train will sit outside the station. So it will fail in that sense, but the failure is a resource shortage, not related to the logistics. And in theory, but not in my current implementation, the station should not make stone available to logistics until the train is already loaded.

I suppose I could post the save if you're having issues, but it's not exactly "presentable" in its current state. And my ADD planning style (build first; plan later) means basically the whole factory is an OCD trigger. And this is one small piece, just an experiment essentially. I was planning to make a demo version to post here so you don't have to deal with the chaos surrounding this piece, but hadn't gotten it done yet. I should be able to post one or the other tonight though.

[SyncViews]

Still not really clear how your doing it, I put my idea into a sandbox map.

The concept is to have a circuit network that knows how much cargo is stored or inbound compared to the maximum amount it is allowed to store (in my save storage is just the unloading chests, but could be the entire logistics network for example or anything else you can count).

Depot:
The depot has a target amount of the item and subtracts from that the amount currently stored, and the amount already on inbound trains (stored in a simple memory cell). It then sends that total amount to the outposts (so a positive value is the amount of remaining storage capacity).

There is also a read mode signal just after the unload station, when it detects a train it subtracts that trains (expected) capacity from the memory cell.

Outposts:
The station is first and trains have the fully loaded condition.

Just after the station is a signal in read mode to detect the trains. When it detects a train, it sends a pulse of the trains expected capacity to the depot, which adds that to the inbound memory cell.

After that signal is a close mode signal which is red if the signal from the depot is negative (no space for the inbound amount just added).


Problems:
Any train that is not full, any train running through the station that is not stopping there, or if one of the supply trains is lost/destroyed en route will result in the memory cell having the wrong value.

Trains for a given loading and unloading station must be the same length, so the circuit can add the right cargo quantity.

With multiple outposts, when there are multiple ready trains that second signal will be closed until the depot has enough capacity to release all of them.
This problem arises because I couldn't think of a way to check the depot counter, decide if the train can proceed or not, and update it all in one atomic action, or if I do need a full/multiple ticks to do so, a practical way to have a "token" system so only one outpost can do so at a time.


The cargo quantity issue could maybe be solved by detecting how much was actually unloaded or loaded from a given train using staging chests, but really not sure about the multiple outposts one.

[TI-89]

Oh gees you're way overcomplicating it. I should just posted mine. Lemme put together a sandbox real quick, you don't wanna have to deal with my whole save, would take an hour just to figure out where the logic happens. Especially since I think you'd keep looking for more circuits

[TI-89]

Alright, here it is. There are still some goofy things in how I did the logic*; I do not guarantee that it will never malfunction. But most of my design goals center around resilience rather than absolute perfection (edit2: this mostly comes from basing robonetwork design on analogies with the Internet -- https://en.wikipedia.org/wiki/Best-effort_delivery). Because shit happens, and something will always go wrong. If the system is not fault tolerant, everything comes crashing down.

I thought of another buzzword to help things sound more confusing: https://en.wikipedia.org/wiki/Separation_of_concerns. Basically I just split the logic into mutually independent parts, rather than trying to track things like resources_in_transit. The secret is: none of it matters. If there's a request to send a train and there's no train, nothing happens. If there's a request and the train is not full, nothing happens. There can even be a second request seconds after the train leaves; still nothing. Or my robot can get eaten by biters while in transit, another will simply be sent.

The mine will provide iron so long as there's enough for a train, and the requester will request so long as its amount is below the threshold. The train schedule takes care of only leaving when full.

The only absolute failure I've had in my game occurred when biters broke through my walls and killed all the bots in my sorting station (I was afk). I've had things slow to a crawl due to extreme surplus of one resource, but (thus far) there have been no deadlocks. Again, I haven't worked out scaling this, I suspect there are conditions under which it will fail. But the only one I can think of offhand is if one of the networks runs out of robots.

*in particular the mine just provides iron if there is enough to fill a train, it has no idea whether or not a train is in the station or already on the way or if it even exists. EDIT: just occurred to me, this will not work for multiple stations because the closest one will always fill the chest and be grabbed first. Though it will still choose a further station once the mine depletes, and stops providing iron. So could be a desirable behavior in some cases I suppose. To fix I'll have to either work out train detection; my thoughts are either from signals or from inserters actually loading the train. I suspect there are similar issues with managing multiple trains.
p.s. I think I still have some mods enabled on the save, but nothing should be critical to function

[SyncViews]

Will load up after work, but Im still not sure how you effectively scale that to multiple trains. That was most of the complexity for me.

• For cargo like copper and iron, for large factories and distant resources, it needs to be possible to have multiple in transit trains.
• When you have space to unload one train, you dont want to accidentally send 10 trains if they were already waiting, because they might not be able to unload, and maybe even block the line.

[Deadly-Bagel]

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?

Yes, sorry, I meant run cable along the tracks. And it depends on how you run your rails, I use a Personal Roboport and a pair of blueprints for a straight rail and an intersection so for me it only affects the process until I get robots. It's much faster and accurate this way, especially for two-way rails, than laying the tracks and signals manually.

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.

Each stack of Big Power Poles cover 1,500 tiles. It's nothing compared to the number of rail stacks you need. I've only ever had problems with power poles directly outside of outposts, and as biters always follow the same path you can just move the affected pole and be confident that area won't have problems again. I find this preferable to having a ton of solar panels at each outpost that may not be used much of the time. I do understand though that over long distances the cost between the poles and the panels/accus is comparable so then it's just space requirement and as RSO spaces everything out it's just down to preference, though I'm curious how that works with turrets. Do you have to use Gun Turrets and ship ammo over?

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

With RSO this is a more viable option as you'll have more room for the holding area. It does however mean you have much more area to defend, letting biters gnaw through all those full wagons would be pretty devastating, and expansion could be somewhat difficult if you find your initial estimates were not enough.

[TI-89]

Will load up after work, but Im still not sure how you effectively scale that to multiple trains. That was most of the complexity for me.

Yeah I mean you tried to do a lot more than what I've finished so far, but I think it should scale fine if for multiples if you replace the goofy ass logic I used. As I said all I've used it for so far is infrequently used resources like stone. So only having one train assigned to the station, and only having one station, makes most of it a non-issue.

But I think it should work as I described before, just not as I've implemented. Don't think it'll take more than a few combinators though. Biggest changes are:

• Resource should be provided only once train is available to send. Simplest way would be check that signal is red, probably need an S/R to say "had enough resources" then signal turned red. But false positives won't break anything, just cause some extra delay in getting your train (if train is requested and there is no train, mine will simply provide resource again -- you just have to wait for the resource to be delivered by logistics before another will be requested).
• Stack size needs to be dealt with in some way. If you noticed in the sandbox, bot placed four iron, inserter took three. Then the leftover would be provided regardless of train availability. Again, ignoring this issue will I think not break the system, just cause another request to be wasted.
  One thing I'm not sure of, is that if I send a request for one iron, I'm fairly certain it counts as a request for 4 because of the way bot logic works (always try to grab full stack size)*. However, I think the only effect this would have is that if there is truly only one of the resource, you will see a negative value. I don't think it would ever deploy more than one bot though, which would potentially cause multiple trains instead of one. But then what if I request two, and there are two chests with one each? I think it would deploy one bot, wait until pick up, at which point the bot only gets one resource, then deploy a second bot. Or would it know that the first bot will get only one and deploy two immediately? Again, shouldn't be too difficult to work around, will just take some testing.

There's probably more. I haven't found a need for requesting things like iron and copper, because they're always being used in large quantities. So I haven't worked much on scaling this yet; been working on setting up some large scale manufacturing. Once I've overloaded my train network, I will probably get back to dynamic requests again. But there's no fundamental reason it wouldn't work. Biggest limitation is you can't request a resource to more than one place, because the lognet doesn't know where things come from. Might be possible but would take some careful routing of requests so that you can differentiate based on which chest is taken from.

But basically, if you try to scale this, just remember message passing. If a resource is taken from the provider connected to the mine, the message is "yo send me some [resource]." By using logistics request to signify a request for a train, you can keep the complex logic within each network. Then they talk to each other by providing/requesting a resource.

If I have time I'm planning to try to add multiple providers to the sandbox map, I'll share if I accomplish anything. But I'm not great with circuit logic yet, trying to figure out some infrastructure atm.

* best way to see this in action is have a network where something is put into an active provider, then moved to storage by bots. Even if there are no requesters in the network, you will see a negative value when the bot picks up from the provider.

[SyncViews]

Yeah both bots and inserters seem to like picking up more than the destination wants. Not sure if you can control that.


Also am thinking for a larger network bots beung fairly slow and trying to take a direct route (away from roboports or over biters) will be a problem. At least with a circuit wire transmision is fast. Maybe there is a simpler/better way with a circuit wird between.

[TI-89]

Yes that has occurred to me as well. The delay can be minimized quite a bit, as the train leaves at pick up, not delivery. If you keep robots near the pick up point it's almost instant.
But I think there should be a balance between the two uses. For example have a train Depot near your perimeter wall linked by logistics, which runs circuit wire to outposts. This way you can have a Depot in each direction, and pass info about resources available at outposts to it. Then bots will decide which one to go to based on what's shown as available. This way you don't have to set up the system from scratch again every time a mine dies. But again, I'm not quite there yet.