More lurking confusion in the revenue code... how should catering work?

[neroden]

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

Code Select Expand


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...

[jamespetts]

Ahh, the reason for the line:

Code Select Expand


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:

Code Select Expand


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.

[neroden]

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.

[jamespetts]

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.