Automated timetables and separation

[Gathers]

Thanks for your comments! Now to answer the questions..

bokkie Yes, a binary would be appreciated. Perhaps petert or someone will be kind and post another?
And no, I've not yet looked closely at the other patches.

Jimbow From my understanding of the daylength patch (I've only glanced at it quickly though) 20 ticks would still pass just as fast. I'd only have to change my use of DAY_TICKS to ORIG_DAY_TICKS, but that's not a problem. In fact I'm not sure I should even use DAY_TICKS at all to begin with, and if I remove that I don't see why there'd be any troubles.

peebee and robotboy Yes, it works with cargodist. In fact, my patch-branch and the cargodist-branch merges cleanly into each other so there are not even any conflicts to resolve. I'm not sure why they didn't apply cleanly for petert, perhaps he used another version of cargodist or I made some error when I made that patch file, but they should work together.

Terkhen As a git user, I like branches. This patch I've made is already split in two. (one for updating the timetable and one for the separation) So if I do import anything from ITiM it'll probably go into a separate branch as well.

[ChillCore]

Hi Gathers,

Most of the times when I test a patch I load my longlasting savegame.
Maybe I should try with a new game as many trains were early/late even after a few rounds but that is related to the nature of my trackbuilding I think. (Spaghetti is nothing compared to it, I even switch tracksides a few times just for fun )
I will try again when I find some time and let it run a little longer ...

One suggestion if I may,
It would have been nice to have a button to start timetabling and seperating all vehicles in one click.

Keep going ...

[Gathers]

What do you mean by one button and where would you place it? Right now there's the "automate" button, which turns things on for every vehicle it shares orders with. I'm not sure anything more than that is needed since you would usually want to control it on a "shared orders group" basis, so that you can have some groups of vehicles that use separation and some that don't use timetables at all.

[ChillCore]

Please see attachment to see where I would put such button and still allow for grouped enabling / disabling of timetabling. (If I would have created groups that is.)

[rbn2903]

Hi Gathers,

I just tested this patch of yours and I have to say: It's amazing how simple it is (sry PhilSophus )! With this patch playing CargoDist is much more fun

But I have one complaint too. This autofill-feature changes also the waiting time at stations. While this is OK and also neccessary for longer waiting times, it is quite annoying if it changes the value to a lower one. Maybe you could add a setting that allows to set the minimal station waiting time. ITiM had such feature too, although it worked different than I just described. What do you think of that?

Oh, and maybe you could add to the tooltip of the automate-button that the timetable will remain static when you ctrl-click it (But this is of course just i-candy for the moment).

Keep up the good work!

Rainer

[peebee]

Hi Rainer!

Sound good! Could you load up your build if it is for w32?

[rbn2903]

I don't have the "COPYING"-file and a few others anymore, but you could try to build it yourself. Cargodist and ATAS are both for revision 18790, but there is a bug in trunk which is quite annoying. This bug got fixed in r18797 and both patches apply cleanly to trunk r18797.

The wiki is really good: wiki.openttd.org You have to have some time if you are new to this.

[Gathers]

Hi Rainer, thanks for your comments.

Sure, I could add something to the tooltip. I'm not just sure what should be the default action when clicking it without ctrl. Perhaps it's better if you need to hold ctrl to clear all the times and stop the timetable completely?

About setting minimal station waiting times:
Should it be set per order or should the same value be used for all waiting times? (perhaps holding ctrl to switch behaviour could be used here as well)
What is most interesting to set? A min-time? A max-time? Both? Or perhaps a fixed time? Or a fixed time that is always added to the automatically-derived time?

But ideally, I'd like to deal less with coding gui options and more on improving the automatic mode to the point where it "just works" well enough. If you have a situation where you think it's behaving extra badly then feel free to upload a savegame and I'll take a look at it.

[rbn2903]

I didn't even think of that. You are right, maybe it IS better to not clear all times when clicking on the automate button a second time, because - let's face it - if you want to play with automated separation, you only want to deactivate it on massive changes in the (rail|road|air|water) network.

Min-Time: I think the problem is in the beginning. Imagine you just build a few station where still no passenger waits. Then a train arrives and continues without waiting. this time is usually "0" and afterwords passengers appear, waiting at the platforms. The next train would actually need some days before it can go Max-Time: on. So this is an inital failure in the timetable which will vanish at least in the second "round".
But I'm not sure, if a maximum waiting time is neccessary because a train will go on further by the time it's full. So this "time" is already limited in trunk. And the only abnormality I can imagine is that the user sets a "full load" order which is ... äh .. kind of stupid.
Both: Well, as I find max-time not useful, you can conclude my opinion to both.
fixed: This option would only work, if the expected waiting time is identical for all station, but especially with cargodist, there are station which are more OR less frequented.
added:: this would would lead to all vehicles waiting longer than neccessary.

Other opinions (than Gathers or mine) to this issue are welcome

Unfortunately I have only a custom build with Cargodist + ATaS, so you wont be able to open my saves :/ Besides I don't play regularly so most bugs would have been reported by the time I find it myself. But I'll keep testing it!!

[rbn2903]

Hello Gathers,

I just did an other testrun with your patch. The attached savegame war created with a MSYS/MinGW-Build of your patch in the first post against trunk r18790. It does NOT contain CargoDist, or NewGRFs or even NoAIs!!!! So you should be able to run it.

Please notice that I have four passenger/post lines (A, B, C, D) with different building styles. Each line has four stations, which means the orders are all the same: 1-2-3-4-3-2. As there are six orders, there are also six trains (respectively twelve on line D which is heavily oversaturated ). Start the trains alltogether with the button in the depot!!! I noticed following things:

1) Why is the first train that arrives at station (ABCD)3 waiting so long?
2) It seems that it takes at least 6 cycles, before the trains are separated correctly. On line D I couldn't even count it, but it happens In my opinion this is a very long time. Is there any way to reduce this time???

Thanks, Rainer

[Gathers]

Hi again! Thank you for testing and for providing such a nice savegame! It's been very useful already!

1) It was a result of attempting to compensate for vehicles not being on time, before their correct position in the timetable was known. But that's fixed now so the first round shouldn't have such delays anymore.

2) It seems that I had made the initial separation speed worse while tweaking and trying other things, but I've uploaded a new version now that I hope will be a little better.

[rbn2903]

Wow, that was fast! Thank you, this new version performs quite well.

In my testrun (same savegame) today "Line A" took nearly 3 cycles (1st + 2 others) to be separated correctly. "Line D" took about 5 to 6 cycles where before I couldn't even count it.

I also added two trains to "Line A" and this takes 2 cycles to be assimilated (maybe resistance is futile ). The same time when taking those two trains out of "Line A" again. I think this is a very good performance and something I would expect as a long-time (Open)TTD-Player and hobby-programmer (unfortunately just VB.Net, otherwise I might be able to help you better, but I do unterstand C++ mostly). BUT would some rookie also expect it to take a while? Do you have to warn him, that "automating" or changing the orders/numbers of trains does not take effect immediatly? Maybe this would be a nice hint to put on some wiki-page.

Just to mention it, I also created some planes. They perfmorm quite well to, but the airports are kind of a bottleneck and create delays!

Also I have to rethink my idea of a minimal waiting time. actually I think it is good as it is now. Maybe one doesn't want to make too much all at once!

Is there anything (except a real game, not such a constructed one) I could test for this patch to be finished? Are you considering getting this patch in trunk? This actually would be great, but I don't know how well the idea is received with the developers. Actually I think I remember belugas saying he sees no point in an automated separated timetable. I don't have the quote right now, but it's somewhere here in the forums

Enough from me for now! Greets, Rainer

Edit: Actually I found it. But belugas' message was different from what I remembered. Sry!

I've never played with the timetable, I do not know why it needs separation, I do not even know what your code do or tries to do.

[Gathers]

Glad to hear you like the changes!

Whether new players would think it separated fast enough or not I can't say. But there will always be a compromise between trains blocking stations for long times and trains separating slowly. I don't think there is any way to fully avoid both.. There are certainly still opportunities for improvements though.

If you keep trying new versions of the patch and report regressions or bugs that'd be very helpful. I might break things and not notice because I was only testing it in other ways. If you'd like I could point to parts in the code you could try changing to tune the behaviour. Perhaps I should make a special testing-version with as many settings as possible so others could help find good default values?

I'd like it if this was included in trunk someday, but I think before that could be considered there is still a lot to do. There are some bugs with stopped vehicles, and buses can get stuck together because the one behind thinks it should be ahead but can't overtake. Things like skipping orders etc should be handed as gracefully as possible, and I have to review the separation logic and decide if I want to rewrite it or not. After looking into the ITiM patch to see if I could lift something from there..

I don't know if any developer is too interested in automatic separation, but I hope if I could make it bug-free and not too intrusive that it'd be considered.

[rbn2903]

There are some bugs with stopped vehicles

Any possibility to trigger those bugs?

Things like skipping orders [...]

Actually I never use conditional orders. How they are supposed to work is beyond my unterstanding. I seem to not be able to make a train load until 60% and then leave for example. I just don't get, how this is supposed to work.

You probably also noticed that I don't play with breakdowns. This savegame represents my usual settings. But I'll give it a try with breakdowns and see how this patch performs under worse circumstances I also wanna try if it reacts correctly if a plane crashes and you don't replaces (It's sad, you can't turn off plane crashes/desasters)

fter looking into the ITiM patch to see if I could lift something from there

I liked ITiM, but i guess it was to much at once. Maybe all those features it had have to be reviewed if this patch hits trunk. So the groundwork is layed!

I don't know if any developer is too interested in automatic separation, but I hope if I could make it bug-free and not too intrusive that it'd be considered.

Yeah, that's very important. Buts I'm sure it's not gonna happen before the release of OpenTTD 1.0.

[Gathers]

There are some bugs with stopped vehicles

Any possibility to trigger those bugs?

Sorry, I should have said "stopped vehicles in depots". It used to be that if you made 4 vehicles, automated all and only sent one out it'd get later and later. Though that bug may have been fixed with recent changes.. Anyway, the amount of vehicles is still used in some places, where the amount of running vehicles should be used instead. I think separation is slower than it should be when there are many stopped automated vehicles for example.

Actually I never use conditional orders. [...] You probably also noticed that I don't play with breakdowns. This savegame represents my usual settings. But I'll give it a try with breakdowns and see how this patch performs under worse circumstances I also wanna try if it reacts correctly if a plane crashes and you don't replaces (It's sad, you can't turn off plane crashes/desasters)

Please do. I haven't tested with breakdowns or different kinds of orders yet, and since I haven't tested it, I assume it's broken. But perhaps with breakdowns it can still keep some kind of separation on longer lines.

After looking into the ITiM patch to see if I could lift something from there

I liked ITiM, but i guess it was to much at once. Maybe all those features it had have to be reviewed if this patch hits trunk. So the groundwork is layed!

The problem is it's old, things have changed and parts of it has already been moved into trunk.

I don't know if any developer is too interested in automatic separation, but I hope if I could make it bug-free and not too intrusive that it'd be considered.

Yeah, that's very important. Buts I'm sure it's not gonna happen before the release of OpenTTD 1.0.

Yes, I really hope it doesn't as that would mean a very delayed 1.0!

[rbn2903]

Ok, for a savegame with breakdowns see attachment. The patch has trouble because the breakdowns happen very often. I don't how people are able to play with this. But the patch fights for a good separation

Regarding stopped vehicles: Interestingly there seem to be problems if you start vehicle 3 out of 4. it gets very very late (how can that be with only one vehicle), and later and later , but on the other hand, if you start vehicle one it works tolerably. This leads me to the question how the functions/properties/parameters "v->FirstShared()", "v->PreviousShared()" and "v->NextShared()" work? Do they return any vehicle? Or only Vehicles that are NOT stopped right now? The latter case could cause the problem. But I'm sry, I wouldn't know how to bypass this problem. As I said I' having enough troubles unterstanding the C++-Code

Edit: Once you start a second vehicle (ANY second vehicle) the problems are gone!

[Gathers]

Hehe, at least it seems to put up a good fight without giving up or exploding despite all the breakdowns.

v->NextShared() etc all refer to the shared orders chain, which is a list of vehicles sharing the same orders. So it has to contain every vehicle, running or not. The sorting of this chain is used to keep track of the "positions" of the vehicles on track.

This is something from the original patch that I'm considering rewriting. If a separate chain was used to handle the separation instead, that might allow for simpler code.

[rbn2903]

I just discovered something I must have ovrread

Perhaps I should make a special testing-version with as many settings as possible so others could help find good default values?

Actually this would be great. This way one doesn't have to recompile again an again And maybe petert (I'm pretty sure, he does want to, since months now he didn't loose the energy to help people in this forum ) could upload a MSVC-Build with a pdb-file, so if it crashes you'd be able to debug it

[boekabart]

Updated the patch to HEAD (r18956), and made an svn diff (not a patch diff) which is easier to apply to an svn checkout.
Savegame version bumped to 138+1 = 139.

[el koeno]

Gathers: Great patch. I've been waiting for a separation feature compatible with cargodist for a while now.

However, I've been having some gameplay issues (no real bugs). After a jam somewhere (happens often because I tend to make a mess of things), it seems trains wait a long time at stations . This makes sense: jams lead to less separation (pile ups), and trains wait to correct for it. However, by doing so, they often jam up the stations they're in, leading to yet another jam! Would it be possible to set a maximum extra waiting time? Players that want quick separation will set this to a high value, and players that are more concerned with the flow through crowded stations set it to a low value. This could be done by a console setting, or somewhere in the advanced settings. Ideally you'd be able to set this for each station separately, but that would require modification of the station window, which would be more work I suppose...

Anyway: keep up the good work, and let's hope this makes trunk!