Trainz/tags


 * Related Introductory Trainz articles and reference pages:   Trainz/ACS Text_Format, Trainz data model, Assets & Content, Acquiring Content, Trainz/containers, Trainz/Kinds, and

Tags are Trainz term for simple containing one  elemental  paired with a reserved keyword. In Trainz data pairs, the keyword always precedes the data on a line. Elemental data types or elementary data types in Trainz means all of which are assigned legal values compatible with that data type.
 * 1)  number types (0 or 1 only, always proscribed single values assessed as True or False),
 * 2) integer (natural or counting) number types; these are used to record discreet quantities such as seven pallets, or 55 kilograms.  Values in Trainz data are almost universally metric, so meters and kg units are defaults.
 * 3) or decimal (aka floating point) number types for more complex data with widely varying analog data such as brake volume of air flow per second in a traincars braking plumbing (part of an enginespec,  which also models factors such as rolling friction, air resistance, Steam generation, flow rates and a host of others unsuitable for simple counting numbers.)
 * 1) or decimal (aka floating point) number types for more complex data with widely varying analog data such as brake volume of air flow per second in a traincars braking plumbing (part of an enginespec,  which also models factors such as rolling friction, air resistance, Steam generation, flow rates and a host of others unsuitable for simple counting numbers.)

Hybrid data types
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 to as a string array separated by semicolons. 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 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.
 * 1) These contain sorting criteria interesting to prototypers but disdained by the programmers to handle eras and regional distributions.
 * 2) There is a similar array construct for co-ordinate oriented tags such as latitude, longitude, and elevation value definitions (and many of which are vector quantities), each containing three comma-separated floating point values sometimes seen organized as a string array inside quotes.

Heirarchy and level

 * config.txt files/Config.txt file/Config.txt files
 * KINDs declarationKINDs 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 in Trainz (albeit with a special name, "KIND"), and will almost always require other container level data groups accompany it in the ini files. These are often included by reference (using a KUID, sharing a component amongst various digital models or prototypes.
 * containers and tagsNow all container and container-like structures will be placed in the MODELS' config.txt file, excepting only the external containers of seasons and LOD (LM.txt files), but the distinction between KINDs and Containers is simply that container types usually have scope in several different KIND assets defining specific parameters, whereas each KIND is unique and indeed, its needs (mandatory parameters) literally define that class of asset to the game engine.

Enumeration and variable values
Some values are tightly proscribed by a pre-defined list of allowed values, this is known as an enumerated type.
 * 1) The values in the tag  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.
 * 2) Other normally seen upper level Config.txt tags  and  are two tag types which are both enumerated and odd because they are both 'string-arrays'&mdash;both of which replace a variable and uncertain number of listed individual tags (to which a numeric suffix was appended) as was the formulation in many an older, but now obsolescent Trainz release version. But the data arrangements live on in the DLS and in many many dependent assets.

Most other tags have even less options, notable amongst these are tags requiring a, a 0 or 1 binary weighted value; generally these are yes/no or true/false keywords defining which part of two options in a decision tree the processing software should branch to.


 * For example, consider these very commonly seen config tags: ; can you begin to guess (by their names) which might be defining decimal values, a yes-no (or a do/don't do this) condition, and which may want a small selection of alternative proscribed and enumerated values? Understand what the tag does, and it's meaning will become obvious.

Important Everyday Tags
The answer is dependent upon what sort of assets you are dealing with at the moment.

Scenery Kinds
These are generally simpler so we use these to introduce the use of Kinds, and with scenery,
 * Kind scenery, kind scenery with track, kind buidable

Freight Cars

 * Basic cars that don't interact with users, industries or those that do!