AI trains
- Thread starter Danieldd4
- Start date
Hi Danieldd,
If there is a limit it's pretty big, but the usual limit is what your computer can handle. The more trainz you add the more load on your computer especially the graphics card and ram.
Cheers,
Bill69
shaneturner12
Tutorial Creator
Actually the limit is in gigabytes, not amount of trains - most versions of Trainz have a 2GB limit in memory for its data (I found that out after getting a kernelstandard_7c.dll fatal error) - it ultimately depends on the complexity of the route and the trains.
If Trainz does hit that limit, you will soon know as it usually throws up a fatal error in kernelstandad_7c.dll
Shane
If Trainz does hit that limit, you will soon know as it usually throws up a fatal error in kernelstandad_7c.dll
Shane
Wessex_Electric_Nutter
New member
And also how many instructions you can give to a train, I ran 7 very intensively timetabled trains on a layout and it worked well. It was for a branch line that was about 8 miles or so long with peak services working at every 10 minutes, whlie off peak was half hourly (and required only 2 trains). Obviosuly, I went ahead and included all ECS moves (Empty Coaching Stock) and passenger moves in the timetable. (although, when I got down the diagrams to around 20:00, my laptops started stuttering big time at this point.)
On top of that, I had about 6-7 trams working on repetitive instructions, another 10 people movers working on repetitive instructions and 10 trains going to portals from one side to the other side of the map.
Last edited:
shaneturner12
Tutorial Creator
I run most of my trains from portals with several instructions as well (on one of my routes, there is at least 10-15 stations that the train has to call at) - it is also a big route (20MB+) with a small session (~1.6MB)
In terms of instruction limits, I think that is determined on computer specs and complexity of route.
Shane
In terms of instruction limits, I think that is determined on computer specs and complexity of route.
Shane
Hi Everybody.
I found my system which is dual core that once you get above nine or ten A1 Trainz running at the same time they start not doing what they are programmed to do. They sometimes will not stop at the stations they are supposed to or go to the wrong destination.
I have never had the system completely crash, but I usually have to press the escape button out on the session as things often become completely senseless.
As already stated it seems depend on the size of the route, how complicated it is, and how complicated the A1 instructions are. Having said that it seems that you can have as many A1 Trains as you like within the above restrictions.
All the best with it
Bill
I found my system which is dual core that once you get above nine or ten A1 Trainz running at the same time they start not doing what they are programmed to do. They sometimes will not stop at the stations they are supposed to or go to the wrong destination.
I have never had the system completely crash, but I usually have to press the escape button out on the session as things often become completely senseless.
As already stated it seems depend on the size of the route, how complicated it is, and how complicated the A1 instructions are. Having said that it seems that you can have as many A1 Trains as you like within the above restrictions.
All the best with it
Bill
Last edited:
G'day all.
My experience with this is that I had 15 AI trains set to run on a lengthy list of commands.
I noticed some trains were not working correctly and found that at some point you reach a maximum of commands that can be set.
As I was adding new commands to a driver, other drivers were losing some.
This indicates that there is a maximum amount that can be assigned to them. How I got around this is by using the 'Resource Verify Rule' and the 'Driver Schedule Rule' to put some in a subset of commands.
Seems to work OK that way.
Dennis
My experience with this is that I had 15 AI trains set to run on a lengthy list of commands.
I noticed some trains were not working correctly and found that at some point you reach a maximum of commands that can be set.
As I was adding new commands to a driver, other drivers were losing some.
This indicates that there is a maximum amount that can be assigned to them. How I got around this is by using the 'Resource Verify Rule' and the 'Driver Schedule Rule' to put some in a subset of commands.
Seems to work OK that way.
Dennis
Bill I've noticed this too with the AI getting stupid when there are too many of them running at once.
One of the work-arounds I have found for this is to use WAIT... commands between changes in the schedule. I do this at the beginning so of the schedules so the trains don't all start running at once, and in between turns at the terminal.
I find that the waiting gives the program and computer a chance to settle down after loading everything into memory, and gives the program a chance to assign the driver command-scripts to the drivers.
John
My first and only route so far has been able to handle 30 trains with no big problems. However, I have observed some weird behaviors that make a huge impact on the performance of the route.
For example, a train stopped in front of a green light waiting to access a junction which is in the right position to go with four or more free blocks ahead, all with green lights. If I right-click on the loco->View Details, it says "waiting for access to junction nnn"; after some 10-20 seconds finally the train is allowed to continue. In the meantime, others locos are piling up behind that first stuck train. That time of 10-20 secs may be longer, it depends when I pay attention to the train-stuck warning.
Other problem I have seen is when two double main lines join at some point. Only one branch gets the green light and until all trains have passed the other branch does not get the green line. Quite unfair, I need a traffic cop!
Another one is a junction gets locked by a train further away even when another train is just in front of the junction ready to go. I have put many intermediate dummy junctions with no success. I am going to experiment with the "signal thingy" I just ran into to see if I get an improvement.
All and all, this game is quite good and it demands powerfull computers if you want to run huge routes. I am experimenting with a new video card ATI radeon 5700 but I am wondering if my cpu may not be able to cope with the calculations/ AMD Athlon 64 dual core 4800+ / Windows 7 ultimate
For example, a train stopped in front of a green light waiting to access a junction which is in the right position to go with four or more free blocks ahead, all with green lights. If I right-click on the loco->View Details, it says "waiting for access to junction nnn"; after some 10-20 seconds finally the train is allowed to continue. In the meantime, others locos are piling up behind that first stuck train. That time of 10-20 secs may be longer, it depends when I pay attention to the train-stuck warning.
Other problem I have seen is when two double main lines join at some point. Only one branch gets the green light and until all trains have passed the other branch does not get the green line. Quite unfair, I need a traffic cop!
Another one is a junction gets locked by a train further away even when another train is just in front of the junction ready to go. I have put many intermediate dummy junctions with no success. I am going to experiment with the "signal thingy" I just ran into to see if I get an improvement.
All and all, this game is quite good and it demands powerfull computers if you want to run huge routes. I am experimenting with a new video card ATI radeon 5700 but I am wondering if my cpu may not be able to cope with the calculations/ AMD Athlon 64 dual core 4800+ / Windows 7 ultimate
Hi John,Ffccnn And Everybody.
Funny you should have said that John regarding the wait command, as over the last couple of days I have given that ago myself and found that it definitely improves things.
I had ten Consists starting at the same time in one session on my North Devon route straight after startup. The first couple of minutes would be all right but it would not be long before the whole session descended into chaos with trains going in the wrong direction, stopping at signals which were in their favor or just not starting at all.
However, I have found that setting the wait command especially in the later running order consists (example, seven and eight) makes a huge difference to the first ones starting up correctly. I am going to continue to the trial see if it sorts everything out permanently.
With regard to the spec of the PC having much effect on the problem, my guess would be probably not. I have a good spec on this computer I am using now and yet I still seem to be having the same problem as others using older lower spec machines. So I feel the problem is probably in the Auran software.
In case anyone is wondering why I need 10 trains to start at the same time, it's for my "take em home session " which is a summer Saturday morning based scenario with lots of holidaymakers leaving the hotels and holiday centers in the North Devon resorts at around 10 AM. So the scenario is, you have all the holiday special Trains starting up in the various resorts at the same time to "take em home"
As I am a soft hearted person I just can't stand to see them waiting for a long time for their train when they are already down hearted at having to go home. (or can I ?......No)
That's my good nature side in action.
Bill
Funny you should have said that John regarding the wait command, as over the last couple of days I have given that ago myself and found that it definitely improves things.
I had ten Consists starting at the same time in one session on my North Devon route straight after startup. The first couple of minutes would be all right but it would not be long before the whole session descended into chaos with trains going in the wrong direction, stopping at signals which were in their favor or just not starting at all.
However, I have found that setting the wait command especially in the later running order consists (example, seven and eight) makes a huge difference to the first ones starting up correctly. I am going to continue to the trial see if it sorts everything out permanently.
With regard to the spec of the PC having much effect on the problem, my guess would be probably not. I have a good spec on this computer I am using now and yet I still seem to be having the same problem as others using older lower spec machines. So I feel the problem is probably in the Auran software.
In case anyone is wondering why I need 10 trains to start at the same time, it's for my "take em home session " which is a summer Saturday morning based scenario with lots of holidaymakers leaving the hotels and holiday centers in the North Devon resorts at around 10 AM. So the scenario is, you have all the holiday special Trains starting up in the various resorts at the same time to "take em home"
As I am a soft hearted person I just can't stand to see them waiting for a long time for their train when they are already down hearted at having to go home. (or can I ?......No)
That's my good nature side in action.
Bill
@Bill,
I'm glad this has worked reasonably well for you. I discovered this awhile ago by accident, sort of. I had at one time around 20 or so trains running at once plus others coming in from the portals. I noticed that as the portal trains were being added, my assigned drivers were getting lost. I even found one exploring the dock-side trackage instead of heading to the passenger terminal.
When I got to the passenger terminal, I noticed there were trains stuck at the station lead. There was one train that had locked the entrance and then had run through the points and derailed, which prevented anyone else from leaving the termanal. Remember this was way before the derailed train erasor and other nifty ways of removing derailed consists. So basically everything was hosed at this point, and I had to end my session.
Another time I noticed when starting a whole passenger-terminal's worth of trains running at once and my machine having fits. For some reason instead of automatically building in a start-delay when starting the simulation, the program likes to send everything off to the races. This too caused many frustrations with junctions, and confused drivers. I figured it was because of the large number of trains running for the junctions, and this was what was causing the tie-ups. Thus one day, I added wait commands to my trains leaving the terminal. The purpose was to allow for an orderly schedule so they all wouldn't be grabbing junctions and confusing everyone else. The end effect was also the program had a chance to settle down and load everything in before starting.
Today the Wait... commands are now part of my regular schedule setup. That short delay makes a substantial difference in how the sim operates. The trains now receive their commands and the program loads. The command is included in the repeat loop so the train waits between runs. The delay maybe only 20 seconds or so, but it's enough to keep things from going too far in the haywire direction.
John
I'm glad this has worked reasonably well for you. I discovered this awhile ago by accident, sort of. I had at one time around 20 or so trains running at once plus others coming in from the portals. I noticed that as the portal trains were being added, my assigned drivers were getting lost. I even found one exploring the dock-side trackage instead of heading to the passenger terminal.
When I got to the passenger terminal, I noticed there were trains stuck at the station lead. There was one train that had locked the entrance and then had run through the points and derailed, which prevented anyone else from leaving the termanal. Remember this was way before the derailed train erasor and other nifty ways of removing derailed consists. So basically everything was hosed at this point, and I had to end my session.
Another time I noticed when starting a whole passenger-terminal's worth of trains running at once and my machine having fits. For some reason instead of automatically building in a start-delay when starting the simulation, the program likes to send everything off to the races. This too caused many frustrations with junctions, and confused drivers. I figured it was because of the large number of trains running for the junctions, and this was what was causing the tie-ups. Thus one day, I added wait commands to my trains leaving the terminal. The purpose was to allow for an orderly schedule so they all wouldn't be grabbing junctions and confusing everyone else. The end effect was also the program had a chance to settle down and load everything in before starting.
Today the Wait... commands are now part of my regular schedule setup. That short delay makes a substantial difference in how the sim operates. The trains now receive their commands and the program loads. The command is included in the repeat loop so the train waits between runs. The delay maybe only 20 seconds or so, but it's enough to keep things from going too far in the haywire direction.
John
I give the wait command a big thumbs up too.
I've found from watching TC3 for many an hour (70 miles long - Thanks Auran!!) that when things go wrong, it is often (but NOT always) when AI is having to do too much at once.
This is a theory, in part, but, for example, I'm a big fan of Green British Rail Diesels showing their reporting number correctly. And if your train spawns from a portal, this can be a problem. (I'm talking about the "Set Reporting Number" rule here).
I once had a train emerge from a portal, first instruction - set train reporting number, 2nd instruction wait 5 minutes. The train emerged with no driver visible in the cab. This also meant that the train had not collected its instructions on passing Go (so to speak), so it came to a stand. After a full 2 minutes, the driver appeared, and, hey presto, the Set Reporting Number rule was executed. So, AI and my processor eventually got there.
So, be kind to your PC.
Set a limit of, say 6 minutes between any two trains emerging onto your session. This really means you have to use the Portal Timetable Rule, rather than programming a portal within its properties
Leave at least one Portal length of track between a Portal and ANYTHING. No signal, no speed restriction, no junctions. Give the poor thing a chance!
If you have the inclination, experiment. But be thorough!! This is a beautifully logical, but complicated, piece of kit - so carefully check any assumptions you make....
I've found from watching TC3 for many an hour (70 miles long - Thanks Auran!!) that when things go wrong, it is often (but NOT always) when AI is having to do too much at once.
This is a theory, in part, but, for example, I'm a big fan of Green British Rail Diesels showing their reporting number correctly. And if your train spawns from a portal, this can be a problem. (I'm talking about the "Set Reporting Number" rule here).
I once had a train emerge from a portal, first instruction - set train reporting number, 2nd instruction wait 5 minutes. The train emerged with no driver visible in the cab. This also meant that the train had not collected its instructions on passing Go (so to speak), so it came to a stand. After a full 2 minutes, the driver appeared, and, hey presto, the Set Reporting Number rule was executed. So, AI and my processor eventually got there.
So, be kind to your PC.
Set a limit of, say 6 minutes between any two trains emerging onto your session. This really means you have to use the Portal Timetable Rule, rather than programming a portal within its properties
Leave at least one Portal length of track between a Portal and ANYTHING. No signal, no speed restriction, no junctions. Give the poor thing a chance!
If you have the inclination, experiment. But be thorough!! This is a beautifully logical, but complicated, piece of kit - so carefully check any assumptions you make....
Wait for trigger works great too...
I discovered the ability to run an increased number of AI trains by using what I call 'progressive scheduling'. I do not use long driver scripts, and NEVER use the repeat function. Instead, any driver's current script (schedule) only gets him to his next stop, and performs all of the actions at that stop such as shunting, loading, unloading, etc. The last command in the script is always a copy/append from the library that sets up the next leg of the drivers schedule as far as his next stop. If the route repeats, the first script/drive is appended at the end of the last one. My library is organized by stop/station, and contains entries for every train that stops there, including path and autopilot local commands. The station to staion mainline commands are always NavigateToTrackmark, and trains that pass through a station on the mainline without stops do not contain a library entry for that station. I have run up to 36 concurrent 'drives' over 114 miles of scale track on 384 boards using this method on the Tacoma Eastern without a crash or loss of program integrity. I DID later divide the route into three divisions for better performance, but this had more to do with scenery splines and video performance than anything else. The TE is essentially a logging railroad, and in a very forested environment, and the very high number of forest splines, even using 400 meter cover splines did have an impact on draw times.
RFB
Tacoma Eastern
So far the only problem I get as far as high AI train count is when they get stopped at a red signal of an occupied block, they tend to stop looking for their next command. By doing this, the lower right control panel reappears, and it continues to wait after it gets caution/solid yellow light and then work its way to the clear/green. I usually have to take control and move the train manually until the AI takes it back automatically at about 1/3 to1/4 of a mile before the trackmark/station/industry. If I wait to see if the AI does eventually resume on its own, it usually doesn't. I have even gone as far as to let all 25 trains on the route either stack up behind the troublemaker, or get hung up themselves. If anyone knows of a way to help this problem without removing trains, I am all ears. I have so far tried breaking the entire route commands into short segments in the library, it helped to reduce the no. of hangups. I have tried the wait for time commands. that made it good for about 40-60 minutes of running, but, when a few of trains started to piggyback. it goes screwy again. I have tried the wait for trigger comand. that one made it worse for me. OH!! I have tried this little test. I have even stacked the trains " bumper to bumper" for the start of the session, watched to see if all trains can unstack themselves. They do, and then then run for about 30-40 minutes, then they start acting up again. I have tried to use portals instead of loops to turn the trains around for the return trip. seems to muck up about the same both ways. and I try to keep a 5-1 ratio of signals to trains so as to allow all trains to start on the green lights. all industries and stations are on side lines so no one is blocking the mainlines during sevice calls. I really hope some one has an idea or to I can try, I'm tired of taking hours away from my own manually operated train to un stick these AI trains. One final obsevation. It is only the freight trains screwing up.(yes, I have changed and/or removed/re-added the locos.) All 12 Amtraks just needed the freight trains in front of them moved along.
It seems that signalling (semaphores) is not correct. Try to put in additional invisible signal at junction (try combination before and after junction without touching the previous semaphore) where train stop. In general it's valid to know that Ai's trains demands additional signals.
BTW running 25 AI trains in the same time is almost impossible, of course it depends how big the route is, which rules you use and how signalling is accurate.
Last edited:
I'm sorry my knowledge of english is not good enough, what does it mean 'up', what do you wish to tell with this.
The problem is along the single line. adding a few more signals helped some but I closely watched the troubled trains and it seems to wait until the line is clear of trains between itself and the next marker. Literally the very nano second the "blocking train" passes the track mark, the ai train sees it and restarts it's run. At the industries, the trains run fine.
NEW POST IN A POST!!!
Febuary 17th, 2012, 4:26 AM(forum time)
I have a new personal best for number of AI trains in a route. 256 single locos. ( I am experimenting with the ASB DTT system) This is all on a 12 x 1 baseboard layout. I stopped counting lights at 200 and was only a third of the way down( yup, need that many to make it work), 4 double track turnouts on the north into portals and the south is a mirror image of that. Nothing added that is not critical to just running trains on rail. I have so far not even seen the game or computer blink once. I guess as long as we stay within the computer specs there is no limit to how many AI driven trains you run.
NEW POST IN A POST!!!
Febuary 17th, 2012, 4:26 AM(forum time)
I have a new personal best for number of AI trains in a route. 256 single locos. ( I am experimenting with the ASB DTT system) This is all on a 12 x 1 baseboard layout. I stopped counting lights at 200 and was only a third of the way down( yup, need that many to make it work), 4 double track turnouts on the north into portals and the south is a mirror image of that. Nothing added that is not critical to just running trains on rail. I have so far not even seen the game or computer blink once. I guess as long as we stay within the computer specs there is no limit to how many AI driven trains you run.
Last edited: