Content Validation: Warnings are not Errors

[TrainzDev]

There has been a lot of discussion in the Trainz community about the various warnings that Content Manager will log as part of the Content Validation process. Some members of the community appear to be under the impression that Warnings are to be treated as Errors – and need to be solved. This is not the case.

Content Manager will generate warnings for a piece of content if it has detected an indication that there is a better way to achieve the desired result from a piece of content. Remember that warnings are not errors, and they do not have to be solved.

If you are using content that is already released, then you should completely ignore all warnings. They are not a serious enough problem to stop a piece of content working in-game, and attempting to solve them can often cause bigger problems.

If you are updating an old asset and intend to release it on the DLS, you will need to address a couple of specific warnings. Whether you address the rest is up to you. Weigh up how difficult it is to fix them (properly, not just hide the message), versus the potential gain from doing so.

If you are making a new asset, you should really address the issues that CM brings up as warnings; but even then, note that it is not strictly necessary to do so.

A few specific warnings have been discussed at length in the community recently:

Warning: This asset uses an obsolete trainz-build number. Trainz-build numbers below 2.9 are no longer supported.

This is just telling you the asset is built to old standards.

If the asset works fine in game, is already on the Download Station, has no errors listed, but has this (and maybe other) warnings, then the asset is fine. Please ignore the warning report, and move on to something else.

This warning only matters if you intend to upload the asset to the DLS. The DLS won't accept asset uploads using versions below a certain level, currently 2.9. Be aware that updating an older asset to a build number above 2.9 can require significant changes to the structure of the asset, so this is not something to do lightly.

In particular, a spline asset will require large changes to the mesh source. This may include dividing or combining spline components into different meshes, changing the way the parts are laid out in the mesh files, and the creation of LOD levels. Given the amount of work involved, it may actually make more sense to build new art and make a new asset to replace the old asset, rather than merely updating the old asset.

Warning: The texture 'black.tga' is a uniform color.

If you have a texture that generates the 'uniform color' warning, it is telling you that you are using the wrong material type, as you have a texture in use that you aren't using to any advantage and don't actually need.

If this is your asset you are creating, then check the list of material types on the TrainzDev Wiki, and either pick a more appropriate type, or make better use of the one you are using.

It is entirely reasonable to use an *.m.notex material type for things that don't benefit from a non-uniform texture, e.g. shadow volumes, collision meshes, and so on.

Do note that introducing a single slightly different shade pixel to "trick" the warning into going away isn't actually solving the problem. You still have an inefficient asset that is using more textures than it needs. All you've succeeded in doing is hiding the message telling you of this problem.

 

[shaneturner12]

Hi James - a note regarding that uniform colour issue. I am aware that sometimes it has to be fixed if it's a large texture thanks to the fact it does become an error. In addition to this, a rethink is needed on that uniform colour warning as alphablanks have to be a uniform colour in order to work correctly.

Also, WindWalkr has stated elsewhere that warnings are likely to become errors in later versions - the progressive mesh warning is one of these as it becomes an error at trainz-build 2.9.

Shane

 

[TrainzDev]

A note regarding that uniform colour issue. I am aware that sometimes it has to be fixed if it's a large texture thanks to the fact it does become an error.

If an asset has a large texture that is a uniform colour, the author has definitely done something wrong. If you are repairing the content, the simplest fix in that case would be to resize it though

In addition to this, a rethink is needed on that uniform colour warning as alphablanks have to be a uniform colour in order to work correctly.

I disagree. Warnings are not errors. You can use the content without changing it. This warning is really only relevant for the original author, to assist them to make a better asset when they release a new version.

If a texture is being provided but not being used (which is what this warning is about), then there is a performance problem here. I stand by my advice above -- check the material list, and see if there is an appropriate one that does not require the alphachannel you aren't using, or make better use of the material, by providing real, useful data in this channel.

Other things which will help here:

• Combining multiple textures into one texturemap. Rather than having a wall texture, a roof texture, a floor texture, a door texture, a window texture and so on; make a proper texturemap for your asset and texture it properly. This will mean there are far fewer textures, and they are far less likely to be uniform colour.
• If you are in the habit of providing alphachannels in separate files (e.g. a 24 bit BMP file and an 8 bit BMP file both referenced from the same texture.txt file), then please convert those to a 32 bit RGBA uncompressed TGA file. There are free tools to do this if your existing image editor can't do it.

Also, WindWalkr has stated elsewhere that warnings are likely to become errors in later versions - the progressive mesh warning is one of these as it becomes an error at trainz-build 2.9.

Only when the content version changes. Which generally only happens when the content is updated. You should not be changing the content version number routinely - only do so if you have to as part of another change, e.g. you were making a new version of the asset anyway.

 

[shaneturner12]

There is an exception there in the form of the DLS Cleanup process - especially as the version has to be 2.9 or higher to be accepted by the Download Station.

I know that warnings are not errors, but that's not to say that a patch wouldn't cause them to become errors in the future (like the uniform colours, which I know a lot of content creators are not happy about).

Take it from me - warnings seem to cause as much havoc as errors do, especially for new users. Bear in mind that assets installed from third-party sites are the worst for this due to the fact they become locally modified on import (but that's a different issue).

Shane

 

[TrainzDev]

There is an exception there in the form of the DLS Cleanup process - especially as the version has to be 2.9 or higher to be accepted by the Download Station.

Correct. I mentioned this in my post. I also said that successfully changing this number is likely to be the biggest part of doing an asset repair, which is true.

I know that warnings are not errors, but that's not to say that a patch wouldn't cause them to become errors in the future

The only way a warning gets upgraded to an error is if the content version number is upgraded. Some reports are errors for new content, but warnings for old content -- but the version this happens at isn't changed over a patch.

We generally do add new errors in each patch, but they are for new problems, which is not something a creator will have known about from a previous warning.

(like the uniform colours, which I know a lot of content creators are not happy about).

A lot of people use many tiny textures when they should use one larger texture map. If we start warning for that (and it is a performance issue, so it would be appropriate to do so) then I expect they'll be unhappy at that too. A lot of people being generally unhappy doesn't mean there isn't a valid point here.

 

[shaneturner12]

Makes sense, but it's going to be harder to convince other forum users regarding warnings, although it is a step in the right direction.

There are a few warnings I know of though that can cause other problems though - like not having a mesh displayed by default, and missing .texture.txt files (which I've noticed in a few non-builtin assets as well as built-in assets).

Shane

 

[andi06]

Auran seem to be congenitally unable to grasp the issue which the community has with errors and warnings and why so much ink has been spilt on it. Allow me to summarise, again!

1. Showing Error flags in CMP is good. It tells authors that the content is broken and it tells users that it isn't going to work.

2. Showing warning flags to general users is bad. By your own admission they won't be able to do anything about it but it will still worry them and detract from their experience with the game. If the correct action for a general user is to ignore something it's not very bright to draw it to their attention in the first place. Despite your assurances (which many of them will never see) some of them will fiddle and may turn the yellow flags into red ones. When this happens they will blame Auran or the Authors. It will also give the general impression that flagged content is of poor quality, whether this is justified or not.

3. Showing warning flags to creators is good, but only some of the time. When they are looking at their own content it gives them useful advice on what to do to improve it. When they are looking at other people's content it shows them what to avoid. But creators are users too and the yellow flags are highly irritating when they are not in content creation mode.

The solution is a no brainer. Provide a switch in the settings dialogue (off by default) to control the display of yellow warning flags. Do this and the level of complaint will reduce, creators will be able to identify issues whenever they need to without having the icons spoil the screen display, users will be serenely untroubled, demands for un-necessary support will reduce and the quality of discourse on the forums will improve.

I would also expect that the incidence of users hacking the assets just to make the warnings go away would reduce and that this would make the warnings a far more effective tool.

 

[Pencil42]

Perhaps the default should be off for everyone else's content, on for your own? With an option to turn them on for everything?

 

[mick1960]

It is entirely reasonable to use an *.m.notex material type for things that don't benefit from a non-uniform texture

If there is one monochrome texture you are right. But if there are more it might be a better idea to put a checker board of those colors inside another already used texture. You can save a lot of materials, which are according to my tests the worst performance eater.

Less materials equals better performance
Less texture maps inside a material ditto.


Mick!

 

[WindWalkr]

2. Showing warning flags to general users is bad. By your own admission they won't be able to do anything about it but it will still worry them and detract from their experience with the game. If the correct action for a general user is to ignore something it's not very bright to draw it to their attention in the first place.

This is why we don't do this any more.

kind regards,

chris

 

[frogpipe]

Really? What are all those yellow "!" for other peoples pre 2.9 assets in my CM list?

 

[andi06]

They still show up here but if this is changed for the next public build then that is good news.

 

[WindWalkr]

Really? What are all those yellow "!" for other peoples pre 2.9 assets in my CM list?

That wouldn't happen to be locally modified content, would it?

chris

 

[frogpipe]

Technically no. It's items installed from non-DLS sources, Jointed rail being one of them IIRC. However the green triangle of "locally modified" does show on those items.

Which is another point - bad naming I suppose - it can't verify it was from the DLS and not altered, because it didn't come from the DLS and marks it modified whether the user has opened and modified it or not.

And in any case, the original argument applies

"If the correct action for a general user is to ignore something it's not very bright to draw it to their attention in the first place."

 

[andi06]

Locally modified is a misnomer. It's true that anything downloaded and installed via CMP doesn't show flags. Download the same asset via FTP and drop it into the game and the flags show up.

This is still third party content that the user has not modified, so I repeat ' Showing warning flags to general users is bad.

 

[Termin]

All right. We need to wait - when the respected authors builders items will give new details on the DLS. We wish them good luck and patience!