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.
|
|||
|
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.
| 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
edit- 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
edit- 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.
- 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.
- 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'"[note 1] |
| 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
editAll 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.[note 2] 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.
Localisation
edit- 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.)
Common Containers
editRelated Links
edit
Notes, Footnotes & References
editConfig.txt files are endemic and ever present in Trainz assets, for no asset can be defined without this type of Computer Science container.
Notes
edit- ↑ Most Content Creators pay little enough attention to providing clear, well thought out description text in English. The use of these tags is minimal in assets originating in non-English locales.
- ↑ Note: This list is 'wikified' on the N3V TrainzOnline Wiki, meaning the first letter has been capitalized after the word 'KIND', whereas actual data tag names in config.txt files are all lower case text. That wiki also uses double quotes in quite a few terms, a practice which we'll spare you from experiencing herein.
- ↑ The 'kind consist' is not often seen directly, it sort of only lives in menus and the Content Manager lists.
Footnotes
edit
References
edit- 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
| This reference page is adapted from the TrainzOnline Wiki under the CC-BY-SA 3.0 License. This page will likely include more textual explanations, exposition, history, and/or examples than [online.ts2009.com/mediaWiki/index.php/Config.txt_file the source page on the same topic]. The TrainzOnline Wiki is for the most part maintained by the programmers or knowledgeable content creators and may have newer more up-to-date information on the current trainz-build code standards, which have some tendency to change as features are added to the software. |