Say a cycle 2^22 ticks long, independent of the bits_per_month setting.
If you happen to play with 22 bits per month, it syncs up perfectly
If you happen to play with 20 bits per month, you set the schedule for four months at once.
If you happen to play with 24 bits per month, you can only set the schedule for a quarter of a month, and the other quarters will be repetition.
Tick 0 could be something like the first tick of the first month of year 0. That would mean with 20 or 21 bits per month, tick 0 would be (beside others) the beginning of each year, with 19 bits per month, it would be the beginning of each even year, with 18 bits per month, it would be every fourth year, and the gap doubles from there. This would be consistent for network games, and can be grasped by a player.
As far as using such a system internally, sure. However, one could be extra clever about it.
> The ticks don't sync up to displayed time nicely. This would not matter if the player could actually operate at tick precision and choose a value between 0 and 4194303, but that sort of precision seems too much when practically, it's probably enough to go with seconds. I suggest a time unit consisting of 728 ticks. Of this time unit, 5760 would make up a cycle. If that cycle lines up with the month, each unit would be displayed as 7 minutes and 30 seconds. Therefore, at bits_per_month=21, you can use quarter hours to set your schedule, and at bits_per_month=20, you still use full hours. It's pleasent down to 17bpm and 8h precision, though I wonder if such short bpms are used.
Of course it does not line up that nicely in reality, using 5760 units of 728 ticks length does not fill all 22bits, but rather leave 1024 ticks unaccounted. Those are just the last bits in which no schedule happens. The imprecision you get from that is about a second, it hardly matters in practice.
A train schedules for time.unit 5759 would be displayed as "30th day, 23:52(:30)", but it would actually depart at tick 4192552, which in a 30-day month would be "30th day, 23:42". Really insignificant, considering we also have 31-day-months, at which the same train would depart on the 31st, but we surely don't want the displayed schedule to shift likewise.
> Even if the cycle has a fixed length internally, that might not need to be shown to the player. I think it would still make more sense for them to say "I want 3 trains per month" rather than "I want 12 trains over the course of a cycle that is 4 months long". This option should be unchanged. If you play with bpm 23, you simply can only use even numbers for the number of trains per month, since it's the same cycle twice, and divisible by 4 in bpm 24. However, this would not go the other way, with quarter-trains-per-month in bpm 20. Likewise, under normal circumstances a manual timetable would always be planned for a month, and if a cycle contains several months, the others are simple repeats. Some kind of "Use monthly schedule" setting which is on by default, and needs to be turned off to allow time units that reach in the next month, while simultanously turning the month-cycle off. Essentially, from the players perspective, everything is set up using in-game time values and monthly cycles, while in the shadows, it's converted to ticks on a fixed cycle length.
Recent Posts
And when I get a problem it's usually that I mis-clicked and placed a stop signal instead of a distant signal thus trains slow down where they should not.