# Trainz/tags

Back to the Top
* Fundamentals for Trainz Trainees
* 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 :
       Related Introductory Trainz articles and reference pages:  Trainz/ACS Text_Format, Trainz data model, Assets & Content, Acquiring Content, Trainz/containers, Trainz/Kinds, and references
Tags are Trainz term for simple data pairings containing one elemental type of data 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
* text strings,
* Boolean number types (0 or 1 only, always proscribed single values assessed as True or False),
* 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.
* 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, kind engine which also models factors such as rolling friction, air resistance, Steam generation, flow rates and a host of others unsuitable for simple counting numbers.)
all of which are assigned legal values compatible with that data type.

### 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.
* These contain sorting criteria interesting to prototypers but disdained by the programmers to handle eras and regional distributions.
* 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.
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.

## Hierarchy and level

* config.txt files/Config.txt file/Config.txt files
   * references
      * 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. These are often included by reference (using a KUID, sharing a component amongst various digital models or prototypes.
      * containers and tags Now 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.
* 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'—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 Boolean value, 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: night, engine, nightmode, lamp, auto-create, start, period, rate, velocity, lifetime, minsize, and maxsize; 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!
* ↑ The trick is knowing whether a value is an integer (count) or a boolean value. That requires knowing what the tag's purpose is because the Trainz keywords do not carry a data-type prefix pairing a NAMCON with any data types.
* ↑ One other caution on strings--NOT ONE is ever tolerable to Trainz if it has any trailing whitespace before the closing quote and is not something for us humans to communicate with another human (e.g. licenses, descriptions, authors, website and other strings Programmer's would prefer never occurred), this DOES NOT APPLY.
* ↑ Any number set off by a proper keyword in context does not need quotes, yet many an older asset had folks using quotes in virtually every line, including enclosing KUID tag references to component (dependencies). That said, any text value, including attachment point names and other ties to software need be in quotes, as do filenames. In general, based on fixing 2,000+ assets in various releases, Trainz parsing has always been smart enough to strip off unnecessary quotes, while versions earlier than TS09 were downright nasty if one was missing somewhere! What the parser did to mangle a config with a missing or misplaced quote is simply incredible.
* ↑ Unlike the bogeys note following, a loco without an Enginespec will not run in Trainz, and newer Trainz releases won't let you select and place it in Surveyor or a Quickdrive menu).
* ↑ A session will run without a bogey on a traincar; I've experienced a loco in the Northbay County session of TRS2006 where Auran forgot to include the bogey in the built-in library. It took me a year and a half before I ever noticed the lack!
* ↑ The last seven are tags in a very common container, the smoke container and are floating point data types taking decimal values, including accel which is an array of three vectors defining the movement of smokes in three dimensions. Of the others, most are simple enums with only a few legal values and over half are boolean.