Timetable based separation patch

[MagicBuzz]

That's something I thought about. Mostly when you replace your vehicle with a new one : you always have to fill again the timetable, then the vehicles just need to separate again, that's quite annoying and a reproach that was already formulated against this patch and I agree with that.

Here is an attempt to :

1/ Reduce lateness_counter by 50% when entering the first station of the shared order
2/ Continuously autofill the first vehicle timetable with a 20% correction against the actual journey duration when entering any station

It's experimental, and I notice some things that are not correct about lateness_counter, but it works pretty well though.

The change is rather smaller than I thought : only a few new lines (about 2 checks and 2 lines of new code)

-- Edit : With attached file it should be better

[PhilSophus]

Hey, you are approaching 7x24 service Don't forget to take your time to relax.

I'll have a look at the patch in the evening.

[glx]

Mostly when you replace your vehicle with a new one : you always have to fill again the timetable

That should be already fixed.

[MagicBuzz]

Why do you mean by "this should be already fixed" ?

My patch (until the yesterday's update) wasn't changing the timetable when you change the engine of your vehicle (autorenew feature by exemple).
And I don't think the timetable feature already do this (is it ?)

My update just now leave the autofill flag set to true on the first vehicle in the shared order list, and it refresh the time with 20% of the difference with the new time. By this way, if your vehicle have a substancial change in its travel times due to engine replace or tracks changes, then after 5 or 6 trips, it will use an updated timetable. But if it's a one-time change (traffic jam, break down, etc.) the impact will be minor and will reduce the next time the vehicle travel on this section.

Same with lateness counter, the first vehicle reduces automatically its lateness_counter when entering the first station in the timetabled trip. By this way, your trains won't spend months to run in time again after some incidents on the tracks.

I don't see how it could be fixed before I did this change... (??)

[glx]

I mean the timetable is "copied" when you manually replace a vehicle since r12296 (and it worked for autoreplace before).
But maybe I misunderstood what you said.

[MagicBuzz]

Yeah, I know.

What I mean it that the timetable isn't automatically refreshed with the new traval time of your new material.

As result, when you upgrade your vehicle with a faster one by exemple, you have to manually fill again the timetable in order to have a timetable that fit with the new vehicle specs.

With my patch refresh, this is fixed automatically.

[zypa]

First of all: Your patch is really great!

Now the question:
Is there a possibility to autofill the schedule better than in the way it's done atm? The time between stations works fine, but the wait/load time at a station is quite difficult to calculate. Is it possible to autofull the schedule with max load/max unload wait time at every station?

[MagicBuzz]

This should be handled by the "timetable" patch (the patch already in trunk my patch is based on).

Most of the time, I just fill an arbitrary value that is slightly greater than the time a vehicle takes to fully unload then full load (when there is enought cargo at the station to fill it).

By exemple, for a bus, it would be 150 ticks for a small bus, 200 for a common bus and 300 for a bouble deck bus, or 300 for a small train (4 passenger carriages) or 800 for a big train (13 carriages).

You can also try to tune it by creating the timetable with arbitrary long values (such as double of the values above), and let the station rates to grow for a while. When the ratings are good, just reset the timetable, and round to the upper about ten value (i mean, if the vehicle stops for 492 ticks, round it to 500). It should just work fine.

[Tiberius]

A small bump to near-trunk version (r13704)

[dbkblk]

What is missing in this patch to get in trunk ? This is one of the most useful feature to make timetables a sense !

[dbkblk]

I don't want to annoy someone but do you plan to put it in the trunk ?

[MagicBuzz]

Hello,

Thank you Tiberius for the refresh, I'll update the first page with it.

dbkblk, thank you also for your support. I don't know why this patch won't get in the trunk. Imho, this patch is just the "final" version of the timetable feature already in trunk. I fixed every comments about coding rules, so it should not be the reason.
One time, I got an answer about the question you ask from an official trunk developper : "It won't be in the trunk because I don't like this patch, I think it's useless", or something like that. So I think the evident reason this patch is still not in the trunk is here : no official dev currently like this patch. I played a long time with it, and never found any critical issue. I have to admimt sometimes it doesn't do what I expected, but most of the time it works very well. It helps a lot with trains and road vehicle I think, and is easy to use compared to the original timetable feature.

Another reason (and I hope it's this one the real one), is that I still never got any feedback about network gaming using this patch. I did some tests, but all alone, so I can't say "it works fine". I didn't experience any issue, but some players should confirm that with real networking experience.

[dbkblk]

In that way, it's a shame to not get it into the trunk I am forced to choose between "NoAI" and Timetable Separation arrrrrrrrg

Anyway, if you could compile your patch with the last one of noai i could test (again) both at the same time !

[Timitry]

Well, i think this patch is VERY useful, and i wonder if there really is no developer who likes it...

[bokkie]

There's a similar patch to this one made by a developer (who didn't look at this one if i remember correctly somehow) in the general section. It was looking for testers but there weren't many replies. Also, it seemed a bit more difficult when it comes to when you can auto-seperate the vehicles.

EDIT: http://www.tt-forums.net/viewtopic.php? ... o+seperate
Ony tried it in a patchpack but in that it was bugged but as I like to play with paxdest I didn't test it 'plain'

[ashb]

So i've been playing with cargodist, and I really wanted automatic separation.

So i've updated the patch to r16734. Seems to work

[bokkie]

Mmm can't seem to make a build with both your patch and the latest cargodist against r16671. Patching is OK when applying cargodist first but Mingw throws a lot of warnings and some errors when compiling. I tried to use Buildottd but since the patches need -p1 I had to try it manually with the programs provided with it. Do you happen to have a windows build with both patches? I'm going to give it another try in a few days but since it has already taken me some hours it would be nice to just be able to play with it instead of trying to compile it .

[ashb]

Ah yes, that patch was one that applied to trunk.

Here is the one against revision 1056ff7db1 of the cargodist git branch:

timetable-separation_cargodist-1056ff7db1.patch

Against 1056ff7db1 from http://fickzoo.com/fonsinchen/openttd.git

(14.23 KiB) Downloaded 193 times

[bokkie]

Nice, tnx! Win32 build attached! Did give me some warnings when compiling but haven't found a bug in 10 minutes playtesting.

WARNING: OTHER PLAYERS SAY THERE ARE BUGS!!!

[id10terror]

Thanks heaps guys!!! keep up the excellent work!

-=Edit=-
Been around 6 months ingame and it seams the ai is working fine in this build (AdmiralAI v22, NoCAB 1.22, PathZilla V6(This is my first test of this ai, and it looks stunning given its playing on an experimental build with additions not found in the current nightly) & WrightAI V3 (shared comment with: PathZilla)

Now at 12 months, No AI has been reloaded, the AI's seem stable