Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
KUIDs ending with 127
- Thread starter hholdenaz
- Start date
Many missing KUIDs have :127 at the end, even though it doesn't exist, with a few exceptions.
IF the :127 version of an asset doesn't exist, then why is the :127 still shown in configurations? It just doesn't make sense to me.
The :127 suffix arrived when the kuid2 prefix arrived, somewhere about TRS2006 or TS2009 I think. It was caused as far as I know by items being uploaded with a kuid2 prefix and either a zero suffix or no suffix. The :127 suffix was automatically assigned and was the highest suffix possible which meant the item could not be updated any further.
Bill69
If you search for an asset with a kuid2 naming convention but with no version numbers then it will show a 127 version.
For example <kuid2:186372:8004> will come up as: unknown asset <kuid2:186372:8004:127>.
So, it's possible that the author has incorrectly typed a dependency in that fashion and the new TANE validation is throwing it up as an error.
Such assets will probably end up on the CRG faulty assets queue. If you want to fix them locally, and some version of that asset exists on the DLS, then you could update the kuid-table, and any other config tags that quote that asset, to the latest version available.
For example <kuid2:186372:8004> will come up as: unknown asset <kuid2:186372:8004:127>.
So, it's possible that the author has incorrectly typed a dependency in that fashion and the new TANE validation is throwing it up as an error.
Such assets will probably end up on the CRG faulty assets queue. If you want to fix them locally, and some version of that asset exists on the DLS, then you could update the kuid-table, and any other config tags that quote that asset, to the latest version available.
If you search for an asset with a kuid2 naming convention but with no version numbers then it will show a 127 version.
For example <kuid2:186372:8004> will come up as: unknown asset <kuid2:186372:8004:127>.
So, it's possible that the author has incorrectly typed a dependency in that fashion and the new TANE validation is throwing it up as an error.
Such assets will probably end up on the CRG faulty assets queue. If you want to fix them locally, and some version of that asset exists on the DLS, then you could update the kuid-table, and any other config tags that quote that asset, to the latest version available.
Only problem is that once you save a new route after replacing the dependencies with the correct versions the cloned route somehow goes back to the versions originally in the KUID table. I'd appreciate any knowledge on how to fix that issue.
Only problem is that once you save a new route after replacing the dependencies with the correct versions the cloned route somehow goes back to the versions originally in the KUID table. I'd appreciate any knowledge on how to fix that issue.
I didn't realise you were talking about routes and I don't know how routes create and update their configs. Is this in TANE and, if so, what version and what route? Or is it one of your own?
If there is a reproducible issue then I can take it up in TrainzDev.
Once you have saved a route that references an asset with a badly configured KUID, then there is no way of forcing it to change back. All you can do is fix the asset (eg, delete the asset that has the wrong KUID), delete missing assets from the route, and manually add the corrected asset back into the route at the correct location.Only problem is that once you save a new route after replacing the dependencies with the correct versions the cloned route somehow goes back to the versions originally in the KUID table.
Or, go back to an earlier version of the route.
stagecoach
75377
All ive ever done is open the asset and delete the 27, leaving just the 1. Any new update will then come into play.
All ive ever done is open the asset and delete the 27, leaving just the 1. Any new update will then come into play.
That works for me too. Until I make a new version of a route: then the KUIDs somehow get revised to the recipes version and image to restart all over again. It would be possible to delete the missing assets and replace them IF o could remember where they were.
stagecoach
75377
Did you do a data repair before you made a new version? or delete missing assets.
Did you do a data repair before you made a new version? or delete missing assets.
I apologize for the late reply.
Anyway, I did try that but at least in TANE once the route is saved the originals are still listed even though they should be different in the config.
Here are the KUIDs in question i'm referring to:
<kuid2:116296:16103:127>
<kuid2:116296:16106:127>
<kuid2:116296:16108:127>
<kuid2:116296:16109:127>
Would it be possible to replace them even though I can't find where they are located?
I wonder how you got those or what they ended up as a dependency off.<kuid2:116296:16103:127>
<kuid2:116296:16106:127>
<kuid2:116296:16108:127>
<kuid2:116296:16109:127>
Do you have a KUID (located on the DLS) that has those assets listed as a dependency?
I just checked my CM and those assets don't exist (as you obviously found out yourself). Those that exist are:
<kuid:116296:16103> sign halt at junction
<kuid2:116296:16103:1> sign halt at junction
<kuid:116296:16106> sign road junction
<kuid2:116296:16106:1> sign road junction
<kuid:116296:16108> sign major road ahead
<kuid2:116296:16108:1> sign major road ahead
<kuid:116296:16109> sign low bridge
<kuid2:116296:16109:1> sign low bridge
I have not read up on the whole topic, so maybe I am misinterpretating the problem.
If you saved the route when the route believed it needed those assets, then they became permanently embedded in the route and you can't get the route to automatically update them to a newer version. You have to delete them from the route, save, and re-insert.Anyway, I did try that but at least in TANE once the route is saved the originals are still listed even though they should be different in the config.
Replacing can be done if you know what asset types these should be. But replacing with a different type( a spline with a scenery item, for instance ) can cause problems. If you create new assets with these KUIDS (eg, by cloning then editing anything suitable) you can see where they should go, and replace the clones with any other asset.Would it be possible to replace them even though I can't find where they are located?
Replacing can be done if you know what asset types these should be. But replacing with a different type( a spline with a scenery item, for instance ) can cause problems. If you create new assets with these KUIDS (eg, by cloning then editing anything suitable) you can see where they should go, and replace the clones with any other asset.
Just want clarification: you do mean in the game using bulk asset replacement, right?
Just want clarification: you do mean in the game using bulk asset replacement, right?
Once you have a working asset for those numbers, then you can use bulk replace, or remove and replace in surveyor, or just remove.
Similar threads
- Replies
- 5
- Views
- 806