Open main menu
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
 Mouse use

The Kind tagEdit

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

Kinds are a special Parent data form with slight differences from exactly being classifiable as one of Trainz containers' general data type and each is designated as in-effect by an explicit unique keyword, the Kind tag, denoting 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. 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 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.

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 levelEdit

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 KINDsEdit

All the below Child Classes are considered to have the TrainzBaseSpec as their Parent Class of data.[note 2] 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 KINDsEdit

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 KindsEdit

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

Track KindsEdit

Trackside KindsEdit

Locomotive KindsEdit


kind engine


  1. 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.
  2. 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.