Trainz/Kinds

From Wikibooks, open books for an open world
Jump to: navigation, search
logo
Fundamentals for Trainz Trainees

Trainz Annotated Reference Pages
Trainz | Introductory Trainz  | Trainz AM&C | Creation  | Appendixes  |  References  • Containers • Kinds • Tags • Index
 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

Kinds are a special form of the Trainz containers data type and each is defined by an explicit unique keyword denoting one of a fundamental set of enumerated basic data classes in the self-defining self-contained Trainz Asset definitions hierarchy. All the elements which define an asset are contained in a single folder accessible when the asset is built or opened for editing. The config.txt file within has the job of defining the KIND data elements and aggregating those and other mandatory and optional data definitions.

KINDs are arguably only slightly less important than the TrainzBaseSpec and config.txt files as 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.

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 and supporting definitions.

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 the 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.


TrainzBaseSpec Child Class KINDs (type asset groups)

 


Important Everyday KINDs[edit]

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]

KIND Engine

Notes[edit]

References[edit]