Topic: Some waiting times not updating on bridgewater-brunel

[freddyhayward]

I can't find a way to reliably reproduce this issue, however one current example is at Aldinghall Junction 3389,811 on the bridgewater-brunel server. At some point (I believe well over 2 game-years ago) a disruption on a particular line caused waiting times for that line to rise drastically, and many of these times have not changed since despite a frequency upgrade. The waiting time for trains to most stations on the line is 5:18 given the frequency of 10:39. However there are major outliers including Nutingwest (4:10:54 hours), Bloxingpike (4:05:30), and Staningsea Junction (34:30 minutes) and a few others on 7:54, which was the original waiting time before the disruption and frequency upgrade.
Travel times generally seem correct, and I have ruled out overcrowding as a factor as the trains are usually well below seated capacity.

[jamespetts]

Thank you for the report. At present, I am not able to run the Bridgewater-Brunel saved game on my own computer, as I have had to disable some of the memory modules because they were faulty, and it no longer has enough memory to be able to run this game. I am planning to upgrade my computer in a few weeks' time. Until then, I will not be able to diagnose any reported issue where the only reproduction case is the Bridgewater-Brunel server game.

In the meantime, if anyone could either find a reproduction case for this issue in a smaller saved game or find the problem itself in the code, that would be much appreciated.

[jamespetts]

Can I check whether A. Carlotti's fixes of a few weeks ago have fixed this issue?

[freddyhayward]

It has certainly fixed the main issue, but given rise to a smaller issue. The problem now is that some lines where trains have not moved for decades due to disruption (in the case of Crandon & Lakes Railway) display a waiting time of 3-6 hours even though there is really no service at all. This generates enough passengers to overcrowd stations.

[ACarlotti]

That is fundamentally a flaw with the algorithm, which uses passenger departure data rather than train departure data to estimate waiting times. This doesn't work if passengers think it's not worth waiting for trains, so there is a backup based upon the timetabled or estimated frequency. This backup is causing the problems you now report. I ideas for how to improve this in conjunction with attempting to improve the path explorer, but it could be a while until I can actually try implementing these.

[jamespetts]

Thank you for confirming this. This is not a bug as such: there is no sensible way of the game being able to determine algorithmically whether any given line is temporarily deadlocked. Even if it could determine that, there is no sensible algorithm for what to do with that information, as the length of time that a temporary deadlock lasts is indeterminate: it might last for game minutes or game years into the future. If it lasts a short time, it will make no difference to what to do, as passengers should not be turned away owing to a short delay. If it lasts a long time, it would make more sense for passengers to find alternative routes; but this is hard to detect.

The ultimate solution would be to make routing based on entirely dynamic data about when convoys are actually likely to arrive. This would also eliminate other anomalies, such as the inability to deal with the fact that services are timetabled and thus to distinguish low frequency from high journey time. However, this would require for larger maps computational power far beyond what is realistically available at present.
I will thus mark this as fixed as the actual reported issue has now been dealt with. Thank you again for confirming.