Add-on.xml - texture calls & long frames

[kmax59]

Hello,

Since v4 I'm struggeling a bit with long frames and loading stutters, just like several developers including myself, you've moved from the classic scenery.cfg entries to the add-on.xml method.
After looking closer to this method, I've discovered that the way you have created your xml can potentially create long frames/ loading stutters, I'll explain this below. This is actually not really your fault but probably the way it is designed by Lockheed martin, that said, there is a way to reduce this effect.

When installing one of your sceneries, you're adding two things in your add-on.xml:
- A scenery entry (for example: D:\Addons\FSdreamteam\Addon Manager\FsDreamTeam\KLAS\scenery)
- A global texture entry (for example: D:\Addons\FSdreamteam\Addon Manager\FsDreamTeam\KLAS\texture)

However, after looking at process monitor, I've discovered that Prepar3D is looking hundred of times for default P3D textures inside the texture folders of your sceneries, and this in a quite short time frame.
Of course these textures don't exist in the FSDT texture folders and Prepar3D is then looking for a "texture.cab" file, and repeat the entire process from time to time. This unfortunately creates long frames in the sim.

Thus, I've simply changed the add-on.xml and only let the scenery entry (for example: "D:\Addons\FSdreamteam\Addon Manager\FsDreamTeam\KLAS\scenery" became "D:\Addons\FSdreamteam\Addon Manager\FsDreamTeam\KLAS").
This still allows the sim to read automatically the texture folder of the corresponding scenery and didn't saw any issue but it eliminates the useless texture calls.

In a nutshell, the global texture entry seems to be useless for your sceneries and is creating useless long frames.
I was wondering if there was a specific reason for using this global texture entry and if not, if you could consider changing this to reduce useless texture calls?

Thanks by advance !
Maxime

[virtuali]

This has been already discussed here:

http://www.fsdreamteam.com/forum/index.php/topic,16371.msg116774.html#msg116774

It's possible, depending on the system, that not having to open the texture.cfg fallback file (since the Simobjects will find the textures before using it, thanks to the explicit <Texture> path added), might be faster than searching for the texture.cab file, or the opposite might be true.

Try changing the GLOBAL specification to WORLD. The SDK is not very clear on this but, we surely require the textures for the Simobjects too, not just the .BGLs in the \scenery folder (in fact, 90% of the scenery is made with Simobjects) so, you cannot just remove the texture call altogether. They are working now, just because they have a Fallback in the texture.cfg, but this would prevent, for example, the ability to change the path of the scenery and the Simobject relative to each other.

So, ideally, if the WORLD spec works better, we might just switch to it, but I'm not sure it's a good idea to leave out the texture path.