Train Navigation Trouble

[iowa_jim]

I have this moster-sized route that emphasizes material movement. I like to set the trains to navigate through their route, but too often the trains make unexpected choices, like taking a siding that turns them around rather than stay on the main line. I know I can use route markers that will force the trains to follow the expected path,but this will be tedious and I'd like to avoid it, if there are other ways. So how do we keep our trains on track?

I have some success by making a siding a little further away from the mainline, but this isn't 100% effective.

Thanks for the help!

Jim

 

[Dermmy]

In general AI drivers will take the shortest available route so if your siding is say inside a curve it will be shorter than the main, so whenever possible the AI is going to take the industrial trackage. To avoid this you can use trackmarks on the main and tell 'main line' drivers to 'navigate via' or you could set main line trains to a high priority and use priority markers on sidings to keep main line AI trains out or even a direction marker set against entry will keep AI trains off the siding but let the player train pass unhindered...

 

[ctclark1]

The Trainz Artificial "Un"intelligence of the drivers has come up multiple times just since I've joined and I've seen countless other threads before that. Things to note:

• What Dermmy said is correct - it will attempt to use shortest route possible (taking into account direction markers against it and track priorities to an extent).
• Track and train priorities aren't as cut and dry as they would seem - a train with a priority of 1 does not take precedence over a train with priority 3, it is used in determining which tracks the train will prefer to take (but it will override if it sees no other options). P1 trains will prefer to take P1 tracks but will not hesitate to take specifically marked P2 and P3 tracks if it feels it necessary. (Tracks default to P2 without a priority marker)
• AI drivers think for themselves and themselves only. A 25mph slow freight is not concerned about the express passenger train being stuck behind it. It will not pull off into a siding just to let the express pass, and even if it does go into a siding due to a matching track priority, chances are depending on the length of the siding the slow freight will still have the far junction locked in its direction before the express can lock it, still preventing it from getting by.
• Along those same lines, trains will do what they have to in order to get a green signal. Lets say you have a large Y siding alongside the main with two trains in succession coming down the main (the second train "chasing yellows", as it were). If the second train can get a green signal by switching into that siding it will take it without thinking twice, even if by the time it does so the first train is well clear of the area, and then voila your second train is running backwards. (See next bullet)
• Unlike the real world, trains have no qualms or concerns with driving backwards at 50mph, if that's what they think they have to do to get to their destination, they'll do it. (See previous comment)
• One of the WORST behaviors I've seen is the actions the drivers take after a SPAD incident (Signal Passed At Danger). The wait ten seconds, then continue driving as if nothing happened. 90% of the time I'd had this happen on my routes, the following train suddenly ends up COUPLED to the train it was following because the leading train hadn't cleared the block yet (and there was no subsequent red signal to stop the following train before it got to the train in front). The following train WILL lose its orders when this happens and will faithfully remain connected to the leading train wherever it goes until you realize this has happened and uncoupled it.
• A method of using track markers as "drive via" commands is not foolproof either. At times trains will give up the "shortest route" through the scheduled trackmark. The don't care how they get to those trackmarks as long as they get to them. If a driver decides on an alternate route past the trackmark then it will get to a point where it can get to that trackmark from a different direction and back all the way down to that trackmark and then continue on its way.

As you can see there are a number of issues with the AI. Some will recommend using "drive TO" trackmarks and "Wait for triggers" for trains to go by if they want a train to wait for another one, but this is best used on routes where things are very carefully times out and structured. For the average user running a bunch of automatic trains with commodities from source to destination (all getting there in their own time, not on a true schedule) this is problematic since you leave open the opportunity for a train to be stuck waiting for a trigger that will never happen (the train it is waiting for has already passed ahead of it, for example).

It has been said before and I maintain that one of the biggest downfalls of Trainz is the AI system, but there's not much we can do about it besides work around, either by a ton of trackmarks and triggers, or by never running a train ourselves and instead constantly playing dispatcher (basically telling each train to only ever drive one trackmark at a time.)

That's my observation. More veteran users may have other thoughts?

 

[Kennilworth]

Hi

The method that I use to get the AI to work consistently is to use path setting rules with their associated driver commands. Once the path is set up the driver will follow it exactly as they no longer have to plan their route themselves. Unfortunately for the OP this method involves a lot more work than setting up direction markers but it can be applied to any route. I have it set up on the ECML route which has in excess of 5000 junctions and trains will run from London King's Cross to Newcastle (approx 260 miles) following their exact route every time. While I tend to use path setting all the time it can be used just for areas that cause problems for the AI and in that case it wouldn't take as long to set it up.

The disadvantage to all this is the amount of time required to set it up, as each signal throughout every path has to have a unique name for the path setting rule to work correctly but I have found it well worth doing to take all the uncertainty out of what the AI does. I have found that the easiest way to employ this is to just program the paths that you need as you need them. The rules and commands that I use are the ones made by brummfondel and it does take some time to learn how to use them correctly but there is some guidance on his website http://www.js-home.org/trainz/ for anyone interested in them.

In real life the train has its path set for it by someone else and the driver just drives the route that has been allocated to him, so path setting replicates this in Trainz. When you consider the number of different combinations of paths possible on a route the size of the ECML the AI doesn't do too bad a job but it isn't surprising that it may need a bit of help from time to time.

Regards

Brian

 

[ctclark1]

Does the PATH command still work? I had it in 2006 at one time and was able to set it up to get it roughly working correctly, but I was never able to get it to operate in 2010, I don't remember offhand what the error was but I believe I could never get it to install properly in CMP, even with compatibility. Maybe I didn't try hard enough? (And can't try right now, I'm in the process of waiting on an SSD to replace my failing system drive on the desktop where Trainz runs, but will be able to try again in a week or so.)

 

[Kennilworth]

Hi again

The path rules and commands by brummfondel work fine in TS12 and, if I recall correctly, in TS2010. I don't use the one by _mutton_ so I can't comment on that.

Regards

Brian

 

[ctclark1]

Ah, thank you, I was only aware of the mutton ones. When I get my desktop back up and running (probably over the weekend) I'll see if I can find the brummfondel ones you mention and try them out.