Exp9.11: Maintenance scaling.

[AvG]

James, inkelyad,
From the discussion about multiplayer-problems I understand that you need the bits_per_month there.
If that is a real fact (which I doubt) the we have to stick to that system.

That said we still have the possibility to switch the maintenance-scaling (thank you inkelyad).
This could be done via:
- A new button in the settings-menu --Maintenance-scaling on/off

- A variable (maintenance-scaling) in the config-file. (seems most easy solution)
I can even imagine that this variable already exists and makes it possible to add it in an already existing scenario, or if necessary to start a new scenario with the new setting.

For a 24-bits scenario is is realy necessary. Of course the Pak has to be adapted.
AvG

[jamespetts]

AvG,

it is very difficult to alter the scaling mid-game because of the way in which the maintenance charges are calculated. What happens is that, whenever you lay a piece of track, a number equivalent to its monthly maintenance is added to a general "monthly maintenance" figure; likewise, when you delete the track, that number is deleted from that figure. It would be very difficult indeed to go back and unpick all of those changes for each re-scaling. Why do you think it important to be able to change this during a running game, rather than using simuconf.tab?

[AvG]

James,
Only, because you do not have to start a new scenario, it would be of interest to have a button in the settings-menu. As a matter of fact only when you are developing your Pak.
So if it is possible to use a new variable in an EXISTING simuconf.tab it would be perfect. I could then use it immediately and stop wasting time using nonrealistic values for maintenance.
AvG

[AvG]

James,
I am still working on my maintenance-calculations.
If we strive for max realism, we should make sure that a month is realy a month, and not only a part of it.
Measured at 24 bits_per_month (bpm) you can see that time (clock) is running ~14 times faster then the result distance/vehicle-speed.
This means that if we would run Simutrans on scale-speed a bpm-setting of 27 or 28 is necessary.
At the moment 24 bpm is maximum. I think however that in the past this max was higher. I can imagine that if one wants to adjust to 28 bpm that it's only a matter of changing one char in the source. However, if you run on that (very slow) speed you are allowed to use the real cost figures from the real world.
If one runs on the standard 18 bpm monthly costs should be divided by 1000 (1024)
If we say 24 bpm is and stays the max (because ......) these real monthly costs should be divided by 14.
I think that, before lots of time are wasted, we should agree on what basis we should go on.
Are there more and different ideas on this matter.
AvG

[jamespetts]

AvG,

we can't practically make the time base for the vehicle speeds/times the same as the time base for the advancement of the years, or else the latter would take an excessively long time. There are mechanisms in the code to adjust the per month costs as the bits per month are adjusted such as to make any such adjustment financially neutral.

[inkelyad]

This means that if we would run Simutrans on scale-speed a bpm-setting of 27 or 28 is necessary.

Edit: My math was off.
At 19 bpm one month is ~500 sec real-time
At 28 bpm:
(500 * 2^9) / 60 /60 = 71 hours per month.
(12 * 500 * 2^9) /60/60 = 853 hours per year.

If one runs on the standard 18 bpm monthly costs should be divided by 1000 (1024)
If we say 24 bpm is and stays the max (because ......) these real monthly costs should be divided by 14.

But do we need to use absolute values? It is impossible. You can't fit thousands of cars/buses from real world to simutrans =>you need to recalculate revenue etc.

If you make pak with 24 bpm as default setting, it will be unplayable at 19/18. All your costs will be scaled down to zero. Integer precision is not infinite.

[jamespetts]

I am not sure that I follow entirely: what do you mean by "absolute values" here?

[inkelyad]

It seems to me AvG want to use real-world maintenance/14 for 28 bpm mode. It will not work.
I think real world "Vehicle pool maintenance"/"infrastructure maintenance" is impossible in simutrans.

[jamespetts]

Ahh, yes, I think that Inkelyad is right, I am afraid. Although it is possible to use realistic ratios of maintenance costs between different vehicles, of revenue between different vehicles, and of purchase costs between different vehicles, it is not possible to use realistic ratios of purchase to maintenance costs, nor of revenue to either of the others because of the way in which Simutrans is scaled. Instead, to get the ratio between different types of costs and between revenue and costs, one must use a calculation based on return on investment (as suggested by Moblet some months ago), preferably using a realistic value for the time taken to capitalise the investment and the overall return on investment over a certain period or alternatively a vehicle's or a piece of infrastructure's likely lifetime.

[AvG]

Actually I am working already with real-world maintenance/14 for 24 bpm mode and the results are exactly what I expected.
But I want more.
I want to be able to TRY and SEE how the playability behaves at 25 bpm (max 28 bpm) It will be slow, but with Fast Forward (1000*) you can do a lot.
After these trials I can pick the right bpm-setting and can go on with my PAK.

So if it is so easy as I think, please do me a favor and alter the max bpm setting from 24 into 28.
AvG

[jamespetts]

AvG,

I am not sure how easy that this would be, since I have never altered this area of the code.

[AvG]

Somebody that did/knows the coding could be of great help.
I have a hex-editor and I still hope it is a matter of changing one char.

Who can help? Maybe Prissi?
AvG

[inkelyad]

it is here:
gui/settings_stats.cc

Code Select Expand


void settings_general_stats_t::init(settings_t const* const sets)
...
INIT_NUM( "bits_per_month", sets->get_bits_per_month(), 16, 24, gui_numberinput_t::AUTOLINEAR, false );


AvG, are you using pre-compiled binaries?
EDIT:
This limit works only in settings dialogs. You can put 'bits_per_month = 28' in  simuconf.tab
and start new game.

But don't touch/open settings dialog -- it will reset bits_per_month back to 24.

[jamespetts]

If it's just a GUI limitation, I can easily change that for the next version.

[AvG]

It seems indeed a GUI-limitation
Starting a new game with 28 bpm in simuconf.tab it runs at 60 game-minutes is ~6 minutes real time.
As long as the Settings-menu is not used it stays that way.
Using that menu, for another reason than the bpm-setting, will set the speed to 24 bpm.
I think this is to risky to use.
So James, if you can alter this easily, please do!
AvG