A Minor Problem Using TRS22

[pitmilly]

I have three particular WIP Routes which I first started in TANE, then progressed through various versions/updates of TRS19 Platinum and now finally, via CDP's, have loaded into basic TRS22. Two of these routes are functioning perfectly in both Drive and Surveyor mode but the third, while eventually performing, is taking in the region of 9 minutes to fully load in TRS22 Surveyoy mode.

The first image to appear is usually the sky followed after an interval by a high percentage of the scenic elements, then by some intermittent rotation of any visible spline points, the gradual appearance of remaining ground details and finally by finally by mouse/cursor/screen movement. I can then proceed as normal.

The two other WIP's will load TRS22 in around 30 seconds which is the same as 22's set routes such as C&O Hinton. All three WIP's are around the same size and have much the same (incomplete) level of of scenic detail and loading, similarly all three are showing a modest number of "unknown assets" from earlier versions( the slow route has 10) but their list of current dependancies are all otherwise showing as being present and fault free.

Running in TRS19, all three routes will load at the 30 second mark. Working from my TRS19 backups, I have now made new CDP's, deleted the original installation and reinstalled into TRS22 three times. I have also completed three EDR's. Still no resolution.

Am running out of ideas - can anyone help?

Many thanks.

John
aka Pitmilly

 

[G.M.]

Hi John
the more files that need to be read and the bigger the route, the longer it takes
also, the first time you open a route it is not cached yet, later it will be faster


My Mainroute NLW7 takes 10min to open, and read from a superfast m2.SSD
its over 5k boards with 45 driving trainz
just get coffee when it loads ;-)

 

[clam1952]

Superfast SSDs or M.2s are not necessarily fast at loading small files and depending on the manufacturer can be very poor however here once everything is cached by Trainz there is not a lot of difference in loading time between an SSD and a 7200RPM spinner once all the assets are cached.

Try this:

Launcher > Trainz Settings > tick Enable advanced debug tools and close launcher.
Launcher > Developer > Run TrainzUtil Command, type prebuild and find something to do for half an hour or so.
When finished start Trainz and see if that has improved the situation? May not if not the problem but worth a try.

 

[pitmilly]

An interesting operation Malc. Have noted it away for future use. Thank you.

Unfortunately, it hasn't resolved the issue - still 8.1/2 minutes. The prebuild operation did however reveal 161 "errors" and issued 1033 "warnings"!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

This has had me trawling through the entire list of Kuids installed - which I'm assuming are those that were placed by the TRS22 program plus additional items from the WIP routes I've brought across. There are a block of kuids - less than 161 - showing Modified - Faulty and - Missing Dependancy status. I've managed to download upgrades for some of the latter but drawn a blank with others. What I can't fathom is that the status of these kuids isn't impacting on the performance of this route, only on the initial loading time and that the problem doesn't exist in TRS19!

Nonetheless, thank you.

John

 

[PC_Ace]

John - Pay attention to the 'errors' and ignore the 'warnings'. Fix as many of the errors as you can and replace those you cannot with substitute assets where possible.
Track down, identify and install/ replace or eliminate any of those 'unknown' assets listed in the dependencies list for your WIP route causing these long loading delays.
The program is spending an inordinate amount of time trying to find these for you before it completes loading.
With your new set-up, did you also adjust your virtual memory/ swapfile settings? Recommend setting this to 3x your physical DDRAM amount for Trainz if you have the spare hard drive space to do this on one or more of your fastest hard drives.
e.g. If 16Gb DDRAM, then 48Gb of virtual memory. This will speed up IO lookups and vastly improve the completion time of any Trainz EDBRs, route merges, loading times and TrainzUtil ops.
Goal is to have zero 'faulty' and/or 'unknown' assets listed in the WIP route's dependencies prior to loading.

 

[clam1952]

Nearly forgot this, check the log for repeated script compile failures, some can go on for ages.

 

[pitmilly]

Thank you Peter and Malc.

Will get back to you if I may - when I've done some deep digging!

John

 

[pitmilly]

Malc, Peter,

A short update,

Now have four WIP's in TRS22. They were all showing faults in TRS22 Content Manager, including a varying number of unknown assets. A significant number of the latter appeared to have been TRANSDEM in origin. I replaced some faulty assets wherever I could find a suitable item and with the remainder, carried out a delete missing assets operation in Route/Default/Surveyor.

All four routes are now showing as complete and fault free in Content Manager and they are all operating perfectly. However, while three of these now " fault free" routes are loading in 30-40 seconds, the fourth - the original "fly in the ointment" - is still taking around 9 minutes to sort itself out. Back to the drawing board.

John

 

[PC_Ace]

Here's a suggestion to track down this recalcitrant object or recursive script:
1. Delete the contents of your cache/internet folder in Userdata
2. Run a quick DBR
4. Clear logs
5. Start up Trainz and navigate to the Routes menu and Select the Really-Slow-to-Load_Route. Do not open this until:
6. From Launcher, choose 'Show Logs' from the Developer Menu. Arrange this on your 2nd Monitor/ screen if available, or set it up as a reasonable-sized viewscreen window on the current screen.
7. Clear logs to empty the Trainz logs viewscreen so that it appears blank in the message pane.
8. Use Alt+Tab to navigate back to the Surveyor Routes Menu with your highlighted problematic route.
9. Click on 'Edit Route' and Alt+Tab back to the logs window to watch the processes and events unfolding in the Show Logs viewscreen.

Observe what appears in red (errors), what is taking an inordinate amount of time to process/ load. Take a note of the KUIDs involved. Remedy in Surveyor once it opens and then try again.

Edit Update: We used the steps above (despite #3 being missing) to troubleshoot this route taking around nine minutes to load.

Then removed the faulty assets causing scripting and stack dump (crashdump.dmp) errors from the route as they were consists placed as scenery items that had been added to the base W.I.P. route instead of to a session.
Did not bother to remove the numerous rulers left lying around the landscape, but the end result was:

Route loading time before: ~8.5 minutes
Route loading time after: "8 seconds flat" (pitmilly)

Then a discussion was had about the dubious wisdom of placing static scenery objects (in this case, parked rolling stock) into a w.i.p. route and of merging the resulting session layers into the route layer.
Sessions and routes need to be kept strictly pure and distinct for best performance and ease of maintenance.
It is easier to isolate errant assets soon after they are introduced to either the route or session so they can be dealt with promptly, without fundamentally affecting other layers and existing development/ progress.