The AI mechanism never ceases to amaze me.

It's latest goof. When told to Drive Via a particular track mark that is on a particular siding, a particular train continues down the mainline for about 1/2 mile past the default green (diverging turnout set for mainline) lever then stops and backs up. You've probably missed your exit in your car every now and then on the highway. Garmin can always recalculate and get you back on course. The funny thing is, the AI train just ahead of it properly executed the command. It threw the lever and drove via the track mark on the siding as it should while setting the lever back to default green behind itself as it should. Both trains were told to drive via the exact same track mark. How come one driver can execute the command correctly but the guy immediately following screws up so badly right in the very same session? One might think all drivers should screw up consistently.

I'm now running XDR. It might be that time for a TS12 reinstall again for the first time in about three weeks. Much edit work in Surveyor and so much running trains in Driver tends to break AI down over so much time. Almost always fresh, clean reinstalls tend to correct AI's brain cramps. XDR often doesn't fix anything AI-wise.

What you describe happens all the time to me, and others. It a bug in the program. Someone said that it has been corrected in TRS19. Is that true? And if so, it would mean that N3V knows the cause, then why not fix it in T:ane, or it is part of the next SP? Can anyone shed a light?

Yes this issue seems to have vanished. Note the word seems. From my testing I haven't run into that, but then again anything is possible to reoccur with AI drivers. You know how that goes.

If N3V fixed it, it's most likely through fixing other things such as the code threading issues which plagued TS12 and below. These threads are data communications going on with various parts of the program that interact with signals, update AI positions, control what track marks do, switch positions, and other things. If these threads are bogged down, the AI can and do weird things. It's like having a stuck key on a keyboard with stuff in the buffer. If we wait long enough, we'll get a bunch of stuff in the command queue and then all the data is streamed at once. This issue causes stutters as well. Through code changes, as well as the 64-bit program code, we now have a much more efficient program so that issue doesn't appear as often if not at all.

One way around this issue in general is to delay the AI trains a bit so they don't drive as close to each other. I've run into this issue a few times which drove me absolutely nuts. I had two trams (trolleys) running one after another. One driver took the mainline back to Gloucester station while the other headed to Western Avenue. The tram that was supposed to take the Gloucester mainline followed quite close behind the Western Avenue tram. Occasionally the one taking the Western Avenue branch caused the following tram taking Gloucester to not flip the junction and he would get lost. It so happened one day I caught the action in front of me and I was able to see why the idiot driver ended up heading to Western Avenue and on to West Gloucester to turn around, or spend the rest of his career backing up and turning around and causing an awful traffic tie up. The solution was quite simple. I delayed the start time of the Gloucester mainline tram by about 10 seconds on start up. That's all it took to offset that driver from going down the wrong branch.

JCitron said:

Yes this issue seems to have vanished. Note the word seems. From my testing I haven't run into that, but then again anything is possible to reoccur with AI drivers. You know how that goes.

If N3V fixed it, it's most likely through fixing other things such as the code threading issues which plagued TS12 and below. These threads are data communications going on with various parts of the program that interact with signals, update AI positions, control what track marks do, switch positions, and other things. If these threads are bogged down, the AI can and do weird things. It's like having a stuck key on a keyboard with stuff in the buffer. If we wait long enough, we'll get a bunch of stuff in the command queue and then all the data is streamed at once. This issue causes stutters as well. Through code changes, as well as the 64-bit program code, we now have a much more efficient program so that issue doesn't appear as often if not at all.

One way around this issue in general is to delay the AI trains a bit so they don't drive as close to each other. I've run into this issue a few times which drove me absolutely nuts. I had two trams (trolleys) running one after another. One driver took the mainline back to Gloucester station while the other headed to Western Avenue. The tram that was supposed to take the Gloucester mainline followed quite close behind the Western Avenue tram. Occasionally the one taking the Western Avenue branch caused the following tram taking Gloucester to not flip the junction and he would get lost. It so happened one day I caught the action in front of me and I was able to see why the idiot driver ended up heading to Western Avenue and on to West Gloucester to turn around, or spend the rest of his career backing up and turning around and causing an awful traffic tie up. The solution was quite simple. I delayed the start time of the Gloucester mainline tram by about 10 seconds on start up. That's all it took to offset that driver from going down the wrong branch.

Click to expand...

Yes, John: delay the AI trains a bit or just start them out in different parts of the layout.

I had three freight trains in a particular staging yard all scheduled to take off at the same time when Driver is launched. A UP manifest followed by an Indiana unit auto-rack followed by a BN piggyback. Upon exiting the yard, all three trains were then scheduled to drive onto a siding shortly up the mainline ahead. The UP lead out of the yard and took the proper route as scheduled. The Indiana followed the UP but took the wrong branch ahead. I then moved the Indiana to another part of the layout and that left just the UP followed by the BN. The UP lead again and did what it was supposed to do. The BN followed the UP out of the yard but made the same goof the Indiana RR train did earlier: took the wrong branch ahead. So now I am doing a trial run with both Indiana and the BN on different parts of the layout at session startup. The UP is now by itself in this yard on Driver startup and so far it has not goofed.

In another part of the layout there is another staging yard with a similar turnout just ahead of it. All three trains coming out of that yard close together seem to not goof at their own turnout just ahead. They all follow one another onto that siding as they should. So go figure. The staging yards is the storage area for AI driven trains and the very long siding ahead is the holding track where they are time-released 20 minutes apart one behind the other. This setup acts like portals emitting trains with time intervals.

This idea of autonomous cars really scares me knowing that computers can screw up so badly. I hope autonomous vehicle software is far superior to Trainz software. There would be many traffic deaths if it weren't. The Trainz game seems to be a sort of an experiment in autonomous transportation.




Ooops! One of my AI trains is now missing its consist: just a pair of SP SD40-T2 engines with the long Tank Train A missing! A re-occurrence of what typically happens when the game software develops rot over time. Time for a fresh reinstall and hopefully the siding junction goof might also be fixed.

AI is not infallible, AI makes mistakes, AI will function correctly one time, and another time it will totally mess up, and following trains will act differently at different sessions.

KISS-Keeping It Simple, is the key, and using many many multiple complexly manual input programed rules, will further foul things up.

I use "Drive" and along with fake junctions that have driveable signalmen on fake branch line BNSF50 invisible siding tracks, blocking the mainline, making a signal red for a mainline train, and locking the turnout, until you back up the driveable signalman a tad, turning the signal green again, allowing the mainline train to pass, and you can use BNSF50 invisible signal, and "signal thingy"

Track dirrectional markers, placed poiting at oncoming trains will stop unruly AI trains from making up their own self devised, or shortest route, paths

Trainz is NOT an automated autonomous simulator, AI makes many, many mistakes

MP242 said:

AI is not infallible, AI makes mistakes, AI will function correctly one time, and another time it will totally mess up, and following trains will act differently at different sessions.

KISS-Keeping It Simple, is the key, and using many many multiple complexly manual input programed rules, will further foul things up.

I use "Drive" and along with fake junctions that have driveable signalmen on fake branch line BNSF50 invisible siding tracks, blocking the mainline, making a signal red for a mainline train, and locking the turnout, until you back up the driveable signalman a tad, turning the signal green again, allowing the mainline train to pass, and you can use BNSF50 invisible signal, and "signal thingy"

Track dirrectional markers, placed poiting at oncoming trains will stop unruly AI trains from making up their own self devised, or shortest route, paths

Trainz is NOT an automated autonomous simulator, AI makes many, many mistakes

Click to expand...

I'm so glad Amtrak doesn't use Trainz software to run its physical trains. Its human personnel screw up bad enough as it is and people still get killed.


Trainz AI is like an finicky Volvo, Datsun 280 ZX Turbo, Fiat, Jaguar or SAAB engine that needs a periodic tune-up under the hood.
So far, a fresh reinstall has always done the trick when all else fails.

No Trainz people, nor animules, have ever been actually hurt, maimed, or seriously kilt' in Trainz

JonMyrlennBailey said:

It's latest goof. When told to Drive Via a particular track mark that is on a particular siding, a particular train continues down the mainline for about 1/2 mile past the default green (diverging turnout set for mainline) lever then stops and backs up. You've probably missed your exit in your car every now and then on the highway. Garmin can always recalculate and get you back on course. The funny thing is, the AI train just ahead of it properly executed the command. It threw the lever and drove via the track mark on the siding as it should while setting the lever back to default green behind itself as it should. Both trains were told to drive via the exact same track mark. How come one driver can execute the command correctly but the guy immediately following screws up so badly right in the very same session? One might think all drivers should screw up consistently.

I'm now running XDR. It might be that time for a TS12 reinstall again for the first time in about three weeks. Much edit work in Surveyor and so much running trains in Driver tends to break AI down over so much time. Almost always fresh, clean reinstalls tend to correct AI's brain cramps. XDR often doesn't fix anything AI-wise.

Click to expand...

Yes Trainz AI will do that and who knows why. I run passenger services in both directions on a long rambling single track line and I have things pretty well set up with correct signalling and the passing loops have direction markers to make sure trains can wait and pass one another. Most of the time my timetable schedule will run for hours without a hitch and then out of the blue an AI driver does something random and unexpected. So for a few minutes I yell at everybody and take control and sort out the problem and once it's fixed off the trains go again until the next time an AI driver has a 'moment'.

By the way my present TS2012 install has been running solidly for nearly 18 months without any problems so I'm wondering why you are having to reinstall it all the time.

KotangaGirl said:

Yes Trainz AI will do that and who knows why. I run passenger services in both directions on a long rambling single track line and I have things pretty well set up with correct signalling and the passing loops have direction markers to make sure trains can wait and pass one another. Most of the time my timetable schedule will run for hours without a hitch and then out of the blue an AI driver does something random and unexpected. So for a few minutes I yell at everybody and take control and sort out the problem and once it's fixed off the trains go again until the next time an AI driver has a 'moment'.

By the way my present TS2012 install has been running solidly for nearly 18 months without any problems so I'm wondering why you are having to reinstall it all the time.

Click to expand...

I don't know. I sadly lack a Doctorate in Trainzology. Could be malware screwing it up. Maybe Windows 7 is the culprit.
Maybe N3V hates me and is jinxing mine with a Trojan horse. It just seems like a fresh reinstall has been getting my Trainz back
"on track", at least for a while. Editing layouts in Surveyor a lot as I do seems to bring on the software rot fast. If you are just running Driver
most of the time and leaving your route and session builds alone you may have better luck.

I just can't have a simple train on a track that goes around in circles like an old Lionel or Marx. I got to have animals, dozens of sounds from crowing roosters to bullfrogs, trucks driving on YARN roads, flying helicopters, walking people, Bigfoot, horse-drawn stagecoaches, driving boats and the whole fancy kit and kaboodle. I'm trying to turn a Trainz layout into a virtual Disneyland theme park, so to speak. AI runs up to 30 vehicles on repeating schedules at once over my route. On top of that I may drive one train of my own by hand.

-1 army Huey chopper
-1 stagecoach
-1 town carriage
-1 farm wagon
-8 semi trucks
-3 logging trucks
-2 maintenance-of-way trucks
-2 speedboats
-1 narrow canal boat
-6 freight trains
-4 passenger trains

Constantly un-installing Trainz, and re-installing Trainz anew, just to get AI, to work is very pointless, like constantly un-installing, and re-installing a Windows OS on a PC, there is no such thing as "software rot".

MP242 said:

Constantly un-installing Trainz, and re-installing Trainz anew, just to get AI, to work is very pointless, like constantly un-installing, and re-installing a Windows OS on a PC, there is no such thing as "software rot".

Click to expand...

corrupt data then

AI is so important to me it is worth a fresh install to fix it

My Uk Norfolk has gone through many rebuilds over this past year as I continue to develop it to handle the demands of the traffic on the line. True enough it's a 'what-if' model of a secondary line and the traffic schedule is a lot lighter than what you've described for your layout, but rebuilding a layout shouldn't actually make any difference to how reliably it runs provided the rebuilding is done properly.
I have traffic running on the roads, trading schooners sailing along the coast, and plenty of background sound generators to help along the general ambience, but perhaps not to the level you describe. I'm actually wondering if you're pushing the TS2012 game engine out to the limits of what it can handle and that might be causing some of the problems your're experiencing.

KotangaGirl said:

Yes Trainz AI will do that and who knows why. I run passenger services in both directions on a long rambling single track line and I have things pretty well set up with correct signalling and the passing loops have direction markers to make sure trains can wait and pass one another. Most of the time my timetable schedule will run for hours without a hitch and then out of the blue an AI driver does something random and unexpected. So for a few minutes I yell at everybody and take control and sort out the problem and once it's fixed off the trains go again until the next time an AI driver has a 'moment'.

By the way my present TS2012 install has been running solidly for nearly 18 months without any problems so I'm wondering why you are having to reinstall it all the time.

Click to expand...

Many who make sessions seem to expect the AI to do everything. They give it insufficient clues in the form of:
* track marks;
* signals of the right kind to make proper blocks and to control junctions, single lines et al;
* no-entry markers;
* properly designed junctions/points.

Putting in these things can make AI sessions that are highly complex - those with lots of trains using the same lines & junctions - run well with no user intervention required. When the AI goes wrong, it's often because it's been given ambiguous, contradictory or impossible instructions because the navigation points are not well designed.

As you have, I've found that proper use of track marks, direction pointers and signals/blocks can generally avoid the AI going doo-lally. But it's also possible to use belt and braces - to include instructions in the driver list that not only give the list of track marks via an achievable route but also include instructions to set/unset points and/or signals as a train approaches them in a default condition other than needed for the route of that train. This stops the delays as a train comes up to points at a default direction opposite that it needs with a signal at red. The AI will eventually churn and change the points/signal. But that AI churn can instead be explicitly programmed into the list of driver instructions with the driver commands that set/unset points and perhaps also put signals to red for other entry points into the junction so any other train can't enter the junction until the first train has crossed that junction.

If a track mark is set at a suitable distance before the wrongly-set junction and it's red light, this can be used as a trigger to apply a series of point-setting instructions so that the points change, the signal goes green and the train goes the correct way through the junction without slowing. Another track mark beyond the junction can be used to release the junction back to it's default direction. If necessary, opposing signals can also be set (and later released) to stop trains coming the other way into the junction from going over the crossover of left & right tracks.

Lataxe

Thank you Lataxe. You've certainly given me some good things to think about. With both my M&GNJR layout and my GER layout with their long single track sections it's been a real learning curve to get them to operate reliably, but now they do for 99% of the time and I'm happy with that.
What I would like to see in Trainz is an instruction equivalent to having the staff/tablet for a section so that the AI driver who has it has full control of the section until the staff/tablet is surrendered at the end of the section. I have no idea how such a thing could implemented, but it certainly would make operating single lines much more immersive.

KotangaGirl said:

What I would like to see in Trainz is an instruction equivalent to having the staff/tablet for a section so that the AI driver who has it has full control of the section until the staff/tablet is surrendered at the end of the section. I have no idea how such a thing could implemented, but it certainly would make operating single lines much more immersive.

Click to expand...

Interlocking Towers and Train Control Blocks would achieve much the same thing. There is a staff/token system, that includes working mechanical staff machines and staff ticket boxes, that is designed for use in Trainz but it is cosmetic only - it has no control over junctions and signals.

pware said:

Interlocking Towers and Train Control Blocks would achieve much the same thing. There is a staff/token system, that includes working mechanical staff machines and staff ticket boxes, that is designed for use in Trainz but it is cosmetic only - it has no control over junctions and signals.

Click to expand...

Thanks pware. My GER layout is in TS2012 so I can't use interlocking towers unfortunately. I do have plans to move it over to TANE, but with so many custom assets I've modded myself on the layout it's going to be a bit of a nightmare.

That cosmetic staff/token system sounds interesting though and I might check that out just for the fun of it.

I must say that AI gives me absolutely no problems whatsoever at all, and I am overall perfectly satisfied with AI operations (as I mostly drive manually), But when using "Drive", AI functions exceptionally (as I have become an AI professional, forcing AI to do exactly as I want it to operate, by "Fooling AI" with outside the box thinking)

I have all the passenger services running on AI controlled schedules, but I drive all the goods trip workings myself. This means that like a real world engine driver I have to be aware of the timetable and work accordingly between the scheduled trains. Having my layout correctly signalled helps a lot with this.

JCitron said:

Yes this issue seems to have vanished. Note the word seems. From my testing I haven't run into that, but then again anything is possible to reoccur with AI drivers. You know how that goes.

If N3V fixed it, it's most likely through fixing other things such as the code threading issues which plagued TS12 and below. These threads are data communications going on with various parts of the program that interact with signals, update AI positions, control what track marks do, switch positions, and other things. If these threads are bogged down, the AI can and do weird things. It's like having a stuck key on a keyboard with stuff in the buffer. If we wait long enough, we'll get a bunch of stuff in the command queue and then all the data is streamed at once. This issue causes stutters as well. Through code changes, as well as the 64-bit program code, we now have a much more efficient program so that issue doesn't appear as often if not at all.

One way around this issue in general is to delay the AI trains a bit so they don't drive as close to each other. I've run into this issue a few times which drove me absolutely nuts. I had two trams (trolleys) running one after another. One driver took the mainline back to Gloucester station while the other headed to Western Avenue. The tram that was supposed to take the Gloucester mainline followed quite close behind the Western Avenue tram. Occasionally the one taking the Western Avenue branch caused the following tram taking Gloucester to not flip the junction and he would get lost. It so happened one day I caught the action in front of me and I was able to see why the idiot driver ended up heading to Western Avenue and on to West Gloucester to turn around, or spend the rest of his career backing up and turning around and causing an awful traffic tie up. The solution was quite simple. I delayed the start time of the Gloucester mainline tram by about 10 seconds on start up. That's all it took to offset that driver from going down the wrong branch.

Click to expand...

John, J Citron:

Reinstalling TS 2012 did NOT resolve the AI junction goof that is the subject of the thread. I pulled my hair out for several hours trying to figure out how to fool these idiots then it clicked! The good ol' Trigger Multiple Signals Rule. You, see, AI doesn't want to follow another train onto this siding if this lead train too close ahead so I was happy to oblige. I rigged up track triggers on the very long siding (about six miles) and an absolute signal right before the switch points. The switch diverges here. If there is another train within a mile down the siding, the following train will be put on hold until the lead train clears this mile-long gap. Track triggers have a range limit of 500 meters, so I used several in tandem to get a total range coverage of about a mile down this siding. Pretty clever, ay? Trigger Multiple Signals can be used with a single signal controlled by several triggers to boot in spite of its namesake. Now, the following train confidently flips the mainline turnout lever to a red state after a several minute wait at the signal if necessary and then goes down the proper siding as he should once he gets a green or a yellow. No more excuses to roll down the wrong branch missing the turnout. You just have to be smarter to a greater degree than AI is stupid to beat them.


Update later: a space (following gap) of 3,000 meters down the siding is overkill, though. I just reduced the siding trigger zone to a mere 1,000 meters , 0.62 miles, so following trains may only have to wait to up to less than a minute at the "gate signal" a couple hundred feet behind the junction points before proceeding down the correct branch once and for all. My gate signal is the one controlled by the TMS Rule and controls movement past this junction based upon whether there is a leading train close on the siding diverging to the right. If the siding is clear at least 1,000 meters down, the gate signal will be green and approaching trains can just roll down this siding non stop. No AI train is ever intended by me to take the mainline past this junction anyway. They are always to be diverted down the siding. Only my hand-driven vehicles may use the mainline branch here. I don't have to stop my hand-driven train on any red here and wait since I know this special signal is only to circumvent AI stupidity. There is just enough gap on the siding now so any lead train is far enough down to make the following approaching AI train ready, willing and able to take this siding without acting balky and miss the intended turnout. It's as if the lead train down the siding is "locking" the lever behind itself for a certain distance.

This very long siding is in the staging area of the route as it is a model RR layout. This siding acts as a train dispenser that is timed-release. Every 20 minutes a new train (variously a steam passenger excursion, a modern diesel passenger, a classic diesel passenger, a MOW truck, a mixed freight or a unit freight with both modern and classic d/e locos) is released from here to travel the loop of the layout then return to this holding siding. Trains are in the AI mode with their own respective command-line schedules and drivers. Some freight trains are even commanded to change their freight loads each run of the mainline loop while waiting in staging. This way, my BN piggy-back trailer train will get a fresh new assortment of differently-marked trailers for each and every go-round. This action effectively mimics what human hands do in a fiddle room. Passenger trains are scheduled to stop at the passenger station downtown. Steam trains make scheduled water stops along the way. Trains line up, stack up, here single file. There is a track mark from where the lead train is released once it's "on deck". Each successive train is given a Wait For command of 20 minutes upon moving up to the standby track mark. This way a train passes the layout circuit about every 20 minutes. Steam excursion passenger trains, because they are less common and rather special, are held for an additional 30 minutes in the staging yard before advancing to the holding siding from which they are then released to make a trip around the layout. It's more or less like the roller coaster rides at an amusement park. Trains line up at the loading platform to take on new passengers before completing their loop then return to line up again and discharge old riders. Continuous repetitive action. This is a two-track/two-way layout mainline system so there is a separate staging yard and holding siding for each direction of the route. Yes, folks, I have a "Disneylandized" philosophy to Trainz route design and building. I could use the Portal assets and train emission for periodic train generation, but those trains are random and don't look as nice as regular rolling stock placed on the track using the Trains tab in Surveyor. I am fussy about the consist makeup and the engines used. I like a lot of color, sound, action, variety and diversity. I like to see every rivet on my locos!

JonMyrlennBailey said:

Track triggers have a range limit of 500 meters, so I used several in tandem to get a total range coverage of about a mile down this siding. Pretty clever, ay? Trigger Multiple Signals can be used with a single signal controlled by several triggers to boot in spite of its namesake.

Click to expand...

It is not necessary to use a line of triggers, all set to 500m, to get the coverage of about a mile down a track. A single trigger, with its default radius of 20m, will do the job. That one trigger can be used to set a signal using the Set Signals Extended Rule or the Trigger Multiple Signals Rule (if you must), 1 mile or 100's of miles away. The signal, switch, or whatever, will remain set until it is cancelled by another trigger placed somewhere else.

Screenshot 1 - Using Trigger Multiple Signals Rule



Screenshot 2 - using the Trigger Check Rule and the Set Signal Extended Rule



In either case only a single trigger is needed.