How Does AI Work?

boleyd

Well-known member
There are probably hundreds of messages explaining various things about AI train operation - computer controlled trains. What is not provided in one place are the rules under which AI operates. As an example I was following some threads and was led back to the year 2006. There was a statement that on some unknown amount of track, not signaled and no speed signs, a train will only run at half of its maximum speed. There must be many similar "rules" embedded in the AI code but they are only exposed when someone discovers them. Then the information is lost among the mass of messages on the forums.

There seems to be two obvious reasons for signals in the AI world. One is to present a real-world (prototypical) Trainz railroad and the other to manage AI trains. There may be others but these are good examples. Without the "rule book" it is difficult to manage either. There are several tutorials on how to create real-world signals but only dispersed information on how to manage AI with signals and speed signs.
 
It seems to work, and is rather easy ... What exactly do you want to know ?

All I want to know is why AI hunts and pecks along a complex line of turnouts, and a long length of track, in a 20mph speedboard zone, and does 20, then 10, then 15, then 9, then 18, then 12 mph ... etc

How do you stop sporadic the pecking along like confused pigeons ?

I said to AI ... AI, I want AI to do 20mph (AI responded: Are you sure, that you are sure, that you surely certain that you want me to do 20mph Dave ?)

Open the pod bay doors HAL ... I'm sorry Dave, I can't do that Dave.
 
Last edited:
Catch 22 going back to the days of MSTS.

FAQ: How do I set up AI traffic in an activity?
A: It depends on how the signals are set up in the route.
FAQ: Okay wise guy, so how do I set up signals in a route?
A: It depends on how you intend to set up the AI traffic in the activities.

Here's your bible;

http://trains.0catch.com/tutorial.html

Note that most of that covers tracklaying and signaling and AI routing markers, see catch 22 for the reason why - to force the AI to do anything except skid around like an unguided missile, the track has to be set up to guide it where you want it to go.

Multitudes of track markers are often required, some routes I have as many as 40 "drive to" instructions along with wait for X seconds (5 or 10 is all that's needed if you just want him to come to a full stop before proceeding) which is long and tedious. To avoid doing it more than once I use a schedule library, with segments of the paths which I can combine to make longer paths, then each AI train I set up I merely have to issue "copy commands from" instructions in sequence for the path I want it to follow.

Best way to learn is by doing, place track markers along a path, set up a schedule library, watch what the AI does. In some cases I have Eastbound 01, Eastbound 02, Eastbound 03, Eastbound 04, Eastbound 05, Eastbound 06, etc. The AI follows the route just fine until one going westbound leaves a switch thrown the wrong way, then the idiot eastbound can't find the path to Eastbound 04 from Eastbound 03 because he can't figure out the pattern of switches. Rather than renumbering all the trackmarks after Eastbound 03, I just place an additional one and name it "Eastbound 03 TWS" (This Way, Stupid) then add the new one as an additional intermediate waypoint between Eastbound 03 and Eastbound 04.

Whatever you do the best laid plans of mice and men gang aft aglee, so plan on doing extensive testing and debugging.
 
My apologies, I'm bouncing all over the place with this, but some things I've learned about AI:
If you want to control every aspect of running trains, it does not replace the "Dispatcher" role in and of itself, this is where your driver commands come in. Clear, concise instructions of where to go and when - much as if you were issuing Track Warrants or Form D's (real railroading, I'm not going to go into that detail, Google is your friend if you must know). Account for every "control point" (or "interlocking") on the route of which track to take, etc. If you want to setup a meet for the train to take a siding, you might be better off having Triggers and having that train "wait for" the other train to hit a trigger before continuing, but keep in mind if the other train hits the trigger before the first train is actually at that step in the command list, it'll wait there forever.

That being said, if you just want to set, forget, and watch trainz zip all over without caring about what they actually do (or in some cases, sit back and watch the world burn), give them all simple "Drive to" or "navigate to" commands for the far end of the route and watch them all interact. It's actually kinda funny sometimes but certainly not "real world".

Other things to keep in mind - Drivers will think for only themselves and attempt to get from point A to point B in the shortest/fastest way (depending on whether you're using Drive or Navigate). Priorities of trainz mean nothing as far as who goes first, it's simply an attempt (and I mean attempt, not foolproof) to get trains to use certain tracks, where you can use different limits to try to get them to let the other go first, but again, not foolproof. If you have a priority 1 and Priority 3 train approaching the same converging switch and the P3 train happens to lock it first, too bad, he's screwed over your passenger express. This is why I say the "Dispatcher" role you play is important to get it setup right, if you want the real world experience. A lot of work goes into setting this up to resemble a real operation before you can ever jump in the driver seat of your own train and interact with them, and even then they'll typically find some way to screw it up.

The commands are parsed one at a time. There's no "looking ahead" like a real engineer might do. This can work to your advantage for real-world ops or disadvantage for seriously un-real-world actions. For example, say you have a local freight running the branch line, stopping at every industry spur. If you just tell it to drive to the industry, it will set the switch as soon as it can (i think there's some distance limitation but don't remember) and drive right into the spur at track speed until it hits the limit for the spur. Very unreal, especially if it's a hand-thrown switch. If you tell it to drive to a trackmark just prior to the switch, wait 10 seconds, then drive to the industry it will stop at the trackmark (make sure it's far enough away), wait, set the switch, then drive in (as if the conductor got out and threw the switch himself). Conversely, though, you don't always want that happening at a junction on a main line that would be controlled from a tower or the CTC dispatcher, so you need to figure out, with signalling and such, how far in advance you want the switches to be aligned, keeping in mind that this could cause other trains excessive waits if the whole thing isn't timed right. Or if it's too late the driver will have to approach the junction at a reduced speed because the points aren't aligned for a route and he needs to obey the approach signals before the junction can be switched.

Cornfield meets were another big one when setting up real-world signals on a single track, but I think this has been improved with newer signal libraries, both built in and in particular third-party stuff on DLS (NS37/JointedRail has a decent library that helps prevent this, as does RRS I think) but at one time the signals would only look one block ahead and you could have two trains pass sidings at opposite ends and get stuck a block away from each other, both refusing to move, because they had clears or approach signals leading into the single track, but then encountered dangers a block away from each other. This is the reason why you'll find tutorials, particularly the one above, that state it's much easier just to setup two-track one-way running from the start, but if you're simulating real world this isn't right, nor is the idea of not putting signals mid-way on a single track. This is also another reason why proper timing and command setup is crucial. If you only have one or two other trains to interact with at a time, this is fine (portal-to-portal, one or two at a time), but if you're trying to setup a real-life busy yard or something, it becomes a painstaking process of trial and error. I have yet to release any routes/sessions, but I've always had the feeling that if I were to, there'd be about 3 months of just setting up AI, running the scenario, adjusting, running again, adjusting, running... All to make sure things went relatively smoothly for other players to have fun.

AALLLLLLLLLLL that being said, from my understanding, the Trainz AI is still a cakewalk compared to setting up non-player trains in MSTS and RW/TS, but I've never tried in either of those so I could be misunderstanding previous comments. (Basically it isn't AI, from what i remember reading... it's all hand written)


Edit: Another plan I've had for a future session I may release, is that if you want to setup a good real session where AI trainz interact properly and on a schedule, setup one train at a time, have it run it's planned route with stops and such, and sit there with a stopwatch and a piece of paper (or a google spreadsheet works too) - Time it out, see how long without other trains it takes to get to each point, perform tasks, etc. Do this for each train separate from the others, then work it out into an actual timetable. After you get everything together, you'll probably have to adjust the timetable (and I doubt the AI will run it the same way twice without extremely precise commands), but it'll give you a good place to work from. Then if you want to get really daring, throw an "extra" into the mix and see what happens, either with another AI, or with you as the driver of the extra. Pay attention to where you'll have to wait for other trains, see if they suddenly take an unusual route...
 
Last edited:
Paragraph 4 sums up the procedure nicely - "The commands are parsed one at a time." Knowing that makes it easier to make them do what you want them to do. Single track sections with 2 way traffic, for example - trackmark just before the single track, then another after, with a double head signal before entering the single track section then a single head or dwarf beyond it, no signals on the single track section at all. That "interlocks" it since the doublehead on the approach track will stay red until both the entrance and exit switches are set for the correct route. Drive to trackmark 08 (just short of the double head signal at the trailing point switch), wait for 10 seconds, drive via trackmark 09 (beyond the facing point going back to double track on the far side) and so on. That wait for 10 seconds command brings the AI to a full stop at a red signal, and he won't start flipping switches until the wait time is finished and he loads the next instruction to "drive via trackmark 09". That wait is the most useful tool for preventing standoffs simply because he won't try to take control of the next set of switches when he's 2 miles away.

I'm currently playing with an expanded American Flyer route, with two extra portal sets added to the 3 in the DLS version. So the coal drag spawns at 40 minute intervals, two portals at each end spawn every 20 minutes, with each portal spawning one of three or four AI trains at random. Since each random AI has a different route to the destination portal (one takes the long way around, one takes a shortcut through an industrial district, one takes a different route over the hills) there's no predictability to the traffic at all.

This is possible with a lot of work, but it's ONLY possible in Trainz - MSTS AI is too simply programmed for complicated traffic patterns, railworks is completely hopeless even for simple patterns.
 
I was wanting some more basic info such as how far apart should signals be to act properly? At what distance does the signal detect a train? How does a 2 head signal determine which track gets the top head? There may be other "sensitivity ranges" plus other logical decisions made by TANE when controlling AI trains. Most info I have seen show how to "fiddle" things to get them to work but little on why certain "discoveries" worked. These AI coded internal rules can be selected and values added to get things to work but how much customer time is wasted just trying combinations looking for success. Anecdotal info only addresses a small segment of the Logic Coded Into the AI world.

I really do not expect TANE/N3V to ever produce a detailed list of why a train slows for no reason, or why a train sits at a signal when the CPU is almost idle. All that logic has grown through many hands and years and we will need to continue to have to rely on the excellent descriptions above this message. Unfortunately, these messages will be lost to time and buried beneath many other messages along with the discoveries of people who devoted lots of time to get things to work. The why factor will thus remain a mystery.
 
"These AI coded internal rules can be selected and values added to get things to work"

I don't think anyone has done that, mainly you just work with how it's coded rather than hacking the AI logic. For example the AI will run at close to whatever the track speed is after passing a green signal unless it's approaching a yellow, approaching a slower speed limit sign, approaching a switch set the wrong way, etc. How far away does it slow to half track speed I dunno, never studied it, and the answer is probably different in TS12 because of the different locking the switches programming. TANE dunno either, never saw it, probably has the same programming as TS12 with the switches locking further away than the default radius depending on speed of approach.

The only programming I know of that can be adjusted is the engine spec, since AI trains use DCC control the acceleration and deceleration values in the DCC motor control section can be adjusted to alter how fast they speed up or slow down.

How far apart should signals be - another of those "that depends". Where I grew up the C&NW ran alongside the Lake Street elevated route, block signals on the NorthWestern were about a mile apart, on the L they were about 1/8th of a mile apart. Difference between rapid transit EMU trains 8 cars or less and mixed passenger / commuter / freight traffic governs how far apart block signals are. Same when you're making your own route - 50 meters or so is the minimum distance to avoid that "overlap" message, other than that what do you intend to run on it? Max speed 30mph or 200 mph? 50 car freight trains mixed with 6 car express passenger trains? Same for how long should a passing siding be, it depends on the longest train length you intend to run on the route.

The "why" factor is a mystery to me but it's irrelevant - as long as I know that an AI train won't take control of the next switch ahead when I use a drive to trackmark followed by a wait for X seconds instruction, I don't need to know why it works that way, I just set it up to do what I want it to do. If I want it to grab control of the next set of switches a mile away without slowing down I use drive via trackmark, if I want it to allow potential opposing traffic arriving sooner to have the right of way I make it stop short of the switch with a drive to trackmark - wait for 5 seconds sequence.

I would suggest some reverse engineering;

Chicago Metro 3,<kuid:522774:100015>

Chicago Metro 3 sparks 10,<kuid:522774:100012>
chimet 3 40th 3020,<kuid:522774:100014>

Play with those two sessions, instead of driving your own train click the F6 window to select one of the AI drivers and ride along. Study the instructions in the window and watch how the AI executes those instructions. Edit the route and study the signals and trackmarks, edit the sessions and the session rules, study how the schedule libraries and stuff like trigger multiple signals are set up. If nothing else it will give you SOME understanding of how to do it, although I would start with that ocatch tutorial before attempting to create my own.
 
The signal logic is based on what country the signals come from. For US-type signals, N3V originally Auran uses the NORAC rules guidelines for their signaling systems. The 2-headed approach signal determines which track is active and at what speed the AI will travel. If the signal is yellow on top and red on the bottom, this tells the AI to stay to the left and travel at medium speed, which is 1/2 the mainline designated speed. If it's red on top and green below, then the AI will be staying at full speed as it takes the right hand track. This is basic logic which is built in to the program in order for the AI to follow basic signaling and driving rules, and without it we'd have AI moving worse than they do already!

The distance between signals is determined as, Jim says, by the designated running speed of the main, plus the max length of the trains along with the number of trains on the track. If you are running mile long freights, then you'll need signals spaced at least a mile apart from each other. In Trainz the maximum distance between signals is about 12 miles or roughly 19 km which I think was mentioned by NS37 awhile ago.

The locking of junctions does take place if you don't put in between signals in between the junctions. I get around this by using permissive signals, those with the small signs under the signal heads, because the AI look signal to signal with junctions as terminators of the sections from what I remember. These permissive signals, placed the equivalent of 1/2 the distance in the largest block, section will actually allow more than a single train in a given block because the AI will see the signal and adjust speed appropriately.

John
 
As Sniper297 said
The "why" factor is a mystery to me but it's irrelevant
I agree. As long as it works, the why is of academic interest.

JCitron
The signal logic is based on what country the signals come from
Didn't know that. Is that based on the region we select when making a route? Change the region and the rules change? I always use Dutch type signals: absolute, permissive, diverging left, diverging right. With only those four I find I can control all the traffic on my routes. Then some maximum speed signs to control how fast or slow they move. If I put a slower speed at the entrance to a spur line, then the mainline speed is not affected but a train taking the diverging switch starts to slow down before going through the switch which looks pretty good. Whether it is totally prototypical, probably not in all cases but it works.
 
As Sniper297 said

I agree. As long as it works, the why is of academic interest.

JCitron

Didn't know that. Is that based on the region we select when making a route? Change the region and the rules change? I always use Dutch type signals: absolute, permissive, diverging left, diverging right. With only those four I find I can control all the traffic on my routes. Then some maximum speed signs to control how fast or slow they move. If I put a slower speed at the entrance to a spur line, then the mainline speed is not affected but a train taking the diverging switch starts to slow down before going through the switch which looks pretty good. Whether it is totally prototypical, probably not in all cases but it works.

It's more of the country of origin of the signals. US-type signals, and Canadian unfortunately, will use NORAC by default using the built-in scripting. GrahamSea made CROR-type signals which look like US signals, but operate to the Canadian Rules.

What you are doing, Martin makes sense. If it works for the AI then we should do that because sometimes no matter how we try to be 100% prototypical with the AI logic, it doesn't work.

John
 
What I use;

Signal USA 2 L02,<kuid:-12:22962>
Signal USA 2 02,<kuid:-12:22902>
Signal USA 2 04,<kuid:-12:303>

From what I've read 1 3 and 5 from that set are permissive, although I don't see any script indicating that. So 04 for single head block signals, 02 for a right diverge, L02 for a left diverge. Theoretically if the through route is to the right and the diverge is to the left you use the L02, through route left diverge right use the 02. Set up that way in simple junctions it should show green over red for the through route, red over green for the diverge. Except when it doesn't, some track configurations - double slip switches and double crossovers for example - either signal will display red over green regardless which way the switches are set. For simple track configurations they indicate correctly, but even when they show the wrong aspect they work fine to control the AI.

12473849_1048931628484450_3024847815227078650_o.jpg


This is the simplest setup, eastbound and westbound on the right hand double tracks. The EB 4 and WB 4 trackmarks are 20 meters or more before the switch so the AI is not in the lock radius, the double heads are always L02 for US railroad right hand running (you want them to always take the right hand track, it would be the opposite for the UK) and there are no intervening signals on the single track section. The eastbound has drive to trackmark EB 4, wait for 5 seconds (10, 20, 30, whatever don't matter as long as it makes them come to a full stop) then drive via EB 5. The effect that has is to make him stop short of the signal, wait for 5 seconds, then flip both switches to set the path to EB 5 - unless both switches are set for that path, signal L02 will remain red over red. Same thing from the opposite direction, fairly simple way to set up short single track sections with two way traffic.
 
Catch 22 going back to the days of MSTS.

FAQ: How do I set up AI traffic in an activity?
A: It depends on how the signals are set up in the route.
FAQ: Okay wise guy, so how do I set up signals in a route?
A: It depends on how you intend to set up the AI traffic in the activities.

Here's your bible;

http://trains.0catch.com/tutorial.html

Note that most of that covers tracklaying and signaling and AI routing markers, see catch 22 for the reason why - to force the AI to do anything except skid around like an unguided missile, the track has to be set up to guide it where you want it to go.

Multitudes of track markers are often required, some routes I have as many as 40 "drive to" instructions along with wait for X seconds (5 or 10 is all that's needed if you just want him to come to a full stop before proceeding) which is long and tedious. To avoid doing it more than once I use a schedule library, with segments of the paths which I can combine to make longer paths, then each AI train I set up I merely have to issue "copy commands from" instructions in sequence for the path I want it to follow.

Best way to learn is by doing, place track markers along a path, set up a schedule library, watch what the AI does. In some cases I have Eastbound 01, Eastbound 02, Eastbound 03, Eastbound 04, Eastbound 05, Eastbound 06, etc. The AI follows the route just fine until one going westbound leaves a switch thrown the wrong way, then the idiot eastbound can't find the path to Eastbound 04 from Eastbound 03 because he can't figure out the pattern of switches. Rather than renumbering all the trackmarks after Eastbound 03, I just place an additional one and name it "Eastbound 03 TWS" (This Way, Stupid) then add the new one as an additional intermediate waypoint between Eastbound 03 and Eastbound 04.

Whatever you do the best laid plans of mice and men gang aft aglee, so plan on doing extensive testing and debugging.




the linik to the ÄI bbible" is no longer working. Do you have a currently working link to a good documentation of AI driving and AI rules?

Secondly, can you point me to some How To guide about using a schedule library? I can see that when the number of trains on the route grows, it would be very handy if one doesn't have to enter the same driver commands for a certain section of track over and over again. Any help is appreciated.
 
the linik to the ÄI bbible" is no longer working. Do you have a currently working link to a good documentation of AI driving and AI rules?

Secondly, can you point me to some How To guide about using a schedule library? I can see that when the number of trains on the route grows, it would be very handy if one doesn't have to enter the same driver commands for a certain section of track over and over again. Any help is appreciated.
I would recommend starting a new thread for your specific problem rather than bumping an almost 10 year old one. Also, tagging people like this — @MartindeGroot — notifies them of your post so they are more likely to read it. 😉

Cheers
 
the linik to the ÄI bbible" is no longer working. Do you have a currently working link to a good documentation of AI driving and AI rules?

Secondly, can you point me to some How To guide about using a schedule library? I can see that when the number of trains on the route grows, it would be very handy if one doesn't have to enter the same driver commands for a certain section of track over and over again. Any help is appreciated.
Hello I find it at wayback machine
https://web.archive.org/web/20160304195155/http://trains.0catch.com/tutorial.html
enjoy

John
 
Back
Top