Automated timetables and separation

[Gathers]

Here is another timetable and separation patch, with two simple goals. First; to implement a "setup once and forget" mode for timetables. Second; to add automatic separation of vehicles.

This patch was inspired by this patch from MagicBuzz but handles separation in a new way.

Vehicles now examine only their position relative to the vehicle directly in front and the vehicle directly behind. To quote the code:

Code: Select all

v->lateness_counter = (separation_ahead - separation_behind) / 2;

The patch adds two new options:
"Automatically manage timetables" - Enables timetables to be automated.
"Use timetable to ensure vehicles separation" - Turns on separation for all timetables.

To automate a timetable, click the Automate button where Autofill used to be. To stop using a timetable, simply click Automate again and all times will be removed. If you ctrl-click Automate when it is active then the automatic updating of times will stop but all the times will remain and the vehicles will keep running on a static timetable.

When Automate is on everything should take care of itself, and one should never have to open the timetable window again to adjust values. Both loading and travel times can automatically increase or decrease as the game progresses, and times for new orders are added automatically as well.

So when you add new vehicles, add or remove stations, upgrade to faster vehicles or redesign the network you will not have to adjust anything in the timetable yourself. All of these changes should only create temporary disturbances that will eventually go away.

A timetable that has been automated will start when the vehicle arrives at any station and stop (until arriving at another station) when the vehicle is stopped, sent to a depot or an order is skipped. This way you can still manually make vehicles skip orders etc without it messing up the times in the timetable.

At least these are all the ideas but this is still a work-in-progress.


Feedback welcome!

I'm new to the openttd-codebase so there are probably better ways to do some things.
I'm aware of the Improved Timetable Management patch and will look at it closer for inspiration.


Enjoy!

Apply patches with patch -p1

Latest binaries:
Version 0.6 by Wouter here.
Thank you for taking the time to build and post these!
(since I've never tested it myself; use at your own risk etc, etc. )


Automated timetables and separation
Version 0.1 - barely works?
Version 0.2 - less ugly code, more stable separation.
Version 0.3 - separation improved, misc fixes.
Version 0.4 - small fixes to order times adjustment.
Version 0.5 - faster separation, hopefully, and misc cleanups.
Version 0.6 - separation logic rewritten.
Version 0.7 - try to handle large deviations like jams by restarting timetable.
Version 0.71 - small bugfix regarding removing shared orders.
Version 0.72 - minor bugfixes, crash when de-automating with no orders fixed.
Version 0.8 - via-orders fixed, ctrl-click behaviour inverted, conditional orders should be less bad.

Todo:
Better GUI-integration?
Try having vehicles begin to separate even when timetable is very incomplete.

[bokkie]

Sounds like everything I ever wanted Just kidding, but chances are I'll try it if I find the time (if there's a build that time is found sooner . I'm curious about how good auto-timetabling works! If trunk-inclusion is a goal someday you might want to consider splitting the patches. I don't know if and how much they rely on each other to work but smaller patches = easier to review and less prone to bugs = bigger chance of inclusion in trunk. If I understand correctly that is and first it will need testing, which is where we come in.

[Gathers]

Sorry about there not being any binary but I'm on linux and I'm sure most people would be interested only in a windows build. I know there are ways to compile one from linux but, well, others can probably make a win-build both much faster and better than I.

You are right about smaller changes being easier to review, and locally I keep everything split up in two branches with smallish commits, so that part is no problem. I just squashed them into one now since they're more fun together.

[petert]

Hello all,
Here's a binary, built on MSVC for Win32, since you guys were asking for one.

Disclaimer:
If Timetables crashes, do not report it to the OpenTTD developers. Report it to this thread. When making your post about the crash, please upload the crash.dmp, crash.log, crash.sav, and crash.png (only available as of r18184, so if you are using a build older than that, don't bother). These files are vital to finding what happened during the crash. Also note that the PDB file attached is not needed when testing Timetables, it is mainly for developers.

Peter

[Gathers]

Hehe, thanks for the quick build!

Is it with or without cargodist?

[petert]

Without, did you want one with?

[Gathers]

I'm fine either way. If someone wants to test it with cargodist, let them chime in.

I just want to hear someone say, "Hey, it works!" or "Oh, it broke.."

[pavel1269]

Code: Select all

+	SDT_CONDBOOL(GameSettings, order.timetable_automated,                       67, SL_MAX_VERSION, 0, 0,  true,                    STR_CONFIG_SETTING_TIMETABLE_AUTOMATED,    NULL),
+	SDT_CONDBOOL(GameSettings, order.timetable_separation,                      67, SL_MAX_VERSION, 0, 0,  true,                    STR_CONFIG_SETTING_TIMETABLE_SEPARATION,   NULL),

Why you made it, as the option is in ottd since savegame version 67? Doesnt it break the savegames?

[bokkie]

Thanks Peter! Saves time, I should have an environment set up somewhere but before I can make a succesful build we're probably an hour further in which I cannot play with this patch.

Good news, the basics work! Timetabling and seperating work. It adapted surprisingly well to the following situations:
- adding a vehicle with shared orders. At the first order, all vehicles were seperated again nicely.
- servicing not part of an order. It took a few months for the vehicles to get seperated again nicely so at first I thought it couldn't cope with this situation, but eventually it did! (Smart thing to do would probably be to add servicing in an order, but I was just testing).
- rerouting a part of the route (makes travelling time longer). Took like 5 rounds before it was corrected, but eventually it did.
- adding a crossing with a train network which added a variable amount of time to some vehicles, in some rounds. Again, it took like 5 rounds.

In conclusion, it seems to work like a charm. In some situations, manually adding some extra time to a non-crowded first or last stop would work better than automating because then 'lateness' would be corrected in 1 round but automating really works good and removes the need to micromanage. I don't know if it's possible to get the same good results while making it correct the timetable a bit faster? Isn't really necessary but that would make it more smooth. I tested it only on a few road vehicles for a few minutes though so more extensive testing will be needed. Adding a Cargodist build will make me test it even more .

EDIT: maybe this patch also serves as an inspiration since it's made by a dev: http://www.tt-forums.net/viewtopic.php? ... 6&start=20 . Reading back on the different patches, ITIM improved on MagicBuzz's patch quite a bit (not only adding features but also in the auto-separating department). Take a look at this post if you want to use ITIM: http://www.tt-forums.net/viewtopic.php?p=827835#p827835

[Gathers]

Why you made it, as the option is in ottd since savegame version 67? Doesnt it break the savegames?

That's a good question. It's probably a mistake so I'll investigate..

In conclusion, it seems to work like a charm. In some situations, manually adding some extra time to a non-crowded first or last stop would work better than automating because then 'lateness' would be corrected in 1 round but automating really works good and removes the need to micromanage. I don't know if it's possible to get the same good results while making it correct the timetable a bit faster? Isn't really necessary but that would make it more smooth. I tested it only on a few road vehicles for a few minutes though so more extensive testing will be needed. Adding a Cargodist build will make me test it even more .

Thanks, glad to hear it worked for you as well. I have also noticed that getting back to a nice separation is sometimes fast and sometimes slower. It can probably be improved, just need to figure out how to make it work in all different scenarios.

Maybe at the start of each round it could find the most late vehicle, take that lateness and divide by the number of orders to get a time, then add that time to each order. That should make the whole timetable slow down until everything is on time, and when it is the times will automatically drop back to normal since they'll be adjusted down as vehicles travel faster.

[petert]

Perhaps you should link to binaries in my posts, so that you don't get that asked so often?

A binary with Timetables and CargoDist are coming up.

Edit: Timetables and CargoDist don't apply cleanly together, no binary coming...

[Gathers]

Oh? I tested against git 268bb03e596e9838 and the patch applies cleanly for me. Checking out svn r18533, applying cargodist and then applying my for-cargodist-patch should work and give the same result.

[Gathers]

Patch updated and improved.

Now separating vehicles should never take forever, even if the changes only occurs gradually and might be slow on very long routes. It also tries to compensate for random travel-times by adding more time to station loading orders if vehicles often arrive too late or early. These loading times might go down only slowly, but if things improve they will eventually go back to a more ideal loading time.

Things like keeping a vehicle with shared orders stopped in a depot should also work (without leaving an empty slot where it should have been) although there are still be some bugs here. Stopping every vehicle except one, for example, does not work.

[audigex]

Out of interest, how does the automatic updating work? Does it just average the train times over a round and then adjust the time based on the difference between that and the time currently stored?

[Gathers]

Basically, whenever a vehicle arrives or departs a station, the travel or wait time is updated. The new time is currently calculated something like this:

1. Update running average of how much "off time" vehicle is. (always positive)
2. Calculate new order time:

• new_time = "time the order just took to execute"
• if arriving at station, then increase new_time by adding average "off time" plus 20 ticks (just so that there is extra time somewhere so late vehicles can catch up and to compensate for small random delays)
• increase/decrease new_time by adding lateness/10 (decreases new order time if vehicle is early, increases if it is late)
• update running average (new_time = current_order_time * 0.8 + new_time * 0.2)
• change timetable so the current order takes new_time

2b. If the duration of the whole timetable was made longer, then make all vehicles be slightly later. If the duration of the whole timetable was made shorter, then make all vehicles be slightly earlier. (I'm not sure if this makes much sense, it's just something I tried and I'll probably remove it.)
3. If a vehicle just arrived at the first order on the orderlist, then compute the "average lateness" of all vehicles and shift all vehicles towards being on time on average. (e.g. If there are two vehicles that both are late, this makes them both less late. If there are two vehicles, one a little late and one very early, this makes the late one more late and the early one less early.)

This is probably too complicated but at the moment I'm playing around with a lot of stuff to see what makes sense and what does not. When a formula that works good for most cases is found the redundant steps can be stripped out again.

[bokkie]

Sounds interesting! I'll try to get to it the next few weeks. Funny that a lot of people seemed interested in separation in the Cargodist thread but nobody posted here... if only someone could make a binary to lower the treshold to try it Have you gotten around at looking at the other (old) patches as well?

[Jimbow]

This patch sounds very interesting indeed!

I will save much work for me, if the vehicles has automated timetables and separation.

It could be cool if you could make the patch work also if a daylength factor are added to the game.
If you set a minimum waiting time to 20 ticks, this can be a very long time, if you play with a deylength factor. So if it was possible to make the waiting time variable according to the daylenght factor it could be nice.

I hope you understand my suggestion, because i think it's sad if your patch didn't work with daylength factor increased.

[peebee]

@ Gathers
So this patch and CargoDist works toghether? If the answer is yes it'll be nice if you could load up a binary.

[WWTBAM]

Perhaps you should link to binaries in my posts, so that you don't get that asked so often?

A binary with Timetables and CargoDist are coming up.

Edit: Timetables and CargoDist don't apply cleanly together, no binary coming...

[Terkhen]

I like the simple approach to this feature. From ITiM I like some additional features (specially warn for very late vehicles and station timetables), but I think you should keep the code as simple as possible by now. After that, you should develop new features as different branches. If not, the patch may become too big for inclusion.