123.0 Stable Release (r10317) - scheduling window bugs

[KneeOn]

This is attempt 4 at posting this report!

Three minor bugs on the latest stable release using the packaged pak64
1. When show month is set to 3 (the default) and a month is represented by the clock as x number of 24 hours days the dates are 1th, 2th, 3th, 4th, 5th rather than 1st, 2nd, 3rd, 4th 5th.
2. When show month is set to 1 and a month is represented by a single 24 hour day (and each in game minute it much slower than if it were 31 days), when setting departures/month to start at dd-hh-mm, the time entered in that box does not correspond to the time in game as represented by the clock. Indeed, that doesn't correspond on show month set to 3.
3. The division of time is not exact - so times do not go up equally.

The maximum number of departures a month is 154.
On show month = 3 and any dd-hh-mm per month on the game clock, this equates to a convoy every 4 hours and 21 or 22 minutes.
On show month = 1 and any other where it is hh-mm per month on the game clock, it is a convoy every 9 minutes.

I did suspect bits per month may be the deciding factor, so I increased this from 20 to 24 however it has had no effect on the maximum number of convoys in a month which remains 154.

Where does 154 convoys per month come from?

I prefer playing clock face games, but even on a month by month game with a "x convoy(s) per day" timetable, or just in general, having even divisions are important. I've not been able to do an hourly one because time gets lost and fluctuates.

On show month = 1, 24 convoys per day should equate to an hourly service. Changing the first at (dd-hh-mm) interval setting should make the clock face work in a fairly uniform manner (i.e. 24 convoys per month first departing at 00:01, should then be at xx:01 until it wraps around, at exactly 1hr intervals based on 24hrs/24 convoys = 1convoy per hour) It does not after the 4th convoy in that month. The time are 00:00, 00:59, 01:59, 02:59, 03:59, 04:43, 05:43, 06:43, 07:43, 08:27, 09:27, 10:27, 11:27, 12:11, 13:11, 14:11, 15:11, 16:11, 17:55, 18:55, 19:55, 20:55, 21:39, 22:39.

Clearly I have 24 services, one for each hour, which does not run at hourly intervals. I changed this to 23 convoys per hour to make sure. The times go up just as randomly, 00:00, 01:02, 02:05, 03:07, 04:10 05:57, 06:59, 07:02...

If the maximum number of convoys is hard coded, then the description of dd-mm-hh should change to something which can be reflected in the window, possibly by making the text change with whatever show month is set to. Without knowing how the dd-hh-mm is arrived to for each mode, I don't know quite what to suggest but it appears 154 equates to 9 minute/4h22m intervals. When it equates to 9 minutes, the minutes start to change in the game clock when the interval clock is increased by 3.

Furthermore, the more services per month there is a lower maximum number in the minutes box in the interval clock. So with show month = 1, when there are the maximum convoys (154), the minutes in the interval setting only goes up to 28. This appears to be because on that clock when the minute interval setting is 0 the times are 0h00m, 0h09m, 0h18, 0h28m. When set to 28, it is 0h09m, 0h18m, 0h28m, 0h37m.

So to summarise:
Minor bug with the displaying of the 1st, 2nd and 3rd as 1th 2th and 3th of the month.

Minor bug in that it is functional but it doesn't work as intended where the division of time isn't equal in any month mode and in a show month mode where the month is represented as a whole day, the time when setting the interval doesn't equate to the time in the game.

[prissi]

At setting 1 the month is represented as three days of 24h, not a single day. At least the difftick code in simintr.cc (which displays the bottom time) does this. Sinewhat this was changed without changing the other code. I fixed this in r10335 to 24h per month.

Numerical plural rules are a nightmare, slawik languages have another set of rules.

The departure setting precision is 65535 ticks which is a little more than minutes per month, so there can be rounding issues. The 154 is due to using the remaining bits in the existing structure from the loading limit.