Getting an asset to use the latest version of a KUID?

[alexl102]

I've got a lot of content that's showing as having missing dependancies because there are KUIDs specified in the config which have been revised a few times and are now no longer listed on the DLS in their current form - for example, Kuid:12345:678 is specified in the Config, but only Kuid2:12345:678:1 and Kuid2:12345:678:2 are on the DLS. I do know how to alter this in each config file but there are are loads of items which are doing this. It would take me ages to fix it all. Is there any way to make Trainz check for later versions of the asset rather than just looking for that version? Cheers

 

[oknotsen]

To my knowledge, Trainz by default downloads the latest version of an asset.

 

[SailorDan]

I've got a lot of content that's showing as having missing dependancies because there are KUIDs specified in the config which have been revised a few times and are now no longer listed on the DLS in their current form

This is a nasty bug that has never been properly addressed. The system should know, without prompting, that Kuid2:12345:678:1 is the updated version of Kuid:12345:678. That's how KUID versioning is supposed to work. In practice, unless Kuid:12345:678 exists on your system, or has existed at some time in the past, then later versions are not recognised as updates.

A workaround is to clone Kuid2:12345:678:1, edit the config to renumber is as Kuid:12345:678 and import it. This causes the obsoleting table to correctly recognize the obsoleting sequence. You will probably find that you can then delete Kuid:12345:678 - it seems that once the initial KUID entry is in the table it stays there, and subsequent versions are correctly recognised as updates.

There is a need for a DB update routine "Load the obsolete assets reference table with the KUID-1 kuid number for all current assets, if it's not already there".

 

[pware]

I get what you are saying but I am having problems understanding one point ...

This is a nasty bug that has never been properly addressed. The system should know, without prompting, that Kuid2:12345:678:1 is the updated version of Kuid:12345:678. That's how KUID versioning is supposed to work. In practice, unless Kuid:12345:678 exists on your system, or has existed at some time in the past, then later versions are not recognised as updates.

If you have never had Kuid:12345:678 on your system, then Kuid2:12345:678:1 would not be an update, it would be a completely new asset.

 

[SailorDan]

If you have never had Kuid:12345:678 on your system, then Kuid2:12345:678:1 would not be an update, it would be a completely new asset.

That's correct as far as your system is concerned. But the 'update' information that dependants require is more than just your system. The dependants have a reference to Kuid:12345:678. It's that reference that needs to be recognised as part of the update sequence Kuid:12345:678, Kuid2:12345:678:1, Kuid3:12345:678:3 etc. That Kuid:12345:678 has never been on your system ought to be irrelevant, but it seems in practice that it is actually necessary if the obsolete table is going to recognise the full update sequence that stars at Kuid:12345:678.

It's possible that the configuration of Kuid2:12345:678:1 has an impact on that process. Strictly speaking, Kuid2:12345:678:1 is not required to have an obsolete table entry for Kuid:12345:678 - the system should generate that item in the obsolete sequence automatically. But the actual rule used for DLS upload validation has changed significantly, especially over the last 18 months, and that possibly reflects issues in exactly how the full obsolete sequence is generated.

/Edit
... Which just made me think: what is the obsolete table for Kuid2:12345:678:1? If Kuid:12345:678 isn't in the obsolete table, try adding it.
Edit/