Trainz/containers

From Wikibooks, open books for an open world
Jump to: navigation, search
logo
Fundamentals for Trainz Trainees
Trainz | Introductory Trainz  | Trainz AM&C | Creation | Appendixes  |  References  • Containers • Kinds • Tags • Index • Vers
 Glossary
 HKeys-CM
 HKeys-DVR
 HKeys-SUR
 HKeys-WIN
 Mouse use
 Notations

Containers[edit]

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 organization[edit]

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 containers[edit]

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.

Containers TOC[edit]

Containers that are part of the TBS[edit]

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

 

Containers not part of the TBS[edit]

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 with the definition of more than one sort of KINDs of assets or parts of assets.

  • 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.
  • flowsize container -- Enginespec
  • junction-vertices container -- The junction-vertices container
  • queues container -- industrial and interactive assets
  • 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.
  • smoke container -- Smokes and vapors abound around a trainyard from the gush of water out of a spigot to the acrid pine plume capping that trackside ranchhouse'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 forms part of such linkages.
  • track-lod-tree container -- track-lod-tree container

See also:  


Kinds list in the TBS[edit]

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 TAGS 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 KINDs[edit]

All the below Child Classes are considered to have the TrainzBaseSpec as their Parent Class of data.[note 1]

TrainzBaseSpec Child Class KINDs (type asset groups)

 


Notes and footnotes[edit]

Notes[edit]

  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.

 

Footnotes[edit]