Trainz/AM&C/containers

↑   Containers TOC — Trainz Config Container ↓

Fundamentals for Trainz Trainees Trainz Asset Maintenance and Creation

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

[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 in CS

A 'container' in the realm of computer science (CS) is a typed variable which holds other values. A primitive type is an data element of the language (with a correspondence to binary machine storage types) and is used to define more complex types when combined in a container such as an array (a indexed list container with all enclosed data elements of the same kind). The 'variable' is a keyword (a symbolic reference) used as a 'human-convenient handle' for referencing the data elements of the type within, whatever types they may be. In general Computer Science, the variable values can be altered and redefined while in Trainz certain keyword names are variable and the data fixed by the Content Creator (CC)) in the config files.

That is in Trainz, containers are enumerated data types which act as keywords followed by pairs of curly braces ({ and }) enclosing the contained data within but some Trainz enumerated container types may occur in multiple instances and so are sub-scripted by appending a numeric index when more than one is needed such as (the commonly seen effects containers) smoke0, smoke1, ..., smokeii.

At the base level--where things are machine dependent: nibbles make up bytes, bytes make up short words, short words make up long words, and (sometimes both short and) long words can be doubled, quadrupled (x4), quintupled (x5) or bundled into larger blocks of bytes given interpretation at the machine code level by the program's conventions for assigning and defining types.
The list above are all primitive types the hardware can manage, the interpretation and program handling of them as a language primitive type is the function of the compiler writers. A high level language when adapted to a computer architecture then uses these machine primitives to define it's language specific data elements or primative types. Other more complex types are all defined in terms of those.
Applications programs rely on those definitions for types such as characters (this text), integers (no fractions, please!), floating point values (decimals in base 10 represented in base 2 --binary or machine form). These Computer Languages must of necessity also have matching primitives, known as pointers to describe the memory address (or physical address) of any and all data elements of each of those primitives. If the element cannot be directly accessed in a random access operation, it is not a discrete element which makes it part of a larger element--a container which holds it's physical state.
In bitwise arithmetic, an integer will frequently be used with particular bits having an associated meaning. These are said to be flags, and together with a bit mask are often used as classifications (is part of this set, satisfies this condition, meets or doesn't meet this test) for determination of further processing. These are YES-NO or TRUE-FALSE evaluations, operations of boolean logic.

When the data primitives need to be handled in bunches, a container type is used.

• A string is a container containing characters that are not meant to be processed as numeric data, or simply text; though the legal representation of text depends on how the text is coded (unicode, ASCII, BOM, etc.).
• An array, an indexed randomly accessible group of values is another type of container. The array of a type (integer, strings, etc.) can hold elements of each matching primitive type. At the machine level, the beginning of the array is an address ('A'), the value at that address is the first element which can hold a value of that type. The next element is offset by the length (L) of the type of data in bytes—the lowest data form which can be individually addressed (indexed for random access)— so the (address of the first element + L) or (A + L) gives the address of the next element. This can be written with an index or cursor variable 'I' so that the Nth element, where I= (N-1) can be addressed by A_i = (A + L * I) often represented by V[i], where V is a variable name. The maximum number of elements in an array is thus N, since the V[0] must be a offset in address arithmetic of zero, and V[N] is an illegal index for it calculates an address in another place in memory not allocated to the array. V[N-1] is thus the last element of N declared memory addresses L bytes in length.
• A matrix

Trainz containers

1. An asset or content is a file folder on the OS file system containing the self-definition files for itself, and which are then incorporated into the Trainz data base as managed by TrainzUtil and Content Manager. Most assets require component parts, or other assets to completely render a digital model, or a run time asset such as Trainz sessions and Routes.
   1. Surveyor module is used to build gameplay worlds on a kind Map (a 'Layout' or 'Route' asset) by placing such content/assets on the Map's Data Base—which is all incorporated in the maps KUID folder, which keeps it all organized.
   2. The Surveyor module' Session Editor is also used to write Sessions which combine Rules representing Scriptletts that are compiled into run time code to create a 'scenario' for game play stored in a Session's KUID folder as a kind profile. These are significantly different in composition and capability from the historic 'Scenarios' type which are pre-scripted in a TrainzScript application and saved as Activities. KIND Activities were discontinued after TS2012, and the menu button for launching them doesn't show up unless one is in the data base.
2. All assets contain a header or self-definitions file Trainz calls config.txt, a resource organizing and parameters declaring text file without which the asset self-definition fails, or has Faults per the spin N3V twists the term to mean.
3. A .cdp file (or .cdp2, .cdpa variations) is another trains container, a portable compressed data collection we receive from other Trainzer, across Trainz versions by export and import, and the data form uploaded and downloaded from the DLS.
4. A Trainz container is an enumerated (defined and constrained) data structure of a complex type, which may include tags, often dummy tags, and values or references (KUIDS) as well as sub-containers container.
   1. They often contain variable length (to the CC) array declarations (passenger attachment point pass parameters) which are used to allocate actual memory and initialization values as modified by the accompanying defining tags in the same structure or by inheritance from the parent container.
   2. What containers are legal in a config, depends on the asset KIND tag definition.
   3. Include files are a computer science class implemented in Trainz by texture.txt files and by reference, meaning listing a KUID of a component dependency. Texture.txt files in Trainz confusingly in the config.txt declarations MUST NOT have the extension .txt, but end with .texture extensions.
   4. In the Trainz hierarchy, KINDs are an upper level complex type with implicit nesting of the necessary tags.
      1. That is just about all kind definitions add some tags in the config not nested in the paired curly braces characteristic a general kind PLUS an element that is a container in appearance.
      2. These are de facto sub-containers special to only that KIND, whereas a Trainz container type is more general purpose, so declarable and used in more than one KIND requirement. In effect, the containers are really sub-containers of KIND which satisfy the broader needs of several to many asset self-definitions.
      3. The implicit nesting is controlled by declaration of the kind tag, so KIND tags not inside it's special sub-containers can be processed correctly.