assets rendered incompatible through updating.

dangavel

Well-known member
hmm, today I was reinstalling my Uintah route on PC and downloading some assets from the DLS that were made for the route, which is made using TANE. I discovered that the standard gauge track used in a couple of Ben Dorseys warehouses ( made specifically for my route) can no longer be used by me unless I change that track ,as it appears the original creator has updated the track to be compatible with 2019. This is all very well but it would be nice if the original TANE compatible track was still available, could asset creators be mindful that there are still many people who aren't using 2019 and who may not move to that platform for a few years yet. Fortunately Ben's copyright allows me to change the track , but the item on the DLS is going to be useless for anyone who actually wants to use it in the route as it ever gets released it will using TANE.
I don't specifically blame the person who made the asset for this issue ,and he does allow reskinning so the problem is rectifiable , but I note that its also made other items of his useless in TANE as I now see that a sand house of his is also not usable in TANE as it also utilises this track .

Since TANE is still viable , can we please try to keep two versions of assets going for the next few years, instead of overwriting items on the DLS that can not be backwards compatible...... it only takes a few seconds to duplicate the item so it has different kuid and will avoid the situation .
 
By and large, the DLS already does this. Often you can retrieve an older version on the DLS with "Download this Version" in the Content Manager after retrieving available versions from a "List Asset Versions" request.

It could very well be that you still have the old version, but there is a built-in affinity for the game to seek the latest version, so the old one may be sitting there idle. Try deleting the problematic version in the Content Manger and see if that resolves the problem.

Otherwise, if an asset has evolved into something incompatible for your pike, you can recover the older version from your backups folder, or recover it from your hard-drive backup.

To make sure you don't overwrite it again, you can edit the username tag to remind you.

You should also pay attention to the "Build Version" column in the Content Manager so you do not overstep the TANE pedigree. This column needs to be activated for those not using the latest Trainz release.
 
Last edited:
By and large, the DLS already does this. Often you can retrieve an older version on the DLS with "Download this version" in the Content Manager.
Otherwise, if an asset has evolved into something incompatible for your pike, you can recover the older version from your backups folder, or recover it from your hard-drive backup.

To make sure you don't overwrite it again, you can edit the username tag to remind you.
Yeah,thats all very well, but its a big hassle for anyone who doesn't use 2019 and just leads to more frustration and angst..In this case the asset creator has made the item made by another asset creator unusable in the route it was intended for as his track is now only compatible for 2019. I will have to make another version of the asset and also any other items that use that track , upload to DLS and hope that all those who have already downloaded it will get the correct version when the route is actually made available. This is just more work when there are probably 3000 unique assets to get working, this could be avoided if he had made a 2019 version and left the original TANE version on the DLS . Also, if the asset can't be changed because its not allowed to be modified, then that's the end of it. By not considering that other asset creators have used his creation as track within buildings , he's made a lot more work for a lot of people when he could have just duplicated the track and used another kuid number. I'm just asking creators to consider the domino effect that some of their decisions can have if their work is used in other assets.
 
Last edited:
Hi Dan,

I'll bet you are referring to some of Pencil42's assets. I ran into this last weekend. I tried to install some of his assets in TANE and they showed as incompatible or with errors. When I opened them up for edit I noticed that they were now updated for 2019. I am not in front of my computer as I write this but as I recall the asset was updated but the kuid number was not changed. Perhaps this was an oversight but this should not be done. If the asset is changed then the kuid number needs to be incremented so that the original remains and either the new version or the old can be used as desired.

Paul :)
 
Hi Dan,

If the asset is changed then the kuid number needs to be incremented so that the original remains and either the new version or the old can be used as desired.

Paul :)

A simple solution, but so often ignored. Not everyone is going to update to TS2019, in the near future or perhaps never. In the cases above the creator has basically withdrawn their asset from the DLS without notice as far as pre-TS2019 users are concerned, which should only happen in cases of copyright infringement and/or piracy.

--Lamont
 
Actually the real problem is that the DLS gives the downloader the most recent version of an asset using the newest version based upon the highest version of Trainz OWNED by the downloader.

In simple terms, If TANE is the newest version I have listed in my account settings, I get only assets compatible to TANE. However, if I also own TRS19 then I get the TRS19 compatible version of the asset. This is crazy. What version of an asset I get should be based on what version of Trainz I'm using to download it. Really simple fix to a really stupid programming bug that has been around since TRS2006.

William
 
Actually the real problem is that the DLS gives the downloader the most recent version of an asset using the newest version based upon the highest version of Trainz OWNED by the downloader.

In simple terms, If TANE is the newest version I have listed in my account settings, I get only assets compatible to TANE. However, if I also own TRS19 then I get the TRS19 compatible version of the asset. This is crazy. What version of an asset I get should be based on what version of Trainz I'm using to download it. Really simple fix to a really stupid programming bug that has been around since TRS2006.

William

More to the point I think is that incompatible assets should not be listed or available as updates in lower versions.

Meanwhile If you look at the list in Manage Content in TANE SP2,3 and 4 it clearly says incompatible for 4.6 assets, unless people are still bizarrely using the DLS web site which is way out of sync with modern versions of Trainz and will enable you to download at the highest version you possess regardless of where you intended installing it.
Incompatible showing in TANE means don't download it but you will not get that from the out of date Web system.
To add as a double check you can show the build version column in Manage Content and avoid downloading. If it says newer version available and not on the latest version of Trainz then check asset versions and the build version or the incompatible marker for the update, don't waste time downloading for it to error in TANE. Bit of a pain agreed but just means people not using TRS19 need to be more observant when using older versions until such time as this is sorted out, maybe. :eek:
I suppose not really that different from TS12 to TANE with incompatible TANE items being downloaded in TS12 and in TS12 there was no incompatible marker in CM, they did get errored in the in game updater and not downloaded, so I would think the technology exists or did to stop inappropriate downloads.
 
Hi Dan,

I'll bet you are referring to some of Pencil42's assets. I ran into this last weekend. I tried to install some of his assets in TANE and they showed as incompatible or with errors. When I opened them up for edit I noticed that they were now updated for 2019. I am not in front of my computer as I write this but as I recall the asset was updated but the kuid number was not changed. Perhaps this was an oversight but this should not be done. If the asset is changed then the kuid number needs to be incremented so that the original remains and either the new version or the old can be used as desired.

Paul :)
Yep you are right, I noticed today there are now dozens of them, fortunately he does allow people to mod his items so it ought to be able to be ok to upload the old version with another kuid number. It's probably not occurred to him that this might be an issue for some users.
 
Yep you are right, I noticed today there are now dozens of them, fortunately he does allow people to mod his items so it ought to be able to be ok to upload the old version with another kuid number. It's probably not occurred to him that this might be an issue for some users.

Careful, he use mesh libraries, that might be the cause of the problem, maybe the wrong library for pre TRS19 assets? might be an idea to let pencil45 know there is a problem.
 
If the asset is changed then the kuid number needs to be incremented so that the original remains and either the new version or the old can be used as desired.

It is not possible to upload a new version without incrementing the version number, but in any case if the asset is changed in a way that makes it inconsistent with an existing dependent asset then incrementing the KUID version of the asset does not solve the problem - the system will look at the newest installed version and see the inconsistency. The user can avoid the problem by not downloading the updated version. The better solution is to upload both dependant and dependency, so the user can download both. If that means that the build numbers have to be increased beyond the user's current Trainz version then there is no easy solution - either avoid the update or start a new KUID.
 
Careful, he use mesh libraries, that might be the cause of the problem, maybe the wrong library for pre TRS19 assets? might be an idea to let pencil45 know there is a problem.
In this case it's his track that's the issue, but he's also updated all his harp switches , I don't think they use mesh libraries like his cliff series do they ? anyway, as most ng routes use his items, it could render a large proportion of those routes in TANE useless unless substitute items are found or if someone else uploads all his old versions onto the DLS with different kuid numbers , but even then, they will have different Kuids and will need to be replaced in the route, could be a lot of work.
 
In this case it's his track that's the issue, but he's also updated all his harp switches , I don't think they use mesh libraries like his cliff series do they ? anyway, as most ng routes use his items, it could render a large proportion of those routes in TANE useless unless substitute items are found or if someone else uploads all his old versions onto the DLS with different kuid numbers , but even then, they will have different Kuids and will need to be replaced in the route, could be a lot of work.
This analysis is wrong. If a new version has made an existing asset faulty, then the fix is to not install that new version. I can't see anything in the above discussion that makes this impossible. It seems that there is an assumption that the new version has removed the original version - that doesn't happen. Where the installation is new it may be difficult to force the correct version to download, but it is doable. There is an additional complication where mesh libraries are involved, but there is a workaround. Whatever, new KUIDs for existing assets is not the solution.
 
More to the point I think is that incompatible assets should not be listed or available as updates in lower versions.

. . . .

I agree completely with that, Malc. At the moment, I have 75 pieces of content in my TANE (SP3) CM showing there are updates available. If I highlight them all and ask for all versions, EVERY ONE of them will show them to be for a higher build than SP3 of TANE. This make legitimate updates hard to pick out of the chaff of all these bogus updates which I can't use at all unless I tack on a special "AND NOT Build Number < TANE (SP3)". That makes all the updates meant for TS2019 go away from the window, leaving just the ones I wanted in the first place. Talk about having to go around the barn to get from here to there.

Bill
 
This analysis is wrong. If a new version has made an existing asset faulty, then the fix is to not install that new version. I can't see anything in the above discussion that makes this impossible. It seems that there is an assumption that the new version has removed the original version - that doesn't happen. Where the installation is new it may be difficult to force the correct version to download, but it is doable. There is an additional complication where mesh libraries are involved, but there is a workaround. Whatever, new KUIDs for existing assets is not the solution.
But dan, if the new version is included in somebody else's assets, as it is in this example, then it invalidates that item, I was able to download bens items but they showed missing dependencies, as the dependency with the same Kurd number is no longer available for tane, then this is an issue especially as bens no longer here to update his stuff, I'd have to change the track and upload my reskin of his original. Fortunately I can do this , but there are other items we here I would not be allowed to do so. Can anyone explain how a Kuid that has a particular number that has been updated can exist for two separate versions of trainz if the newer update is not backwards compatible, as some seem to be suggesting? Or have I just got it wrong....
 
But dan, if the new version is included in somebody else's assets, as it is in this example, then it invalidates that item.
Then the solution is to delete that item, as I stated. Depending on the installation, this might require installing the earlier version. Then, with the dependency and the dependant compatible, there is no error. Is there some reason this is not possible?

… but they showed missing dependencies, as the dependency with the same Kurd number is no longer available for tane
Why not? Assets do not get removed from the DLS, so if it was there previously it is still there. What is the asset that you believe has disappeared?

…this is an issue especially as bens no longer here to update his stuff, I'd have to change the track and upload my reskin of his original.
The point of my comment is that no update is required, so that's not relevant.

Can anyone explain how a Kuid that has a particular number that has been updated can exist for two separate versions of trainz if the newer update is not backwards compatible, as some seem to be suggesting? Or have I just got it wrong....
Do you mean "... can be installed with two different KUID version numbers that have different build number"? There is no difficulty in that at all: the system will always use the asset with the higher KUID version number. So if that asset is incompatible with some other asset, then it needs to be removed. But if you mean "...how do I arrange things so the two assets with different KUID versions and different build numbers are installed, but some dependent assets use one version and other dependent assets use the other version?" then it can't be done. In that case the likely fix is to remove the dependent asset that relies on the later version dependency, so everything is back at the level where it is all compatible.
 
Then the solution is to delete that item, as I stated. Depending on the installation, this might require installing the earlier version. Then, with the dependency and the dependant compatible, there is no error. Is there some reason this is not possible?


Why not? Assets do not get removed from the DLS, so if it was there previously it is still there. What is the asset that you believe has disappeared?


The point of my comment is that no update is required, so that's not relevant.


Do you mean "... can be installed with two different KUID version numbers that have different build number"? There is no difficulty in that at all: the system will always use the asset with the higher KUID version number. So if that asset is incompatible with some other asset, then it needs to be removed. But if you mean "...how do I arrange things so the two assets with different KUID versions and different build numbers are installed, but some dependent assets use one version and other dependent assets use the other version?" then it can't be done. In that case the likely fix is to remove the dependent asset that relies on the later version dependency, so everything is back at the level where it is all compatible.
Let me reiterate , the issue is, . Ben Dorsey’s
Ury Mack depots which have Curtis’s track are now unable to be used in tane if any user has to download them off the Dls as he had updated his track to 2019 standards using the same kuid number that was used for tane .it would have been better if he had uploaded a separate 2019 version with a different kuid, but he hasnt . As this item is bens I cannot change it on the dls, I will have to change the track used, then upload as a new asset. I can only do this because Ben allowed us to do this with his assets. It is part of a route not yet released. It is not just a matter of me just reinstalling the original which I could do, but When the route is released unless I made a reskin with different track, no one who downloaded the route could use the as set that is currently on the dls in tane. As it happens I can change bens assets and work around this issue, but if Curtis does this to all of his assets it is going to play merry hell with lots of routes . In some cases it may well be that his track or assets are used in assets made by others which we are not allowed to modify. It’s all very well to say “reinstall the original” but that will not work if I want to put the route on dls for distribution to people who do not have already have copies of the older tane versions. There is also the small matter of if one had a hard drive loss which contained all backups , because then, where do you find the original ? My gripe is because i’m Making two routes that I will have make changes to both because assets are no longer usable in a version of trains that is still for sale and hasn’t even had its last revision. Surely there has to be a way to stop this from happening as it throws a huge spanner in the works for anyone route building who is still working in Tane.
 
Let me reiterate , the issue is, . Ben Dorsey’s Ury Mack depots which have Curtis’s track are now unable to be used in tane if any user has to download them off the Dls as he had updated his track to 2019 standards using the same kuid number that was used for tane .
This can't happen. It is not possible to upload an item to the DLS with the KUID of an item that is already on the DLS. If you believe that this has happened you should quote the asset KUID so that the error can be independently verified and reported to N3V for fixing.
 
This can't happen. It is not possible to upload an item to the DLS with the KUID of an item that is already on the DLS. If you believe that this has happened you should quote the asset KUID so that the error can be independently verified and reported to N3V for fixing.

It can if N3V update the asset - they've done it to one of my enginespecs (with less than glorious results I might add).
 
To me there is an obvious problem if an asset is updated (even by N3V if they choose to) without an update to its kuid.

Assume that I have downloaded and installed an asset from the DLS. If that same asset is later updated without changing its kuid then, according to what I understand happens, how will my CM detect that it has been updated? I thought that the whole purpose of using the incremental :z values at the end of the kuid is so that CM can detect that an asset has been updated if its :z kuid value is greater than the same asset I have installed.

Or am I totally misunderstanding the whole process?
 
Back
Top