Trainz/refs/TrainzBaseSpec

Trainz Annotated Reference Pages Trainz Asset Maintenance and Creation

TOC | Beginnings | Fun | AM&C | Creation | InBook Refs | ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers

Glossary

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

Mouse use

Notations

[e]
KINDs (type asset groups) and containers
KIND Achievement-category  KIND Achievement-group  KIND Activity  KIND Asset-group  KIND Behavior  KIND Bogey  bogeys container  KIND Buildable  class library  KIND Controlset  KIND Consist  KIND Drivercharacter  KIND Drivercommand  KIND Engine [1]  KIND Enginesound  KIND Environment  extensions container, or extensions  KIND Fixedtrack  flowsize container  KIND Gameplaymenu  KIND Groundbrush  KIND Groundtexture  KIND Hornsound  KIND HTML-asset  KIND Industry [2]  KIND Interior  junction-vertices container  KIND Library [3]  kuid-table  KIND Map  KIND Mesh [4]  member-of-groups  mesh-table container  KIND Module  KIND MOCrossing [5]  KIND MOJunction [6]  KIND MOSignal [7]  KIND MOSpeedboard  obsolete-table  privileges  queues container  KIND Pantograph  KIND Product [8]  KIND Product-category [9]  KIND Profile [10]  KIND Region  season-selector container  KIND Scenariobehavior  KIND Scenery[11]  KIND Scenery-Trackside[12]  KIND SceneryWithTrack [13]  script-include-table container (TBS)  KIND Servlet  smoke container  KIND Steam-engine [14]  KIND Texture [15]  KIND Texture-group  thumbnails container, or (TBS)  KIND Track [16]  track-lod-tree container  KIND Tracksound [17]  KIND Traincar [18]  KIND TrainzBaseSpec [19]  KIND Turntable  volume container  KIND Water2

Introduction to the KIND Hierarchy

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.

• 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 config.txt 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 kind declarations and requirements, 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.

• 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 (CCP) 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 (CCG 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.

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.

Child Classes

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 — setting up the requirements for everything that gets processed after. In short, the kinds' value, a small select tightly defined members-only group — 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 TrainzBaseSpec 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 Content Creator's Guide section of the N3V Trainz Wiki TrainzOnline site here with illuminating examples of legacy Kinds here. 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—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 — 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.

TrainzBaseSpec Child Class KINDs (type asset groups)
kind achievement-category  kind achievement-group  kind activity - scenarios kind  kind asset-group  kind behavior  kind bogey []  kind buildable  kind controlset  kind consist  kind drivercharacter  kind drivercommand  kind engine [20]  kind enginesound []  kind environment  kind fixedtrack []  kind gameplaymenu  kind groundbrush - undef'd  kind groundtexture []	kind hornsound []  kind html-asset []  kind industry [21]  kind interior  kind library [22]  class library  kind map - Route kind  kind mesh [23]  kind module - undef'd  kind mocrossing [24]  kind mojunction [25]  kind mosignal [26]  kind mospeedboard  kind pantograph  kind product [27]  kind product-category [28]  kind profile [29] - session kind  kind region	kind scenariobehavior - undef'd  kind scenery[30]  kind scenery-trackside[31]  kind scenerywithtrack [32]  kind servlet  kind steam-engine [33]  kind texture [34]  kind texture-group  kind track [35]  kind trainzbasespec [36]  kind tracksound [37]  kind traincar [38]  kind turntable  kind water2

 

Table I, TBS Standard definitions

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	"'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)
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)
custom-category-list   "'string-array'"	script interfacing feature
must-have-product-rights   "'string-value'"	DRM string array
must-not-have-product-rights   "'string-value'"	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.
script-include-table     {     }	(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 Tags

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

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 three or four colon separated data-fields, but does not require brackets—though commas are required delimiters for multiple kuids in the search API Window. It is generally easier to aggregate data in the full kuid tag-ends bracketing, and generally clearer to read. For cutting and pasting a huge list, buffer size limitations may break off the end of the list, in which case, trimming out both end brackets in a text editor may allow getting the whole list into the API.

• 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 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!!?)

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 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 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 container(s).

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—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' (CTRL+F ) 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 Route maps or layouts 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 kind map).

• 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 'diamond crossings' 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 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

kuid-table   {
 numberit_library                      <kuid2:75134:99003:7>
 0                                     <kuid:-3:10164>
 1                                     <kuid:-1:42004201>
 2                                     <kuid2:50567:11155:1>
 3                                     <kuid2:58422:50120:1>
 4                                     <kuid:-3:10003>
 5                                     <kuid2:30671:94407101:1>
 6                                     <kuid2:87907:94407101:1>
 7                                     <kuid2:87907:94407103:1>
 8                                     <kuid2:87907:94407105:1>
 9                                     <kuid2:30671:9870190:1>
 10                                    <kuid2:30671:94407100:1>
 11                                    <kuid2:87907:94407100:1>
 12                                    <kuid2:87907:94407102:1>
 13                                    <kuid2:87907:94407104:1>
 14                                    <kuid:-3:10013>
 15                                    <kuid2:60318:10008:1>
 16                                    <kuid2:60318:10010:2>
 17                                    <kuid2:189041:301:1>
 18                                    <kuid2:50567:11121:1>
 19                                    <kuid2:30671:9840820:1>
 20                                    <kuid2:30671:9870899:1>
 21                                    <kuid2:50567:12646:3>
 22                                    <kuid2:124017:30000:2>
 23                                    <kuid2:124017:30001:2>
 24                                    <kuid2:124017:30002:2>
 25                                    <kuid2:124017:30003:2>
 lodi_icon                             <kuid2:124017:35000:1>
 lodi_lib                              <kuid2:124017:40000:1>
 26                                    <kuid2:30671:69006:1>
 27                                    <kuid2:124017:35000:1>
 28                                    <kuid2:30671:90810901:1>
 29                                    <kuid2:30671:9081290:1>
 30                                    <kuid2:60318:10009:1>
}

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.

 

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'—merely listed as a number sans name, as placeholder parameters, 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—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.

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' (a Pick List) 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.

• 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		<kuid:-25:230>

Animal_Horses		<kuid:-25:236>

Animal_Cows		<kuid:-25:239>

Animal_Piggies		<kuid:-25:238>

Animal_Sheep_Flock	<kuid:-25:240>

} ... 

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

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:

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—they get stripped out if not properly referenced by texture.txt or the config.txt thumbnails container.  

Software linking

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 Trainz Online Security Zone. 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 Trainz Short URL 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 privileges container 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 config.txt file 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 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.

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

 

---

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

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

 

Obsoleted tags

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.

 

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

 

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

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

 

References

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