Trainz/containers

=About Containers=
 * ''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 data larger than a single parameter normally represented in a tag, but still compliant with the mandatory for all Trainz data files. In that backdrop, Containers are complex s containing more than one elemental representing one R-value when defined properly, from the point of view of the processing software. In a pragmatic way to us humans, they are each set of related tags and values also compliant with the ACS Text Format standard, and furthermore, represent reusable grouped data definitions  which are purposely defined to be reused in more than one of Trainz Kinds. A config file and a KIND are in the abstract, both in and of themselves a 'merged-container', but together the Kind TBS and KIND create a unique type and type of container.

In one sense, Trainz assets are nothing but a collection of data organized by proper and these containers, including the parent-classed containers known as  define the interrelationship and configuration of an asset, and the behavior of the digital model in the  run-time software&mdash;the. The container is but one element in an assets self-definition as initialized by the asset creator.

Data organization
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  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&mdash; see the form, format, and examples at 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  (See  or  (See the several examples in ).

Trainz Wikibook containers
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. 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&mdash;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.

Containers that are part of the TBS

 * Where two links are listed above, the first accesses a dedicated reference page about the container type, and the second links to the 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 TBS
These are trainz config containers that are not part of the TrainzBaseSpec, but which are used by more than one of asset. Containers not part of the 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  of assets or parts of assets.
 * -- Optional definitions of a parallel spline attached to a asset, which is to say any fully updated spline asset in Trainz now since the arrival of the TS2009 data model.
 * -- 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.
 * -- Enginespec
 * -- The junction-vertices container
 * -- industrial and interactive assets; this container's definitions are used to load traincars, and unload or load commodities into industries.
 * -- Enginespec
 * -- Fundamental to any 'manifesting' asset, without a mesh, there is nothing to paint with a texture, so nothing to look at.
 * -- Added for multi-season texture alteration in spline assets (all since TB v2.9/TS2009 data model are variants of ), a new feature in TS12 (TB V3.5).
 * -- 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 its 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.
 * -- 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. Its main function is thus to keep game framerates high by reducing the number of polygonal calculations needed when an object is at increasing distances&mdash;whether close, near, farther, midway, or far off.

Kinds list in the TBS
The 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, with links duplicating the TOC above, and/or to the N3V Wiki for ease of reference.
 * are a special kind of container, for their 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  puts that judgement in jeopardy&mdash;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.