Problem with Arn Library v2.02

Suddenly the kuid for the Arn Library appears in Installed Content as 2:104722:2501038:127

This causes any rolling stock using the library to show as faulty/missing dependencies and thus not useable in the program, as the needed library is 2:104722:2501038:4. When I try to re-download this version, CM tells me it is already installed. Content Manager will not allow me to delete or modify the 127 version, and rebuilding the Data Base has no effect. Thus, I now have scores of unuseable assets.

Is there any way around this, or a quick fix for it? I hope I am not stuck with having to completely reinstall everything!!!

Any guidance would be greatly appreciated!

127 is the built in version that obsoletes all other builds. All my rolling stock seems to be OK. Can you give me a Kuid of one that you have the problem with.

Scores of them, all of which were fine yesterday. Basically it's everything third-party that was installed, such as all JointedRail rolling stock and locos, USLW, etc. All freeware and payware are affected
Any piece that requires the Arn now shows as faulty. Most of the config files list the Arn dependency as 2:104722:2501038:4

For example: TTX 48 Husky Stack KUID2:45324:300018:1. In dependency list is listed v127, but config file lists v4. If I edit the config file to v127, it is still a no-show.
CM now shows v4 as Modified, Obsolete.

I vaguely recall issues with anything with a:127 version being discussed in the past on the forums, but my searches for info have been in vain.
What little hair this old man has left is rapid

...rapidly being pulled out.

KUID can only go from :1 to :127 so it can not be replaced. Some use KUID2: xxx:0 witch was wrong and they got KUID2:xxx:127, I think that was the old bug, could be wrong.

whitepass said:

KUID can only go from :1 to :127 so it can not be replaced. Some use KUID2: xxx:0 witch was wrong and they got KUID2:xxx:127, I think that was the old bug, could be wrong.

Click to expand...

Once a kuid reaches 2:xxxx:yyyy:127 it can still be updated and replaced. This is done by adding ...

obsolete-table {
0 <kuid2:xxxx:yyyy:127>
}

... to the config.txt file of the asset that replaces 2:xxxx:yyyy:127.

The replacement asset can have a kuid number in a completely different series

Whitepass, if memory serves, you are right about it being a bug. Years ago it was discussed in the forums, but searching now does not reveal a fix. The DLS accessed thru Trainz Portal shows the version to be :127, but trying to re-download it results in the same issue.

Pware: so, if I want to replace v127 with v4 (which worked for all assets), I have to write an obsolete table for all affected assets and obsolete v127? There are scores of them! And it's not that anything replaces:127, just that :127 obsoletes all prior version that functioned correctly, and can not be deleted nor disabled.

Right now I regret having installed TANE again (uninstalled it due to a multitude of issues), as TS12 (which is no longer installed) had been tuned such that it gave me no problems. I still can't understand why everything worked perfectly yesterday, yet has gone to pot today, even though I have made no changes nor downloaded anything.

I am of the mind that there should be a Backup/Restore function in the program, such that if things go south like this, it can be reverted to a previously known good configuration.
Think I'll just delete it and start from scratch. Now I remember why I gave up on Trainz before. So very frustrating.

johnmactsf said:

... so, if I want to replace v127 with v4 (which worked for all assets), I have to write an obsolete table for all affected assets and obsolete v127? There are scores of them! And it's not that anything replaces:127, just that :127 obsoletes all prior version that functioned correctly, and can not be deleted nor disabled.

Click to expand...

Not quite. Once an asset reaches 2:xxxx:yyyy:127, you have to replace it with a new asset with a different kuid number sequence, you cannot replace it with an earlier now obsoleted version in the same sequence.

So, for example, if you need to update kuid2:1234:567890:127 with a newer updated asset (I am assuming of your own creation) then you would have to use kuid:1234:567891 or any other number that does not end in "567890". Note that the replacement kuid does not have to be a "kuid2" type number nor does it have to follow with the next number in the sequence - kuid:1234:10000, for example, would be suitable if it was a free kuid number.

I would not advise going retro and trying to replace a newer version asset with an older one even if, as you claim, it worked previously. The update may have been made for a variety of reasons that you may not be aware of. I believe it would be far better to try and resolve why the new update is not working.

OK pware, do me this favor please. Look at your installed assets and see what version of the Arn Library shows as installed, and which are obsolete. The "so-called" built-in is kuid2:104722:2501038:127, and I am thinking it is bugged, as whitepass mentioned. Yet DLS shows it as uploaded in 2016, and if you look at prior versions, they are all shown as "Unknown Asset", and thus I do not think it is a newer and updated asset. TKI shows a few references to to v4 of that kuid, and many to the v127, which again I believe is bugged. Looking at all my downloaded items, mostly from JR which worked perfectly yesterday (including the Christmas items), most use dependency 2:104722:2501038:4, and a few list v2 of the same kuid. Simply put, they worked, now they don't, from shutdown to startup something has gone awry.

Looking at my "Installed" listing, now I see that v1 thru v4 are greyed out as installed but obsolete, and I can't rid myself of the v127.

So, let me propose this, simply for my own use. Would that I could possibly make a minor modification to v4, making v127 obsolete, and package it using a different creator and asset number (my own) and then edit the config file for affected assets to show my "creation", then it might work? Certainly not something I would upload to DLS, but only to use locally to get this donkey working again? All I want is a functional Arn Library.

The thought of losing scores of freeware assets, and a few 100's of $$ of payware makes me a bit queasy, and a lot agitated.

Thanks for the input....I'll keep plugging at it!

Regards,
JohnMac

I only have one ARN Library asset installed <kuid2:104722:2501038:127> Arn library, v2.02. There are no greyed out obsoleted versions on my system. Opening its config.txt file there is no obsolete-table tag entry.

v127 has 42 dependents on my system, mostly payware (presumably from "Coal Country" which I recently downloaded but I'm not certain of that) and all of them are working with no errors. Coal Country is certainly working as I would expect it too.

So I would agree with you that between "shutdown to startup" on your system something has indeed gone wrong but that problem is not showing up on my system.

Would that I could possibly make a minor modification to v4, making v127 obsolete, and package it using a different creator and asset number (my own) and then edit the config file for affected assets to show my "creation", then it might work?

Click to expand...

Not something that I have ever tried but possibly worth a shot. But before trying this have you tried downloading and reinstalling the v127 asset on the DLS? You will probably get a warning from CM that the asset is already installed and/or open for edit (in which case submit it) and I would make a .cdp backup of it first.

Failing that, you could create a new asset with your own kuid number and then copy the contents of the v127 asset into the new folder, then edit the new config.txt file to include the v127 asset in the obsolete-table, then submit. I would be interested in hearing how this, or the other suggestion works, if you choose to try them.

:127 obsoletes all previous versions in that particular kuid and as pware says you can only replace with a different kuid. It was originally caused by authors using an invalid format like kuid:1234:4567:n. Incidentally kuid2:1234:4567:0 is valid and is equivalent to kuid:1234:4567. But :127 should still work, even if :4 was stated, as it is builtin and by N3V definition has no errors or warnings. In any case trainz/tane will always use the highest valid version of an asset in the game under the obsoletion process. Altering the config will make no difference AND as a builtin you cannot replace or repair the ARN Library. The unwanted consequence of :127 error is that versions of an asset prior to :127 (in this case :1 through :126 plus kuid:104722:2501938) will turn up as missing dependencies or unknown assets. You can see this by using "List Asset Versions".

On my system build 90945 and with the total DLS downloaded, If I use "List Dependants":

a. there are some 2,693 assets that use the ARN Library.
b. Only 42 with faulty dependencies, plus 4 payware with faulty dependencies. The faults have nothing to do with the ARN Library as far as I can see.
c. Only 75 with missing dependencies.
d. and 2 obsoletes.

On all the rest you can look at the results using CM Preview.

IN summary:

It is unlikely that ARN Library is at the root of your problems.
Nor is the :127 issue relevant because obsoletion methodology will take care of the difference in version numbers.

I recommend you compare the faulties you perceive on your system match up with the above anomalies.

Do bear in mind that vaildation is usualy much stricter as each version of trainz/tane is released and this may be the problem.

Thanks to all for the advice and suggestion. I have tried everything mentioned, but to no avail.
50 of 510 dependents of the Arn show as "Missing Dependencies" even the nothing shows as "Unknown Asset" or "Available for Download" in "List Dependencies".
In all 50 cases the list of dependencies matches the kuid table in the config file.
An exam of 30 non-faulty items that are Arn dependents have v2, v4 or v127 as the Library, and I can't find any difference in their files as compared to the faulty items.
I think this is completely random, as there are faulty rolling stock assets in both Tutorial 09 and Kickstarter Rewards wagons.

I suppose now I must resort to uninstalling Tane, then reinstall from the original disks (purchased directly from Auran, Build 74885) and patch up to Build 90945.
Then as I import content, I will check for problems item-by-item. Fortunately I have all third party freeware/payware saved on a separate drive!

I greatly appreciate everyone's time, advice and suggestions.

Regards, and Happy Holidays!

JohnMac

johnmactsf said:

Thanks to all for the advice and suggestion. I have tried everything mentioned, but to no avail.
50 of 510 dependents of the Arn show as "Missing Dependencies" even the nothing shows as "Unknown Asset" or "Available for Download" in "List Dependencies".
In all 50 cases the list of dependencies matches the kuid table in the config file.
An exam of 30 non-faulty items that are Arn dependents have v2, v4 or v127 as the Library, and I can't find any difference in their files as compared to the faulty items.
I think this is completely random, as there are faulty rolling stock assets in both Tutorial 09 and Kickstarter Rewards wagons.

I suppose now I must resort to uninstalling Tane, then reinstall from the original disks (purchased directly from Auran, Build 74885) and patch up to Build 90945.
Then as I import content, I will check for problems item-by-item. Fortunately I have all third party freeware/payware saved on a separate drive!

I greatly appreciate everyone's time, advice and suggestions.

Regards, and Happy Holidays!

JohnMac

Click to expand...

I'm really sorry to hear this for you and Im greatly troubled by this problem. Really bothers me how unstable this program is.

ledzeppelinfan1 said:

Really bothers me how unstable this program is.

Click to expand...

That's a very broad statement implying that all or most users are experiencing major stability problems with TANE. I am certainly not in that category and, judging from the posts in these forums, neither are the majority of users. Otherwise the forum would be flooded with complaints like it was after the initial release of TANE over two years ago.

There are some users that are having problems with assets that other users are not experiencing (the ARN asset in this thread is a case in point). If the program was that unstable then all of us would be having asset problems. I have no faulty assets or missing dependencies out of 400k+ installed.

There are still bugs in TANE that remain to be fixed but very few that are critical judging by the considerable reduction in such reports in these forums since HF1 was released. For some users, HF1 has introduced some new issues, some of which are probably asset related while others may not be. For me, at least, there are no new problems in HF1.

Well, TANE was initially frequently frustrating, but with the SP and HF updates it has gotten to the point that it only infrequently gets my dander up. I will say that every version of Trainz I have used (and I go back a long ways) improved over time.
I think this problem is a random event...perhaps a stray electron, a gamma ray,a passing Higgs boson, or something else equally nonsensical.

Now, to the original problem, and ongoing resolution.
I installed TANE on a slightly older computer, using only items directly from Auran (N3V)including payware, and noted no faults. Absolutely zero.
I have then added a few third party assets, both freeware and payware, making sure I had all dependencies such as loads. No problems other than one tank car missing a body mesh (not a TANE problem). All seems well and good.
This leads me to think that this is perhaps a single data base corruption with far-reaching effects.

So, back to the newer computer and do another data base repair. No joy.
In a moment of brilliance (or desperation) I do an extended data base repair.
Amazingly, about half the faults were rectified. A second EDR resolved even more.
Now, after three extended repairs, only 6 items that I can attribute to the Arn Library show as faulty. Perhaps I can live without them, but I'll keep trying.

I don't know how the obsoletion and re-direction process works, but this seems to have been the point of failure. Again, I think just a random event.

Once more, I thank everyone for their input.

Regards,

JohnMac