Help. I need a fix to stop trains backing out on "Drive To ..." AI/Driver commands.

K3JohnHO

Member
Now that 'Drive To', 'Drive to Trackmark' and 'Drive via Trackmark" commands no longer function as per Command Description at,


Quote: "The AI driver will NOT attempt to find a way around blockages when calculating the shortest path to the trackmark."


Does anyone know how to prevent 2nd, 3rd etc. queued trains, (each behind a red Signal), from backing out and attempting find an alternate path?


Note: Entered a bug report but the answer back from support contradicts the command description.

Supports Response: "Since 122411, AI trains had improved and more aggressive pathfinding as part of the preparation for TLR.

As such, if the path they were currently taking were to be suddenly blocked, they will seek alternative routes.

They will still follow any track markers/track direction commands but will back up if they can find an alternative unblocked path.

The best way to resolve this, is with use of track directional markers and track markers."


We all know how well 'Directional Markers' work (or don't).


Thanks
K3JohnHO
 
What version are you running?

TRS22/Plus build 126280 solves that problem pretty well. Since that update, I've had no issues with that.
 
You might find the direction markers useful to prevent (sometimes!) a train from reversing. You could also add an additional Trackmark just ahead of any problem intersections, and direct the trains to go "Via (the new Trackmark". i.e. it would serve no purpose for the train to reverse. Regards. Colin.
 
I had that problem a while back, the cause was simple, there was a track section that was not connected to the existing path. Also, the use of signals and track marks, visible/invisible will help. I use visible track marks.

TRS22/Plus build 126280
John
 
Check your driver commands are correct for the route. Hint, hint. I found this out the hard way after chasing a problem where the AI drivers on a particular route kept backing up.

I checked the commands and they appeared correct, I checked the track marks and they appeared correct.

I deleted and added drivers, and I did it again, deleted the commands and added them again and again, and then ...

I noticed I sent the AI drivers to the wrong platform of a passenger station!

Well, no wonder they were backing up. They were sent to track mark down one track, then backed up to get to the station platform on the other.

This was not easy to spot believe me, and I felt bad afterwards for firing a bunch of drivers over nothing. ;-)
 
Check your driver commands are correct for the route. Hint, hint. I found this out the hard way after chasing a problem where the AI drivers on a particular route kept backing up.

I checked the commands and they appeared correct, I checked the track marks and they appeared correct.

I deleted and added drivers, and I did it again, deleted the commands and added them again and again, and then ...

I noticed I sent the AI drivers to the wrong platform of a passenger station!

Well, no wonder they were backing up. They were sent to track mark down one track, then backed up to get to the station platform on the other.

This was not easy to spot believe me, and I felt bad afterwards for firing a bunch of drivers over nothing. ;-)
Oh that sounds so familiar! I guess we've all done it at some point in time! :) Regards. Colin.
 
Thanks for the comments.

I have been a 'Trainz MODEL Railroad' member since version 1.3, (before the great community database fiasco, the disappearing sound in 2006 and the 'Coupler breakage' and the 'Southern China derail' bug in TRS12 etc. etc.

I find it interesting that no one commented on the action of backing out contradicts the command description. Also, most inferred it is my 'problem' not N3V. Do we all assume N3V software is perfect? Every patch fixes 'numerous bugs' according to N3V.

This was a 'Tongue in Cheek' request as I already use combinations of 'Trigger Multiple Signals' on invisible signals in reverse direction, 'Track Direction Markers' and 'Force Signal On' rules to at least prevent Driver/AIs backing out of 'loops' on dual trackage.

Note:
1. If you use 'Force Signal On', it will often lock signals on Red when it is deleted, (not checked in 126280). Check signals both sides because rotating the marker after placement can lock signals either side when deleted.
2. For 'Trigger Multiple Signals' rule, I use a Trigger named, 'T Signal Locker', under a dining car on a disconnected piece of track. (Lunch bar at a station :).
3. There appears to be two Direction Markers in DLS, with status of 'Base', an 'AI Routing DM' and a 'Track DM'. I am using 'Track DM' from the 'Track 'F4'" menu, so my comment that they 'may not work' might be 'kuid' specific.

Talking 'Location Markers', here's a tip, check your 'Client Log'. I found 'Location Markers' using only a hyphen between words as in 'Location-Marker'
instead of 'Location - Marker' in a Driver/AI command string can show up as a 'Miss-Matched Tile' warning. A preceding '#' when using 'Token Management rule/2' assets can cause the same warning. Delete them and rename them and yes, you will have to modify all your Driver/AI command strings appropriately.
Using a lower case first letter junction name in an 'Enhanced Interlocking Tower' section can also show up with this warning.

P.S. Just watched a train back 2 Kms. in 126280 (eventually stopped at a combination of a 'Track Direction Marker' and an invisible signal set by the 'Trigger Multiple Signal' rule). Duplicated this action twice with both a manually stopped AI train and a signal locked on Red by 'Trigger Multiple Signals'. At least in 126280 unlike the previous version, it does not leave the train in a pseudo 'Autopilot' mode where it cannot be restarted in Driver/AI mode, (so far).

I raised the "pseudo 'Autopilot'" as a bug report in the previous version, (1 of 7 Reports). Maybe I helped in getting it fixed? ;).


Thanks all
K3JohnHO
 
Back
Top