[RC 10.9018] Altered journey times on loading

[Carl]

When loading an existing map in the RC, some journey times display lower than when the same map is loaded in 10.18. To clarify, this is immediately after loading, and not after a recalculation, which is why I thought it odd -- normally I would expect these times only to alter upon a recalculation and not upon reloading, since the data is presumably stored with the savegame.

Some other quick facts:

* In some cases, the differences in journey time are large. Having checked, I can verify that in these cases the RC's lower times represent an introduction of error rather than a correction.
* This appears to affect all routes.
* A few journey times return to normal after a monthly recalculation. But not all do. Some of those which do not are those where the journey time has been reduced by more than 50% of the real value -- presumably because of the recent bug fix regarding journey times. (Nevertheless, it does not seem that the latter fix is to blame here.)
* In almost all cases the journey times are lower, but in a small minority they are higher.

I've reproduced this in a couple of saves, so hopefully it should be visible in any developed savegame loaded in both versions simultaneously.

[jamespetts]

Hmm - this looks to be a loading/saving issue, where some alteration in the load/save code alters the journey times somehow.

Bernd - would you be able to look into this?

[Bernd Gabriel]

Carl, could you please post a link to a saved game and name a convoy to look at?
I cannot reproduce this issue.
Thanks.

[Carl]

Sorry for the delay.

https://dl.dropbox.com/u/61716/journeytimes.rar

Here is a savegame and the required pak folder. Look at the halt details of the nearest station in 10.18, and compare the journey times to those displayed in the RC. There should be discrepancies (though they are more slight on this map than on the other, larger one I've looked at).

[Bernd Gabriel]

Issue fixed in my "112.x merge" branch.

Standard simutrans has changed hashtable_tpl. It now sorts its bag entries, but standard does not know our koordhashtable_tpl. Method koordhashtable_tpl::comp() had to be modified accordingly.

I remember that there was a NULL pointer issue with hashtable_tpl (because entry not found) after merging, but not exactly what it was. Most probably this issue is fixed as well.

[Carl]

Thanks Bernd!

[Carl]

I can confirm that this bug is absent from the new RC build. Thanks again.