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

[AndiK]

Maybe one could take the Manhattan distance between stations and use some rough average train speed (i.e. 0.75*vmax) for a first estimate.

And now for something completely different:
Wanna binary with cargodest! Wanna, Wanna, Wanna! *cryinglikeababy*

edit: enlish languag = hart languag

[PhilSophus]

Now presenting: V1.10 which features a "light version" of station timetables. Please see top post for details and download.

Edit: Believe it or not, V1.20 is already out featuring the non-destructive auto-fill mode suggested by Regiovogel.

And now, I need a bit of sleep.

[Roujin]

Now presenting: V1.10 which features a "light version" of station timetables. Please see top post for details and download.

Edit: Believe it or not, V1.20 is already out featuring the non-destructive auto-fill mode suggested by Regiovogel.

And now, I need a bit of sleep.

Nice,
If you manage to get that part (the non-deleting of autofill) into trunk, my flyspray task #1124 from about a year ago when I suggested this could finally be closed

[PhilSophus]

Nice,
If you manage to get that part (the non-deleting of autofill) into trunk, my flyspray task #1124 from about a year ago when I suggested this could finally be closed

So it probably makes sense when I pull that part out (which isn't that hard as it's all separate patches anyway, maybe some conflicts because it's ontop of my patch stack) and attach it to your flyspray suggestion. I'll do so either tomorrow evening or on Monday.

[razielanarki]

maybe it's a little late, but i feel obliged to mention my patch (#2008).

i knew i wasn't the only one bothered by the clearing autofill

[Tekky]

Wouldn't it be more appropriate to use absolute time values in the timetable instead of time values relative to the last order? Using absolute time values would make the timetables support conditional jump orders better.

[Eddi]

i'm sure there are situations where absolute times are worse than relative, so both should be possible...

i had no chance to test the patch yet, but i'd like to request a news message when a vehicle is significantly late (where the value of "significantly" is to be determined by a patch setting)

[PhilSophus]

Okay, I have now attached the non-destructive autofill part to Roujin's flyspray feature request #1124. If you would like to have this in trunk consider voting for the task.

Wouldn't it be more appropriate to use absolute time values in the timetable instead of time values relative to the last order? Using absolute time values would make the timetables support conditional jump orders better.

i'm sure there are situations where absolute times are worse than relative, so both should be possible...

I assume that absolute is supposed to mean relative from the starting of the timetable. I'm not sure that this is so useful. At least relative times are much easier to deal with if you fill in the timetable (at least partly) manually, which non-destructive autofill encourages.
You have a valid point mentioning conditional orders, though, but they don't fit in with strictly planned timetables anyway. Wouldn't using absolute times with conditional order just mean that you had to wait for a long time somewhere if the conditional order is not executed? I'm also not yet sure, how to treat "service in depot" orders which is in effect also kind of a conditional order.

i had no chance to test the patch yet, but i'd like to request a news message when a vehicle is significantly late (where the value of "significantly" is to be determined by a patch setting)

Good idea. I had such a feature in an experimental timetable patch I had running before timetables hit trunk (while working correctly technically, it didn't gameplay-wise. That's why I never published it.) I'll put that on my TODO list. I'm only a bit afraid that we get an explosion of patch settings.

[Regiovogel]

Hi PhilSophus,

I just wanted to thank you for including my suggestion. Voted for it

But once again, I'm asking for a Win32 binary (preferably with CargoDest ). We three people from south germany don't seem to be able to cope with compiling OpenTTD. Either it doesn't compile at all, the compiled file is massively corrupted (compiling without any warnings, but isn't even able to be executed - it crashes immediately) or - this is my own case - I don't understand what the wiki says what files are needed really. (On the one hand, it says "install this", and a few lines later it says "do not install, just copy some files out of it")


Maybe we're only unable to do it. If someone can point out what we're doing wrong, please do so...
I would be really glad to test the feature suggested by me.

Greetz,
Regiovogel

[Tekky]

I assume that absolute is supposed to mean relative from the starting of the timetable.

Yes, that is correct.

I'm not sure that this is so useful. At least relative times are much easier to deal with if you fill in the timetable (at least partly) manually, which non-destructive autofill encourages.
You have a valid point mentioning conditional orders, though, but they don't fit in with strictly planned timetables anyway. Wouldn't using absolute times with conditional order just mean that you had to wait for a long time somewhere if the conditional order is not executed? I'm also not yet sure, how to treat "service in depot" orders which is in effect also kind of a conditional order.

I believe that handling conditional orders is very important for the concept of timetables, because, as you rightly said, a "service in depot" order is also a conditional order, even if it does not contain an explicit conditional jump.

Wouldn't using absolute times with conditional order just mean that you had to wait for a long time somewhere if the conditional order is not executed?

Yes, or one could make the time in the timetable so that trains who execute the conditional order will be a little late and trains who do not will be a little early.

But once again, I'm asking for a Win32 binary (preferably with CargoDest )

I will compile a Win32 binary for you in a moment. Please give me 10 minutes.

[AndiK]

I am testing my own Binary with Cargodest right now.
Let me just try out a few things and I will post a link here.

Edit:
Proudly presenting: my binary with Cargodest!
I don't give any warranty about anything - but it works pretty well even in Multiplayer, so far.

[Tekky]

Proudly presenting: my binary with Cargodest!
I don't give any warranty about anything - but it works pretty well even in Multiplayer, so far.

Did you patch against the latest cargodest (with savegame bump) or against revision e79bdd28d8bb, for which version 1.2 of the timetable patch was originally designed?

[AndiK]

hg tip says:
changeset: 19779:3cd2b4a0e1a3
tag: tip
parent: 19764:f73d2f50bb61
parent: 19778:2e4575f188ad
user: vici@rivendell.site
date: Mon Sep 01 09:26:24 2008 +0200
summary: Merge from trunk

Savegame version is 104.

[Tekky]

since changeset 17960, cargodest uses savegame version 104, so shouldn't TIMETABLE_SAVELOAD_VERSION be incremented to 105?

[AndiK]

You mean I'm supposed to do a savegame bump upon publishing a patched nightly? Wouldn't version 105 be used by the next significantly changed nightly, anyway?
If it's necessary, I'll do the bump. I just haven't understood why, yet.

[PhilSophus]

Sorry to spoil your just compiled binaries

But there it is: V1.30 features:

• the lateness warning suggested by Eddi
• fixes the graphical glitches when changing patch settings
• improves the GUI for setting times by adding a text field

Edit: And BTW the cargodest version is bumped to 105

I'm not sure that this is so useful. At least relative times are much easier to deal with if you fill in the timetable (at least partly) manually, which non-destructive autofill encourages.
You have a valid point mentioning conditional orders, though, but they don't fit in with strictly planned timetables anyway. Wouldn't using absolute times with conditional order just mean that you had to wait for a long time somewhere if the conditional order is not executed? I'm also not yet sure, how to treat "service in depot" orders which is in effect also kind of a conditional order.

I believe that handling conditional orders is very important for the concept of timetables, because, as you rightly said, a "service in depot" order is also a conditional order, even if it does not contain an explicit conditional jump.

Wouldn't using absolute times with conditional order just mean that you had to wait for a long time somewhere if the conditional order is not executed?

Yes, or one could make the time in the timetable so that trains who execute the conditional order will be a little late and trains who do not will be a little early.

But you are forgetting that there is also the "jump to order" order which means you can conditionally skip whole parts of the timetable. I might change the "all or nothing" approach when showing arrivals and departures, that is arrivals and departures could be shown up to the next conditional or non-timetabled order, but I don't see what can reasonably be done about conditional orders (conceptually I mean, I'm not even talking about implementation). Service orders are a bit of an exception here, as they are not that general.

[Roujin]

You mean I'm supposed to do a savegame bump upon publishing a patched nightly? Wouldn't version 105 be used by the next significantly changed nightly, anyway?
If it's necessary, I'll do the bump. I just haven't understood why, yet.

If you introduce new patch settings, you do a savegame bump and specify your new patch settings to be used from that savegame version onwards. This makes it possible to load clean trunk savegames and play them with the patched game. (Because when you load a savegame of a lower savegame version, the game will know that those patch settings weren't existing back then and doesn't try to get them from the savegame but just take the default values.)

If trunk has version 104 and you introduce new patch settings in your patch but still use savegame version 104, the patched game won't be able to load clean trunk saves because it will try to get the values for the newly introduced patch settings from the savegame, which, of course, aren't in there. It will fail loading and say that the savegame is broken (while actually, you broke its information what values are expected in this version).



This practice (bumping +1 from trunk) is commonly used with user patches that introduce new patch settings. Its downside is that when a savegame bump is done in trunk and the patch is updated for the new trunk version, backwards compatibility towards the older version of the patch is lost.

[Tekky]

You mean I'm supposed to do a savegame bump upon publishing a patched nightly? Wouldn't version 105 be used by the next significantly changed nightly, anyway?
If it's necessary, I'll do the bump. I just haven't understood why, yet.

Both version 1.20 and version 1.30 of the timetable patch for cargodest bump the savegame version by one. Therefore, it seemed strange to me that you did not bump it up from 104 to 105 in your binary, but instead left it the same. However, as far as I understand, cargodest has already bumped up the savegame version by one, so bumping it up a further time in the timetable patch for cargodest is not necessary. This is only necessary in the timetable patch for trunk(not cargodest!), if I understand correctly.

[Roujin]

Well, it would be necessary if you wanted to load savegames from the "clean" cargodest build you are basing your patch on. See my last post for explanation.

[Tekky]

Ah, yes, I was surprised that my old cargodest game worked with the new timetable patch. Now I know the reason why. So the additional savegame bump IS necessary.