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.
This page is a stub of an intended page, its' outline, or otherwise a page in major ways temporarily incomplete relative to plans for future contents Trainz Wikibook writing and in-progress overhaul. You can help Wikibooks and the TrainzWikibook project by adding to it and expanding it.
KINDsdeclaration 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.
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.
This Trainz/tags section is a stub placeholder, an outline or marker that this section of the book is otherwise incomplete. You can help the Wikibooks Trainz project by expanding it with fuller discussion of the topic.