Download Station Cleanup
(Added a list of common config.txt file errors, hope that's ok) |
(→Content Validation) |
||
| (10 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | The Download Station has historically been rather lax about checking the validity of uploaded content, relying on the individual content creators to ensure that various data fields (including dependencies) were specified correctly. | + | The [[Download Station]] (also referred to as DLS) has historically been rather lax about checking the validity of uploaded content, relying on the individual content creators to ensure that various data fields (including dependencies) were specified correctly. Additionally, [[N3V]] has been slow in providing up-to-date content examples, documentation, and validation tools. As a result, due to misunderstandings and human error, quite a lot of the current DLS content has configuration errors or missing dependencies. |
There are two steps that need to be taken to resolve this situation: | There are two steps that need to be taken to resolve this situation: | ||
| Line 6: | Line 6: | ||
* Mechanisms are put in place to ensure the quality (from a configuration perspective) of future uploads. | * Mechanisms are put in place to ensure the quality (from a configuration perspective) of future uploads. | ||
| − | Neither step is as easy as it first seems, since complete validation of an asset is not reasonably possible. Validation is a moving target, and with each improvement to the validation toolset, it is expected that some number of "good" assets will become flagged as "faulty". In practice, this means that the first step must be repeated with each update to the validation toolset. | + | Neither step is as easy as it first seems, since complete validation of an asset is not reasonably possible. Validation is a moving target, and with each improvement to the validation toolset, it is expected that some number of previously "good" assets will become flagged as "faulty". In practice, this means that the first step must be repeated with each update to the validation toolset. |
| − | + | =Content Validation= | |
| + | The DLS upload mechanism performs validation on all incoming assets, using the same underlying process as [[Content Manager]]. For technical reasons, certain tests are not possible to perform on our server hardware, meaning that some specific errors are not detected by this process. If an incoming asset is flagged as faulty, the validation log is emailed to the content creator who is attempting the upload. | ||
| − | + | The validation process is updated on a regular basis to maintain parity with the current Trainz release. This means that once an asset passes validation on the DLS, it should show as error-free on the current version of Trainz. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | =Cleanup Process= | |
| + | It is N3V's intention that the Download Station is fully cleaned. This is a long process, and while we are actively progressing towards this goal, it should be made clear that we do not have a specific completion date in mind. The repair process will involve the following steps: | ||
| + | * Faulty DLS content is identified by our asset validation tools. | ||
| + | * An attempt will be made to contact any content creator who has faulty content on the DLS. The content creator will be given the option to provide a fixed version of the content within 8 weeks. | ||
| + | * Where we cannot make contact with the content creator or where the content creator chooses not to participate in the repair process, we will flag the asset as needing independent review and repair. | ||
| + | * A list of content available for review will be published. | ||
| + | * A mechanism will be provided for any content creator to supply a repaired version of content on the review list. | ||
| + | * Content which remains on the review list for an extended period may be removed from the DLS listing. | ||
| − | + | Further information about this process, including the public repair list, is available from the Download Station Cleanup [https://www.auran.com/planetauran/com_dls_cleanup.php Index Page] | |
| − | + | ||
| − | + | ||
| − | + | ||
| + | N3V will also seek to reduce the occurrence of missing dependencies in DLS content. It is expected that we will begin to tighten the upload criteria in this regard. We have not fully evaluated our options here - we do not wish to negatively impact the payware marketplace, for example - but it is clear that we are unhappy with the current situation. | ||
| + | |||
| + | =Some Common Errors In config.txt Files= | ||
| + | ''Please note that the following information has been provided by third parties.'' | ||
=> means "should be changed to". | => means "should be changed to". | ||
Latest revision as of 14:38, 9 February 2014
The Download Station (also referred to as DLS) has historically been rather lax about checking the validity of uploaded content, relying on the individual content creators to ensure that various data fields (including dependencies) were specified correctly. Additionally, N3V has been slow in providing up-to-date content examples, documentation, and validation tools. As a result, due to misunderstandings and human error, quite a lot of the current DLS content has configuration errors or missing dependencies.
There are two steps that need to be taken to resolve this situation:
- The current DLS content is repaired;
- Mechanisms are put in place to ensure the quality (from a configuration perspective) of future uploads.
Neither step is as easy as it first seems, since complete validation of an asset is not reasonably possible. Validation is a moving target, and with each improvement to the validation toolset, it is expected that some number of previously "good" assets will become flagged as "faulty". In practice, this means that the first step must be repeated with each update to the validation toolset.
[edit] Content Validation
The DLS upload mechanism performs validation on all incoming assets, using the same underlying process as Content Manager. For technical reasons, certain tests are not possible to perform on our server hardware, meaning that some specific errors are not detected by this process. If an incoming asset is flagged as faulty, the validation log is emailed to the content creator who is attempting the upload.
The validation process is updated on a regular basis to maintain parity with the current Trainz release. This means that once an asset passes validation on the DLS, it should show as error-free on the current version of Trainz.
[edit] Cleanup Process
It is N3V's intention that the Download Station is fully cleaned. This is a long process, and while we are actively progressing towards this goal, it should be made clear that we do not have a specific completion date in mind. The repair process will involve the following steps:
- Faulty DLS content is identified by our asset validation tools.
- An attempt will be made to contact any content creator who has faulty content on the DLS. The content creator will be given the option to provide a fixed version of the content within 8 weeks.
- Where we cannot make contact with the content creator or where the content creator chooses not to participate in the repair process, we will flag the asset as needing independent review and repair.
- A list of content available for review will be published.
- A mechanism will be provided for any content creator to supply a repaired version of content on the review list.
- Content which remains on the review list for an extended period may be removed from the DLS listing.
Further information about this process, including the public repair list, is available from the Download Station Cleanup Index Page
N3V will also seek to reduce the occurrence of missing dependencies in DLS content. It is expected that we will begin to tighten the upload criteria in this regard. We have not fully evaluated our options here - we do not wish to negatively impact the payware marketplace, for example - but it is clear that we are unhappy with the current situation.
[edit] Some Common Errors In config.txt Files
Please note that the following information has been provided by third parties.
=> means "should be changed to". All typo corrections only apply when used as keywords. Do not change when in a filespec unless that is changed too.
- KUID folders within KUID folders (in TRS2004 terms).
- Mismatches between KUID folder names and KUID tags in config.txt files (in TRS2004 terms).
- kind "behaviour" => kind "behavior"
- colour => color
- discription => description
- independent => independant
- kuid { => kuid-table {
- kuid{ => kuid-table {
- kuid table => kuid-table
- kuidtable => kuid-table
- obsolete { => obsolete-table {
- obsolete{ => obsolete-table {
- obsolete table => obsolete-table
- obsoletetable => obsolete-table
- table{ => table {
- any character other than a space or a tab, immediately followed by an open curly bracket => insert the space
- any character other than a space or a tab, immediately followed by an open angle bracket and kuid => insert the space - but not in HTML where this is valid
- "utc" => 1.5 (in a trainz-build tag)
- Two forward slashes, when intended to be a comment. Probably delete the whole line.
- organization => organisation (not sure if this one is critical)
- Open-double-quote and close-double-quotes used inside normal double-quotes in name tag parameters, often rendered as accented characters and the Euro currency symbol, and cause the asset to be sorted out of natural alphabetical order. They can be deleted.
