From Wikibooks, open books for an open world
Jump to: navigation, search
Fundamentals for Trainz Trainees
TOC | BeginningsFun | AM&C | Creation | InBook Refs ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers
Loupe light.svg
  Mouse use
Related Introductory Trainz articles: Trainz/file formats, containers, kinds, and references

Tags are Trainz term for simple data pairings containing one elemental type of data paired with a keyword. Elemental data types or elementary data types in Trainz means text strings, single value boolean (0 or 1 only), integer (natural) or decimal (floating point) number types which are assigned legal values compatible with that data type. There are also a couple of work-around hybrid data types, which consolidated multiple string key name codes in the same single (newer) tag key name which are now assigned a range of values (referred in this work) to as a string array separated by semicolons. There is a similar array construct for tags latitude, longitude, and elevation value definitions, each containing three comma-separated floating point values.

More complex data groups used in Trainz data definitions are discussed in Trainz containers and in Trainz kinds, in and of themselves a 'container', but of a more unique type. In one sense, Trainz assets are nothing but a collection of data organized by proper enumerated codes and these containers, including the parent-classed containers known as Kinds define the interrelationship and configuration of an asset. The container is but one element in an assets self-definition as initialized by the asset creator.

Heirarchy and level[edit]

  • category-class tags
  • KINDs declaration
    KINDs in the Trainz simulators define the attribute that together with category-class set up required fields of information to make the model of an asset render properly. In a very real sense, the KIND data structure (grouping related data of disparate type relevant to the needs of model rendering and run-time simulation) is a first level container in Trainz (albeit with a special name, "KIND"), and will almost always require other container level data groups accompany it in the ini files.
  • containers and tags
    Now all container and container-like structures occupy the config.txt file, but the distinction is simply that container defined types usually have scope in several different KIND defined assets, whereas each KIND is unique to that class of asset. KIND Engines and KIND Traincar both have bogeys (wheels on trucks) so both have a bogeys container in their ini file. Tags on the other hand have local scope as a Config.txt tag, or within a container where it's purpose is the same, to define and initialize a particular single data item with a value.

Enumeration and variable values[edit]

Some values are tightly proscribed by a pre-defined list of allowed values, this is known as an enumerated type. The values in the tag category-class tags are tightly controlled, which is to say must come from a given list of allowed values on which they were enumerated (listed out). They are in-effect, alphanumeric codes which when defined, must be on the list. Other normally seen upper level Config.txt tags category-era tags and category-region tags are two tag types which are both enumerated and odd because they are both 'string-arrays' which replaces a number of listed individual tags as was the formulation in an older, now obsolescent Trainz release version.