Constantly validating obsolete packaged assets is getting a bit old!

[JCitron]

What gives?

Whenever I start up TRS-Plus, I have to wait, sometimes for an hour or more before I can use the program. I usually end up doing something else and closing the program when the main menu appears because I've lost interest.

Here's a couple of the assets.

? <kuid2:502415:100566:5> : Validating <kuid2:502415:100566:5>
! <kuid2:502415:100566:5> : Skipping validation as asset is locally obsolete.
? <kuid:-25:1534> : Validating <kuid:-25:1534>
! <kuid:-25:1534> : Skipping validation as asset is locally obsolete.

These are the same obsolete packages over and over again among the gazillion others. The question is why is it the same assets every time?

I have performed an EDR, which then validated and precached content afterwards for 26 hours completely tying up my computer and preventing me from doing anything else and the problem still exists.

I reinstalled all packages which took a couple of days because the download is horribly slow and we can't do more than a few at a time.

The other issue is this doesn't just end when the menu becomes accessible. Entering into a route starts the validation process all over again and to make matters worse this impacts moving around in Surveyor making it difficult to check for performance problems because this process is constantly running in the background.

When I finally did use the program the other day, I had some decent performance after I enabled the resizablebar setting in my BIOS and NVidia Control Panel. This however is something else because the disk was still chattering away and running at 100% utilization, causing menus and content to load slowly in Surveyor.

I have a feeling that this has been going on for some time and I feel it more because I use old-fashioned spinning rust instead of an SSD. Given the amount of disk access, I'm glad I don't have an SSD because the constant writes would kill the storage device in a short time.

In some ways, this reminds me of the old TADDaemon validation in TS12 that would spend about 40 seconds per asset and tie up the system for hours as it pushed the CPU and disks to 100%. The difference this time is the CPU isn't impacted at all and it's only the disk.

 

[pcas1986]

I'm assuming that validated assets get marked in some way so Trainz can ignore them next time around. Perhaps obsoleted assets should be similarly marked. While outputting those messages to the log can be useful I suppose, it also chews up processing time and it all adds up. Especially if it is writing to a file on disk because such I/O is mega slow. You might turn off the logging options in settings unless you particularly need them.

I've learned not to attempt any script debugging while this validation is occurring as the log quickly overflows and my debug messages end up in the bit bucket.

 

[wreeder]

I am running the current beta and I don't see the problem. My setup is similar as I too use a spinning HD for both program install and local data storage but my copy pops up quickly to the main menu and then when I choose KSC 2 and my TLR test session either surveyor opens to fully ready to use in less than a minute. I experience no lags or slowness when using surveyor or driver. Now I have only an handful of DLC installed in this copy as it is for testing only but my stable copy of Trainz Plus with more packaged content performs without issue as well. The main difference between us is I am still running Win 7.

Are you sure what you are seeing is not due to the 100% disk usage bug that is common in Win 10 and perhaps in Win 11 too?

 

[JCitron]

I'm assuming that validated assets get marked in some way so Trainz can ignore them next time around. Perhaps obsoleted assets should be similarly marked. While outputting those messages to the log can be useful I suppose, it also chews up processing time and it all adds up. Especially if it is writing to a file on disk because such I/O is mega slow. You might turn off the logging options in settings unless you particularly need them.

I've learned not to attempt any script debugging while this validation is occurring as the log quickly overflows and my debug messages end up in the bit bucket.

I agree. Assets should be marked as validated so it isn't necessary to check the same assets again and again. This is true for DLS and third-party content but not for assets that are packaged which makes me think this is a bug.

The messages in the log are the general messages and not anything I've selected. I don't enable any kind of message logging in my released version because I'm not checking content. These are messages that show Trainz start up, server authorization, etc., and the content validation. This constant chatter in the background definitely impacts performance as the log is constantly updated.

If the log is opened while in Surveyor, it clearly shows packaged obsolete assets being validated every time the camera is rotated or moved. In Driver, this is worse because it takes time for the content to load into the scene, although I did mitigate this a lot by enabling the resizablebar option. If the profiler is loaded, there's a visible drop in framerates until the train or movement is stopped. After pausing or stopping, the framerates are back up to where they were previously like a tank is being filled with fuel, then they drop off considerably as the train moves in Driver or the camera is moved around in Surveyor.

 

[JCitron]

I am running the current beta and I don't see the problem. My setup is similar as I too use a spinning HD for both program install and local data storage but my copy pops up quickly to the main menu and then when I choose KSC 2 and my TLR test session either surveyor opens to fully ready to use in less than a minute. I experience no lags or slowness when using surveyor or driver. Now I have only an handful of DLC installed in this copy as it is for testing only but my stable copy of Trainz Plus with more packaged content performs without issue as well. The main difference between us is I am still running Win 7.

Are you sure what you are seeing is not due to the 100% disk usage bug that is common in Win 10 and perhaps in Win 11 too?

Why does this only affect TRS-Plus and no other programs? Is it because of the high I/O usage by the program? TRS19 doesn't have his issue and my test version PE does have this. I think it's a program issue, or maybe it's a package issue with some assets for some reason are nerfed causing the problem.

User @skittlekicks noticed a similar I/O problem in Linux which to me says it's not the OS.

 

[ApproachMedium]

I think this occurs with Trainz Plus if you've installed DLC and have removed it. Sometimes DLC dependencies will have higher kuids than a previous version (built in or DLS). This isn't always the case but I think the game is scanning to validate those types of assets. Depending on the dependency, the tag for that asset may end up changing from something like "payware, active" to "payware, inactive" or "packaged" etc.

I could be entirely wrong on this but that's been my experience. It's also why I keep a totally clean content folder with no DLC or packaged assets (Kickstarter is all I have installed).

Hope that helps.

 

[JCitron]

I think this occurs with Trainz Plus if you've installed DLC and have removed it. Sometimes DLC dependencies will have higher kuids than a previous version (built in or DLS). This isn't always the case but I think the game is scanning to validate those types of assets. Depending on the dependency, the tag for that asset may end up changing from something like "payware, active" to "payware, inactive" or "packaged" etc.

I could be entirely wrong on this but that's been my experience. It's also why I keep a totally clean content folder with no DLC or packaged assets (Kickstarter is all I have installed).

Hope that helps.

I have all the DLC installed in this particular installation and nothing has been removed. The problem is some routes I've built over the years now have DLC content because that has replaced the original assets with the packaged ones.

That's good point and it makes me wonder if you have the same issue but at a smaller scale and recover a lot faster because of the fewer packaged assets. I need to experiment with this by setting up a new test install with only a few packages. It won't hurt. This may end up as a bug report. I usually find the "good ones".