Trainz/refs/TrainzBaseSpec

Introduction to the KIND Hierarchy
KIND TrainzBaseSpec provides the basis definitions for all Trainz asset types in all s. 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.
 * 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 Classes

 * None, Valid and mostly all necessary for all content defined by defacto parent container, the file required for all Trainz digital models. KIND TrainzBaseSpec (TBS) is a root class from which other Trainz Asset classes are derived.
 * They are said to be derived because they inherit processing attributes (instructions) and values defined by the parameters listed therein, the key one being the value of the kind tag. That enumerated word determines the asset's specific, which are added to the defines of the TBS within that assets config files.  Other key TBS defined data are of obvious importance and utility such as a name for the asset, the Kuid identifier and version, the Trainz-build Value (TBV) and others with widely variable need of definition, applicability, and scope such as string-table, obsolete-table, kuid-table and thumbnail images are each circumstantial. String values, even the asset name and description are most often totally unnecessary and totally omittable in practice.

Many of these same 'defaulted yesterday' definition lines today in post-TANE releases, will instead more often generate a fault, demanding a clear value definition when such was defaulted in past loadings. This is a much preferable annoyance compared to the olde-tyme days when a faulty asset definition would sometimes cause the infamous 'Blue Screen of Death' or more often, crash the run time software back to the desktop, resulting in a loss of edits, and possibly a need to rebuild the data base.
 * When a kind is declared, that kind becomes the parent class requiring and dictating the necessary pairs of data which must be satisfied in the class, in addition to those listed in the TBS.
 * Certain parameters may be left undefined in a case for that asset's kind, especially a common practice for older historical Trainz-build tag values and for those, Content Manager or the Content Creator Plus utility will assign a default value, but list a warning message when processing it.  Many tags in the TrainzOnline wiki, here, or the older TC3 era Content Creator's Guide ( will mention a default value.
 * The Content Manager modules of each release, from TRS2006 and Trainz Classics (TC1&2) onwards, each imposes more and more pre-commitment error testing and each has become increasingly adamant about warning such a tag has not been defined when it expects such a tag--data pair.

Kinds of KINDs
---> All Trainz defined data (content) has three required elements: A config.txt file to organize the data, an identity meaning a kuid (username alone will do you no good, a legal asset however can be created without a name!) and last, a legally defined kind tag. The kind is in charge, the conductor of the orchestra, the Platoon Sargeant or CEO giving directions &mdash; setting up the requirements for everything that gets processed after. In short, the kinds' value, a small select tightly defined members-only group &mdash; tells Trainz software what is to be rendered and displayed in the virtual worlds we create, and how (or where) to find the other parts needed to make those parts of the asset linked together in that config.txt file. Each of the below Child Classes are considered to have the as their 'Parent Class' of data. A few kinds listed below, those 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 section of the N3V Trainz Wiki  with illuminating. Perusal of the CCG is highly recommended to any users of the Trainz Download Station or anyone contemplating creating content. The insights gained from understanding of the background history of how older content was defined can then be contrasted with the current TrainzOnline coverage of the same data type and compared, for often this kind of then-vs.-now provides valuable insights to fixing, altering and customizing assets. More to the point, the writing in the CCG was professionally produced and is far more tautological&mdash;it will often give you insights as to extended effects if this or that is altered, which the Trainz Wiki just doesn't provide. The CCG put up on TrainzOnline is the TC1&2/TC3 version &mdash; the last published of several booklets printed dating back to Trainz in 1999; the TC3 CCG contains the altered Enginespecs Locomotive assets from the TRS2004/TRS2006 AND UTC data models need to be properly updated.
 * To edit source page material

Supported Tags
The   supports the following tags in a. :

kind tag

 * type: string.
 * field definition: The asset type which this config.txt file represents. See the index and list:

kuid tag

 * type: (brief), Main: KUIDs
 * field definition: The unique asset ID referencing this asset.


 * KUID
 *  '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: '', where wwwwww is the author's 'unique Trainz Identity' and xxxxxx represents an author assigned model identifying code.


 * Most Trainz assets specify a list of dependencies in their &mdash;other component assets which are assembled by the various parts of the software suite to make up a renderable and useable asset in a .
 * 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.


 * KUID2
 * A updated and update tracking modified version of the KUID format which allows a version number to be specified. A  is the same as saying   (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 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 tag

 * Main coverage: trainz-build tags, abbreviations: TB & TBV (TB-value)
 * type: One decimal point floating point number d by N3V 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&mdash;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 or version value assigned V1.4 was Auran's Paintshed release, a reskinning tool also applicable to the  (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 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&mdash;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&mdash;TS09-sp4 share some 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: 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 &mdash;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  is compulsory. If not specified, Trainz will make a primitive attempt to guess at a legacy Trainz version based on the contents of the, which normally resolves out as a value of 1.3 as TBV.

username tag

 * 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.

username-XX tags

 * type: UTF-8 string, alternative language versions of the username tag.
 * field definition: (Where XX is replaced with the appropriate 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 tag

 * 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 tags

 * type: UTF-8 multi-line string, description tag.
 * field definition: (Where XX is replaced with the appropriate 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 container

 * type: UTF-8 string list container, the.
 * 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 as an identifier. Assets authored by non-native English speakers must still create a non-suffixed string-table container if any is needed.  Software only links to and references names and values in the string-table container without a suffix, which must irk Spanish, French, German, Chech, Dutch... Japanese authors to no end. In other words, the suffixed string-tables are solely there for translation purposes, which creates problems when a map is written in non-English&mdash;there is no string-table-en to give a table for back translations.  Ditto, username-en and description-en.  All three lackings demonstrate an old fashioned and cavalier arrogance and insensitivity to the World dynamics.

Other languages are supported by similar string-tables (e.g. string-table-XX) with a localization code suffix (XX) matching that of the internationalization suffixes for description and username keywords/tags, but those language keyed string-table containers will always have the same key-values in the left hand entries.
 * These left-hand keys or tags serve as both a 'local index keyword', and as a 'table of equivalencies' between languages.
 * The left hand column will always have the objects that a Content Creator gives a 'special' name such as names of signals, trackmarks and industries, junctions and so forth, that might be referenced, and will appear in the Driver and Surveyor module 'Find Utility' function applet.
 * The index side conversely will also not list defaulted names of places such as the innumerable collection of junctions, automatically indexed by a random number when building a route map (i.e. meaningless clutter. If important, the route building CC will name it!); but will automatically include potentially temporary assets such as traincars' default names. If renamed, those names take the place of their corresponding default names.
 * Its principal use is for those objects designed to interface to script references and take on variable attributes such as a train station or amount of products needed by or ready to ship at an industry, or carried by interactive traincars (rolling industrys to scripting) and other configurable assets as simple as a generic billboard style sign which with a bit of height adjustment and angle torquing can be placed in front of the facade of a stock building or industry to put a different business name on a building. In other words, a bit of configurable scenery.
 * Overall in these LHS names correspond to named objects on the map asset, and that is where most string tables are seen (literally, populated by the thousands of entries in a large route ).
 * In some assets, that default name is hooked into software scripts, so the string-table becomes specifically important instead of ho-humingly-boring. (see below)


 * The use of a string-table type is always legal in every kind of asset, just like description tags and trainz-build and kind tags. Unlike those, it need not be present or defined and is in no way mandatory. Values encapsulated within a string-table container have no function or effect unless code expects their marriage.
 * In other assets, again say taking that hypothetical programmable business sign as an example, the string table must needs be given a default name if it is to interface to software. All map placeable assets can be named or renamed but 'special names' have to match in scripts and the string table index value. Most configurable assets define an interface variable which serve to replace the default name as an index or look-up table referenced script and by the binary data of the asset. Other variables will likely be defined in a programmable asset as well. Each of these may be referenced by scripting, but it is the index value that makes it to the map or session string-table which makes everything work together when Driver or Session creator variability is desired.


 * In contrast, without the system software knowing the location of the item named in the index the objects' script will possibly have no triggering, conditional checks, or capacity to be updated. That was characteristic of objects in 2000's Trainz 1.0, not more modern Trainz railroad simulators since 2003's TRS2004 was released. (We've come a long way baby since then!)
 * There are assets which only work together as a group. In such, naming each in the map or session layer enables them to function together. For an example, consider a highway grade crossing with five tracks, two of which are off junctions and form so called 's' with the through tracks. How does one set up signals so any rail traffic closes the highway gates, or so use of diamond crossings disallows other trains to travel through the one transiting the crossing. Both road and rail signals and points and gates all have to work in concert. Certain 'ATLS system' assets and their scripts as married by the string-table can make that complicated system function.
 * See string-table-XX for further information.

string-table-XX container

 * 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 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 that list, the English string-table container is referenced instead.

kuid-table container

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


 * Generally:Only assets with sub-components or with alternative choices (Cargos) will have a kuid-table with any appreciable length. Most with sub-components only have a few.
 * Secondarily, there is a convention arising from the fact that sometimes the internal keywords are 'auto-defined'&mdash;merely listed as a number sans name, as, faux-keywords which may be any unique value (typically, zero-indexed sequential integers. ) They may be given names or not as a user or 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&mdash;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. [OTOH, This has been experienced (i.e. witnessed as a successfully fault free submitted asset in the TSxx CMs) porting maps and sessions between installs with GSARS to change kuids so overlaps would not write over assets already using the same kuid on the destination install without seeing an error message.] Whether it functioned too required a braver or more foolish soul than me! --Fabartus, ed.

kuid-table { 0           Kuid-1 1           Kuid-2 3           Kuid-3 ...         kuid-ii N-1        Kuid-N }
 * Format (all values are  format)


 * A really useful exploitation of the fact these are dummy parameters is to pair the kuids of products in a complicated rolling stock asset. A boxcar might contain all sorts of products... getting permission to assign your author ID to your own series with a different load set might be your first content creation of a significant sort! Consider a stock car, allowed products container and the kuid list could contain the following entries:

... {  Animal_chickens		 Animal_Horses		 Animal_Cows		 Animal_Piggies		 Animal_Sheep_Flock	 } ...

Note the underlines joining the words... two symbols, key and value! We let figuring out where to add the kuids to the loads and allowed products queue-table entries to the student. (Your welcome, but that's a good reason to change the names! Keeping things straight is nearly the whole battle making an asset!)

obsolete-table container

 * type: KUID list container, same format as the.
 * field definition: A 'placeholder-key&mdash;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&mdash;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 tag

 * purpose: Filters in CM and Surveyor (searching criteria)
 * type: enumerated string or string-array.
 * field definition: A list of two-character 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  and  assets, but may be supplied for any asset.


 * examples
 * 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 tag

 * 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 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.

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.
 * examples

category-era tag

 * purpose: Filters in CM and Surveyor (searching criteria)
 * type: enumerated formats string-array.
 * field definition: A list of five-character, separated by s (';').


 * Each era code represents a decade and consists of a four digit integer then must be 's' terminated 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
 * 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"
 * example

thumbnails container
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 the Railyard and surveyor asset selection APIs, which should have an Alphamask or a very light background. Many an older didn't use jpg files, but listed .tga files (Targa True Color) in a '_art' subfolder (Trainz 1.0&mdash;TC3 conventions: _art, _body, and _shadow were three subfolders mandated by early Trainz data model Requirements named 'asset-filename_suffix'(The obsolete tag- pair), which looks like the following:
 * purpose: Filters in CM and Surveyor (searching criteria)
 * type: The.
 * 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 (by generally) using a as the key name or tag. Convention makes these 0 indexed integer numbers, but the value can be any non-null text value that can be evaluated as a . (See the second example below)
 * An actual example: (from an asset fix edit )

thumbnails { Icons {   width 128 height 64 image "40ft_boxcar_art\40ft_boxcar_art_icon.texture" } CM { width 240 height 180 image "$screenshot PRR 40ft_boxcar (240).jpg" } DLS1 {  width 512 height 512 image "40ft_boxcar_art\40ft_boxcar_art_512.texture" } DLS2 {  width 512 height 512 image "$screenshot PRR 40ft_boxcar (512).jpg" } } Assets uploaded without a proper thumbnails container in TS2009's and TS2010's early versions flagged assets without a thumbnails container as faulty. Patches later turned these into warnings. which practice was dropped in a TS12 hotfix after many complaints in the user community. If the asset lacking a thumbnail container (even with the outdated thumb tag) was later chosen in a new built-in route or session, the asset will generally be distributed as an item without images&mdash;they get stripped out if not properly referenced by texture.txt or the config.txt thumbnails container.

info-url tag

 * type: URL string.
 * field definition: A link to an online description of an asset, asset instructions (help) or other help pages on the TrainzOnline wiki, intended for use from within the embedded special purpose N3V browser. The URL must resolve to a site within the . Currently there are three domains acceptable to the embedded browser:

auran.com ts2009.com ts2010.com Further, instead of linking to these domains directly, use of custom formats is recommended to future-proof the URL against possible future site layout changes. 'Short URLs' are Trainz-specific URLs which help future-proof content by allowing the content creator to reference certain pages on the N3V website without relying on a specific web layout. Short URLs are intended for in-game usage such as info-url links and will only work in the Embedded web browser and not in any external web browser. Where this tag is present, in-game buttons are provided to allow the user to view the asset description or help without leaving the game environment. This could be tremendously valuable in Driver to access a route map, guide, or session instructions or clarification. 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 tag

 * 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 tag

 * 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 container

 * type: The is a DRM, copy protection implementation used by some authors, which might as well be called the privileges DRM container.  DRM means Digital Rights Management, which is what this implements.  If defined, some of the parameters will prevent even looking at the config.txt file for the asset.
 * field definition: A set of privileges set by the asset creator to control how this asset can be manipulated.

privileges { is-payware-content 0 permit-listing 1 permit-edit 1 permit-commit 1 } The container above is set up with the default values, which says:
 * 0) This isn't payware, so other fields have relevance [when payware editing and committing will be zeros, but listing may be allowed];

allows:
 * 1) looking at the of the asset,
 * 2) editing of the asset, including seeing the contents of the component files in its home folder,
 * 3) Re-saving any changes to the asset (Committing (submitting) the re-validated asset to the database).

script tag

 * 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 tag

 * 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 container

 * 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 is a top-level  entry available to any Asset which derives from KIND TrainzBaseSpec (in short, all Assets.) This container allows the asset to directly  from the parent asset's script file(s) using the. The extensions container is a list of custom tags or subcontainers with a specific naming convention.
 * related

S-I-T container Supported Tags
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 ) 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 Validation
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 Example
script-include-table { a-key        enginespec   anim-doors   }

extensions container

 * type: The.
 * 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 at a later date, based on the extension-creator's guidelines.

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

category-keyword tag

 * 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 need not be repeated in the category-keyword list.


 * Various 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&mdash;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

custom-category-list

 * type: ascii string-array container.
 * field definition: A list of custom category identifiers, separated by semi-colons (';'). Each 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 container

 * Min-build: V3.5 and above
 * type: paired list of  and  kuids.
 * field definition: A list of assets to which this asset belongs. See the  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 tags

 * 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).

license

 * 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.)
 * Most assets on the DLS are badly worded versions of what is known as the (CC-BY-SA) like this and other Wikimedia wiki projects.
 * 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&mdash; before uploading your creation, get permission to use those pieces belonging to someone else.

author tag

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

organisation tag

 * note the British spelling, the North American spelling 'organization' also works!
 * type: UTF-8 string. (Depreciated in favor of updatable .)
 * 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 tag

 * type: string, email address. (Depreciated in favor of updatable .)
 * 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 where they can be limited or updated as necessary.

contact-website tag

 * type: URL string. (Depreciated in favor of updatable .)
 * 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 can be registered against the creator's  where they can be limited or updated as necessary.

Obsoleted tags

 * After initial compilation, some common but now obsolete tags found in older renditions of the data model have been added below such as found in many bridge assets.


 * asset-name, name, and name-XX &mdash; V1.3–v2.8 &mdash;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
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 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 tag

 * Scope: Found in 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.

casts-shadow tag

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

name and name-XX tags

 * 'name' and 'name-XX' were early data model forms of the longer and  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  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 appearing if not present.

category-era-nn tags

 * Superseded by


 * category-era-nn &mdash; V1.3–v2.8 s.a. {{TN|S|{tag: category-era-0, category-era-1, category-era-2, ...&#125;}} &mdash;a former dating system with a numeric suffix&mdash;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 string array was introduced to combine these onto a single config.txt line. 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   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 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 tags

 * Superseded by


 * types category-region-nn &mdash; V1.3–v2.8 &mdash;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 tag.
 * Replace with string-array type 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  codes followed by a ';' separator between codes, but not at the last before the terminal end-quotes.
 * Any in the string array will cause an read error, and fault message, including space(s) at the end before the trailing quotes.


 * region &mdash;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 (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&mdash;to be a . 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 . Both these tags had some benefits and drawbacks and both date back to Trainz 0.9 Beta release.

shadows tag

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

thumbnail tag
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 tag

 * type &mdash; V1.3–v2.8 &mdash;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&mdash;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&mdash;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&mdash;without giving the user capability to save multiple pick lists or easily load a filter defined and refined in CM.