PeterN
commented
2 weeks ago I've not looked too in depth but I don't think 'approximately' needs to be abbreviated here.
Also, we require rebase instead of merge to keep up to date :)
Open flowprint opened 2 weeks ago
PeterN
commented
2 weeks ago I've not looked too in depth but I don't think 'approximately' needs to be abbreviated here.
Also, we require rebase instead of merge to keep up to date :)
flowprint
commented
2 weeks ago Rebase, ok. Thank for mentioning :)
Motivation / Problem
When using days as display style for the timetable, two lines with the same total timetable duration may run out of sync. The internal precision in the timetable calculation is done in seconds even if the display mode is days. The total duration can be one second (half a day) off without noticing due to rounding to full days in the GUI. Unless the client switches display style to seconds or ticks and checks all timetables.
Description
First, when using days as display style for timetables, set the internal precision also to days (74 ticks). This way the total duration will be exactly what is shown in the timetable. Second, for savegames where this problem already occurred and for cases, where the client manually altered the seconds or ticks of the timetable, perform a check if the displayed total duration is the exact duration. If not, insert an "approx." before the days/seconds in the GUI so the client knows that the actual duration differs slightly from the presented. The client can then correct the seconds or ticks if desired.
Limitations
The expression "approx." only appears for the total duration so far and not for each individual order to keep strings short and the timetable window narrow. This could still be added if desired. I would suggest defining a new "approx." string and insert it into existing strings if needed, rather than creating more duplicates.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.