|
|||
|
| 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, written under the Windows operating system that bucket is the data folder or directory, which all Trainz versions turn into a set of folder arranged in a tree hierarchy.
The early Trainz releases established a hierarchy of folders relative to the game root folder path that was relatively rigid. Certain types of assets were mandated to put data in a specific place so the asset would work. The good news is the head of that path wasn't forced (dictated), so instead of hiding the data three or four layers deep in some schema defined by Microsoft, the path could be started in the root of a main hard drive, or on a different hard drive[note 1] and unlike many software installations the user could and can still give each install's a folder name of her choice in whatever root path she deems appropriate.
Trainz Utility Manager
In all Trainz releases, the boss in an asset folder is the asset's config.txt file. In that file, each line (sic) contains data pairs, a 'keyword' and a paired 'value'. Legally formatted tags (keywords) and container names begin in the left margin. Within a container, which is set off by paired curly braces:
keyword-containername {
indented words and container guts
}
the trailing & matching closing curly-parenthesis needs to balance. CONVENTION has it under the first letter and lined up with the keyword's first letter. Given that some containers can go hundreds of lines, you must wonder how we can still say "each line (sic) contains data pairs, a 'keyword' and a paired 'value'." The answer is both procedural and conceptual; it is procedural and the keyword being a container name passes control to a handler subroutine. These handlers know where to put data associated with the keywords legal to that sort of container, and how to find the next non-white character which is evaluated as tag, value or brace, then repeat as needed until it finds a closing brace which pairs to the brace following the first (opening) curly brace. So long as each keyword, internal brace (Yes, Matilda, there are containers with subcontainers, and containers with a variable number of subcontainers. Thanks for asking!) is whitespace separated, and legal in 'expectable context', all the subcontainers of a large long
- 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. Trainz milieu is inside computers, so no surprise that those files address and list other files.
- You probably know, suspect, or have heard Trainz uses various kinds of image files to texture objects. These have varying strengths, capabilities, and size impacts, but are common types; excluding the newest post-TANE types, 99.99% of the 500,000+ assets downloadable from the DLS rely on combinations of .JPG files, .TGA files, and Windows own .BMP files, nowadays, all common file types. Of these the TGA format, invented for commercial applications in graphics arts and television is likely the least familiar —and was hardest to find graphics editors to process.
Was because the popularity of digital gaming required the masking/transparency Alpha Channel or layer behind their capabilities to blend with other projected images. - There are files with 'How-To' apply a texture — these carry the suffix: .texture.txt
- You probably know, suspect, or have heard Trainz uses various kinds of image files to texture objects. These have varying strengths, capabilities, and size impacts, but are common types; excluding the newest post-TANE types, 99.99% of the 500,000+ assets downloadable from the DLS rely on combinations of .JPG files, .TGA files, and Windows own .BMP files, nowadays, all common file types. Of these the TGA format, invented for commercial applications in graphics arts and television is likely the least familiar —and was hardest to find graphics editors to process.
- 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.
- In the given minimal lines 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:
- The Trainz Data Model is a moving target.
- 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.
- 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:
- 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
- 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.
 |
|
 |
|
- 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.
|
|
- 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[note 2]). 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.
- ↑ This writer has a desktop computer with Trainz installs (version and variants) installed on four different hard drives
- ↑ Hence, a region tag in maps was an entirely different keyword use with scope only in that kind, whereas the discontinued region tags were essentially part of the TrainzBaseSpec and could be used in any Trainz Asset KINDs.
- ↑ Christoph Bergman, N3V Games chief programmer, aka 'Windwalkr', KIND TrainzBaseSpec history page.