Trainz/AM&C/data model

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

The Trainz Data Model

It is said that if you are going to carry digital bits around, you need a container, a bucket with a handle you can grasp to move it around and do things within its capabilities. In Trainz that bucket is the config.txt file. In that file, each line contains data pairs, a keyword and a value:
In the simplest sense, all Trainz data is organized in pairs on a data line of a text file, a keyword which tells software how to process the data which follows it. Every part of Trainz loadable into the game from the tiny bit of configuration data found in a texture (color & lighting resources) the largest route (layout or map) must have a config.txt file. All config files may contain 'any' of the keywords and containers whose meaning and legal data types are enumerated in the TBS, except most of those—can be legally skipped depending upon whether the enumerated Kinds requires that tag-value pair, but more since most TBS tags are more for human convenience than the rendering of any module. There are a handful which have paramount importance. At a minimum all configs contain an asset index the line pair of kuid--KUID, the KIND line (kind--TBS), and a (external file) reference tag--value pair. In the given case the asset defaults to the original TBV 1.3 asset technology standard, and the extern reference would be the asset-filename tag—a tag obsolescent from TRS2004 on, triggers a warning in the Trainz Classics (TBV 2.7) and one which triggers an error message above V2.9 (TS2009-SP0, fall 2008). This 'old tag elimination' enforcement first arose to prominence in the V2.7/TCC releases, wherein major changes occurred in the list of allowed tags and containers in the engine specs, steam, electric, and diesel.
There are several salient lessons in the preceding paragraph:

1. The Trainz Data Model is a moving target.
2. Exactly what it means at any given era (release) depends on previous practices as modified by new features, keywords, constraints, requirements, or methods added to the previous releases technology and practices.
3. There are quite a few tags which are solely for human convenience, such as author, organization, email, and internationalization data (language translations).

This is great news for the beginner—it means many tags and lines can be ignored. The bad news is that the trick of course is knowing which and why, and which combinations and data arrangements are illegal together.

Data arrangement 1999

Learning old data practices is alas, necessary. With any sort of significant experience in acquiring content, there will be occasions when something simply won't be acceptable to the Content Manager of the release.

In the oldest practices the reference tag required was 'asset-filename' which depending upon the kind value referenced an image file (textures) or a mesh file (an simple object skeleton). Beyond those two building block types, even a name for the asset was not required. More complex kinds however required more definitions:

1. the fact that Trainz is an international product demanded internationalization abilities, these will be easily recognizable because they all suffix a hyphen and two letter language codes to the base tags 'username', 'description', and
2. objects displayable in the run time menus required images, the standard mimicked practices in the commercial 3ds Max generated modeling world, and incorporated a sub-folder to contain such asset-filename plus

 

KINDs in the model

There is not one single data model for Trainz digital objects, but an extensive series of asset requirements that gradually grew differently for each varied kind of parts-of-models resulting to a set of data with different importance given to intrinsic changes and timings. Consider that the original Trainz 0.9 CDROM 'Beta' release happened during the Y2K run up, when some thought the computer world was about to melt down and thrust the planet into the stone ages once more. Ahem. As funny as that became, it was in those very worrisome days that Auran shipped the Beta version to their collaborators in those many world wide hobby groups for evaluation. In essence, the way that release defined modeled data sets is still much with us today. It has flexed and shed skin cells, had hair cuts, and gotten sunburned on some occasions, but the core... is still stable and recognizable within a few different data structures added to generate even more ease of capability, capacity, or flexibility. Those key improvement features, as well as the driving requests by the Trainz community while maintaining a large degree of backwards compatibility is why many users stay with the products, despite the occasional swearing-at occasion.

Definitions Under-construction

Early Trainz was an experiment in search of finding out whether there was a market niche. Consequently, while the designers and software engineers of the Game Company, Auran felt there would be such a market, no one was sure. In the event, they did due diligence, research, in contacting many railroad hobbyist groups and did a pretty fair job of putting together a specification for modeling requirements inside their proprietary JET I game engine. The evidence supporting this statement is that the controls and options, the way the software functions in the surveyor module have gone through the least evolution since Trainz 1.0 was in the research phase now over twenty years ago.

Obsoleted tags

Most of these tags began in the original Trainz release.

The following 'tag list' are 'de facto' because their 'use-convention' antedate the formal compilation of the above listed TBS tags but not the specification for using them, and indeed, also antedates the coining of the term TrainzBaseSpec (introduced with the TrainzOnline Wiki in 2008-2009), or it's formal definition in the N3V Wiki pages 11:32, 12 May 2009.

Editor's note: These 'TrainzBaseSpec tags' are obsolescent by programmer fiat in some cases with TB V2.7, and in all cases, after TS2009-SP0 and all N3V Games releases after it (despite the utility that many users found in some of them, the time penalties it would impose on the content creators, nor the ability to just ignore those no longer useful in a preprocessing operation) and will generate Faults (error messages) if the asset is opened for edit and partially upgraded by raising the trainz-build tags to V2.9 and greater data models. Conversely, by keeping the TB value sufficiently low, removal of said tags is unnecessary (at least up through TS12). Assets may be upgraded to V2.8 and before locally, and most often made to work, even when given several generations of data model elements improvements, then operate normally. It this way many assets can be made to function with TRS2004 or TRS2006 data modeling, yet be conformable with TS-releases in-processing and rendering. Experience shows an older asset made warning and fault free at trainz-build 2.6 (TRS2006-SP1) will generally work without further change in TS09-TS12. The exception are the programmer gaffs introduced in the parsing of TS09, left uncorrected until TS12 restoring the prior status-quo-ante: Single Track Bridges and tunnels in those versions need a second (and incorrect) parameter for track offsets and track-direction parameters, and the enginespec For example, most pre-TRS era data model assets (v1.0–v2.3) can be made to work in the TS releases simply by adding a mesh-table to replace the ignored former effects of 'asset-filename' as ignored in the TSes. Conversely, often TS-release assets with TBs v2.9 and above can be back-fitted to work with earlier data models by understanding the effects and use of some of these tags, and a little judicious alteration to eliminate texture.txt modifier lines (e.g. AlphaHint needs commented out, etc.) which are not understood by earlier versions.

• asset-name, name, and name-XX — V1.3–v2.8 —found historically in virtually all scenery, spines, and Trackside assets. Asset-name was the primary folder name for the asset in the Trainz 1.x--TRS2004 Trainz era; within such assets today one generally finds the asset-name is also used for that early-Trainz era's data sub-folder's system, giving sub-folder names 'asset-name_art', 'asset-name_body', 'asset-name_shadow' in a traincar asset, and perhaps others in other types.

 

• 'name' and 'name-XX' were early forms of the longer tags username and username-XX, the XX representing ISO two letter suffixes of non-English language translations of the English 'name tag' (or today's 'username' tag); the 'XX' forms as with description-XX being part of 'Localisation' support for other language's user-friendly values.

• Replace with username and username-XX in oldest Trainz era (v1.0-v2.4) assets if present, or delete.

Note: Username (English) is the official asset name on the DLS, and should never be in a foreign language; it also supersedes and replaces 'asset-filename'. Subfolder names by convention will have pathspec names beginning with the username/asset-name field and utilize the suffixes _art, _body, and _shadow as part of the normal naming conventions. This may be a 3ds Max and gmax convention carried over into Trainz, which has historical ties to said graphics development software. (Gmax was bundled with Trainz releases V0.9—v2.4)

 

• category-era-nn — V1.3–v2.8 s.a. {tag: category-era-0, category-era-1, category-era-2, ...} —a former dating system with a numeric suffix—found historically in virtually all date-worthy assets upto Trainz-build 2.4 when the current category-era string array was introduced to combine these onto a single config.txt line. While not directly accessible in Surveyor, after TR06 and CMP, one could define a filter to select a date range and use that filter along with region and type in Surveyor to vett assets that were listable in Surveyor's placement and selection tools. Obsoleted in and after TS09 which uses the shorter category-era string array in a single line instead of using multiple '-nn' suffixed tag-value pairs.

• Whitespace in the string array will cause an error; all values must be suffixed with an 's' and have four digits, s.a. 1880s;1950s;2010s (which might be wholly appropriate for a woman's garment of certain types that go in and out of fashion!). Defining a range is alas, not currently possible, but has been requested by the user community.

• Replace with string-array type category-era tag with no whitespace and semi-colons between date codes; these are given as full four digit decade numbers followed by a 's' (Small Ess) suffix.

 

• types category-region-nn — V1.3–v2.8 —found historically in virtually all locale-worthy assets. These have been superceded by the 'string-array' of two letter enumerated ISO country codes in the category-region tag.

• Replace with string-array type category-region with no whitespace and semi-colons between the two character country codes enumerated in that referenced tag section; these are given as full two uppercase letters comprising enumerated codes followed by a ';' separator between codes, but not at the last before the terminal end-quotes.
• Any whitespace in the string array will cause an read error, and fault message, including space(s) at the end before the trailing quotes.

 

• region —valid part of TBS V1.3–v2.8 as a built-in filter and Map asset custom localization identifier (kuid); now the only legal tag use is in kind map (layout) assets.

 

• See current use of this tag below in Region tags in config.txt files.

As a former filter modifier, the tag is found historically in virtually all older assets, but it was especially prevalent in rolling stock, scenery, spline assets, Track types (including tunnels and bridges) and Trackside assets with a degree of localisation.

• Map assets still retain the keyword Region which was defined in Map configs with a contrary use—to be a kind region kuid reference. Hence, Region is required in Maps, and since TRS2012, like the tag type, illegal in the very large number of assets where it once occurred as data.
• Any region tag to a text string is obsolete after the TRS2009, as in the programmer's mind they replaced the crude filtering group selector of 'type and region' string-values in the Surveyor tools with the Pick List. Both these tags had some benefits and drawbacks and both date back to Trainz 0.9 Beta release.

• type — V1.3–v2.8 —a former filter modifier, and found historically in virtually all assets, but were especially prevalent in rolling stock, scenery, spines, Track types (including tunnels and bridges) and Trackside assets. Type was used in Trainz 0.9—TC3 releases as an in Surveyor filter which combined with region, gave groups of assets instead of being overwhelmed by a whole list of placement tool selections. Both defaulted to 'All' giving the same mega-list as tools do in TS09 and after.

• Every type tag is obsolete after the TRS2006 spinoffs (i.e. TC3), as in the programmer's mind they replaced the crude filtering group selector of 'type and region' in the Surveyor tools with the TS09 Pick List.

Region tags in config.txt files

Region tags, a Surveyor quick sort-by-grouping-tag filter implemented as part of Trainz are no longer acceptable tags in TS2009 and later Trainz versions, outside the kind map assets (where they are still a KUID reference, not a filter). category-region tag, specified by two-letter codes, are still used to aid sorting in CM and Surveyor modules.

The region keyword is now limited to a legal presence in only kind map config files, where they are specified as a kuid to a predefined 'cookbook' region setting various geographic and era specific criteria such as lists of Trainz Carz automatically generated on the roads, the carrate value-dictating the density and frequency of said Trainz Carz generated, the base altitude, latitude, longitude co-ordinates and such regional variables that could be bundled rationally together now; these keywords and the purpose have been stable—in use both historically, and in the newer TS2009-TS2012+TANE data models). One of the quickest ways to give a Route a different feel, is to point to another kind region kuid—the sun angle changes, as does the seasonal look, the cars on the map change and so forth.