I had already posted this in the month

Month length in hours: reference sheet a few weeks ago but that was at a time where the forum had huge trouble so I don't know if anyone could read it and I guess it's worth a discussion thread on its own so I moved it here.

First, I want to thank both of you, Carl and Matthew, for this reference sheet, it's nice work!

However, I had some thoughts about month lengts and distances. The current time per month doesn't really satisfy me, as I recognized users being confused of 1:04/32/16/8... minutely schedules and 6:24:00 hours long months when it comes to calculating schedules, thinking in "half hourly" services, where these are actually 32 minutely

What do we want?Ideally we want

- round meters_per_tile values

- round time per month values

- round schedule times for as many "schedules per month" values as possible

Currently, we can not achieve this due to some odd ticks to second conversion.

The first point ist obviously fullified, if a round meters_pe_tile value is set in the config.

The second point depends on the definition of "round time per month". I would define it: ~"we have a round time per month, if a month length is a multiple of a full hour" This is obviously fullified, if the calculated seconds per month is a multiple of 3600, which is

currenly only the case for meters_per_tile values that are multiples of 625. Multiples of 125 will at least have full minutes. Anything else will be odd.

The third is a bit vague as "as many as possible" is not pretty well defined.

However, we will get many round schedule times, if our month length in minutes has many divisors.

360 or a multiple of it is a good number for this, which would be a month length of 6:00:00 or a multiple of it.

btw. angles in degree use 360° for a full turn because it is a relatively small number with many divisors.

Now we know what we need.

How can we achieve it?A possibility would be simply altering the ticks to seconds conversion function by multiplying currently returned value by 60/64, so what was 6:24:00 before will be 6:00:00 now. As this is just a visual effect, I don't expect that change to negatively affect schedules, as these are still exactly the same in ticks.

Currently that function is

`get_settings().get_meters_per_tile() * ticks * 30L * 6L / (4096L * 1000L)`

We could change it to something like

`meters_per_tile * ticks * 27/(4096*160)`

That way we will get a month length of 6:00:00 for 125 mpt, 22 bpm

If vehicle movement speeds matches to the time currently displayed time, that means a vehicle travelling at 100 km/h for one hour in a mpt 100 world, will travel 1000 tiles, and we consider that consistency to be important, we would also have to apply that 60/64 factor to simmulation speed, which could be a slightly larger job, I didn't look at this.

As there is a comment in the code mentioning that we should seperate the time scale from meters per tile, I don't expect it to be important. To seperate it, we could do something like this:

`time_scale * ticks /2^18`

That scales month length to be 00:00:01 for 18bpm, time_scale 1.

To get 6:00:00 months at bpm 22, we would set a time_scale of 60*60*6/2^(22-18)=60*60*6/16=1350

If no time_scale is given, we could use meters_per_tile*11.52, so we would get the same month lengths as before, or alternatively meters_per_tile*10.8, so we would get 6:00:00 instead of 6:24:00

Alternatively, we could also eliminate bits_per_month

`seconds_per_month* ticks /2^bits_per_mont`

That scales month lengths to be always 00:00:01 for time_scale 1, no matter the bits_per_month nor meters_per_tile.

As this is straight forward to use for pakset developers, I don't think we should do this, as players sometimes prefer more or less bits_per_month and changing bits_per_month should imho scale paksets default month length.