There's something weird about the way catering revenue works.
This is how I *thought* it should work:
- catering_level_4_minutes is 180. catering_level_4_max_revenue is 1000
- catering_level_5_minutes is 210. catering_level_5_max_revenue is 1500
So what I *thought* would happen is, if you have catering level 5 and a trip length of 195 (halfway between "minutes" for catering level 4 and 5), then you would get revenues of 1250 (halfway between "max_revenue" for catering level 4 and 5). This *seemed* to be what was documented in simuconf.tab.
This isn't what is implemented. What is implemented is weird. What is implemented is the larger of
-- half of 1500 (750)
and
-- 1000 + 4 (1004)
Is this deliberate? It looks like it was simply a mistake.
May I reimplement this in the way in which I think it was probably supposed to be implemented?
----
I have a further question. If I'm not mistaken, you're saving an *awful lot* of settings in the save file. This makes it really hard to test new versions of a pak, where the settings are changed. I feel like a bunch of this stuff -- for instance, the long list of catering calibration settings -- should *not* be saved in the save file, only in the pak settings file.
Changing station coverage size has such a game-breaking effect that it makes some sense to save it in the saved game. But changing the catering values? Why is this saved in the save file?
---
Uh, and a further question. Is there any good reason why this isn't implemented in simuconf.tab as
catering_minutes[0]=...
catering_minutes[1]=...
catering_max_revenue[1]=...
other than historical accident? If it's just historical accident, that's fine, I can work with it...
Ahh, the reason for the line:
final_revenue += (max(proportion * (sint64)(welt->get_settings().get_catering_level5_max_revenue()), ((sint64)(welt->get_settings().get_catering_level4_max_revenue() * 1000) + 4000)) * ware.menge);
is to make sure that revenue never goes down if one increases the catering level. If you notice, there is deliberate fallthrough in the switch/case statement, meaning that the code for catering level 5 is only actually used if the journey time is greater than or equal to catering level 4 minutes: even with catering level 5, if journey time is less than catering level 4 minutes, the code for a lower catering level is used (intentionally).
So, if the program has reached the line:
final_revenue += (max(proportion * (sint64)(welt->get_settings().get_catering_level5_max_revenue()), ((sint64)(welt->get_settings().get_catering_level4_max_revenue() * 1000) + 4000)) * ware.menge);
the journey time is somewhere between levels 4 and 5. If we had catering level 4, and the journey time was equal to or greater than level 4 minutes, then the maximum revenue for level 4 would be applied. No less revenue than this should be applied if we have level 5, so the greater of catering level 4 maximum revenue or a proportion of catering level 5 revenue is applied.
As to saving things in the settings files, this is necessary for multi-player games to ensure that everyone in the game has identical settings. Every setting that has any effect at all on a running game (that is, every setting bar GUI/cosmetic and map generation settings) must be saved/loaded, as it is the saved game that is transmitted.
The only answer to that is that I didn't think of doing it that way at the time.
OK, so it sounds like you did implement catering revenue wrong (routinely too low). I have fixed it.
The point is: how is the revenue supposed to behave with a catering-level 5 vehicle, for a journey time between the "max" for catering level 4 and the "max" for catering level 5? Before my fixes, it flatlines for a while and then takes a small slope upwards shortly before catering level 5, which is *bizarre*. After my fixes, it moves linearly between the two levels.
Ahh, thank you. I am not quite sure what I did wrong, but your description of how you have made it work sounds as if it is better.