Trainz/refs/Index of Tags & Containers

About this page
This is meant to be a comprehensive list of tags and containers, past and present, and (eventually) where possible linked to the TrainzOnline detail page which covers the data element, or hopefully here to an expanded and extended data detail page here that covers the same topic in depth, with examples, discussion, and with suitable background and introductory materials. The 'Kinds of KINDs table' from in the (TBS) is re-listed below in section 4 before the long table of tags and containers that starts in section 5 for your convenience and reference, and a later generation (editorially newer) ''navigation link template sidebar now occupies the right hand column in the upper part of this reference, which also links to individual containers. This document then concludes with a large cross-reference table that unlike the Trainz Wiki, will also have links to pertinent data definitions references.

Wiki vs. Wiki
For example, the N3V Wiki and the N3V programmers and staff who make the majority of alterations therein, aggressively purges references to older tags and obsoleted containers, while here the Wikibook mentions them, their role, and their replacement data structures, since readers here need primer background material and scope in order to understand how to repair or upgrade an desirable older asset to shut up warnings and errors in a current Trainz Content Manager. So Wikibook coverage of topics keeps THAT COMMON reality in mind in our explanations and expositions, and is not just a corporate reference stating data associations in dry programerese (i.e. Geek-speak).

Data Model evolution
Take speed and complexity of object generation as a example. From the y-2k release of Trainz 1.0 to the Christmas release of TRS2006 (SP0) in 2005, a six year span&mdash;Trainz object components definitions necessarily followed a fixed file placement schema; this was an open data storage system under the '\World subroot folder' of those early s utilizing the now obsolete tag 'asset-filename' to link the data subfolders which had requisite suffixes. That tag was actually the name of the mesh, or in the case of a pure texture asset, the texture defining the asset. But that technique left complex data objects such as a steam locomotive with the unenviable task of making a perfect mesh with all the pertinent detail, or coming up with another scheme, with the flexability to have sub-meshes. Together the and  satisfy that requirement. In those early Trainz, the complete library of open asset folders and subfolders was then compressed into various '.chump' base files placed into other cache subfolders of the root folder, which were the quick load files for the run-time GUI modules. This proved a time problem once a users asset library swelled to contain a lot of added content. There were only a handful of Chump files combining data kinds for ease of reference in Surveyor, but which meant large data files needed traversed each time a route and session were loaded.

The Demise of Useful Filters
Illustrative of how users points of view and needs differ from the programmers is how the utility of certain tags is exploited or not. In these early schemes (they evolved, obviously) the surveyor-important type, and region tags and the name-xx tags, to provide internationalization names displayed like origin and company tags in the Railyard gallery GUI. To the world builder content creators the type and region tags were useful group bundling sorting criteria defined by their asset content creator's as permanent group member filters for prioritizing the list of names one sees placing assets in Surveyor. These also sped up the access of a new tool or asset menu when toggling between F-key modes in Surveyor. Once you get a fair number of added assets into their data base, even TANE and TRS19 stagger noticably because they lack this sort of prefiltering. With such a filter selection, one could select groups of related assets, for example: UK versus USA tracks, buildings, or signals; or commercial or industrial or residential buildings; or German Commercial buildings&mdash;groups all before presenting a list of menu based selections. The menu of everthing was a targeted menu. Some CC's defined special types, like 4-Poly Tree groupings, or by large club organizations such as "TrainzProRoutes" (TPR) or the German club "Blue-Sky International"; both of which had many prolific member content creators building the assets available in early Trainz releases. In fact many of those are still very popular, and can be considered core Trainz assets. But the type and region (misnamed in actual fact) pre-filters vanished with TS2009's arrival. Regardless of how organized or disjointed such filters were logically&mdash;all of such groupings (however disjointed or poorly considered) formed additional memory associations other than kuid, author, and names helping and enabling an experienced route builder to quickly reaccess the data element sought. It also gave two pre-filter criteria a user could customize for associations in the way his or her mind works. Wikibook explains such to the new Trainzer. WELCOME ABOARD! Those two pre-filters, type and region, were often quite handy when world building, and the open storage scheme (One always knew where an assets config and other files were located... if an author's name, type, or region choice was an annoyance, one could change them easily enabling an easy way to regroup the pre-filtering tags. Alas, the implementation and keywords used for defining the later two was not well standardized, and many a content creator or group of CC's used them to group narrowly focused assets.

Evolution, Both Useful and The Stupid
Evolutionarily, the arrival of CMP in 2005 'did in' the open storage scheme for non-built-in assets when for speed, it adopted hash code calculated file associations and saved all assets in one of 256 subfolders, but one could still open the asset and customize&mdash;you now had to open the asset for edit and alter the compressed data. Worse, the bone-headed programmers of N3V decided they were never useful, and that those and other legacy tags&mdash;those  now and thereafter  termed  by them in their arrogance, as 'Obsolete'. This obviously breaks thousands of assets produced under the predecessor rules of modeling for Trainz. Having made this monumental change without consulting the user community the N3V programmer team of N3V arranged for the Surveyor Module of TS2009 to no longer have the two related click-windows which allowed quick selection of an item under a particular branch of the asset placement tools in surveyor. In point of fact, they'd eliminated one (region) in the TC releases, which aside from skin color, is the primary difference of V2.7 and V2.8 Content Managers compared to Trainz 1.0&mdash;TR06 releases. By the end of the Trainz-Classics (TCs) releases, the new programmers were accustomed to ignoring objections of the users, and continued to make unilateral decisions on usefulness of tags, they chose not to just ignore&mdash;despite ample proof that few were users and had little understanding of what Trainz users actually did and needed as tools. It's as if they had a paranoia about a few extra bytes in a config file in a day when computer memory and processor speeds was growing tremendously in power and availability almost daily! In the TCs, in particular were given a tag-trim and regrouping and spline based data objects began undergoing a similar shift in 'how-to construction needs'; this process continued into TS09  and concluded when all spline objects became definable as sub-types of track with various tags steering the software to generate the proper characteristics (not the former, Kind bridge, kind Tunnel, and even double tracked Track sub-type ... their understanding of classification and relations and formal logic is clearly lacking!). In point of fact, this is another faux-advance. Whilst appearing to advance the data model, the processing necessity for each sub-type remains. Again, something they could have incorporated as a pre-processing translation stage, maintaining full backwards compatibility was instead chosen to maintain run-time processes, but annoy the users requiring manual changes and use of a different set of definitions. Worse, N3V's programmer's under the guise of 'obsolete' chose not to just pre-process such lines of data pairs as'' 'vaporware', but to call them out instead as errors or faults in all subsequent Trainz code releases. Stated another way, instead of the easy, simple path of just ignoring such old data forms&mdash;and a few others such as the ability to comment in-file, they created tens of hours of unnecessary demands upon the time of their users for almost any legacy asset in reading the file in (pre-processing stage), including ones previously built-in and ' made perfectly to the 'current data model' of the day .'' That is, and apparently will forever be a drag and glassiness fact of Trainz-life for each such non-built-in assets which still must be processed a bit differently based on the setting of its Trainz-Build tag value (TBV) anyway. Change the TBV&mdash;you change the pre-processing and tag interpretation process, so change the errors or 'nominal faults' (actually: faux-faults) shown by Content Managers... and so the list of 'legal tags' vs. 'illegal tags' the content manager processing will tolerate. (Hmmm, sounds like something easy to automatically never bother a user about, n'est pas? A competent management and programmer team would strive to eliminate frictions caused by their product, wouldn't they? Ha!)  Guess what still works? Guess who still must invest their time to fiddle with 3rd-party assets to satisfy this artificial barrier? Bottom line, the programmers took the speed out of any users ease of use of legacy assets.

Evolutions for Speed and Function
The initial Trainz versions used what is called a Progressive Mesh but Auran in the largest re-cast of their data definitions as they evolved Trainz UTC data set/data model for the new power of interactive industries and customizable Driver Sessions, they also introduced the slightly simpler 'Indexed Mesh'  and LOD during the overhaul of the Trainz UTC data models for the much more powerful TRS2004 original release.

It is clear, at that point, at least internally, the still governing Trainz asset creation was defined and formalized as the flexibility of TR04 took shape. Mentions of this externally are missing&mdash;at least until N3V Games decided their first sole-developed evolutionary release, TRS2009: World Builders Edition tried to rely on the fancy new TrainzOnline Wiki for documentation. That is still unfinished, and doesn't give the least heed to making older data models comprehensible &mdash; which is where the importance of the Content Creators Guide(s) to old and new users enters the story.

The Wise and the Unwise Janus of Programming
Before it arrived in the community, Auran, the operating company and software house would 1) First loose Greg Lane, genius head-programmer responsible for Trainz, UTC, TR04, and Trainz 2006, 2) overextend spending millions developing another (unsuccessful) computer game, 3) go into bankruptcy and reorganization laying off essentially everyone 4) Even loose the DLS data base, probably to sabotage by a disgruntled unemployeed personage, or management decision&mdash;the Trainz Community suddenly lost its forum server and the DLS for several months. 5) Undergo the indignity of having to give-over operations control to a new court-ordered partner, Tony Hilliam and the others invested in N3V Games. 2006-2008 were not happy times for Auran, which ended up reorganized as a holding company owning certain Trainz rights, but N3V Games and a new, much smaller team of employees (Five or Six compared to 32-35 of Auran!) was in charge of Trainz operations (i.e. version licensing and releasing) and further developments since 2007, which became permanent in 2008.

Computers were rapidly changing at the time as well&mdash;both disc drives and internal RAM memory soared to unheard of uncounted gobs of storage, numbers unthinkable just a handful of years earlier&mdash;and values which seem sedate today with phones having similar power and flexibility! But TR04 was buggy initially, so it had FOUR service pack releases and a host of patches and hot-fixes over several years. Many considered that the best Trainz release ever, well into the teething troubles of TS12 (1 SP) (i.e. through TS09 (4 SPs), TS10 (also 4 SPs) and finally peaking in 2014 with TANE and the beckoning power promised by the 64-bit CPU-World beyond. TRS2006 came out introducing ContentManager Plus but its run-time software packages, as are the coding of TC1&2 (V2.7) and TC3 (V2.8) are the same JET 2 game engine and operate with little evident differences. Surveyor and Driver operate and display the same way. CMP and TS2006&mdash;TC3 sometime crash in Windows 10, but otherwise run fine&mdash; save the TR06 'Intro-video' is best disabled when launching. Turning off internet access seems to minimize their run-time packages causing crashing&mdash;which normally happens when exiting the program or Alt-TAB switching to another App without pausing Driver... CMP and the new local file storage scheme (Hash-Code folder names) are offsetting changes&mdash;users lost easy access to the raw data files, but gained in DLS operations. One can still open an 3rd-party asset for edit and fiddle at need. CMP did many of the things 3rd-party 'TrainzObjectz' had given the community, but not all; it did combine other independent tools for uploading, downloading, archiving, and fault checking into one package, but TrainzObjectz caught more relevant basic faults, specifically missing attachment points and textures for years&mdash;undoubtedly a large reason many Content Creators stayed with models developed first for TR04 and TR06, even into the current post-TANE era. The promised land is just a service pack or new release version away has become an over-familiar and much-undelivered refrain from N3V. None-the-less, there was the data model, and a new head strong inexperienced TS2009 gave their users the time-wasting shitload of artificial faults, including new 'fault tests' on mesh data, ones threatening to kill .PM file defined assets entirely (While hypocritically maintaining them in the built-in data base cabinet files (-' J et A rchive files).  They also eliminated a couple of engine-spec sound tags (breaking legacy Loco definitions&mdash;they'd require them again in TS12 and after!), and introduced the LOD files system, requiring an asset to have multiple meshes (near, middle, far) or generate a fault. Even assets without meshes had to have a mesh container in certain circumstances!  Logic, is not an N3V programmer's long-suite, but they have a lock on bone-headed programming decisions and stubbornness adverse to the communities needs!

The above table from the TrainzBaseSpec is a list of current KINDs, but does not include the obsolescent KIND classes antedating N3V's reorganization of the Trainz data model between the release of TC1&2 / TC3 (2007) and TS2009 (2008).

Notations

 * 1)  are set off by at least one  character and a following open-curly-brace, and the second column of the tables following identify that one is a part, sometimes a repeating part of the other.
 * 2) Containers have scope in more than one, whereas subcontainers, so far as we as editors can discern, do not, and are married uniquely to and within their particular container parent, including  as well.
 * 3) Terms below ending with -ID are 'variables'&mdash; string identifiers (i.e. keywords) and set up by the content creator. Some are arbitrary and unimportant, but many are handles and specific to interfacing with GameScript software files in their run time interactions. (For example, if an config.txt file is defining a rule which takes identifiers and input of data parameters, such '-ID' terms represent variables that the script code has to match up with.)

Notes, Footnotes & References
{{#if:||