Constant CTDs in beta Build 96191

Whilst the Early Access Build 96000 remains fairly solid, I'm afraid I am experiencing way too may inexplicable CTDs in the current beta build, 96191.
For a while, I thought it might have something to do with changing viewing camera modes, but I've now discovered that afflicted AI sessions will still CTD if I do absolutely nothing but let them run their course without intervention.
Reports I've submitted to QA included the logfiles and crashdumps (.dmp) that show a huge number of runtime errors and warnings for the autonumbering system and the digital consoles found in one or more of the new CSX locos together with many script timeout errors.

On the other hand, a built-in session for KSC2 (like the Highland Limited passenger run) works flawlessly and completes without errors.

It is my own home-built sessions that now mostly include TRS2019 built-ins like the CSX locos (and nothing too exotic) that are suddenly crashing, when they would run for hours on end without error prior to this particular beta.
Now I'm also beginning to suspect some of the changes made to Post Processing might be implicated, since one CTD occurred immediately after I attempted to modify the PP settings during a Driver session. (Could be coincidental).

Is anybody else out there seeing an increase in CTDs on this beta build?
Or do I need to go back and rebuild from scratch my sessions that have worked without issue for many T:ANE and TRS2019 closed and open beta builds before?
Seems to me that it has to have something to do with changes made to TRS2019 built-ins and scripting behaviour since 96000.

Not noticed anything here yet but haven't done much driving, Got the compatibility setting enabled?

Haven't had any crashes to the desktop in Driver, but plenty in Surveyor. I stopped working in TS19 and went back to TAME

clam1952 - Yes - set to Maximize Compatibility. Might experiment with the 'Show errors on legacy calls' option to see if that turns up any new clues.
My logfiles show huge numbers of entries like: [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]; <NULL> World.NativePlaySound> Cannot find asset '<kuid2:45324:100139:16> "SP SD45"' in scene.
These are extremely numerous (scores of lines) and appear for every loco scheduled in the session.
The locos are indeed present and happily performing their AI chores. Sound is present for all when the camera is close enough...
I monitor memory use and the core temps and frequencies for both GPU and CPU constantly on another monitor and nothing unusual appears before the abrupt drop in utilisation accompanies a CTD.
Despite having many AI locos busy all around the map, these Driver sessions represent only a very modest load on my rig, with utilisation mostly in the ~30s percentage levels on the CPU and ~60s for the GPU.
Windows Maintenance records show no clues. TRS2019.exe simply terminates without protest or telling logfile entries and I'm left staring at my desktop wallpaper!

davesnow - I had no problems in Build 96000 and Surveyor is stable enough in this beta too, so it has to be some change made/ introduced since that build. Don't think I could ever go back to T:ANE for route building now that I have experienced TRS2019's capabilities, so only do so now for the beta testing in 96202 to help refine that excellent product that has served me well for several years.

Last night I replaced the CSX locos and purged the Cache/Internet files and the CTDs appear to have ceased, though I don't have sufficient samples to be confident that this CTD issue has been resolved.
Besides - I like those new CSX locos and want them back in my sessions again sometime when they're better behaved...


[/FONT]

I had one, but that was self-inflicted and due to a route I was testing for Celije while attempting to merge his very large route with lots of legacy content in it.

If you've played with the PP settings, try reverting them to one of the built-ins and see what happens. It could be a number of factors causing this and sadly we need to eliminate them one at a time to find the answer, and that's always in the last thing we try.

JCitron - Typically, I run Post Processing in Manual mode to remove the irksome and unwanted blur, Bloom, Depth of Field and SSAO effects that destroy distance clarity and views.
However, for these particular test runs, I left the PP settings entirely alone (except for a single test) so the tests were run at either 'Ultra' or 'Low' PP defaults. Accordingly, I can now pretty much exclude PP as a factor in these CTDs for now.
Will keep chipping away at this problem until I manage to nail the culprit...

PC_Ace said:

JCitron - Typically, I run Post Processing in Manual mode to remove the irksome and unwanted blur, Bloom, Depth of Field and SSAO effects that destroy distance clarity and views.
However, for these particular test runs, I left the PP settings entirely alone (except for a single test) so the tests were run at either 'Ultra' or 'Low' PP defaults. Accordingly, I can now pretty much exclude PP as a factor in these CTDs for now.
Will keep chipping away at this problem until I manage to nail the culprit...

Click to expand...

That's good. One thing off the list for now.

I'd hate to say it, but it could very well be content that's causing the problem and not necessarily those locomotives. I've run a ton of Jointed Rail's locomotives and they're pretty much all I use on my routes and so far I haven't had any problems. This could be related to a scripted asset such as a station, or other industry, any number of other things.

Could it be the route its self? Try merging the route into a blank and setup a session - you could copy a session and alter the route kuid to match the new route so you can keep the current operating session. That will eliminate the route its self, and then there's the session to work with. It could then be anything in there including something that's scripted as I said.

Thanks, John. That makes sense. Will go back to the original route (which was a merge test I created for T:ANE SP3 betas brought over to TRS2019) and re-design from there.
Will try the merge with a blank block trick first; test with a single loco and industry; then rebuild the session item by item until I locate the miscreants and deal to them severely.

PC_Ace said:

clam1952 - Yes - set to Maximize Compatibility. Might experiment with the 'Show errors on legacy calls' option to see if that turns up any new clues.
My logfiles show huge numbers of entries like: ; <NULL> World.NativePlaySound> Cannot find asset '<kuid2:45324:100139:16> "SP SD45"' in scene.
These are extremely numerous (scores of lines) and appear for every loco scheduled in the session.
The locos are indeed present and happily performing their AI chores. Sound is present for all when the camera is close enough...
I monitor memory use and the core temps and frequencies for both GPU and CPU constantly on another monitor and nothing unusual appears before the abrupt drop in utilisation accompanies a CTD.
Despite having many AI locos busy all around the map, these Driver sessions represent only a very modest load on my rig, with utilisation mostly in the ~30s percentage levels on the CPU and ~60s for the GPU.
Windows Maintenance records show no clues. TRS2019.exe simply terminates without protest or telling logfile entries and I'm left staring at my desktop wallpaper!

davesnow - I had no problems in Build 96000 and Surveyor is stable enough in this beta too, so it has to be some change made/ introduced since that build. Don't think I could ever go back to T:ANE for route building now that I have experienced TRS2019's capabilities, so only do so now for the beta testing in 96202 to help refine that excellent product that has served me well for several years.

Last night I replaced the CSX locos and purged the Cache/Internet files and the CTDs appear to have ceased, though I don't have sufficient samples to be confident that this CTD issue has been resolved.
Besides - I like those new CSX locos and want them back in my sessions again sometime when they're better behaved...

Click to expand...

PC_Ace,

I noticed that you state that a <NULL> error appears in your log file. The following was reported on the 4th September by pguy in a Post of the same name:

pguy said:

Just to report (before sending a bug report tomorrow to N3V helpdesk) that it seems that builtin driver command AutoDrive <kuid2:192081:4:4> by Brummfondel is now broken in both beta TRS2019 build 96191 and beta Tane SP3HF1 build 96202.

After analysis, it seems that the script compiler is now more strict, and no longer supports some script API call with ambiguous parameters like null.
It may become a big problem, as the scripts by Brummfondel are encrypted (.gse files) and if we have the compiler diagnosis we are not able to locally fix the problem. And as Brummfondel is no longer active in Trainz, it may be difficult to obtain an updated version …

And as many users of Interlocking Towers or of EITS do prefer to autodrive their train this is not a good news for all ITs and EITs users …

Regards.
Pierre.

Click to expand...

It looks like scripts containing a NULL parameter are no longer supported and could be the cause of your crashes. There has not been an N3V reply to that thread.

Aside from other bugged issues, I had also started to see CTD.
Was in the process of making a new route when first this popped up
UIAddSingleComponent> null view

When I clicked on Continue and Ignore Errors, I found myself back on the desktop.

Will try again. .... Naturally it doesn't repeat on schedule