Asset versions reaching 127!

Downloading UMR-2018 and others and suddenly a lot of 'unknown location' assets all ending in 127.

Does anyone know why we are suddenly besieged by assets that, possibly, do not exist?

CoachMan888 said:

Downloading UMR-2018 and others and suddenly a lot of 'unknown location' assets all ending in 127.

Does anyone know why we are suddenly besieged by assets that, possibly, do not exist?

Click to expand...

Some kind of bug that has popped up a few times, try a Database repair?

clam1952 said:

Some kind of bug that has popped up a few times, try a Database repair?

Click to expand...

Yes, what I do is highlight all the version 127 assets, list asset versions, download the available assets then data base repair and all the 127 versions disappear.

An alternative method is too open for edit the asset calling for the 127 assets and edit in AssetX. AssetX will not show a 127 asset if the kuid list is not calling for it. Save is AssetX and submit the edit.

Just a bit of a time-consuming nuisance especially the DB repair.

Thank you for the reply.

I don't think that it is a bug. The "Unknown Location" status simply means that the asset has been superseded by a newer version (i.e. updated) but that specific asset (the one that was updated) was never uploaded to the DLS.

It is not unusual for content creators to build a new asset (e.g. <kuid:12345:6789>) but never upload it to the DLS. Instead they develop it with further internal updates (e.g. <kuid2:12345:6789:1> then <kuid2:12345:6789:2> then <kuid2:12345:6789:3>) before it is released. So the first version that appears on the DLS is, in this example, <kuid2:12345:6789:3>. If you download that asset and list its asset versions then <kuid:12345:6789:>. <kuid2:12345:6789:1> and <kuid2:12345:6789:2> will be shown as "Unknown location".

Added to this the fact that :127 (e.g. <kuid2:12345:6789:127>) is the highest "up-versioned" kuid value that an asset can have (there is no :128 or higher) because CM uses signed binary update values (-128 to +127). When an asset reaches version number :127 and is updated again it has to be given a new kuid value, for example <kuid2:12345:6789:127> becomes something like <kuid2:12345:6972:1>. If <kuid2:12345:6789:127> was never uploaded to the DLS but it was updated and that update was uploaded then :127 will be shown as "Unknown location".

My explanation anyway (and possibly full of holes).

The 127 issue where there are a lot of them is a bug as a large number of my DLS assets were showing as 127 a couple of months ago. DBR and reboot and all back to normal. Curiously initially on list asset versions there were none despite the originals and updates being on the DLS, I have concluded rightly or wrongly it's a server issue of some kind.

Other than a genuine 127 or the above problem, often it's actually a kuid2 asset uploaded where the creator missed off the version number, as in kuid2:12345:12345 instead of kuid2:12345:12345:1, only on old kuid assets pre 2009 I believe and you can install them and edit the config and verify the version is missing of the end of the kuid, that unfortunately won't fix the problem though as the DLS is transfixed on it being a 127. Newer Trainz versions I'm pretty sure nipped that one in the bud.

127 was given to assets that failed to give a kuid2 version number by default. This all happened when the kuid2 came into existence and creators made assets with the new kuid2 ID. I believe that all the 127 assets that were on the DLS did get sorted out and are no longer on the DLS. Deleting the 27 from the asset config will also clear the asset. It shows because the route had used them before they got changed and the route is still looking for them.

Thank you both for the additional information.

stagecoach said:

It shows because the route had used them before they got changed and the route is still looking for them.

Click to expand...

(A) If the asset was updated but NOT uploaded how does CM know there is an updated version?

(B) When being confronted by (v)127 assets the first thing I have learned to do is seek to 'List Asset Versions' which so far had shown no kuid2: versions, only originals.

I can accept it as a 'bug' in the system somewhere, when this digital technology performs not as expected, we blame a 'bug' in the system, it is easy to understand and ignore according to our digital experience and knowledge, when in reality the problem is more likely to be 18inches from the keyboard.

I can accept it as a 'bug' because the solution is easy to perform. The computer is tricked into thinking we need v 127 when we do not (how or why this occurs is above my pay grade) we trick it again to accept the original version.

Which brings to mind my Commodore C64 introduction. 'What is a computer?' was the first thing we were asked. The answer, a very fast calculator but stupid. You have to load the instructions every time you want it to do something. You and me, we can learn.

Thank you all for your suggestions/knowledge.

Roger

A= It wont. Trainz loads the highest version number so 127 can not go higher. As it got this default version number any updates made correctly to that asset with the correct version number (which will be lower than 127) will not download.
B = Correct because the original problem was resolved by removing the 2 for assets with no version number.
When an older route was created the incorrect kuid details were entered in the route or session kuid-tables. These remain in the config file when Trainz does a search for all the assets needed.

Lets say I created an asset back when kuid2 first appeared and gave it <kuid2:9999:106> but forgot to add the version. Trainz added 127 to give it a version number. Sometime later I updated the asset and did it the correct way <kuid2:9999:106:3> being my 3rd update. This will not download because of 127 but my route used the 127 assets when it was built so it is still looking for them. The DLS later corrected the 127 by removing the 2 from kuid2 and hence reverted back to the original kuid number.
Some of these 127 versions may still be on some computers without the person knowing and inadvertantly put them in a new route.

I believe that some of the answers you seek have changed between TRS19 and Trainz Plus/TRS22

CoachMan888 said:

(A) If the asset was updated but NOT uploaded how does CM know there is an updated version?

Click to expand...

If an asset has been updated in a DLC package but not on the DLS (and that is usually a decision made by the asset creator) then CM, until recently, would report that the DLS asset had a newer version available but could not locate it. That issue seems to have been resolved in the latest SP update for Trainz Plus and TRS22. The ability to identify if an update is available, I believe, comes from the DLS server.

CoachMan888 said:

(B) When being confronted by (v)127 assets the first thing I have learned to do is seek to 'List Asset Versions' which so far had shown no kuid2: versions, only originals.

Click to expand...

That, again, may have changed in the recent updates. I have not come across any :127 assets lately but now when CM "Lists Asset Versions" of any updated asset it shows all the previous versions (known and unknown). I did some checking as I thought that the "obsolete-table" tag in a config.txt file may have had something to do with CM identifying past versions but this does not seem to be the case.

Your description of computers is "spot on" although I suspect that with the rise of AI systems (but the AI Trainz driver "Alister" is an obvious exception) we may have to revise the definition of "learning".

stagecoach said:

Lets say I created an asset back when kuid2 first appeared and gave it <kuid2:9999:106> but forgot to add the version.

Click to expand...

Aha! The 18 inches from the keyboard problem.

Thank you all for your replies.