CCG/Common Containers

Latest revision as of 10:42, 6 June 2011

[edit] Common Containers

The following containers are present in all kinds.

[edit] kuid Table

A list of KUIDs required for this asset to function correctly.

A kuid-table must be included where the config.txt references additional KUIDs, such as a bogey, or a pantograph. The Download Station performs a search, and those found are added to the download pack.

[edit] obsolete Table

The obsolete-table describes the assets revision history.

This container was used extensively for pre-TRS2004 assets as each version required a unique Content ID. In order to simplify this process the KUID2 format was introduced, which now supersedes the obsolete-table method. TC and the Download Station automatically detect and use the most recent version of an asset whether it be through the KUID2 system or through the obsolete-table.

The obsolete-table container has been included to maintain backwards compatibility with older assets and it is recommended that the KUID2 system be used instead.

[edit] privileges

As of TRS2006, limited content protection applied, but only to built-in (JArchived) assets. The following tags were used:

The permit tags grant or deny the user specific access rights. By default, all permissions are granted on an asset. Setting one of these tags to false (0) removed the permission. Built in assets may deny you some options.

permit-commit - Allows the end-user to commit changes to this asset.

permit-edit - Allows the end-user to open this asset for editing.

permit-listing - Allows the end-user to view this object in the surveyor pickers (if it is of an appropriate kind). It does not affect the visibility of the asset within the CMP asset list.

[edit] string table cn, cz, de, es, fr, it, nl, pl, ru

Every asset can have a string table. A string table is a list of text strings that are defined in the string-table section of the asset's config.txt line as follows:

On their own, these string tables are not used. The string tables become useful for scripting, and are referenced in the script.

To compliment the English String Table, a variety of additional String Tables allow for equivalent strings to be supported across other languages.

[edit] thumbnails

Any asset may specify a thumbnail or preview image. The exact usage of this image may vary depending on the asset kind and the build of Trainz, but the following usages are historically common:

32x32 - standard icon representation for display in lists.

128x64 - `kind traincar' list icon in Surveyor.

512x512 - `kind traincar' preview image in Surveyor.

240x180 - Download Station thumbnail image - mandatory.

Note: The Art files directory in previous versions of Trainz may now be replaced by the Thumbnails container.

To allow for the generic specification of thumbnail images, the following format is adopted for TC onwards.

Any number of thumbnail entries may be present, however it is recommended that no more than 3 images are used. The specified width and height must match the actual width and height of the image file in pixels.

Supported image formats include:

· 32-bit uncompressed targa (.tga) - this supports an alpha channel

· 24-bit windows bitmap (.bmp)

· Jpeg (.jpg)

When displaying an image, the closest-sized image required by the function (in terms of pixel dimensions) will generally be used in Trainz.

[edit] Extensions

Third parties may sometimes wish to include additional config.txt tags in an asset's config.txt file for the purposes of providing asset-keyed date to custom scripts.

It is important that the following mechanism is used to prevent potential conflict with future Auran tags or other content creators.

All third-party tags must be embedded under an extensions container which is placed at the top level in the config.txt file. Tags within the extensions container should have a meaningful name and should end with a hyphen and the UserID of the content creator who is responsible for the extension. The responsible content creator should determine any rules and restrictions which apply to his or her tag and should make an effort to provide this information to other creators (outside the scope of the asset itself).

While creators are permitted to make use of each other's extensions, it is not permissible to create a new extension (or change the meaning of an extension) in the namespace belonging to another creator.

Each tag in the extensions container may be either a single value, or a subcontainer. If a subcontainer is used, the contents of the subcontainer should be specified in the extension's documentation.

No restrictions are placed by Auran on the values within a specific extension, beyond the normal config.txt file format guidelines.

Common Containers and Tags

Common Tags

[edit] Return to CCG Index

Content Creator's Guide