Prissi commited r9504 that makes players to set waiting time in days, hours and minutes. After testing the feature, I had a few concerns about this change.
- How long are days, hours, and minutes? In simutrans, one month has the same length defined with bit_per_month, and days are the divisions of the month with the number of the day in the month. The number of days is different between months, for example, January has 31 days and February has 28 days. So how long is a day in the schedule setting? That is so vague for players even if you described it in this forum. At least, the Japanese community was pretty confused about the length of a day.
- The interface to set the waiting time is controversial. To set the waiting time to more than one day, you have to press the button for a certain period of time. There is no way to set the waiting time in a second, as it was possible with the conventional interface.
- The new feature has a compatibility issue in UI. Most of simutrans players are familiar with the conventional interface and can be confused when they see the new interface in the first time. They are familiar with the unit such as "1/16 month" and "1/64 month". It needs some calculations to set the waiting time to 1/16 month in the day, hour, and minute unit.
I think a discussion should have to be held for changes that forces a new thing for all conventional players. At least, an introduction should be posted immediately after you commit it to the nightly trunk.
Actually, when the waiting time feature was introduced in fractions of a month, most commented that this should be rather in days, hours and minutes ...
A month in SImutrans always has the same length (1<<bits_per_month) no matter if February or July. The waiting time is just these ticks, for a month with 31 days. For a 30 day month the waiting time is the exact same amount in ticks, although the display in days etc. will be slightly off. Moreover, on the short setting, a month has just three days. (This is also taken into account.)
The ticks, that can be set are 16, which means 0...65535. Since a 31 day has 44640 minutes, this is enough for minute precision.
Since this feature was ment also for the introduction of real scheduling (i.e. departure at a certain ticks since start of the month), it was like this setting. Even the old feature could have used a much fine graduation, but it was just discarded. (And is still discarded right now on saving.)
But I am open on how to input a finer setting. What do you suggest? A number-input for ticks and a connected approximate display of days, would that be better?
I think a number input for ticks is better. The waiting time can be set with only one value. Days, hours and minutes should be displayed only for reference because they have ambiguity for their length.
Ticks for time scheduling can be 16 bit but it may be too fine for players. In my forked version, departure time is set in the time unit which has 1/1440 of a month. The length of the time unit is configurable. See more from here. (https://github.com/teamhimeh/simutrans/blob/OTRP-distribute/documentation/OTRP_information_en.md#specify-departure-time)
16 bit was choosen for those, who would run Simutrans as a model railway and thus want something resembling real time.
EDIT: please check r9516
r9516 seems to be good as a design concept, but it contains a bug. Waiting time does not sees to be correctly saved after editing the schedule. In my map, I set the waiting time 3600 for a stop in a line window but it changed to 16 after I close and reopen the line window.
And, the number input should be disabled as long as the schedule entry is not selected or the minimum loading is 0.
Since in the old saving, only the most significant bit was stored (128 was saved as 7) there is a great loss of precision. This will be fixed when the save game version is increased. However, 3600 should be roudn down to 2048 upon saving. I will investigate.
I am not 100% sure how to implement the visial differences between a schedueld departure and a relative waiting time. I think there will be a combo box.