Download Station Cleanup

From TrainzOnline
(Difference between revisions)
Jump to: navigation, search
(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. Aditionally, Auran 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.
+
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.
  
  
In preparation for TS2009, the Download Station will be fully cleaned. Auran will assume responsibility for repairing all current faulty DLS content such that it passes our internal validation processes (similar to those performed by CMP.) The repair process will involve the following steps:
+
=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.
  
* Faulty content is identified.
+
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.
* Trivial mistakes (eg. obvious typos and missing dependency information) will be silently fixed.
+
* An attempt will be made to contact any content creator who has faulty content on the DLS. They will be given the option to provide a fixed version of the content.
+
* Auran will fix any remaining content where feasible.
+
* Auran will remove from listing any content which cannot be fixed.
+
  
As a result of updated dependency information and faulty content removal, it may occur that various dependencies are missing from the Download Station. This scenario will be treated in a similar fashion to the content being faulty; meaning that Auran or the original content creator will update content such that it does not depend on any missing assets, or that the content will be removed from listing.
+
=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.
  
'''''Discussion Items'''''
+
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]
* It may be best to split the DLS between TS2009 assets and older assets. This split would be transparent to users, and it would allow users of older Trainz versions to continue working completely unaffected by the updates while TS2009 users get the benefits of the new changes. The disadvantage of this approach is that pre-TS2009 users do not get the benefit of a cleaner DLS.
+
* TS2009 will feature improved validity checking. This means that attempts to upload TRS2006 content which has passed TRS2006 validity checking may fail. One possible resolution here is to release a CMP update for TRS2006 users.
+
  
'''''Some Common Errors In config.txt Files'''''
+
 
 +
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.
Personal tools