Timetable Improvement Patch

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: Timetable Improvement Patch

Post by Eddi » 23 Apr 2014 12:20

i think you're trying to solve a problem with date-based timetables where time-based timetables would be better suited.

randomly lengthening or shortening the timetable by a day (or more) seems like a worse idea than shifting the start date.
You might not exactly be interested in Ferion, but if you are, have fun :)

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 23 Apr 2014 12:42

Well, I did not invent the time scale of OpenTTD...

However, as I play with breakdowns enabled, my timetables anyway need some relax time included, as it can always happen that a vehicle needs 15 days for a distance that is scheduled with 10 days. The gap between months is some factor smaller than that effect breakdowns have. Similar in reality: Timetables have some relax time included, no one designs a timetable where the vehicle is supposed to be at the destination within a time that is only possible if anything works perfectly fine under optimal circumstances. I.e. I do not design a timetable in a way that it is essential that there is a 31st.

Beside this: For me, what you call time-based timetable is just a mechanism to ensure that vehicles move in certain intervals. A time-based timetable does *not* link that movement to any senseful time scale. Some people may be happy with that.

For me, this simply is no real timetable, as it completely fails to link movement with a senseful time scale. Given that I want that, ignoring the (small) problem with the 31st was the only possibility I had in OpenTTDs world.

(what would you say in reality, if your train arrives Monday at 8:15 am, Tuesday at 8:23 am, Wednesday at 8:31 am, just because your train company has designed a schedule of length 24 hours and 8 minutes? ---- transformed to OpenTTDs world, this is what you propose: Having a 360 day timetable for a year that unfortunately has 365 days).

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: Timetable Improvement Patch

Post by Eddi » 23 Apr 2014 13:43

no, you misunderstand me. i meant "time-based" as in "24h clock" not as in "24h and 8 minutes"

if you have this 24h clock (which several patches did already), there is no reason to align it with a month, or a year. you just make sure your roundtrip time is aligned with the clock, and nothing "shifts", and you don't get weird "leap days" between cycles. thus your "absolute times" idea works perfectly with the 24h clock.

PS: i play with breakdowns off.
You might not exactly be interested in Ferion, but if you are, have fun :)

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 23 Apr 2014 14:32

Ah ok, this way...

Well, writing a patch for being based on another patch one didn´t write oneself is a bit... difficult.

Then I would see it that way: I have written a patch that deals with current trunk state of OpenTTD as best as possible. It would probably deal as well with a 24h patch, given some hopefully not too big adjustments. Maybe the adjustment would be having another option in that dropdown, maybe something else, depending on how such a 24h patch changes gameplay exactly.

But given no 24h patch is in trunk yet, I cannot rely on one sensefully, and as long as this is the situation, IMHO my solution for my way to play is the best possible given the current time system.

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 23 Apr 2014 18:47

Got rid of the "day in the past" in the first line of the timetable only order view.
Attachments
stip_v2.zip
(105.15 KiB) Downloaded 97 times

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 09 Aug 2014 13:30

Eddi wrote: if you have this 24h clock (which several patches did already), there is no reason to align it with a month, or a year. you just make sure your roundtrip time is aligned with the clock, and nothing "shifts", and you don't get weird "leap days" between cycles. thus your "absolute times" idea works perfectly with the 24h clock.
You wrote this some time ago.

What I would be interested in: In which state are the existing 24h patches? Is it for you as devs clear that something like this would be desirable, do they suffer from gameplay problems, are they still buggy, or...?

Why I ask this: If I try to improve my timetabling patch (with the ultimate goal of making it a full-featured replacement for the existing timetabling scheme), then it would be good if I could do this on the correct basis; and if I read your above statement right, then this currently is not the case.

Specifically, if the current situation tends to persist for a longer time, I might think about integrating some sort of 24h-support into my patch queue as its first patches, if this would make sense. Simply because timetabling is probably the place in gameplay where 24h-support is needed mostly (where - except as a purely graphical add-on - would one use 24h-support else in the game?), and because I don´t think that implementing a patch based on the requirement of having another patch applied is a good idea.

I write this to get clear what I might do with the timetabling patch in future, not necessarily because I want to implement something related to it right tomorrow.

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: Timetable Improvement Patch

Post by Eddi » 10 Aug 2014 01:05

let me clarify this: i'm not a developer.

i do like the 24h clock, but a timetable or route managemant should work for any arbitrary period given in ticks, whether the time will be displayed in days or minutes should be irrelevant. (also, for multiplayer purposes, the timetable synchronisation period should be a company setting)
You might not exactly be interested in Ferion, but if you are, have fun :)

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 10 Aug 2014 06:28

Eddi wrote:let me clarify this: i'm not a developer.
Ah, sorry, that indeed was a misconception on my side.
i do like the 24h clock, but a timetable or route managemant should work for any arbitrary period given in ticks, whether the time will be displayed in days or minutes should be irrelevant. (also, for multiplayer purposes, the timetable synchronisation period should be a company setting)
So, the idea is that the game is either in mode "display time in date", or "display time in hh:mm", do I get that right?

Based on this, timetabling GUI then has to display times either in days or in hh:mm, without further setting in the timetable GUI.

Hm, for my current patch this means:

- I currently save arrivals and departures as Date. This is no big problem, as the factor between Date and ticks is 74 anyway.
- For lengths and offsets of timetables, I currently have a newly introduced type Duration, either with unit Year, Month, Date. Ignoring the differences in month lengths we discussed above, I could transform Months into Hours by dividing by a factor two (as a month has approximately 30 days, but an hour has 60 minutes). I.e., 2h 30 min would be equivalent to 5 months (ok, a correction factor based on how many ticks a minute has would be needed as well).

I think the crucial question is, is the transition 24h <--> non-24h one that you can do in-game?

What do you mean with "timetable synchronisation period"?

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: Timetable Improvement Patch

Post by Eddi » 10 Aug 2014 07:07

ic111 wrote:What do you mean with "timetable synchronisation period"?
i guess this is what you call a "Duration". so basically, if you set "Duration" to 1 Month, every timetable that does not add up to a full month will get extra padding ticks, to restart the timetable at a full "Duration". Or Something (tm).
You might not exactly be interested in Ferion, but if you are, have fun :)

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 10 Aug 2014 09:30

In my system, a timetable has a fixed start date (type Date), and a length (Duration), and each vehicle has a vehicle-specific offset (also Duration).

Thus, I require that any arrival / departure of this timetable is within the interval [Start Date, Start Date + Length[, or if you take it vehicle-specific, [Start Date + Offset, Start Date + Offset + Length[. Once a vehicle has completed its last order, I increase Offset by Length, and once all Offsets of shared orders vehicles are > Length, I decrease them by Length and increase arrivals/departures accordingly.

Obviously, I can do the same also for Hours and Minutes, the only thing is that unit hh:mm is not enough for me, I would need full timestamps with date part. I.e. if some timetable has length 8 hours, current start date is <Day 1>, 21:00, then in the next iteration start date has to be <Day 2>, 5:00.

To summarize, I don´t think that I have / need something like a timetable synchronization period, my timetable lengths are timetable-specific, i.e. technically a property of OrderList, and thus I also shouldn´t have a problem with multiplayer games.

Alberth
OpenTTD Developer
OpenTTD Developer
Posts: 4746
Joined: 09 Sep 2007 05:03
Location: home

Re: Timetable Improvement Patch

Post by Alberth » 10 Aug 2014 11:09

Why not have all time points in ticks, probably relative to the start of the current cycle?
You have maximum precision, and you can easily compute hh:mm from it.

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 10 Aug 2014 13:32

Of course I can transform *absolute* ticks into a hh:mm value. The problem is more the question, how should the player enter the absolute start date of a timetable? If the player enters 01:00, is it 01:00 the current day, or 01:00 the next day?

Timetables in may games sometimes have lengths like 20 months - how much are 20 months in a 24h patched game? Don´t I run into the problem that then, the player cannot simply determine wether a displayed start time of e.g. 01:00 is 01:00 the current day, or 01:00 the previous day?

Regarding lengths and offsets of timetables, I think Durations (i.e. numeric value plus time unit, e.g. 4 months) are the right concept as long as one wants to support timetables in the current system. Only if I drop that support completely, and only allow timetables in a 24h concept, I can sensefully switch to ticks for that pieces of information.

(the reason again is that months have different lengths, and one basic feature of that patch is that the same behaviour of some vehicle happens again at the same dates, e.g. arrive every four months the 25th).

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: Timetable Improvement Patch

Post by Eddi » 10 Aug 2014 15:00

ic111 wrote:The problem is more the question, how should the player enter the absolute start date of a timetable?
yes, that is indeed a problem, and one that i think previous 24h patches solved insufficently. particularly, the last one i used interpreted all entered numbers as value in the future, which caused problems when you wanted to shift a train backwards a little bit. but i think with a bit of proper design this can be solved.
(the reason again is that months have different lengths, and one basic feature of that patch is that the same behaviour of some vehicle happens again at the same dates, e.g. arrive every four months the 25th).
and i still think that is the weakest point of your current approach. because sometimes i really don't care about things happening on the Xth of every month, but in a fixed frequency. like a terminus station with an X crossing, every 4 days a train arrives, and every 4 days a train leaves, but they should be offset by exactly 2 days, otherwise there will be a conflict, and one train will be delayed. this will totally be broken if an additional day is inserted every random amount of times.

and in such cases, a 24h time would be beneficial, because it does not have this random padding problem.
You might not exactly be interested in Ferion, but if you are, have fun :)

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 10 Aug 2014 18:05

Eddi wrote: and i still think that is the weakest point of your current approach. because sometimes i really don't care about things happening on the Xth of every month, but in a fixed frequency. like a terminus station with an X crossing, every 4 days a train arrives, and every 4 days a train leaves, but they should be offset by exactly 2 days, otherwise there will be a conflict, and one train will be delayed. this will totally be broken if an additional day is inserted every random amount of times.

and in such cases, a 24h time would be beneficial, because it does not have this random padding problem.
Of course your point is valid.

But given what frosch writes in the German forum, I think that one of the worst things I could do to my patch is extending it by a 24h concept.

And, the other way round, the discussion wether we have Durations or ticks as unit of lengths is a quite technical one. I agree that for pure 24h, ticks would probably be sufficient, but as we don´t have 24h (and IMHO won´t have in the near future), IMHO on a technical level Durations are the better concept.

Beside this, my patch supports your 4 days interval scheme anyway, you just need to use Durations with unit "Days": Timetable length e.g. 60 days, offset 4 days, 8 days, 12 days and so on, should do exactly what you want.

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 10 Aug 2014 21:11

Release 3 of the small timetable improvement patch. It is a pure "adapt-to-trunk"-release, as there were some major refactorings in the code I have to touch for this patch.

Known bugs:
- Some of the text I print should behave better if one increases font size as I do (can be seen in the screenshots)
- I should remove the "via Route"-button, it is without function now.
- The speedlimit button is also without function currently.
- Some internal cleanup tasks within the patch queue, which should not affect playing

Image
Image
stip_v3.zip
(108.94 KiB) Downloaded 69 times
Attachments
Rogsand Transport, 20th Feb 1922#2.png
(241.29 KiB) Downloaded 4 times
Rogsand Transport, 20th Feb 1922#1.png
(241.29 KiB) Downloaded 4 times
Last edited by ic111 on 10 Aug 2014 21:22, edited 1 time in total.

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: Timetable Improvement Patch

Post by Eddi » 10 Aug 2014 21:21

ic111 wrote:But given what frosch writes in the German forum, I think that one of the worst things I could do to my patch is extending it by a 24h concept.
that is probably right, but i think it's still useful to conceptually explore how this 24h timetable can later be applied on top, even if it's not going to be implemented right away, or by someone entirely different. i guess my aim here is to open up a way of thinking so that this later addition is not going to be blocked by your development.
And, the other way round, the discussion wether we have Durations or ticks as unit of lengths is a quite technical one. I agree that for pure 24h, ticks would probably be sufficient, but as we don´t have 24h (and IMHO won´t have in the near future), IMHO on a technical level Durations are the better concept.
i suppose that does make sense, and if done right, "hour" and "24 hours" are then easy additions as new units on top of "day"/"month"/"year".
Beside this, my patch supports your 4 days interval scheme anyway, you just need to use Durations with unit "Days": Timetable length e.g. 60 days, offset 4 days, 8 days, 12 days and so on, should do exactly what you want.
that is actually a piece of detail i was missing from my idea about what your idea behind this patch is. as a followup question: is this unit adjustable for each timetable (i.e. part of my network) individually?

say i want my FIRS *supplies delivered on a monthly scale, but my tram and passenger network operate on the daily scale?

if the answer to that is yes, then what the 24h timetable boils down to is basically:
  1. make handling of long day-based roundtrips easier. e.g instead of 560 days, you define 80 days=1 hour, then the round trip will take 7 hours.
  2. make synchronizing roundtrips of different lengths easier, by offering easy to remember fractions. like if one round-trip is 50% longer than the other, you define one of them as 2 hours and the other as 3 hours. now they are on a scale where you can easily shuffle them against each other
of course there are also players who want 24h timetable to make actual daily cycles, like parking trains for 8 hours during the "night" and stuff. of course it won't be dark, and passengers will still be produced, but that is certainly outside the realm of this patch.
You might not exactly be interested in Ferion, but if you are, have fun :)

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 10 Aug 2014 21:30

To make it short: The answer is yes. The length of a timetable is a property of the OrderList, the offset one of the vehicle.

One additional screenshot I could not add to the post above as just 3 attachments are allowed:
Image
Attachments
Rogsand Transport, 20th Feb 1922#3.png
(236.56 KiB) Downloaded 4 times

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 11 Aug 2014 20:34

I was asked to provide some binary of the patch, and just try to generate one for windows by cross-compiling from a Debian system.

Code: Select all

wol@dbis-lap13:~/openttd/_trunk_stip_win$ ./configure --host=i686-w64-mingw32-g++
checking awk... awk
detecting OS... MINGW
checking build system type... i486-linux-gnu
checking host system type... i686-w64-mingw32-g++-gcc not found
I couldn't detect any gcc binary for i686-w64-mingw32-g++
wol@dbis-lap13:~/openttd/_trunk_stip_win$ i686-w64-mingw32-g++ --version
i686-w64-mingw32-g++ (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
wol@dbis-lap13:~/openttd/_trunk_stip_win$
I never before cross-compiled something using MingW, but according to what I just read and found out, I thought that the above configure statement should work. Why does it complain about not finding i686-w64-mingw32-g++, although the statement below tells as that exactly such a binary exists?

Or do I make some fundamental mistake?

Rubidium
OpenTTD Developer
OpenTTD Developer
Posts: 3815
Joined: 09 Feb 2006 19:15

Re: Timetable Improvement Patch

Post by Rubidium » 11 Aug 2014 20:42

ic111 wrote:Or do I make some fundamental mistake?
Yup. The configure script is searching for $(HOST)-gcc, $(HOST)-g++ and friends. You can see that because it can't find the gcc named i686-w64-mingw32-g++-gcc. Remove the last 4 characters from the configure command and it should work.

ic111
Director
Director
Posts: 608
Joined: 17 Jul 2007 17:56

Re: Timetable Improvement Patch

Post by ic111 » 11 Aug 2014 22:24

Thank you, now it at least runs until it complains about a missing zlib. Interesting, since I just installed zlib-bin --- or does it need some dev package? (which?). But, for today it´s too late for inspecting this.

Code: Select all

configure: error: zlib couldn't be found
configure: error: you requested a static link, but I can't find libz.a
Anyway, here is another updated version of the patch, I improved layout (width handling) of the timetable dialog, i.e. the "..." you when you open it with a too big font (see screenshots above) should be gone now.
Attachments
stip_v4.zip
(110.26 KiB) Downloaded 75 times

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 7 guests