Train waiting bays unused

[Sephrat]

I'm trying to build a central deposit for my ores, where all my trains from my outposts would unload. Given the high traffic this will involve, I've built parallel waiting bays and made sure that they all have the same length and are equally distant from my deposit.

train setup.png (6.41 MiB) Viewed 11820 times

(forgive my Paint skills )

The trouble I have is that once a train waits at the entrance of the waiting bays (namely train B), it will never ever choose another path from the one it has chosen, in my case the first waiting bay from the left (as indicated in the picture), in which there is already another train (namely train A) waiting. This leaves all other waiting bays unused (I have moved the other trains you see manually for testing purpose). If I switch the automatic mode on/off of the entering train (train B), it still tries to enter through the busy waiting bay.

I've made a few more tests. If I switch the train sitting in the waiting bay (train A) to manual mode, then train B will in less than a second reroute its path through another waiting bay... the one on the right of the previous one, which in my example is also busy. If I keep doing so with all the trains in the waiting bays, the train eventually reroute its path through a free waiting bay (the first free one from the left). Therefore it appears my setup only works if my trains are in manual mode. This seems pretty strange but I'm not convinced it is an actual bug, because I'm guessing I'm not the only who came up with the idea of parallel waiting bays.

Am I doing this wrong? Do you have any setup to share?
Here is my save file if you'd like to give a try (vanilla 0.14.13). I've left it after switching train A to manual mode.

[Deadly-Bagel]

See my response to this topic.

Basically a train recalculates its path when it passes a signal or something on the track changes (rails removed, signals added, etc). So when approaching the chain signal, it picks a bay and queues up. However, while sitting at the signal it never recalculates so doesn't see the open bays as they become available.

The solution is to link your signals with green wire and make a "faux chain signal". Have all the signals into the loading bays output their status, then have the "faux chain signal" (where your current chain signal is) read those signals and go red if ([Green] = 0). This way the faux-chain signal will ALWAYS go green when there is an available bay, the train is then allowed to pass it which triggers the recalculation and it slides into the open bay.

[Sephrat]

Thanks for your answer. I will test your solution and let you know how it went, however I'm still confused on the path recalculating thing. The train should (re)calculate its path when I switch the automatic mode off/on, shouldn't it? Because that's not the case with my setup: it will always chose the same waiting bay, even if all the other waiting bays are available (they don't "become available" later on, they are already available).

[Deadly-Bagel]

Get rid of all the chain signals between the bays, they are not necessary and probably causing that part of the problem.

[Sephrat]

I've laid my chain signals this way so that blocks are smaller. By doing so, if a train (train 1) is entering a waiting bay on the far left, it doesn't stuck another entering train (train 2): instead of waiting until train 1 has come to a full stop at its waiting bay, train 1 can start moving towards its waiting bay (which would be closer to the entrance) as soon as the path is freed by train 1.
I know it sounds/looks complicated but if they indeed make my system not work, I would say that's a bug in the pathfinding.
I'll run some more tests (hopefully) tonight.

[Deadly-Bagel]

You're going to run into the same problem though.

If you really want I would suggest having an intermediate faux-chain signal a short way along (slightly longer than a train length) that only responds to the bays further down. You then need a gate to combine it with the rest of the signals for the first faux-chain.

Actually you could just link it exactly the same as the first faux-chain signal, if there is an open bay (even behind it) it doesn't matter if it goes green. Though you will want to maybe read the signal of it and ensure if it is red the first faux-chain is red too, otherwise you'll have trains moving into the waiting area to enter a bay that a train is pulling in to.

[Lemlin]

With so many trains I would have added a series of prestations (with the same name) for the trains to pass, in 4-5 lanes and capable of holding 2-4 trainsets in a row.
From the train stations I would have built a dual track to the unloading bays and divided the number of bays between them. The dual track could of course have a few signal sections, as you have now, to always have a train ready.
Even better if you have room ofr more unloading bays.
You currently trying to squeese 15-20 trains into one track and that´s not an easy task.

This would of course require more space..

[Sephrat]

The solution is to link your signals with green wire and make a "faux chain signal". Have all the signals into the loading bays output their status, then have the "faux chain signal" (where your current chain signal is) read those signals and go red if ([Green] = 0). This way the faux-chain signal will ALWAYS go green when there is an available bay, the train is then allowed to pass it which triggers the recalculation and it slides into the open bay.

Get rid of all the chain signals between the bays, they are not necessary and probably causing that part of the problem.

OK so I did as you said: got rid of intermediate chain signals to start off, and "coded" my own chain signal. I tried with "only" 5 branches: it seemed to work for a moment, but broke at some point. An entering train didn't reroute to an open waiting bay when passing the "faux chain signal" but instead went ahead and stacked up before the waiting bay, therefore stucking other available waiting bays.

train stuck.png (1.36 MiB) Viewed 11703 times

I've uploaded my save file with this config, just in case: https://www.dropbox.com/s/xz83pzr47n3p7 ... o.zip?dl=0.
I think that passing a signal is the same as turning off/on the automatic mode: the path is recalculated, however it seems that the pathfinding isn't smart enough to queue in another waiting bay, even though the distance is the same.

I may have narrowed down the reason it sticks to the far left waiting bay: it behaves differently depending on the train queueing up down the waiting bays (where they all merge, see image in spoiler below), It seems to look at other trains' positions in the different paths and make a decision based on that, I can't figure out the logic behind that though.

down the waiting bays

merge point.png (1.72 MiB) Viewed 11703 times

Edit: This might be why I thought it worked for a moment: I started my tests with all waiting bays completely full, thus with trains at different positions in the "merge section": at this point, whenever a waiting was free an entering train went and queued up in the newly available waiting bay. I noticed it didn't work when they were all almost empty (see my first screenshot).
Edit 2: I actually have the same problem with the faux chain signals with a simpler setup:

station entrance.png (687.62 KiB) Viewed 11696 times

All 3 branches lead to a station, all 3 stations have the same name. However the entering train doesn't necessarily reroute properly: when I turn on the entering train, it will enter the bottom lane instead of the top one which is symetrical, therefore at the same distance.


I'm quite disappointed that I can't get this setup to work, nor why my trains don't try alternative routes in this particular case.

With so many trains I would have added a series of prestations (with the same name) for the trains to pass, in 4-5 lanes and capable of holding 2-4 trainsets in a row.
From the train stations I would have built a dual track to the unloading bays and divided the number of bays between them. The dual track could of course have a few signal sections, as you have now, to always have a train ready.
Even better if you have room ofr more unloading bays.
You currently trying to squeese 15-20 trains into one track and that´s not an easy task.

This would of course require more space..

Yes I thought of that as an alternative solution but I don't want to dispatch all of my trains manually to each pre-station. I'd like to have a compact, expandable and plug-and-play solution.

[Deadly-Bagel]

Trains don't look at distance, they look at signals. When all paths to the destination are blocked the train will park with the fewest number of signals between it and its destination.

Therefore you ONLY want one signal before the waiting bays, a signal at either end of each waiting bay, and a signal after all the waiting bays, so that a train would only ever be passing four signals to pass through the waiting bays. If coded properly you can probably put some intermediate signals between the entrances but NOT the exits.

[Sephrat]

Trains don't look at distance, they look at signals.

That is a very helpful info that makes a lot of sense, that explains why most of time my trains would always chose the far left waiting bay: it's the one with the fewest number of signals.

Therefore you ONLY want one signal before the waiting bays, a signal at either end of each waiting bay

Yes I realised that after posting: removing chain signals at the exits seems to solve my problem, although I didn't test it thoroughly. I still feel frustrated not to have an opti layout (removing train stacking on the top part is terrible for throughput) but that will do for now.

If coded properly you can probably put some intermediate signals between the entrances but NOT the exits.

FYI I can't keep chain signals on the entering path because there currently is a bug when trains reroute after passing a chain signal (see here and here). I won't test it but I guess the same behaviour will occur with faux chain signals.
Looking at other train bugs that are waiting for 0.15, I think I'll wait for it too for now, my OCD hurts with all those workarounds.

Thank you very much for your wise advices.

[Deadly-Bagel]

Good to hear you got your head around it but I spent like 20 mins wrestling with GIMP's vector tool and layers so you're gonna get this diagram anyway xD but will be a good visual representation to make things a bit clearer for anyone else finding themselves on this topic.

WaitingBay.png (6.71 KiB) Viewed 11665 times

This is an efficient waiting bay system. For large waiting bays you can even put a third signal in the middle of each waiting bay (they will need to be twice as long) so that two trains can park in each bay, this halves the number of bays you need and therefore reduces the rails reserved for trains entering and leaving their bay.

[Sephrat]

Nice diagram, this is quite what I was looking for. Thanks.
I hope with 0.15 we'll be able to put intermediate signals to improve the throughput of this setup without breaking anything.

[Deadly-Bagel]

Purely semantics I know but that wouldn't affect throughput whatsoever. Throughput refers to the rate of flow, and since using that line as a waiting bay doesn't make the trains go through any faster it has zero effect on throughput.

Mostly what you achieve by using intermediate signals between the bay exits is increasing your buffer, which can be achieved by adding more bays or as I said doubling the length of the bays so two trains can park in each (which is more efficient space-wise).

I don't see train signals being changed enough to achieve what you want to do there, it would break other mechanics for no real payoff. If you -really- want to do something like that you might be able to manually program signals but off the top of my head I can't think of an easy way of doing this without having a train stop in each waiting bay.

[Sephrat]

By throughput I mean that in a simple case when my base is starving, only one train can enter the loooong path through the waiting bays at a time.
My waiting bays are not only a buffer but also a way to stack my trains close to each other without having a looong straight path with hundreds of signals.

The exit leads to multiple stations with the same name, so basically the entrance (bottom part in your diagram) with this setup will be the bottleneck of my network because I have a high amount of trains in input (I like trains ) and a high output demand. That is why I had so many chain signals in the bottom part + regular signals in the top part of my setup in the first place: to make several trains enter their waiting bays at a time, so that if a train goes and queue up in the far left waiting bay, another train can enter the far right waiting bay as soon as the first train has passed the entrance to this waiting bay (am I clear enough?).

The only hope I have for this case (base starved, high output demand) is that a train entering the waiting bay will start queuing up from right (close to the entrance) to left (further away from the entrance). However I guess I can't count on the pathing algorithm to behave like so, and I see no way to force a train's path through circuit conditions ("queue up in the first available waiting bay starting from right to left").

[Deadly-Bagel]

I like trains

*train'd*

ASDF aside, parking a train between the station and bays should alleviate that problem. If you mean the length of the bays themselves, then that's not a problem anyway because a train will always park at the leftmost signal in that diagram, at the end of the waiting bays. When it leaves to go to the station another train will take its place ready for when the station is available. Again the only way this would impact throughput is if it takes longer for a train to drive the length of the bays than it does for a train to enter the station, unload, and leave the station (assuming you also have a signal directly after it).

[Sephrat]

the only way this would impact throughput is if it takes longer for a train to drive the length of the bays than it does for a train to enter the station, unload, and leave the station (assuming you also have a signal directly after it).

That's actually the case in my current setup (I have several unloading stations, that makes the unloading time quite quick), I guess I'll need to make room for a long enough queue in between the waiting bays and the stations. Bye bye compact setup.

[Deadly-Bagel]

Or you could have waiting bays for your waiting bays! lol

[Linosaurus]

Trains don't look at distance, they look at signals.

That is a very helpful info that makes a lot of sense, that explains why most of time my trains would always chose the far left waiting bay: it's the one with the fewest number of signals.

It seems that chain signals are counted differently from normal signals, because in the first picture it looks like you have one chain signal below and one normal signal above for each station.

[Deadly-Bagel]

They're counted the same, having signals between both the entrances and exits balance the count out. However this then causes other problems.