Trials and tribulations of a route upgrader

[MSGSapper]

I am currently in the process of upgrading and expanding my TRS19 New England Coastal (NEC) route in TRS2022 (Build 123794) to TRS22 standards. As part of the process, I checked my route dependency list for the category of ground textures and found that 71 of them were not PBR, so I decided to replace them to ensure that all textures used on the route are PBR ones.

I used the Bulk Asset Update/Replace utility in Surveyor Classic to laboriously replace each ground texture one-at-a-time with a similar but PBR based one. About every 8-10 tries the Bulk Asset Update/Replace utility would totally lock up Trainz with no way to shut down and get out of Trainz. I was only able to recover by going to my Windows 11 Task Manager and shutting down the TRS22 process. Aggravating to say the least!

After finally finishing the replacement of all 71 of the ground textures I went to my route dependency list and found that all 71 of the ground textures were still listed as dependencies of the NEC!

If they have been replaced, then why are they still listed? I also found no way to purge them from the route.

Questions:

1. Is there any way to purge these textures from the dependency list?

2. Are people who download and run my NEC route going to be required to download these replaced textures simply because they are on the route dependency list even though I replaced them?

3. If they are still listed in the dependency list how can anyone, including myself, tell if that texture is truly in use or has been replaced by a PBR texture?

Bob

 

[JCitron]

I used the Bulk Asset Update/Replace utility in Surveyor Classic to laboriously replace each ground texture one-at-a-time with a similar but PBR based one. About every 8-10 tries the Bulk Asset Update/Replace utility would totally lock up Trainz with no way to shut down and get out of Trainz. I was only able to recover by going to my Windows 11 Task Manager and shutting down the TRS22 process. Aggravating to say the least!

Please report this to the QA Team. During the beta and the previous version, I reported this and I was told it had to do with something on my route.

You can remove textures and then run Delete Missing assets but you'll then have to manually replace the textures again from scratch. Deleting the assets listed in the config.txt file does nothing since this is only for reference. The actual textures and other objects are tracked inside data files associated with your route.

When running the bugged DLM, I do this:

Save prior to doing anything.

Close Trainz completely including the Launcher.

Start up again and edit the route.
Run the DLM utility on a single texture and do not touch anything while that texture is replacing.

Given how it is, this process is really, really slow and the progress is really, really slow.

Once the texture is replaced, SAVE!

If you want, try a second texture but I got cold feet and I closed everything out prior to replacing textures again.

If it works a second time, SAVE, exit and repeat. Don't try your luck for a third time.

Here's the Bug Report.

Trainz Bug Report

Turn data collection into an experience with Typeform. Create beautiful online forms, surveys, quizzes, and so much more. Try it for FREE.

n3vgames.typeform.com

 

[MSGSapper]

You can remove textures and then run Delete Missing assets but you'll then have to manually replace the textures again from scratch. Deleting the assets listed in the config.txt file does nothing since this is only for reference. The actual textures and other objects are tracked inside data files associated with your route.

When running the bugged DLM, I do this:

Save prior to doing anything.

Close Trainz completely including the Launcher.

Start up again and edit the route.
Run the DLM utility on a single texture and do not touch anything while that texture is replacing.

Given how it is, this process is really, really slow and the progress is really, really slow.

Once the texture is replaced, SAVE!

If you want, try a second texture but I got cold feet and I closed everything out prior to replacing textures again.

If it works a second time, SAVE, exit and repeat. Don't try your luck for a third time.

Thanks for the reply!

Because of the fairly frequent crashes/lock-ups I learned to save the route after every successful bulk replacement operation.

I thought of deleting the textures but there are two problems with this approach:

1. Other routes I have in Trainz are probably using them. I would first have to run a search on each texture to see what is using it before I could delete it. That would be very tedious with a lot of textures.

2. In CM only the ones shown as "Installed from DLS" or my own textures can be deleted. Items shown as "built-in" or "Packaged" cannot be deleted.

My approach, as I elaborate in my OP was to replace the textures with another. You would think this would do the trick but while the texture is replaced on the route map itself, the old texctures still shows up as a dependency of the route.

Any insights/answerts to my questions #2 and #3 in my OP?

BTW I did submit the bug report.

Bob

 

[Forester1]

I am curious from other threads whether you could disable the unwanted textures in CM, then edit the route and use "Delete missing assets". In other threads people have used this to get rid of unwanted items, as disabling the asset makes it "missing" from the route. After they are gone from the route you could go back to CM and enable the assets again.

 

[philskene]

Bob --

This has also happened to me in the past. One workaround I used was to delete the old textures in Content Manager if they were from the DLS and disable them if they were built-in. Then in Surveyor use Delete Missing Assets. Remember to reactive the built-ins.

Phil

 

[dangavel]

I've had quite a few issues with items that will not delete in later versions of trainz, it certainly isn't the easiest of tasks to ensure a route will have no missing assets on the DLS with these bugs in the software.

 

[JCitron]

To answer the other two points I blindly missed,

2) No, if you replaced the textures with something else, then the new textures should, note the word should, override the dependencies. If you are concerned, run the Delete Missing Assets and that will clear that up or should anyway.

2) This is correct behavior for packaged and built-in. You can't delete these and can only be deactivated.

3) And no, the textures should be removed as I said.

 

[pware]

1. Is there any way to purge these textures from the dependency list?

What I have found to work in those situations is to use Content Manger to Disable (not delete) the assets that you want to remove from the route. Then, after loading the route into Surveyor, run the "Delete Missing Assets" option and save. Return to CM and Enable all the Disabled assets so they will not be listed as Missing assets in other routes.

 

[MSGSapper]

Thanks everyone for your replies and help!

The consenus from the various comments was that you had to disable the packaged items and then run the Delete Missing Assets function from the Surveyor Edit for the route. I tried this but got mixed results and found I had to do this multiple times.

My first run of the Delete Missing Assets function results in this image:

I then checked the dependencies list for textures and got this result:

As you can see the many of the assets that were disabled are still showing up as dependencies.

I then ran the same procedure over again a few more times and finally narrowed it down to this in CM:

The results show that a single run of this procedure apparently is not enough to get rid of the disabled assets. Why this needs to be done multiple times is something I do not understand as Trainz is reporting that the assets were deleted.

In the final image, as you can see, it got rid of many of the texture items but not all, despite running this several times. It is much better then before so I guess I will have to settle for what victory I can get here.

What Trainz really needs is a purge function to go through the route assets and see what is and is not being used and then eliminating any reference to those assets not being used.

Bob

 

[CaseyBerg]

What Trainz really needs is a purge function to go through the route assets and see what is and is not being used and then eliminating any reference to those assets not being used.

Bob

Agree with the purge function. Especially useful for folks who only work on and run their own route.
casey

 

[JCitron]

You can test this by setting up a fresh database and installing your route in that without the DLC just like another user. If you see the packages listed as missing dependencies, then you'll definitely know this doesn't work as we thought it would. If you do decide to do this, let us know how things go.

 

[MSGSapper]

You can test this by setting up a fresh database and installing your route in that without the DLC just like another user. If you see the packages listed as missing dependencies, then you'll definitely know this doesn't work as we thought it would. If you do decide to do this, let us know how things go.

While an interesting idea, I think I'll stay with what I have. At least I got the list of texture dependencies down to just a few now. This is a route I have been spending most of the winter upgrading and expanding and don't want to risk messing it up any more then I may have already.

Thanks for your help on this!

Bob

 

[Cayden]

Replacing textures when upgrading my route to PBR textures was a real chore. Took me weeks. What I ended up doing was to concentrate on the baseboards close to the track, that is, the ones through which the track crossed. As I came to each one, I would add two or three textures that were not part of the route. If adding the second or third texture caused the first one to disappear then I knew I had a problem with that baseboard containing more than 16 textures.

I would make a copy of the baseboard which placed it in the scrapbook. I then closed the file, opened a new Trainz route, to which I had removed the grass, pasted textures in and save the route. Then in Content Manager I would open the new route and look at the dependencies. I usually had several Colorado Rocky Hillside and Colorado Water textures I could do without. I temporarily deleted them then reopened my route. From high above, I painted the blue spots with a grass texture that was a dependency of my route (PBR Foliage 3 <kuid2:661281:85093:4>) then went in and replace it with an appropriate texture.

Sounds frustrating. It was, but I got the job done. What puzzled me is that if N3V could replace a texture with an individual (default green grass) texture why couldn’t they have built that capability into Surveyor 2 so that creators could selectively replace individual textures.

Cayden

 

[pware]

What puzzled me is that if N3V could replace a texture with an individual (default green grass) texture why couldn’t they have built that capability into Surveyor 2 so that creators could selectively replace individual textures.

There is a big difference between adding a new baseboard with a default texture, be it green grass or the standard grid pattern (which is a PBR texture), and replacing an existing texture throughout a route. I have successfully used the Surveyor Classic Bulk Update/Replace Asset tool to replace all the non-PBR textures in an old route with PBR textures one texture at a time. But it was a 10m grid resolution route, not a HD route and that may be the difference with your experience. It would be great if that tool could be added to Surveyor 2.0 but in the meantime it is no great inconvenience to switch between S2.0 and S1.0.

 

[FootplatePhil]

:
:
:
The results show that a single run of this procedure apparently is not enough to get rid of the disabled assets. Why this needs to be done multiple times is something I do not understand as Trainz is reporting that the assets were deleted.

In the final image, as you can see, it got rid of many of the texture items but not all, despite running this several times. It is much better then before so I guess I will have to settle for what victory I can get here.

What Trainz really needs is a purge function to go through the route assets and see what is and is not being used and then eliminating any reference to those assets not being used.

Bob

You experience matches mine. I too found that after disabling the old (replaced) textures in Content Manager I had to run multiple Passes of the 'Delete Missing Assets Tool' to remove them as dependencies in the route. I eventually got rid of all of them (seems I was fortunate).

 

[Lewiscc65]

This is just a thought, and I have done it also. For some reason, it seems content manager list the dependents of a, route or session, from the config file listing. So, I have deleted all of the kuids from the kuid-table in the config file. I then listed the dependencies in the Content Manager, and nothing showed. But when I open the route, everything was there. I made a change, moved a tree, and saved it. Then I listed the dependencies in the Content Manager again and it listed the right stuff. I would make a backup CDP first just in case.

 

[pware]

For some reason, it seems content manager list the dependents of a, route or session, from the config file listing.

Not actually. For routes (and possibly sessions as well but I have never tested that) the <kuid-table> in the config.txt file is built from the data stored in the map files and other files in the asset.

So, I have deleted all of the kuids from the kuid-table in the config file. I then listed the dependencies in the Content Manager, and nothing showed. But when I open the route, everything was there.

When you reload the route Trainz rebuilds the contents of the <kuid-table> from the map (and other data) files. The <kuid-table> is basically a quick way for CM to list the dependencies of the route without having to search through all the data files (again).

For my experience it is best not to mess with the <kuid-table>. In the past some users have had the idea that you could get rid of missing dependencies by deleting them from the <kuid-table> only to discover that they always reappear back in the table when the route is reloaded.

 

[JCitron]

I did this a year ago with a session, after backing it up of course, with no ill effects. The config.txt showed many, many unused consists that had been placed, sometimes during tests, and long deleted. After clearing the config.txt, the session loaded fine and the config.txt was updated and reflected the current consists I had on the route.