Compatibility issue

[llebrez]

Interesting issue with built numbers: I had to re-install TRS19. Left it without any patch, so it is 105096. It works fine with all the built in routes. Some of them show in the config file as build 4.3 others as 4.6. I import my own route with 4.6 with all the dependencies. As far as I can see there are a few missing dependencies or faulty. All repairable or available to download from DLS. but the route shows as incompatible and the build number not recognized. How come? My number is the same.. Bottom line is how can I get my route working before I start patching up this version? The error shows: VE88 This asset has a number not recognized by this tool.
Years ago, I did it and had no problems, as far I can remember I did the same thing as now. Thanks.

 

[JCitron]

Try running a database repair then import the route again.

 

[llebrez]

John: I forgot to mention that in content manager, my route appears in black and white, and others in red. Can't find what the difference of colors mean. Will an EDBR helps? or may damage more things..?

 

[OddRails]

You can also list dependencies recursively to see what asset is causing the problem.

I'm guessing it is either a TrainzPlus item or someone repaired an asset with a dependency that has a build number greater than 4.6

 

[p-dehnert]

In ContentManager red assets are faulty, or have missing (or faulty) dependencies.

Peter

 

[llebrez]

Just a far off thought: Note my text on the start of the thread. I installed my back-up of the route. This back up happens, or I do once a week, so it is made on a route that was installed on build 111951 TRS19 Latest update. The new install is raw, has not been updated yet. Is it possible that a route backed on build 111951 would not work on 105096 ? even if the 4.6 is the same? Defies logic but is the only thing I can think at the moment.

 

[OddRails]

I don't know what would happen when you transfer a route from 111951 to 105096. But if it has the same build number 4.6, I think it should work.

So you're saying that none of the route's dependencies are faulty or incompatible and the actual route is the only problem?

What happens when you select the route in content manager and then click on the show errors and warnings function?

 

[p-dehnert]

Build 111951 is TRS19 SP3, which usually uses trainz-build 4.8 when saving a route. Build 105096 is TRS19 SP1, using trainz-build 4.6.

Peter

 

[llebrez]

Build 111951 is TRS19 SP3, which usually uses trainz-build 4.8 when saving a route. Build 105096 is TRS19 SP1, using trainz-build 4.6.

Peter

Thanks for clarifying. Then, I assume that SP3 should open routes with 4.6 and or below? And, SP1 will not open 4.8 Further, changing these numbers in the config file does not convert to whatever number I select. Is there a way to convert the build number in a route?

 

[JCitron]

Thanks for clarifying. Then, I assume that SP3 should open routes with 4.6 and or below? And, SP1 will not open 4.8 Further, changing these numbers in the config file does not convert to whatever number I select. Is there a way to convert the build number in a route?

Yup. This is exactly the issue. I made this mistake before.

As Dave mentioned above, be aware of this. Some people have updated older assets and use newer dependencies. While the main asset maybe the correct build for an older Trainz version, the newer dependencies cause the asset to fail.

 

[llebrez]

Indeed: Since I have all my assets backed from long ago, I am replacing the latest ones with the old ones. Visually I can't tell any difference. And they work! It just takes time and more clicks on the mouse. However, the old ones have mostly Testures, and the updated ones are TGA, and I think trainz works better with TGA than Textures.. A conundrum? Remember this version is SP1, and eventually I will update to SP3, and then, the TGA thing will come back...

 

[JCitron]

Indeed: Since I have all my assets backed from long ago, I am replacing the latest ones with the old ones. Visually I can't tell any difference. And they work! It just takes time and more clicks on the mouse. However, the old ones have mostly Testures, and the updated ones are TGA, and I think trainz works better with TGA than Textures.. A conundrum? Remember this version is SP1, and eventually I will update to SP3, and then, the TGA thing will come back...

All Trainz versions use .textures files. These are proprietary binary files that Trainz versions use to load the .TGA plus the texture_name.texture.txt file combination into Trainz.

If we have taken built-in or DLC assets and export them out and try to import them in, Content Manager complains about them and brings up an error not because the asset is bad, but because Content Manager doesn't recognize the .texture file format. PEV's Images2TGA will fix this by decompressing or rather decompiling the .texture files into the .TGA and texture_name.texture.txt components.

While decompressing brings back the two components and makes the assets usable again, decompressing the textures this way can degrade them because. On some assets, this is pretty obvious due to low resolution textures to start with while other assets may appear fine with little or no apparent degradation.

 

[Forester1]

All Trainz versions use .textures files. These are proprietary binary files that Trainz versions use to load the .TGA plus the texture_name.texture.txt file combination into Trainz.

If we have taken built-in or DLC assets and export them out and try to import them in, Content Manager complains about them and brings up an error not because the asset is bad, but because Content Manager doesn't recognize the .texture file format.

I am familiar with this and am an experienced user of Images2TGA, but this just seems odd. "All Trainz versions use .texture files." and "Content Manager doesn't recognize the .texture file format" just doesn't make sense to me. These are files specific to a program that doesn't recognize them. And yet we know that Trainz uses these files without complaint until someone touches them or loads them from third party sites. Am I missing something here?

 

[norfolksouthern37]

It doesn't recognize it because the program doesn't open them it expects source files in order to create them; CM makes .texture files using the source image plus the texture.txt information. This is the only texture format that is used in the simulator except for UI elements.

When you pull an asset of the built-in archived items the .texture files are there, but the original image and texture.txt are not included in order to save space since the simulator doesn't use them. That is why an error is given about texture.txt when trying to move them to a new install or submit these items. These .texture files are usually encoded in such a way that the TGA tool cannot open them to recreate the required files either.

 

[Forester1]

I understand what you are saying, but that seems like it would be some pretty simple recognition intelligence to include to see the .texture files and recognize them for what they are. Only a little more to analyse them to make sure they are what they should be.

 

[llebrez]

There is some truth to all this. Buil in assets all have Texture files and these are not shown red or faulty in CM. If I convert them with PEV, they are now TGA, and no faults. Is it worth to modify these? or better leave them alone. If not broken, don't try to fix...