Timetable Improvement Patch

[ic111]

Would be an interesting view either. It obviously suffers from needing someone that implements it

What I did in my recent games was that in heavily used stations, I place waypoints named "Foo Station Track 1", "Foo Station Track 2" and so on at their entries, to make trains enter exactly some particular track. Otherwise, setups where three or four trains enter around the 1st of some month, and leave in different directions afterwards would not work (e.g. Train 1 leaves at 3rd via route A, Train 2 leaves at 3rd via route B, train 3 leaves at 7th via Route C, train 4 leaves at 10th via route A, which splits up some tiles away). If then, e.g. train 2 crosses the track of train 3 and train 3 that of train 4, you have nice delay chains...

However, it would be difficult to link that playing behaviour with such a view.

Anyway, here is the version with re-introduced departure tables (arrival tables also work with some flaws, if you Ctrl + click on the timetable button). The button can be found in the station / waypoint / depot window.

See the attached screenshot (not made with the current version, font sizes are not fully representative, as I had to tune them quickly for being able to make a screenshot on a bigger game on an older, savegame-incompatible patched OpenTTD) for how this departure view looks like.

New Alpine Railways, 26. Apr 1935.png

(198.61 KiB) Downloaded 7 times

One additional idea I just had is: Instead of the term "Train 123" I can add the timetable name into the header lines of timetable entries. Then one can set up real route numbers, which actual show up in the station timetables.

E.g.: "10.6. IC 7 to Foo-Town". for a timetable named "IC 7".

[Eddi]

wrt daylength: daylength patches have the problem that they tag into so many core game features that nobody has yet found a way that would be acceptable for trunk inclusion. and additionally they have many problems where people can't agree on what they should do or shouldn't do.

applied to timetables the main issues are:
1) all GUI stuff should apply the daylength scaling (as in converting ticks to days). this shouldn't be a big problem, but it potentially involves touching a lot of places in the GUI code.
2) rounding to full days becomes too crude for useful timetabling, so there needs to be a way to specify fractional days (this is where the concept of an independent 24h clock comes in handy)

[Wahazar]

24h clock is mandatory, in my opinion, to work with such advanced timetable.
Main timetable concept is to synchronise traffic in whole network - therefore, fixed timetable period is required,
in contrary to existing flexible group-related timetable period.
However, if timetable period is fixed, you need define it either using tick or more convenient hh:mm, not days/months,
because days/months would be shifted to another date at the end of period.

[ic111]

I think you actually play similar to my playing style, but ...

However, if timetable period is fixed, you need define it either using tick or more convenient hh:mm, not days/months,
because days/months would be shifted to another date at the end of period.

... I think you missed some features of my patch...

My timetables have an offset (Days, Months) and a length (Days, Months). The offset is vehicle-specific, the length is timetable-specific.

IMHO what you want is both offset and length in Months.

Then you have e.g. a timetable of length 4 months. For simplicity, assume a vehicle with offset zero months. It contains orders e.g.
Arrive 27th January, Depart 3rd February
Arrive 12th February, Depart 16th February
Arrive 27th February, Depart 11th March
(...)

Once the vehicle has completed its round, the timetable will shift to:
Arrive 27th May, Depart 3rd June
Arrive 12th June, Depart 16th June
Arrive 27th June, Depart 11th July
(...)

No days are shifted. But you obviously have to cope with the fact that different months have different lengths, i.e. sometimes the period between 27th and 3rd has 7 days, sometimes just 4, 5 or 6 days.

But, based on former discussions, I can just say: The latter problem can be solved by a 24h patch, just unfortunately, there is none in trunk yet, thus when timetabling one has to work with the infrastructure already present.

And if I look at the length of my patch queue, introducing 24h in the same patch queue would just be ways too much code in one queue...


(if I did not understand your problem correctly, please correct me...)

wrt daylength: daylength patches have the problem that they tag into so many core game features that nobody has yet found a way that would be acceptable for trunk inclusion. and additionally they have many problems where people can't agree on what they should do or shouldn't do.

I know why I asked for details...

1) all GUI stuff should apply the daylength scaling (as in converting ticks to days). this shouldn't be a big problem, but it potentially involves touching a lot of places in the GUI code.

Probably, a daylength part has to replace DAY_TICKS by a variable / inline function returning that variable. Thus, this part shouldn´t be too complicate indeed.

2) rounding to full days becomes too crude for useful timetabling, so there needs to be a way to specify fractional days (this is where the concept of an independent 24h clock comes in handy)

Yes. This would be a bigger problem, where I agree that you actually would need something like 24h support.

Anyway, I personally circumvent the problem of day length by periodically applying the Date Cheat. Works without problems in my experience.
(as a cheap variant of a day length patch, one might even think about a config variable "Keep game in Year X", with the effect that once the 31st December is reached, game restarts with the 1st January of the same year. Such a patch should be quite trivial, as it would just have to do what I currently do manually by applying the Date cheat).

[ic111]

Fixed the remaining flaws of station timetables:

- The captions now not just tell you "Timetable", but e.g. "Arrivals Foo-Station", or "Departures Bar-Waypoint"
- Improved tooltips
- The button in the station timetable window for switching to the corresponding arrivals / departures timetable now works
- Arrival timetables now also calculate the correct final destination
- Bugfix: Arrivals / departures beyond the final order of a vehicle are now displayed correctly
- Orders with "neither load nor unload" are now never considered final destinations
- Wether the improved timetable view or the old order view is opened by default is now controlled by the config variable "Interface / Open Timetable View by default". The default is currently opening the new view, in fact it can do anything the old could, and even has a mode for only showing the destination lines.

Beside this, the idea I stated above ("use timetable name in header lines of timetable entries") was already implemented...

As I now regard this patch as feature-complete, my plans for the future regarding this patch involve the following points:
- Bugfixing - feel free to point me to bugs and problems, either here or by opening tickets at https://dev.openttdcoop.org/projects/op ... tip/issues
- Documenting the patch queue, I will probably write a Readme.txt containing an entry for each patch file
- Add source code comments, and fix issues where changes are in patch A although they conceptionally belong to patch B
- Remove some no longer needed code of the current trunk timetable implementation

By playing experience, I will obviously find problems in timetabling trains (although, I don´t expect many problems, as I already played some huge networks with this patch, and to the best of my knowledge I fixed the problems I experienced in that games).

What would be good at some point in the future:
- Someone who is not interested in timetables at all, but playing with this patch
===> For finding out, wether I accidentally damaged some functionality for playing in a non-timetabled mode
- People who play more heavily using road vehicles, ships and aircrafts than I do.

In both cases, I don´t expect big problems, but I´m to some degree the wrong person for testing that in a non-trivial network.

[ic111]

I just came across the topic of OrderBackups.

Can anyone explain the idea behind that data structure?

As far as I get it, they are related to the feature of storing vehicle properties, when a vehicle is sold in a depot, and then in the same depot a vehicle is built.

But in what way is that related to network? Why is there a separate saveload section in order_sl, which is only used in networking games? The code below is from order_sl.

In my concept, timetable start and length are properties of the OrderList. I currently wonder wether they also have to be included into the OrderBackup (the properties below are from Vehicle), but maybe answers to the question above make this point clear.

Code: Select all

const SaveLoad *GetOrderBackupDescription()
{
	static const SaveLoad _order_backup_desc[] = {
		     SLE_VAR(OrderBackup, user,                     SLE_UINT32),
		     SLE_VAR(OrderBackup, tile,                     SLE_UINT32),
		     SLE_VAR(OrderBackup, group,                    SLE_UINT16),
		 SLE_CONDVAR(OrderBackup, service_interval,         SLE_FILE_U32 | SLE_VAR_U16,  0, 191),
		 SLE_CONDVAR(OrderBackup, service_interval,         SLE_UINT16,                192, SL_MAX_VERSION),
		     SLE_STR(OrderBackup, name,                     SLE_STR, 0),
		SLE_CONDNULL(2,                                                                  0, 191), // clone (2 bytes of pointer, i.e. garbage)
		 SLE_CONDREF(OrderBackup, clone,                    REF_VEHICLE,               192, SL_MAX_VERSION),
		     SLE_VAR(OrderBackup, cur_real_order_index,     SLE_UINT8),
		 SLE_CONDVAR(OrderBackup, cur_implicit_order_index, SLE_UINT8,                 176, SL_MAX_VERSION),
		 SLE_CONDVAR(OrderBackup, current_order_time,       SLE_UINT32,                176, SL_MAX_VERSION),
		 SLE_CONDVAR(OrderBackup, lateness_counter,         SLE_INT32,                 176, SL_MAX_VERSION),
		 SLE_CONDVAR(OrderBackup, timetable_start,          SLE_INT32,                 176, SL_MAX_VERSION),
		 SLE_CONDVAR(OrderBackup, vehicle_flags,            SLE_FILE_U8 | SLE_VAR_U16, 176, 179),
		 SLE_CONDVAR(OrderBackup, vehicle_flags,            SLE_UINT16,                180, SL_MAX_VERSION),
		     SLE_REF(OrderBackup, orders,                   REF_ORDER),
		     SLE_END()
	};

	return _order_backup_desc;
}

static void Save_BKOR()
{
	/* We only save this when we're a network server
	 * as we want this information on our clients. For
	 * normal games this information isn't needed. */
	if (!_networking || !_network_server) return;

	OrderBackup *ob;
	FOR_ALL_ORDER_BACKUPS(ob) {
		SlSetArrayIndex(ob->index);
		SlObject(ob, GetOrderBackupDescription());
	}
}

[Eddi]

I just came across the topic of OrderBackups.

Can anyone explain the idea behind that data structure?

As far as I get it, they are related to the feature of storing vehicle properties, when a vehicle is sold in a depot, and then in the same depot a vehicle is built.

But in what way is that related to network? Why is there a separate saveload section in order_sl, which is only used in networking games? The code below is from order_sl.

this is required in multiplayer games, because when person A has a depot open and just sold a vehicle, player B joins (and loads the network savegame), then when person A builds a vehicle, player B needs to know which order list to attach to that vehicle.

this cannot happen in single player, because you can't have a depot window open while loading a savegame.

[ic111]

Thank you, that makes things clear.

A windows binary of v13 can be downloaded at http://www.tt-ms.de/forum/showthread.ph ... 3#pid86233

[ic111]

A new release (v14) can be downloaded at the start post, see http://www.tt-forums.net/viewtopic.php? ... 9#p1058369

The changes are mainly of internal nature, I cleaned up the patch queue, moved misplaced code fragments to the patches they belong to, added patches for removing code that is no longer needed after the patch queue is applied.

One bugfix: The misplaced error message when setting the start date as first step after creating a new vehicle is gone.
Furthermore, some improvements concerning the way autofill sets up timetables.

I hope that this is the last version of the patch with major code changes, my hope is that from now on, only relatively small bugfixes have to be done (several bugs and tasks are already recorded in the bugtracker of this patch project, see start page for the link). Nevertheless, it is quite improbable that I myself will play a big game with this patch version at least within the next weeks. Thus, any sort of tests and feedback is welcome.

But Warning
Due to my cleanup tasks, this version is savegame-incompatible to v13. Thus, if you started a game you want to keep using v13, please stay with v13, you won´t win anything significant by using this version, but loose the ability to load your savegame.


Additionally, I completed the readme file, which can also be downloaded at http://www.tt-forums.net/viewtopic.php? ... 9#p1058369
It describes the contents of all patches in the queue, and additionally contains some explanations about the basic ideas of timetables provided by this patch.

[ic111]

An adapt to trunk release.

[le_harv]

The TIP has totally changed the way I use OpenTTD and I really admire the effort that went into it. I've been playing with the STIP 15 Windows Binary with R27025.

My ultimate goal was to complete bug 7120 and have it so that trains could wait in depot using the patch you suggested.

This is a long shot, but did you by any chance get those patches to work together?

I have been attempting to compile a new binary with both your patches and the wait in depot patch but am running into failed hunks with STIP 15 because I believe the newer version of trunk is not compatible with your releases. I am a complete novice to be honest so attempts to check out R27025 have caused an error in MinGW that I can't seem to fix very easily. I also explored manually fixing the failed hunks but that looks a bit daunting to me as I literally looked at C++ for the first time... yesterday.

Thanks

[ic111]

An "adapt to trunk" release at some time in the next weeks / months is probably possible (I don´t want to promise too much regarding the near future). I didn´t check, I can just hope that there are not too many changes in trunk interfering with this patch queue.

Regarding trains waiting in depots, I have no concrete plans. Actually, I´m quite happy with the present behaviour, after all depots are something like a black hole anyway, i.e. a point where trains disappear for some time. Probably, servicing on some special kind of station track would be more realistic.

[Eddi]

one of the primary applications of waiting in depot would be releasing new vehicles in a timed fashion, instead of releasing all at once, and blocking the first station until things spread out, quite likely results in a deadlock or disruption of other lines.

[le_harv]

An "adapt to trunk" release at some time in the next weeks / months is probably possible (I don´t want to promise too much regarding the near future). I didn´t check, I can just hope that there are not too many changes in trunk interfering with this patch queue.

Regarding trains waiting in depots, I have no concrete plans. Actually, I´m quite happy with the present behaviour, after all depots are something like a black hole anyway, i.e. a point where trains disappear for some time. Probably, servicing on some special kind of station track would be more realistic.

Thank you for the heads up on a possible trunk adaptation. I appreciate its a lot of effort so understand if it takes time or real life prevents its build.

Interesting point of view on the depots. How this all came about for me was I was struggling to get an effective/realistic siding arrangement to park trains 'overnight'. I basically wanted to model a full day cycle using the days in the timetable to represent a unit of time (e.g. 3 days = 30 seconds, A full day = nearly 24 game years or something like that, based on a distance scale of 40 tiles = 1 mile... I went a little overboard in thinking this through!).

My 'cheat' plan was to make it so trains can wait in a depot 'overnight' to workaround my sidings issues, not realistic maybe but a substitute for the logistical issues I am having. I'd be really interested in how you approach stabling in sidings overnight!

Screen A - This layout allows for full use of a single siding but requires that the trains going into Sidings B arrive first and leave first... which gets quite serious to calculate when figuring out the logistics with many trains

Screen B - Each train gets its own track... which works logistically but isn't necessarily how it works in real life

Screen C - A layout that ensures a train is always likely to have an escape route but again, it's a bit unrealistic.

Sorry if this is a bit off topic here but it sounds like we think about this in the same way.

[le_harv]

Sorry for the double post and possibly still off-topic but I thought I would show the depot sidings idea and how I intended to achieve it using a GRF for modular sheds. Hopefully this explains the merit of the idea and why wait in depot is important despite potentially being 'cheating' when using the timetable realistically.

[ic111]

I admit I never thought about trains staying overnight in a depot. My usage of timetable so far is always, I have a certain number of trains on a railway line, and they make their roundtrip more or less forever.

Thus, depots in my games are more or less locations where a train passes once in its roundtrip.

Having a depot as a station that is big enough to offer space for all trains IMHO is probably not feasible within the landscape scale of OpenTTD. Probably, unless one plays with very few cities per landscape area, such a station depot would simply consume too much space.

I more thought about a one track station a train enters as replacement for a depot, and leaves after a few days. This would avoid the impression of trains disappearing in a black hole. Additionally, my experience is that at railway junctions, depots quickly become bottlenecks, simply because a train first blocks the adjacent track for several days while it enters, and then blocks it again while it leaves. If it would be a station, in such a situation I would add a second track, if it is a depot I have to introduce a second depot and re-route the trains in their orders.

So yes, I get your point why you would need that...

And yes, the ability so simulate the night would have its interesting aspects, although it probably makes bookkeeping quite a lot more complicate.

[le_harv]

although it probably makes bookkeeping quite a lot more complicate.

Ah, now I understand. It is a difference in playing styles. I am wishing openttd is a model railway hence why my balance sheet is...er... conveniently forgotten! I know openttd is not really a model railway but TIP has made it more possible to play it that way.

I don't know if this is of use but this is how I use it.

• Pick a date to represent when I want the day to start say 1st January represents 3.30am
• Every train has this as their start date set as this, no offset and every train has a length of a full 'day' (e.g. 3 days = 30 secs, 24 hours = 8637 game days)
• I do this on a spread sheet so I know what game date corresponds to what time
• Then each train gets its own timetable including sidings, stations, waypoints etc. that runs over the full 'day'... its a little insane I know. So if a train is starting in a siding... it may not get moving until nearer rush hour so in game dates this could be 4.30am or 27th December.
• Knowing how fast a train covers a certain distance allows me to be quite accurate with the 'times' for arrival, travel and departure etc especially when busy lines have speed limits built in... allowing headway to be factored in to figure out what the maximum capacity of a line is. The bit I haven't figured out is timetabling for trains that run at different speeds on the same line.

MY first objective with this is to get a small system up and running with connecting lines to test some of this out.

[ic111]

In fact adapting it to trunk was fairly easy, so here a release.

It contains only some small adaptions to changed trunk, no functional changes.

In strgen_tables.h, at some time in the last months, struct CmdStruct gained an additional field default_plural_offset. Unfortunately, it is --- at least in that file --- undocumented.
So I tried to make a best guess, and initialized it to -1 (does that value mean something like "unused"?), like in the similar DATE_FOO entries:

Code: Select all

	{"DATE_TINY",         EmitSingleChar, SCC_DATE_TINY,          1, -1, C_NONE},
	{"DATE_SHORT",        EmitSingleChar, SCC_DATE_SHORT,         1, -1, C_CASE},
	{"DATE_LONG",         EmitSingleChar, SCC_DATE_LONG,          1, -1, C_CASE},
	{"DATE_ISO",          EmitSingleChar, SCC_DATE_ISO,           1, -1, C_NONE},
	{"DATE_DM",           EmitSingleChar, SCC_DATE_DM,            1, -1, C_NONE},
	{"DURATION",          EmitSingleChar, SCC_DURATION,           2, -1, C_NONE},

... DATE_DM and DURATION are added by my patch, the other four already existed. default_plural_offset is the one with value -1 in those entries.


Please note that I did only a very very quick test. As I will probably not start a non-trivial game in the short term, any tests are welcome

[ic111]

I started with integrating the "Wait in depot" patch that can be found at http://www.tt-forums.net/viewtopic.php?f=33&t=70969 into this patch.

For trains, everything seems to work fine (please test nevertheless), however the road vehicles (and ships) drove me mad in the last hour.

I have a road vehicle, where for all two stations, and the depot order, a departure is set. Nevertheless, I always run into the case "there is no departure set".

To me, this looks like at some place, the order is copied (I remember that I had this impression already once when I inspected this topic for the first time), and (probably as I never found that location in code) without my new attributes.

Thus, the questions are:

(1) In which respects are train orders handled in a different manner than road and ship orders?
(2) Are orders copied when approaching a depot, and if yes, can anyone point me to the location in code?

I have added temporarily some debug loggers in code, some are added but commented out because they are triggered too often, thus if you like, you may have a look yourself.

Attached what I have right now, should be usable for trains, has the above described problems for road vehicles and ships, and is not yet tested for aircrafts. Take it as a debug release.

[Wowanxm]

ic111, nice to hear that you didn't give up improving the patch!