[Patch] Improved Timetable Management [V2.31tr SVN15778]

[PhilSophus]

This large patch aims at providing improved timetable management. It has the following features:

1. Virtual Time: A wall-clock-based time scale.
2. Arrival, Departure and Expected Time in vehicle timetables
3. Setting Start Times for vehicle timetables
4. Headway Management: Grasp the status of a shared timetable at a glance and keep your vehicles at a defined interval
5. Station Timetables: Show arrival, departure and expected times of vehicles stopping at a station.
6. Warning for very late vehicles: Configurable by patch option

To be done:

1. Fix the bugs you find
2. Cleanup the code
3. Start discussion with developers to get it into trunk step after step.

The rest of this posting gives you a more detailed impression of the patch.


1. Virtual Time

Have you ever been annoyed that timetables in the game are measured in days or even an artificial unit like ticks? Than this feature is for you. It introduces a second time-scale to the game, the virtual time measured in hours, minutes and seconds. You can configure the relation between virtual time and the traditional scale (which I will call calendar-scale for now) with patch setting between 1 virtual seconds per tick and 4 vsecs/tick yielding the following relationships:

Code: Select all

vsecs per tick | 24 Virtual hours equal about
---------------+--------------------------------
1              | 3 years  73 days (38.4 months)
2              | 1 year  219 days (19.2 months)
3              | 1 year   24 days (12.8 months)
4              |         292 days ( 9.6 months)
---------------+--------------------------------

You can enable display of the virtual time in the status bar by patch setting. The patch setting timetable_in_ticks was changed to timetable_unit and allows you to choose between days, ticks, HH:MM and HH:MM:SS. This setting works for both displaying and setting timetables.

Note: Virtual times are a GUI level concept, i.e. internally ticks or days are used and conversion between virtual time and calendar scale happens when displaying or setting data. This is why the virtual time settings are purely client-side settings. It is safe to use different virtual time settings on different clients in multiplayer.


2. Arrival, Departure and Expected Time

Have you ever seen a timetable in real world showing you how long the train drives / stops. Probably not. Usually they display arrival and departure times. And this is what this feature does: When the patch setting "show departure and arrival times in timetables" is enabled a new column is added to timetable windows showing the next scheduled arrival and departure times (actually it shows arrival and departure dates if you happen to set the timetable unit to days or ticks). When pushing the "Expected" button the expected times are shown instead, i.e. lateness/earliness is taken into account (earliness is not propagated past the next departure as the vehicle will just wait until it is on time again).

Note: Arrival and departure times are only shown for complete timetables without conditional orders and only for timetables that have already started (see the next section for an exception).


3. Setting Start Times

So, you want to create a tightly coupled headway system or just make sure that vehicles are equally separated? As a first building block you need to control the time/date the timetable is supposed to start. When a start date is set, the timetable is set to "not started", lateness is reset and when arriving at the first station lateness is initialized according to current time and intended starting time of the timetable. When a start time is set arrival/departure times are shown for orders before the current order even when the timetable is not started (this is the exception mentioned above).

This part is based on a patch by Maedhros.


4. Headway Management

To be rewritten for V2.00: Headway Management Window Details here.

To manage a whole line of vehicles more easily, this feature allows you to put vehicles with a shared timetable at a constant interval. The start time/date must be set for the current vehicle to be able to set an interval by clicking the "Headway" button. The interval is preset to the value leading to an equal separation between vehicles. This feature works by assigning start times of the requested interval to shared vehicles starting at the current vehicle and following the order the vehicles have on the track/road (so it should work for vehicles which are not able to overtake).

This part is based on a patch by MagicBuzz.


5. Station Timetables

This feature allows you to sort the vehicle lists accessible from station and waypoint windows by arrival and departure time (scheduled or expected) at this station/waypoint (vehicles with unknown times are put after those with known time and sorted by unit number). When you do so, arrival and departure times are shown below the vehicle instead of the profit. When pushing the "Expected" button, lateness/earlyness is taken into account.

A separate GUI for station timetables showing all types of vehicles in one window is now available. When you <CTRL>-click any of the vehicle icons of the station window, the integrated station timetable is shown. It features:

• Arrival/departure panel opening the timetable window of the vehicle when you click on it.
• Mini order list (as already in trunk for ships and aircraft) starting at the station the window is for (i.e. it always shows the next stations starting at this station, instead of starting at the first order).

6. Non-Destructive Auto-Fill

When <CTRL>-clicking the auto-fill button, the timetable is not cleared before auto-filling. The waiting time at stations is only updated if the value auto-fill just determined is larger than the currently set value. This feature is very useful when upgrading timetabled vehicles.

Thanks to Regiovogel for the idea.

Please vote for flyspray feature request #1124 if you would like to see this part in trunk soon.


7. Warning for very late vehicles

The patch option "Warn if vehicle is late" in the vehicles tab allows you to set a delay, which when exceeded by a vehicle, triggers a warning that the vehicle is very late. The warning also appears when the lateness is truncated due to being larger than the total timetable time if this patch option is enabled. The warning is shown at most every 30 days per vehicle.

Thanks to Eddi for the idea.


A. Known Issues

• The "Warn if vehicle is late" can only be set in days no matter what timetable unit you choose.
• This one is not really a bug, but a feature: Since, the headway function assigns the start time cyclically starting at the current vehicle, the vehicles between the current vehicle and the first order get a start time in the "next round". So, they are very early when they arrive at the first order and wait at the first station for a long time. You can avoid this by calling the headway function for the vehicle that next approaches the first station.

B. Compatibility Notes

A patch for the cargodest branch is attached.


C. Patch Settings

Patch settings in the Interface tab of the patch settings GUI:

• Show virtual time in status bar: Off, 12-hour, 24 hour
• Virtual seconds per tick: 1-4
• Show timetable in: Days, ticks, hours/minutes, hours/minutes/seconds
• Show arrival and departure in timetables: Off, On
• Show notice when vehicle has finished timetable autofill: Off, On

Patch settings in the Vehicles tab of the patch settings GUI:

• Warn if vehicle is late

D. History

• 2008-08-28 / V1.00 First public release
• 2008-08-29 / V1.01 Bug fixes:
  • Setting start date did not work in the calendar scale
  • CTRL-click "Headway" did not work in calendar scale when keeping the proposed value (reported by Tekky)
• 2008-08-29 / V1.10 Arrival/departure in station/waypoint vehicle lists
• 2008-08-30 / V1.20 Non-destructive autofill mode
• 2008-09-01 / V1.30 Warning when vehicle is late, text field for entering times, graphical glitches fixed
• 2008-09-03 / V1.40
  • Integrated station timetable
  • Warn of late vehicles at most every 30 days
  • Bug fix: Warning when lateness is truncated was missing
  • Bug fix: Station timetables assumed that the station was only in the order list once
• 2008-09-04 / V1.50
  • Interval is always preset for the headways feature (<CTRL>-click has no function anymore)
  • Don't refuse showing arrivals/departures completely when timetable is incomplete/has conditional orders but continue as far as possible.
  • Show mini order list also for non-timetabled vehicles in integrated station timetable
  • Allow to sort by expected arrival/departure time
  • Some internal rewriting
• 2008-09-04 / V1.51 Bug fix: Garbage arrival/departure times for non-started timetables
• 2008-09-05 / V1.52
  • Bug fix: Graphical glitches in arrival/departure panel
  • Featurette: When entering start time as time, don't assume it is in the future, but between 6 hours in the past or 18 hours in the future.
  • Some more internal cleanup (hopefully didn't break anything)
• 2008-09-06 / V1.53 Bug fixes: YAGG (Yet another graphical glitch), -6 to +18 hour window for start times not working correctly, headway tooltip corrected.
• 2008-09-11 / V1.54
  • Featurette: Show whether the timetable is already started (don't just show "on time")
  • (Kind of a)Bug fix: If you click headway on a stopped vehicle, don't ignore this vehicle as for other stopped vehicles. The user (hopefully) knows better what he does.
  • Bug fix: Only use timetable start for the intended start not for the last start as otherwise headway breaks.
  • Bug fix: Room for Mini Order List was reserved even for lists that don't have it.
  • Bug fix: Mousewheel scrolling was not working properly for vehicle timetable panel.
• 2008-09-15 / V1.55 Internal change: Order list rewrite
• 2008-09-18 / V1.551 (cargodest only) Bug fix: Loading games/the title screen could crash with cargodest
• 2008-09-18 / V1.56 Bug fix: Order lists were not properly saved, resulting in invalid savegames
• 2008-09-19 / V1.57 Bug fix: Display of group GUI triggered assertion
• 2008-09-19 / V1.571 (cargodest only) Bug fix: Connections were not properly updated when inserting orders
• 2008-09-20 / V1.58 Bug fix: Reloading NewGRFs resulted in trying to convert order lists a second time
• 2008-10-02 / V2.00 Headway has been rewritten completely. It features now a management window showing the state of a shared timetable in a well arranged way.
• 2008-10-09 / V2.01 Bug fixes: Several problems when unit was ticks or days. Make sure that headway features can only be used when at least two vehicles that are not stopped in depot exist.
• 2008-10-16 / V2.10
  • Auto-fill rounds to timetable unit selected when starting auto-fill
  • Auto-fill allows to set a minimum waiting time (just select a station with a set waiting time, when starting auto-fill and that time will be taken as the minimum time)
  • Bug fix: Edit boxes wouldn't accept unchanged settings
• 2008-10-24 / V2.11 Adoption to current trunk and cargodest. No new features or bug fixes.
• 2008-10-29 / V2.20 Headway window: Allow orders without vehicles to be selected and avoid order jumping for complete timetables in most cases.
• 2008-11-11 / V2.21
  • Featurette: Show group name of vehicle in vehicle lists when vehicle has no name.
  • Bug fix: Mouse-wheel scrolling was not working properly in station timetables.
  • Bug fix: Truncation of very late timetables did not work with headway.
  • Bug fix: Change date cheat totally confused headway.
• 2008-12-01 / V2.30
  • Show leader (^) and autofill (@) marker in headway window.
  • Show news item when autofill has finished (default: disabled).
  • Autofill & start headway (a leader vehicle must be selected, so that the interval button becomes enabled).
  • Bug fix: Clear lateness for leader when (re-)initializing headway.
• 2009-03-21 / V2.31tr (Trunk-only)
  • Bug fix: Re-initialize headway when last passing vehicle is removed during first round (e.g. by auto-replace)

E. Notes for Developers

This patch was developed as a series of smaller patches (21 so far) with Mercurial Queues which allows to separate the development of trunk and of the patches into two different tracks. Moreover, if parts of the patch should be included in trunk, the patch is already broken up into chunks which can be applied sequentially. I can only recommend warmly to developers planning a similar project to have a look at Mercurial queues. For me, it worked out quite well.

The project uses a versioned patch repository. If you like to do work based on this patch feel free to PM me for a Mercurial bundle of the patch repository.


F. Acknowledgements

• The setting of start times (dates), the GUI for setting dates and for setting times is heavily based on the timetable patch by Maedhros.
• The setting of headways is based on the timetable based separation patch by MagicBuzz.

[Eddi]

• When patch settings are changed when timetable windows are open graphical glitches may appear, especially when toggling the display of the arrival/departure column. The glitches disappear when closing and reopening the affected windows.

use the Window::SetDirty() function to repaint the window when changing settings, i'm sure there are plenty of examples in the code

• Selecting a number from a 60-entry drop-down (setting minutes or seconds) is a bit cumbersome. I'm open to suggestions how to improve the GUI for setting times.

select the digits separately, one dropdown from 0 to 6, and one from 0 to 9

alternatively, have a textbox and then parse the input as hh:mm:ss

i'm definitely gonna try this out, the feature is really needed

[PhilSophus]

• Selecting a number from a 60-entry drop-down (setting minutes or seconds) is a bit cumbersome. I'm open to suggestions how to improve the GUI for setting times.

select the digits separately, one dropdown from 0 to 6, and one from 0 to 9

I considered that, but to be honest I didn't like that this much, either, as you have to select so many dropdowns.

alternatively, have a textbox and then parse the input as hh:mm:ss

Something like that was also in my mind. And maybe that's really the best solution although not looking that fancy.

[_Robbie_]

Looks great! I integrated it with CargoDest, and so far it works. One thing you may want to add is virtual time counter somewhere nearby current "real" date, as right now it's impossible to see current virtual time (or is it?).

Partial solution to your problem with dropdown menus might be making some buttons with "predefined" times, like 1min, 2min and so on. Something like on the picture in attachment.

[PhilSophus]

Looks great! I integrated it with CargoDest, and so far it works. One thing you may want to add is virtual time counter somewhere nearby current "real" date, as right now it's impossible to see current virtual time (or is it?).

There is a patch setting "Show virtual time in status bar" in the interface section which does just that. It can be set to "Off", "12-hour" and "24-hour" format.

Edit: I added a "Patch Settings" section to the top post so that they are not this hidden in the text.

[bokkie]

If you happen to have a Windows binary with this patch and paxdest I'd be happy to test it

[PhilSophus]

Sorry, I have only a Linux build environment.

Maybe another user could compile for Windows and post it here (maybe also a version with clean trunk). That would be great. I would put links in the top post then.

[Tekky]

Your patch looks great! In the current trunk state, timetables are not very useful. But this patch makes some very important additions, making them a lot more useful.

However, I have found the following bug:

When you CTRL-click "Headway" in the timetable window and then press ENTER or click "OK", the value in does not take effect. It only takes effect if you enter a different value. Therefore, I must CTRL-click "Headway" in order to find the ideal separation and then click "Headway" again (this time without holding CTRL) in order to enter this value manually.

[Zuu]

Win32 build using plain nightly r14180.

It complains that it don't find generic_trams at startup for me, don't know why if it is an issue with the patch or because of me missing something.

I've:
* Checked out r14180 with TortoiseSVN
* Applied patch with TortoiseMerge (takes lot of time compared to patch as it seams to like to display what it is doing which of course takes time. If anyone knows how to use it in silent mode I'll be happy to know)
* Compiled using VS 2005 Express (Release target)
* Copied openttd.exe to bin-folder
* Renamed bin-folder
* Added the patch-file in the folder for reference
* zipped it

[PhilSophus]

When you CTRL-click "Headway" in the timetable window and then press ENTER or click "OK", the value in does not take effect. It only takes effect if you enter a different value. Therefore, I must CTRL-click "Headway" in order to find the ideal separation and then click "Headway" again (this time without holding CTRL) in order to enter this value manually.

This is strange. I can reproduce it. But when looking at the code, I do the same thing as is done for "Change Time", but there it works and with "Headway" it doesn't. I'll have a deeper look at it tomorrow.

Win32 build using plain nightly r14180.

Thank you, I'll add a link immediately.

It complains that it don't find generic_trams at startup for me, don't know why if it is an issue with the patch or because of me missing something.

I didn't touch anything close to that at all. But there was some fix relating to NewGRFs in r14182, so maybe there was a bug in trunk. My patch should apply to r14182 cleanly, so you may try if it's solved.

[Brianetta]

PhilSophus, you are an absolute darling. A browse of the IRC logs will show that I've been pining for this for months! You're my new hero.

A. Known Issues

• ...
• Selecting a number from a 60-entry drop-down (setting minutes or seconds) is a bit cumbersome. I'm open to suggestions how to improve the GUI for setting times.

I'd recommend using the left-right selector, as seen in the "Place signals every..." and "Service interval" patch settings.

[PhilSophus]

When you CTRL-click "Headway" in the timetable window and then press ENTER or click "OK", the value in does not take effect. It only takes effect if you enter a different value. Therefore, I must CTRL-click "Headway" in order to find the ideal separation and then click "Headway" again (this time without holding CTRL) in order to enter this value manually.

This bug (and another one that made it impossible to set a starting date in the calendar scale) is fixed in V1.01 which is now attached to the top post.

[dbkblk]

That sound fantastic !!
Is there a way to compile it with the cargodest patch ?

EDIT: Hmm i dunno how to do it :s

[PhilSophus]

Is there a way to compile it with the cargodest patch ?

Umm, by applying the attached patch, maybe (this is for the newest Mercurial revision of cargodest, i.e. e79bdd28d8bb)

Edit: Updated patch in top post

[Regiovogel]

Well, so somebody should only need an option to compile it, then.

- BuildOTTD doesn't work anymore (at least for me, even with the patched version in the thread it doesn't give any more than "unknown patch format" for most of the patches or - if they would work - it complains about path names)
- Visual Studio seems to take some years before doing anything - but that again doesn't matter, TortoiseSVN doesn't like the patch file at all...

So I'm hoping for a precompiled Win32 binary...

BTW: Nearly forgot to say something about the timetable patch. I tested the version posted above, it's great! Hopefully this patch (or at least any patch with working vehicle separation...) will make it into trunk.

[el koeno]

I'm currently busy with a nice game, so I won't check this patch out for a while, but I have a question regarding Headways, which really is the only feature in this patch which I would use. How much user intervention does it take? In MagicBuzz's version you still had to do quite some micromanaging of your lines (e.g. when upgrading vehicles) to ensure proper separation. Personally I just want to click a single button and have acceptable separation, and not have to worry about timetables at all.

[PhilSophus]

I'm currently busy with a nice game, so I won't check this patch out for a while, but I have a question regarding Headways, which really is the only feature in this patch which I would use. How much user intervention does it take? In MagicBuzz's version you still had to do quite some micromanaging of your lines (e.g. when upgrading vehicles) to ensure proper separation. Personally I just want to click a single button and have acceptable separation, and not have to worry about timetables at all.

I'm afraid, it is almost the same as with MagicBuzz's patch in this regard since headways need a complete timetable. So after upgrading you need to auto-fill the timetable again and modify it to provide for some overhead. Then CTRL-click on Headway would do the rest.

What would help you here is kind of a "continuous auto-fill" and on-top of that a "continuous auto-separate" feature. But this doesn't really fit into this patch as this is about controlling the timetables manually.

As I'm quite familiar with the related code at the moment, I might provide such a patch, after I'm done with all the main features of this one (working at station timetables at the moment). But I can't promise as I'm not sure if I'll have the time for it.

[Regiovogel]

If you implement such a feature like the "continuous auto-fill", I would like to have a possibility to disable this behaviour as it can lead to problems if you want the trains to go into some sidings before they go again on their lines. By setting the time for driving into the sidings to a high value, they can reduce delays and are able to go back on time.


When clicking autofill in an already filled timetable, it would be quite useful to
- keep the times at the stations
- overwrite times between stations without clearing them immediately

This way, an existing timetable with many vehicles using it wouldn't be broken.


The very best would be to have a system that precalculates the time between two stations... but I don't think this can be done with reasonable effort.

Enough wishes for now, keep up the good work!

[PhilSophus]

If you implement such a feature like the "continuous auto-fill", I would like to have a possibility to disable this behaviour as it can lead to problems if you want the trains to go into some sidings before they go again on their lines. By setting the time for driving into the sidings to a high value, they can reduce delays and are able to go back on time.

As I said: Not in this patch, anyway. And if so, I would make it a patch setting.

When clicking autofill in an already filled timetable, it would be quite useful to
- keep the times at the stations
- overwrite times between stations without clearing them immediately

This way, an existing timetable with many vehicles using it wouldn't be broken.

Now, this is a good suggestion that would fit nicely into this patch and should not be very complicated to implement (I think there already is a similar patch in the forum, which I might even "steal" ). This feature just reached my TODO list.

The very best would be to have a system that precalculates the time between two stations... but I don't think this can be done with reasonable effort.

No, I don't think so, either. You would need know which path the vehicle takes in advance, how fast it accelerates (in the plane, on slopes), how long it has to wait for other traffic, etc.

[Regiovogel]

(continuous autofill)

As I said: Not in this patch, anyway. And if so, I would make it a patch setting.

So special features timetables won't be broken by your patch anyway, I just wanted to assure that

(keeping old times with autofill)

Now, this is a good suggestion that would fit nicely into this patch and should not be very complicated to implement (I think there already is a similar patch in the forum, which I might even "steal" ). This feature just reached my TODO list.

Sounds cool. This should make upgrading to better vehicles easier without getting jams...

(precalculating times)

No, I don't think so, either. You would need know which path the vehicle takes in advance, how fast it accelerates (in the plane, on slopes), how long it has to wait for other traffic, etc.

I also thought about that. Even if you don't take other traffic into account, there will be too much dependencies to get reliable times. Although it would be quite useful to have some estimated values for the travelling times, which could also be a bit higher than they will be in reality... so one could start a line with 5 trains that are well separated from the beginning. You could use autofill later on to get the "real" values...
Would be great, but I don't think this can be done. I suppose it would be rather difficult to calculate this...

Looking forward to upcoming versions,
Regiovogel