Jump to content

Trainz/tags

From Wikibooks, open books for an open world
logo
Fundamentals for Trainz Trainees
TOC | BeginningsFun | 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

  1. text strings,
  2. Boolean number types (0 or 1 only, always proscribed single values assessed as True or False)[note 1],
  3. 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.
  4. 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.[note 2]

Hybrid data types

[edit | edit source]

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.

  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.[note 3]

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 | edit source]
  • 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

[edit | edit source]

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 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.
  2. 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?[note 6] Understand what the tag does, and it's meaning will become obvious.


Important Everyday Tags

[edit | edit source]

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

Scenery Kinds

[edit | edit source]

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

[edit | edit source]
  • Basic cars that don't interact with users, industries or those that do!