the curse of packaged routes.

[rwk]

I had TUME assets like that where they say Payware, Inactive. People use payware assets in their routes not realizing that the downloader might have to buy payware routes to get those assets. There's a bunch by RoysTrainz as well. Probably in his payware Canadian routes by N3V.

 

[JCitron]

I had TUME assets like that where they say Payware, Inactive. People use payware assets in their routes not realizing that the downloader might have to buy payware routes to get those assets. There's a bunch by RoysTrainz as well. Probably in his payware Canadian routes by N3V.

That's exactly where they came from.

To help find out where the assets come from, turn on Show KUIDs in the 3-bar settings menu while in Surveyor or at the Routes menu. This will display the KUID of each asset you select in the list. Assets that are built-in or DLC will be yellow while others will be red and blue. I can't remember what the other colors mean and only remember yellow being built-in or DLC.

 

[Paulsw2]

I have a lot of sympathy with this thread! I've just installed TRS22PE and I've just spent days trying to track down all the packages and dealing with 'missing dependencies' errors. A problem is that they package and increment the kuid and then count it as payware. So now the version from the DLS shows as 'obsolete' and meanwhile your route is searching in vain for the most recent version. I've had to physically revise some routes' config files to add the lower kuid number for the DLS version. So all quite messy.

Paul

 

[frogpipe]

I've been thinking a lot of hair pulling might be avoided if surveyor used the root Kuid instead of the literal one. And then CM grabbed the latest it could find.

So route calls for KUID:123:456, and CM grabs KUID2:123:456:X

If a route builder used 123:456:4 and that was payware, but 123:456:3 was on the DLS, the game would use :3 and be happy, no?

 

[pware]

If a route builder used 123:456:4 and that was payware, but 123:456:3 was on the DLS, the game would use :3 and be happy, no?

That is what is supposed to happen and, in my experience, usually does.

From the Wiki at Understanding Content Manager Status Labels#Using Packaged Assets in Routes Uploaded to the DLS

In the examples shown below, an updated asset, <kuid2:33404:501440:4>, is installed from a DLC package in one copy of Trainz (shown on the left). An earlier version of the same asset also exists, <kuid2:33404:501440:3>, as Installed from DLS in a different copy of Trainz (shown on the right). The updated version has not been uploaded to the DLS so there is no Newer version available status label.

Computer 1 Computer 2

The updated asset is then used in a route and uploaded to the DLS. If that route is then installed in a copy of Trainz that does not have the packaged update, then:- if an earlier version (:3 in this case) has been installed then it will be used instead of the update (:4) and no missing dependency or <unknown asset> messages will appear on the new route if an earlier version of the asset is NOT installed, then the latest Available for download version (:3) can be downloaded and installed from the DLS. This will occur automatically if the route was installed directly from the DLS, or manually if it was imported from another source. In both cases the missing dependency and <unknown asset> messages will not appear after the :3 asset version has been installed if there is NO Earlier version available from the DLS then the installed route will be labelled as having a missing dependency and the asset will be labelled as an <unknown asset>

 

[JCitron]

This is how it's supposed to work but as I said it does not when you've installed a route from another source outside of the DLS that references a dependency that has an earlier version than the one installed.

 

[frogpipe]

Which explains why I thought it always happens, I don't buy routes thru N3V, or haven't in ages.

 

[pware]

This is how it's supposed to work but as I said it does not when you've installed a route from another source outside of the DLS that references a dependency that has an earlier version than the one installed.

That, plus the endless hunt for missing assets (which can happen with the DLS but, in my experience at least, not as frequently) is why I only download assets from the DLS and DLC. My opinion.

 

[java23]

Hi guys,

From my point of view, the config.txt of a map should reference only root kuid's without any versionned "kuid2" ones .
I find it most irritating the fact that :
- if the map references an older version of a kuid, the Content Manager is clever enough to download the most recent one,
but ...
- if the map references a newer version of a kuid (not available), the Content Manager is MORE THAN ENOUGH STUPID to NOT download a less recent one !!!

This irritates me as hell ! Why reference a special version of a kuid in a map's config ? Just reference the root kuid ! Full stop !

I am in the process of releasing a map to the DLS : I have rooted down ALL the kuid list in the config file !!!

Cheers,

Philippe

 

[johnarran]

My father's favourite saying was "Son, you can't polish a turd!"

 

[JCitron]

That, plus the endless hunt for missing assets (which can happen with the DLS but, in my experience at least, not as frequently) is why I only download assets from the DLS and DLC. My opinion.

I agree, it doesn't happen often with the DLS but when it does happen it's nearly impossible to fix without going through hoops. My latest annoyance was a route with a DLC version older than the one that is on the DLS with a higher build-number, but for some reason my route would not see the one on the DLS and went for the DLC version instead. No matter how many DBRs, EDBRs, or cache-clearing moves were performed, did that asset mess clear itself up. I ended up cloning the one on the DLS by downloading it into another version, faffing with the version number and installing the asset into my current setup.

It's not that this asset was important or not, it was a matter of principle that I had a missing dependency that wasn't a missing dependency previous and was when I installed the route.

 

[rwk]

And sometimes you get missing assets when importing a route into a newer Trainz version because the route used a couple of built in assets that aren’t in the new version and if you import them as cdps they have texture errors that the pev tool can’t fix.

 

[JCitron]

And sometimes you get missing assets when importing a route into a newer Trainz version because the route used a couple of built in assets that aren’t in the new version and if you import them as cdps they have texture errors that the pev tool can’t fix.

Yup. I've run into that too. Like a lot of things, this wasn't thought completely through before implementing anything.

 

[hutten]

Hello,

The point made by dangavel, who started this thread, is that it is the user of the routes that gets frustrated. Frustrated because he/she has to download one or probably several routes and hundreds of assets that he/she will never use. I have complained about it earlier, years ago, and some of the reactions were: "disk space does not cost much". Sorry, that is not the point.
It would be very helpful if one could at least see what the asset is, so that one can decide whether it is worth going after it.
But I simply think that one should have access to an asset if one is entitled to have access to the route that contains it, because of a purchase. Technically complicated or impossible?

Regards,
Paul