Timetable Improvement Patch

[ic111]

A release where I did my very best to adjust v2 of the patch to current trunk.

I did my very best means: I know that at least my DurationWindow that relies on the querystring GUI (providing easy input of intervals of e.g. 3 months) is currently broken; you can enter an interval if you use the buttons, but input you type on the keyboard will not be displayed in the input line. I suspect it is related with the fact that the function HandleEditBoxKey (or similar) disappeared without obvious replacement. Thus, one needs to dive into that further, hopefully finding a way to repair it.

EDIT: After having a look at it again, I think this indeed is the problem: Is there any replacement for HandleEditBoxKey?

More new bugs are possible (adjusting that big queue to some nasty changes in trunk wasn´t exactly easy...), as I concentrated on making it run again, and did not yet do any extensive tests.



Question (see attached screenshot): I added the ability to display delays (in red in the style "+7") or vehicles being too early (in green in the style "-3")

(1) directly on the map near the vehicle
(2) in a vehicle window
(3) in the vehicle list

Additionally, in the upper right corner of the vehicle list I display an average delay of all vehicles in that list.

Do you like that? I ask because the two patches providing that feature could easily be extracted out of the patch queue, adapted to the old timetable concept, and become a small separate patch queue.
But I would only consider doing that if people say they like that feature, and thus there is the clear goal of making that separate patch ready for trunk quite quickly. If not, extracting those two patches would just be wasted time for me.

Of course, a setting in the advanced setting turning this on or off would be necessary / part of that separate queue, and of course one could discuss graphical details etc.; currently I mainly ask about the basic idea, not the details.

[frosch]

Is there any replacement for HandleEditBoxKey?

That function is gone. Take a look at other windows how it is done now resp. what was changed for them, e.g.: hg diff -r 0752671e1f50:beef809c6546 src/signs_gui.cpp
Mostly you will need to remove code from your window, which is no longer needed.

[ic111]

Thank you very much, this was the piece of information I needed

An updated version of the patch is attached.

BTW, the window we are talking about here is shown in the following screenshot.

McAlpine & Co., 14. Feb 1922.png

A screenshot of the window we are talking about here...

(232.23 KiB) Downloaded 6 times

[ic111]

I adjusted the patch to current trunk.

Furthermore, some bugfixes are included, beside some fixed segfaults, the departure timetables should work as desired now.

I have played a longer game using v4 + fixes + mhl, and have the feeling that I am able to build up a major, fully timetabled network using this patch (which was the goal of writing it ). In that game, most of my timetables where designed for trains running in intervals of one, two or four months; this way I was relatively easy able to build up a network where trains on single track lines (I have many of them) meet at defined dates in the stations, plus I was able to timetable connections between trains which is useful for cargodist.

For a future game, I will probably modify the game (outside a patch) in the following two fashions:
- decrease production by factor two or four
- apply ship acceptance rating scheme also for trains, i.e. I have to call at stations less often

Desired effect: A network where I have less trains, thus more single track lines suffice, and I have more lines where not every two or three stations is a train (if you look at the situation at some particular point in time). After all, in reality, if I e.g. have a train interval of one hour (which is a quite common interval for rural areas), then this means that between a train and the next train, the distance can easily be 10 stations. Whereas, in current OpenTTD, that distance is rather three or four for reasons of the acceptance rating.

[KeldorKatarn]

While this is amazing stuff I have to play the advocatus diaboli and ask: Is it really a good idea to take a complicated, badly designed feature and make it more powerful but by doing that even more complicated?

In my opinion the entire time tabling feature is something most players will never touch, since it is simply way too complicated to use without a separate manual explaining it.

I think the seperation patches are closer to the idea and even they should get rid of a lot of unnecessary UI and simply take over the work and hide all the nuts and bolts away from the player and maybe offer them behind some "advanced" button or something.

From what I understood the upcoming "train fever" automatically separates busses e.g. once they have a route and the player doesn't have to do anything. That's what I expect 99% of the players out there to want 99% of the time. And I think the UI should represent that.

A feature like this is awesome if you really want to dig into one of your ICE routes and make it all nice and cool by hand. But overloading this screen with all sorts of stuff by default will only scare off most of the players IMO. That the times are represented in unrealistic days or abstract ticks instead of easy to understand real-life based time values (why would it take a 200km/h train 3 days to get from one city to the one right next to it. explain that to Joe Average who's supposed to design routes with this)

Sorry to rain on your party As I said I think this is cool work, but I had to mention this issue.
I mean look at the number of windows open in that screenshot. And that is what.. one or a couple of routes for a handful of trains? The average game will end up with several hundred trains, which also need to be constantly replaced with newer models while track peaces need fixing and trains are getting lost... and then the player sees this and thinks.... uh... cool but... no thanks, I think I need to fix this track peace before my game time runs out...

[ic111]

In my opinion the entire time tabling feature is something most players will never touch, since it is simply way too complicated to use without a separate manual explaining it.

Well, it is a feature designed for people who want to set up timetables that are close to reality. And this is much more than just separating vehicles using a fixed interval between them, but without interaction between different groups of vehicles. Such a timetable is based on the ability to define that at a certain date, a vehicle of group A has free space to left station foo, and 10 days later, a vehicle of group B, and so on.

Beside this, the goal of this feature is not forcing anyone to use it. If no timetable is defined for some vehicle, it acts as usual without timetable. (and if this is not the case in some situation, I would simply regard this as bug of the patch).

I think the seperation patches are closer to the idea and even they should get rid of a lot of unnecessary UI and simply take over the work and hide all the nuts and bolts away from the player and maybe offer them behind some "advanced" button or something.

The "advanced button" is the decision to use such a feature. I did not touch the feature of the orders window, to switch between the traditional orders view, and the detailed orders view.

From what I understood the upcoming "train fever" automatically separates busses e.g. once they have a route and the player doesn't have to do anything. That's what I expect 99% of the players out there to want 99% of the time. And I think the UI should represent that.

I don´t know what 99 % of the players want, I wrote it for people like me who want detailed control over timetables, in a way as described above. As I have said, I like playing with one-track-routes, and I actually like having the responsibility of deciding where meeting points of trains are etc.

A feature like this is awesome if you really want to dig into one of your ICE routes and make it all nice and cool by hand. But overloading this screen with all sorts of stuff by default will only scare off most of the players IMO.

Well, this feature is in no way finished, but written mainly for myself. The question of what is the default behaviour of the GUI of some patch is mainly relevant in the time before it enters trunk, and this patch is clearly far away from that state.

That the times are represented in unrealistic days or abstract ticks instead of easy to understand real-life based time values (why would it take a 200km/h train 3 days to get from one city to the one right next to it. explain that to Joe Average who's supposed to design routes with this)

Yes, in reality the unit timetables are based on are mainly minutes and hours. Unfortunately, in OpenTTD, a typical scale for trains leaving a station and reaching the next one are days and maybe months. Thus, the logical consequence is that such a patch operates on the level of days and months.

You would have to slow down game time in OpenTTD by factor maybe factor 1500, to make having a timetable based on minutes and hours make sense.

I mean look at the number of windows open in that screenshot. And that is what.. one or a couple of routes for a handful of trains?

Well, from todays perspective I would say, the routes are the less important part of the patch. However, I have ideas how I can use them for collecting the orders for a new vehicle much more easily (by providing a GUI element where the player just chooses some destination along the route at hand, and all stations along the route until that destination are filled into the timetable automatically).

Beside this, what already works is timetabling orders in a way that you open the dialog for the first station, select the date to arrive/depart using -10/-5/-1/+1/+5/+10 days buttons, and then the GUI automatically switches to the next station, suggesting a date that is hopefully not that far away from the day you need.

The average game will end up with several hundred trains, which also need to be constantly replaced with newer models while track peaces need fixing and trains are getting lost... and then the player sees this and thinks.... uh... cool but... no thanks, I think I need to fix this track peace before my game time runs out...

(1) The game I mentioned above was in the scale of about 200 trains.
(2) I always play by modifying time frequently using the Date cheat, e.g. play from 1.1.1923 to 31.12.1924, switch back to 1.1.1924, etc.

To conclude, this patch does more or less what I personally expect from it, from time to time I improve it or adjust it to current trunk, but my experiences with the more heightlevel patch which I also wrote teached me not to regard my patches too much a possible part of the game, i.e. trunk. Already years ago, I spent in sum days of work for work with the more heightlevels patch that in effect never payed out with respect to that.

Thus, see that patch mainly as an offer for people who like to play in a way similar to the way I like.

[Wahazar]

I was waiting for such feature till 1991.
It should be especially useful for large maps with infrastructure costs enabled.

Sorry for plain question, but is there a way to implement all this patch queue automatically?
Sorry for naive question, I know how to apply single .patch file, but must I perform it for each ~80 files?

BTW, there is only title in tip.pdf file.

[KeldorKatarn]

[...]Thus, see that patch mainly as an offer for people who like to play in a way similar to the way I like.

Hey as I said, I think it's great Just had to throw that in there It's not even directed specifically at you. it's a general tendency in open source games I usually see. Things are getting more and more feature rich and all but at the cost of losing the normal player because the complexity rises to incredibly levels but the entry learning curve becomes steeper and steeper at the same time and simple usabiliy upgrades are neglected.

But yeah, as I said, just throwing that out there, I think the patch is really cool aside from that

[ic111]

I think the way to deal with that should be designing things in a way that makes features really optional.

For example regarding timetables, they should be designed in a way that you don´t have to bother about them if you don´t use them. I.e. if a vehicle has no departure, then it leaves as soon as possible. So the game does the right thing one expects who did not even think about the possibility to use timetables.

@McZapkie: No, you don´t have to apply them separately. Roughly spoken, you checkout a hg working copy (see http://www.openttd.org/en/development), install mq (mercurial queues as an addition to hg), copy the released patches at a defined place in the working copy, and use hg qpush -a to apply them all.

(description applies for a linux system, and I know that it is not very detailed; I would have to find out some things again myself as they are one-time-tasks one forgets again after having done them; maybe someone can help with a link to some tutorial or similar?).

[Alberth]

Let me offer you a thought about this, more as a player than a developer:

I think the way to deal with that should be designing things in a way that makes features really optional.

That is indeed important. However, you can go further in making features newbie-friendly.

For example regarding timetables, they should be designed in a way that you don´t have to bother about them if you don´t use them. I.e. if a vehicle has no departure, then it leaves as soon as possible. So the game does the right thing one expects who did not even think about the possibility to use timetables.

The absolute newbie is now happily unaware of timetables.

But what about people like me? Been playing the game every now and then for the last 6 years or so, and I sort-of know how to make a train network. I know I need timetables in some cases. I toggle the feature on and WHAM I get hit with the full complexity of timetables!

In my view it would also be useful to gently introduce it to new users of timetables (or any other feature for that matter). Otherwise you just move the steep learning curve by a few years.

I don't know if that can be done to timetables, or to your improvement patch, I haven't studied it closely enough to say anything about it. If it can be done, I believe it's always worth the effort, since more people will be able to use the feature, even if they use it only partly.

maybe someone can help with a link to some tutorial or similar?).

The best site is probably the Mercurial website, mercurial.selenic.com

[planetmaker]

I was waiting for such feature till 1991.
It should be especially useful for large maps with infrastructure costs enabled.

Sorry for plain question, but is there a way to implement all this patch queue automatically?
Sorry for naive question, I know how to apply single .patch file, but must I perform it for each ~80 files?

BTW, there is only title in tip.pdf file.

The tool you want to use are mercurial queues.
For advice see the mercurial wiki and the hgbook:
http://mercurial.selenic.com/wiki/MqTutorial
http://hgbook.red-bean.com/read/managin ... ueues.html

[ic111]

But what about people like me? Been playing the game every now and then for the last 6 years or so, and I sort-of know how to make a train network. I know I need timetables in some cases. I toggle the feature on and WHAM I get hit with the full complexity of timetables!

In my view it would also be useful to gently introduce it to new users of timetables (or any other feature for that matter). Otherwise you just move the steep learning curve by a few years.

I don't know if that can be done to timetables, or to your improvement patch, I haven't studied it closely enough to say anything about it. If it can be done, I believe it's always worth the effort, since more people will be able to use the feature, even if they use it only partly.

Hm, one might work with a small tutorial, including some screen shots.

I mean, basically it reduces to the following steps:

1. Create a vehicle
2. Open its timetable window
3. Add some orders (this can of course also be done in the usual window)
4. Define the start date and the length of the timetable ===> If a timetable e.g. starts at 1st January 1923, and has length 4 months, then this means that in the subsequent steps you define absolute arrival and departure dates for all its orders in the interval [1st January 1923 ... 30th April 1923]. Once the last order is processed, exactly 4 months will be added to all those arrival and departure dates, and the vehicle does the same again, just four months later.
5. Define arrival and departure dates for all its orders: Mark the very first order, click the arrival button, use the -10/-5/-1/+1/+5/+10 days buttons, click "Choose and Next", and do the same for the departure / the next order, until you have timetabled the complete order list.
6. (Optionally): Define a vehicle offset != zero, to have multiple vehicles use the same timetable, just in intervals of e.g. 2 months.

Example:
Timetable with start date 20th December 1922, length 4 months.

Arrive at A-Village at 20th December 1922, depart at 10th January 1923
Arrive at B-Town at 27th January 1923, Depart at 3rd February 1923
Arrive at C-Village at 20th February 1923, Depart at 10th March 1923
Arrive at B-Town at 27th March 1923, Depart at 3rd April 1923

Vehicle One has offset zero months, vehicle Two has offset two months.
Thus, vehicle Two is e.g. supposed to Arrive at C-Village at 20th December 1922 and at 20th April 1922. It is also supposed to arrive at B-Town, heading for C-Village at 27th March 1923.

This is a simple timetable for a one-track-line, where A-village and C-village both can be one-track-stations, and B-Town is the only two-track-station where both trains meet every two months.

A-village ------------------------==== B-town ==== ------------------------------- C-village

Situation at 20th January:
A-village ---------- Train One >>> ----==== B-town ==== -----<<<Train Two -------- C-Village

Would you think, that using such an explanation (given some screenshots), the key point is easily enough understandable?

I think, as developer of such a feature one has the problem, that anything beyond such a tutorial includes work implementing additional newbie dialogs, i.e. more work, which makes things more complicated than they already are (for the developer).

Of course, if such a feature is in trunk, one has also the possibility of providing some test games where people can look how the feature is used in a real game (e.g., the simple example of above, in a game). This, however is not feasible for a patch, because those test-games would quickly become incompatible to trunk.

The more advanced version is:
0. Create a route including A-village, B-Town, C-village.
(...)
3. Goto A-village. Once you choose A-village, the Game will offer you B-Town and C-village as possible next Goto destinations, based on the route.

The not yet implemented version is: Choose A-village. Choose C-village as destination, the game fills in everything until/including C-village, i.e. B-town and C-village.

Disclaimer: Currently the default behaviour of the Goto button is that it operates using the advanced version, unless Ctrl+Goto is pressed. Honestly, I have forgotten what the patch does when it finds no destination based on a route in that mode, because there is no route. Either you see an empty suggestion window, or the behaviour of Ctrl+Goto.

[Alberth]

Hm, one might work with a small tutorial, including some screen shots.

A tutorial also helps of course. That was however not what I meant. I was mostly aiming at reduction in complexity of the feature for the player, probably at the cost of less expressiveness for the player.

Since your aim is to be explicit and precise, I am not sure it is possible. For me steps 1-3 looks like enough detail to tell the computer. I would then expect the system to find find nice defaults for the other steps. However that would defeat the purpose of your patch, I think. (maybe another distinction is possible to make the patch more usable. For now, it mostly looks like I am not a customer for your patch ).

Would you think, that using such an explanation (given some screenshots), the key point is easily enough understandable?

For any feature you need to explain how it works, and an example looks like a good way to do that. It is however not the same as what I meant.

To understand that, imagine an insane difficult new feature. If you write an example for it to explain how it works, your example is still insanely complicated. You'd need to write 200 pages to explain what it does.
What I meant was to hide the "insane" part, it reduce the complexity of the new feature to just "difficult". One way of doing that is to have the computer fill in defaults, for example, but there are other ways as well, eg the company face window has a simple and detailed interface.

The on/off toggle allows to switch between using 0.0 and 1.0 of the feature. In my view, it is useful to also add settings for other values, eg use 1/4 or 1/2 of the functionality.

I think, as developer of such a feature one has the problem, that anything beyond such a tutorial includes work implementing additional newbie dialogs, i.e. more work, which makes things more complicated than they already are (for the developer).

That's normal. You also detect and handle errors rather than just crashing the program, don't you?
Core functionality is almost always simple to program, the surrounding code however makes that core useful for its users.
(In an extreme thought experiment, the core functionality of this patch doesn't need any GUI at all. Without it however, literally nobody can use the feature.)

The more advanced version is:
0. Create a route including A-village, B-Town, C-village.
(...)
3. Goto A-village. Once you choose A-village, the Game will offer you B-Town and C-village as possible next Goto destinations, based on the route.

It may be better to see these extensions as a new and separate problem. That keeps your timetable patch smaller, and makes these new route functionality also available for users that are not interested in timetables.

[Eddi]

a partial step towards a "less complex" feature would be: define only a round-trip time (e.g. 30 days) without filling the whole timetable, the vehicle would then wait at the first stop until the roundtrip time is over, and set the next departure time for that stop. if you then have a "separate vehicles" button that is not hidden behind ctrl in a totally unintuitive place, the feature would be "complete" in the sense that the basic function is ensured, but leaving out all the synchronisation etc. that would be possible with a full timetable.

In an (un)related note: it always disturbed me that "0" travel/waiting time means "not fully timetabled", it would be way more useful if it meant "do not wait here to catch up delays".

[Wahazar]

Thanks to everybody for help, now I have compiled version with this patch.
Some technical issues, bugs etc was PMed to author.
Here my toughs, how it should work.
I agree with Alberth and others, that in current version, this patch seems to be very complicated,
even for people familiar with timetables diagrams.
I hope, that it is possible to make these features more transparent and automated.
But I disagree, that it should work as plain "time separation" patch, which is good for buses, trams or urban railway.
As described in http://www.tt-forums.net/viewtopic.php?f=32&t=69892
improved timetable patch is necessary for synchronisation of variety of trains, rather for plain separation.

Below my opinions, how i should work.

1. Route definition - it is typical procedure for real timetable construction, however it can appear complicated for typical player.
Instead this, I suggest to automagically generate route during defining train schedule, which is familiar to every player.
Although seems it is not trivial problem even for simple single line, for example:

route from 1 to 4 and back

tsch.png (177.2 KiB) Viewed 10103 times

Even if first schedule station is in a middle of a route, resultant route should be 1-(2)-3-4, where (2) is optional - train must go either trough either.
I don't know how manage complicated branch routes. Of course these should be spitted, but how to check where is junction? Pathfinder tracking?
Already defined routes can be edited, if automatc generation is not satisfactory for user.

Once routes are generated, string diagram and timetable with numbers is available defined and filled, see below.
User can press button "show timetable" and ready to use (or editing) timetable and appropriate graphs should be displayed.
IMPORTANT - approximate position of train should be marked on string graph diagram.

2. Autofill - the most annoying thing in current timetable. As I mentioned in above linked thread, travel times should be estimated immediately during schedule definition. There don't need precise numbers, thus always a safety margin for waiting time should be applied.
You can start timetable immediatelly or correct timings. Travel time should not be editable - instead of this, user can change max velocity,
and software should recalculate all timings.

3. Absolute vs relative Timetable
Important - unlike current "vehicle relative" timetable, every routes with at least one common node should use by default SINGLE timetable,
i mean, all those routes have this same starting time and span. If you need time separation for next train, just shift its starting time relative to timetable start, instead to shifting timetable start itself.
Of course, user can manage with splitting timetables into different independent ones, or join and synchronise separate timetables together
(which is required, if two independently build lines are connected).

4. Line dispatcher view
Because timetable should be an instance above individual vehicle and consist information about all vehicles, it would be great,
if string diagram can show not only theoretical strings for given vehicle and all other spotted along given route, but also display
approximate position of EVERY vehicle on time vs station graph, indicated by its (clickable) number.
It would be great tool for maintenance large numbers of trains and other vehicles.
You can easily see every late train, deadlocked train, traffic jams etc. and immediately open vehicle window.

5. Timetable start and span.
I beg, remove this annoying "set start time" button! It is strange and always show date from the past.
Each timetable should start at 1 January of a given year (in case of leap year, trains would just wait one day more at nearest station).

Once defined and approved, vehicle timetable should be replicated along timetable span - of course with possibility of further corrections.
Real timetable span have naturally fixed length - 24 hours.
Because traveling along 1000 tiles distance back and forth, takes usually about two years,
let say, that typical predefined timetable length should have 24 months.
Or it can depend on map size - 12 months for smaller one (512x512 and less), 24 for big one.

Above features would be helpful for adding new trains, joining separate timetables and overall maintenance.
Of course you can optionally decrease timetable span, but not below the longest time span of existing scheduled train.
If the long schedule was shifted into future and doesn't fit before timetable end, remaining end should be automatically "hyphen" to the beginning of timetable.

Erratum: the most convenient way is to make buttons with predefined 3, 6, 12 and 24 months of timetable span,
and additional button "crop to max schedule length".
Existing entry with days/months/years seems not to be convenient.
Timetable span pinned to 1st January instead of floating one, gives additional opportunity to better control of yearly cost and revenues.

I even don't know, if it is possible to implement above features in existing openttd data and class structures, I just stated how is should works.

[ic111]

Inspired by this http://www.tt-forums.net/viewtopic.php? ... 0#p1118171 discussion, I spent todays evening with extracting the core timetable logic from the patch, and putting it into an extra patch I publish with this post. To be precisely, that reduces the size of the patch queue from 61 to 25 patches.

This reduced version can:
- Define timetables based on absolute dates, no more need to fiddle around with those non-robust relative dates.

- Timetables start at a fixed date, have a fixed length, and their arrivals and departures are defined in an absolute manner either.
- Vehicles can share timetables by defining different, vehicle-specific offsets. E.g. for a timetable of length 4 months, you may built two vehicles, one with offset zero months, one with offset two months.
- Once a vehicle has completed its timetable, it will increase its offset by the timetable length (e.g. from zero to four, or from two to six months) and start again. An automatic logic will take care that those offsets keep small.
- Timetable durations are really months: The 3rd February plus 1 month gives the 3rd March. Thus, you can easily built timetables where vehicles meet around the 1st of some month, similar to a symmetry minute in real world timetables.
- There is a GUI for easily entering arrivals and departures: Just hit "Choose and Next", modify with the plus/minus buttons, "Choose And Next", ..., until you are done with the timetable.
- Three different order views: Full, destination info only, timetable info only. See screenshots in the thread linked above.

What I left out for this version:
- Routes
- Station arrival/departure windows
- Route timetables

I do not consider these aspects completely discarded, station departure windows are even an obvious extension IMHO, but I think that discussing and maybe improving that patch in an constructive manner is easier if I reduce its size as far as possible.




One comment to that old post I admit I did not answer then:

5. Timetable start and span.
I beg, remove this annoying "set start time" button! It is strange and always show date from the past.
Each timetable should start at 1 January of a given year (in case of leap year, trains would just wait one day more at nearest station).

No, IMHO this button is essential, since the time a vehicle needs until it has completed its orders and starts again at the same station is vehicle-specific, in my games it varies between 2 and 24 months,. I cannot simply say, a timetable lasts a year, since this would mean that for a vehicle that has completed its order within 4 months, I would have to record them three times, and for a vehicle that needs e.g. 8 months, there wouldn´t be a proper solution at all.

However, you are right that that date in the past shown there is simply a bug. But one that only affects displayment. What I however probably will change in future is the behaviour that when changing the start date, the other dates of the timetable are shifted. This doesn´t work properly in practive due to variable-length months.

[Eddi]

- Timetable durations are really months: The 3rd February plus 1 month gives the 3rd March.

i'm very sceptical of this bit.

[ic111]

Could you elaborate why you are sceptical?

I introduced that to make timetable schemes possible where trains meet at some particular station in a regular manner, e.g. around the 1st of each even month, at station Foo trains from A, B, C, D meet.

Example: Consider two lines A---B---C and D--B--E.

In reality, the first line might reach B at 3.57pm and leave at 4.03pm, the second line might reach B at 3.53pm and leave at 4.07pm. Thus the passengers can change between the two lines.

The equivalent setup in OpenTTD is:
The first line meets at 27th April, leaves at 3rd May. The second line arrives at 20th April, leaves at 10th May; i.e. you have a setup friendly to CargoDist as passengers can change between those two lines quickly.

Now: To make this work in a regular manner, i.e. the vehicles meet again around 1st July, then 1st September, 1st November, and so on in the same way, I need months that are actually months. If I instead would choose 30 days (*), the meeting time would move, and some years later they suddendly meet symmetrical around the 17th ===> Maintaining such a setup would be much more difficult from player perspective, since you always would have to look first, what is my meeting time now?

(*) BTW, the patch also supports that scheme, you just need to choose Days from the drop down to have that scheme. However, for the reasons stated above, I almost always choose months. That also for me was a bit of learning while playing after I implemented both possibilities, eventually realizing that IMHO months are the way to go.



PS: Two small further remarks: Please ignore the "Route" button that is still there in the order window, it is without function in this version, I just didn´t want to redesign the GUI yesterday in the evening. And there is a button in the upper right corner that can access the old-style order view (as I altered the timetable_gui), my patch means to replace that one, having that button permanently is not what I would suggest.

[Transportman]

- Timetable durations are really months: The 3rd February plus 1 month gives the 3rd March.

i'm very sceptical of this bit.

I'm also skeptical of that bit, because it would cause small differences in gap between trains. Especially with February that gap becomes quite a bit smaller, which might cause other problems on the network. Sometimes I have trains that should not leave 2-3 days earlier/later because they then would block other trains, so I'm quite skeptical about it. Of course, if the entire network drifts like that, it might be less of an issue, but even then it might be a bit messy on very busy stations where the moment one train has left the signal block the next one already enters.

Now: To make this work in a regular manner, i.e. the vehicles meet again around 1st July, then 1st September, 1st November, and so on in the same way, I need months that are actually months. If I instead would choose 30 days (*), the meeting time would move, and some years later they suddendly meet symmetrical around the 17th ===> Maintaining such a setup would be much more difficult from player perspective, since you always would have to look first, what is my meeting time now?

But both meeting times would move equally if their schedules are multiples of 30 days.

[ic111]

Still, keeping track of that is a challenge for the player, in terms of bookkeeping what´s going on on your network. I personally find it quite convenient, knowing that each time at the 1st of an even month, the same pattern takes place at some station. Then I start thinking, Hm, I need another train, ah, the slot "Arriving at 20th at that station from that direction" is still free, take that one".

Yes, the gap you mention is there, but IMHO it´s effect is smaller than the influences breakdowns have (do you play with or without breakdowns?).
For all months but February, it is one day. A breakdown costs approximately five days.

Anyway, as I have said, the patch also supports days as measurement unit, so this is an optional feature anyway.