Open main menu

Wikibooks β


< Trainz
Fundamentals for Trainz Trainees

Introduction to Trainz Containers data elements
TOC | BeginningsFun | AM&C | Creation | InBook Refs ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers
Loupe light.svg
 Mouse use


Containers TOCEdit

[e ]
KINDs (type asset groups)
and containers

Containers that are part of the TBSEdit

  1. extensions container, extensions
  2. kuid-table container
  3. member-of-groups container
  4. obsolete-table container
  5. privileges container
  6. script-include-table container
  7. thumbnails container, thumbnails container


  • Where two links are listed above, the first accesses a dedicated reference page about the container type, and the second links to the TrainzBaseSpec (TrainzBaseSpec) section covering the container's keyword (name). Most of the above links will navigate to the proper section of the TBS.

Containers not part of the TBSEdit

These are Trainz Config Containers that are not part of the TrainzBaseSpec, but which are used by more than one Kinds of asset. Containers not part of the TrainzBaseSpec are the norm, not the exception, for containers have been defined to be multipurpose sub-groups of data used for the self-definition of more than one sort of KINDs of assets or parts of assets.

  • attached-splines container -- Optional definitions of a parallel spline attached to a kind track asset, which is to say any fully updated spline asset in Trainz now since the arrival of the TS2009 data model.
  • bogeys container -- also called trucks in some railroading sub-cultures, Trainz uses bogeyNN notation for which set of wheels is arranged where on the frame, and other modifiers to orient, slide, or spin the wheelsets. The bogeys container is endemic to traincar classed assets.
  • flowsize container -- Enginespec
  • junction-vertices container -- The junction-vertices container
  • queues container -- industrial and interactive assets; this container's definitions are used to load traincars, and unload or load commodities into industries.
  • volume container -- Enginespec
  • mesh-table container -- Fundamental to any 'manifesting' asset, without a mesh, there is nothing to paint with a texture, so nothing to look at.
  • season-selector container -- Added for multi-season texture alteration in spline assets (all since TB v2.9/TS2009 data model are variants of kind Track), a new feature in TS12 (TB V3.5).
  • smoke container -- One of the oldest container types. Smokes and vapors abound around a trainyard from the gush of water out of a spigot to the acrid pine plume capping that trackside ranch house's chimney; semi-transparent filmy thingys make for many effects that are almost magical. Anyone for smoke and mirrors to aid believability? This sort of container finds it's way into all sorts of assets. More than one earns an NN number as a suffix forming smoke0, smoke1, smoke2, ..., smokeNN as an asset needs. Smokes are also interactive and have various interfaces with software, the smoke container definitions form part of such software linkages.
  • track-lod-tree container -- New in the TS2009 data model changes, the track-lod-tree container is used to present decision parameters for choosing between a higher resolution and lower poly mesh. In practice, it is often used recursively giving rendering software choices between three or more meshes in an LOD series. It's main function is thus to keep game framerates high by reducing the number of polygonal calculations needed when an object is at increasing distances—whether close, near, farther, midway, or far off.


Kinds list in the TBSEdit

The TrainzBaseSpec (TrainzBaseSpec) is a comprehensive list of all Trainz data model tags and containers which are mandatory or optional in any and all trainz assets. The part recapped below lists the KINDs in the Trainz data model, with links duplicating the TOC above, and/or to the N3V Wiki for ease of reference.

  • KINDs are a special kind of container, for their defines also include tags which stealthily sneak into the tags hiding in the config.txt files, and so seem not to be contained at all. Defining the kind tag puts that judgement in jeopardy—by defining the kind, it is as if a programmer had added an include file in an high level language. One in this case, requiring a manual addition, instead of the text read of a true include file.
  • Things which are tags in the KIND define, are also tags in the config file. Grasp that, and half the battle's won.

Kinds of KINDsEdit

All the below Child Classes are considered to have the TrainzBaseSpec as their Parent Class of data.[note 1] Kinds below which are underlined are legacy kinds antedating changes to the Trainz data model in the release of TS2009 (i.e. since late 2008), with only gradual (incremental) changes imposed since by the N3V programmers. Details for fixing assets based on these legacy kinds can currently be found in the Content Creator's Guide section of the N3V Trainz Wiki TrainzOnline site here with illuminating examples of legacy Kinds here. Perusal of the CCG (the one online is the TC1&2/TC3 version, containing the altered Enginespecs Locomotive kinds from the TRS2004/TRS2006 AND UTC data models.) is highly recommended to any users of the Trainz Download Station or anyone contemplating creating content.

TrainzBaseSpec Child Class KINDs (type asset groups)



About ContainersEdit

For the technical background of Trainz containers, see Trainz/AM&C/containers.
This page lists the '
reference pages links' of specific Trainz containers covered by this Wikibook after a brief introduction of their role in the Trainz data model.

Containers are Trainz term for complex data structures containing more than one elemental type of data but data groups which might be used in more than one of 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, and the behavior of the digital model in the GUI run-time software—the game engine. The container is but one element in an assets self-definition as initialized by the asset creator.

P train grey.png
Recall from elementary math:

{X: A, B, C, ..., xx} is read as "The set 'X' of legal values that are one of: list of valid data values."

Data organizationEdit

All Trainz data is represented by a key-word and a value. Containers are identified by a unique enumerated key-word (identifier) and for a container, all the values within the paired curly braces '{' and '}' are in the abstract, the value of the container key-word. Within, again, all elements are paired values, often again a keyword and a value.  

Within many containers (or in practice, a sub-container— see the form, format, and examples at thumbnails for an oft seen and easy to understand representation and example) the keyword is a de facto variable (non-enumerated and undeclared, unconstrained) and are usually by convention represented as a simple integer {X: 1, 2, 3, ..., nn} followed by whitespace and 'the value' as the right hand column in the config.txt file, which defines the data value.  

These are called 'dummy parameters' or 'dummy key-words', or 'pseudo-keywords' and a content creator might easily instead use {X: A, B, C, ..., xx} or {X: throttle1, throttle2, throttle3, ..., tt}, for in such cases, in all containers in fact, the value(s) is (are) being ordered and organized to fill a KIND dependent physical address in memory, normally part of an array (See throttle-power container or list (See the several examples in thumbnails container).


Trainz Wikibook containersEdit

The Trainz Wikibook and the N3V Games TrainzOnline wiki (or Trainz Wiki) have different focus and purpose. The TrainzOnline pages are meant to be a technical specification and reference for the benefit of content creators, and a means of communication of the data needed by the run time software for an asset to operate correctly inside the Trainz GUIs. It serves as a terse guideline to content definitions.

Here in the Trainz Wikibook our focus is on providing elementary introductory material through intermediate and some times advanced knowledge—to imparting understanding, and helping new Trainzers and old have a more verbose exposition of the ins and outs of Trainz. The costs and man-power of a small business struggling to make ends meet constrains the Trainz Wiki, which of necessity must be authoritative. We strive here for the same degree of accuracy, but also for a bigger picture and necessarily have a time lag for some changes introduced in the course of the ever ongoing evolution of Trainz. This product wouldn't have survived without such change, and while it makes it hard to 'catch up', it also makes the Trainz experience an ever improving one.  

When and if we deem a topic needful of additional exposition and lacking a cohesive build up of fundamental knowledge, we amplify the pages of the TrainzOnline Wiki with additional information, explanations, examples and hopefully aid understanding where the stricter terser writing is undesired by the N3V programmers who oversee the Trsinz Wiki. The following is a table of contents for our container pages to date. Below that you will see a recap of some key fundamental material in the TrainzBaseSpec.

Notes and footnotesEdit


  1. Note: This list is 'wikified' on the N3V TrainzOnline Wiki, meaning the first letter has been capitalized after the word 'KIND', whereas actual data tag names in config.txt files are all lower case text. That wiki also uses double quotes in quite a few terms, a practice which we'll spare you from experiencing herein.