[Patch] ATC speed control

[urdh]

Ever been annoyed by fast trains stopping and starting when trapped behind a slow freight train? With this patch, you can emulate a certain behaviour of the ATC system heavily utilized in Scandinavia: Trains trapped behind a slower train (up to one signal block or 20 tiles away) will automatically slow down to match the speed of the slower train. This eliminates the stopping-and-starting, making the train move a lot smoother. AFAIK it has no real impact on game mechanics.

Patch applies to r21666, there are no major bugs that I know of.

[Dwight_K._Schrute]

Wow it sounded great and my first test pointed out that it seems to be so...

I compiled a Windows version for other possible testers:

OpenTTD_ATC_r21666.rar

Windows Binary

(3.68 MiB) Downloaded 805 times

[Arie-]

Only thing I can say is: if it's as good as I hope it is, PLEASE INCLUDE IT IN 1.1 . Gonna test it now.

[Comm Cody]

Using Dwight's Binary, there is a clash with one setting

Go under Trains in advanced settings. Go to sparks/steam/smoke effect. Set it to the left all the way.

Picture is here for your benefit.

[urdh]

Seems like an issue with english.txt, should be fixed.

As for the patch being included in 1.1.0, I'll get a task up in flyspray tomorrow if there aren't any horrible bugs. After that, it's up to the devs

[Arie-]

I managed to trigger strange behaviour, see attached screen shot. A split track, one is empty, one is occupied with a slow train. The follow up train, a fast one, slows down, speeds up, slows down, speeds up, etc.

[Lord Aro]

One thing i can say is that you will probably have to get rid of all references to 'ATC' as many people (including me) will not know what that means...

[planetmaker]

It's a nice idea.

A few remarks and thoughts, though:
- you totally break savegame compatibiliy. In settings.h you remove existing lines without comment, necessity and on the penalty of breaking the loading of old savegames. Nor do you bump the savegame version when introducing your new setting which alone also needs this savegame bump. Thus it needs taking care also in the saveload code.
- it doesn't fulfill its purpose flawlessly. Trains also slow down if they pass a slow train on a two-track arrangement or "see" a train in a depot (see screenshot and let two trains run on a similar thing). As this flaws became obvious after looking at a new game in 5 minutes I expect many other cases to fail or suffer from similar bugs.
- As a result of the above point, my guess is that you'll have to integrate this into the path finder - and worse - have a train know about the paths of other trains. The performance impact of this will need assessment.
- Especially in settings.h but also elsewhere you should watch the coding style. Indentation is done by tabs, avoid trailing and leading white space.

[urdh]

I managed to trigger strange behaviour, see attached screen shot. A split track, one is empty, one is occupied with a slow train. The follow up train, a fast one, slows down, speeds up, slows down, speeds up, etc.

Hm, I can't seem to reproduce this. Under certain conditions, however, acceleration may cause the train to break too much, increasing the number of signal blocks between the trains, causing it to accelerate and so forth, making it oscillate between two different values. It could also be that the train leaves the 20-tile "search radius".

It may also behave strangely when two trains are heading for a head-on collision. I may include a check for this.

At stations, it may appear to be behaving strangely, since it'll slow down oncoming trains to arrival speed (24km/h). I'm not sure how to fix it though, I could add a check for station tiles, or I could increase the lower speed limit for which the rule is applied. I'm not a big fan of magic numbers, so the first option is probably the way to go.

A few remarks and thoughts, though:
- you totally break savegame compatibiliy. In settings.h you remove existing lines without comment, necessity and on the penalty of breaking the loading of old savegames. Nor do you bump the savegame version when introducing your new setting which alone also needs this savegame bump. Thus it needs taking care also in the saveload code.
- it doesn't fulfill its purpose flawlessly. Trains also slow down if they pass a slow train on a two-track arrangement or "see" a train in a depot (see screenshot and let two trains run on a similar thing). As this flaws became obvious after looking at a new game in 5 minutes I expect many other cases to fail or suffer from similar bugs.
- As a result of the above point, my guess is that you'll have to integrate this into the path finder - and worse - have a train know about the paths of other trains. The performance impact of this will need assessment.
- Especially in settings.h but also elsewhere you should watch the coding style. Indentation is done by tabs, avoid trailing and leading white space.

Thanks, I'll have a look at these things.

Edit: I've looked over the code, bumped the savegame version and fixed most (all?) style issues. The problem concerning stations should also be fixed (a train is no longer considered if it is braking), as should the dual-track issue (search stops when a switch is encountered, this is an ugly solution but it's the best I can do without meddling with the pathfinder... I think). Obviously this needs more testing, and I appreciate any input I receive.

[urdh]

I've fixed it up further, so that the algorithm now makes a more conscious choice when it encounters switches. It tries to follow its reserved path, which should improve things in certain conditions. If there isn't a reserved path, searching stops at the switch. Trains are also ignored if they travel in the opposite direction.

Still not perfect, but this should take care of most issues. I'd like it to check all possible paths so that instead of simply not limiting speed when switches are encountered, it tries to actually follow all tracks and limit the speed anyway if they're occupied. I fear that may be too computationally expensive though, even if it could be done without meddling with the pathfinder (through a recursive search with a limited depth).

[Fesken]

This project dead? I NEED this patch

[planetmaker]

This project dead? I NEED this patch

I suggest you get better working on it then

[Vaulter]

Updated to trunk

[Fesken]

Updated to trunk

WOW nice! Thank you!

[DoppyNL]

What is the current status of this patch?
Is it working properly (in most cases)? Are there still bugs?

[FooBar]

The status is the same as that of 31 Dec 2010, 16:00.

[DoppyNL]

Are there any plans on putting this in openttd? or will this remain a patch here on the forum forever?
This could be *very* useful.

[FooBar]

With a status of "still not perfect", chances that this will be put into OpenTTD are close to zero.
That doesn't mean it's a bad idea. It just means that the implementation doesn't meet the standards yet.

[DoppyNL]

What are the current problems that still need to be fixed?
The thread isn't entirely clear on that.

[Alberth]

With the author having left 1.5 years ago, probably nobody knows, so why not try it yourself and find out?