So the terms of the DLS Cleanup are, you're allowed to fix an asset under the original KUID with an incremented KUID2 revision number. But what if you have an asset that's, for example, <kuid2:62523:23523>, which gets interpreted as <kuid2:62523:23523:127>? Keep in mind that we're using unsigned 7-bit integers here so that 128 = 0 and is thus invalid.
Question about DLS Cleanup
- Thread starter Scottbe8
- Start date
shaneturner12
Tutorial Creator
That kind of asset would be a problem, as you cannot have a number above 127 version-wise.
Shane
Shane
This might be the solution:
Find a kuid never used by that author (which might be easier said then done) and use that kuid. Add kuid2:62523:23523:127 to the obsolete-table.
This was also the way to replace kuids before the kuid2 was "invented" if I remember correct.
Find a kuid never used by that author (which might be easier said then done) and use that kuid. Add kuid2:62523:23523:127 to the obsolete-table.
Code:
obsolete-table
{
0 <kuid2:62523:23523:127>
1 <kuid2:62523:23523>
}In theory this sounds logical, but in reality you cannot do that because the original author, if he's still with the community, may create new content and upload it, or the content maybe hosted elsewhere. Now there will be two assets with the same KUID floating around and if an end-user downloads the other content, this will overwrite the 'revised' asset, or vice a versa.
I ran into a situation like this twice now. The first was caused by a typo. I downloaded the new asset from the DLS and that replaced a building I used extensively with a tree. This back in the TRS2004 days so replacing assets was very difficult. I contacted the content creator and he repaired the asset and re-uploaded which solved the problem. Another time this was self inflicted. I had created a building and used what I thought was the highest KUID. I had misread the KUID number in Content Manager. The result was my building replaced my modified YARN roads. Once I realized what had happened, I repaired the new asset.
John
.I have 2 questions.
1. I claimed an asset <kuid:35848:6420> for repair, created a new wersion (<kuid2:35848:6420:1>), repaired it and uploaded to DLS. A few hours later I received a message:
2. When I work with asset, which have negative author ID (<KUID:-12:209>), it is impossible to create a new version via standard method (kuid2:..:...:1)
What will I do in this case?
1. I claimed an asset <kuid:35848:6420> for repair, created a new wersion (<kuid2:35848:6420:1>), repaired it and uploaded to DLS. A few hours later I received a message:
What would it mean?
2. When I work with asset, which have negative author ID (<KUID:-12:209>), it is impossible to create a new version via standard method (kuid2:..:...:1)
What will I do in this case?
narrowgauge
92 year oldTrainz veteran
I think that selecting an unused number would be fairly safe as KUID can be any number up to 9999999 and you are unlikely to pick one he has used in that range. Probably less chance than winning the lottery.
Peter
Peter
ZecMurphy
Community Assistant
Good Morning All
At this time, it is not possible to update assets with a ':127' revision number through the DLS cleanup, only the original author can do this. We will be looking into this in future, however we do not have an ETA on when this might happen.
In regards to assets with the old '-' userID's (e.g. '-3'. '-12', etc) we are aware of these and will be looking into these in future. However, as the old '-' userID's cannot be updated any updates would be released under new kuids which cannot obsolete the originals. As such, you would still need to replace the original asset through Surveyor (or edit the asset, if not a map/session).
Regards
At this time, it is not possible to update assets with a ':127' revision number through the DLS cleanup, only the original author can do this. We will be looking into this in future, however we do not have an ETA on when this might happen.
In regards to assets with the old '-' userID's (e.g. '-3'. '-12', etc) we are aware of these and will be looking into these in future. However, as the old '-' userID's cannot be updated any updates would be released under new kuids which cannot obsolete the originals. As such, you would still need to replace the original asset through Surveyor (or edit the asset, if not a map/session).
Regards
BuilderBob
New member
That is the case for assets uploaded to the DLS, but it's not the case for assets installed in the DLS using a different process, which I presume would be used for these 'old' assets. For instance, this asset:
kind "groundtexture"
kuid <kuid:-25:965>
obsolete-table
{
0 <kuid:-3:6090>
1 <kuid:-25:577>
}
correctly obsoletes the other assets listed. There are many other examples.
NSWGR_46Class
Just call my Captain Rude
Using the 127 version of a items was a choice by some content creators to prevent the very thing that the DLS clean up is try to archive which is someone else changing their content
johnwhelan
Well-known member
It also happens if you use kuid2:123:123 as the kuid. It is accepted but is given :127 on the end. This is an undocumented feature of Trainz, well its probably documented somewhere in the wiki but not all content creators understand the use of kuid and kuid2.
Cheerio John
johnwhelan
Well-known member
Got to love programmer selected default values. Perhaps a suggestion for the suggestion box sometime.
Cheerio John
KingConrail76
New member
Something that seems to have been neglected in this discussion is the second set of "terms";
"You are not permitted to fundamentally change the content beyond what is necessary for the repairs."
--It would seem to me, that assigning an unused KUID by said Author would fall into this catagory, as it is not fundamental to "fixing", but instead implemented to "upload" the fixed asset.
Another point I think has not been addressed is the purpose and scope of HOW the asset should be fixed/updated:
-In my opinion, the assets should NEVER be updated BEYOND the OLDEST supported version of Trainz, NOT the MOST-RECENT version...
--Updating an old TS2004 asset to TS12-SP1-HF3 standards pretty much nullifies the fact that it was updated, because it excludes the use of the asset by such a large portion of the potential downloaders.
Simplest answer; move on to something else. There are plenty of things need fixing.
True, but sometimes it was done in error, by creators not understanding the (at the time) new KUID2 system, as noted below by John.
-Maybe one way to determine the suitability to "fix" would be: If the asset was an update of an older asset without a kuid2 version ( kuid:655957:54321 to kuid2:655957:54321:127 ...I've done this myself accidentally) it is more likely a "mistake", but if there is a :1, :2, :3, then jump to :127, I'd say it is safe to assume there was a purpose behind "locking" the asset at it's current state.
I think it would be wrong of N3V to change the ability to update any asset with a :127 suffix, and infact, I think that no one except the Original Author should be allowed to assign anything over :126, ultimately giving the Original Author the final say at version :127.
As a 3D Modeler, and someone who has created content for this and other sims/games/VRRPGs, the TOS of the DLS is one of the biggest reasons I stopped converting my stuff to Trainz and have only uploaded repaints of other creator's models. I have a problem with My Freeware content being included in N3V's payware products (but that is a whole other topic), I have an even bigger problem with the fact that they somehow see fit to take away my right of claim to my own content, and not only allow others to "fix" it (with only a single sentence to discourage making fundamental changes), but refuse to remove my content from public availability at my request, should I see a need to do so.
"You are not permitted to fundamentally change the content beyond what is necessary for the repairs."
--It would seem to me, that assigning an unused KUID by said Author would fall into this catagory, as it is not fundamental to "fixing", but instead implemented to "upload" the fixed asset.
Another point I think has not been addressed is the purpose and scope of HOW the asset should be fixed/updated:
-In my opinion, the assets should NEVER be updated BEYOND the OLDEST supported version of Trainz, NOT the MOST-RECENT version...
--Updating an old TS2004 asset to TS12-SP1-HF3 standards pretty much nullifies the fact that it was updated, because it excludes the use of the asset by such a large portion of the potential downloaders.
Simplest answer; move on to something else. There are plenty of things need fixing.
True, but sometimes it was done in error, by creators not understanding the (at the time) new KUID2 system, as noted below by John.
-Maybe one way to determine the suitability to "fix" would be: If the asset was an update of an older asset without a kuid2 version ( kuid:655957:54321 to kuid2:655957:54321:127 ...I've done this myself accidentally) it is more likely a "mistake", but if there is a :1, :2, :3, then jump to :127, I'd say it is safe to assume there was a purpose behind "locking" the asset at it's current state.
I think it would be wrong of N3V to change the ability to update any asset with a :127 suffix, and infact, I think that no one except the Original Author should be allowed to assign anything over :126, ultimately giving the Original Author the final say at version :127.
As a 3D Modeler, and someone who has created content for this and other sims/games/VRRPGs, the TOS of the DLS is one of the biggest reasons I stopped converting my stuff to Trainz and have only uploaded repaints of other creator's models. I have a problem with My Freeware content being included in N3V's payware products (but that is a whole other topic), I have an even bigger problem with the fact that they somehow see fit to take away my right of claim to my own content, and not only allow others to "fix" it (with only a single sentence to discourage making fundamental changes), but refuse to remove my content from public availability at my request, should I see a need to do so.
NSWGR_46Class
Just call my Captain Rude
That why My content creation partner and I chose to up loaded newer version of content not upgrade
ianwoodmore
Active member
I'd be wary of doing any repairs to the DLS Cleanup list. The list is very out of date. There doesn't seem to be much progress if one observes the length of time those that have been claimed have not either been repaired or if unable to do so returned to the list so others can repair.
Many of those that were ?repaired when DLS Cleanup was first launched had to be repaired again in order to make them work properly.
Some of the assets have already been updated by the creators themselves using normal obsoletion process.
So trying to assign them the next higher kuid extension ain't going to work.
There are also a whole bunch of Trainz Classic assets that have kuid in the low extension numbers that also have :40 numbers when they were updated to TS2009. This produced the broken sequence problem that plagues us as all numbers between the low and :39 are obsoleted for those with Trainz version TS2009 or higher.
Incidentally kuid2:123:456:0 is supposedly the same as kuid:123:456.
The :127 error almost always occurs not by assignment but by the creator mixing kuid and kuid2 formats. Trainz then assigns the :127 extension. In doing so it obsoletes all lower extension numbers, The DLS exacerbates this error by treating it as :0 but cannot be replaced because it is obsolete..
Hence other than N3V only the creator can fix this error as it requires to be superseded by an entirely different kuid number in the creator's kuid group.
About 50 of them are N3V (Auran) kuids. You'll note that there are NO negative number kuid2 assets.
For whatever reason they converted -1 etc kuids to -25 Kuids and obsoleted the previous numbers via the obsolete-table, but failed to make them fully compliant. So many do not have thumbnails or the category tags provided as well as other errors and warnings (tomorrow's errors). These are conveniently masked if they are builtins so that CM doesn't declare them defective, but surely they still cause performance errors.
This has also caused chaos at TS12 SP1 where up to 5,000 aliased assets cannot be updated by us to get rid of PMs because with the introduction of the DLC mechanism these are also locked. Aliased assets that can be upgraded cannot be upversioned beyond TB 2.9 because they become invisible. Another retrograde step.
Why is N3V not fixing their own assets on the DLS Cleanup list. Most of these are simple defects. All their assets could be repaired in less than a day.
Please note that according to N3V Life Cycle policy the following versions of Trainz will be unsupported by Sept 2014, a mere ten and a half months away. So any asset that has a trainz-build < 3.5 will become a legacy asset and may require further repair or upversioning in order for them to be compliant to the then validation standard.
Many of those that were ?repaired when DLS Cleanup was first launched had to be repaired again in order to make them work properly.
Some of the assets have already been updated by the creators themselves using normal obsoletion process.
So trying to assign them the next higher kuid extension ain't going to work.
There are also a whole bunch of Trainz Classic assets that have kuid in the low extension numbers that also have :40 numbers when they were updated to TS2009. This produced the broken sequence problem that plagues us as all numbers between the low and :39 are obsoleted for those with Trainz version TS2009 or higher.
Incidentally kuid2:123:456:0 is supposedly the same as kuid:123:456.
The :127 error almost always occurs not by assignment but by the creator mixing kuid and kuid2 formats. Trainz then assigns the :127 extension. In doing so it obsoletes all lower extension numbers, The DLS exacerbates this error by treating it as :0 but cannot be replaced because it is obsolete..
Hence other than N3V only the creator can fix this error as it requires to be superseded by an entirely different kuid number in the creator's kuid group.
About 50 of them are N3V (Auran) kuids. You'll note that there are NO negative number kuid2 assets.
For whatever reason they converted -1 etc kuids to -25 Kuids and obsoleted the previous numbers via the obsolete-table, but failed to make them fully compliant. So many do not have thumbnails or the category tags provided as well as other errors and warnings (tomorrow's errors). These are conveniently masked if they are builtins so that CM doesn't declare them defective, but surely they still cause performance errors.
This has also caused chaos at TS12 SP1 where up to 5,000 aliased assets cannot be updated by us to get rid of PMs because with the introduction of the DLC mechanism these are also locked. Aliased assets that can be upgraded cannot be upversioned beyond TB 2.9 because they become invisible. Another retrograde step.
Why is N3V not fixing their own assets on the DLS Cleanup list. Most of these are simple defects. All their assets could be repaired in less than a day.
Please note that according to N3V Life Cycle policy the following versions of Trainz will be unsupported by Sept 2014, a mere ten and a half months away. So any asset that has a trainz-build < 3.5 will become a legacy asset and may require further repair or upversioning in order for them to be compliant to the then validation standard.
Last edited:
The last paragraph of this very informative set of facts would tend to promote us to step up and work more with the DLS cleanup, rather than become wary of working with it.
KingConrail76
New member
That only applies to another patch to TS12, or an actual TS14-15 version of TrainZ...the majority of users (with TS12-preSP1, TS2010, TS2009, TS2006) will NOT be affected.
-remember N3V refuse to even consider patching anything beyond the newest release.
Why should the rest of us suffer, or be required to update because a handful of people have to have the latest and "greatest" newest unproven version of something?