[Patch] Improved Timetable Management [V2.31tr SVN15778]

[AndiK]

Code-wise it can't because there is no data structure for a shared order list.

I will comment this with only one word: Arrrrrr.

I will have a look at the code - maybe I can magically find somewhere to put my variables. (I'm not too optimistic about this, tho. ^^ )

[DaleStan]

I feel sorry that I don´t be able to make a better diff at the moment. I don´t know why mingw don´t make a right head in the file.

Use "svn diff" instead.

[Jans]

If I use "svn diff" the system told me all time it ist not a workcopy.

Now I find a way using diff.

Code: Select all

diff -u -I RE oldfile newfile >patch.diff

It is a little bit bigger than the old one but it work fine.

[AndiK]

I've got another idea!

-> Autofill with (selectable) buffer quota. Means: Add x% to the measured time at each stop as a buffer for delays.
Everyone who doesn't want it sets it to zero and everything is back to normal.

[PhilSophus]

Also, not all graphical glitches were removed in the last patch, as can be seen in this screenshot (I moved the window around a bit):

I say only one word: Arrrrrrrrrgh. I missed one line again.

I have try to translate all strings in the file "german.txt".

Thank you! I'll have a look at it and incorporate it.

I feel sorry that I don´t be able to make a better diff at the moment. I don´t know why mingw don´t make a right head in the file.

Use "svn diff" instead.

Which - if you'd take it strictly - is wrong as Jans already noted as it is not a diff relative to a SVN revision. Actually, this may work in this case as german.txt was not changed by my patch.

Code-wise it can't because there is no data structure for a shared order list.

I will comment this with only one word: Arrrrrr.

I will have a look at the code - maybe I can magically find somewhere to put my variables. (I'm not too optimistic about this, tho. ^^ )

I've thought quite a bit about it. Making Order polymorphic (i.e. providing a sub-class OrderHead) would not work as orders are allocated from a common pool an thus must have the same size (providing a separate pool for OrderHead seems a bit complex). Making this stuff members of Vehicle means that it can not be easily shared between vehicles with shared orders. Making it members of Order is wasteful because it would only be needed for the first order but would be the easiest to implement.

Before it assumed the given time is always in the future (so if you set 19:00 at 19:01 it would take the next 19:00 in almost 24 hours). Now it assumes a window from 6 hours in the past up to 18 hours in the future. So, if its 19:01, times from 13:01 to 19:00 would be interpreted as lying the past and times from 19:02 to 13:00 in the future).

PhilSophus, may I ask you a question, because I'm not quite sure, I get this right? Does this mean that, if I use the "Headway"-Feature, there won't (only sometines) be anymore trains which run 5:50 hours late in a timetable that is about 6:30? I sometimes really wonder, why my train is THAT late. (The train in my example above should be 0:40 early and not 5:50 late, or not?) Thanks for your help!

No, this was just about how start times are interpreted when you enter them manually as virtual times. Internally, the start date is always in ticks since the year 0. Headway is just a way of setting the start times of all shared vehicles at once. It should not cause vehicles to be late (like timetable start it does actually reset the lateness counter and set the timetables to "not started", however I'm thinking about changing it in this respect). Since the assignment of start times starts with the vehicle for which you execute headway, it may cause a vehicle being about one round-trip early when it arrives at the first station. I'm planning to change this also a bit.

So your 5:50 lateness is really lateness, probably accumulated over some time.

I hope my explanations make it clearer. If you see different behavior than I just described, that is probably a bug. In this case please report it here. (Actually, when I sat in the underground today, I all of a sudden realized,that this -6 to +18 hour window I mentioned above has a bug which will be fixed in the next version, which will come this evening.)

Edit: New bug fix release 1.53 in first post.

German language was not added as it also contained translations for cargodest. However, if you could provide a diff with just the timetable strings I would be happy to include it.

[Tekky]

Here is the new Win32 binary for realistic timetables 1.53 with cargodest.

http://rapidshare.com/files/143238527/r ... 3.zip.html
EDIT: This binary is now out of date. A more recent binary is available later in the thread.

I only gave this new binary a quick test, so, as always, you are using it at your own risk.

I would like to thank PhilSophos for fixing the two bugs that I reported. And, also, thanks for creating this great patch in the first place!

[PhilSophus]

Before it assumed the given time is always in the future (so if you set 19:00 at 19:01 it would take the next 19:00 in almost 24 hours). Now it assumes a window from 6 hours in the past up to 18 hours in the future. So, if its 19:01, times from 13:01 to 19:00 would be interpreted as lying the past and times from 19:02 to 13:00 in the future).

PhilSophus, may I ask you a question, because I'm not quite sure, I get this right? Does this mean that, if I use the "Headway"-Feature, there won't (only sometines) be anymore trains which run 5:50 hours late in a timetable that is about 6:30? I sometimes really wonder, why my train is THAT late. (The train in my example above should be 0:40 early and not 5:50 late, or not?) Thanks for your help!

I just noticed that despite what I wrote before this can come from the headways function. Headway works relative to the start date/time of the vehicle. However, when not set manually the start date is set to the last start of the timetable which of course is always in the past. This is a left-over from Maedhros' patch which I thought wouldn't do any harm but might be an interesting information, but it indeed does harm with the headway function. I'll change this.

I also think of further improving the headway function, so that it readjusts vehicles to the set interval, when timetables are changed and put new vehicles into a sensible position if there is a hole in the headway. This feature will not change the headway interval automatically.

[rbn2903]

I just noticed that despite what I wrote before this can come from the headways function. Headway works relative to the start date/time of the vehicle. However, when not set manually the start date is set to the last start of the timetable which of cause is always in the past. This is a left-over from Maedhros' patch which I thought wouldn't do any harm but might be an interesting information, but it indeed does harm with the headway function. I'll change this.

So I wasn't completely paranoid?

[bokkie]

Bug! (Found in v1.53+cargodest, build by Tekky but was present in earlier versions).

In some train windows, a little bit of space on the right seems to be reserved for a column which isn't there. Oh well, just look in the screenshots Widening the window shows more of the train, while the whole train should've been visible in the first window.

[rbn2903]

I found another bug: In the Trains Timetable window the mousewheel does not work in the green area, but it does in the pink one. If you disable the patch option "Show arrival and departure in timetables", the mousewheel doesn't work at all, as the pink area is not visible in this case.



Oh, i just realise, that this bug is present in v1.52. I've not tested 1.53 yet.

[PhilSophus]

Okay, it was already high time for a bugfix release, so here you are. All bugs reported until now are (hopefully ) fixed. See the History section of the top post for details.
The repair for the not working mousewheel seems kind of hacky. I had to add an invisible scrollbar as mouse scrolling only works for the scrollbar itself and the widget just before it in the widget array.

I didn't get at rewriting the Headway feature so far. Partly, because of lack of time, partly because I noticed, that it isn't this clear what the intended behavior should be in some cases. So, let me give some random thoughts to start a discussion on it:

1. When you start the headway, it may be the case that you have fewer or more vehicles than needed to completely fill the headway. In the first case you obviously have a hole in the headway and I think it is reasonable to leave this hole before the vehicle you executed headway for. In the latter case it might be the best just to continue assigning start times and risking double occupied slot. However, this is not always the case, e.g. if you have a total timetable duration of 4.5 hours and request a headway interval of 1 hour continuing would not cause two vehicles at the same time. A duration of 5 hours would, however, but this should be handled by the user.
2. While I do not think automatic changing of the headway interval would be a good thing, I think preserving the requested interval (and thus repairing the headway) might be. There are several events which might break the headway:
   1. Changing the timetable (waiting time, traveling time, adding/removing orders)
   2. Stopping and restarting a vehicle (or starting one that was stopped during headway assignment)
   3. Adding a vehicle to the headway (i.e. to the shared order list) or removing one
   4. Resetting lateness counter for a vehicle of the headway
   What should happen in each of these cases? Should it be allowed for a headway to have multiple holes or should vehicles try to catch up if the time distance to the previous vehicle is more than the intended interval? Should resetting of a lateness counter cause the other lateness counters to be changed by the same amount or should the resulting breakage of headway just be repaired when it is detected on reaching the first order?
3. Should setting a headway put all vehicle's timetables in a "not started" state as it is now or should they continue in their old timetable until they reach the first order. Both seems reasonable in some cases. Or maybe the lateness should be changed immediately, reflecting the change in headway (might be hard to implement, though).

I would really like to read your comments on that.

[Tekky]

Here is the new Win32 binary for realistic timetables 1.54 with cargodest.

http://rapidshare.com/files/144530354/r ... s_1_54.zip
EDIT: This binary is now out of date. A more recent binary is available later in the thread.

Disclaimer: Please note that I merely compiled the patched source code and checked the binary for viruses using VirusTotal. I have not audited the source code itself. Therefore, I cannot provide any warranty that this binary contains no harmful code.

This disclaimer is only provided for legal reasons and I have no reason to believe that this binary contains harmful code, as I have been using this binary myself.

[AndiK]

Ad 1: After thinking about the problem for some time, I think it'd be best for trains to "fight" for the same position in the schedule. It might look chaotic and cause delays all over the route. But the alternative would be mighty jams in the starting station which could block other routes as well. Apocalypse now.... Oh, and an info message would be much appreciated in this case.

Ad 2:
As far as I know, GUI programming is hell of a job - but I'd love to have a timetable management window with a list of all trains on the route (including stopped ones) and where holes are. One could change the order of vehicles in the list (might be useful sometimes...) and watch the general health of the timetable (holes, average delay, relation between currently set headway and "Autosep" proposal...) Oh, and a general "restart" button might be useful. Starting times stay the same but trains get resorted in the order of arrival at the first station.

2a) Show a warning message if the new timetable settings would lead to holes in the headway.
b) Maybe put a "resort" button in the TT window.

Default behaviour for stopped trains: Put a hole in the plan where the train should usually be. Upon restarting the train, it completes its lap with massive delay. Upon arrival in the first station, it either waits for its hole to "rearrive" or tries to catch up its delay. (Depending on what can be achieved easier. Maybe a setting "When delay is < xx% of tt running time, try to catch up"?)

User pushes "resort": Get the next starting time assigned upon arrival in the first station. (If the train is already stopped there, assign as soon as it gets started)

c) Removing: Put a hole where it was. Adding: Fill the next available hole in the plan. If there are none, behave like 1).

d) Lateness should IMO be managed for the whole timetable. User could push the proposed "restart" button if neccessary.

Ad 3:
I'm all for trains continuing in their old timetable as default behaviour. This might be a good thing to put into the Headway setting window as an option.


Maybe you have noticed that I'm proposing a whole lot of options. This makes coding a bit harder, but gives enthusiastic players a whole lot of tools at their hands that they can use to micromanage their timetables. The big downside of this is that there is quite a lot of stuff you have to understand to use it. This makes it neccessary to find a reasonable default behaviour so that Sepp Gschwendtner from Hinterhuglhapfing* doesn't have to think about all them flashy buttonses.

Just my two cents. Might sound a bit chaotic, but it made perfect sense when the thoughts crawled from my bubbling pool of insanity.

Pfiatseich, Servus

AndiK

* Think of a hill-billy in the bavarian outback

[PhilSophus]

AndiK, thank you for your thoughts. They are really helpful. Due to lack of time, I can't comment on them in detail just now, but I will later!

As for implementation, the more I think about it, the best way is creating a data structure OrderHead or OrderList that resembles a shared order list and where stuff common to the headway can be managed. AFAICS, any other approach would be a lot of working-around the lack of such a data structure, making it hard to understand, hard to maintain or for short error-prone (you already demonstrated in you pseudo-code how easy some things get if you have such a structure). So I'll have to swallow the bitter pill (or to "bite into the sour apple" as we say in German) and implement such a data structure before implementing any advanced headway feature.


Edit: I replaced the trunk version of this patch by version 1.55 which has no new features, but rewrites the order list handling and has to bump savegame for that. Please test for regressions! For details, please see order list rewrite

The cargodest version still has to be updated.

[Tekky]

The cargodest version still has to be updated.

I will post a new cargodest/timetable binary as soon as you release this cargodest patch. I don't want to release any non-cargodest binaries, as it could be confusing if I release both cargodest and non-cargodest binaries.

Please test it with -d misc=6 option and "review vehicle's orders" advanced setting turned on

You wrote this in the other thread. I guess this also applies to this thread?

[PhilSophus]

I will post a new cargodest/timetable binary as soon as you release this cargodest patch. I don't want to release any non-cargodest binaries, as it could be confusing if I release both cargodest and non-cargodest binaries.

To my astonishment the OrderList patch collides quite heavily with cargodest, so I first split it to avoid maintaining the whole 50k patch twice (I should have done that in the first place ) So it takes a little more time than thought.

Please test it with -d misc=6 option and "review vehicle's orders" advanced setting turned on

You wrote this in the other thread. I guess this also applies to this thread?

Yes.

Edit: I finally managed to merge OrderList with cargodest, so cargodest variant is also at 1.55 now.

[Tekky]

I have compiled a Win32 binary of realistic timetables version 1.55 with cargodest. It can be downloaded from this link:

http://rapidshare.com/files/145949114/r ... s_1_55.zip
EDIT: This binary is now out of date. Also, this version is known to create INVALID SAVEGAMES. A more recent binary of a version, in which this bug has been fixed, is available later in this thread.

Disclaimer: Please note that I merely compiled the patched source code and checked the binary for viruses using VirusTotal. I have not audited the source code itself. Therefore, I cannot provide any warranty that this binary contains no harmful code.

This disclaimer is only provided for legal reasons and I have no reason to believe that this binary contains harmful code, as I have been using this binary myself.

[rbn2903]

Hi Tekky, thanks for compiling. Lately I've trouble to do this myself, as BuildOTTD doesn't work (at the moment). I even tried to compile this myself, but I've problems obtaining the Sourcecode for Cargodest manually (like for trunk "svn://svn.openttd.org/trunk") with msys and mingw. I just don't unterstand it. But if you tell me, how you do this, maybe you could reveal your secret Then I finally could have this patch and Daylength

@PhilSophus.
I'll keep looking for bugs I'd also help you with some ideas to the questions you asked before, but this is tooo theoretical for me. All I think is, that, if you for example add a train to a shared order, you should manually confirm the change by using "headway" again.

[Tekky]

Hi Tekky, thanks for compiling. Lately I've trouble to do this myself, as BuildOTTD doesn't work (at the moment). I even tried to compile this myself, but I've problems obtaining the Sourcecode for Cargodest manually (like for trunk "svn://svn.openttd.org/trunk") with msys and mingw. I just don't unterstand it. But if you tell me, how you do this, maybe you could reveal your secret Then I finally could have this patch and Daylength

I assume you are talking about how to optain the source code on a Windows 2000/XP/Vista PC.

Cargodest uses Mercurial instead of SVN. You can download the latest Mercurial Win32 binary from this page. To download the source code, you must write

Code: Select all

hg clone http://hg.openttd.org/developers/celestar/cargodest.hg cargodest-celestar

on the command line. This command puts a copy of the latest cargodest repository into the subdirectory "cargodest-celestar". After that, you must apply the timetable patch supplied by PhilSophus, using

Code: Select all

patch -p1 -i <patchfile>

from inside the directory "cargodest-celestar", i.e. after typing "cd cargodest-celestar".

As far as I remember, MSYS does not supply its own "patch" program. At first I used GnuWin32's patch program, but this program was unable to handle UNIX style line endings and always expected them in Windows format. So, I started using the UnxUtils patch program, which is a port of an older version of GNU patch, but it works perfectly with both UNIX and Windows text formats.
EDIT: In contrast to what I just wrote in this paragraph, MSYS does supply its own "patch" program and I found out that the unxutils version of "patch" does not support UNIX text files on Windows. The "patch" program that works perfectly with me is the one supplied by MSYS. I'm sorry for the confusion caused by my previous false statement. For the above reason, I recommend the "patch" program supplied by MSYS when using a Windows OS.

Please note that you must patch with -p0 instead of -p1 with the daylength patch, because the daylength patch is in a different format than the timetable patch.

When patching, it is important to look at the output of the patch program, as all patches may not have been applied successfully. This is because the source code keeps on changing and therefore may become incompatible with patches which were made for ealier versions of the source code. The patch parts that could not be applied automatically will have to be applied manually, which requires an understanding of the source code.

After obtaining and patching the source code, you must compile it. Follow these instructions if you want to compile with MinGW. You may also compile with Microsoft Visual C++ 2005 or 2008 Express Edition (free of charge), which is what I use. For Visual C++, the instructions can be found here (2005 Edition) and here (2008 Edition).

[PhilSophus]

All I think is, that, if you for example add a train to a shared order, you should manually confirm the change by using "headway" again.

Given that you share orders by ctrl-clicking on another vehicle, wouldn't it be quite annoying if a pop-up would ask for confirmation? I think, if different behaviors make sense, they should be configured as part of the headway setup (i.e. when you also configure the interval).