Trainz/Kinds

The Kind tag

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

All the elements which define an Trainz Asset outside of the Data Base are contained in a single folder&mdash;the  or &mdash;either of which is accessible when the asset is opened for editing or built respectively&mdash;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. The Kind tag legal values are strictly constrained. 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 s' general data type and each is designated-by-type as controlled by their explicit unique keyword, the Kind tag value.

Each Kind thus denotes one of the fundamental sets of 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 &mdash;in effect and in fact, the configs have the job of defining the, of merging those things needed by the other 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 must contain when submitted to a Trainz Content Manager for  (now, strangely called  since the TANE Content Manager arrived.) or  (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. 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 and that ubiquitous container of both, the  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 can be taken one by one.

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

To a lesser extent the KIND and, 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.

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

Hierarchy and level
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 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.

This list below is comprehensive as of page composition, and updated regularly. See 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.

Important Everyday KINDs

 * 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 shifted and the differences can be seen using.

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 and the mandatory  solely have scope inside CM and surveyor selection and sort filters.
 * What is the most important KIND?

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