Transport Tycoon Forums

Now presenting V2.00 of Improved Timetable Management [ITiM] (formerly known as realistic timetables).

The headway feature has been rewritten. The most obvious change is a nice GUI which shows which vehicle is were in the shared order list, and how big is the theoretical gap (i.e. if the vehicles were on time) between vehicles. When clicking on an order, a vehicle or a gap it shows informations on the affected vehicles.

The window allows you to change the timetable by CTRL-clicking on an order and opens one/both vehicle window(s) by CTRL-clicking on a vehicle or on a gap.
Internally, headway now works as follows: You enable it by setting an interval (clicking keeps the last selected interval or presets with the equal-separation value when none was set, CTRL-click always presets with the equal-separation value). If a vehicle is the selected, this one will be elected as the headway leader, if none is selected the next vehicle to arrive at the first order will be the headway leader. The start time of the leader will be honored when one is set.

When the leader arrives at the first order after you enabled headway, a phase called "first round" starts. All vehicles arriving after the leader get there lateness adjusted so that they keep the desired interval when on time. The first round ends when the leader re-arrives at the first order. The gap between the last vehicle and the leader may of course be different from your selected interval.

After the first round has ended, headway keeps out of your way unless you activate "automatic" mode, which works like a permanent first round and thus can adopt for overtaking, skipping orders, changing timetables, adding and removing vehicles.

At any time, vehicles keep running in their timetables. They are not set to "timetable not started". Headway only modifies the lateness of vehicles when arriving at the first order and only when either being in the first round or in automatic mode.

The "Reset Late Counters" button in the headway window changes the lateness of all vehicles in the headway by the same amount and makes sure that this amount is dividable by the headway interval (I'm not sure if the latter should be kept). Clicking on the button makes sure that no vehicle is late after this (causing most vehicles of the headway to be early). CTRL-clicking only adjusts by the least delay (rounded down to headway interval).

There is probably a lot more to say, what I just forgot, so ask if something is not clear. I guess much becomes obvious when trying it out as you now get visual feedback of what happens.


I also attached a little patch taken out from the old passenger destination patch by prissi that allows to reduce the number of passengers by the selected power of two (i.e. 0: no effect, 1: cut in half, 2: cut to a quarter, ...). The patch is meant to be applied on-top of the cargodest version of "ITiM" and it bumps the savegame version a further step.

Here is the new Win32 binary of improved timetable management version 2.00 with cargodest. I have supplied two binaries, one with and one without the passenger reduction patch.

Legal Information:
Please note that this program is copyrighted and licensed under version 2 of the General Public License, which means -among other things - that it is distributed without any warranty. Please see the file COPYING.txt for further information, which is included in the .zip archive. I have supplied this notice because it is mandatory according to section 1 of the GPL.

EDIT: This binary is now out of date. A more recent binary is available later in the thread.

Hi PhilSophus,

sorry for not replying until now, I've had no time for that so far. I'm currently testing the new version and think I have found the problem. It seems to be working now as I'm using the Hours:Minutes display for timetables. However, I prefer ticks for timetables. I just did a quick test: Setting the display back to ticks and changing the headway to 1200 ticks resulted as "Interval: 400 ticks" in the headway window. That seems strange, isn't it? If I understand it correctly, you don't need to set a start date any more? Btw, when opening the start date window, the default value is 15 years in the future with timetables shown in ticks - perhaps it has something to do with that setting.

I haven't seen very much of the new version, but I'm impressed of what I have seen until now. It's great, thank you

Up to now, I haven't played it yet, I have only compiled the binaries. But I must say, I love the new GUI as seen in the screenshot Thanks PhilSophus!

@PhilSophus: I am considering to make my own patchpack which includes this patch and your stop in depot order patch. Do you give me permission to do this? If so, it would be nice if you could make a statement licensing your patches under version 2 of the GPL, similar to the statement of forum user "Swallow" in this post. Actually, I think I violated your copyright and the license of OpenTTD itself by posting a binary of your patch without obtaining a GPL-compatible license from your beforehand.

Tekky wrote:@PhilSophus: I am considering to make my own patchpack which includes this patch and your stop in depot order patch. Do you give me permission to do this? If so, it would be nice if you could make a statement licensing your patches under version 2 of the GPL, similar to the statement of forum user "Swallow" in this post. Actually, I think I violated your copyright and the license of OpenTTD itself by posting a binary of your patch without obtaining a GPL-compatible license form your beforehand.

Of course, I would be honored if you put my patches into your patch pack and am looking forward to try it out

As for the legal stuff: I believe that every patch for OpenTTD unless stated otherwise by the author is licensed under GPL v2 as it is derivative work of OpenTTD. So, I believe that such an explicit statement is not needed. If it was needed that would mean I wouldn't be in the position to give it as I used patches without such an explicit statement for my work. You see the dilemma, here

Thus, I consider my work to be licensed under GPL v2 under the assumption that all patches I used are licensed under GPL v2.

Anyway I assure you that you are not breaking my intellectual property rights when posting binaries for my patches or use them in a patch pack, as long as this happens either in the topic of the patch or a link to the topic of the patch is given. Whether, you are breaking other people's rights you must check yourself.

This is just my personal opinion on this subject and no legal advice to anyone. I am not a lawyer an thus not allowed to give legal advice by German law.

Regiovogel wrote:1200 ticks resulted as "Interval: 400 ticks" in the headway window. That seems strange, isn't it?

That sounds like a value given in ticks to be interpreted as virtual seconds and getting converted. Is the virtual time factor set to 3?

Regiovogel wrote:If I understand it correctly, you don't need to set a start date any more?

That's correct. For any vehicle except for the leader it is even ignored during first round or automatic mode as this overrides the lateness.

Regiovogel wrote: Btw, when opening the start date window, the default value is 15 years in the future with timetables shown in ticks - perhaps it has something to do with that setting.

I'll have a look at this. I'm always playing in virtual time scale, this is why I didn't notice it myself.

PhilSophus wrote:

Regiovogel wrote:1200 ticks resulted as "Interval: 400 ticks" in the headway window. That seems strange, isn't it?

That sounds like a value given in ticks to be interpreted as virtual seconds and getting converted. Is the virtual time factor set to 3?

Yes, it is. I just realized that ctrl-clicking on "Set interval" with ticks enabled doesn't set a value if there was no value set before.

PhilSophus wrote:

Regiovogel wrote: Btw, when opening the start date window, the default value is 15 years in the future with timetables shown in ticks - perhaps it has something to do with that setting.

I'll have a look at this. I'm always playing in virtual time scale, this is why I didn't notice it myself.

I thought so With the virtual time scale it works as it should.

The passenger reduction is a good addition for cargodest, thanks for adding it. The new version is great

Hello Philsophus,

this new GUI is outstanding!!!! I really like it. But I do have a bug which causes the whole game to freeze. Steps to reproduce (a savegame won't be helpfull I guess).

1. Start a new game.
2. Build a depot and two stations. You may connect them like in a real network, but it makes no difference, the error will happen anyway.
3. Buy a train and give him two orders to the stations.
4. Don't start the train!
5. Clone the train with shared orders.
6. The Headway button will now become enabled. If you click it, the whole game will freeze.

I guess this happens, because the headway GUI has nothing to do, as it only uses non-stopped trains. Maybe it should check, if all the trains in a shared order are stopped and then not enable the button. I hope I could help

I'm using Tekkys compiled version "improved_timetable_management_2_00_with_reduction.zip". btw thanks for that too


Rainer

PhilSophus wrote:I also attached a little patch taken out from the old passenger destination patch by prissi that allows to reduce the number of passengers by the selected power of two (i.e. 0: no effect, 1: cut in half, 2: cut to a quarter, ...). The patch is meant to be applied on-top of the cargodest version of "ITiM" and it bumps the savegame version a further step.

Are you also able to adapt a patch for mail too? I now find that there is more mail generated than passengers using this patch.

PhilSophus wrote:As for the legal stuff: I believe that every patch for OpenTTD unless stated otherwise by the author is licensed under GPL v2 as it is derivative work of OpenTTD.

You might think that was a safe assumption, but it might not be. Quite aside from the fact that not all patches are derivative works,[1] not all patches are even legal. A patch might contain unlicensed code, or even unlicensable code. Assuming that all patches are GPL because they are to be applied against GPL code is wishful thinking at best. At the very least you need some reasonable evidence that it is, in fact, GPL code. This can be included in the patch's comments, or a statement could be made an the accompanying body of text. Tekky was correct to ask for clarification, because without it the only fairly safe assumption is that there's an implicit license to read the patch because it's on a public forum. There's certainly no implied license to include it in other people's works.

[1]in fact, supplying a patch is often used as a way around licensing; the LAME mp3 encoder originally used this to side-step licensing of the ISO reference MP3 implementation.

Wibblebutt wrote:

PhilSophus wrote:I also attached a little patch taken out from the old passenger destination patch by prissi that allows to reduce the number of passengers by the selected power of two (i.e. 0: no effect, 1: cut in half, 2: cut to a quarter, ...). The patch is meant to be applied on-top of the cargodest version of "ITiM" and it bumps the savegame version a further step.

Are you also able to adapt a patch for mail too? I now find that there is more mail generated than passengers using this patch.

I never play with mail

Honestly, either all cargoes would be reduced by the same factor (which wouldn't be a good thing, AFAICT from my playing with ECS) or we would need a separate setting for each cargo (which would be too many settings and hard to do since NewGRFs add cargoes). So, I rather keep it what it is (a quick and dirty, but simple hack) and put my effort into ITiM (fixing the reported bugs that is ).

If anyone wants to improve the passenger reduction patch: Feel free to do this.

Hi, i found a bug. Two trains with shared orders stopped running. One waits in depot, one waits for free path, although there is free path and other trains runs throught station without problem.

zde-nek wrote:Hi, i found a bug. Two trains with shared orders stopped running. One waits in depot, one waits for free path, although there is free path and other trains runs throught station without problem.

I highly doubt that this is a ITiM bug, as that only modifies the lateness. If the train waited at the station thinking it was to early it wouldn't say "waiting for free path" (and the screenshot looks as if it wasn't waiting in the station but had already left anyway). But without a savegame I can not tell for sure (and please specify the version you are using).

PhilSophus wrote:

zde-nek wrote:Hi, i found a bug. Two trains with shared orders stopped running. One waits in depot, one waits for free path, although there is free path and other trains runs throught station without problem.

I highly doubt that this is a ITiM bug, as that only modifies the lateness. If the train waited at the station thinking it was to early it wouldn't say "waiting for free path" (and the screenshot looks as if it wasn't waiting in the station but had already left anyway). But without a savegame I can not tell for sure (and please specify the version you are using).

I found that it is probably problem with YAPF, because when I forced train 6 to continue despite of signals, it got to depot and then both trains ran normally.

Okay, the reported problems when ticks or days were the selected unit are fixed. Also the headway window now can only be opened if the number of non-stopped-in-depot vehicles is at least two and the window is closed when this is no longer true.

The updated version is attached to the first post. You can safely continue your games with the updated version.

I didn't merge newer trunk revisions as cargodest didn't either and I didn't want to take the trouble of adopting to too different trunk revisions.

Regiovogel wrote:Yes, it is. I just realized that ctrl-clicking on "Set interval" with ticks enabled doesn't set a value if there was no value set before.

I couldn't reproduce this one. Maybe the fixes I did before trying repaired it, although IMHO none of the problems I fixed could have caused it to my understanding. If it still happens please post a savegame which reproduces the problem.

Here is the new Win32 binary of improved timetable management version 2.01 with cargodest. I have again supplied two binaries, one with and one without the passenger reduction patch.

Legal Information:
Please note that this program is copyrighted and licensed under version 2 of the General Public License, which means -among other things - that it is distributed without any warranty. Please see the file COPYING.txt for further information, which is included in the .zip archive. I have supplied this notice because it is mandatory according to section 1 of the GPL.

EDIT: This binary is now out of date. A more recent binary is available later in the thread.

Hi PhilSophus,

at least for ticks, ctrl-click on "Set interval" doesn't work. The proposed value is right, but it can't be set. If you change the value (to any other than the proposed), it sets it - clicking OK does not change the value. Even typing it manually doesn't help (only, when the window is not opened with ctrl-click). Every other value works, very strange

@Regiovogel:

The bug you just reported is very similar to the bug I reported in this post a very long time ago. This bug has been fixed, but I guess PhilSophus introduced the same kind of bug again.

I assume PhilSophus is using an EditBox graphical element which, by default, assumes that not changing the value is equivalent to pressing the Cancel button. Such behavior is meaningful in many situations, but it is not meaningful when the program proposes a value and the user is supposed to simply press "OK" to accept it.


@PhilSophus:

Please don't interpret what I just said as a confirmation of the bug that Regiovogel reported. I just wanted to offer a possible explanation of the bug, based on the description provided by Regiovogel. I have not encountered this bug myself.

Regiovogel wrote:at least for ticks, ctrl-click on "Set interval" doesn't work. The proposed value is right, but it can't be set. If you change the value (to any other than the proposed), it sets it - clicking OK does not change the value. Even typing it manually doesn't help (only, when the window is not opened with ctrl-click). Every other value works, very strange

Tekky wrote: I assume PhilSophus is using an EditBox graphical element which, by default, assumes that not changing the value is equivalent to pressing the Cancel button. Such behavior is meaningful in many situations, but it is not meaningful when the program proposes a value and the user is supposed to simply press "OK" to accept it.

Tekky wrote: Please don't interpret what I just said as a confirmation of the bug that Regiovogel reported. I just wanted to offer a possible explanation of the bug, based on the description provided by Regiovogel. I have not encountered this bug myself.

I can confirm that the bug exists. When trying to reproduce it the first time, I just stopped before actually setting the value .

Your explanation sounded very plausible. Unfortunately, the code looked as it should, or should I say as it should have looked like before trunk changed where the necessary flag is stored It used to be a bit of the length field now it is in a separate flags field. So, until the next version you can now enter 4127 characters in this field , but you must change it.

The bug will be fixed in the next version.

Hi PhilSophus,

at the moment, we're playing a multiplayer game with V2.01 and it's great. I can't imagine playing without timetables now
Setting another interval value and changing it again is a good workaround for the bug, but it's a bit annoying

However, we've just had a problem with CargoDest. Right after expanding a line, there were some messages that no destination was found. I suppose the savegame should be posted in the CargoDest thread? (Typing "rn rr" into the console solved the problem)

By the way: Tekky, thank you for providing the binaries with every new version... I couldn't manage to use patch files until today, so your service is appreciated!

Regiovogel wrote:However, we've just had a problem with CargoDest. Right after expanding a line, there were some messages that no destination was found. I suppose the savegame should be posted in the CargoDest thread?

The savegames produced by ITiM are not compatible with cargodest. Therefore, it would only be meaningful to place a cargodest savegame and not an ITiM savegame into the cargodest thread. Would it be possible to reproduce the bug easily with the cargodest binary?

Regiovogel wrote:By the way: Tekky, thank you for providing the binaries with every new version... I couldn't manage to use patch files until today, so your service is appreciated!

I'm pleased that I was able to help you with my binaries.