TBS Standard definitions

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 tag

type: string.

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

kuid tag

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

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.

KUID2

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 tag

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 onto^3rd' 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!!?)

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

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 tags

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

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

kuid-table container

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
 }

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 container

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.^{[note 4]}
• 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 tag

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.

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

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.

examples

category-era tag

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 5]}
• 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.

example

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

thumbnails container

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 (by generally) using a placeholder parameter as the key name or tag.^{[note 6]} Convention makes these 0 indexed integer numbers, but the value can be any non-null text value that can be evaluated as a string. (See the second example below)

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 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—TC3 conventions: _art, _body, and _shadow were three subfolders mandated by early Trainz data model Requirements named 'asset-filename_suffix'(The obsolete tag-<value> pair), which looks like the following^{[note 7]}:

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.^{[note 8]} 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—they get stripped out if not properly referenced by texture.txt or the config.txt thumbnails container^{[note 9]}.  

info-url tag

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

related

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

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

extensions container

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.

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

custom-category-list

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 container

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.  

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 Creative Commons Share Alike with Attribution (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— before uploading your creation, get permission to use those pieces belonging to someone else.

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 tag

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 tag

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 tag

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 tag

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.

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

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 tag

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

name and name-XX tags

• '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.

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 tags

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 10]}. 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 tags

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 tag

see bendy above, depreciated/obsolete pre-TS2009 legacy kind track 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 — 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.

Footnotes