Open main menu


< Trainz‎ | refs
Trainz Annotated Reference Pages

Trainz Asset Maintenance and Creation
TOC | BeginningsFun | AM&C | Creation | InBook Refs ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers
Loupe light.svg
 Mouse use
[e ]
KINDs (type asset groups)
and containers

Introduction to the KIND HierarchyEdit

KIND TrainzBaseSpec provides the basis definitions for all Trainz asset types in all config.txt ini files. The TBS provides for a number of "Standard Tags" which are common to (or at least, can legally be defined) for any and all Trainz assets[1].

  • Some of these are mandatory, for they determine the further processing of the asset and the interpretation of the config.txt file and the assets data in its folder.
  • However most are optional and a defining line using the tag may be omitted in most sub-assets.

Parent ClassesEdit

  • None. KIND TrainzBaseSpec is a root class from which other Trainz Asset classes are derived. They are said to be derived because they inherit processing attributes and values defined by the parameters listed herein, and the asset's kind declarations.

Child ClassesEdit

All the below Child Classes are considered to have the TrainzBaseSpec as their Parent Class of data.[note 1] Kinds below which are underlined are legacy kinds antedating changes to the Trainz data model in the release of TS2009 (i.e. since late 2008), with only gradual (incremental) changes imposed since by the N3V programmers. Details for fixing assets based on these legacy kinds can currently be found in the Content Creator's Guide section of the N3V Trainz Wiki TrainzOnline site here with illuminating examples of legacy Kinds here. Perusal of the CCG (the one online is the TC1&2/TC3 version, containing the altered Enginespecs Locomotive kinds from the TRS2004/TRS2006 AND UTC data models.) is highly recommended to any users of the Trainz Download Station or anyone contemplating creating content.

TrainzBaseSpec Child Class KINDs (type asset groups)


Table I, TBS Standard definitionsEdit

TBS Standard definitionsEdit

These tags and containers are standard definitions which are likely found in nearly all assets. Some tags are optional, and may not be defined by content creators, as their choice. Tags are keywords, and have a single assigned key-value or containers such as a string-array or '{' ... '}' bounded enclosed tag-value pairs or sub-containers. (Everything declared in Trainz config files is in pairs, for even '{' ... '}' is considered a key-value'.

  • Containers are collections of 'key' and 'key-value' pairs and 'upper-level containers' in the TBS (as opposed to sub-containers such as those within the thumbnails container) are generally suffixed by '-table'.
 kind    "'string-value'"
 trainz-build 'float', 1 digit decimal value
 kuid  <Kuid coded value>
 username    username "'string-value'"
 username-XX    username-XX "'string-value'"
 description    description "'string-value'"
 description-XX    description-XX "'string-value'"
 kuid-table (container)

  { A list of dependencies
  by kuids }

 A key-value table listing all assets upon which this asset is dependent.
 obsolete-table (container)
 kuids list this asset replaces (makes obsolete)
 normally none (empty)[note 2]
 string-table (container)
 key-value list of strings and messages used in the asset
Generally empty, large only in routes and sessions.
 string-table (container[s])
    {  Non-English
    language text }
 list of translated strings matching onto the mandatory English string-table
 category-region tag enumerated codes  category-region "'string-array'"  
 category-class tag  category-class "'enumerated string-value'
 category-era tag  category-era "'constrained string-array'"  decades
 category-keyword "'string-array'" max length of 64 bytes    category-keyword tag natural language searching keywords
  (replaces type, region)
 script interfacing feature
 DRM string array
 DRM string array
 privileges (container)
 More DRM
 thumbnails (container)
 thumbnails container
 script (filename)    "'string-value'"
 class (script asset class)    "'string-value'", must synch with script specification class.
 (container listing library scripts)
 extensions (container)
 formal script extensions also used by asset
 license "'string-value'"  Asset creator's copyrights statement
 author    "identity 'string-value'"
 organisation    "3rd party group identity 'string-value'"
 contact-email    "email addy 'string-value'"
 contact-website    "authors/groups web url 'string-value'"
 member-of-groups (container)
 A list of KIND Asset-group assets to which this asset belongs.


Supported TagsEdit

The TrainzBaseSpec supports the following tags in a config.txt file.:  

kind tagEdit

type: string.
field definition: The asset type which this config.txt file represents. See the index Kinds and list: here (above)


kuid tagEdit

type: KUID (brief), Main: KUIDs
field definition: The unique asset ID referencing this asset.
'Koolthingz Unique IDentifier'. The Trainz system software's unique database reference number for an asset, also extended to track multiple versions in the KUID2 form. The heart and soul of Trainz upgradability, and modular design of assets, as each asset has it's own unique kuid code, so one can specify a component (bogeys) or entire Traincar from another, and selectively replace either in a new asset (re-skin or modified truck).
  • base KUID format: '<kuid:wwwwww:xxxxxx>', where wwwwww is the author's 'unique Trainz Identity' and xxxxxx represents an author assigned model identifying code.
Right-pointing hand in green octagon.svg
Editor's note: Be advised though many online sites will require searches using separate data fields (author and serial), the Content Manager will require the full form, including brackets.
  • Most Trainz assets specify a list of dependencies in their kuid-table—other component assets which are assembled by the various parts of the software suite to make up a renderable and useable asset in a kuid-table container.
  • Within the heart of many assets, specific tags may be defined by kuid reference and use the referenced asset as a part. This is in fact how reskinning is implemented, and it is possible to also use a mesh in an asset, though more modern practices recommend such referencing to be to a mesh library asset.
A updated and update tracking modified version of the KUID format which allows a version number to be specified. A <kuid:xxx:yyy> is the same as saying <kuid2:xxx:yyy:0> (Zero revisions or version zero, meaning the original)
  • This allows data items (Trainz Assets) to carry an inherent version code for the asset. This will not generally match the CM Trainz-build code identifying the software technology levels, but indicates previous versions history.
  • Assets having a higher suffixed code in the KUID2 override or replace older assets, given both the assets in the data base. Having an early version is not necessary but CM will list the missing chain of revisions as missing dependencies, a software bug to those who resent the contamination of that facility in CM or 'feature' kept as is by the programmers, in any respect reducing the utility of using CM to identify what a user is missing, and causing users to spend time manually figuring out what is really what.


trainz-build tagEdit

Main coverage: trainz-build tags, abbreviations: TB & TBV (TB-value)
type: One decimal point floating point number Enumerated by N3V[2] to track and identify data types corresponding to the technical level of the evolved software.
range: 1.0–4.3 corresponding directly ('mapped onto3rd' Trainz 1.0—TANE-SP1+hf2; this value is expected to creep upwards incrementing by 0.1 with each new major software upgrade.

Each legal value must exactly match a released Trainz version number with these exceptions:

  • The TBV or version value assigned V1.4 was Auran's Paintshed release, a reskinning tool also applicable to the Microsoft Trainz Simulator (MSTS), and also appears as a build value for auxiliary software modules of TRS2004; specifically it's ContentManager.exe utility.
  • The gap between 1.7 and 2.0 was either foreign language releases, or as seems more likely after hours of digging and researching, unused by Auran because in the minds of the programmer team which built that original Trainz, the TRS2004 releases were the Second Trainz product, no matter how the front office hyped the marketing names (Like Trainz UTC, was ultimate anything... seriously?. Com'on man! Seriously!!?)
The series of Trainz Version and corresponding Trainz-build tag values are Trainz 1.0=v1.0, Trainz 1+SP1 ⇒ V1.1, Trainz 1.0+SP2 ⇒ V1.2, Trainz 1+SP3 ⇒ V1.3, etc. (but skipping 1.4 & 1.7–1.9), so TRS2004-SP0 = v2.0 then incremented, where each is incremented by 0.1 from 2.0 (TRS2004 no service pack) to present releases (v3.7 = TS12-SP1, v3.8 = Mac2, 3.9=TANE-CE, 4.0—4.3 & thence? From March 2016 4.3 and up are TANE SPs TBDL).
  • From v2.0 (TRS2004) onwards the Trainz-build tag number values have increased through 23 steps which are continuous though non-monotonic, for Trainz TS09-sp3—TS09-sp4 share some Trainz-build[2] values; that is, there are a few commonly shared TBVs that overlap in TS2009 and TS2010's joint development era and releases.
  • Further, N3V's foray into the Macintosh computer interrupts the smooth increments in Windows based Trainz releases TBVs 3.4, 3.5, 3.6, 3.7 & 3.8 intermingling between Windows and Mac based Operating Systems.
    Note: Hotfixes do not change version numbers.
field definition: The file format version to which this asset is built (and archived) not necessarily anything to do with technology levels used by the asset, but corresponds to the asset level assigned by creating an asset in Content Creator Plus—the same as will be found in the title bar of CM.
  • The programmer's recommend this number should generally be set to the Trainz version number of the Trainz installation on which the asset is being created and tested. The Content Creator community, in contrast tries to set the number as low as possible to give the new asset the widest possible audience/user scope when downloaded. The better content creators will test it on a naked install (no added content) of the corresponding versions as well as verifying the generated cdp contains all relevant materials.
  • Some asset kinds are parsed significantly differently depending on their trainz-build version tag. NOTE: The trainz-build tag is compulsory. If not specified, Trainz will make a primitive attempt to guess at a legacy Trainz version based on the contents of the config.txt_file, which normally resolves out as a value of 1.3 as TBV.


username tagEdit

type: UTF-8 string, username of asset, mandatory specification.
field definition: The English human-visible name for this asset.

In trainz-builds after TC1&2 (v2.7), the username also becomes the operating system folder name when the asset is edited, and asset-filename is ignored, whereas it took precedence through v2-6 config files. Per the TBS standards by N3V games, this field should never contain non-English text, except where the asset name is a Proper Noun (eg. a place name) with no English localized variant. This value is the datum everyone usually searches for and remembers, so keeping a clear name is recommended.

P train grey.png
When creating an asset, highly recommended one vetts a new proposed name against several trial partial names in CM searches and from that knowledge adopt a name which matches sensibly with existing available content.
How many 'house 2' or 'road' assets do we need tolerate to confuse us further!? Okay, In practice, we all search house and select from images, but it's darn nice to be able to specify a unique name and get what you expected!


username-XX tagsEdit

type: UTF-8 string, alternative language versions of the username tag.
field definition: (Where XX is replaced with the appropriate localization code for the language being represented.) The localized human-visible name for this asset. This field is similar to the username field except representing a non-English locale. Multiple username-XX tags may be present in an asset, once for each supported locale. If the appropriate 'username-XX' tag is not present to represent this asset on a given end-user system, the English username tag is used instead.


description tagEdit

type: UTF-8 multi-line string, providing a clear language description of the asset.
field definition: The English human-visible descriptive summary for this asset.

The description is visible in the Content Manager 'Asset Details' pane, and is used to clarify the asset name, provide specs, and often a bit of history.

N3V's Chris Bergmann has stated this field should be kept to a short (1-2 paragraph) blurb describing the asset and extended details should be provided via an info-url page, but quite lengthy blocks of text are tolerated. Some use the bottom of the block as a version change record.

This field must be comprised of English descriptive text, although the text may reference non-English Proper Nouns as explained elsewhere. Other language translations or source text are to be placed in one of the many possible alternative language localization tags (see description-xx tag).  

description-XX tagsEdit

type: UTF-8 multi-line string, description tag.
field definition: (Where XX is replaced with the appropriate localization code for the language being represented.) The localized human-visible descriptive summary for this asset. This field is similar to the description field except representing a non-English locale. Multiple description-XX tags may be present in an asset, once for each supported locale. If the appropriate 'description-XX' tag is not present to represent this asset on a given end-user system, the English description tag is used instead.


string-table containerEdit

type: UTF-8 string list container, the String-table.
field definition: A key-value list of English strings. Each key is a meaningful script identifier mapped to and referenced by binary data. Each value is an English string. An English string may comprise of or reference a non-English Proper Noun.

Other languages are supported by similar string-tables with a localization code suffix, but have the same key-values in the right hand entries, which serve as an index or look-up table referenced by the binary data of the asset. See string-table-XX for further information.  

string-table-XX containerEdit

type: UTF-8 string list container, the localized string-tables, each suffix corresponding to languages other than English.
field definition: (Where XX is replaced with the appropriate localization code for the language being represented.) This field is similar to the string-table field except representing a non-English locale.

The English string-table (no suffix) is mandatory, other localization languages are optional at the behest of the asset author. Many assets submitted to the DLS and then also used on routes bundled with a Trainz release will generally be translated and have a full set of localization translations for description-XX and the string-table. In particular, the routes and sessions bundled with a release receive professional translations into multiple languages with each retail release.

Note that the left column of the string-tables is identical as it is a mapped symbol table, and index into the binary data such as the mesh, session, or route files. It is only the use names, the right hand or data element of the two elements which are localized and substituted by the run-time localization software. These can be manually edited for more user friendly names if desired, even in the English string-table. The index or left reference column syntax must not be changed in any respect, so be careful with global SAR specifications if changing names in the data column.

Multiple string-table-XX tags may be present in an asset, once for each supported language. Each should contain a list of strings with the same Keys as in the string-table list, but with different Values. If the appropriate 'string-table-XX' tag is not present to represent this asset on a given end-user system, or the appropriate string is missing from the that list, the English string-table container is referenced instead.  

kuid-table containerEdit

type: KUID list container, same format as the obsolete-table container (next below). A dummy parameter+ a (dependency) kuid
field definition: The key-value delineating the list of assets upon which this asset is dependent.


  • The internal keywords are placeholder parameters, keywords which may be any unique value (typically, zero-indexed sequential integers.[notes 1]) They may be given names or not as a user/author prefers.
  • Entries in this table serve two purposes:
    first: to ensure that the game systems are aware of the dependency such that installing and loading this asset will successfully install and load any dependencies, and
    second: to allow scripts to locate relevant child assets.
  • Only first-level dependencies are to be included in the kuid-table—children or parts assets with their own dependencies are handled within the validation and data base committal of that sub-asset.
  • Circular dependencies are illegal.
  • An asset cannot be listed as a dependency if it is also marked as an obsolete version of this asset. (There is only one replacement kuid slot in a kuid in the Trainz Asset index (historically assets.tdx files), this would create a circular definition requiring an older version of itself!)
  • Similarly, an asset cannot be listed as its own dependency.
Format (all values are <kuid:aaaaa.bbbbb> format)
kuid-table {
 0            Kuid-1
 1            Kuid-2
 3            Kuid-3
 ...          kuid-ii
 N-1          Kuid-N
P train grey.png
Most users first content will be to auto-clone an built-in route and it's associated session. Normally because one wants to modify something. Examining the kuid-table for a route or session will let the new or old-hand Trainzer have an editable list of assets in the route. These can be easily turned into a style sheet 'filter' which lets one add to and alter a route using the same assets as the original author... or to copy his styles in your own expansion.


obsolete-table containerEdit

type: KUID list container, same format as the Kuid-table container.
field definition: A 'placeholder-key—key-value' list of assets which are made obsolete by this asset. Any attempt to load any asset on this list will result in this asset being loaded instead.
  • Further: It is illegal for two assets to both mark a third asset obsolete, unless one of the two also marks the other as obsolete.
  • Circular obsolete references are illegal.
  • All lower-numbered KUID2 versions of this asset are implied as obsolete and need not be included in this list. Concurrently, both a newer improved asset with a higher Kuid2 and one of it's predecessors should NEVER list the same predecessor (such as the original!) to the 'in-between' intermediate predecessor—as these values are used as table-of-substitute entries and only ONE asset can be substituted for the earlier versions. (The arrays only hold one value, and one cannot substitute two for one!)
  • It is illegal to mark a higher-numbered KUID2 version of this asset as obsolete as that creates an implicit circular reference.
  • The assets referenced in this list must have the same creator as this asset for the asset to be vetted and accepted by the DLS uploading process, this restriction does NOT apply in you local version, where it might, for example, be used to replace all the old paper wheel kuids on a large group of Traincars with one which is more graphically pleasing and newer.


category-region tagEdit

purpose: Filters in CM and Surveyor (searching criteria)
type: enumerated string or string-array.
field definition: A list of two-character category-region tags codes, separated by semi-colons (';'). No other characters (including whitespace, etc.) should be present in the string. This asset is considered relevant to each of the specified regions - this is most relevant for kind traincar and kind mosignal assets, but may be supplied for any asset.
category-region "CA;US"
category-region "CA;MX;US" (North American countries, Canada, Mexico, United States)
category-region "CA;CS;DE;MX;US;VE;AU;FR;IN;IT;JP;KR;ES;AR;AT;BE;CH;DK;IE;EE;NL; NO;NZ;PA;PL;PR;PT;RO;RU;SE;SK;UA;UK" (most of the 1st world countries)


category-class tagEdit

purpose: Filters in CM and Surveyor (searching criteria); determines with KIND declaration how CM software processes the asset, and where Surveyor lists it.
type: enumerated string.
field definition: A single 2-3 character category-class code which describes this content item. The category-class tag is used to provide additional human sub-categorization beyond what is implicit from the Asset Kind. Each Trainz asset's category-class tag helps describe the 'intent' of the Asset in the game, as opposed to the internal structure of the Asset.
P train grey.png
The Content Creator's Guide (CCG) for TRS2006 & CCG for Trainz Classics explained these classes represent a standardized system for referring to the various types of Locos, Rolling stock, Scenery, Spline and Industry assets. The Category-class classification codes become important to all Trainzers when searching and/or filtering for suitable assets to make into content in a session or route (layout).


Note that many category-class codes are only relevant to specific Asset Kinds - category-class codes must not be applied to assets of an inappropriate Kind.

    category-class "XBG" Boxcar - from PRR 60'
    category-class "BR" Railway (scenery non-functional) — a building perhaps
    category-class "BIN" Industry asset with product processing functionality


category-era tagEdit

purpose: Filters in CM and Surveyor (searching criteria)
type: enumerated formats string-array.
field definition: A list of five-character era code, separated by semi-colons (';').
  • Each era code represents a decade and consists of a four digit integer then must be 's' terminated (e.g. "1990s;2000s;2010s"), thereby creating a enumerated software token (value) which must be an exact match for one of the specified legal era codes.
  • No other characters (including whitespace, etc.) should be present in the string, including (and especially at the end of the string) before the terminating double-quote character.
  • The allowable year range is 1800–2010s[note 3]
  • The only meaning of this asset is to other humans, that this asset is considered valid and appropriately relevant in the specified era range, and Content Manager will accept search filters specifying the applicable years.


category-era              "1920s;1930s;1940s;1950s"


thumbnails containerEdit

purpose: Filters in CM and Surveyor (searching criteria)
type: The thumbnails container.
field definition: The thumbnail(s) which are used to represent this asset in 2D preview boxes, lists, and icon form throughout the game environment (including in-game, in Content Manager, and on the Download Station.) Each data set is included in a sub-container using a placeholder parameter as the key name or tag. Convention makes these 0 indexed numbers, but the value can be any non-null text value that can be evaluated as a string.
An actual example
(from an asset fix edit[3])
thumbnails {
	0 {
		width					240
		height					180
		image					"$Screenshot (240)(kuid 68787 25222).jpg"
	1 {
		width					512
		height					512
		image					"$Screenshot (512)(kuid 68787 25222).jpg"

The other common size is the 128x64 'icon' used in Railyard, which should have an Alphamask or a very light background; and many an older didn't use jpg files, but tga files in a '_art' subfolder, which looks like the following[note 4]:

    width 128
    height 64
    image "40ft_boxcar_art\40ft_boxcar_art_icon.texture"
   width 240
   height 180
   image "$screenshot PRR 40ft_boxcar (240).jpg"
   width 512
   height 512
   image "40ft_boxcar_art\40ft_boxcar_art_512.texture"
   width 512
   height 512
   image "$screenshot PRR 40ft_boxcar (512).jpg"

Assets uploaded without a proper thumbnails container[note 5] if later chosen in a new built-in route or session, the asset will generally be distributed as an item without images—they get stripped out if not properly referenced by texture.txt or the config.txt thumbnails container[note 6].  

Software linkingEdit

info-url tagEdit

type: URL string.
field definition: A link to an online description of this asset. The URL must resolve to a site within the Online Security Zone Trainz Online Security Zone. The use of custom Short URL Trainz Short URL formats is recommended to future-proof the URL against possible future site layout changes. Where this tag is present, in-game buttons are provided to allow the user to view the asset description without leaving the game environment. It is recommended that generic group pages are used for entire classes of asset in any case where the assets provide similar functionality but minor differences in appearance. This reduces the time-expense of creating, maintaining and localizing such documentation.


must-have-product-rights tagEdit

type: ascii string.
field definition: A list of required product rights, separated by semi-colons (';'). If the local installation does not have the required product rights then the asset may not be loaded by certain game systems.


must-not-have-product-rights tagEdit

type: ascii string.
field definition: A list of conflicting product rights, separated by semi-colons (';'). If the local installation has one of the listed product rights then the asset may not be loaded by certain game systems.


privileges containerEdit

type: The "privileges" container privileges DRM container.
field definition: A set of privileges set by the asset creator to control how this asset can be used.
privileges {
  permit-commit 1
  permit-edit 1
  permit-listing 1
  is-payware-content 0 


script tagEdit

type: string filename.
field definition: Indicates the filepath of the primary script file for this asset, if any. This filepath should always end in a ".gs" extension - the runtime will attempt to add or substitute a ".gs" extension if the filepath has an alternative extension.


class tagEdit

type: string.
field definition: Indicates the script class name to load as the primary class for this asset, if any. This class is loaded from the primary script file for this asset.


script-include-table containerEdit

type: List of kuid-parameters and corresponding names as keys.
field definition: A key-value table of scripted assets which are searched for script includes when compiling this asset's script file(s). The key (a variable, so NOT a Tag) is currently unused but must be unique; the value indicates the KUID of the asset to include.

The script-include-table container is a top-level config.txt file entry available to any Asset which derives from KIND TrainzBaseSpec (in short, all Assets.) This container allows the asset to directly include another asset's scripts from the parent asset's script file(s) using the N3V TrainzScript's Script_Include_Directive.


The extensions container is a list of custom tags or subcontainers with a specific naming convention.

S-I-T container Supported TagsEdit

This container is a simple key-value table of names of scripted assets and their kuids which are searched for script includes when compiling the asset's script file(s). The key or tag-name is currently unused (i.e. is a placeholder parameter) in searching; the value indicates the KUID of the asset to include. Being able to search and identify key-names is a content creator requested feature, so using the scriptfile names instead of numeric dummy tag-names is suggested as a best practice, for it conveys more than a kuid-reference.

S-I-T container ValidationEdit

It is typically best to restrict such references to KIND Library assets, however this is not mandatory and any assets can be referenced.

S-I-T container ExampleEdit

script-include-table {
                       a-key        <kuid:nnnn:nnnnn>
                       enginespec   <kuid2:www:xxxxx:yy>
                       anim-doors   <kuid:tttt:uuuuuu>


extensions containerEdit

type: The Extensions container.
field definition: A set of extended attributes which provide additional information to scripts beyond the Config.txt file specifications defined for this asset type. Care should be taken to abide by the extensions naming guidelines when creating a new extension, and to abide by the extension-creator's guidelines when providing data for an existing extension. Auran reserves the right to add validation for specific entries in the Extensions container at a later date, based on the extension-creator's guidelines.


Newer and less often seenEdit

The below key-words are relatively new developments and won't have analogs or presence in older assets.  

category-keyword tagEdit

type: UTF-8 string.
field definition: A list of natural-language keywords, separated by semi-colons (';'). No other characters (including whitespace or irrelevant punctuation) should be present in the string. These keywords form the basis for asset keyword searching. The asset's username need not be repeated in the category-keyword list.
  • Various default search keywords are supplied automatically based on the asset type (KIND+category-class), so need not, and possibly should not be repeated. Ø
  • The tag may not be present as a null string ("") or blank after the tag—these conditions generate a fault.
  • Obvious uses: Company such as ATSF, Santa Fe, and AT&SF, B&O, Chessie, CSX, NS, PRR or NYC, etc. whereas basic types such as flatcar, boxcar, hopper should be automatic. Bridging keys such as depressed, well car, and side dump (modifiers in other words) should probably be used to augment the limited smarts of the automatic keyword generation. Repeats of terms automatically generated should not be concerning.


{{anchor|custom-category-list container|Custom-category-list Container|custom-category-list tag|Custom-category-list Tag|custom-category-list string|Custom-category-list String|Custom-category-list Container|custom-category-list container


type: ascii string-array container.
field definition: A list of custom category identifiers, separated by semi-colons (';'). Each custom category identifier should be a short (eg. 3-6 character) alphanumeric token. No other characters (including whitespace) should be present in the string.
  • These custom categories are used to enable scripts to rapidly locate certain classes of asset. It is strongly recommended that new custom category identifiers are introduced sparingly.
  • The custom-category-list tag value may have no more than 64 characters total. This tag should be left blank unless there is an existing specific script requirement that can only be fulfilled via the custom-category-list approach.


member-of-groups containerEdit

Min-build: V3.5 and above
type: Member-of-groups container paired list of placeholder parameters and asset-group kuids.
field definition: A list of KIND_Asset-group assets to which this asset belongs. See the kind KIND Asset-group documentation for details on how and when this is used.

The container holds a regular list of KIND Asset-group KUIDs. This inclusion is a declaration stating that there-after, particularly in searching operations (including script interfacing and TrainzUtil), this asset will be considered as a member of each listed asset group.

If no entries are specified for a given "member-of-groups" container, or if the asset omits the "member-of-groups" container, then the simulator software may specify some default asset groups based on the asset's Config.txt file. The exact behaviour may change between different versions of the simulator, however the current logic is described here.  

Optional depreciated tagsEdit

The following tags are never mandantory for any asset, and many assets leave them blank.
Historically, the identification and licensing tags began with Trainz 0.9 (Beta).



type: UTF-8 multi-line string. (Depreciated by programmer fiat.)
field definition: A license describing how the asset creator would like this asset to be used. Most often seen are license statements prohibiting use of the copyrighted asset in any payware route, dependent assets (e.g. train parts like bogeys, couplers, etc.) or reskin, including distributing the asset on any site which is for-pay operated. (This is theoretically correct even for the DLS. The FCT fees are for faster access and unlimited downloads, not for access to the assets.)
The meaning of the license tag is ambiguous and its usage is not recommended by N3V, but it's presence antedates N3V's management by 6-7 years.
Content uploaded to the Download Station or provided for inclusion into the game may be under a specific redistribution contract or license agreement which supersedes any text in this field. The license field does not provide for localization support. The text of the license field is not validated or enforced by Auran or N3V and may or may not be legally binding to end users.
OTOH, history at Planet Auran has shown that someone violating copyrights by using others content as their own, may bring speedy banning from the Auran sites and loss of download station privileges, etcetera in a permanent block. Further, the community will come down hard on other users violating another's copyright, and shun both the violator and ignore any assets allowed to remain on the DLS.
In summation, experimenting and altering assets is an accepted and even condoned way of life for Trainzer's trying to climb the steep content creation learning curves (everyone wants more content creators!), but if the asset has dependent parts, especially meshes, scripts, textures, which are intellectual properties— before uploading your creation, get permission to use those pieces belonging to someone else.
P train grey.png
Asset parts specified by 'kuid reference' are not meant to be covered by this statement—using a common coupler, bogey, or basic traincar mesh (Auran minted several standard types which many authors use by default by making a kuid reference to the mesh, for example examine dependencies of Boxcars (UK: Covered Wagons or Vans)—over half are likely using a kuid reference to a basic mesh published by Auran back in Trainz 1.0!)


author tagEdit

type: UTF-8 string. (Depreciated in favor of up-datable Planet Auran database.)
field definition: The author's name or mark. The use of this field is not recommended as attribution can be determined programmatically.


organisation tagEdit

note the British spelling, the North American spelling 'organization' also works!
type: UTF-8 string. (Depreciated in favor of updatable Planet Auran database.)
field definition: The name or mark of the organization responsible for the creation of this asset. The use of this field is not recommended as attribution can be determined programmatically.


contact-email tagEdit

type: string, email address. (Depreciated in favor of updatable Planet Auran database.)
field definition: The contact email address for the creator of this asset. The use of this field is not recommended as attribution can be determined programmatically and contact details can be registered against the creator's Auran account Planet Auran account where they can be limited or updated as necessary.


contact-website tagEdit

type: URL string. (Depreciated in favor of updatable Planet Auran database.)
field definition: The contact website for the creator of this asset. The use of this field is not recommended as attribution can be determined programmatically and [contact details ] can be registered against the creator's Auran account Planet Auran account where they can be limited or updated as necessary.


Obsoleted tagsEdit

P train grey.png
The following 'tag list' are 'de facto' because their 'use-convention' antedate the formal compilation of the above listed TBS tags but not the specification for using them, and indeed, also antedates the coining of the term TrainzBaseSpec (introduced with the TrainzOnline Wiki in 2008-2009), or it's formal definition in the N3V Wiki pages 11:32, 12 May 2009[4].


  • After initial compilation, some common but now obsolete tags found in older renditions of the data model have been added below such as bendy and it's friends below found in many bridge assets.


Right-pointing hand in green octagon.svg
Editor's note: These 'TrainzBaseSpec tags' are obsolescent by programmer fiat in some cases with TB V2.7 (mainly those pertaining to Locomotive KINDs), and in all cases, after TS2009-SP0 and all N3V Games releases after it (despite the utility that many users found in some of them, the time penalties it would impose on the content creators, nor the ability to just ignore those no longer useful in a preprocessing operation) and will generate Faults (error messages) if the asset is opened for edit and partially upgraded by raising the trainz-build tags to V2.9 and greater data models:
  • Assets may be upgraded to V2.8 and before locally, and most often made to work, even when given several generations of data model elements improvements, then operate normally. It this way many assets can be made to function with TRS2004 or TRS2006 data modeling, yet be conformable with TS-releases in-processing and rendering.
  • For example, most pre-TRS era data model assets (v1.0–v2.3) can be made to work in the TS releases simply by adding a mesh-table to replace the ignored former effects of 'asset-filename' as ignored since the TS versions to define the path using the folder grouping of the original Trainz data model using subfolder and names with suffixes '_art', '_body', and '_shadow' (where the string defined by asset-name plus the suffix sets the path to the assets components.
  • Conversely, often TS-release assets with TBs v2.9 and above can be back-fitted to work with earlier data models by understanding the effects and use of some of these tags, and a little judicious alteration to eliminate texture.txt modifier lines (e.g. AlphaHint needs commented out, etc.) which are not understood by earlier versions.

  • asset-name, name, and name-XX — V1.3–v2.8 —found historically in virtually all v1.3-v2.0 assets. Whereas 'asset-name' was kept without causing complaints through v2.8, but discouraged from v2.5; hence after v1.5 the only name needed, wanted, or honored within an asset's config.txt file is a username-XX variant.



Asset-name was the primary folder name for the asset in the Trainz 1.x--TRS2004 Trainz era, and is, more often than not, the name of the folder CM will open when opening the file for edit; within such early data model assets today one generally finds the asset-name is also used for that early-Trainz era's data sub-folder's system, giving sub-folder names 'asset-name_art', 'asset-name_body', 'asset-name_shadow' in a traincar asset. When repairing such assets, most often the value can be substituted with a SAR in a boilerplate copied and pasted down from a resource file. This substitution will often correctly define and link asset sub-folders for body, shadow and artwork, as the filenames in that early scheme were based on the asset-name tags.  

bendy tagEdit

Scope: Found in track or bridge assets prior to v2.9 standards when spline objects underwent a large change to a unified data model definition, dropping several prior KINDs in the mix in favor of all spline objects being unified under kind track.


casts-shadow tagEdit

see bendy above, depreciated/obsolete pre-TS2009 legacy kind track tag.


name and name-XX tagsEdit

  • 'name' and 'name-XX' were early data model forms of the longer username and username-XX tags, the XX representing ISO two letter suffixes of non-English language translations of the English 'name tag' (or today's 'username' tag); the 'XX' forms as with description-XX being part of 'Localisation' support for other language's user-friendly values.
  • Replace name and name-XX with username and username-XX in oldest Trainz era (v1.0-v2.4) assets, or if username(s) are present just delete.
    • name-XX will cause an error if the asset has a trainz-build v2.7 up. Interestingly, even as late as TS12, name-XX tags appear as the asset name in the Surveyor tool's search lists, with TrainzBaseSpec appearing if not present.


P train grey.png
Note: Username (English) is the official asset name on the DLS, and should never be in a foreign language; after TB v2.5 (TRS2006-SP0 it also supersedes and replaces 'asset-name' when CM opens a folder for edit.

Subfolder names by convention will have pathspec names beginning with the username/asset-name field and utilize the suffixes _art, _body, and _shadow as part of the normal naming conventions. This may be a 3ds Max and gmax convention carried over into Trainz, which has historical ties to said graphics development software. (Gmax was bundled with Trainz releases V0.9—v2.4)


category-era-nn tagsEdit

Superseded by category-era tag
  • category-era-nn — V1.3–v2.8 s.a. {tag: category-era-0, category-era-1, category-era-2, ...} —a former dating system with a numeric suffix—found historically in virtually all date-worthy assets up to TBV 2.0 (and even after up to TBV 2.8 built assets!) when the current category-era string array was introduced to combine these onto a single config.txt line[note 7]. While not directly accessible in Surveyor, after TR06 and CMP, one could define a filter to select a date range and use that filter along with region and type in Surveyor to vett assets that were listable in Surveyor's placement and selection tools. Obsoleted in and after TS09 which uses the shorter category-era tag string array in a single line instead of using multiple '-nn' suffixed tag-value pairs.
  • Whitespace in the string array will cause an error; all values must be suffixed with an 's' and have four digits, s.a. 1880s;1950s;2010s (which might be wholly appropriate for a woman's garment of certain types that go in and out of fashion!). Defining a range is alas, not currently possible, but has been requested by the user community.
  • Replace with string-array type category-era tag with no whitespace and semi-colons between date codes; these are given as full four digit decade numbers followed by a 's' (Small Ess) suffix.


category-region-nn tagsEdit

Superseded by category-region tag
  • types category-region-nn — V1.3–v2.8 —found historically in virtually all locale-worthy assets. These have been superseded by the 'string-array' of two letter enumerated ISO country codes in the category-region tag.
  • Replace with string-array type category-region with no whitespace and semi-colons between the two character country codes enumerated in that referenced tag section; these are given as full two uppercase letters comprising enumerated codes followed by a ';' separator between codes, but not at the last before the terminal end-quotes.
  • Any whitespace in the string array will cause an read error, and fault message, including space(s) at the end before the trailing quotes.


  • region —valid part of TBS V1.3–v2.8 as a built-in filter and Map asset custom localization identifier (kuid); now the only legal tag use is in kind map (layout) assets.
As a former filter modifier, the tag is found historically in virtually all assets, but it was especially prevalent in rolling stock, scenery, spline assets, Track types (including tunnels and bridges) and Trackside assets with a degree of localisation.
  • Map assets still retain the keyword Region which was defined in Map configs with a contrary use—to be a kind region kuid reference. Hence, Region is required in Maps, and since TS2012, like the tag type, illegal in the very large number of assets where it once occurred as a 'grouping data' 'quick filter' for the TRS-series releases Surveyor Tool Windows.
  • Any region tag to a text string is obsolete after the TRS2009, as in the programmer's mind they replaced the crude filtering group selector of 'type and region' string-values in the Surveyor tools with the Pick List. Both these tags had some benefits and drawbacks and both date back to Trainz 0.9 Beta release.


shadows tagEdit

see bendy above, depreciated/obsolete pre-TS2009 legacy kind track asset mode control tag.


thumbnail tagEdit

The thumbnail tag was the early one view implementation of the thumbnails container (briefly documented above as well). The early pre-N3V programmer versions of Trainz would find a .jpg file, preferably sized as 240x180 pixels in either the main asset root folder, or the asset-name_art or asset-name_body folder and use it to display the asset in CMP and the DLS if it were uploaded. The tag was depreciated during TRS2006 since the thumbnails container was introduced with v2.0 (TRS2004-SP0). In older repaired assets wherein the TBV is kept below v2.4, the thumb will often still work in newer CMs provided it is in the _art subfolder and the asset-name matches the username.  

type tagEdit

  • type — V1.3–v2.8 —a former filter modifier, and found historically in virtually all assets, but were especially prevalent in rolling stock, scenery, spines, Track types (including tunnels and bridges) and Trackside assets.
  • The type tag, like the 'region tag', was used in Trainz 0.9—TC3 releases as an 'in-Surveyor group-filter' which combined with region, gave smaller selections (tool groups) of assets. Since TS2009 removed the capability and use of these local click-selectable filters in favor of a new more cumbersome filter. These left the tools selections be quick and simple, instead of being slow and pausing when switching between tool tabs—today's pre-TANE versions often seem overwhelmed by reloading a whole list of selections when switching back and forth between tool tabs.
  • Both type and region defaulted to 'All' giving the same mega-list as tools do in TS09 and after.
  • Every type tag is obsolete after the TRS2006 spinoffs (i.e. TC3), as in the programmer's mind they replaced the crude filtering group selector of 'type and region' in the Surveyor tools with the TS09 Pick List and filter—without giving the user capability to save multiple pick lists or easily load a filter defined and refined in CM.



  1. Note: This list is 'wikified' on the N3V TrainzOnline Wiki, meaning the first letter has been capitalized after the word 'KIND', whereas actual data tag names in config.txt files are all lower case text. That wiki also uses double quotes in quite a few terms, a practice which we'll spare you from experiencing herein.
  2. The obsolete-table must be used with care, and is most commonly seen in Auran authored assets. The table replaces an older kuid with a newer, and most content creators properly use the Kuid2 form of the kuid to supplant an older version. N3V by contrast, over uses the obsolete-table for new release 'upgraded' built-in assets, which can lead to much confusion, and a failure to get what one expects to see. (e.g. many nice 'Flip-trees' were obsoleted in TS10 and TS12 in favor of Speedtrees which affected many Routes wherein Speedtrees were NOT WANTED nor Desired by the creator. Across installs, this also causes missing dependencies until the asset containing the obsolete-table can be located.
     • FURTHER, only one obsolete entry per kuid is supported in the Assets.tdx data base indexing, and obsoleting a kuid with a Kuid2 version can lead to problems (i.e. which will you see?)
     • One excellent use of an obsolete-table is to upgrade a series of assets using a particular part, especially bogeys. Adding a mix of kuids to be replaced by an newer good bogey can dramatically improve the appearance of a route or session with a single edit (provided the bogey, for example, is compatible and sized properly!)
  3. On category-era tag range: The safe play, known to work. Other 'future decade' values should be tested before relying on such.
  4. In the second thumbnails container example, there is a second 512x512 sized image, an extra. Which the DLS would use is unknown. Larger image sizes can also be included, and via an email chat, T:ANE may support a large image size that will find a use in a preview operation or the DLS listings. N3V Games doesn't generally telegraphy such information.
  5. TS2009 and TS2010 early versions flagged assets without a thumbnails container as faulty, which practice was dropped in TS12 after many complaints in the user community.
  6. In a private email conversation with former version manager James Moody over the winter of 2014-2015, on point on this topic the DLS upload vetting software may well have been altered since to enforce a proper thumbnails container
  7. On category-era-nn vs category-era tags values:' The TRS's would accept either form category-era data; but TS2009-SP0 and up versions created faults from formerly legal keyword-value pairs and attempted to force content creator's to change all the assets the programmer's deliberately broke. Later the DLS upload software enforced the conversions, but that is far more acceptable, for the first action costs many an man-hour of frustration for fixes which are unnecessary and should have been implemented automatically in a software pre-filter pass when vetting older trainz-build assets. The actions virtually guaranteed that older asset downloads would have faults. It's one of the dumbest and most arrogant things the N3V programmer's have ever done and Auran's more experienced software people would have never acted so cavalierly at the communities time-expense.


  • The central body of this page is taken from the N3V TrainzOnline Wiki from KIND_TrainzBaseSpec. The enhanced information was added by the members of the Yesterdayz-Trainz user group.


  1. N3V's KIND_TrainzBaseSpec,as unaugmented source page lacking historical information (tags) found here; accessdate=Summer 2014
  2. a b "Trainz-build" tag direct link
  3. per fabartus, summer, 2014; likely the same day this example was added.
  4. Christoph Bergman, N3V Games chief programmer, aka 'Windwalkr', KIND TrainzBaseSpec history page.