[Bug/Problem 6.3] distance_per_tile issues (FIXED)

[dantedarkstar]

Hello

After a large break, I played Simutrans a little bit recently. I found out a small issue with the distance scaling.

Issue:

When loading a game, the current value of distance_per_tile in simuconf.tab is disregarded, and instead a value saved with game is used when determining running costs and revenues of vehicles. (WAD as I understand)

BUT

1. The maintenance cost of ways uses distance_per_tile from simuconf.tab instead the one from savegame. (BUG)
2. When loading an old save game (from before the distance scaling was added) a value 2530 is used for running costs and revenues, not the current value from simuconf.tab (problem, all older saves were build with distance 100 so suddenly changing to 25 causes massive problems). [edit: actual value used, found out in savegame]



Story:

I noticed that when loading an older save game (from 3.14) and playing for a while my transport empire that normally earned like 2-3 millions annually, was falling apart with over half million losses.
Looking at history graphs I noted that my revenue and running costs plummeted down about fourfold (without much decline in transported passengers/goods), while the infrastructure maintenance remained mostly the same. After reading what's actually new in 6.3 I noticed the scaling and immediately knew what's wrong - all distances were cut to 1/4 thus reducing revenue and running costs, but the infrastructure (stops mostly) still drained cash away as before, resulting in big minus instead of big plus overall.
So, to revert to "old ways" (after all, that game started like that and whole network was built in these conditions) I changed the distance_per_tile from 25 to 100. Unfortunately, I found out that pretty much NOTHING changed.

Curious why, I made experiment:
Small, new map. 10 tiles of road and a bus with order to go from one end to the other. Settings: distance_per_tile = 100. I ran for a year.
Then, I changed distance_per_tile = 25, loaded the save and ran for another year. Then, changed distance_per_tile = 10000, loaded and ran another year.
Result: Only maintenance cost of ways was affected. The running costs were not (can't say about revenue because it was all 0, but looking at issues with the savegame it would stay the same too).

Next experiment:
Now small map. 10 tiles of road and a bus. The same setup, except this time I started game with distance_per_tile = 10000. I ran for a year. Then, changed to distance_per_tile = 25, loaded save and ran for another year.
Result: The running costs were through the roof (as expected with distance_per_tile =10000), as were road maintenance costs. But after switching to 25, road costed accordingly less, but running costs were still astronomical.

Conclusion:
distance_per_tile is saved with savegame (I suppose this is WAD, since there's no way for a bug like that to occur by itself), but it is not used for maintenance cost. Maintenance uses current value from simuconf.tab, creating disparity between these two if distance_per_tile in savegame and in simuconf.tab do not match.
Moreover, experimenting a little with my old savegame, I realized that it always uses 25 for running costs/revenues (default), but the issue is that with older, pre-scaling savegames it was always 100, so transport empires crash around and die and you can do nothing about it.

[Edit:]
Actually, after saving the savegame as xml, and finding the value in the save (thanks to small trial save with some odd value for distance_per_tile like 313), I noticed that the old savegames have "assumed" the value 30, not 25.

[Edit2:]
Hmm... I don't understand it anymore. Now that I fixed the distance_per_tile in savegame, the running costs came back to normal. However... revenue didn't. Something's a bit wrong. Oh well. Revenue must use different multipliers hidden in save file somewhere else. It didn't change when changing distance_per_tile in simuconf.tab, nor when changing it in savegame (or at least I thought it was that, I mean, it worked for running costs), so I guess it must be still somewhere out there.

[jamespetts]

Dante,

thank you very much for your observations. Could you upload your original saved game, perhaps? That might be useful. I shall have to look into this in more detail when I have more time, but I am struggling to understand how there can be two different values for distance_per_tile used, since, when a value is read from simuconf.tab, it is read straight into one specific variable in memory, and thereafter used solely from there. There is only one place in the code (the part that reads it into that variable) that is capable of parsing simuconf.tab, and that is only invoked whenever a game is loaded or started anew.

[dantedarkstar]

Maybe it doesn't load two different values and that's the issue ? Like just using some default for revenue calculations instead the actual value from the savegame ?

Anyway, here is the savegame in question:
http://simutrans-germany.com/files/upload/Q4_x13_14.sve

When I loaded it into 6.3 and just ran for a year, I seen a sudden decline in revenues and running costs (while maintenance changed only a little since the big part of it were stops, not ways). This decline can be easily seen in the history graphs in budget.

[jamespetts]

Thank you very much for uploading the saved game - I will have a look at that when I get a chance.

When I loaded it into 6.3 and just ran for a year, I seen a sudden decline in revenues and running costs (while maintenance changed only a little since the big part of it were stops, not ways). This decline can be easily seen in the history graphs in budget.

This is the expected behaviour - the revenue and running costs will decline proportionately, and the infrastructure costs will also decline, but more modestly, because much of the infrastructure consists of stops. One thing that perhaps needs to be done to re-balance the game to work with a smaller distance_per_tile value is to increase the radius for stops, so that fewer stops can cover a larger area. I recommend at least 3 for the default distance_per_tile of 250m.

[dantedarkstar]

Yes, after I realized the distance was rescaled, I could understand the behavior of all values.
But what is buggy, as I said, is that changing distance_per_tile in simuconf.tab changes upkeep costs for infrastructure accordingly, regardless what is the value in the savegame.
Moreover, the revenue seems to be "immune" to changing distance_per_tile in savegame itself (done using xml save format) while running costs do change.

Actually, rather than increasing stop coverage, I would actually lower maintenance cost for stops and similar structures. Well, at least for sure I would lower the cost of basic stops. I mean... how a single pole with a sign can cost more upkeep than a kilometer of a highway ?
And I'm not sure if changing catchment to 3 could solve the infrastructure relative high costs. Yes, the area changes significantly, but you still need this train station as big as before, and depots etc. still cost all the same. Maybe it could be turned to profit, but certainly it wouldn't be like in regular 1 tile = 1 km setting. Even on typical scaling, I usually found infrastructure costs almost as high as running costs for vehicles (and even more so with still undeveloped passenger network).

[jamespetts]

Dante,

thank you very much for isolating the issue - I was eventually able to track it down in the code, and it is now fixed in the latest release, 6.5. Thank you for your report :-)