Trainz/Hierarchy Of Assets

←  Prev  Assets ↑   Trainz TOC, Trainz AM&C TOC — Introductory Trainz ↓  Hierarchy Of Assets  Next  →

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

As is often the case with software, the devil is in the details

---

When N3V Games took over responsibility for continued development of the software for the Trainz franchise in 2007, the mindset of the young programmer's was on their convenience, not of the impact their changes would have on the tens of thousands of existing assets. The preferred method of specifying asset elements EXPLICITLY by using such containers as Mesh & Bogey Tables, Thumbnails and extensions and other such containers had mostly been 'in place' by Trainz UTC

Note to newcomers

The words Assets and Content are frequently used interchangeably on the Trainz forums because they are the same except for context. In a strict technical (computer-science-defined) sense, an 'asset' needs be within a container to become 'content', which on the highest side, means it will be a dependency of a route (or map) or profile (or Session). But those assets do not report all needed dependents for they just list a series of other upper data types in association (link or call) as referenced KUIDs   The most important container to individuals is her local data base (Selected by using the 'The local content' filter (or tab) in Content Manager) which lists assets—initially just Routes and Sessions for us all; but then assets added to the code builds' base data cabinets). Some items are optional. Some rolling stock parts only apply to powered rolling stock.

Asset Organization

Trainz assets all start as data in the same folder, usually when edited, the folder wiil be named after the username listed in the mandatory parts of the TrainzBaseSpec in a config.txt file—the central data self-defining INI file that sets up each asset. As one discovers when one begins fixing faulty content two key data elements define what else must be defined inside such config.txt ini files: category-class tag, which (originally) only loosely defined certain enumerated types describing the way the content creator means for the asset to be used (e.g. various types of rolling stock, scenery, interactive trackside items like signals, etc.) and the KIND specification (mix of tags and containers specifying certain sub-elements as are necessary to define an Object Oriented Class's data elements. In the newer data models, particularly for spline objects, the category-class tag has a processing determining role, and interacts as part of the Kind Track definition, the only allowed current spline data class (That Object Oriented thinking again) and the DLS upload filters now are disallowing older spline Kinds to be uploaded.

Unfortunately the N3V programmer's see no reason to provide a translation utility, and many older content creators such as the redoubtable PhilC (his World of Trainz now closed) have quit making new content, or updating the old creations. Making spline objects such as bridges and tunnels is a much more difficult task for the CC's however much an standardized object class eases the task of the programming staff; they would appear to think the user community works for them!

First a note about asset data storage and faulty content
Many if not most content Faults in Downloaded content are due to mismatched pathspecs, that is to say, the newer digital models don't always connect with the original data conventions. Such assets work fine in older Trainz releases but many will not in the N3V Games Trainz versions until the assets are fiddled with to conform to the N3V programmers Object Oriented Programming ideals of data organization.
File Folder	normally the same name as the asset's username, unless that is duplicated
Config.txt file + KIND	merges the TrainzBaseSpec and the KIND needs into one INI file. The config file also "includes" dependencies—other asset parts with established KUIDS.
Misc root files	—other asset parts, especially common texture files used by several parts of the asset and usually, the assets screenshot file(s).
1st subfolder	—the total of such varies, as organized by the Content Creator (CC), from none to many, some Kinds have lots. Others, especially kind Scenery such as buildings or trees, often none at all.
XXn component files	—normally meshes, textures and texture.txt files, but also animation files. If there are no subfolders, these must reside in the asset root folder (where there is no need for specifying a common part, as all are in the same pathspec already). Tip: Note above about the pathspec!
iith subfolders	—varies, by conventions assets generally have three in most digital models, especially rollingstock Traincar digital models.
iiths folder component files	—normally meshes, textures and texture.txt files, but also animation files, etc.
NNth subfolder	—varies, organized by the Content Creator (CC), from none to many, but by conventions generally have three in Traincar digital models. The convention is based on how assets were organized in Trainz 1.0.
NNths component files	—normally meshes, textures and texture.txt files, but also animation files.
Common conventional Foldernames	_art, _body, night or nighmode, _shadow (the one's with underscores are very common for rolling stock assets in particular).

In Trainz, all such sub-element associations are not necessarily independent assets, but some are called references (Meaning a sub-data type, a structure with particular properties and members—but which unlike a Kind can be used as a sub-element in a variety of Kinds in a parent child relationship) and which are included in various Kinds and whose active effects (subsequent processing) are based on the tag category-class tag and the Kind specifying that child.

For those with some familiarity with object oriented programming, Trainz KINDS are class structures, and their sub-container elements have inheritance but the various mandatory needs of such subordinate multipurpose (more primitive data classed) elements are based on the KIND, not the container.

Driver Session or Scenario

Route, Map or Layout

The category-class tag is to Map, the manuals, Trainz menus and surveyor controls refer to 'Routes' and route building and route builder tools, while the Model railroading Hobbiest world refers to a Layout. In each case, it is meant the data set defining a virtual world which in Trainz starts with a single Base map board.

The following assets are attached to map assets:

Ground Textures (terrain painting, F2 tools)

Buildings (kind Scenery unless an interactive industry.)

Other structures such as, animals, animated or static people, windmills, lighthouses, etc.

Electricity pylons — formerly spline objects, now classed as Track

Vegetation — foliage scenery (trees, shrubs, flowers, field crops)

Roads — formerly spline objects, now classed as Track

Road signs and signposts (special 'trees' with verbiage and sometimes symbols!)

Vehicles, Static Road types —somewhat confusing to the new comer, these are also sometimes classed by category-class tag as buildings or scenery assets. Previously, pre-N3V Trainz had two built-in filters that affected object and component searching in CMP and Surveyor, type and region—both useful in CMP and especially in Surveyor searching, if somewhat non-uniformly defined by CC's. These tags are now illegal in TB's above v2.8 (TC3).

Track —including tunnels and spline engineered (extendable) bridges. As noted above, all spline types are now forcibly retired by DLS upload screening.

Trackside Objects —includes a ton of general content: (signals, speedboards, gantry's, electrical panels etc.)

Industries (including passenger stations)

Products

Rolling Stock

Rolling Stock, such as Locomotives (engines), passenger cars (carriages), and freight cars (wagons) are placed on a map in the Surveyor editor module, but actually are attached in the related Trainz Session module, while being enumerated (listed in a reference table of kuid codes) in the map.

These asset types are component parts of rolling stock assets:

Bogies (US English: Trucks)

Enginespec

Enginesound

Hornsound

Interior

Pantograph

HTML, media, and TrainzScript assets

Media assets in Trainz serve various functions.

Sounds —Sound file types are used to create background noises such the soft murmur of a brook, the raucous cawing of a crow, the sound of a distant church bell or a noisy bustling industrial area with jack hammers. They are essential aural scenery items, serving much the same function as a well designed three-dimensional scenery building (e.g. a Tree species, or fancy house). Many are attached and part of more dynamic objects and triggered solely when there is a specific action (The noise of a mechanical switch changing the position of junction points).

HTML Assets —

Rules —rules are little applets (often called scriptlets) fronting for a gamescript asset used inside Driver's Sessions. They provide 'software hooks' to digital model features of a route (kind map) and enable the session's coding to communicate values with the gameplay software. Such rules also often involve monitoring, storing and processing tabulated data such as a session coded to let a driver speed once but not twice without penalty, or other possible scoring interactive imagineerings.

Driver Commands —are user modifiable rules that can be changed during driving Sessions or provided as AI Drivers task commands to be executed one at a time.

• Allowed Driver Commands are controlled by the Driver Commands Rule, and that limits the optional choices to us humans in the drop down Driver Command menu when playing a session in Driver. This means if the session designer doesn't want you to navigate via a trackmark, or allow auto-coupling or decoupling, you have to modify the session in the session editor (auto-cloning the bundled route and session into your personal version) to access such a rule afterwards in the new modified session.

Scenarios supporting files

—Scenario support has been in all versions Trainz UTC to TS12 but has largely died a natural death from disuse of TrainzScript. It is not being supported in TANE.

Scenario TSO File —Scenario support file, the main program of a Trainz Scenario

Scenario GS or GSE File —Scenario support Trainz script files.

The ..\libraries and various asset folders will continue using *.gs (open source) and *.gse (encrypted) files which are also used to create certain asset features and Rules, new Driver Commands, etc., all supporting Sessions.

Notes and Footnotes

Notes

citations