Time lag in boarding trains at transfer stations

[Rakuten]

I encountered a weird situation where passengers refuse to immediately board a train to their final destination at transfer stations, even though the route to the destination is unique and trains on that line are not at full capacity.
Instead, I find that passengers rushed into trains of the said line after like 15 or 20 minutes, despite that multiple available trains called at the station during the period. This causes unnecessary congestion within the interchange station.
Is this some sort of built-in mechanism, or am I missing something?

[ezzatam]

Are you running different service patterns on the same tracks? Local-Express arrangements will make pax wait for the express if the interval difference is not big since they prioritise routes with fewer stops.

[senorsoupe]

I am having the same problem. My MegaHub at Chicago is full but pax aren't boarding trains. For example I see that most of my pax want to go East towards Toronto, Montreal, and Quebec City but when the high frequency trains to Detroit come, very few people board them (despite the trip finder saying that is their chosen route) and the station stays full

[Hannibal]

I think this is the same issue I'm having. I posted it under bug reports as incomplete train loading and shared my save with the dev. Here's his explanation of what happened (hope this is ok to post here) shared by e-mail:

Rather than giving trains arriving at a station a full detailed list of all the pax in the station to check, the game just gives them the total number (actually 2 numbers, the total transfer pax and the total new pax). So while the train checks the station pax listing, it just decrements this number. What might be happening is that a very full train arrives and unloads hundreds or thousands of pax in the station. The train counters are not updated to consider this fact, since doing so precisely is basically impossible (imagine N trains checking pax, and then M trains arriving, all introducing and removing pax at the same time). Since the actual list of pax is now longer, but the counter has not been increased, when it reaches 0 there's still pax waiting to be checked.

It could be understood that those pax are just the very latest to arrive so it is reasonable to leave them there. And this was true in the past. But since clustered/sorted pax were introduced, pax are now processed by the internal order defined by their destination station database ID. Said ID is just an opaque number, but it is stable, and increases in time (a station created later has a higher ID). If a station has a higher ID than others, it is always relegated to the end of said checking. So it's always one (or a few) destination station that suffers from this too early end of processing.

So basically if I understand correctly and summarise, due to this mechanism big hub stations with a large constant I/O flow of pax have an effectively reduced capacity. The effective capacity of the station from the perspective of a boarding train is not the total pax waiting at the station, up to 10k. But it's reduced with whatever inflow the station has during the train's stopping time.

So: if the station processes 300 pax / second (on average) and the train stops for 10 seconds, that's 3000 pax that you see in the real time station info, that the train will (on average) miss from the pax listing and will not process for boarding. If the station contains 8000 pax it means the train checks only 5000 of those for boarding during a 10 second stop time on average.

That's not a huge issue for me really, as transfers are not immediate in real life too. The problem is that the 3000 pax the train will not check are not a random set (last pax to arrive for example), but a specific subset of pax with the highest station database IDs. So you have a build up of pax with specific destinations that fail to board for a significant period of time. Then when something external happens, the stuck pax suddently clear. For example it could happen when new pax enter the station with even higher database IDs, pushing up the "stuck" destination in the processing order in relative terms.

[senorsoupe]

Ok thanks, this is an issue for me on certain days (Monday and Friday) when Chicago Union Station fills up and it becomes a bit of a vicious cycle to clear. I've tried adding frequencies to my busiest trains (including the 15 commuter lines) but I am questioning about whether or not that will help the problem. I just need to figure out what the best strategy is to avoid Chicago getting bunged up without having a cascade effect elsewhere in my system. Despite my best efforts to have high speed lines bypass Chicago (St-Louis-Indianapolis-Detroit as an example) pax still wanna go through there !

[Hannibal]

I've found that saving and reloading helps but that really should be temporary gap, hopefully the dev can find a way to improve this as we all seem to have some issues here.

If it's not changed I think I will have to split some big transfer hubs. For example I've now combined Paris Gare du Nord and Paris Gare de l'Est in a single in game station. In real life there's a 5 minute walk between them. If I would split them into two, this issue would not disappear but there'd be more headroom until the stations get full.

[Weird and Wry]

> If the station contains 8000 pax it means the train checks only 5000 of those for boarding during a 10 second stop time on average.

Not really. If the train saw a total number of 8000 pax in the station at the moment it entered the station, it will process at full flow speed 8000 pax, and it will bump its waiting time (up to 3m) to make it happen. The issue is the train arriving, seeing 5000 pax, and while it's loading another train arrives and unloads an additional 3000 pax. That extra pax is not considered in the train pax flow counter. This has always been the case, but since clustered pax, the order of pax in the station is based on their destination, not the time of arrival, which is unfairer.

The fix is to make sure every train stopping at a station completes an entire loop of all the sorted destinations. There's a variety of ways to fix it but at this point the fix is more likely to show up in the v1.2 series.

EDIT: I've found a better and cleaner solution, basically moving the pax checking logic to consider the POV of the train rather than the station, coupled with an efficient way to have an independent iteration of the station pax per-train. Unfortunately it's quite involved and I don't want to open the 1.1 branch again, so it will be implemented in the 1.2.x series.