Trainz/refs/config.txt file

Intermediate and Advanced Content Creation 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

This is the more technical coverage of the Trainz ini file type known as config.txt files.

For an introduction to topic, see: Trainz/Config.txt files, for general basic knowledge building see Trainz/AM&C/config.txt files.

Regardless of Trainz release version, the release specific Trainz data model has always had the KIND data container 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.

Every content item has a single definitions file named config.txt in its folder, which determines the asset's name, identifies it's kind and specifies the KUID ID code of the item uniquely allowing data marrying and referencing from asset to asset or to the run-time software. Each config, dependent upon the asset KIND will hold as well the various kind-specific details defining that asset and any keys which allow multiple occurrences (instances) during the running of a GUI using multiples of the same asset. (Trees, traincars, houses, etc.—many of them semi-customized with script influences such as random road numbers, alternative skins, labels and other session writer defined features.)

The config.txt file (and for the most part, all text formatted Trainz file types) is stored in the ACS Text Format, which in brief defines a keyword and a value paired. Some keywords are aggregate values, in Trainz, corresponding to a container 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 Content Manager, 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: TrainzBaseSpec

The Trainz digital models are based on data definitions all of which follow the format wherein an enumerated 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—a quote setting off data or a opening-curly brace '{' which set off other specific keyword—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 subprogram (In computing, a Handler routine) 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 the matching closing brace '}' (or end-quote '"). The Kinds 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 (CamelCase) jargon becomes the TrainzBaseSpec specification—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—earlier versions were more forgiving). Thus, various config tags, both required ones and those which are optional are inherited from the kind trainzbasespec base asset type, and are described there in detail. These value types are:

Tags 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 string value) for that tag. (Example: "CA;MX;US" is a category-region define covering all of North America—Canada, Mexico, and the United States.

Containers 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 mesh-table container 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—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 commit) 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 TrainzBaseSpec (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 Kinds 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.

kind	"'string-value'"
trainz-build	'float', 1 digit decimal value
kuid	<Kuid coded value>
username	username "'string-value'"
username-XX	username-XX "'Non-English Language string-value'"
description	description "'string-value'"
description-XX	description-XX "'Non-English Language description string-value'"
kuid-table list of dependencies by kuids (container)   {   }	A key-value list of 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, But! Likely Very large in routes and sessions. (Named assets on maps are listed here, from trackmarks and triggers to signals, named buildings and industries, to sign posts.
string-table-XX by each Non-English Language (container[s])     {     }	list of translated strings matching onto mandatory string-table
category-region "'string-array'"	category-region tags
category-class "'enumerated string-value'"	category-class tags
category-era "'string-array'"	category-era tags
category-keyword "'string-array'"	natural language 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.

 

Kinds of KINDs

All Trainz defined data (content) has three required elements: A config.txt file to organize the data, an identity meaning a kuid (username alone will do you no good, a legal asset however can be created without a name!) and last, a legally defined kind tag. The kind is in charge, the conductor of the orchestra, the Platoon Sargeant or CEO giving directions — 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 [1]  kind enginesound []  kind environment  kind fixedtrack []  kind gameplaymenu  kind groundbrush - undef'd  kind groundtexture []	kind hornsound []  kind html-asset []  kind industry [2]  kind interior  kind library [3]  class library  kind map - Route kind  kind mesh [4]  kind module - undef'd  kind mocrossing [5]  kind mojunction [6]  kind mosignal [7]  kind mospeedboard  kind pantograph  kind product [8]  kind product-category [9]  kind profile [10] - session kind  kind region	kind scenariobehavior - undef'd  kind scenery[11]  kind scenery-trackside[12]  kind scenerywithtrack [13]  kind servlet  kind steam-engine [14]  kind texture [15]  kind texture-group  kind track [16]  kind trainzbasespec [17]  kind tracksound [18]  kind traincar [19]  kind turntable  kind water2

 

Localisation

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

As the ACS Text Format 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— 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.

The following standard tags support this form of localization:
where XX is the iso two character abbreviation for a language. (e.g. de=German, fr=French, it=Italian, etc.)

• username tags and username-XX tags
• description tags and description-XX tags
• string-table container and string-table-XX containers.

Common Containers

• attached-track container
• extensions container
• kuid-table container
• mesh-table container
• obsolete-table container
• string-table container
• textures container
• thumbnails container
• ... TBC

Related Links

• Config.txt files & config.txt file
• Index of Tags & Containers
• Content Configuration
• 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 Computer Science container.  

 

 

References

• Trainz printed or pdf file Manuals, applicable version - usually in the ..\extras or ..\extras\manuals folder
• TrainzOnline Wiki Config.txt file page and various other pages
• TrainzOnline Wiki Content Creator's Guide pages (various)
• Various CCG and Auran websites