Duplicate kuid numbers in TS10 and TS12

[PortlandBill]

I am not sure that this problem has been seen before or is so obvious to everyone except me but I use surveyor to develop routes and sessions in both TS10 and TS12. I was trying today to move a route I had developed from TS12 to TS10 for testing purposes using a CDP. When I tried to load the CDP into TS10 it asked if I wanted to overwrite a different asset that I had already created in TS10. When I looked closely at TS10 and TS12 they both had used a whole series of kuid numbers that were identical but the content was very different. I don't know how kuids are chosen but it appears that they are only unique to a particular trainz version. The lesson here is to check carefully when moving assets between trainz versions to ensure that you are not going to accidentally overwrite something important on the importing trainz version.

 

[Mouse84]

I might be mistaken, but I don't think that you can use routes built in 12 into 2010.

 

[Dinorius_Redundicus]

@PortlandBill - That doesn't sound right. Kuid numbers are supposed to be unique to each asset, otherwise chaos reigns. No idea what has caused this problem or what the solution is. I don't have TS12 but I have never encountered or even heard of this happening in other versions of Trainz.


.

 

[sniper297]

Happens all the time with stuff you haven't uploaded - I make a new route in TS2010, the automatic gizmo assigns it KUID number <kuid:522774:100931> Meanwhile I'm testing a new cabview in TS12, which is also <kuid:522774:100931> since the bot checked the DLS, found no KUIDs either local or on the DLS with that number, so that was the number it assigned being the next available.

Workaround when you get that;
1. Open route <kuid:522774:100931> in TS2010 content manager for edit in explorer.
2. Copy the editing folder to a backup.
3. Open TS12 content manager, clone something, it checks for next available KUID and assigns the clone <kuid:522774:100985>
4. Open that for edit, copy the KUID number from the config to your backup of the route folder, paste to overwrite <kuid:522774:100931> with <kuid:522774:100985>
5. Delete all files from the <kuid:522774:100985> you have open for edit in TS12, copy the contents of the temp backup folder into the editing folder.
6. Commit, now you have the route with a new KUID number assigned.

Alternate, if <kuid:522774:100931> is something like a boxcar reskin you haven't uploaded yet, clone that, delete the original, now you have <kuid:522774:100931> free for importing the route.

 

[clam1952]

@PortlandBill - That doesn't sound right. Kuid numbers are supposed to be unique to each asset, otherwise chaos reigns. No idea what has caused this problem or what the solution is. I don't have TS12 but I have never encountered or even heard of this happening in other versions of Trainz.


.

Happens in all versions 2009 upwards if you don't import your assets from previous versions or don't upload them to the DLS, TS12 has no other way of finding out what's been used.

 

[Dinorius_Redundicus]

I stand corrected. So much for the kuid system then. What a chaotic mess this game has become.

 

[sniper297]

It's not a complete mess, just another one of them wonderful programming ideas to make things easier for the user - which like UAC inevitably causes more problems than it solves. With 2004 you manually assigned KUID numbers and had to keep track of which ones you already used, later versions (don't know exactly when) look at what's in the cache and what's on the DLS, and automatically assigns the next unused number. If you're creating content in 2 different versions of the game, then it becomes a problem, easiest way to avoid it is to pick one copy of one version and designate that the developer's copy. Create everything in that and save to CDP, import into whatever version you want to do further work on it. By choice I use one copy of TS2010, and if it's something like a multiplayer session I'll make a basic session in TS2010, then import into a copy of TS12 to finish and add the multiplayer specific stuff to it.

 

[PortlandBill]

As I said in my original post, it isn't a problem if you are aware that it can happen.

@Sniper297, the cloning method is fine if there are only a few duplicate kuid numbers. In my case I have over a hundred duplicate numbers, mainly of sessions developed for the different routes in TS12 and TS10. I was moving my development environment to TS12 and I wanted to import part of the route previously developed in TS10 into TS12. Being aware of the merge bug I thought I would be clever and do the merging in TS10 before moving everything to TS12. Fortunately for me the asset number I want to overwrite was a failed experimental session so no great loss but it could have been a lot worse.

@mouse84, the same problem could occur if you transfer assets from TS10 to TS12

What we need is for some clever person to write a program that any version of trainz could automatically access that would give a unique kuid, or give us back the opportunity to select a kuid (or both)

 

[slabay]

Seems that KUID's are assigned numerically, starting with <xxxxx:100001> and going up. I've encountered the same problem with stuff that is not in TS12 being assigned rogue numbers like <xxxxx:1000036>, when I'm up to nearly 300 used KUIDs already. It would be nice if there was an option in the settings where creating new KUIDs would continue automatically generating numbers with the option to set a floor value. In other words, tell Trainz, go ahead and keep doing whatever it is you are doing, but don't use any numbers less than <xxxxx:100300>.

 

[dnevans8]

In earlier versions of trainz (TC and 2009 I believe) the next available kuid number was stored in a file called kuid.txt. It was possible to change this number so that the different versions did not duplicate in each version or if you wanted to group different asset types. Perhaps we need to go back to that or a similar method whereby the user can assign the starting kuid number for each version.

 

[clam1952]

Think that disappeared somewhere through the 2009 patches and was the obvious simple solution.