Trainz/Kinds

↑   Trainz content creation, References — References TOC ↓

Fundamentals for Trainz Trainees Trainz Annotated Reference Pages

TOC | Beginnings | Fun | AM&C | Creation | InBook Refs | ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers

Glossary

HKeys-CM

HKeys-DVR

HKeys-SUR

HKeys-WIN

Mouse use

Notations

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

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

Defining an asset in the Trainz Data Model: config.txt files = (declarations) TrainzBaseSpec + category-class tags + KINDs + supporting containers + texture and mesh processing include files

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

Defining an asset in the Trainz Data Model-II: TrainzBaseSpec + category-class tag + kind "engine" determine a set of required supporting containers while category-class + kind "trancar" determine a different set of supporting containers. TrainzBaseSpec + category-class tag + kind "scenery" determine a set of required supporting containers while category-class + kind "industry" determine a different set of supporting containers.

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

All Trainz defined data (content) has three required elements: A config.txt file to organize the data, an identity meaning a kuid (username alone will do you no good, a legal asset however can be created without a name!) and last, a legally defined kind tag. The kind is in charge, the conductor of the orchestra, the Platoon Sargeant or CEO giving directions — setting up the requirements for everything that gets processed after. In short, the kinds' value, a small select tightly defined members-only group — tells Trainz software what is to be rendered and displayed in the virtual worlds we create, and how (or where) to find the other parts needed to make those parts of the asset linked together in that config.txt file.
  Each of the below Child Classes are considered to have the TrainzBaseSpec as their 'Parent Class' of data. A few kinds listed below, those 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 is highly recommended to any users of the Trainz Download Station or anyone contemplating creating content. The insights gained from understanding of the background history of how older content was defined can then be contrasted with the current TrainzOnline coverage of the same data type and compared, for often this kind of then-vs.-now provides valuable insights to fixing, altering and customizing assets. More to the point, the writing in the CCG was professionally produced and is far more tautological—it will often give you insights as to extended effects if this or that is altered, which the Trainz Wiki just doesn't provide. The CCG put up on TrainzOnline is the TC1&2/TC3 version — the last published of several booklets printed dating back to Trainz in 1999; the TC3 CCG contains the altered Enginespecs Locomotive assets from the TRS2004/TRS2006 AND UTC data models need to be properly updated.

TrainzBaseSpec Child Class KINDs (type asset groups)
kind achievement-category  kind achievement-group  kind activity - scenarios kind  kind asset-group  kind behavior  kind bogey []  kind buildable  kind controlset  kind consist  kind drivercharacter  kind drivercommand  kind engine [2]  kind enginesound []  kind environment  kind fixedtrack []  kind gameplaymenu  kind groundbrush - undef'd  kind groundtexture []	kind hornsound []  kind html-asset []  kind industry [3]  kind interior  kind library [4]  class library  kind map - Route kind  kind mesh [5]  kind module - undef'd  kind mocrossing [6]  kind mojunction [7]  kind mosignal [8]  kind mospeedboard  kind pantograph  kind product [9]  kind product-category [10]  kind profile [11] - session kind  kind region	kind scenariobehavior - undef'd  kind scenery[12]  kind scenery-trackside[13]  kind scenerywithtrack [14]  kind servlet  kind steam-engine [15]  kind texture [16]  kind texture-group  kind track [17]  kind trainzbasespec [18]  kind tracksound [19]  kind traincar [20]  kind turntable  kind water2

 

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

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

Locomotive Kinds

Enginespecs

kind engine