Error checking sessions in TRS19


Well-known member
Working on a big route/session from Anatoth, London to Lille through the canal tunnel
wonderfull creation and very realistic.
but found performance below, what I know Trainz can do on my computer.

I have a 3 monitor setup here, 2 I use for trainz most of the time
on left monitor I opened the log screen, cleared the log, then started the session
was watching what trainz processes and finds

Many of my trains still use the brilliant Loco Light control rule, from didoz
I noticed it is not happy when some of the corona's are not in the kuid table
So repaired my trains that miss it.
Also I use sparks for my electric trains and noticed at start it cant find a.pant0
where I attached the sound to in my scripts.
So I made my script start with a 20 seconds delay before actually checking the spark conditions

Then I found an English NSE clock sign that constant gives log entries, cause it misses something
had no time to repair it yet, but removed them for now.
Another item constant spams the log is a clickety clack thing for track crossings
looked at the script, seems nice but it constant uses cpu time.

Why this long post?
If you work on big routes with many trains, everything has to be as correct as possible
or your framerate goes down the drain.
If something is causing many log entries repeatedly, replace or fix it.
hope it helps someone, it does me, so thought to share it.
have fun with trainz
greetings GM
Last edited:
This sounds oh too familiar. I'm not a script writer so I can't go in and tweak any scripts I wrote or modify others so in the end I remove things that cause issues. I have a particularly busy route that has been my test bed for new versions due to its number of assets. This route is also one of my favorites because of the varying action ranging from trams and local freight on the tram line along with freight and commuter trains on the mainline. When things went well, the session ran for hours, but when things got a bit tits up, it's a different story. Without cause, the AI would do weird things such as ignore track marks, direction markers, yeah those too, signals, speed limits, and anything else just to screw things up worse.

My culprit turned out to be too much of a good thing in this case. I had tram wheel squealing assets on nearly every curve on the line. While this is true on the big-city Green Line in Boston, I can't do this too much on my route because each and every one of these things is yet another hit on the CPU. I noticed that during the beta-testing these things produce a divide-by-zero error with the script. They work but so many of them caused the script to get a bit off kilter in the end, and that's when things went what we call south. After removing a bunch of those cool-sounding squealing objects, performance got better and the AI behaved a bit better.

In some cases, it could be an asset or two placed in Surveyor as I found out too that cause outright stutters. Being an oceanside route for the most part, I have lots and lots of boats and other marine-associated assets. In among my many, many downloads, I have some beautiful boats I've downloaded over the years. Most of the boats work fine, but there were some that could melt an NVidia 4080Ti-Premium if that card ever came out! The poly-count was upwards in the 86K range and even with LOD, they acted as a framerate sink. The trams would round a corner, and if viewed from within the cab, everything stuttered frame-to-frame until that spot was passed. Since this route is pretty tight, there's not much in the way for assets to completely drop out of view so this asset was hitting the GPU nearly all the time when sitting in the cab.

I then ran into another asset, or few assets on another part of the route. This was an interesting one which sent me into a snit for months until I found them. I would get to the fastest stretch of the line out to another community. This particular stretch had little in the way of lots of assets outside of a farm, small houses, trees, roads, and of course catenary. To the right is a river inlet with buoys and a few boats. I would round the corner and on to the nearly straight stretch only to be hit only once by a stutter Where everything would pause as if the program was gasping for air before continuing on. This only happened on the first load of these assets, making them difficult to find.

I then set out on the asset hunt. I deleted some old houses. Tried again, nope, and put them back. I thinned out my trees, nope, put some back but not a lot more. I kept this up with other suspects, but couldn't find them until one day I happened to be scrolling over the area in Surveyor and stopped suddenly then continued. I exited and returned, after saving since I had done some edits, and tried that area again. Located in the river were three tiny, innocuous buoys. A couple of red and one blue one. I deleted those ever so tiny things, and everything ran normally afterwards. Upon checking the assets, I saw nothing untoward about them, so I've come to the conclusion they're corrupted in some fashion. I deleted them and if they're needed, I'll download them again at some point, but given their size, honestly, I don't know why I put them in there in the first place because they were never, ever, ever seen since they were hidden down an embankment and out of view in the first place!

I then ran into this kind of situation again on another part of the route. This turned out to be an automobile. The car topped out at 150K polygons and never had an opportunity to decimate through LOD. After that pretty yellow Porsche was removed, everything came alive in that part as well.

So in summary, it's a combination of things. Scripted assets can be by far the biggest culprit due to how the code interrupts the operations and clogs threads, but in addition to that, it can be some pretty little innocent building, buoy, boat, car, or something else.
If someone knows how to pipe the output of the debugger that appears on the window, it might be possible to filter the results to show troublesome situations.
Yeah John, 1 litle thing can hit framerates bad
We now dont have to worry too much about polies, specialy when lod is applied properly
I do find things over 70k cause trouble even if they have lods, so they are banned here

The problem is often not 1 item but the combination of items.
Same applies to textures, I have to limit myself, textures over 4mb i generally refuse/remove
how much ground texture PBR do I actually see when I drive my Eurostar with 300km/h, i think nothing

I saw you mention boats, many have been made as trains but are mostly scenery
for every "train" Trainz has to calculate various parameters with every game tick
unless you turn physics off. Will incorporate that in next version of my SDCR.
No idea if it helps, but less calculations should be better.

no idea how to pipe the output pitkin, but since its a separate screen,
i can just have it open and live update while I play/check a session.
greetings GM