I imagine we're all sick of my reports of errors in journey time calculation, but I'm afraid I have another to report. I found this in a version compiled from the latest sources, but upon testing it appears to also be present in 10.0 -- so the bug is not new.
In a nutshell: journey times, while correct upon initial calculation, fail to update at all when the line is changed -- even after several path refreshes.
Demonstrating this is somewhat complex, however. Here's a savegame: http://dl.dropbox.com/u/61716/journeytimesagain2.sve
(This should open with the old http://dl.dropbox.com/u/61716/carladdons4.zip pak file; let me know if it doesn't)
Now carry out the following steps:
1. Observe the journey times from Werdohl -- which can be verified as point-to-point accurate because part of the line is slow and part is fast.
2. Now change the line in a specific way. Update the 'slow' section with 'fast' track, and the 'fast' section with 'slow' track. This should lead to a change in journey times -- it should make the journey between Werdohl and Worgl much longer, and between Werdohl and Gelden much shorter.
3. Wait for a path refresh.
4. Observe that the journey times have not changed to reflect the major change in track work.
Hmm - I can't reproduce this, I'm afraid. I get the following results:
On loading
Worgl - Glendern: 20:12
Worgl - Werdohl: 9:24
Werdohl - Glendern: 9:36
(Avg. trip time: 43:28)
(after 1 refresh)
* Identical *
Modified (all fast)
Worgl - Glendern: 17:54
(Avg. trip time: 36:05)
Modified (reverse pattern)
Worgl - Glendern: 23:30
Worgl - Werdohl: 15:48
Werdohl - Glendern: 6:30
(Avg. trip time: 48:38)
Are you using a debug or release build?
How strange. The times upon loading are the same as yours, but no changes occur after path refreshes. (However, the 'avg trip time' does change.)
I'm using a release build. However, I find the non-updating behaviour to be identical in both the official 10.0 release and the latest sources. If you run the save in 10.0, do you get the same results as posted above?
Is there any chance this could be a 64-bit issue? Seems like a long shot, perhaps, but I can't think of any other potential difference.
Ahh, but are you compiling with optimisations on or off? We had a problem with a build with optimisations previously that I had to fix by a rather bizarre and circuitous bit of coding the need for which I still do not fully understand.
Quote from: jamespetts on October 09, 2011, 12:47:20 PM
Ahh, but are you compiling with optimisations on or off?
I'm not sure. But regardless, I'm experiencing this issue in the official release versions downloaded from Github, too (including 10.1) -- so I don't think the discrepancy can be traced back to a different method of compiling.
That doesn't rule it out, since I was testing with a debug build (optimisations off), whereas the official release versions are release builds (with optimisations on). The Linux makefiles in their default configurations will apply optimisations.
It was a release build issue - see my bugfix for this on the 10.x branch. It was part of the same release build/optimisation that caused the problems previously, and was fixed by extending the fix applied for that to updating existing timings as well as adding new ones. Thank you for reporting that!
That looks to have fixed it. Many thanks!