Page 1 of 1

railroad best practices: about long latencies and waiting areas.

Posted: Fri Jul 02, 2021 5:14 pm
by Laie
The last time around, I built my stations with waiting areas: Typically three slots for every ore unloading station.

This still worked until my inner tier of mines was depleted and the trains had to travel longer distances (average perhaps 3000m by the game's reckoning, which doesn't strike me as all that far). Empty stations became a common sight, with the new shipment arriving just in the nick of time. So, things still worked, mind you, and given that there were zero interruptions I have a suspicion that it may not even have been as tight as it seemed: perhaps the game is doing some really smart scheduling. But anyway: trains arriving at the very last moment looks scary, and I wonder what I can do to avoid it the next time around.

The core problem is that the maximum train limit on a station is coupled to the amount of space and track I designated as waiting area. If I set the train limit higher than what the waiting area can hold, trains will back up outside the station. Allowing for more space will only postpone the problem.

The next best solution I can think of is external waiting areas, eg on the approaches from the mines to the factory proper. I'm not sure if that would really work, though, I can as well imagine it to cause problems of it's own. Besides, I don't have a well-defined factory / outskirts boundary.

Re-loading stations would be the same idea, taken one step further: I come up with a new class of train for long-distance ore transfer, and somewhere near the factory the stuff gets unloaded into the short-distance trains that travel within the factory. I actually like that concept, if only it wouldn't add a lot of inserters... it's an obvious UPS brake.

What can I do? What do *you* do?

Re: railroad best practices: about long latencies and waiting areas.

Posted: Fri Jul 02, 2021 7:54 pm
by astroshak
It depends. Sometimes I build smelters there at the production outposts, other times I build centralized smelting and then train the plate to other outposts.

Either way, it helps to have more bays in the stacker than you think you are going to need, just so you can add more trains to each station. Also, you do not need to build the extra stacker bays initially; just having room and including their construction as part of expanding train service for those stations works as well.

The other alternative is larger trains. If a 2-4 train works well, a 4-8 train would carry twice the ore at no cost in train speed. You would just have to set up the mines to accommodate such larger trains, which when they get real long can be a challenge in and of itself (if 1:2 is the optimal ratio for L to C, take this to the extreme you could have a 50-100 train, but how would you load and unload the thing, and what kind of fuel production center would you need to run a fleet of such trains?)

I’ve been toying with 4-8 trains of late; sooner or later I may double that again to 8-16. I would have to redesign my rail BP’s for trains of such length, one reason I’ve not gone ahead and done so yet.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Fri Jul 02, 2021 10:27 pm
by Laie
astroshak wrote: Fri Jul 02, 2021 7:54 pm It depends. Sometimes I build smelters there at the production outposts, other times I build centralized smelting and then train the plate to other outposts.
...that alone would essentially be a re-loading station. I don't think I'm desperate enough to consider that option yet, as that involves a lot of unloading and re-packing for little actual work in between.

Just planning with more stacker bays would be a alright if I knew just how many trains I'm going to need in the end. It appears that the number is only ever going to go up, though, with no end in sight. *sighs* Well, it doesn't need to last forever, only long enough until I abandon the game for some different reason.
astroshak wrote: Fri Jul 02, 2021 7:54 pm if 1:2 is the optimal ratio for L to C
is it, though? That piques my interest. Using nuclear fuel, 1-8 didn't feel sluggish. I went with 2-8 mostly because why not? I can afford it, and yes, acceleration is notably better than 1-8. But all game long I've been wondering whether that was really a good idea. Which is a long-winded way of saying that I think a 1:2 ratio is quite excessive. The again, I'm assuming nuclear fuel as a matter of course, which it probably isn't.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 3:50 am
by astroshak
I remember reading here a few years ago that it is indeed the optimal ratio of Locomotives to Cargo Wagons. You should be able to find it if you really want to; though a very quick search for the words “optimal” and “train” came back with 19 pages and I admit to not looking through more than the first couple.

I do not remember seeing anything in patch notes since then suggesting that it has changed, either. It has to do with the weight of the Locomotive compared to the weight of the Cargo Wagon.

That said, 1-4 is not bad; and you likely won’t notice much difference between it and a 2-4, or a 1-3. I don’t think I’d suggest using a 1-8 or lower L:C ratio though.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 1:20 pm
by Amarula
What if you turn the depleted mining stations into intermediate parking stackers? This allows you to add enough extra trains to keep the destination busy, but instead of making parking space at the destination, it is replacing space that you no longer need for the mines. It doesn't require you to know how much space you are going to need in advance, and theoretically is infinitely expandable...

For example, in the beginning three trains go from mine #1 to destination; when mine #1 is depleted and you set up mine #42, six trains from mine #42 go first to DPM1 (depleted mine #1), where three can wait until there is room, and then to destination; when mine #42 is depleted, nine trains from mine #98 go to DPM42 where three can wait, and then to DPM1 where three more can wait, and then to destination...

Edit: oh and you don't have to build every train schedule from scratch! You just copy the previous train schedule, and add one stop...

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 1:45 pm
by Laie
astroshak wrote: Sat Jul 03, 2021 3:50 am a very quick search for the words “optimal” and “train” came back with 19 pages
I tried aunt google and ended up with a reddit post where someone had set up an obstacle course, basically a round trip with five stops, and measured how long it took different trains to complete the course: https://www.reddit.com/r/factorio/comme ... e/dhnjkq1/

That chart is a bit dated, though. I've taken some measurements myself:
Start | 450m | 900m | 100m | 900m | 600m | 150m | Finish - total round-trip distance 3100

I always had a locomotive up front; for trains with two locos, whether I added it to the front, rear, or somewhere in between did not make the slightest difference.

First round, using all five stops: (too lazy to figure out how tables work around here, so plaintext):

Code: Select all

Train     Rocket Fuel     Nuclear
1         54              51
2-4       63              58
1-2       65              59
1-4       77              66
2-8       73              65
1-8       99              81
2-16       -              79
3-16       -              69
Notice how longer trains perform better than short ones with the same L:C ratio. Air resistance I guess?

Then I tried skipping stop#4, same round-trip but one stop less and the longest un-stopped distance now 1500m:

Code: Select all

Train     Rocket Fuel     Nuclear
1         51              48
2-4       58              54
2-8       66              59
1-8       88              73
2-16       -              71
3-16       -              63
and just for the heck of it, 3100m without any stops:

Code: Select all

Train     Rocket Fuel     Nuclear
1         40              39
2-8       43              42              
1-8       51              45
Well the long and the short of it is that stopping a train is really costly. Just compare the round-trip times with one stop more or less. Also keep in mind that my stops were merely touch-and-go, I did not have to wait for another train to clear the junction first -- which is also bound to take longer if trains are slower. So all in all, while I believe that 1-8 may turn out to be fully sufficient, perhaps even faster than 1-4 due to less congestion, I'm not actually willing to commit to that scheme. Adding another loco just to be sure is much preferable to ending up short.

--

That said. With these numbers in hand, I can also think better about my original problem. My fastest unloaders drain a train at a rate of four blue belts, that's puh, less than 90 seconds to empty 8 cars. As I can see from the numbers above, if the mine is 3km away, that will about suffice for the round-trip time under ideal conditions. Loading takes 18 seconds (I only have 4 inserters per car), every unscheduled stop takes at least 6 seconds... yeah, i see how three trains per unloader was getting tight.

Amarula wrote: Sat Jul 03, 2021 1:20 pm Edit: oh and you don't have to build every train schedule from scratch! You just copy the previous train schedule, and add one stop...
But I still have to apply that schedule to every single train, and make sure that i don't miss one. It also doesn't seem to be something I could stick into the schedule right from the beginning... except perhaps I can? Might be worth a try.

I think I prefer temporary stackers over any other solution I've thought or heard about. Space near my factories may be at a premium, but the temporary stackers don't have to sit between them or even especially close. My main worry, apart from having to change every schedule, is that it might lead to extra traffic and congestion.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 2:11 pm
by Amarula
Laie wrote: Sat Jul 03, 2021 1:45 pm But I still have to apply that schedule to every single train, and make sure that i don't miss one.
I don't quite understand... you are setting up a new mine, so every train for that mine needs a schedule that sends it there, and if you miss one it doesn't work... It is true that if you replace a mine using the exact same name, the train schedules don't need to change at all... but if you are adding more trains to keep up with the extra distance/time to deliver, you still need to copy the schedule to the new trains...

And what is the worst that can happen? Any train you miss will sit empty at DPM1 waiting to fill. One look will show it is empty instead of full so it is easy and obvious to tell that it has a problem and what the problem is, and it is easy to fix. If it is only one, or even two, the other trains will go around it.

These are essentially temporary stackers, and by using the same train limits you ensure that no more than three trains ever head to your destination station so there will never be more congestion in your base than you had with the original mine #1...

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 2:51 pm
by astroshak
I always name my mines the same thing, depending on which resource is being mined there : Iron Mine, Copper Mine, Coal Mine, Quarry, Uranium Mine. The only variance I have from that is sometimes dedicating an Iron Mine to Steel, in which case I’ll name it Steel Mine.

I use a Balancer to ensure that the cargo wagons get an even distribution of ore, and use the total amount at the station to determine what the Train Limit should be (Iron Ore / (2000 * # Cargo Wagon)) = Train Limit. With this, there will never be more than 7 trains headed toward that particular mine; less if I use a pair of Decider Combinators to artificially cap the Train Limit.

The key though, is to ensure that you have enough waiting bays at the stacker for the offloading station.

Use of a separate, general stacker has its own problems. Basically, a train will skip a station if all of the stations with that name are disabled; but it won’t move if there is an enabled station of that name but there is no room due to the Train Limit. With this in mind, I’d expect that the Offload Station (Empty), Onload Station (Full), Waiting Area (none) might just be the best way to go here; just ensure that you have enough Onloading Area stations (aka mines) for every train you have lest an empty train sit at the Offloading Station due to Destination Full issues.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 3:11 pm
by Laie
Amarula wrote: Sat Jul 03, 2021 2:11 pm I don't quite understand... you are setting up a new mine, so every train for that mine needs a schedule that sends it there, and if you miss one it doesn't work...
Not sure if we're talking about the same thing.

Old schedule: Mine -> Unloader
New schedule: Mine -> General Waiting Area -> Unloader

If I miss a train, well, it will still work. Just skipping past the waiting area and making directly for the unloader, reserving a slot of the station limit while taking a long time to arrive. The worst outcome would be occasional but brief interruptions that are hard to catch as they happen.

But nevermind: I just noticed that the new trains menu has them sorted by schedule, so it will indeed be easy to check if any still use the old scheme.
astroshak wrote: Sat Jul 03, 2021 2:51 pm Use of a separate, general stacker has its own problems.
Such as? I understand your description as an easy way for me to add a (disabled) temp-stacker to every schedule right from the beginning; when the time comes, I can build the installation, enable the station, and presto, it's done.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 3:18 pm
by astroshak
Laie wrote: Sat Jul 03, 2021 3:11 pm
astroshak wrote: Sat Jul 03, 2021 2:51 pm Use of a separate, general stacker has its own problems.
Such as?
astroshak wrote: Sat Jul 03, 2021 2:51 pmBasically, a train will skip a station if all of the stations with that name are disabled; but it won’t move if there is an enabled station of that name but there is no room due to the Train Limit.
I don’t know about you, but I would definitely consider an empty train sitting at an unloading station with a full train behind it, unable to move to Destination Full, to be a problem…

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 4:05 pm
by Laie
Ah, that was what you were getting at. Well, if I cannot provide enough raw material, that is of course a problem. I don't see how a blinking train is making it any worse than it already is, however. If anything, it's a warning sign I may notice before everything grinds to a standstill.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Sat Jul 03, 2021 7:33 pm
by mmmPI
Laie wrote: Sat Jul 03, 2021 3:11 pm
Old schedule: Mine -> Unloader
New schedule: Mine -> General Waiting Area -> Unloader
astroshak wrote: Sat Jul 03, 2021 3:18 pm I don’t know about you, but I would definitely consider an empty train sitting at an unloading station with a full train behind it, unable to move to Destination Full, to be a problem…
You could use the ""General" Waiting Area " twice in a schedule that would look like : Mine->General Waiting Area -> Unloader -> General Waiting Area

This way the general waiting area fills up with filled train if you have surplus raw material, fills up with empty train if you need more mines, and when empty it means you need more trains easy to monitor :).

The fix distance between the "general waiting area" and the ressource-consumer, ensure you can find the "optimal" number of train and keep it. The inceasing distance between the "general waiting area" and the raw ressources means an increasingly big "general waiting area".

I personnally try to avoid the situation as much as possible by spacing my miners to the maximum in an ore patch, this way the mine deplete slowly, also i play most of the time without pollution or biters, in this case i put full productivity modules in the mines to increase their longevity.

I would also think like : for a green circuit factory that consume 1000 iron per hour, place miners to cover 24000 iron and you're good to move it every day. Place miners to cover 240 000 iron and you would be required to move it every 10 day. Place miners to cover 2 400 000 iron, and you're good roughly for the next 3 month.

It's different than "how much miners do i need to get the throughput for the factory?", you would end up placing more miners than the strict minimum and the miners won't be functionning 100% of the time, you will have to "reposition" a mine less often, making it easier to ramp up the total number of mine you have, instead of getting always distracted when one critial source of material deplete.

This makes smaller ore patch with higher yield more desirable than large patch with lower yield because that's the only variable left you have if you want you miners to function continuously or close , and yet that they last long time to avoid replacing them often. In factorio every area is getting equally better the further from the starting position you go.

Following previous logic i tend to do place the area that consume lots of raw material away from each others , spread far away in all direction around the center, this way they have access to their own circle of rich mines. ( green circuit assembly lines in one place , red circuits in another area, blue circuits in another, could do one for steel, and later for the rockets parts, or dedicated assembly for modules).

Each of them having its own "waiting area" for trains that get the raw ressources ( wait before and/or after) that also serve for intermediate product from other areas. The "main base" being the starting area with labs & building material has a "waiting area/hub" for the refined product from every other area.

it's a bit frustrating sometimes to see the green circuit assembly has too much ressources and the red circuit assembly not enough. As they are semi isolated and have their dedicated smelters and miners. Which is yet another incentive to follow the previous logic of "over placing" spread apart miners on richer yield ore patch. So as to minize the number of overall occurences of those frustrating moment and reduce the "scaryness" of train arriving at the last moment ;).

Most of the time i know i will on purpose place so many miners that i won't need a waiting bay on the way out, but i build it nonetheless because better safe than sorry :).

Re: railroad best practices: about long latencies and waiting areas.

Posted: Wed Jul 07, 2021 5:54 am
by JimBarracus
quite simple: add a train limit to the unloading station.
Set it to 4, one train will be at the station and up to 3 will be in the stacker.

If there are more trains that are ready to go to the unloader they will wait at the ore field and not depart before there are less than 4 trains going to the unloading station.

Re: railroad best practices: about long latencies and waiting areas.

Posted: Wed Jul 07, 2021 5:25 pm
by mmmPI
JimBarracus wrote: Wed Jul 07, 2021 5:54 am quite simple: add a train limit to the unloading station.
Set it to 4, one train will be at the station and up to 3 will be in the stacker.

If there are more trains that are ready to go to the unloader they will wait at the ore field and not depart before there are less than 4 trains going to the unloading station.
But over time you need to increase this limit when the closest mines deplete and trips to ore patch takes longer and longer.

Then you need to add more trains, and to make sure in case of a excess or lack of ressources they won't pile up where it causes problems.

For this particular example ,

I would use the "incoming train limit" on the unloading station, as you say, but to make sure not too many trains leaves from the waiting area to the unloading station. ( that's what i meant in my previous post by "you can find the optimal number of train and keep it"; set the limit to 3 so you are sure you will never have more than 3 train from the waiting area going to the unload, maybe on your game it's 5 or with another material it will be 3 but i mean it's a somewhat fixed value, your unloading speed will increase with research, your trains will get faster with better fuel and brake later with research, there may be more traffic-crossing as time goes : But that doesn't tend to a general increase as it does with the number of trains required to go fetch new ressources further and further away over time).

And i would also use the train limit at each ore patch , to make sure not too many trains goes to the same ore patch from the waiting area. ( closer ore patch you set limit to 1 or 2, and further ore patch that requires more trains due to distance , set the limit to 4-5 , very very far or very small trains, set the limit at 10- 12 , provided you have have enough space for all train in the waiting area AND each outpost has enough parking for the amount of trains it could receive based on the limit you set and how you set it).


Making use of the limit only at the unloading station, without generic waiting area, and letting the trains wait at the ore patch would work too as long as each ore patch has enough room to park all trains that are associated with it ( if limit on the ore patch is 4, make room for 4 or 5 trains, this requirement you can't skip while it's optionnal with the generic waiting area as you can set limits dynamically and expect the trains to wait somewhere else than at an outpost), all of this in case the main base doesn't need ressources because you don't want some empty trains queuing on the main road all in line behind the filled train that is waiting at an outpost blocking half the map .

This means the outpost will need bigger and bigger parking over time ( since they'll be further and further away), but it frees the player from the need keep to space in a central location to expand a "waiting area", like a distributed parking.

There is a drawback however, i would call it "reactivity" if your factory reaches a stage where its buffer for material are full, and all trains are at the outpost. You do not control how much time will a train take to arrive to the station. Depending on your settings, you could need super mega huge buffer if your outpost are very far, your factory consume very fast and does frequent on-off.

this is just theory though because in game depending on the time you spend on one base , the parameter for ressources, water, ennemy, train-world or not, things like that would make some argument become insignificant, stuff that work for 25H are not the same as those you do for 250H or 2500h in multiplayer for example :)

Re: railroad best practices: about long latencies and waiting areas.

Posted: Fri Jul 09, 2021 10:11 am
by JimBarracus
mmmPI wrote: Wed Jul 07, 2021 5:25 pm

And i would also use the train limit at each ore patch , to make sure not too many trains goes to the same ore patch from the waiting area. ( closer ore patch you set limit to 1 or 2, and further ore patch that requires more trains due to distance , set the limit to 4-5 , very very far or very small trains, set the limit at 10- 12 , provided you have have enough space for all train in the waiting area AND each outpost has enough parking for the amount of trains it could receive based on the limit you set and how you set it).
My outposts also have some logic that enables the train station when there is enough material /2.5k ore) to be loaded for every cargo waggon.
This eliminates the waiting time for resources when loading. The waiting time at the station equals the loading time.

I also have a train limit of one.

If there are no valid targets for the trains (no ore field train stations activated) than I know that I need to add new ore fields.
Some surveillance logic could be added:
-trains waiting for a certain time at the unloading station, either because of ore backing up or no free ore fields
-not enough trains in the waiting area

There are only two actions I can do, to increase ore throughput
-add trains
-add ore fields

When travel time becomes significant I could upgrade to longer trains.