I am having some trouble with some routes on the Bridgewater-Brunel server. I have a route where trains were stuck for a long period in game but I have since fixed this. However despite the game running through the pathfinder multiple times the waiting time for the route is stuck at 7 hours despite the frequency being much higher than this. This was previously a very highly used route and now it sees next to no passengers whatsoever.
(https://i.imgur.com/hhVHcER.png)
As you can see in the image below there is a service every 25 mins.
(https://i.imgur.com/Sc4tCoL.png)
Quote from: SuperTimo on July 07, 2019, 01:51:13 PMHowever despite the game running through the pathfinder multiple times the waiting time for the route is stuck at 7 hours despite the frequency being much higher than this.
The path explorer (for determining optimal passenger routes) does not recompute the waiting times, but rather uses the waiting times already stored in the halts. I think this data is updated when convoys depart/arrive or at month end; running the path explorer is irrelevant here.
Thank you for your report. I am afraid that I cannot at present debug any issues where the reproduction case is the Bridgewater-Brunel saved game, as my computer needs replacing before I will have enough memory to run this game.
Quote from: ACarlotti on July 07, 2019, 03:19:11 PM
The path explorer (for determining optimal passenger routes) does not recompute the waiting times, but rather uses the waiting times already stored in the halts. I think this data is updated when convoys depart/arrive or at month end; running the path explorer is irrelevant here.
In that case the problem must be something preventing these times from updating when they are supposed to. I've had the exact same issue (https://forum.simutrans.com/index.php?topic=19090.0) as well for a few years now.
I used this patch (https://forum.simutrans.com/index.php/topic,19069.0.html) to test the waiting time like this to see if station has a class connection with each station. :-[
(The code is here (https://github.com/Ranran-the-JuicyPork/simutrans-extended/blob/08cda025fcecf365b72ef09494e2817257a470e8/gui/halt_detail.cc#L1217).)
This shows the waiting time for each class registered in the station in grey.
The left side is the low class.
(https://i.imgur.com/BKTLljt.png)
The time next to the hourglass is the average wait time currently visible to the player.
Displayed time is not an average of classes, it seems to always show the waiting time of highest class. And this keeps taking the same value as highest class even if time passes. ???
The waiting time for the highest class may be shorter or longer than the average.
For example, check the passenger connection to Eastham station.
Very high class has very long waiting time compared to other classes.
Sometimes this time is very different from convoy's service frequency, so I have no idea how it is calculated, but I'm guessing this waiting time may be longer if there are fewer passengers/mail in the highest class.
(Could it be based on the actual travel time of each class?)
EDIT:
That image has some parts that have not been updated yet and may be different from some of the highest classes, but as time progresses, all values will be the same with highest class.
The data in that window is very interesting. :lightbulb: Almost shocking!
The really positive side is that it reveals how sophisticated James' passenger classes system is and how clever the path explorer is. Thank you to James and everyone else who has worked on these developments.
The discrepancy in the data also suggests that it will be good to improve the UI so that players can harness the full power of these systems. It confirms that Ranran's Station Details patch is a step in the right direction.
I believe I've distilled this problem to its essentials. The attached save has two stops linked by a hackney carriage (each with a capacity of 2 passengers per convoy) line running every 16 minutes. Initially, the line attracted 66 passengers until reported waiting times rose to about 34 minutes before passenger numbers dropped to 0 and waiting time remained at 34 minutes. I then deleted and replaced the two stops and the line attracted another 44 passengers until wait times permanently rose to 73 minutes and passengers dropped to 0.
As a temporary workaround before the issue itself is addressed, could players be given a "reset waiting & travel times" or similar button in the station details window? The effect can already be achieved by deleting and replacing stations but this has a financial cost and is difficult in complex railway stations.
In contrast to my earlier fix, this bug was caused by the change I made last month to how waiting times and connexion data were stored. In the process I unintentionally changed the code in haltestelle::new_month to increment a copy of the variable holding the number of months without new waiting time data, instead of the updating the original variable.
- FOR(waiting_time_map, iter, *waiting_times[category][g_class])
+ FOR(waiting_time_map, &iter, *waiting_times[category][g_class])
I still think there is significant scope for improvement to the way waiting times are computed, so that they are still updated accurately even when there have been no passenger departures. At present (after returning to the intended behaviour) a severely overcrowded line will need to see a whole calendar month with no journeys before it resets to waiting times based on frequency rather than measured passenger waits. This possibly ties in with changes I would like to make in the long term to how the path explorer works.
The fix for this is also on Github. Thanks for reporting the issue.
Thank you very much to A. Carlotti for the fix to this, which I have now incorporated. As noted elsewhere, I have been very busy in the last few weeks and also hampered in working on Simutrans by the lack of availability of components to build the new computer that I need.
I do agree that it would be most helpful to have a UI showing the waiting times for each class separately: how to do this clearly and neatly is quite a challenge. If any of the UI focussed people were to look into this, this would be extremely helpful.