View Full Version : Releasing a Route...?

April 9th, 2013, 10:04 AM
Hi guys,

I'm very near completion of a part of a route that I wish to share with everybody, all that's left is registering a domain, designing the website and packing the files for distribution.
Yea, that last part has been abit of a mess during beta-testing. Here is what I've done in CMP: right click Route > List Dependencies > View in Main List > Save to CDP, and repeat same steps for the session.
Some beta-testers reported a couple of missing dependencies, some listed dozens upon dozens, and some run fine right out of the box. All of which is very confusing to be honest, this being my first time releasing something.

Can the more experienced route builders who've completed and released big routes kindly share what you did in the distribution process? I'd have preferred to upload it to the DLS, but during construction many non-DLS assets were used (it was not originally intended for public) so that is out of the question. My goal is to make the installation process for users as seamless and straightforward as possible, through the all-inclusive er..inclusion of every asset used in both Route and Session. These days large file size is not a big concern as most people have high-speed connections and I have access to a server with FTP upload capability.

Manually hunting down every reported missing kuid and reuploading them for every release would be prohibitively time-consuming and unfeasible, so a workaround is needed.

Your advice is much appreciated.


April 9th, 2013, 10:14 AM
I'd have preferred to upload it to the DLS, but during construction many non-DLS assets were used

Then I would recommend releasing it on your own website, not on the dls. Payware or hunting around for foreign assets is a BIG no no.
I for one would look at a list of unknown dependencies & just say "sod it" can't be arsed.

April 9th, 2013, 10:30 AM
Well, if not needed or if they can be substituted, get rid of the 3rdy party stuff.

When giving out my current WIP route for people to test, I first delete all the assets for it, then re-download it. (Even if its not the on the DLS, you can drop a route into the download helper and it will pull all the DLS assets off of there.) Then, after making sure nothing important like ground textures or rolling stock is missing, I go into surveyor and delete all missing assets. Ive found that when uploading to the DLS, even if I only have a few things there, the head aces of having a missing dependency. One of the MRL sessions had a missing locomotive, and I got about 100 messages asking where I could find it, or that the session was bad because of it.

This is just my suggestion though. If your talking about your Cole County route, I highly encourage you do this. Id love to use it, and maybe make an MP session for it. But thats just cause I like MP...

April 9th, 2013, 10:33 AM
You can share it with a few beta testers via dropping the CDP right into the Skype dialg box, or host it on Mediafire, or the likes.

April 9th, 2013, 10:56 AM
You can share it with a few beta testers via dropping the CDP right into the Skype dialg box, or host it on Mediafire, or the likes.

Media Fire works good, its how I pass out my route, and other files needed for my iPortal gang. You can set it so only people with a link can get to the download. Skype works, but can be slow if sending large files. And if one of the people logs out, then the file transfer gets interrupted and canceled. Took about 8 hours to send a 2 gig file via Skype. And both of us where on high speed connections. Took 15 min to upload to Media fire, send the link, then download at the other end.

April 9th, 2013, 12:08 PM
Hi guys,

Thanks for the advice. Transmitting the file is no problem, as I've access to a server that accepts FTP upload and unlimited storage and bandwidth, so it's really easy to share. One beta-tester on fiber got the whole 2GB in less than 10 minutes. What I am most concerned about are missing dependencies. I borrowed my sister's laptop (the only other Windows machine powerful enough to run the route) and dropped the CDPs onto a fresh install of TS12. It seems the problem is not missing dependencies per se, but rather missing dependencies of the dependencies. I don't know how to round these up though, because the asset count is in the thousands.

If it makes life easier for everybody, I also wouldn't mind finding DLS equivalent assets and swapping out 3rd party ones. However because over the years A LOT of non-DLS stuff has accumulated I've absolutely no idea which ones are from the DLS and which ones are not.


April 9th, 2013, 12:29 PM
That's where my method would come in handy. Deleting all the dependencies for the route but not the route it's self will get rid of every thing.Then re-downloading it will get all the DLS only content. Then going in and hitting "Remove Missing Dependencies" will get rid of the reference to the asset in the route. Though it the asset is some thing like signal or building, you might have to manually replace them. I suggest doing this on a clean instal of Trainz, as not to mess up other routes you might have.

April 9th, 2013, 01:33 PM
I've absolutely no idea which ones are from the DLS and which ones are not.Set this filter: "locally modified = true". The assets now listed are either modified by you or downloaded from 3rd party.
Assets you have fixed might be worth replacing by working (DLS?) equivalents if available, so others do not have to re-fix them when getting those.
Assets from 3rd party website which you cant trace back to its origin probably also would need to be replaced as you are usually not allowed to re-distribute those 3rd party items, no matter how good your intentions.

I'll avoid the rest of the discussion for now.

April 9th, 2013, 01:59 PM
There is only one way to absolutely find all 3rd party assets in a route and that is to import the route into a virgin install of Trainz, download the DLS dependencies and see what's left. Locating the remaining asset in your 'working' install is easy and the config will normally give a hint where you found the asset, and importing those to the clean install will in turn lead to the sub-dependencies, and occasionally to the sub-sub-dependencies. If you can't find it again, assume nobody else can either. If your clean install is not eventually free from missing dependencies no-one else's will be either. All of my routes go through this process in Ts10 and TS12, I do 10 and one of my testers does 12, which is kinda cheating because TS10 is much better at DLS dependencies than 12 - TS12 will always return false negatives that need chased down manually from the DLS.

As you import dependencies keep a list of kuids and source links, then either include a readme text doc with the route (which no-one will ever look at!) or publish the list on a web site or in the forum...

April 9th, 2013, 04:17 PM
..... over the years A LOT of non-DLS stuff has accumulated I've absolutely no idea which ones are from the DLS and which ones are not.

NicholasThat's the root of the problem, Nicholas.
As you have unlimited space on which to store the route files, the problem would not exist if all those files could be identified and stored along with the route, making everything - except DLS assets - available from one location.

After only a few weeks back with Trainz I am already finding it a frustrating exercise to find dependencies of dependencies!


April 9th, 2013, 04:37 PM
A list of every kuid and were to find them is help full.

April 10th, 2013, 01:19 AM
All this is why all my layouts use built in stuff ONLY.

April 10th, 2013, 05:10 AM
All this is why all my layouts use built in stuff ONLY.

That works, but then you would've no idea what you're missing out on. Take Samplaire's content for example.

Thanks Andy, that does sound like what would be required. It will be a colossal effort identifying all non-DLS stuff and finding suitable replacements, and perhaps miss the release date, but it doesn't seem like I got a choice. Also explains why many choose to keep their routes to themselves. At this point I am also considering making the route TS10 compatible (in native mode), since what I need to do is almost like completely rebuilding it. Would this be advisable?

Ok I'll rephrase the question; will a "flawless" TS10 route install "flawlessly" into TS12 as well, and/or vice versa? Since I'm going to alot of trouble to replace non-DLS assets, I might as well go the whole nine yards and make it a multiplayer-capable route with the modified assets put on the DLS (again, with permission).


April 10th, 2013, 05:35 AM
All this is why all my layouts use built in stuff ONLY.
Pretty much explains a lot too :hehe:

April 10th, 2013, 04:21 PM
will a "flawless" TS10 route install "flawlessly" into TS12 as well, and/or vice versa? Nicholas

No, and No!

TS 10 contains a lot of legacy built-in content which is not included in TS12. All that content IS on the DLS, accessible only to TS12 users (because nobody else needs it!) but unless it is an undocumented SP1 fix, TS12's CM is notoriously bad at finding it. Expect 'Missing Content' reports, and expect the 'missing' object to be a DLS object that TS12 isn't finding.

On the Vice-Versa, TS12 routes won't install in TS10 without a backwards hack.....

April 10th, 2013, 11:01 PM
No, and No!

Ah, not like the good ole days of 04/06 compatibility huh. Guess I'll stick with TS12 then.
Ok, I've installed the route into a new Trainz install and deleted all the missing dependencies. When rebuilding with DLS-assets, how do I choose (from the object list) which ones were downloaded from the DLS?


April 11th, 2013, 12:05 AM
I can never remember which colour is which, but if you have showkuids turned on (developer settings menu in TS12, trainzoptions entry in earlier version) the kuid number has one colour for built-in, another for DLS assets and a third colour for 3rd party which makes it easy!

April 11th, 2013, 12:16 AM
The only 3 colors I've ever seen (it's -showkuids) of the kuid numbers are white, yellow and red. Never knew what the first two meant but doesn't red indicate a faulty or erroneous asset? Perhaps someone else can chime in on this.

April 11th, 2013, 02:12 AM
Different red! Red up in the menu flyouts means faulty, not to be confused with red down in -showkuids which is part of the BuiltIn/DLS/3Party coding. Pretty sure red is 3Party, but not at my Trainz compuer to check....

April 11th, 2013, 08:17 AM
I wont to know more about your route and less about the problems and so on soo tell us more about your project ?

April 11th, 2013, 08:11 PM
I'd just like to point out that doing a fresh intall of trainz, whatever the version modernity is likely totally unnecessary if you all know WHERE your version is putting files of various kinds. CMP is a database manager and internet interface, not something incorporating pre-rendered data into a compiled object. That is, when we boot into a route or a session, Surveyor or Driver have their own calling routines to suck in data objects (kuid objects) which they then label, attach internal handles, etcetera used 'on the fly' to populate the visible Polygonal Meshes we can see... the most common of which are likely pre-located in the cache and less used organized in the HDD Cache. A 'just one' kuid will likely stay on the HDD until needed on a largish layout. Colors, common cars, trees, etc. will reside in RAM and cache RAM.

Only things we can see, not things off camera are being processed at anyone time. Oh there is simulation software 'timing' and 'operating' whatever the other consists are doing in simulated real time, but no or only a few video mesh operations (e.g. track crossing from one baseboard to the next, requires off camera re-indexing of the 'addressing' of the 'off' locale should you suddenly visit that loco, but until that train enters your visual sight, until it needs a camera view, Trainz isn't likely to be doing graphical rendering.)

To return to the point on topic, simply renaming the given directory something else and substituting an empty substitute folder of the right 'normal' name will and should more than suffice. Running CMP THEN, will flag the assets as missing dependencies... thereby identifying your third party dependencies at the first level... which is the one's we grab inside Surveyor and place on the layout. At the least, that will give you a complete list of things that ARE NOT PART OF CD/DVD boxed assets (those are likely located in the db Cab files, I'm nearly positively certain there is no co-mingling, so the Cab content is expanded in a different folder entirely). Once produced, that list (Screenshot time) can then be further vetted vs the DLS, so you can identify which calls are real 3p assets (3pC) and be culled. You can really expedite this with a second (illegal--but see my bio) PC running a clone of the first... then the screen of one can be used to cull the things on the other...

If your folder is renamed elsewhere, say off C:\ instead of C:\Program Files\Auran\TRS20xx (or whatever) your original data remains unmolested, an you aren't wasting chunks of time overexercising your hard drives, adversely affecting date stamping, nor generating a need to track versions. For that and another reason, I moved all my Trainz into an C:\Auran folder to expedite directory flipping and ease finding stuff I moved for a bit. Do 'that conversion' as a save as before and after weeding out such 3pC when you are ready to rename the folders, create dummies and check, cull your 3pC contents, or keep them. Notice here you should have an indication that some are in DLS available state, so you know others can get them. Making a list to get would be nice though. Add it as a text file inside the route folder before you export it. (Open for Edit should not be necessary, I'm nearly certain 'spare files' in one of my layouts or another have been satisfactorily ignored by CMP.) I don't know whether the db manager checks and inventories when it boots, but it likely does... the loading delays indicate that is so to me. I'm sure we all know it rebuilds if Assets.tdx and .bku are renamed or deleted. Then, it does resurvey and index each data item for certain. (The other day it even sucked in stuff (parts of a layout to merge) I'd deliberately put in a sub-folder to have at a later time when I deliberately killed assets.tdx and .bku and rebooted. I'd forgotten all about them.)

By extension, you can copy an entire layout and or session knowing where Trainz is keeping your layout and Drivers sessions, merely by copying the correct hashcode named folders. Identifying those is easy as well. Search using windows in advanced mode for the most recently changed files in the local (directory) sub-folder. Sort by date modified, and the top or bottom of the list will be files most recently altered. Click and Open Containing Folder, and look in am editor edit to check the 'username=' field is what you actually wanted, then copy once you've got the data directory. (The Date the folder was created may or may not be valid as some clue to find what you want.)

I used this method to move files from one networked computer to the other just three days back. I'd overwritten something in the laptop adding the deluxe content of TRS2004 when I should have told it no... the TRS2006 item was more up to date and so I broke part of it generating a run time error in both Driver and Surveyor. (I've got a handle on it, or at least several things to try to fix it. I'd had hardware issues with the tower, which turned out to be a loose or faulty power cable that needed pushed together. I'd feared I lost several years of Trainz work! So I'll take the mistake over a broken main computer that crashes mysteriously or on which the hard drive [out of the blue] in the next instant 'hard drive cannot be found' error! Whew! I'm glad that's over.)

(I've just begun to think of building a flat data base on a spreadsheet (Open Office) to give me a route/session map to source data. Meaning which hash-code named folder is which route or session. The content should you look is the same folder content you get when 'Open for Edit in Explorer'. I've not tested whether the folder names change, but believe they don't and so are based on a hash of the kuid or username (English) to maintain 'onto' mapping to the db manager.)

In any event, no need to break things and spend time wasted when a few renaming keystrokes and a little basic computer knowledge will suffice. Hope this is helpful to you all.

April 11th, 2013, 09:51 PM
What you say is exactly right for TRS04. In fact back then I had a series of batch files on the desktop which would change the 'World' folder around and delete the corresponding chump files to suit specific routes etc. Pretty sure the original idea came from the DHLR group, but I pinched the idea and expanded it. But back then the world folder was comparatively tiny and the 20 or 30 seconds it took to rebuild the chump was no big thing.

In later versions though you would need to rebuild the data base every time you changed the local folder, plus you'd need to change the 'Original' and probably a couple of others. to NOT rebuild the database every time there's a whole slew of folders and files you'd need to rename every time, and get it exactly right every time.

IMHO easier to just have two installs - a working install and a clean install. Bombproof!

April 11th, 2013, 11:49 PM
The only 3 colors I've ever seen (it's -showkuids) of the kuid numbers are white, yellow and red. Never knew what the first two meant but doesn't red indicate a faulty or erroneous asset? Perhaps someone else can chime in on this.

Different red! Red up in the menu flyouts means faulty, not to be confused with red down in -showkuids which is part of the BuiltIn/DLS/3Party coding. Pretty sure red is 3Party, but not at my Trainz compuer to check....

Yellow = content is built in.
White = content was downloaded from the DLS.
Red = content is neither built-in nor from the DLS.

April 12th, 2013, 12:57 AM
Compared to reloading a fresh trains every time you want to validate and upload a route:(, rebuiding the database is a moderate time sink:D. So let me revise and extend with a step-by-step method per your input. (Looking with a Hex editor, the world folders *.ja files do appear to be pre-processed indexed parts of the data base reflecting content, but not the routes or sessions. They appear to be the Cab, compressed organized compendium of assets in binary form of the distributed release.)

Whether the world folder can contain added & changed content I can't say as I have yet to download a single thing, but the time stamps in my world folder indicate all the *.ja files are part of the initial install and haven't changed since. Pursuing the thought "where the "Deluxe Content" I did add from TRS2004 deluxe's bonus CDROM go", I just checked, and they appear as *.gsl files in the TRS2006\libraries sub-folder, and affected no other directories. Those assets included spines, locos, cars, buildings at the least and I'm not sure what else. Hence, if downloads go there or to world or both, that's what needs 'backed up, blanked, and rebuilt'. Note there are a lot of other .gsl files in the libraries directory, but all have the common date stamp of the build release date as those in ...\world, the exe and so forth. In short they are easy to identify by the version's release common date stamping which won't be changing, whereas any new downloads will have widely varying timestamps.) This suggests to me that when downloading 3pC off the DLS, tracking which files it creates in a list therein (...\libraries\3Pclist.txt) would streamline finding which to hide somewhere later. This means forethought and self-discipline to create that tracking record will save a lot of time over the long haul. It also suggests you can likely eliminate a lot of 3pC content by 'Date Modified' vetting, in which case, I'd rename the libraries directory, and copy JUST THE release date coded ones into the new manually created replacement directory. When done delete the whole thing and rename the libraries directory back to \libraries. Simple. Actually, I can improve on that immediately. After downloading 3pC, move it into a '\Auran\LibraryFilesFrom3pC' directory. Now copy that whole directory into the \libraries directory, when it asks whether to overwrite the first duplicate (old) file, tell it 'Yes to All'. By copy the whole, I mean open each folder, [CTRL]-[A] to select all, [CTRL]-[C] to copy the file names, then paste ([CTRL]-[V] into the open \libraries folder. This will give all 3pC in \libraries the same datestamp making it easy to find them and either move or just delete them when needed ( s.a. for this task going forward).

[Having just written the last part of the above while proof reading all this, I'm not at all sure we need the below, given the date stamping in \libraries clearly indicate which are originals. But since it's done, I'll post it in case I'm misfiguring this.]

Recalling the mission, finding what 3pC kuid's are polluting a route we want to upload and share on the DLS... so the first step is to identify what 3pC is NOT on the DLS... so we want a naked stock virgin database as a testing tool. Hence:

1) You want to have a clean install to work with, so need to reload Trainz just one more time. Note changing your trains directory name (e.g. ...\Auran\TRS2006 renamed ...\Auran\TRS2006full) gives you a missing Trainz and safeguards important things like Assets.tdx and so forth. Renaming it effectively deletes it, as the registry has whatever path name it was installed under (unless you changed it like I did when I moved C:\Program Files\Aurans to C:\Aurans, requiring five or six pathname edits in regedit.exe, iirc), you can now safely reinstall it under the same (old) pathname.

[Also note, you can rename the exe files and the path and actually have two runable copies by using regedit to make matching changes before you install and use the old appropriately modified and clearly named shortcuts. In this motif, you need to preserve but modify the data/path in the registry Hkeys, not break them (renaming the directory does that). I'd FIND the exe name, and add the 'a' suffix (e.g. TRS2006.exe becomes TRS2006a.exe) everywhere, including in Hkey fields... Hence TRS20xxa.exe is or could be the dirty current directory and executables, the new install we're about to make in TRS20xx using the standard named TRS20xx.exe. Before leaving regedit, return to the top and search ([CTRL]-[F]) just the name of the exe file without the '.exe' and add the 'a' suffix to any Hkey field which has just that short name. There should be at least one. This technique would use double the disk space and duplicate everything but one version would be naked Trainz and the other extended Trainz where you do your main creation and work and downloads. What you loose in HDD you gain in saved time. Further, any of the exe file references in the registry you might have missed renaming will also work, even if they call an executable--the same file is in the other directory and your RAM doesn't know where it came from, nor care. Want to test for 3pC, drag or copy the route and session over into the naked trainz\local subfolder then rebuild it's two assets.* files. Just don't try and run both copies at once! Also, make sure to modify your shortcuts and rename them before the install of a new naked Trainz. I'd test it all runs before reloading a naked Trainz.]

Resuming the folder renaming method (without editing the registry)...
2) Reload Trainz in the same path as before (...\Auran\TRS2006 or whatever). [We now have a clean or Naked Trainz, and the old Trainz in a renamed directory.]

3) Now back up the new 'virgin' world and Libraries folder contents to the Auran root as well (...\Auran\world_No_3pC, ...\Auran\libraries-naked). Since I'd want to also allow 3pC that is available on DLS, I'd copy the later to ...\Auran_No_3pC as well.

4) Copy your route and sessions into the \local folder.

5) rename Assets.tdx and cache\Assets.bku or delete them. (e.g. You just rename assets.tdx and assets.bku to assets.good.tdx and assets.good.bku to restore later. The Windows hotkey sequence to rename things quickly are [CTRL]-[F]-[M].)

6) Launch trainz, let it rebuild, then look at missing dependencies... this is the list of things not part of the distributed base Trainz version you are running.

As someone mentioned just above, colors will identify which are available on the DLS and so can be kept on the route.
The rest are the target we set out to identify and eliminate as being user unfriendly to others. :hehe:

7) Copy the list (Screenshot) or make text notes of the missing kuids.

8) Now you copy back your original directory content into the newly reinstalled directories (unnecessary if you did the two runable copies method), and get back to your fully loaded CMP.

9) Using the screenshot and/or hand or notepad list, find what the kuids are and figure out how to eliminate them from your layout. :hehe:

10) Finish the upload, and get back to more entertaining Trainzing.

Feel free to drop me an email if you need further clarification or have registry editor questions or whatever. Fabartus at gmail dot com.

April 12th, 2013, 08:23 AM
Compared to reloading a fresh trains every time you want to validate and upload a route
G'day, pretty easy really, install trainz from disc or downloaded file, patch to your desired build and then make a back up copy.
Do your testing or whatever then when you are finished delete it and copy your backup in it's place. Bingo fresh install is back, too easy.

April 12th, 2013, 09:33 AM
I don't even do that: CM > Built-In=False > Crtrl+A > Del. Takes about a minute!