Trainz/tags/trainz-build tags

[[file:CM will input Versions too advanced-TS10-SP2 shown.JPG|thumb|400px|TS10 SP2's Content Manager (TBV-3.2) happily imported TS12 version (TBV-3.4) texture cdp's for TransDEM.exe in November 2013. Other legacy versions of Trainz will also willingly import 'Version unidentified' Trainz content. Supposedly this will no longer happen after an new DLS protocol is in place after mid-August 2015.
 * Trainz software suites will not attempt to download and incorporate an asset into its local which has a  tag that is newer than its own version number, but ...
 * Unfortunately 's will continue to report there are updates, even when they are entirely inappropriate.
 * One can also import inappropriate assets from other versions of Trainz or a library collection (say of fixed assets saved before committing after Faults cleanup&mdash;a 'handy habit' for those of us running more than one Trainz ), so one need be aware of that.

The is also an indication of the age of the asset, and the general technical configuration and standards to which it is built. The values will range up from the oldest ('none listed in the asset' so Trainz 1.0-1.3) with a default reporting value as if Trainz 1.3 (TBV v1.3){{efn|Trainz 1.0 was released (2001) with three {{wp|service pack|Service Packs}} by June 2002, making the version commonly referred to as {{TL|Trainz 1.3|Trainz 1.3}}. For the new Trainz users:' the moral of this story is to examine trainz-build tags (versions) ASAP after importing new content into CM and provide human intelligence as to whether to delete, keep the asset, or set it aside{{efn|For the new Trainz users:' trying to use an asset with faults {{BL|does not}} actually risk breaking Trainz for while, and most versions won't let you place faulty content until CM is happy with the asset. So experiment away. That's how many a good asset got created in the first place!
 * Assets with older Trainz-build numbers are not built to take advantage of new Trainz features that did not exist in their original version of Trainz (that the asset was built in and for), and the oldest such used design approaches which in some cases, have been entirely abandoned.{{efn|1=
 * The trainz-build tag itself was totally unknown until {{TL|Trainz UTC}} (v1.5) and many CC's of that era and for a few years into even the TRS2004 era never assigned a TB code in the config.txt files. {{TL|TRS2006}}'s through {{TL|TC3}} 'new fancy-schmancy {{TL|CMP}}s' advances, didn't even list TBVs as one of it's data columns!
 * Newer Trainz releases do their best to translate these older technologies into the newer releases standards (data organization and graphical tech) but some significant percentage of older assets cannot be auto-converted; not because it's not possible, but because N3V's programmers decided to retroactively impose new more stringent data model fault testing; whereas the TRS2006 era's (and spin-offs) handled such conversions readily. Most of these can be fixed easily by adding a {{TBS|mesh-table}}, {{TBS|thumbnails container}} and/or {{TR|C|bogeys}} to the config.}}
 * Most newer content can be retrograded to work in earlier Trainz releases, at least as scenery items since those with newer script files may use features not present in older Trainz releases. {{BL|More recently published Routes and Sessions cannot.}} The programmer's changed the formatting of the session and {{TR|K|map}} files, to support more flexible sessions and layers in TS2010 and up.}}
 * As a general rule, before fixing a fault, use the Versions tool to get the most recent version on the DLS, and if it's legal for your install, download that instead. Deleting the old faulty one then will satisfy your dependent assets on your system, and a 'subsequent download and then delete the obsolete asset' process costs little in time and avoids much frustrations. Conversely, if you desire to create assets, fixing assets manually is a great way to learn how they are made. In this case, fixing an obsolete faulty asset has value too.]]

Trainz-build tag number(s)
The trainz-build tag (TBV or TB) is an very important single decimal digit floating point number that is applied to any new asset created under the particular technology level. When you create a cloned session or route, the version number of your install will assign the matching TBV to any new assets Surveyor or CM creates for you. (But NOT it's code build or build number, which is different).
 * This quantity is often also referred to as the Trainz Version, naturally, as various benchmark TBV's start or end a named retail release version, which names are common to all it's service packs&mdash;which normally increment the base TBV value assigned the version before the Service Pack(s)


 * The Trainz Retail Version is a text string for a product release in "marketing speak", such as Trainz Simulator 2009: World Builder Edition, or "Ultimate Trainz Collection" (which was way premature!). These are quickly abbreviated to use names everyone understands like TS2009, TS10, TC3, or UTC.
 * The Trainz version (TB or TBV) is a decimal numeric code, a value, (e.g. 2.4 or 3.6) which is 'most always' incremented for each major software upgrade release, formally defined by Trainz software for any new asset. This code is updated whenever a significant change to the Trainz data model processing is made by a code build release. Sometimes this, in fact, reflects changes to the data model such as a new mandatory requirement above TBV x.y that such and such an must henceforth define a specific tag value or container parameter value, and ...
 * Furthermore: Most service packs (which introduce significant functionality changes) will have a new  assigned, but lesser software upgrades, the (which do not introduce significant functionality changes) do not generate a Trainz version number change. BOTH upgrade types generate new code build values (changes)&mdash; sometimes several times over, as a series of such upgrade code builds, for example, such an upgrade that affects each 'internationalization' editions; non-English language code builds released early in a retail products . Different language versions of the same product will however generally share the same 'asset-oriented' Trainz Version/trainz-build code, so the TBV is for asset compatibility, and the code build is for functional compatibility, and software troubleshooting needs.


 * The Trainz Code Build Number is a unique number (e.g. 44653 or 58414) that identifies an individual Trainz release. All releases (including minor changes and language translations) have a different Code Build Number. The lowest known in 'the editor's collection' is a code build of '10' in the Trainz 1.1 CDROM release.


 * The  tag value uses the Trainz Version numeric code, and after TS2009-SP3, the content manager Windows title bar repeats this value for ease of reference. Assets each report a value reflecting the technology (coding of the data model version) they were meant to comply with.


 * Note that several (or many) code build releases (each having a unique code build number identifying it's exact mix of component software) will share and have the same trainz-build value (TBV)) or 'version number'. The 'build' or 'build codes' or 'code build numbers' are sometimes also spoke of as versions or 'code versions, and many of those increment based on the readiness and availability of internationalization releases–versions customized a bit with translations in built-in content for readers of non-English languages. Code versions, trainz-build versions, retail versions... Context counts!
 * Theoretically, from a newly created asset's point of view, the content manager assigned trainz-build tag number also indicates the minimum  required to use the asset.

When assigned, a trainz-build tag number supposedly indicates the minimum technology level (code version) needed... which in pratcie in gross terms will be the first TBV of the first retail released version in the group's development cycle. This is because data model changes to types and operations are defined in advance of any coding needed to implement the feature. The feature itself may not appear until several Service Packs progress the technology changes to the whole suite. In the early days of a release, such planned advancements take a back seat to priority troubleshooting and bug fix repair edits. Once the version is stable, development resumes for the targeted features. Hence a great majority of assets aimed to vett successfully at TBV 3.2 will work fine at V2.9 or V3.0 if the TBV value is appropriately reduced. However, if the newer TBV release(s) contains software dependent 'new features' those will not work in the earlier tech level install(s). Hence Speed Trees will not work in TS10 TBVs 2.9-3.0 but do in V3.2-3.3, both later Service Pack updates. Lack of processing software mirrors also a release's 'designed intentions' in comparable versions&mdash;while TS09 will not generate errors for speedtree assets, neither will it display them; even in the final software release V3.3, identical with TS10's last TBV level. They are effective as an obsolete asset--never seen, never used, taking up disk space. The feature was never supposed to be part of TS09 so it is not enabled or perhaps not included in the software at all. Many assets readily can be converted to lower TBV values with such a simple one decimal digit edit. . Conversely, assets with a lower Trainz-build version should be compatible with the later more modern install, albeit with an occasional need to tweak and update the data model of the asset.

Asset compatibility
It is important for an asset to list the correct Trainz-build in the. It specifies the version of Trainz the asset was intended to be used with. An earlier version of Trainz will refuse to load the asset. A later version of Trainz will enable appropriate backwards compatibility workarounds (e.g. using different validation requirements) as required.

A correctly-constructed asset built for an older version will usually function in a newer version of Trainz. However, while Trainz content validation has improved over time, and newer versions of Trainz detect errors that older versions did not pick up on, many errors are useless make work caused by callous and rapacious programmer and management practices. Often, content may be detected as 'faulty' in a current Trainz version that was missed in the version it was originally created for, but the most frequent issues are missing thumbnail images which have nothing to do with the functionality of the asset, or obsoleted tag names.

Or that is the official party line per N3V, which ignores the fact there are errors they could just fix in parsing, such as ignoring legacy tag names like, , , or , etc. and similarly could convert in situ older forms to newer container forms of data, then test for faults. They do neither putting the time cost of their unprofessionalism onto the customers who must one by one correct errors their software should be handling.

It should be noted that content that is uploaded to the Download Station is validated for faults by the most recent version of Trainz&mdash;and may be rejected if an more stringent newer fault or error test has been put in place. This depends on the version of Trainz that you are running, and if we've updated the DLS error checking. I can make content that shows no errors in TS2009, but will be rejected from the DLS under the current error checking due to issues that TS2009 could not detect. This is essentially the same here. The DLS error checking is updated regularly, and may be more strict than the error checking in TS12 SP1. OTOH, TS:Mac2 is a newer release and will have most of the updates to the error checking.

We have stated many, many, many, many, many, times over the last 12 months that the error checking on the DLS is generally ahead of that in Trainz. Hence, if you are given a rejection notice with actual errors in it, you'll need to correct these. &mdash;N3V spokesman ZecMurphy at forums.auran.com/trainz# post1289419, May 11th, 2014. Assets generated under a perfectly valid currently supported version of Trains, using the validation compatibility for the trainz-build specified by the asset, may still be rejected by the Download Station Software.

If Content Creator Plus CCP is used to modify an asset, it will automatically update the trainz-build version in the config.txt file to the current Trainz version it came with. ''This is problematic and contrary to the greatest interests of the most members in the Trainz community, as the lowest trainz-build code is desired from the standpoint of giving the asset the most Trainz users access to the new product (asset). Prior to V3.2, such codes could then be manually back-dated to a lower trainz-build, but the error checking in versions since requires exporting the asset-open-for-edit by copying the folder, reverting it, deleting it, editing the trainz-build code change in the copy, then re-importing it&mdash;a discourteous number of extra steps-in-the-dance for content creators, and yet another friction point with Trainz programmers. If Using CCP to fault fix and update, often this version with the invincibility of naive programmers forcing others to toe their line and if the asset specs have changed significantly, many other changes to the config.txt file will probably be required, as CCP wants to promote the asset to the current Trainz-build version.''

Assets which are manually edited will need the appropriate version entered. If the line is omitted entirely, the lowest possible version is assumed. This is currently Trainz-build 1.3.

Obsolete Versions
Trainz-build numbers up to and including 2.8 are considered obsolete as of September 2012 and can no longer be uploaded to the Download Station. See the Trainz Life-Cycle Policy for additional details.