Train Stacker weird behavior

[frayien]

Hi ! I have a strange issue, sometimes a train will absolutely want to go to a specific slot in the stacker even if another train is already in it, resulting in it being stuck, any idea on what I am doing wrong ?

[Yoyobuae]

What I think happens: The next train arrives at the chain signal BEFORE the train entering the stacker has fully entered the respective slot. So the train trying to enter the stacker sees the chain signal as RED. The train DOES NOT repath because all paths are equally blocked.

Fix: Make sure that the next train does not try to enter the stacker before the previous train has already entered it's stacker slot fully. You can achieve this by redesigning the rails and/or signals to allow for more spacing (and thus more time for acceleration).

Alternate fix using circuit network: Place a rail signal right before the chain signal. Make the rail signal to always be red whenever the chain signal is also red.

[valneq]

I believe that a train waiting at a blue chain signal will repath after some time. Not sure exactly when, but they do eventually.

[Yoyobuae]

Wiki says they should repath every 5 seconds which makes it weird for that specific train to be stuck there.

[astroshak]

Don’t expect this to fix your issue, but I tend to put Chain Signals at the end of every parking space in a stacker. I then have Rail Signals at the end of where the train parked at the Station will be. This allows me to have multiple Stations fed by the same stacker.

That bit of unasked for advice aside, I got nuthin for your posted problem.

[valneq]

Wiki says they should repath every 5 seconds which makes it weird for that specific train to be stuck there.

Information from the wiki could mean the train will repath at the latest after waiting for 30 seconds. Not sure exactly how to read "multiple of 5s" and "multiple of 30s" in this context.

[Loewchen]

It will check for validity every 5s and will repath every 30s unless the check fails, I do not know what would invalidate a path though.

[Yoyobuae]

Information from the wiki could mean the train will repath at the latest after waiting for 30 seconds. Not sure exactly how to read "multiple of 5s" and "multiple of 30s" in this context.

I don't know what the "If the trains has waited for a multiple of 30 seconds ..." means. I just know that when a train is stopped at a chain signal it will repath every 5 seconds. There' a debug option to show when train repaths and it shows the train repathing every 5 seconds when at a chain signal.

[disentius]

This one drives everybody crazy:)

Trains choose their path when they leave the source station.

This means that when they arrive at the stacker, the situation is almost always different vs when they left.
The best solution is to make the train repath just before entering the stacker.
Look at the repath events on the wiki, you can force a train to repath in different ways.
An easy one is to add a station just before the stacker, and set the schedule to wait 0 seconds. the train will repath when leaving that station.
[edited for clarity]

[frayien]

Wow so many answers ! Thanks !
According to the wiki the train reevaluate if the path is still valid every 5 seconds and force repath every 30 seconds.
If i understand well the train should recalculate if it is braking to a signal it cant reserve, I have been watching my trains for long and yeah sometimes it recalculates.
Also the issue appends even if all trains are stopped before the new train arrives, so it is not due to a bad timing.
I dont exactly know what it means the trains cant reserve a signal, but I will try to explore this, if it leads nowhere i will just put a dummy train station.

Also I dont understand how I have bean using trains and making stackers for hundreds of hours but I never noticed this behavior ...

[Theikkru]

Important terminology distinction: "repath" only means "revalidate the existing path to make sure it's not broken". That is a very low bar to clear, and does not account for potential delays such as red signals or other trains. "Recalculate", is when the train actually (re)tries to find the fastest path to its destination using the pathfinding algorithm (which always happens once when the train leaves a station).
In the Repath events section of the wiki, it details the conditions under which a "repath" or "revalidation" will occur. Some of these ALSO force the train to do a full "recalculation", which is the only thing that would convince the train to pick a different stacker slot. Unless one of the conditions to force a recalculation is met, the train will keep whatever path it had in mind, even if that path is now longer due to other trains.

In this stacker example, it's actually the opposite of what some people have suggested. The train in the stacker MUST have already fully pulled into the stacker and cleared the chain signal section before the problem train even came within braking distance of the chain signal, because of the following repath triggers:

The train is preparing to stop at a signal (chain or regular) that changes so that the train can now continue. The train is forced to recalculate its path.
The train is braking for a signal (chain or regular) it cant reserve and the train is not inside a chain signal block. The train is forced to recalculate its path.

If either of these had been triggered, the train would have recalculated, and found the other stacker slots preferable.
The key here is to do something that triggers a recalculation, and not just a repath/revalidation. That's why a passthrough train stop at the stacker entrance is the simplest solution: trains can go through a stop at full speed if there are no conditions in the schedule for that stop, and because they always recalculate their path when leaving a station, they will update their path with the latest info about the occupancy state of the stacker.

Another weird workaround would be to simply put down a second train stop with the same name as the destination train stop somewhere. It doesn't even have to be connected:

The train has waited at a chain signal for a multiple of 5 seconds.
If the trains has waited for a multiple of 30 seconds or if multiple train stops with the name of the destination exist, the train is forced to recalculate its path.

Hilariously, getting hit by the train would also do the trick:

The train collides with something that is not a train (like a player). The train is forced to recalculate its path.

[Impatient]

Nice and helpful insights Theikkru.

[Theikkru]

Also I dont understand how I have bean using trains and making stackers for hundreds of hours but I never noticed this behavior ...

Can you post a save or demo? I'm kind of curious how exactly the train controller got confused like that and I'm having trouble reproducing the problem.
P.S. Just to make sure, are you playing on version 1.0?

[disentius]

Thanks for the detailed explanation Theikkru:)
The way I read your post implies a Waypoint station (stop with no conditions in the schedule) would work. is this true?

[Theikkru]

I don't see any reason a waypoint station would be different from any other station. Unfortunately I'm unable to reproduce the problem, so I can't confirm it as a solution directly.

[frayien]

Also I dont understand how I have bean using trains and making stackers for hundreds of hours but I never noticed this behavior ...

Can you post a save or demo? I'm kind of curious how exactly the train controller got confused like that and I'm having trouble reproducing the problem.
P.S. Just to make sure, are you playing on version 1.0?

Yes I am playing on 1.0, but what may be important is that I am playing on a server. (linux headless server)

here is a backup : https://www.dropbox.com/s/jx8vwg65szp9v ... e.zip?dl=1

[Theikkru]

Thanks, I was able to reproduce the issue and verify that it is in fact caused by stale pathing info that the train never got triggered to recalculate. This seems like it could be a bug or oversight in the coding for the repathing triggers, so I'm going to crosslink to the bugs forum and see what the devs think.

Crosslink.

Now that I know more about the issue, I've discovered that simply deleting the chain signal also works around the issue. The caveat is that the trains entering the stacker must have enough momentum that their braking point will reach any occupied slot before the train itself passes the entrance to all open slots, but with this specific stacker, and with those cargo-heavy train configurations, the condition is easily met.

[Theikkru]

This behavior is now marked as a bug fixed for 1.1.0.
(Turns out I was a bit off about the root cause.)

[frayien]

I know, i have been reading the bug post you made ! Thank you for the time you took to help me and to ensure the bug was correctly reported and understood !

[Mr. Tact]

I don't know if it is still the case, but the problem described here used to be "fixed" by using two regular signals close together and wired together.

Signals:

parking signal.gif (69.84 KiB) Viewed 5587 times

First signal:

front signal.gif (226.95 KiB) Viewed 5587 times

Second signal:

back signal.gif (179.67 KiB) Viewed 5587 times

Although I have to say, looking at it now, if it does work I don't understand it any longer. Or maybe I messed this one up... ?
IIRC, the idea is the changing signal forces a recalculation of the route, hence if a train has taken your spot, you will pick a new one.