Trainz/Kinds

From Wikibooks, open books for an open world
< Trainz(Redirected from Trainz/KIND)
Jump to navigation Jump to search
logo
Fundamentals for Trainz Trainees

Trainz Annotated Reference Pages
TOC | BeginningsFun | AM&C | Creation | InBook Refs ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers
Loupe light.svg
 Glossary
 HKeys-CM
 HKeys-DVR
 HKeys-SUR
 HKeys-WIN
 Mouse use
 Notations

The Kind tag[edit]

Click Here to Quickly Navigate to the Table of Contents of KINDs

All the elements which define an Trainz Asset outside of the local Installs Data Base are contained in a single folder—the asset folder or asset source folder—either of which is accessible when the asset is opened for editing or built respectively—both involve (possibly many kinds of edits) editing and data manipulation.

 

Kinds are the special Parent data form within those asset source folders and defined within the folder's sole config.txt file. The Kind tag legal values are strictly constrained.[note 1] Each config has a kind, and each has a home in an directory holding the rest of the parts locally defined to make that asset. Hence the Asset Source Folder is also classifiable as one step above Trainz containers' general data type and each is designated-by-type as controlled by their explicit unique keyword, the Kind tag vlaue.  

Each Kind thus denotes one of the fundamental sets of enumerated basic Trainz asset types or asset kinds data classes in the self-defining self-contained Trainz Asset definitions hierarchy. The config.txt file within has the job of defining the sole KIND line's 'type of asset' data needs and aggregating those things the KIND requirements define as necessary (or optional) with the other mandatory and optional asset data definitions set by the TBS—in effect and in fact, the configs have the job of defining the Parent KIND, of merging those things needed by the other TrainzBaseSpec definition lines with the definition lines required by the Parent KIND line (kind "name") value to make an asset of type KIND as defined by setting the 'kind "KIND enumerated type name"' line in the TBS.
To translate that computer science into English: Each 'kind tag' sets the rules of what an asset is, and what data types and definitions its asset folder must contain when submitted to a Trainz Content Manager for Committal (now, strangely called Submittal since the TANE Content Manager arrived.) or Validation (Error checking and testing, step preceding Committing (or Submitting) an asset to the Data Base. Also before uploading to the DLS. Each kind is married to a source config.txt file as (usually) one of its very first lines[note 2]. EVERYTHING is part of a pair TAG--DATA. Some are TAG-Container, many are TAG-Value, but all config data is paired. Sub-containers in a container follow the same rule. Even the array data elements--strings, multiple values, multiple possibilities (Category-era & Category-region) are defined in a pair relationship on one line. Containers thus are keyword tags meaning expect an '{' and '}' and process the data between by the rules defined by the tags name.

Understanding the role of KINDs is arguably only slightly less important than comprehending the role of the TrainzBaseSpec and that ubiquitous container of both, the config.txt file. All three are at one time or another, for that case the most important data elements for users to get a handle on for either fixing or creating assets. Fortunately, each type of Trainz asset has a unique KIND, so these can be mastered either at need, or systematically one by one, and similarly understanding each containers can be taken one by one.

In point of fact, all three elements are tightly interlinked as they work together within the asset root folder which must contain the config, which in turn, 'must' contain a kind tag in the TBS and other mandatory TBS supporting definitions such as a kuid and username, and from the KIND defined and selected in the TBS's lines, 'must' therefore contain those definitions required by that kind tag and all supporting definitions... including requisite containers and sub-containers.

To a lesser extent the KIND and category-class tag, work together to tell the Content Manager software what other keywords are necessary, optional, or illegal within the asset's config.txt file, and the latter has the defined purpose of adding that category-class member (the asset being defined) to a mix of various sorting criteria useful to users in the CM's sorting and selections operations.

P train grey.png
Defining an asset in the Trainz Data Model:

Trainz Kinds are upper level containers defining minimal data structures for characterizing a asset type under a single identifying kuid.

Hierarchy and level[edit]

KINDs in the Trainz simulators define the attribute that together with category-class set up required fields of information to make the model of an asset render properly. In a very real sense, the KIND data structure (grouping related data of disparate type relevant to the needs of model rendering and run-time simulation) is a first level container in Trainz (albeit with a special name, "KIND"), and will almost always require other container level data groups accompany it in the ini files. These are enumerated supporting containers and tags which the combination of the enumerated types of the kind tag and category-class use to determine which other data elements must be defined for such an asset, which may be considered a sub-kind, for all like assets require the same data elements be defined as well.

Now all container and container-like structures occupy the config.txt file, but the distinction is simply that 'container defined types' usually have scope (applicability) in several different KIND defined assets and represent a shared attribute (a feature, e.g. bogeys), whereas each KIND is unique to that class of asset. KIND Engines and KIND Traincar both have bogeys (wheels on trucks) so both have a bogeys container in their ini file.

P train grey.png
Defining an asset in the Trainz Data Model-II:

This list below is comprehensive as of page composition, and updated regularly. See Trainz-Wiki KIND TrainzBaseSpec for possible updates. (Many links there below connect to the N3V TrainzOnline Wiki and there is a slight color difference between those and Wikibook sections links. Those that are still redlinks in late August 2014 have not been formally defined in the N3V Wiki, though the class has likely been promulgated in one of the content creator's forums.  


Kinds of KINDs[edit]

All the below Child Classes are considered to have the TrainzBaseSpec as their Parent Class of data.[note 4] Kinds below 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 (the one online is the TC1&2/TC3 version, containing the altered Enginespecs Locomotive kinds from the TRS2004/TRS2006 AND UTC data models.) is highly recommended to any users of the Trainz Download Station or anyone contemplating creating content.

TrainzBaseSpec Child Class KINDs (type asset groups)

 


Important Everyday KINDs[edit]

This section to provide links to a set of examples subpages showing the evolution of a common asset
to kind configurations from v1.3-v1.5, v2.2, v2.5, v2.9, v3.7, v3.9, or to other such versions where the active data model shifted and the differences can be seen using file comparison software.
What is the most important KIND?

The answer is dependent upon what sort of assets and asset sub-types you are dealing with at the moment. Locomotives and boxcars are both Kind "traincars" in the human thought process, but are different KIND declarations in Trainz configs and a Diesel powered locomotive and a Steam Locomotive each need differing data parameters defined to model the asset; this differentiation within configs comes from the definition of the kind and the mandatory category-class tags solely have scope inside CM and surveyor selection and sort filters.

Scenery Kinds[edit]

These are generally simpler so to introduce the use of Kinds,

Track Kinds[edit]

Trackside Kinds[edit]

Locomotive Kinds[edit]

Enginespecs[edit]

kind engine

Notes[edit]

  1. Kinds and many other Trainz data defines, while wide ranging are enumerated data types... meaning they must be <values> from a legal list of allowed words. No Others Need Apply!
  2. The position of all tags and containers inside a config file simply does not matter, save proper nesting of data structures in quotes, brackets and parentheses does
  3. While not formally acknowledged by the N3V programmers (anywhere I've seen), the LOD files[1] such as 'meshname.LM.txt', and filespec.texture.txt files can be thought of as ini file types or include file types, in effect expanding the inline defines located within the config files. (texture.txt files + LM.txt files) Each contains not only path information, but essential how-to-implement data instruction lines, and like config.txt file lines, are required to be in the proper format or an asset will generate a fault.
     • One key difference between the config.txt file and such include files is they do not hold strictly to the Trainz keyword—<value> pair on a line format, but instead often use equalities as part of their syntax.
  4. Note: This list is 'wikified' on the N3V TrainzOnline Wiki, meaning the first letter has been capitalized after the word 'KIND', whereas actual data tag names in config.txt files are all lower case text. That wiki also uses double quotes in quite a few terms, a practice which we'll spare you from experiencing herein.

References[edit]