Trainz/refs/config.txt file

Regardless of Trainz release version, the release specific Trainz data model has always had the in a config.txt file with an kuid identifier code as the minimal central description needs for a Trainz content item. That makes the config.txt file in a particular asset folder, the central description for any given asset; and to tighten the model, the config file defines the folder name in which it is located when the data is within the data base, and not open for editing.

The config.txt file (and for the most part, all text formatted Trainz file types) is stored in the, which in brief defines a keyword and a value paired. Some keywords are aggregate values, in Trainz, corresponding to a holding lists of such data pairs and other containers.
 * When hand-editing the file, care must be taken to use correct syntax or the meaning of parts or the entirety of the file may become permanently lost. When content is installed into Trainz, or when it is archived (in CDP Format or similar .cdpa file format) the config.txt file is stored in a machine-optimized binary format. If the content is later extracted using, the config.txt file is converted back to text format, however any custom formatting or erroneous syntax is already lost and cannot be restored.

TBS Standard Tags

 * main article: 

The Trainz digital models are based on data definitions all of which follow the format wherein an tag keyword leads a line followed on the same line by data pairings. In some more complex data allowed, the data element is just begun&mdash;a quote setting off data or a {{BL|opening-curly brace '{'}} which set off other specific keyword&mdash;data pairings. Even complex containers, some with sub-containers follow that demanded format. In that sense, containers and sub-containers each consists of a tag and a value set-off and included within matching curly-braces, a convention on loan from the C programming language. Note this complex data definition makes ready sense at the subprogram data handling level, as the tag, once recognized is used to select the apropos handling (In computing, a  ) which inputs the rest of the line (or lines) knows how to interpret the contained data following that first '{' (or quote mark glyph) until it encounters {{BL|the matching closing brace '}' (or end-quote '")}}. The  data sub-type defines the necessary unique pairings for that asset to be rendered properly inside the game engines. In contrast, a variety of tags and containers are legally available to all Trainz content definition kinds, legal in the config.txt file of that kind of asset, regardless of the specific asset type. For convenience, since TS2009's release and the inception of the TrainzOnline Wiki, this set of data keywords and often mandatory data definitions are referred to as the Trainz Base Specification (TBS), which in programmer's   becomes the  specification&mdash;a list of always legal tags, containers and their requisite definitions. Legality does not involve your local law establishment, but the Cop residing in the heart of the Content Manager and DLS error checking software routines. If the tag-value pair is out of context, for example a sub-container tag placed outside the container boundary, or is inappropriate, then the 'Cop' will generate a fault message and complaint ('indictment!') as well as flagging the asset as faulty... making it unusable until fixed (at least in later Trainz releases&mdash;earlier versions were more forgiving). Thus, various config tags, both required ones and those which are optional are inherited from the base asset type, and are described there in detail. These value types are:

or individual line-start words are 'keywords', and have a single assigned 'key-value', a correctly formatted container data structure, or sometimes that key-value is required to be organized as a quoted string-array (effectively, a container for the parameters defined by that specific tag type), usually restricted coded values (enumerated list members) separated by semicolons between quote glyphs defining single strings (a ) for that tag. ( is a  define covering all of North America&mdash;Canada, Mexico, and the United States.

 are collections of keywords and key-value pairs and possibly sub-containers. Upper-level containers (as opposed to sub-containers such as those within the thumbnails container) are required as part of a KIND specification (including KIND TBS) and high use containers, especially those which may take a variable number of sub-container elements such as the are generally suffixed by '-table'.

Last, but most importantly, there are various kinds (see list in 2nd table below or in the TBS), one to each config.txt file required and which defines those other keywords, both mandatory and optional which are needed to satisfy any definition of an asset of that type. Each kind data group thus expands the required and optional parameters, the tags and containers which must be defined there in that config.txt file in detail to correctly put together all the elements used to create a digital model&mdash;the Trainz asset. Note the Kinds are a container defining both other containers and other specific tags which must be satisfactorily defined for Content Manager's error checking to accept (and ) the asset into the data base. If the digital model isn't in the data base, it can't be displayed and used by content creators making sessions or maps.

Table-1 keys found in any config.txt

 * The following table is known 'formally' as the 'Trainz Base Specification' or (TBS) .  The TBS contains keyword and keyvalue pairs of the Trainz Data Model Specifications that might be found in any asset. Other tags and values are defined by the  tag's value, listed in Kinds of KINDS Table.


 * 1) Adding any one of these tags to a config.txt file missing such, should never cause an issue, providing your syntax (typing and spelling) is spot on.
 * 2) The tags with the suffix '-XX' are multicultural non-English Language support. The suffixes originate in an ISO standard abbreviation's list, but are often straightforward. For example: -it for Italian, -fr for French, -cz for Chech, -de for German, -es for Espanol (Spanish) and so forth.

Localisation

 * Localisation is 'academic-speak' for "Internationalization", or data translations to other languages...

As the uses UTF-8 encoding, so non-English text string entries may occur within any string field in the config.txt file, save where proscribed. (For example, the username tag is supposed to always be English, but language suffixed forms also allow for support of multiple locales in the regions languages&mdash; and to avoid confusion, the standard string tags which require localisation support effectively allow multiple entries because the run-time software uses the following conventions:


 * username - The content's human-readable name, in American English. The English name for the asset must be present, and is supposed to be defined in English. (Unfortunately, a small number of assets were uploaded without policing of that criteria, so some non-English names are found on the DLS.
 * username-cz - The content's human-readable name, in Czech.
 * username-de - The content's human-readable name, in German.
 * username-es - The content's human-readable name, in Spanish (Espanol).
 * etc.


 * and tags
 * and
 * and s.

Common Containers

 * ... TBC
 * ... TBC
 * ... TBC
 * ... TBC
 * ... TBC
 * ... TBC
 * ... TBC
 * ... TBC
 * ... TBC

Related Links

 * Config.txt files &
 * Content types
 * Content types
 * Content types

Notes, Footnotes & References
Config.txt files are endemic and ever present in Trainz assets, for no asset can be defined without this type of.