When the AI are good, they're very good, but when they're bad they're terrible.

Just like the old saying about a problem child goes, this holds true for AI drivers. I agree that some of this is self-inflicted, but it's not always and it's due to game mechanics and that bit of randomness that gets thrown in the works. There are days when things go well, and there are days when everything falls apart as if the AI went out on a toot the night before and come to work in less than perfect form. With those days, the AI will get stuck at signals, run junctions, SPAD, and do all kinds of unkind things that keep me from doing what I want. It's those days, I want to take the whole kit-and-caboodle and rip it off my PC!


Well anyway, yesterday, I did some Trainzing for the first time in a few months outside of some brief beta-testing. I fired up build 111951 and went about the usual. Downloaded some routes, installed some updates, and then did some Surveyor stuff. It was quite fun and I enjoyed my time, which hasn't been that way in quite awhile. I then decided to drive and poke around my venerable Gloucester Terminal Electric route with about a dozen AI drivers, lots of consists spread out, and some portal-consists that run back and forth.


Outside of the portal-consists, the rest of the dozen or so AI drivers run various loops around the this compact route between various points with tram stations spread out along the way. In addition to the traction operation, I have some diesel switching operations that I do, with everyone else doing their thing. Instead of doing the usual routine of gathering the boxcars, covered hoppers, and tanks in the big yard near Gloucester, I instead started down along the docks. Like the rest of my switching, I use a couple of SW1500s and this operation was no different. In the yards, they work in tandem with each one facing in opposite directions. This makes switching easier, and when I go out on the road, I put an engine on each end so each one can push or pull cars in and out of the various sidings. Todays, switching job was to pick up loads and empties and return them to the yard, and if there was time left I was to switch the brewery.


While I did my switching, I was only interrupted twice. Yes, only twice due to stuck AI and that was at the very end of my operation since it was getting late. Nothing has changed in this setup, there was no new install of anything including the program or Windows. It was only a power up and go about my business. The AI for the most part did their job, and I didn't have to babysit them. After about 3-1/2 hours, it was time for bed and everything ended on a high-note for a change, and it was at that point that the AI started to come unglued.


I'm almost tempted to try this again, but then at the same time I don't want to ruin a good thing. Being a retired hardware technician and IT guy, I want to know why things worked pretty well this time but not others? Do I need to consult Oracle by throwing a power supply at the feet of the computer gods as the soothsayers did with goats in ancient times? The temps are good in my PC most of the time, except for the summertime, and even then they're not that high to do nasty things. I can't figure it out unless it was the Trainzing gods decided to shine a nice light on me for a change!

Well written John.

After reading your piece I did a Google search for problems with AI systems and it produced a wealth of links. Some common threads that that I found in the ones that I read were that most AI systems

• rely heavily on preset rules and lots (lots & lots) of data - if the rule base or data set are insufficient or incomplete then the predictions/actions of the AI will be faulty.
• can be very good at one particular task under very specific conditions - problems will arise when users try to apply them to solving new problems under new conditions, even when those new problems and conditions seem closely related.
• require a great deal of human supervised training - this training cannot guarantee that all possible inputs have been covered.

While the task of finding an available route through a freight yard may seem simple or even trivial to a human player, the same cannot be said for an AI system. How many possible switch and signal settings must be considered? What are the other consists in the route doing - have they locked any of the switches? While humans can quickly look at an overview of the yard layout (the "God's eye" or pigeon-eye view) the AI can only look at one switch at a time - like "Deep Blue" the IBM chess playing computer that calculates its next move by basically looking at all possible move combinations and it used enormous processing power to do it, and still lost some games.

The Trainz AI is useful but it has many limitations. Throwing more development time and resources at it will possibly make some improvements, probably minor, but not enough to satisfy everyone. Meanwhile other features will go wanting.

My thoughts.

Good description of the chances you take when using AI to run sessions and control your drivers/consists.

As a retired IT 'nerd' who once was trained in the Assembler machine language I realize that you have to treat each set of instructions for a Driver or consist as a small programme which must be very exact as to what you need to happen. Any condition or outcome must be allowed for and specific instructions written to do what is needed to achieve the desired result. It's a real mental challenge sometimes to get the AI engine to do what you want but I love it. Ive gradually built up a reasonably good session on my Sydney Metro route to have most of the lines running upwards of 40 consists to near real timetables but AI still throws in a curve ball.

Stil it keeps me off the streets and out of trouble.
PG

In the TRS19 forum part you can read a post from Russian multiplayers that they want a savegame for MP
the reason being after 3-4 hours its unplayable and crashes.
I asked the for me logical question, shouldn't that be fixed first? (as usual no response)


Trainz is a complex game with many parameters changing and being stored, with many threads running
The last few years we have new search meganisms that allow unload and search closer by
but those are constant running threads. Personally not convinced it is an improvement yet.


What i fear is that many things clog up in time, the trainz dbase (called soup) gets filled more and more
no idea how big it can be(probably related to your own hardware). and performance degrades over time.


The randomness probably lies in us the players, if we 1 day are at 1 train at 1 part of the map
and the other on a different location/train other things get loaded/started.

Great start to a discussion and I can confirm the behaviour of AI has been discussed since the day the first version of Trainz was released aeons ago! We used to refer to the AI idiosyncrasies as "Alistair and his pals" but, sadly, the character of "Alistair" was based on a real person, Alistair Duthart, and since he passed to the great big heavenly railway we don't tend to joke about him any more.
We always suspected that the original Aussies in Auran's "Brew Crew" wrote some form of randomisation into the AI drivers' scripting (long before N3V came into being). You can open a session today, and everything behaves as it should but when you open the same session tomorrow, AI trains get horribly stuck, go "wrong road" or set out on a 150 mile journey when they were only supposed to shunt the yard!
It's all part of the fun....................

PGibbons said:

Good description of the chances you take when using AI to run sessions and control your drivers/consists.

As a retired IT 'nerd' who once was trained in the Assembler machine language I realize that you have to treat each set of instructions for a Driver or consist as a small programme which must be very exact as to what you need to happen. Any condition or outcome must be allowed for and specific instructions written to do what is needed to achieve the desired result. It's a real mental challenge sometimes to get the AI engine to do what you want but I love it. Ive gradually built up a reasonably good session on my Sydney Metro route to have most of the lines running upwards of 40 consists to near real timetables but AI still throws in a curve ball.

Stil it keeps me off the streets and out of trouble.
PG

Click to expand...

A good summary of the issue and the solution - personally I find it astonishing how much the AI can cope with if its programmed by the maker of a driver's AI list to be explicit, unambiguous and granular enough to handle as many if-thens as might arise.

However, what's really impressive is that even a very minimal set of AI instructions can often guide a consist through a long journey transitioning numerous junctions and signals, even if there are other consists doing the same and occasionally demanding access to the same junction-signal nexus. You just have to get the signals, junctions and track layout "right". The AI is better than many of the complaints imply. .... But not perfect.

An important requirement beside the "make AI lists explicit, unambiguous and granular" is that the assets interacting to serve the AI calls (junctions, signals, locos et al) also need to be defined and constructed with sufficient quality. If they or their scripts are not also "explicit, unambiguous and granular" enough, things can go awry. This isn't inadequacies of the AI but of the asset definitions.

I've spent many happy but frustrating hours constructing complex AI sessions of many consists running on highly detailed routes with lots of complicated trackwork. With persistence and a lot of furtling, such sessions are often successful. Well ... let's say 97% successful. A glitch can sometimes emerge if random factors (such as variable timings) are included.

Perhaps some want the AI to do all the hard work in making the decisions about the next steps? I understand the desire for things to be automatic and easy, in this day and age of blackbox products - but sometimes the demand for more skill and understanding in the user to make things work can be a pleasure albeit one enjoyed by semi-masochists. I make my own furniture. Try that for a lesson in how to manage persistence-fade, frustration, mistakes and all the other things we humans are prone to!

Lataxe

"The randomness probably lies in us the players, if we 1 day are at 1 train at 1 part of the map
and the other on a different location/train other things get loaded/started." GM

Very true. Unless you really understand the big picture it is difficult to see that Fix-A caused another bug in unrelated code. Or that engine you added was not properly coded and did bad things that only occurred much later in the run.

Having fixed the hardware and coded the software I spent many long nights going over blueprints or very large books of system listings while answering the phone from the customer. It taught me that setting up defined conditions/tests were a good tool for getting that Ah-Ha moment. Simplify and test.

As Lataxe nicely explains, its not just the Trainz code or AI
but the combination/quality of all assets/kuids/items used
everything has to be loaded, processed at 1 time


Often I see what i silently call ego-ware
Many creators seems to think that their item is the best and most important item ever made
sorry dude(and dudess)..it is not.


Examples:
-too many polies, bad use of LOD, too big and too many textures
-PBR textures used on placed you never or hardly see
these increase loading times, cause they are up to 10 times the size
-Over complex scripts with too many threads for things that often will never happen/be used
-over the top complex railroad crossing,
because the built-in mocrossing never gets updated since 2000,
and simply is not flexible with their fixed trigger distances.


In many cases on a 1 board map and a test run will show no problem whatsoever.
But the moment it is used in a huge map with many trains, things add-up


I find great joy in optimizing and improving a route, working with (as apposed to against) the AI
that it is not perfect, makes it a challenge and fun

These are good thoughts on this, guys. Thank you.

I've always thought of the AI "schedules" as program subroutines even with my very limited programming experience, which consisted of classwork while taking IT classes. The interface is in its self a bit of OOP with the drag and drop nature of the command queue. Each AI driver, while an entity its self, interacts with similar entities, and interacts with other scripts, and internal threads within the program, and each AI driver and its driver commands is essentially a subroutine within a larger subroutine. In most programs, this isn't as obvious as it is in Trainz.

As said by G.M. the problem isn't just the simple AI drivers and their schedules, but instead is a combination of everything within the environment in which they exist. Overly complex scripts and infinite-sized tables can bog down the underlying threads and cause weird things to happen. Having an overly textured asset, or too high a polygon asset, will put a drag on the system at the wrong moment, and everything will start to fall apart. In the end, it's a sum of all these things that makes the overall system fail. Herein lies the problem. We enjoy the opened-ended, freely created and placed assets, but at the same time it's a blessing and a curse, and basically too much of a good thing in some cases. Other simulators utilize fixed-assets, tightly controlled built-in content, and very small environments for obvious reasons.

A number of revisions ago in TANE, I reported that my big routes would suffer from "dumb" AI after about 30 to 45 minutes. The AI would start out fine, then things started to fall apart. The AI drivers would stop at signals that were green, ignore junctions, and then get stuck later on at various places. They would stop as if they were on a lunch break or outlawed on their runs. There was nothing different in their schedules to cause this, and inserting some quick wait... commands didn't help, because I was thinking that perhaps I had too many commands as they navigated a bunch of track marks in various locations.

Other times, the immediate signal was red, but those further down were green, and pressing pause for a few seconds would "unstick" the AI and everything was happy. I found I could do this routine only once, or if I was lucky a second time, but after that I had to save, quit and load the saved session. Starting up the saved session, didn't work either and in fact things actually got worse. Signals this time remained dark and the AI ran through them, ignored track marks, direction marks, and speed limits. This wasn't consistent either. There were times when the signals started out red and the AI would SPAD them all. I went as far as to change out the signals from one creator for another and this worked initially making me think the problem was the signals and their related scripts, but as soon as I got things up and running again, the problem occurred again.

When I reported this issue to N3V, I got an immediate response from not only the QA team, but also management. The issue is quite deep and admittedly, they said there needs to be a complete rewrite of the underlying threading at the time. TRS19 has had some improvements in this area, but the underlying problem is still there as the Russian multiplayer dudes have seen. Larger routes tend to fall down a lot sooner than the smaller ones for obvious reasons, but small complex routes can bring things down even quicker.

As PGibbons noted as well as others, the solution to building complex setups is to keep things simple. We can do a lot of complex things with smaller, less complex components that don't overbear the underlying subsystems with too much fluff. This doesn't mean a barebones route, but it does mean we pick and choose our components carefully. Perhaps some day we will see an updated AI system that will handle much bigger routes without falling apart. N3V we know is working on this with the new segmented route structure. Hopefully, as time goes on, this will be improved as well without breaking what already works.

This has become an interesting and good discussion TY for starting John.


What I discovered while scripting, that many parts of Trainz are not in the maincode
but little addon scripts, like lego blocks that interact with each other and the main program.
Each of these little building blocks can fail and currently they are not capable of restarting themselves if
an exception occurs.
The longer you are in game the more things have happened and thus increase the risc of a little stuck script.


A good example was in "the polish loc script disaster" around SP2 maybe some remember that.
threads run wild and 2 scripts fight over who should get the action done.


If the base code would have saveguards, to stop a spamming/looping script or restart parts when exceptions have occurred
you could probably play Trainz longer with a working AI. I know this is hard to do.
Also it is very important that actual coders of trainz, regular post/interact on forums and explain about the inner workings
so we can make content more effective and better.
I realize its a small crew, with limited time, but this time is essential cause the code they write does not standalone.

"the code they write does not standalone"


VERY TRUE

I run the AI on the K.I.S.S.sytem. I use very simple non prototypical signaling. Use only 02 and 04 signals and some dwarfs in complicated yards. The drivers run on line of sight in yards and work happily together. The main lines are all double track with direction arrows. My main route is made up of early Philskene routes brought up to Tane standard merged into a large layout that takes 90 minutes real time to get from one end to the other. I have had 45 consist running at one time with very few AI failures. I think the biggest problem that most have is they make the instructions too complicated.
Cheers,
Mike

I find that AI works better if you take the crews out for coffee and Krispy Kreme doughnuts once in a while. Let 'em know you appreciate them.

Love the comments on this thread especially from all the IT tragics...


My Session for the Sydney Metro route is built using the Schedule Library where I have created 'schedules' to run consists on most of the Sydney network routes T1, T2, T3, T4, T5, T7, T8 & T9. Each route has an Up & Down schedule so far and I plan to create express and all station versions. The schedules usually have Portals at the ends which spawn consists at regular intervals, travel the route then get sent to the terminal portal. Ive recently installed several EIT's and these add to the ability to exercise some more control over accidental mishaps where consists get into trouble and gradually lock up the session waiting for some condition to be met.. Most of the routes run well thanks to the actual design of the Sydney rail network which separates 'up' and 'down' tracks and, in the inner areas, has Local, Suburban and Regional sections of track such as the section between Central & Strathfield and quadruple lines for Illawarra and Western lines.
The current version of the session generally spawn consists at between 5 to 10 minutes which I've tested over several months to get good results.

The most interesting set of Schedules is a group which controls the assembly of a 16 car Indian Pacific consist at Central then despatch to the Western Portal.
eg. A shunter picks up 2 car transport wagons from Eveleigh yard and delivers to Central Vehicle dock, returns to Eveleigh to pick up cars 1-8 of the IP deliver them to Central Platform 1, return to Eveleigh, pick up cars 9-16 of IP deliver to Central Platform 2. then return to shunter dock at Eveleigh where he trips a trigger to set the IP loco's in motion at Flemington yard. IP loco #1 couples with loco #2 then loco #3 then runs in to Central. At central the IP loco set couple in turn with the car transporters, cars 1-8, then cars 9-16, and at a set time head west to the Western Portal.
All of this happens in parallel with other traffic running on the suburban lines and normally takes just on an hour to run.


As with the suburban routes Ive broken the IP part of the session up into about 6 individual schedules so I can test and fine tune each part until it works as designed. Ive used a good range of Driver commands including Drive to, Drive via, Couple/Uncouple, run around train, triggers, Move to loco...etc Although built in TANE SP4 i've tested successfully in TRS2019.



All this is great fun, a real challenge and a break from my route building projects - currently Coffs to Grafton.


FYI: my Sydney Metro (over 10 years in the making !) covers south to Menangle, Illawarra to Sutherland, East Hill, Bankstown, Olympic & Carlingford lines,North to Hornsby (soon to Berowra), west to Penrith. SSFL and freight lines Botany container, to Chullora. and the Metro Light Rail . Mainly rail infrastructure and sparse scenery. Only trouble is keeping up with changes being made by Sydney Rail as various parts of the network are updated. Ive decided to lock up my version at about 2010 level and concentrate on building sessions to keep my brain in working order.
PG

I've been going back through several very large routes (typically 35-45 trains running at once) and removing all -- every last one -- of the Navigate/Drive To/Via commands and replacing them with EIT tower routes and AutoDrive commands. So far the result has been that several of the routes that in the past would die after about 45-55 minutes can successfully run for up to 2-3 hours or more. My own theory on this is that the demands on the CPU of those commands, while individually minor, can add up to enough of a backlog in the Trainz messaging system that things start to fall apart (symptomized by signals that sometimes don't change from green to red for up to a minute or more after the passage of a train).

(Of course this requires careful setting of all intermediate switches as the AI will not do any auto-routing. Once a train stalls, it's all over.)

As Churchill once wrote, "If it isn't true, it ought to be."

--Lamont

Hi

I've been using Trainz for the past 13 years and have always used path setting and autodrive for the AI. It takes decision making largely out of the AIs hands and so saves time and a lot of frustration. I started with brummfondels path setting and timetabling rules and commands, then onto the SCS2006 rule and its successor the SCS2013 rule which were excellent but unfortunately can't work with Tane and TS19. Since Tane was introduced I work with P Guy's EITs, Mission Codes and Timetabling rules and driver commands.

Little things can make a big difference such as ensuring that in a yard all junctions are set from the entry/exit track to the furthest siding away so that the AI only has to throw one junction to get into or out of any track. I also use the Schedule Library to create a lot of "subroutines" for a route. It is much easier to debug a small section of route than to do the whole thing. These schedules are reusable and can be called in any order to make up other much more complicated schedules.

I occasionally use the Drive to/ Drive via commands where there is no scope for the AI to get lost but I never use Navigate to/Navigate via commands as they allow the AI to make their own decisions with unpredictable results. The runround command is also never used as it can be very unpredictable. Set up individual commands for each leg of the run round in a schedule in the schedule library from where they can be called with one copy command.

Another thing that I make a lot of use of is variables which can allow you to control decision making in your schedules without the AI being involved.

As I've written before, In my opinion success with the AI is dependant on the amount of effort you put into taming them. I'm lucky as I'm retired and so have time to experiment with lots of the scores of driver commands and rules that are on the DLS but I do realise that many people aren't that fortunate and don't have the time to do this.

I think that the main thing is to minimize the opportunities for the AI to make wrong decisions.

Regards

Brian

Is there a way to examine the logic, or at least the results, of the AI's decisions, rather than waiting to see if it breaks? Even if we can't change it, at least would know if I put a signal here or lock that switch there it would help guide the AI.