Getting rid of the mysterious division by 3

[neroden]

I am eager to get rid of the mysterious division of revenue by 3.

I can push the division down a very long ways, to the point where it is applied upon loading of paksets.  But it would be ideal to have the numbers specified in the .dat files be "normal" rather than divided by 3.

I am not sure how to do this as it is an incompatible change to pakset format.

I had one idea.  Revenue specification has changed in experimental.  We could retain compatibility with standard paksets by dividing "value" by 3, but *not* dividing by 3 if fare stages are specified.  This would, however, break compatibility with recent versions of pak128.britain.experimental (and anyone else using fare stages).

I had a second idea.  I have been itching to change the way fare stages are specified to be slightly cleaner: instead of

Code Select Expand


value[0]=60
to_distance[0]=16
value[1]=50
to_distance[1]=32
value[2]=47
to_distance[2]=0

I want to see:

Code Select Expand


value[0]=60
from_distance[0]=0
value[1]=50
from_distance[1]=16
value[2]=47
from_distance[2]=32

For reasons which may be obvious.  You'll see that it means the same thing.  If we specified a new way of specifying fare stages, *this specification* could be the form which isn't divided by 3.  (We could also allow for specification of numbers smaller than 1 simcent, or of distances smaller than 1 kilometer, while we're doing it.)

[jamespetts]

This is very interesting. I still do not fully understand why we have a division by three: it is an ancient, Hajo-era legacy from Standard.

However, one thing to consider before going all out to implement this: I plan, in the fairly near future, to implement a system of price factorisation/indexation in Experimental, so that price multipliers (the "neutral" multiplier being 100) for all costs and revenues can be set in .dat files, and, furthermore, set to vary over time. The idea of this is twofold: firstly, to enable much easier balancing of types of costs as against each other, and secondly, to allow the simulation of inflation (and variable relative rates of inflation, such as rising costs of labour), which has important economic consequences. Such a system would allow us to have a default of "33" instead of "100" for prices loaded from paksets whose goods.dat file is below a certain version. That might be the cleaner way to do it, I think.

[prissi]

Hajos idea back then was to use 3 to get higher precision, since a revenue of 3.33 is very different from 3. It is therefore a Hajo era legacy, and all pakset have it this way.

[jamespetts]

Thank you - it is useful to know why it is there.

[neroden]

Such a system would allow us to have a default of "33" instead of "100" for prices loaded from paksets whose goods.dat file is below a certain version. That might be the cleaner way to do it, I think.

That would be extremely elegant.  Indeed, let's do it that way.

[jamespetts]

Indeed, even more elegantly, we don't need to detect the pakset version at all: we can just supply the planned prices.tab by default with "33" for unmodified paksets, and hand-alter it to (a base of) "100" for modified paksets.