Just curious

[Forester1]

I have been working on some older assets that go faulty because they have ".texture" instead of ".tga" and ".texture.txt" files. Simple enough to fix with PEVSoft's Images2TGA software, until you find yourself updating an older route with a ton of pofig trees and are cloning st_rmm and auran trees to replace them. That becomes quite a bit of work. But the question arises, why is this only an error when you are doing something like this? There must be a ton of assets out there that are packaged, payware, built-in or otherwise on the CM that are this way, but none of them cause errors until you touch them. So, if they are fine the way they are, why is this an error? Shouldn't this just be a warning? After all, they are proven to still work.

 

[oldman777]

In legacy versions of assets, ".texture" files had a different format than the modern one ".texture" and modern Trainz versions identify this as an error.
Therefore, it is necessary to fix with PEVSoft's Images2TGA software".tga" and ".texture.txt" files to eliminate the errors.
Only game developers can convert to a modern ".texture" format, and there is no publicly available software for this.

 

[wreeder]

What you say is true but not the answer that he is looking for. N3V has code that overlooks some errors in some assets until they are edited. This is part of compatibility mode. The so called spaghetti code was supposed to have been purged in TS12 since it doesn't have a compatibility mode but issues with plugging the TS12 program code into the new E2 graphic engine caused most of the program code to have to be rewritten for TANE. With the release date fast approaching, it was deemed faster to write code to ignore the errors in the included content rather than fix it. But when you edit the content, the error checking system flags the errors.

 

[JCitron]

Actually, the reason is that the older assets were once built-in and now imported. The built-in assets compress everything down to the .texture format, a format that's Trainz specific for the game engine to use. These compressed files are the combination of the texture configuration file, aka the texture-name.texture.txt, and the texture.tga file. Since the files are already compressed, they can't be interpreted when the files are brought in raw into Content Manager who has a hissy fit over them and throws up an error. Peter was a genius by writing the Image2TGA to decompress the .texture files into its components, but this comes at a cost. Since the textures were already compressed before, decompressing them and then compressing them again actually degrades the quality of the textures. This is no different than decompressing a compressed .jpg and recompressing then decompressing the file.

Pofig's trees suffer from older SpeedTree format that used the old 4.x 32-bit engine which is incompatible with TANE and up. Instead being able to update the trees, we we've been stuck replacing them. This is why N3V has sought out an alternative and gotten away from SpeedTrees.

 

[Forester1]

I appreciate your responses, and I think I understand them, but I still don't understand why a given st_rmm or auran tree is OK as is, with .texture files, but the minute I clone it, those .texture files are all of a sudden faulty. My argument is no, they are not, because they are just fine in the st_rmm or auran tree. Nothing has changed except the KUID number. They are the exact same file with the same compression. Every time I run a DBR, it checks for faulty assets. Why aren't all of the st_rmm and auran trees flagged as faulty if the .texture files really are faulty? Conversely, why are the clones flagged as faulty if they really are not? it still seems like it should be at most a warning, not a faulty.

 

[wreeder]

Perhaps I wasn't clear with my answer. The error checking routine looks for a texture.txt file and the images named by that file. If the images are missing then that throws an error. This is because when the game loads the asset, it creates the .texture file for the game engine to use interrnally from the images named by the texture.txt. In order to reduce space in digital downloads, N3V does this processing on all incuded content and then deletes the images as they are no longer needed to create the .texture file. The error checking routine ignores the fact that the images are missing because N3V tells it to do so on pre-cached assets. But when you open the asset for editing, that pre-cached condition no longer exists so the error checking routine flags the fact that the images are missing. The images2TGA software simply recreates the images and or the texture.txt file from the .texture file therefore making the error checking routine happy.

 

[Forester1]

I think I understand what you are saying, but I still don't understand it as the answer. I'll just have to accept that it is the way it is. Thank you for the explanation!
EDIT, rereading both your posts it sounds like the st-rmm and auran trees actually are faulty, but the system doesn't really look at them until they are edited. But I guess my point is, they actually work in the simulator! In that case, I guess I am questioning whether they are actually faulty at all, or maybe I don't understand the concept of faulty.

 

[wreeder]

Ah, if you are getting the same error message as I have seen, the trees are fine as far as the game engine is concerned hence the reason they work. But when you clone them and go to commit them, the error checking routine in CM is looking at them as if they are newly created by you. So it applies its rules for freshly created content. Those rules are expecting there to be a texture.txt file for every image and that there be an image in .tga or .bmp or .jpg format matching the name in the texture.txt file. When it doesn't find that situation it declares an error and marks them as faulty. But if you could get around that error checking then the trees would work in the game. It is a bit of a Catch 22.

Lets go back to TRS2004. It didn't check content for errors before it loaded into the game engine. The content if it was made badly could cause the game engine to write an error to the error log during play but it could be that the error was minor and the asset seemed to work as expected so no one cared. On occasion, the object would load but be invisible due to errors with the mesh. Checking the error log would give you the error and you tried to fix the issue. TRS2006 introduced the first Content Manager app and error checking outside of the game engine. So an asset that failed the CM error checking was declared as faulty and not allowed to load into the game engine during play. Note, that the error checking is external to the game engine's error log. In TRS2004, some content could crash the game engine if it had bad enough errors. So the error checking in CM is protection to stop content with errors from being loaded and possibly crashing the game engine.

In the particular case of the trees, they were made with the images and CM was happy. But prior to shipping N3V processes the content set and during that process the .texture files are created so the game engine won't have to do that when you load a route that uses them. Remember how some of the Trainz Plus updates were slow the first time you loaded any route? That was because the content included in the beta build was not pre-cached yet. I understand the process takes quite a long time so they only do it for important builds like release candidates. N3V decided that as part of that process done to the entire content set, they would remove the images to save space since the game engine only cared about the .texture files and the assets in the content set don't go through the error checking of CM.

 

[Forester1]

Thank you, I am gaining more understanding, but I still think if it works, it works. Throw a warning, but not an error.

 

[JCitron]

As you know, you can ignore warnings but not errors.

If you want to give this a try, you can precache specific assets using the Trainz Util command. Sometimes, rebuilding the cache will get rid of old errors because the cache is stale and Trainz is reading the cache and not the data on the disk.

Click on the Developer menu located at the top of the Launcher and on Content Manager.

Choose Trainzutil

A window will appear where you can type in these commands.

prebuild --force --nofail <KUID> (Put in the specific kuid you want to precache.)

A second window will appear while the command runs with a green bar moving back and forth until the command processes.

If this doesn't work, you can put in prebuild --force --nofail without the kuid and rebuild the full cache. If you do this, plan on letting it run over night, or do something else while the process is running.

 

[wreeder]

Thank you, I am gaining more understanding, but I still think if it works, it works. Throw a warning, but not an error.

But it is an error. Trying to submit an asset that is lacking the images the game engine needs to create the .texture files will result in an asset that at the least will not look correct in game and at most could crash the game. As I pointed out in my first post, this is an example of N3V bending the rules by not having the builtin content set be subject to the rules checking of CM because they know the content is OK. Perhaps the logic of the error checking routine could be changed to something like "if the images are missing, throw an error unless the .texture files are present" but that is assuming the end user knows what they are doing and in programming that is a very dangerous assumption to make.

Many items created for TRS2004 were made on the if "it works in game then it is good mind set". However, behind the scene many assets were secretly causing performance issues and sometimes crashes. It was a major pain to try and find those assets based just upon the error log's cryptic entries. Having external error checking in CM greatly reduce the hassle of fixing those items.