Trainz/containers

 

←  Prev  tags ↑   references, TrainzBaseSpec, List of Tags & Containers  Kinds  Next  →

Fundamentals for Trainz Trainees Introduction to Trainz data elements-2 Containers

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

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 ACS Text Format mandatory for all Trainz data files. In that backdrop, Containers are complex data structures containing more than one elemental type of data 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 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.

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

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

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

[e]
KINDs (type asset groups) and containers
KIND Achievement-category  KIND Achievement-group  KIND Activity  KIND Asset-group  KIND Behavior  KIND Bogey  bogeys container  KIND Buildable  class library  KIND Controlset  KIND Consist  KIND Drivercharacter  KIND Drivercommand  KIND Engine [1]  KIND Enginesound  KIND Environment  extensions container, or extensions  KIND Fixedtrack  flowsize container  KIND Gameplaymenu  KIND Groundbrush  KIND Groundtexture  KIND Hornsound  KIND HTML-asset  KIND Industry [2]  KIND Interior  junction-vertices container  KIND Library [3]  kuid-table  KIND Map  KIND Mesh [4]  member-of-groups  mesh-table container  KIND Module  KIND MOCrossing [5]  KIND MOJunction [6]  KIND MOSignal [7]  KIND MOSpeedboard  obsolete-table  privileges  queues container  KIND Pantograph  KIND Product [8]  KIND Product-category [9]  KIND Profile [10]  KIND Region  season-selector container  KIND Scenariobehavior  KIND Scenery[11]  KIND Scenery-Trackside[12]  KIND SceneryWithTrack [13]  script-include-table container (TBS)  KIND Servlet  smoke container  KIND Steam-engine [14]  KIND Texture [15]  KIND Texture-group  thumbnails container, or (TBS)  KIND Track [16]  track-lod-tree container  KIND Tracksound [17]  KIND Traincar [18]  KIND TrainzBaseSpec [19]  KIND Turntable  volume container  KIND Water2

Containers that are part of the TBS

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 TBS

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 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.
• 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. 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—whether close, near, farther, midway, or far off.

 

---

Kinds list in the TBS

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 KINDs

All Trainz defined data (content) has three required elements: A config.txt file to organize the data, an identity meaning a kuid (username alone will do you no good, a legal asset however can be created without a name!) and last, a legally defined kind tag. The kind is in charge, the conductor of the orchestra, the Platoon Sargeant or CEO giving directions — setting up the requirements for everything that gets processed after. In short, the kinds' value, a small select tightly defined members-only group — tells Trainz software what is to be rendered and displayed in the virtual worlds we create, and how (or where) to find the other parts needed to make those parts of the asset linked together in that config.txt file.
  Each of the below Child Classes are considered to have the TrainzBaseSpec as their 'Parent Class' of data. A few kinds listed below, those 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 is highly recommended to any users of the Trainz Download Station or anyone contemplating creating content. The insights gained from understanding of the background history of how older content was defined can then be contrasted with the current TrainzOnline coverage of the same data type and compared, for often this kind of then-vs.-now provides valuable insights to fixing, altering and customizing assets. More to the point, the writing in the CCG was professionally produced and is far more tautological—it will often give you insights as to extended effects if this or that is altered, which the Trainz Wiki just doesn't provide. The CCG put up on TrainzOnline is the TC1&2/TC3 version — the last published of several booklets printed dating back to Trainz in 1999; the TC3 CCG contains the altered Enginespecs Locomotive assets from the TRS2004/TRS2006 AND UTC data models need to be properly updated.

TrainzBaseSpec Child Class KINDs (type asset groups)
kind achievement-category  kind achievement-group  kind activity - scenarios kind  kind asset-group  kind behavior  kind bogey []  kind buildable  kind controlset  kind consist  kind drivercharacter  kind drivercommand  kind engine [20]  kind enginesound []  kind environment  kind fixedtrack []  kind gameplaymenu  kind groundbrush - undef'd  kind groundtexture []	kind hornsound []  kind html-asset []  kind industry [21]  kind interior  kind library [22]  class library  kind map - Route kind  kind mesh [23]  kind module - undef'd  kind mocrossing [24]  kind mojunction [25]  kind mosignal [26]  kind mospeedboard  kind pantograph  kind product [27]  kind product-category [28]  kind profile [29] - session kind  kind region	kind scenariobehavior - undef'd  kind scenery[30]  kind scenery-trackside[31]  kind scenerywithtrack [32]  kind servlet  kind steam-engine [33]  kind texture [34]  kind texture-group  kind track [35]  kind trainzbasespec [36]  kind tracksound [37]  kind traincar [38]  kind turntable  kind water2