Plan for a TIP - Timetable Improvement Patch

[ic111]

Hello,

I plan to write a patch improving timetable handling. This thread is
currently just for presenting my ideas for such a patch, lateron if
and when I write such a patch, I will make this the corresponding
development thread. Note that currently, no line of code is written
for this. So, I present these ideas now to get feedback on them.

My aim when using timetables is building up a network of trains, that
meet at defined times at defined stations or other places. Simple
example: I have a one-track-line with a station in the middle, and in
this station every 60 days two trains from different directions should
meet.

With the current timetable handling, building up this is possible, but
has in my opinion several disadvantages:

• Orders are given in a relative manner, not in an absolute. There
  is a patch for a departure board that helps a lot, but if I know, at
  time X something should happen, I can´t just write X into the orders,
  but have to calculate somewhere outside the game starting at some
  base time Y.
• Thus, synchronizing a non-trivial number of vehicles IMHO only is
  feasible by keeping book outside the game about their timetables.
• Starting dates of timetables are recorded once and forgotten
  afterwards. You can synchronize vehicles by giving different
  timetables matching lengths (e.g. 30, 60, 120 days), but if you have
  to change something in a timetable, and the timetable for a short
  period of time has e.g. 116 instead of 120 days, vehicles quickly get
  out of sync.
• If you want to get an overview about the timetable of some railway
  line, there is no simple way to do that in-game, you have to keep
  track about this outside the game. Actually, OpenTTD has not even a
  concept of a railway line.

What do I want to do? My basic idea is:

• Set up vehicle timetables using absolute dates. E.g at 4th
  September 1932, leave Station X. Relative dates can be used for
  setting up a timetable conveniently (e.g. 6 days later enter Station
  Y), but will be transformed into absolute dates.
• Different vehicles sharing a timetable are connected using
  offsets. I.e. the timetable exists once, and each vehicle stores a
  offset relative to the start of this timetable.
• Each timetable is explicitely assigned a length. Based on both
  length of timetable and offsets, absolute times for vehicles (Vehicle
  X should enter Y at time Z) are calculated. Periodically, the length
  of the timetable is added to all absolute dates, to keep offsets
  small.
• Introduce a concept of (railway) lines. Why do I want to
  introduce railway lines? My ultimate goal is supporting train graphs
  (I hope the term is correct, in German I would say Bildfahrplan), and
  for being able to support them I need an abstraction of railway
  lines.
• In terms of GUI,
  displaying them can be switched on or off using a new transparency
  option. If activated, they are painted as lines over map, giving the
  player an abstraction of the actual railway lines for planning. If
  deactivated, nothing at all is displayed for them. An appropriate GUI
  is provided for managing them, plus a tab in the minimap for
  displaying information about them.
• Railway lines consist of nodes (stations or maybe coordinates on
  map) and edges (between two nodes, having coordinate points for
  displaying them). E.g. railway line 120 goes from node A via node B,
  C, D to node E.
• Timetables technically define arrivals and departures at nodes.
  The idea of supporting arbitrary coordinates here is making
  synchronizing things at junctions outside of stations simpler. A
  timetable reads like Start at time X at node (read: station) A and go
  via railway line 345 to node (read: station) B, arriving at time Y.
• Note that I only talk about timetables, not about routing. I do
  not intend to change routing in any way. Thus, if one don´t want to
  deal with railway lines, one is not forced to do so. If the via
  railway line 345 part in my above example is not filled because a
  player doesn´t care about, this only affects the ability to display
  data about timetables, not the ability to use timetables at all.

In summary, I want to be able to support the following ways of
displaying data about timetables:

• Timetable of some particular vehicle
• Timetable at some particular station
• Train graph / Bildfahrplan of some particular railway line /
  edge.
• Either in the train graph or separately, displaying timetable data
  for some particular edge in textual form.
• As a tool for this, display data about railway lines on map using
  a new transparency setting, in minimap, and in an appropriate GUI for
  this.

Pretty long post, as I have said all of this is currently just in the
state of not-yet-coded ideas (although I already had a look on what
data I would have to put into which data structure, and which new data
structures I would need - I could detail this probably quite fast).

When, and how much time I will have for this is to some degree an
open question (in particular, but not only, depending on some other
well-known-patch...). So, feel free to comment on it.

[Level Crossing]

I don't know if this is feasible, but I've always found this lacking: at station X, 'connect' with a train from group Y (connect meaning be at the station at the same time as. If there is no train currently there from that group, wait for one).

[ic111]

Said in an abstract manner, this would be something like "Start at time X, but only if condition Y is true / event Z has happened". I think this is complementary to what I indend to do.

I personally don´t feel a big need for it as I would enforce such conditions using timetables. (if train A should head only if train B has just arrived, then I give A an order like leave at 5th June, whereas B gets an order like arrive at 31st May, and get a pretty big chance that it works).

So: I think something like this would be feasible (given a detailed / senseful concept for it), it is also somewhat complementary to timetables, but I personally will probably not implement it.

[John_Smith]

Hi ic111,

This sound like a nice additional to OTTD, and would work well when CD or YACD comes in and if you talk to those projects leaders as it could be useful to your project before starting.

Things to think;
- How will the player control the vehicles meeting will it be in the vehicle menu, station menu, or a new screen and how will it look.
- Will one vehicle be able to meet many vehicles i.e. train A will meet buses X, Y and Z at station 5.

JS.

[Eddi]

what i'm frequently missing is a way to pre-fill timetables instantly based on distance and speed.

also i think a timetable should have at least two entries for the time, one "raw" travel/loading time, and one "buffer" time. an optional "autoseparation" would then only be adjusting the "buffer" times, an "autofill" would put the "raw" time as if it were always travelling at full speed, and the "buffer" time with whatever time it spent wating on signals.

[ic111]

what i'm frequently missing is a way to pre-fill timetables instantly based on distance and speed.

I agree, something like this would simplify things significantly. The question is how do you want to handle that feature in terms of GUI, and how exact should it be?

The simplest solution would be a small dialog where you can enter distance, measured in tiles, and average speed (or the vehicle) and get an approximate result.

If it should be exact, one would have to simulate vehicle movement (not only distance and speed are parameters, but also curves and inclination). The basic problem (and BTW one reason why I want to introduce railway lines as abstract concept) is that computing the exact path a vehicle will take based on the information available in a timetable requires a complete routing calculation; I regard implementing an exact simulation for this a quite hard problem.

Maybe prefilling based on a shortest path calculation ignoring routing might be a solution? I.e. execute a Dijkstra algorithm on a railway network, where each track tile forms an edge in the network, and signals can´t be crossed in the wrong direction. Then you will get a path, and can calculate the speed distribution (given time) based on curves, inclination and vehicle properties. This would get a senseful result in quite a lot of cases, and maybe in some cases, the player would have to adjust things manually.

also i think a timetable should have at least two entries for the time, one "raw" travel/loading time, and one "buffer" time. an optional "autoseparation" would then only be adjusting the "buffer" times, an "autofill" would put the "raw" time as if it were always travelling at full speed, and the "buffer" time with whatever time it spent wating on signals.

I don´t fully understand your point here. Questions:
- Could you define what you expect from an autoseparation feature?
- Could you define what you expect from an autofill feature?
- Could you give some simple example for making clear why you would need those two times?

Specifically, based on my understanding of an autoseparation feature, to what degree would the underlying problem be solved by a simple solution for manually defining offsets between vehicles as stated above?

[Eddi]

The question is how do you want to handle that feature in terms of GUI, and how exact should it be?

well as a proof-of-concept case, this would just take the air-distance between two stations, and the max speed.

I don´t fully understand your point here. Questions:

i'll need to get back to you on that when i have more time.

[ic111]

One quite technical question:

I have defined in new pool types (1) a set of TileIndex and (2) a vector of TileIndex. So, in terms of savegames, I have variable sized containers of data type SLE_UINT32.

Now, I wonder how I can save that data to a savegame. As far as I get it,
(a) SLE_LST only supports reference types, so it is not an option.
(b) SLE_ARR needs a length parameter hardcoded in the SaveLoad-description-struct, so it is not an option either, as my data structures are conceptionally variable-sized (although usually quite small, maybe << 10 elements, or empty at all).

Now I am a bit surprised because I would not have expected this becoming a real problem. After all, I don´t want to define a pool type only storing a TileIndex to work around this.

Can anyone give me a hint how to solve this? Is there a standard-way to solve that problem, or did I actually find a missing feature of OpenTTD savegame logic? :-/

[Eddi]

i'm no expert in this, but try taking how town_sl.cpp handles "_town_supplied_desc" as example.

[ic111]

You mean the SlAutoLength feature? Hm, it *might* do what I want but on first glance, it looks like a quite huge / complicate tool...

Complicate for a quite simple task, namely storing a variable n and then n times 4 bytes of information into the savegame. I will think about it.

[ic111]

The problem I have is that the parameter type of the savegame macros is sometimes a reference type and sometimes a variable type.

Unfortunately, as far as I understand it, both value ranges overlap (or at least, it is possible for the future that they will, if there are more reference types than today). Thus, I need some way to distinguish reference types from variable types when processing a container. The end of enum VarTypes currently looks this way:

Code: Select all

	/* 8 bits allocated for a maximum of 8 flags
	 * Flags directing saving/loading of a variable */
	SLF_NOT_IN_SAVE     = 1 <<  8, ///< do not save with savegame, basically client-based
	SLF_NOT_IN_CONFIG   = 1 <<  9, ///< do not save to config file
	SLF_NO_NETWORK_SYNC = 1 << 10, ///< do not synchronize over network (but it is saved if SLF_NOT_IN_SAVE is not set)
	/* 5 more possible flags */

Thus, if no one tells me that this is a really bad idea (or has a better idea...), I will occupy one of those 5 possible flags with a new SLF_REF flag, which, if set, indicates a SLE_REF, if not set indicates a SLE_VAR. Then, the container loading/saving code can either process a reference, or just write/load an ordinary variable.

[Eddi]

i'm sorry, i really don't understand what you're trying to do. but what you propose smells overcomplicated and wrong.

[ic111]

I am trying to store a variable sized data structure storing TileIndex instances in a savegame (conceptionally, std::vector<TileIndex> or std::set<TileIndex>). Transforming that data structure into a std::list, an array or something else for the purpose of saving/loading wouldn´t be the problem. But, std::lists can currently only be stored in a savegame if they contain references, and arrays must be fixed sized (size known at compile time) to be stored in a savegame.

When processing a std::list, savegame code currently takes the type passed to the SaveLoad macro, casts it to SlRefType and processes it. Thus, I can´t simply define an SLE_LST with SLE_UINT32, since that SLE_UINT32 would be processed as SlRefType. Thus, I would need a way to distinguish SlRefType from VarTypes in the list processing code. And here, I had the idea to define an extra bit for this, using one of the free bits in the type parameter of SaveLoad.

Clear what I want to achive?

[Michi_cc]

Create a SLE_LST_VAR instead?

[ic111]

I could do this indeed.

I did not consider this possibility because to me, defining a new container type because I have a problem in deciding what´s in the container sounded a bit weird.

[Michi_cc]

Well, if you're storing it in a std::vector/SmallVector anyway, make it a SLE_VECTOR of course. That's exactly the way all other SLE_* were born.

[ic111]

Ok, then I will do it that way, at least for now (after all, once I know that I can get a particular container into the savegame somehow, later changes to the savegame code will stay local and will not affect major parts of the code I just write).

So, then I have a SLE_LST working only for reference types, and a SLE_VEC working only for ordinary variable types.

[Wowanxm]

Any news?

[Level Crossing]

Obviously not, since there are no updates...

[ic111]

The state of that project is that I have the management GUI for routes more or less working, and an idea of how I want to alter the order management dialogs to reflect routes. Compared to the concept of the starting post, I will probably drop the concept of route edges, as I don´t actually need them.

But, due to several tasks real life has for me, I am at least some weeks away from being able to continue working for this. So there will be no release of this in the next one or two months.