Feature #3384

Cost structure

Added by oberhuemer almost 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:2011-12-19
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


At the moment, there are only a few actual prices in the table. That'll never work out, and manual setting for everything is a bit tedious too.
I suggest starting with http://users.tt-forums.net/pikka/wiki/index.php?title=Vehicle_Cost_Calculation#Trains, that'll need to be turned into a formula.


#1 Updated by Eddi almost 8 years ago

i tried to figure out a formula for the "unrealistic cost" a while ago, but found nothing that fits well into the (few) "realisitic cost" values that we have, so i left that be.

feel free to experiment with the formula, but the values that we have now should be taken as anchor points, imho.

we probably won't find a "universal" formula, so an approach for developing separate pricing schemes for engines, MUs and wagons might be appropriate, possibly also separate into traction types.

#2 Updated by Eddi almost 8 years ago

I put a (crude) formula for calculating purchase prices in the tracking table, so most engines should now have a price > 0 (some engines with missing stats are still wrong)

the formula is a bit problematic for articulated vehicles...

a big problem left is the maintenance cost. suggestions include:
  • base it on running/stopped (speed = 0)
  • base it on max speed
  • base it on current reliability

#3 Updated by Eddi almost 8 years ago

For reference, the purchase formula currently is:
  • For vehicle classes steam, electric, diesel and wagon choose a reference vehicle with realistic price
  • For each other vehicle, calculate price according to stats:
    • Steam:
      • reference: BR 01
      • price = reference*weight(vehicle/reference)*boiler_pressure(vehicle/reference)^(1/2)
    • Electric:
      • reference: E 60
      • price = reference*weight(vehicle/reference)*power(vehicle/reference)^(1/4)
    • Diesel:
      • reference: 0.75*(E 60)
      • price = reference*weight(vehicle/reference)*power(vehicle/reference)^(1/4)
    • Wagon:
      • reference: random value
      • price = reference*weight(vehicle/reference)
  • for articulated vehicles (except tenders), price is doubled (very crude/inaccurate)

all values subject to tweaking after some gameplay testing.

#4 Updated by oberhuemer almost 8 years ago

I took a few glances, and it seems to work well enough for engines. Not much attention paid to wagons, and articulated vehicles have some issues as you said.
For the running cost, it should definitely become close to zero when the train is standing still, and should rise with falling reliability, but no fancy unpredictable constructions beyond that.

#5 Updated by oberhuemer almost 8 years ago

Influences on the "base" running cost: Power (to a lesser degree; or boiler pressure if you will), maximum speed, engine type of course (high, med, low for steam, diesel, electric); wagons: capacity (and maximum speed?).
Power is just there so weak engines can still be sensibly used, would also give a bonus to MUs.

#6 Updated by oberhuemer almost 8 years ago

Comparisons (UKRS2):
  • Steam: 8F (1156 kW & 80 km/h, equivalent to a 50) - 23362 euros per year
  • Electric: 90 (3729 kW & 177 km/h, equivalent to a 146) - 28086 euros per year
  • Diesel: Brush Type 4 (1924 kW & 152 km/h, equivalent to a 218) - 25200 euros per year
    (also Class 66 in both sets, 23886 euros per year)
  • DMU: Sprinter (578 kW & 120 km/h, 60 kW more than a RegioShuttle) - 9712 euros per year
  • EMU: Electrostar (1119 kW & 160 km/h, little more power than a Talent 2) - 8662 euros per year

These values are also slightly scaled by year. One more thing is that they should fall by 25-33% if infrastructure maintenance is enabled.

#7 Updated by oberhuemer almost 8 years ago

One more: A cost automatically added to everything (think "train driver"), encourages making longer trains (equals using stronger engines) and discourages double-heading. Might be a good idea, might not.

#8 Updated by Eddi almost 8 years ago

Not really sure what you mean by that. Cost added to what? And what effects do you think this has?

#9 Updated by oberhuemer almost 8 years ago

I don't think people will mind, so forget about that.

#10 Updated by Eddi almost 8 years ago

I tried a short test game, and with one coal train i didn't really make any profit, the wagon running costs are probably too high (should we have those at all?)

#11 Updated by oberhuemer almost 8 years ago

  • Status changed from New to Closed

No further complaints

#12 Updated by Eddi over 7 years ago

  • Status changed from Closed to Feedback

there's several things "wrong" with r654.

  • the obvious one that it doesn't compile. i think it's a missing nml feature to apply rounding on float values in that context
  • checking for vehicle_is_stopped is useless, because that applies to manually hitting the "stop" (or "send to depot") button only, and in that case,running costs are set to 0 by the game anyway. maybe you meant checking for "speed == 0" instead?
  • i think a crude 1/8 (or any other fixed factor) doesn't make a lot of sense. maybe instead we should distinguish in the tracking table for "cost every X km (fuel, etc.)" (scaled to running full speed for a year) and "cost every X years (personnel, etc.)" (scaled to a full year). then we can also list them separately in the purchase menu.

#13 Updated by oberhuemer over 7 years ago

I wasn't aware that running costs were automatically set to 0 in those cases (filed a report about it), this was meant to reduce them to something manageable from normal.
Fixed factor - this is just "a little ugly, but simple" vs. "elegant, but complicated for us and the user" again. I generally take # 1, but remain open to any code for # 2.

#14 Updated by oberhuemer over 7 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF