=================================================================================================================
Current version: v20 (attached here)
Windows binary of v15 can be downloaded at http://www.tt-ms.de/forum/showthread.ph ... 4#pid87114
Bugtracker can be found at: https://dev.openttdcoop.org/projects/op ... tip/issues
===> Please report problems either here in this thread, or by opening a ticket.
State of the patch: Feature-complete, played (though not the newest version) with bigger train networks, testers welcome
![Smile :-)](./images/smilies/icon_smile.gif)
Especially, at some point someone not being interested in timetables at all (for finding out wether I accidentally broke non-timetable functionality) but playing with this patch being applied, and people who more heavily play with timetabled road vehicles, ships, aircrafts than I do would be good.
=================================================================================================================
Readme describing the individual patches, and the general concepts of the patch, in a quite code-oriented way, but also with some examples.
=============================================================================================================
Merry Christmas!
After about a year of (occasional) development, I am able to publish
version one of the Timetable Improvement Patch. Note that it aims for
people who like to do detailed timetabling on their maps, e.g. trains
meeting always in the same station at some specified time. If you do
not care about that, then this is not the right patch for you ---
however, it does not want to force the player to use timetabling, so
you should be able to ignore the new features even with the patch
being applied.
This patch in fact is a quite big patch queue, introducing the
following features (for a short overview, see the attached screenshot):
- You can enter routes, consisting of route nodes.
- Vehicle orders can refer to routes. They serve as vias: A vehicle
travels from station A via route Foo to station B.
- Timetables are specified using absolute dates: Each OrderList (aka
timetable) has a (global) start date and a length. Individual
vehicles refer to their timetable using an offset. E.g. vehicle one
drives with offset zero months, vehicle two with offset one month.
Arrivals and departures at individual stations are also specified
using absolute dates, and are a property of the timetable, i.e. the
vehicle offsets work for them either.
- Once a vehicle reaches the end of its orders, the timetable length
will be added to its offset. If all shared timetables leave the
range 0 ... timetable length, the global timetable start date and
the offsets will be adjusted accordingly to keep offsets small.
- Timetable offsets and lengths can be specified in days, months and
years. This way, one can easily specify timetables where vehicles
will always do some action the same day of some month.
E.g. timetable length two months, always meet in station bar the
15th of a month with some other vehicle.
- If no timetable information is entered, then everything is supposed
to work the traditional way, without timetabling.
- The Goto tool works either the traditional way, or using a new GUI
supporting routes. Imagine the previous order is for some station
Foo, then the Goto tool will offer all stations reachable from Foo
via some route in a extra window, no scrolling and clicking on the
main map is necessary.
- Timetabling also works using a extra GUI, which allows to specify
several arrivals or departures in a row, without any window closing
and reopening in between.
- Stations have a station timetable.
- For routes, you can open either a train graph, or a tabular route
timetable.
The overall goal is making timetabling in OpenTTD much more robust
(avoid problems with unwanted timetable shifts, when relative dates
in a timetable are changed), and offering tools for planning and
synchronizing timetables in-game, in my games on unchanged trunk
I always had to use several sheets of paper to keep track of information
like which trains meet where etc.
The key to that goal IMHO is the introduction of routes, as for
displaying the traffic on some railway line in some useful way, I
first need some concept representing it.
This patch is neither actually finished, nor was I (for reasons of
time) able to play a bigger game using it yet. But I hope, that the
most severe bugs, problems of user handling, etc. are already fixed,
i.e. that this patch is ready for playing test games using it.
Major problems and tasks I am aware of:
- Generally, GUI handling is not yet tested in a bigger game. I am
quite sure that the ideas are the right ones for the problems I
want to solve using them, but there might be GUI problems which
one notices once a game grows beyond some size.
- The node and route timetables are not yet finished; in the node
timetable some heuristics for choosing the displayed destination is
still needed, in the route timetable I am not sure wether all of the
more complex cases (like trains overtaking each other) do already
work.
- I added the ability to have route nodes formed by a set of tiles.
However, such an ability is not yet introduced into the Goto
meachanism. At first, I thought about just using them for
timetabling (offer routes intersecting outside stations, plus
updated delay information outside stations), but in fact I believe
that supporting order destinations formed by a set of tiles may be
realistic using that infrastructure. After all, in terms of a
pathfinding algorithm, a station with multiple tracks is also a
collection of possible destination tiles (either enter track A, or
B, or C), and in terms of the algorithm, my hope is that this is
more or less equivalent to supporting a set of arbitrary destination
tiles. This might also be a solution for the common problem of defining
that certain trains must enter certain tracks (but not other ones) of some
particular stations. But I did not yet inspect this further.
- Arrivals and departures are currently forced to be in the interval
timetable start ... timetable start plus length. My feeling
currently is that this restriction may be too severe in terms of
easy user handling, maybe just ignoring that interval, or silently
adjusting arrivals outside that interval by multiples of the
timetable length is a better way to deal with that.
- Updating dialogs like the node and route timetables if some affected
piece of information changes is not really implemented at all
affected places.
The future: In the short term, I have quite little time to even answer
in this thread during the next about two weeks. But also in the longer
term, do not expect too much activity from me concerning this patch.
If there is real interest in this patch, then probably opening a bug
tracker for it is the best choice.
And now: Have fun
![Smile :-)](./images/smilies/icon_smile.gif)