Trainz/containers/extensions container

The Extensions container is a top-level config.txt file entry available to any Asset which derives from  KIND TrainzBaseSpec—in short, all Assets. The purpose of the container is to allow content creator key words which hook together scripted features or inputs so that they can be defined (allocated as variables and initialized for the particular asset instince) without having ContentManager.exe or the DLS uploading software fault and validation testing fail the asset. In short they keep flexible extensibility as part of Trainz, one of it's hallmarks since Trainz (Beta) 0.9 release.

• This container is intended to allow third-party developers to introduce custom Asset-keyed data which may be processed by custom scripts.

←  Prev  KINDs ↑   Containers — Trainz Config Containers ↓  TrainzBaseSpec  Next  →

Trainz Annotated References

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

[e]
KINDs (type asset groups) and containers
KIND Achievement-category  KIND Achievement-group  KIND Activity  KIND Asset-group  KIND Behavior  KIND Bogey  bogeys container  KIND Buildable  class library  KIND Controlset  KIND Consist  KIND Drivercharacter  KIND Drivercommand  KIND Engine [1]  KIND Enginesound  KIND Environment  extensions container, or extensions  KIND Fixedtrack  flowsize container  KIND Gameplaymenu  KIND Groundbrush  KIND Groundtexture  KIND Hornsound  KIND HTML-asset  KIND Industry [2]  KIND Interior  junction-vertices container  KIND Library [3]  kuid-table  KIND Map  KIND Mesh [4]  member-of-groups  mesh-table container  KIND Module  KIND MOCrossing [5]  KIND MOJunction [6]  KIND MOSignal [7]  KIND MOSpeedboard  obsolete-table  privileges  queues container  KIND Pantograph  KIND Product [8]  KIND Product-category [9]  KIND Profile [10]  KIND Region  season-selector container  KIND Scenariobehavior  KIND Scenery[11]  KIND Scenery-Trackside[12]  KIND SceneryWithTrack [13]  script-include-table container (TBS)  KIND Servlet  smoke container  KIND Steam-engine [14]  KIND Texture [15]  KIND Texture-group  thumbnails container, or (TBS)  KIND Track [16]  track-lod-tree container  KIND Tracksound [17]  KIND Traincar [18]  KIND TrainzBaseSpec [19]  KIND Turntable  volume container  KIND Water2

• The extensions container is a list of custom tags or subcontainers with a specific naming convention.

• From the standpoint of the average Trainz Owner, exposure to the need for adding this container will be to acceptably Fixing Assetsupdate and fix up older assets off the DLS with software hooks. One of the key features giving Trainz an advantage over the various competing Train Simulators over the years is it's extendability — the ability of Content Creator to extend and enhance the base programs capabilities by adding software it For example, various Trainz extensibility schemes that offer alternative 'traincar liveries' (paint skins)—one series of these developed by TrainzProRoutes is known as 'Chameleon skins'—or instance auto-numbering system on a specific car type's kuid. Older assets on the DLS may not be reconfigured so throw an easily curable fault .

Supported Tags

The naming of top-level tags within the 'Extensions container' is important. Tag names should be meaningful and must end with a hyphen followed by the User ID Number of the content creator who is introducing the extension.

• This content creator is solely responsible for determining any rules and restrictions which apply to the tag or subcontainer, and should ideally make an effort to provide this information to other creators via this wiki and the TrainzOnline wiki, with links to pages covering such in the Extension Documentation section below.

• While content creators are permitted to make use of each other's extension formats, it is not permissible for a creator to introduce a new extension (or change the meaning of an extension) which exists in a namespace belonging to another content creator.

• Each tag in the extensions container may be either a single value, or a subcontainer grouping a variety of data elements. If a subcontainer is used, the contents of the subcontainer should be specified in the extension documentation. No restrictions are placed by N3V Games on the values within a specific extension.

 

Validation

At the current time, the contents of the Extensions container is not validated. It is expected that future versions of Trainz and the Download Station will perform validation of the extensions container according to the rules described on this page. Furthermore, it is feasible that N3V will formally adopt specific extensions which have entered common use. In this scenario, N3V may choose to introduce asset validation to the extension creator's formal specification or, where such specification is not available, to a formal specification written by N3V derived from the common usage.  

Extension Documentation

If you are a third-party content creator who has created a custom extensions according to these specifications, please document your extension on this wiki and link to your extension page here:

• Add your entry here.

Extensions container Examples

Locomotive with running numbers

The following lines are taken directly from a Trainz 1.3 era locomotive later updated to or beyond V2.9 (TS09).

---

Example from a TBV 1.3 Locomotive upgraded to TBV 2.9. Locomotive configs and many other traincars which share 'traincar parts' will specify such parts (beginning with bogeys) by a kuid reference. 
 • Single key-word—value pairs signify either boolean parameters (only 1 or 0 meaning True or False are allowed) 
 • or an integer count= 'Number of fonts', (in this case-meaning font-sub-meshes (really meaning font locations where named attachment points are defined in the mesh) to permit showing a digit) with suffixed identities. 
 • These tell a script asset how many memory locations to reserve (allocate) for this traincar's scripts. The value pair with suffixed keywords assign values or initialize such values.

---

bogeys
{
...
}
enginespec                              <kuid:-1:42004231>
enginesound                             <kuid:-1:42003000>
engine                                  1
fonts                                   4

Prior TBV level parsing will tolerate the running-numbers container directly in the config.txt file.

extensions
{
   running-numbers
   {
     rn-0                                  "# 2004"
     rn-1                                  "# 2005"
     rn-2                                  "# 2006"
     rn-3                                  "# 2007"
   }
}
The script of such engine assets utilizes the labeled 'key-name — value-pairs' in the extension to assign a range of locomotive numbers. In this case, the prototype railroad had only four locomotives of this type which were assigned the numbers listed. Other arrangements to list a range of numbers are common, especially for dynamically numbered freight cars such as hoppers. boxcars, flatcars, etc. of specific types.

 

Notes, Footnotes & References

Config.txt files are endemic and ever present in Trainz assets, for no asset can be defined without this type of Computer Science container. The keyword-value_of_key pairing must always be kept in mind in editing or creating Trainz content. The TrainzBaseSpec contains values and containers which are most common in asset defining config.txt files.  

 

 

References

• Trainz printed or pdf file Manuals, applicable version - usually in the ..\extras or ..\extras\manuals folder
• TrainzOnline Wiki Config.txt file page and various other pages
• TrainzOnline Wiki: Content Creator's Guide pages (various)
• Various CCG and Auran websites