Trainz/refs/KUIDs Geneologies-- groundtextures

← Prev Indexes, technical, Introductory Trainz

↑ Trainz Main TOC — Trainz reference pages ↓

Trainz Appendices or Appendixes

Trainz Asset Maintenance and Creation

Background, Introductory history

Trainz, almost from its inception, used a data structure introduced with Trainz 1.0 SP3, the obsolete-table to allow Content to be superseded by a different, presumably newer better version of an asset. By the time Trainz UTC was coming together, the KUID and KUID2 succession system was invented, leaving both methods as legal alternatives.

Issues of connectivity

There are several problems with the use of obsolete-tables — and most of them emanating from Auran/N3V's inhouse content creation team's over use of the tables to maintain kuid identifiers with negative author indexes. This dubious strategy has long outlived its utility, and should have been retired with the introduction of the kuid2 capabilities, which always point both forward and back in time to related generations of changed asset releases and by inference, to any later iteration. The base kuid identifier is applicable to the same asset, so a parent-child relationship is always explicit, and unlike obsolete-table enclosing kuids, which have their own base kuid with no specific relationship to the older kuid, assets sharing the same base kuid identifier are predictable--the newer generation is of a higher suffix, not a different (and unknowable!) random kuid.

On its face, this may seem like small beer, but in the multiplication of the practices by numbers of content creator over twenty years, in absolute terms, the numbers of disconnected next generation kuids is simply staggering. The great majority of missing assets in any sizable downloaded route will suffer from this problem with about 50% of the unknown kuids being precisely because until both assets are in the local Content Manager data base, there is no way to know that relationship exists between two different base kuid identifiers.

The problem has also been exacerbated by N3V's nearly consistent practice of upping the iteration with each major retail release (and Major TBV plateau)—again (per differential binary comparison) with no particularly significant change to base component files except the identity within the new kuid and the revised obsolete-table.
As illustrative of the problem, consider the succession of an gravel-less 'bridge track' (key word "bridgetrack" in fact in dependent bridge kinds!) used as a linked resource asset in dozens, possibly hundreds of bridges (Some content creators create their own, others default to the N3V built-ins, swelling the count and size of the problem!):

This list was generated by TANE: by requesting all versions of the 'obsoleted' <kuid:-1:100673> 1 track wood damp—which was the built-in replacement for the previous TS10 iterations, and the situation further gets confused because the TANE '<kuid:-25:1062> TANE 1Trk Wood' is actually MERGING two lines of different tracks, one wet wood and the other consistent with the general wood track with the several built-in gravel ballasts.

The line items without identifiers are reported as 'unknown':

<kuid:-25:1043> 
<kuid:-1:15> 1 track wood
<kuid:-25:1055> 
<kuid:-25:1058> 
<kuid:-25:1002> 
<kuid:-25:197> 1 track wood US

<kuid:-25:1061> 
<kuid:-25:196> 1 track wood damp
<kuid:-1:100608> 1 track wood US
<kuid:-1:100673> 1 track wood damp
<kuid:-25:1062> TANE 1Trk Wood
<kuid:-25:195> 1 track wood

Which one came first, and in what order did they replace the previous? When an asset only knows what is in its kuid-table and obsolete-table, and the two don't both show in CM, there is an information gap which the GUI's can't overcome... they don't know what on-hand kuid to substitute for the older number in the kuid-table.

To be complete, this problem may be mitigated with changes to the data communication with the DLS and post-TS2012 Content Managers. There appears to be extra information available, probably in a 'side list of linked kuids' that is available to TANE and TRS19 which does not get reported to or used by the design of the older Content Managers. This is evident in the reported content of the above list. The list returned by TS12 for the very same 'show asset versions' query is quite different:

1 track wood damp,<kuid:-25:196>
1 track wood damp,<kuid:-1:100673> (Obsolete)

So we can conclude <kuid:-25:196> superseded TS09/TS10 era's <kuid:-1:100673>, and nothing more. Certainly not that its grandparent was a particular specific ubiquitous kuid dating back to TBV 1.3 and Trainz 1.0—which is what that newly downloaded older route or bridge may list as a dependency. Bam, information gap, even to the software. Which segues into the other related issue. Generally superseding assets were assigned the very same Trainz-build (TBV), likely to expand international visibility and utility to a new language group added to the standard releases' asset queues.

Identification

Kuid (base kuid) format: <kuid : Author ID# : Base Kuid index >
Kuid2 format: <kuid2 : Author ID# : Base Kuid index : Version Suffix>

Specifically the most common Auran 'Author Identifier' kuid-parts, spanning twenty years of growth are: {id#: -1, -3, -10, -12, -14, -16, -18, -25, -26, -101, -105 and lately many +523}; emphasis added to the ones with the most codes.

Ironically, testing and comparisons have shown the most of the successor kuids in the Auran genealogies are graphically and pragmatically identical assets, with the iterative changes mainly being focused on adding new internationalization data-names and descriptions (See: username-XX and description-XX) when a release was translated into other languages.

Independent 3rd Party CCs

Other independent creators, '3rd Party Content' originators, causing widespread problems using obsolete tables rather than a generational kuid are a handful of the oldest group of content creators, including two of the most prolific steam engine originating modelers, maestros paulhobbs and bdaneal, who specialize in British and North American steam locomotives and rolling stock, respectively. Unfortunately, generally locating a specific missing kuid is problematic, and many are shrouded as unindexed parts of kits. But which kit should be looked for and downloaded? Others, especially a few key dependencies by Mr. Paul Hobbs were only released as part of a payware route of yesteryear—which aren't available now, and have been superceded in the routes replacement by a payware 'alleged upgrade', leaving the poor sod simply desiring to use a derivative reskinned asset with a missing dependency. In this case, perhaps one that is incurable.^{[note 1]}

Decentralized base kuids, and source locations

In the case of the later type, there seems to be an overreliance on private 3rd party websites to distribute full data sets. Many of their locomotives in particular utilize a low poly, often invisible mesh as an anchor mesh providing orientation and the origin, axes of a coordinate system to provide anchor points to which other meshes attach. This sort of mesh can grow organically as parts are added, or have a particular anchor point moved in 3D spatial co-ordinates.

In the case of such gorgeous steam locomotives as both are known for, there is a definite mechanical advantage to the method: when the separately configured bits of something as bulging, bulky, and possessing so many moving parts, each with their own motion to animate, working a data set individually enables them to debug each part as they progress each subsystem over the months it takes to complete such a model. The same degree of complexity rarely applies to most Auran/N3V sourced models, which in the greatest cases generally have a much more mundane and uncomplicated mission.

Table of groundtexture geneology

<kuid:523:1463> TS09_53_Concrete <kuid2:523:1463:1> TS09_53_Concrete <kuid2:523:1464:1> TS09_54_Asphalt <kuid:523:1464> TS09_54_Asphalt <kuid2:523:1465:1> TS09_55_Asphalt <kuid:523:1465> TS09_55_Asphalt <kuid2:523:1466:1> TS09_56_Asphalt <kuid:523:1466> TS09_56_Asphalt <kuid:523:1467> TS09_57_Asphalt <kuid2:523:1467:1> TS09_57_Asphalt <kuid2:407941:1048:3> SeasonalGrass4 <kuid2:407941:1048:2> SeasonalGrass4 <kuid2:407941:1048:1> SeasonalGrass4 <kuid:407941:1048> SeasonalGrass4 <kuid2:407941:100040:1> SeasonalGrass8 <kuid:407941:100040> SeasonalGrass8 <kuid2:407941:100040:2> SeasonalGrass8 <kuid:407941:1044> SeasonalGravel2 <kuid2:407941:1044:1> SeasonalGravel2 <kuid2:407941:1044:2> SeasonalGravel2 <kuid2:407941:1044:3> SeasonalGravel2 <kuid2:407941:1043:2> SeasonalGravel4 <kuid2:407941:1043:1> SeasonalGravel4 <kuid:407941:1043> SeasonalGravel4 <kuid:-25:1291> hayfield

[note 1]