News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

[Bug v3.11] Fixed maintenance costs in pak file

Started by Bernd Gabriel, May 24, 2009, 01:25:49 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Bernd Gabriel

It seems, there are some bugs around the fixed maintenance costs:

I wanted to set the fixed maintenance costs of some locos to 100.00 .. 900.00 per month.
As described in http://forum.simutrans.com/index.php?topic=2112.0 I set the values to 10000 .. 90000.

1) The results in Simutrans: something about 0.64 .. 5.76.

The current source code writes 16 bits and reads 8 bits (vehicle_writer.cc/vehicle_reader.cc).
It should write and read 32 bits.

2) After changing the reader to read 16 bits, the (small enough) 10000 results in Simutrans to 400.00.

This happens due to "get_welt()->ticks_bits_per_tag-18ll" being 2, my intended 100.00 is multiplied by 4.
What is this calculation good for? A month is a month, there is no need to calculate anything.

3) The fixed maintenance cost is not added to the "This month" value in the "Finances" dialog.
The journey is the reward!

jamespetts

Bernd,

thank you very much for the report - the issue about the fixed costs being an 8/16 bit value will be fixed in the next version: I will use 32-bit values as you suggest. The calculation that you describe is necessary for all monthly costs (and is used throughout the game for all monthly costs) because the relative length of a month can be changed in the game, so the monthly costs must all be adjusted accordingly.

As to the "this month" value, that seems to refer only to track/building maintenance, and not to vehicle operation costs. The fixed monthly amount is part of the operation costs of vehicles, not the maintenance of infrastructure, and is booked under "operation costs".
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

This bug is now fixed in 3.13. Note that the new version of Makeobj-Experimental will also be needed in order to fix this problem, and .pak files compiled with this new version of Makeobj-Experimental will not work with versions of Simutrans-Experimental earlier than 3.13.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bernd Gabriel

Quote from: jamespetts on May 24, 2009, 06:45:25 PM
The calculation that you describe is necessary for all monthly costs (and is used throughout the game for all monthly costs) because the relative length of a month can be changed in the game, so the monthly costs must all be adjusted accordingly.

Maybe I didn't understand the role of neuer_monat() / new_month() yet. But, if it is called once per month as described in simplay.h for spieler_t::neuer_monat(), there is no need to take the game speed scale into account. Could it be that the formula is a relict from times before neuer_monat()?

I would expect, that the cost per month I set in the pak file is exactly, what I have to pay each month.

This calculation issue applies to the infrastructure maintenance in spieler_t::neuer_monat() as well, but would halve the existing costs as long as they are not adjusted in the pak/dat files.

BTW: The fixed maintenance costs are calculated from vehilces in convois. What about the vehicles in depots? They need maintenance as well, but do we pay for it in the current game?
The journey is the reward!

jamespetts

Ahh, no, don't confuse, on the one hand, the game speed, represented by the number in the lower right hand corner, and, on the other hand, the ticks per month setting. The first increases or decreases the speed of all things that happen in the game by the same amount: the whole game is fast forwarded or slowed down.

The second is very different: it alters the relative scale of the speed of the game, on the one hand, against the passing of time on the other. Increasing the speed using the ticks per month setting (which requires reducing the number in simuconf.tab) increases the number of months/years that pass in comparison to everything else that happens in the game.

To give an example: suppose that you have a railway between two towns: A and B, and one train on that railway. At a speed setting of 1.00 and a ticks per month setting of 18 (the default), suppose that your train goes between A and B ten times per month, which takes ten real minutes. At a speed setting of 2.00 and the same ticks per month setting, in ten real minutes, the train would travel between A and B twenty times, earning twice as much revenue, and costing twice as much in maintenance, and two months would pass.

However, if, instead of increasing the time to 2.00, you reduced the ticks per month to 17 and left the game speed at 1.00, in ten minutes of real time, the train would still travel ten times between A and B and earn the same amount of revenue, and cost the same amount in maintenance as the first instance, but two game months would pass.

It should be apparent from that description that the maintenance cost per month needs to be scaled with the proportion of months to ticks, since, were it not, lowering the ticks per month setting would mean that the fixed maintenance cost (the per month cost) would increase the monthly maintenance cost, but not the variable maintenance cost. Since changing the ticks per month setting is supposed to be cost-neutral, this cannot happen, so all costs that are calculated monthly have to be adjusted to take account of the ticks per month setting in order to counteract its effect.

I hope that this all makes sense now! Thank you for your interest in this topic, and your work on Simutrans-Experimental.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bernd Gabriel

THX, now I've got it!

At this point, i'd like to write the function sint32/64 welt_t::get_monthly_amount_according_to_ticks_per_tag(sint32/64 nominal_monthly_amount), which implements the correction once for all appliances and being the right place for a comment with your previous description.

OK, the name could be a more handy one... say: get_monthly_amount(nominal_monthly_amount)

What do you think?
The journey is the reward!

jamespetts

Ahh, that's an excellent idea! It had better be an inline function, I think. How about sint64 welt_t::calculate_adjusted_monthly_cost(sint64 base_monthly_cost); for a name?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bernd Gabriel

I'd rather prefer 'quantity' over 'cost' as the function is valid for any kind of values related to the tick. The production of factories is calculated the same way!
The journey is the reward!

jamespetts

Ahh, I see, yes. Perhaps "figure" would be better than "quantity"?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.