Are trains really more efficient than belts?

[Nich]

Spread sheet or it didnt happen

[realm174]

When you have multiple stations with identical names, the train will indeed pick the closest available station. But, if that closest station is mining at a slower pace than what's needed to fill up the train, do you not risk the possibility of either...

This problem is being fixed in 0.15 - you'll be able to disable train stations by signal. So if you can wait, it won't be a problem anymore.

Until that time, what I do is just give my mines names like "Iron Mine 1", "Iron Mine 2", and so on. Depending on how lazy I am in the game I've (re)started, I then use dedicated trains for each mine, or just have the one train (2-4-0) go to each station, and wait until full, or until the ore at the mine is less than some amount. It burns more fuel and trains, but is stupidly simple to set up. I play Factorio to relax, so I don't often build complicated things, unless it's a pattern I've made before and memorized, or copied from the internet.

First of all, sorry for reviving a necro post... I started playing 0.15 a couple of days ago, and when I got to the trains, I remembered this post, so came back to it to refresh my memory. Indeed, using signals to enable/disable stations works beautifully... most of the time. As I am setting up mining areas, I make sure I enable/disable the train stations, which does come with 2 obvious advantages: I don't need to mess around with train schedules, as they pick up the new station as soon as it's up and running, and I don't need to worry about dismantling old/empty mining areas.

I did come up with one issue however. The condition I am setting up to enable a station is a minimum number of items in one of the chest (I load-balance the loading of chests, so they should all be the same-ish). So when there's 1000 items in that one chest, I "enable" the station. So typically, after a couple of train visits, the chest has less than 1000 items in it, so until it replenishes, I won't send trains there. My problem occurs when a train was already on its way to that station. If this is the last station with that name that was enabled, the train just stops dead wherever it's at, blocking traffic for other trains coming down the same track. I'm not sure if that train will ever pick up a new destination or not, but so far, it's been sitting there for about 15 minutes or so, while other trains with the same schedule have been visiting various stations. That one train is still stopped, with the destination font being red.

I am sure I can go and manually restart, but based on your experiences, will it eventually restart on its own? And any suggestion on how to prevent that from happening?

thanks!

Edit: Upon further investigation, the problem is actually a different one: The schedule for all the trains is basically Mine-X (as in, Mine-Iron, or Mine-Copper) and Unload. It just so happens that since it couldn't go to Mine-Copper, it looked at its schedule, and picked the next destination, which is "Unload". However, from it's current location, it ended up with a "no path" error. When the train came to a sudden stop, it was right in the middle of a 3-way intersection, and I guess it can't find its way home from there.

[Lav]

Edit: Upon further investigation, the problem is actually a different one: The schedule for all the trains is basically Mine-X (as in, Mine-Iron, or Mine-Copper) and Unload. It just so happens that since it couldn't go to Mine-Copper, it looked at its schedule, and picked the next destination, which is "Unload". However, from it's current location, it ended up with a "no path" error. When the train came to a sudden stop, it was right in the middle of a 3-way intersection, and I guess it can't find its way home from there.

You're using terminus stations I guess? Or did the train fail to path through a disabled station?

[realm174]

Edit: Upon further investigation, the problem is actually a different one: The schedule for all the trains is basically Mine-X (as in, Mine-Iron, or Mine-Copper) and Unload. It just so happens that since it couldn't go to Mine-Copper, it looked at its schedule, and picked the next destination, which is "Unload". However, from it's current location, it ended up with a "no path" error. When the train came to a sudden stop, it was right in the middle of a 3-way intersection, and I guess it can't find its way home from there.

You're using terminus stations I guess? Or did the train fail to path through a disabled station?

From what I can see/understand, here's what happens:

The train is on its way to station "A"
Station "A" gets disabled due to insufficient items in the chest
The train stops since its destination is disabled (The same way that if you're riding a train and select a different destination, it will come to a complete stop, before re-evaluating its path and restarting)
The train looks for a path to the "Unloading" station, and cannot find one, so it just sits there.

The reason why this happens, in my case, is due to the way the trains normally went, before I added that option. Better explained with a picture (as I happen to have one that came to a stop as I write this):



So the first train at the south east was heading for the copper mine. Chest ran out after being visited, so the train came to a stop. Its next stop would be the unloading area which is located at the main base, to the north west. Of course, there's no way for the train to head out that way since the track doesn't loop any where. Normally that's not an issue since the train would pull in the mining station, get loaded and head back in the opposite direction, but that's not gonna work here, unless I put roundabouts... Unless someone has any other idea?

[Lav]

So the first train at the south east was heading for the copper mine. Chest ran out after being visited, so the train came to a stop. Its next stop would be the unloading area which is located at the main base, to the north west. Of course, there's no way for the train to head out that way since the track doesn't loop any where. Normally that's not an issue since the train would pull in the mining station, get loaded and head back in the opposite direction, but that's not gonna work here, unless I put roundabouts... Unless someone has any other idea?

As far as I understand, if you disable stations, only ro-ro approach offers protection from a lockdown like this. Terminus stations might be fine for as long as they only get disabled when there's already a train there, and there's a waiting bay which has it's own exit back into the rail network, but a single mistake in the setup and the lockdown becomes a possibility.

Update. Okay, that was a bit too sweeping a statement. Correct one would be: disabled ro-ro stations are easier to proof against such a lockdown.

[Deadly-Bagel]

Unless someone has any other idea?

Hmmm quite the pickle. Unless you put crossover tracks between every signals yeah you're going to need loops somewhere, either that or better management of the train schedules.

Another minus for two-way trains, for the sake of a smaller station it doesn't seem to be worth using. However, it is possible for this to affect ANY rail network with "dead" rails, ie those that don't lead anywhere. If the train had stopped at the southmost intersection, it would have continued straight across it while braking. From there it wouldn't be able to go anywhere.

[Aeternus]

This is the reason why I always terminate the ends of my double rail with an "end loop", connecting the two tracks so trains can turn around. Your train would run all the way to the south, over the endloop and back to the unloading area, albeit empty.
Once I want to expand the rail net, I simply deconstruct those loops and expand. For even more gridlock resilience, if you do make sure all your tracks have endloops, you can make the T junctions to a single side of the double rail only (or split off a unidirectional station and make your trains single direction, much faster accelleration that way and trains will not get stuck blocking eachother if 2 trains decide to try for the same track at once), forcing the train to take a slightly longer route but never blocking both directions of the track at once. As fast as trains go, it barely matters to throughput, especially if you then do make roundabouts at places where your double rail branches out.

[realm174]

This is the reason why I always terminate the ends of my double rail with an "end loop",

Yep, this is what I ended up doing to fix my issue, as much as I dislike loops. But it's working, that's all that matters at this point. What I somehow expected was that the train losing a destination would "pause" (ie, come to a stop), but would then restart towards the same destination once it became available again. Which could cause the same kind of issue, with the exception that there's a better chance it would restart after re-evaluation a path (once it found a station with that name to be available) rather than toggle to the next destination in the schedule. But I do understand why it is the way it is, and it makes some sense. I just need to work my way around that. Loops seem to be the way.

[Aeternus]

This is the reason why I always terminate the ends of my double rail with an "end loop",

What I somehow expected was that the train losing a destination would "pause" (ie, come to a stop), but would then restart towards the same destination once it became available again. Which could cause the same kind of issue, with the exception that there's a better chance it would restart after re-evaluation a path (once it found a station with that name to be available) rather than toggle to the next destination in the schedule. But I do understand why it is the way it is, and it makes some sense. I just need to work my way around that. Loops seem to be the way.

It does that, but the problem your situation has was that there -was- no path to such a station, so you get the "no path available" error once it's tried every station in it's list. I'm assuming the schedule is a simple "go to mines - load, go to smelter - unload" setup. It was at the "go to mines" when the station became unavailable, so it's forced to cycle to the next - and last - in the list. Since that one fails too you end up with the "no path found" error.

But yea, a simple endloop prevents this. Simple solutions work

[Lav]

But yea, a simple endloop prevents this. Simple solutions work

A simple endloop won't prevent it, only make it considerably less likely. If the station is disabled when the train has already diverted from the main railway to the station, the train will still get stuck and exactly the same deadlock will follow.

You need an endloop on the station, not on the main railway to completely eliminate this type of deadlock. That, or use ro-ro stations.

[Aeternus]

Yea, but this kind of setup disables a station when the cargo drops below a threshold. Which can only happen if there's already a train loading, and that'd cause a red signal. Provided you have a chain signal at the entry way to prevent trains from trying to get into the station when it's occupied, that should cause the train to never go to the blocked station.

[realm174]

Yea, but this kind of setup disables a station when the cargo drops below a threshold. Which can only happen if there's already a train loading, and that'd cause a red signal. Provided you have a chain signal at the entry way to prevent trains from trying to get into the station when it's occupied, that should cause the train to never go to the blocked station.

So far, that appears to be correct. I have added a loop on the mainline tracks (at each end) and what I've seen happen is the train stopping, then restarting to go to the unload area (empty). I did, however, have to make adjustments to prevent a situation where a train would be loading, another one would be off the main track, waiting at the Y junction to enter the one already occupied. When the loading train would leave, the station would get disabled and the waiting train would face the same issue as original. So I just had to make sure there would be no train waiting in the "off the main line" areas, and it all goes well so far.