Route Config File- Should I delete old items

[davemare]

I was curious about my TANE custom route configuration file and was scanning through it. It appears to have every asset I have ever opened/saved in the file. As my route evolved many of these assets are no longer used. Should I clean up non used assets in the route config file? What impacts might this have? Also how is the session config file related to the route config file and does it need clean up also? I tried several searches that can up empty thanks Columbia and Western RR Dave

 

[pware]

I could of course be totally wrong, but my experiences with deleting unused asset kuids from the route config.txt file is that it makes no difference. The next time you load the route into Surveyor or Driver, the deleted kuids will be put back into the config.txt file again.

Short answer: leave them be.

 

[JCitron]

Your experiences are correct pware. The config.txt file keeps the assets listed as a way to reference the assets in Content Manager, and it bears no resemblance of what's stored in the route data files.

I went through the exercise of removing old consists listed in a session config.txt file, and nothing happened.

My conclusion:

Leave the file alone it doesn't matter.

 

[davemare]

Thanks- so do I need to clean up content manager

Thanks for the info. If I understand Content Manager is where I should focus. So my next question would be- What should I clean up in Content Manager and how do I do this? based on the amount of objects I have tried and then deleted form my custom route, I begin to sense some clean up is needed? Columbia and Western RR

 

[pware]

Any routes or sessions that you do not want you can delete in CM.

Other assets are more problematic. For example, should you also delete all the installed locos used with a session, or buildings that are used with a route?

These assets may be used by other routes and/or sessions that you already have installed so deleting them will result in "missing dependencies" and you will have to download them again - a waste of time and download charges.

Even if a building is not used by another route that you have installed, it might be used by the next route you download so leaving it on your system will save you the download time and charges.

In short, if an asset is not taking much space or you have plenty of free space to spare, then leave it on your system.

Alternatively, you can archive unused assets and store them offline.

 

[clam1952]

It's not the route that takes up the space, it's the routes dependencies, however as they may well be used by another route or assets, it's not a very good idea to go deleting stuff without at least backing it all up first so you can repair the inevitable damage.
Initially, disabling stuff is far safer, if it doesn't cause a problem with any of the routes or sessions installed then it's probably safe to delete.

 

[JCitron]

Yup the clean-up is a sticky mess to get into. After a messy upgrade a few years ago from TS2010 to TS12, I thought it was time to do a bit of clean up. I spent about a month eliminating stuff that didn't have dependencies and what I though were just collecting data bits on my hard drive as they took up space.

Then I downloaded a route, and a bunch of the deleted content ended up coming back in again.

So much for that exercise!

The problem too with archiving off to CDPs, especially with your own content, is the KUID numbers get out of synch. When we reinstall an older asset with our ID on it, we risk overwriting and replacing another asset because Content Manager, and the underlying TAD (Trainz Asset Database) doesn't look at the KUID being installed and compare that with one that's already installed. There have been more than one case where restoring an older route has resulted in another dependency being obsoleted or replaced.

This is a bug, even if I've been told otherwise, and not a feature. We would think that this kind of thing would be tracked by the TAD and Content Manager. A simple get KUID, compare KUID routine should be there to ensure that data is not inadvertently overwritten.

Should an asset already have the same KUID, then the asset being restored should produce a dialog box to inform us and to offer to update the KUID to the latest one on the system. In the case of routes with sessions, this might be sticky, but it's possible to upgrade those too even manually if needed.

 

[pware]

So my next question would be- What should I clean up in Content Manager and how do I do this?

The short answer: Do this at your own risk

 

[trev999]

... Also how is the session config file related to the route config file and does it need clean up also?

A session config file has a tag: map-kuid that associates the session with its map. Think of the route as a picture and the session as a layer of glass held in front of the picture.

Objects drawn while editing in a route layer are placed in the picture.
Objects drawn while editing in a session layer are placed on the glass.

If you hide the session layer then you only see what's in the picture. This analogy breaks down when the session runs because a train on the session layer is hidden when it enters a tunnel in the picture.

If you edit the route then the game doesn't know which sheet of glass to use so it uses a default one. That may not be the one where you drew your train.
When you edit a session you inform the game which glass sheet (session) to use and your train will be there.

Regarding cleaning up the config files, N3V should provide a facility that does that automatically. It should not be up to the user to remove deleted assets from the file.

Trevor

 

[davemare]

Thanks I am going to leave it alone

Thanks everyone for insight into this area, My conclusion is that I am just going to leave it alone. Not causing a problem. Columbia and Western