Purchase costs, maintenance costs, speed and bits per month

[The Hood]

Sorry if this information is somewhere, but I've had a good dig around the forum with no success so I'm just going to ask

I'm having a more detailed look at balancing for pak128.Britain and I'm trying to estimate the effects of infrastructure costs  and purchase costs on the balancing.  What I want to know is:

1) Does the "per month" maintenance cost of track, depots, stations, signals etc increase with "bits per month" or is it a constant?
2) Do purchase costs of vehicles and infrastructure increase with "bits per month" or are they constant?
3) How is a convoy's speed related to the number of tiles per month? (i.e. 100km/h is equivalent to how many tiles per month, assuming a constant speed?)

Basicly I'm trying to calculate returns on investment, which means calculating profit per month.  I'm just worried that some costs don't vary with bits per month, so if you increase bits per month, you make the game easier...  Is this right? Is this a loophole that needs closing?

PS if other pak-maintainers think I'm barking up the wrong tree, I'd love to know how they did it.  Especially how they decided how to price the purchase and maintenance costs of infrastructure.  I'm trying to get it so that infrastructure should be limited to only what is appropriate, and that over-engineered solutions aren't financially viable...

PPS Thinking about it further, it would be great if there was an option to adjust costs in game, so having a global factor for vehicle purchase costs, vehicle running costs, infrastructure maintenance costs, and infrastructure purchase costs.  This would (a) help the trial and error process of balancing paks without changing 10001 dat files and (b) allow people to increase / decrease difficulty levels as they desired (e.g. I've already had conflicting reports of "too easy" and "too hard" for pak128.Britain).  If this was linked to bits_per_month then the effect of making things easier with larger bits_per_month described above could also be removed.

[prissi]

You do not need to bother about bits_per_month:

1) The mainenance increase with bits_per_month.
2) Therefore the vehicle costs (and all other fix costs) are the same.
3) Somebody fitted that, maybe in the old forum. I never bothered.

I usually use only the money you can make with a train (with the best passenger car at full length) and take 10% of that as running cost. More than 20% is very difficult to obtain in realistic nets. YOu can change the revenue by using the geginner mode and adjust the factor accordingly.

[VS]

1+2) Instead of thinking in game months & years, think in game ticks. All the per-time-interval aspects are handled correctly with variable length, so that leaves you with a model of time where things always stay the same.

3) Ask Zeno. He knows too much about that, I am sure his explanations will make you look like this: The calculations are (imho) pretty insane. But they work.

[The Hood]

Thanks for the explanation.  If I understand correctly:

1) all per-month costs scale with bits per month.  That's good.
2) one-off costs don't.  So with a really high bits per month you can repay your super-expensive all-singing-all-dancing train purchase in 3 weeks, but with a really low bits per month it will take 100 years (exaggerate to make a point).  Is there not a case for scaling this with bits per month (i.e. so in identical saves with different bits per month it takes the same number of game years to repay a loco or track investment?)
3) Insane calculations.  sounds good to me

[prissi]

With both settings it takes the same time for the player in front of the screen, which is the most important point.The balance after two hours of playing will be the same, and thus the amount of construction possible during that time. THe only  difference would be the date ingame.

[megasycophant]

Did you ever figure out #3? Was just searching the forums to answer this question.

[jamespetts]

I had to solve this problem when creating some features on Simutrans-Experimental about a year ago; I cannot remember the answer now, but I think that it is in the forum archive somewhere.

[tonu]

Hi!
I was searching about the "bits per month" setting and I found this old thread, I mostly understand.
So, if I increase the bits_per_month value the game will be the same but the timeline for new vehicles will be slower? Is there a limit for the value?

[jamespetts]

I don't know off the top of my head whether the value has a limit, but, yes, the game will work internally in more or less the same way, but the months and years will pass more slowly. To compensate for this, any cost that is calculated monthly will be adjusted accordingly.

[AP]

how does one convert from bits per month to realtime? I mean, assuming a game running continuously, what bit-per-month setting would make a game-month take a full real-life-month to pass?

Have been doing some thinking about best time settings to use for server games (will post my suggestion at some point...) but this is the bit I'm unclear on.

[jamespetts]

Hmm - I know that, in Experimental, with 21 bits per month and 250m/tile, each game month lasts 6.4 game hours, but these game hours do not exist in Standard. About two game years will pass every real life day, I think, if the game is kept running at 21 bits per month, but this is an approximation and I haven't tested it.

[prissi]

Since those are ms internally, it would be 32 for real time. However, values larger than 24 will likely overflow some values (as the number is not linear, but exponentions, 24 instead 20 means 16 times slower passage of time).

[AP]

Since those are ms internally, it would be 32 for real time. However, values larger than 24 will likely overflow some values (as the number is not linear, but exponentions, 24 instead 20 means 16 times slower passage of time).

So it halves each time e.g. 31 is 50%-of-realtime, 30 is 25% etc?

[jamespetts]

Yes, I think that it does.

[AP]

Hmm - I know that, in Experimental, with 21 bits per month and 250m/tile , each game month lasts 6.4 game hours, but these game hours do not exist in Standard. About two game years will pass every real life day, I think, if the game is kept running at 21 bits per month, but this is an approximation and I haven't tested it.

Why does the 250m/tile factor in (or doesn't it?) - into the time calculations I mean. Speed presumably yes, but not time?

[jamespetts]

Ahh, no: because we don't actually change the real time speed with which vehicles move in the game when we change the distance, we change the time that is deemed to pass to travel that distance. So, a convoy will traverse X tiles in Y real time ms no matter what the number of meters per tile. But the number of in-game minutes represented by Y will change in proportion to the number of meters per tile so that the convoy will always cover the same number of meters in the same number of game minutes.