Asset Validation
Tonyhilliam (Talk | contribs) (→Common Misunderstandings) |
|||
Line 11: | Line 11: | ||
2. That warnings must be fixed. Warnings are generated when the game believes that there may be reason for the content creator to review their asset. It is purely a courtesy to highlight cases which are known to be frequently problematic. This does not necessarily mean that the content is faulty, or that anything needs to be changed. Modifying your own created content to resolve warnings is encouraged, but not mandatory. Modifying content created by others to resolve warnings is strongly discouraged as it is likely to introduce compatibility issues for no benefit. | 2. That warnings must be fixed. Warnings are generated when the game believes that there may be reason for the content creator to review their asset. It is purely a courtesy to highlight cases which are known to be frequently problematic. This does not necessarily mean that the content is faulty, or that anything needs to be changed. Modifying your own created content to resolve warnings is encouraged, but not mandatory. Modifying content created by others to resolve warnings is strongly discouraged as it is likely to introduce compatibility issues for no benefit. | ||
+ | |||
+ | :: Note that it is also a myth that "today's warning is tomorrow's error". In some cases we warn people about errors prior to making the changes mandatory in future versions, but this is a guide not a rule. | ||
== Recent Validation Changes == | == Recent Validation Changes == |
Revision as of 17:03, 28 April 2015
All Trainz assets must be correctly formed in order to work properly across a wide range of software and hardware configurations. To aid in this process, Trainz includes asset validation functionality which checks each item of content for a range of known flaws. This validation process is performed both on your local Trainz installation, and also as part of the Download Station Upload Process. Assets which fail validation cannot be used in-game.
This page documents recent changes to the asset validation process. It is not intended as a complete list of possible failure cases, nor does it seek to provide information on how to fix each error condition. If a fault is discovered in your own content, you should review the relevant Content Configuration documents to understand the rules and restrictions which are relevant to the asset in question.
Common Misunderstandings
There are two common misunderstandings that our users often have regarding asset validation:
1. That built-in content is exempt from validation, and may be faulty. This is incorrect; all built-in content is validated at the N3V Games offices using the same tools as are available to end users. We do not perform validation of built-in content on end-user machines because (1) it is slow, and (2) the content cannot be modified and was known to be good at the time it was made built-in.
- It is important, however, to note that built-in content does not contain source textures. This means that a user who attempts to clone or edit built-in content will be faced with a faulty result unless they provide their own source textures. This does not indicate that the built-in content was faulty, but rather that the user's manipulations have left the game with a faulty copy of the asset.
2. That warnings must be fixed. Warnings are generated when the game believes that there may be reason for the content creator to review their asset. It is purely a courtesy to highlight cases which are known to be frequently problematic. This does not necessarily mean that the content is faulty, or that anything needs to be changed. Modifying your own created content to resolve warnings is encouraged, but not mandatory. Modifying content created by others to resolve warnings is strongly discouraged as it is likely to introduce compatibility issues for no benefit.
- Note that it is also a myth that "today's warning is tomorrow's error". In some cases we warn people about errors prior to making the changes mandatory in future versions, but this is a guide not a rule.
Recent Validation Changes
The following changes are reasonably new additions that many users may not yet have experience with. They are included here to highlight the requirements and to advise users that they are legitimate problems.
- All non-v6 SpeedTrees will be considered faulty by TANE. The older v5 trees built in to previous Trainz editions are no longer supported, and have been replaced with v6 equivalents.
- Meshes with LODs that don't reduce poly counts by at least 20% are considered faulty. The purpose of Mesh LOD is to substantially reduce polygon detail in order to benefit performance. If you are not correctly reducing polygon detail, then the use of LOD can actually worsen performance.
- Image files which are referenced from both the config.txt file and also a texture.txt file are considered faulty. Typically, the config.txt file should reference the texture.txt file (either directly as a ".texture" resource, or via a ".im" file.) In some cases (eg. for thumbnails) it is more common to reference an image file directly rather than as a texture. It is an error, however, to use both styles of reference on a single image file.
- Files with overly long path names are considered faulty. This helps preserve content compatibility with some platforms where the overall path name length is limited.
- Validation of preview meshes for the old obsolete track types has been introduced. This ensures that tracks which will fail to load into the Surveyor asset picker 3D view will be considered faulty.
- Scenery with attached track is now validated for duplicated tracks. It is not possible for multiple splines to share the same pair of attachment points. This has never worked and can cause problems if attempted; it is now detected and flagged as an error.
- The 'mandatory' keyword has been added to Trainz script. This specifies that inherited() must be called in overriding functions. (This keyword has been added to several built-in scripts.) Assets which attempt to override these functions and forget to call inherited() cause problems, and this is now detected by validation.
- KUID fields are now sanity-checked to ensure that they are correctly formed. This is required to ensure that they show up in dependency checks, etc.
- When referencing a mesh from a mesh library asset, both the latest version and the specified version are now checked for the presence of the mesh.
Recent Additions
The following changes are recent additions to the config format.
- Control of PhysX collision data generation in the "mesh-table" container.
- Spline collision support.
- "enable-pfx-collisions" for scenery objects.
- TBD: Procedural Track assets.
- TBD: TANE water configuration options.