Change "Prepar3D v4 Add-ons" dir

[simbol 5,773]

They copied multiple versions of the same files, textures, effects, etc. all over the place and reference them multiple times inside multiple directories on multiple XML files.

Recipe for disaster as PD3V4 will override the texture and effect loading engine using the last entry read on the last XML .

You need to read the SDK in order to understand this, the XML method was designed for developers not end users.

Lots of people disagree and that is fine, it is a free world.

Regards,

Simbol 

 

[SimonC 116]

3 minutes ago, simbol said:

They copied multiple versions of the same files, textures, effects, etc. all over the place and reference them multiple times inside multiple directories on multiple XML files.

Recipe for disaster as PD3V4 will override the texture and effect loading engine using the last entry read on the last XML .

Actually, I did read what there is about the new .xml system. Not a dev, but I have some understanding about it. I actually started making those files by hand, before the tool was available.

But thank you for the warning, I'll sure keep in mind what you said, I'll include that into my "list" of things I'll look at, if things go south.

[simbol 5,773]

3 minutes ago, SimonC said:

But thank you for the warning, I'll sure keep in mind what you said, I'll include that into my "list" of things I'll look at, if things go south.

You are welcome.

Best of luck.

Simbol 

[downscc 1,327]

2 hours ago, simbol said:

You need to read the SDK in order to understand this, the XML method was designed for developers not end users.

Lots of people disagree and that is fine, it is a free world.

Yeah, the reason i disagree is there are plenty of computer savy users.  This hobby is full of end users that build their own systems and maybe even spend time with 3DSMax and Visual Studio... I'm not a developer and don't pretend to be but understanding an XML file is one of the easiest things I can imagine.  My impression is that a developer to take such an attitude is a little bit like self promotion.

As for where stuff goes on my machine, all my non-Orbx scenery addons use the xml method regardless of how the developer installs it. I put restrictions on what I allow, for example most will create folders for each product which I modify to one folder for each developer and all their products go in the same xml file.  Less clutter.  Also, if the developer opts out of the auto discovery method I will undo that and force it into my method such that all addons are done the same way with the exception of 12bPilot's SODE which has a logical framework and works so I leave alone. Maybe it's my OCD but I don't allow developers like FSDT to list both scenery and texture components.  All my scenery component paths are to the folder the contains the scenery and texture subfolders and with over 100 addons this seems to work well enough.  Just keep it simple and uniform.  My practices work for all scenery except Orbx of course and I suspect they will start using the xml method in the future just as I think PMDG will too... they have had a full plate just keeping up with multiple platforms and did not want to change their installer method in the middle of that.

[simbol 5,773]

1 minute ago, downscc said:

My impression is that a developer to take such an attitude is a little bit like self promotion.

I am heavily offended by your comments, how I am self promoting myself by trying to avoid people from damaging their simulation environment?

I am just helping people on this forum, specially because the lack of understanding of the SDK XML method is causing havoc all over the place.

And in my personal opinion I don't think you understand the full consequences of XML entries, in any case we can agree to disagree, but by any means is not helpful to start personal vendettas just because someone thinks different from you.

Best Regards,

Simbol 

[SimonC 116]

49 minutes ago, downscc said:

Yeah, the reason i disagree is there are plenty of computer savy users.  This hobby is full of end users that build their own systems and maybe even spend time with 3DSMax and Visual Studio... I'm not a developer and don't pretend to be but understanding an XML file is one of the easiest things I can imagine.  My impression is that a developer to take such an attitude is a little bit like self promotion.

As for where stuff goes on my machine, all my non-Orbx scenery addons use the xml method regardless of how the developer installs it. I put restrictions on what I allow, for example most will create folders for each product which I modify to one folder for each developer and all their products go in the same xml file.  Less clutter.  Also, if the developer opts out of the auto discovery method I will undo that and force it into my method such that all addons are done the same way with the exception of 12bPilot's SODE which has a logical framework and works so I leave alone. Maybe it's my OCD but I don't allow developers like FSDT to list both scenery and texture components.  All my scenery component paths are to the folder the contains the scenery and texture subfolders and with over 100 addons this seems to work well enough.  Just keep it simple and uniform.  My practices work for all scenery except Orbx of course and I suspect they will start using the xml method in the future just as I think PMDG will too... they have had a full plate just keeping up with multiple platforms and did not want to change their installer method in the middle of that.

Dan, interesting concept.

I was actually thinking of separate folder and xml per product. And consolidating all that dev has for that product inside of one folder.

Say in example of Aerosoft, there is Ecosystem\Aerosoft and Effects. I created a separate folder for given airport, put everything in there, and added appropriately into xml. Seems to work fine.

I am still trying it out, seeing what the best concept is for me, but I thought this to be a good way to start it up, so I don't mix anything up.

[simbol 5,773]

1 hour ago, SimonC said:

Say in example of Aerosoft, there is Ecosystem\Aerosoft and Effects. I created a separate folder for given airport, put everything in there, and added appropriately into xml. Seems to work fine.

That works as long as:

1) You only copy textures, effects and sound into your declared XML directories that belong only to those airports.

2) There are no other Add-on's (Planes, Airports, etc.) that use the same Effect or texture names, that you are putting inside those folders.

Why?

When you declare Effects, Sounds or Textures inside of an XML and you use the Add'on's XML method you are instructing PDV4 to override any other effect, Sound or texture in the system with the ones declared on your folder structure.

To illustrate this, imagine this situation:

1) Plane A, it is a Boeing 737 under the sound subfolder there is a sound with the name EngineSound.WAV

2) Plane B, it is a Cessna and under the sound subfolder there is also a sound with the name EngineSound.WAV

Under normal circumstances both planes will load their own custom EngineSound.WAV since they are located under their own sound directory.

Now an end user decides that it doesn't want these planes under the normal SimObject directory, and it wants to copy their structure somewhere else, it copies each plane under D:\MyPlanes.

D:\MyPlanes\PlaneA

D:\MyPlanes\PlaneA\Sounds

D:\MyPlanes\PlaneA\Texture

D:\MyPlanes\PlaneA\Effects

Etc.

D:\MyPlanes\PlaneB

D:\MyPlanes\PlaneB\Sounds

D:\MyPlanes\PlaneB\Texture

D:\MyPlanes\PlaneA\Effects

Etc.

And for the sake of the example the user creates 2 XML  files, one for each plane.

Here is where people do mistakes, inside the XML they place entries for Effects, Texture and Sounds, this instruct PDV4 to override Sounds, Effects and Textures using filenames, what does this mean?, let me illustrate an example?

PDV4 reads your first XML, it says there is a Sound folder under D:\MyPlanes\PlaneA\Sounds

PDV4 reads your second XML, it says there is another Sound folder under D:\MyPlanes\PlaneB\Sounds

The last entry has priority over any sound folder in the system.

You open Prepard3D, it ask you to active the Add-on's and you said YES.

Next time you load the Cessna and the sim needs to locate the Sound EngineSound.WAV, the highest priority for this sound would be the sound located inside D:\MyPlanes\PlaneB\Sounds, which in this case is the right sound.

Now you load the Boeing, the sim needs to locate the Sound EngineSound.WAV, however the highest priority is still the sound located on D:\MyPlanes\PlaneB\Sounds, so unfortunatelly your 737 engine now sounds like a Cessna!. The same concept applies to Textures, Effects, Shaders, etc.

This is just an example of how many users are breaking their simulation environment due to the lack of understanding of the SDK Addon-on's XML method and behavior, I am not saying everybody does this mistake or that you would make this mistake, I am just raising awareness of the implications of the XML method, and before any user wants to start using it they should fully understand the consequences of what they are doing.

On the example above the correct method to move these planes is to copy the structure of the planes to the alternative directory and declare inside the XML only the SimObject directory (D:\MyPlanes), however a lot of users then find that some planes don't work under this scheme but this is because those planes need their developers to adapt their Gauges, Models, etc. to support the XML method in accordance with LM requirements.

Best Regards,

Simbol

 

[Ebs 114]

13 minutes ago, simbol said:

PDV4 reads your first XML, it says there is a Sound folder under D:\MyPlanes\PlaneA\Sounds

PDV4 reads your second XML, it says there is another Sound folder under D:\MyPlanes\PlaneB\Sounds

The last entry has priority over any sound folder in the system.

Is this the case? I thought the Sound folder declared in the add-on.xml just gave P3D another sound folder to load files from. So, the PlaneA and PlaneB situation would only cause problems if they contained identical filenames?

I'll have to read through the SDK section properly! 

[simbol 5,773]

1 minute ago, Ebs said:

Is this the case? I thought the Sound folder declared in the add-on.xml just gave P3D another sound folder to load files from. So, the PlaneA and PlaneB situation would only cause problems if they contained identical filenames?

I'll have to read through the SDK section properly! 

How do you think my AI Lights are overriding all the default lights for all your planes without modifying any Aircraft.cfg file?

Best Regards

Simbol

[SimonC 116]

18 minutes ago, simbol said:

PDV4 reads your first XML, it says there is a Sound folder under D:\MyPlanes\PlaneA\Sounds

PDV4 reads your second XML, it says there is another Sound folder under D:\MyPlanes\PlaneB\Sounds

The last entry has priority over any sound folder in the system.

Huh, that doesn't make a shred of sense. That would mean all and each addon developer must have unique filenames...?? Or did I misunderstand something?

[vgbaron 3,486]

Simbol -  As you know I agree in principal with what you say but not always in practice. The problem is n ot the METHOD but the fact that many developers either do not understand it or choose to ignore it. If any developer is using an effects file with the same name, then it will overwrite the one in the default effects folder whichever method they choose to install.

Now, I do NOT believe it is intentional but your comments about sim users vs developers ARE insulting. We simmers are a varied group and being a developer is no big deal except if you have a popular product. There many simmers who have had long careers in IT, Aviation, product development, etc.  There are also many who are barely computer literate.

I agree that one should understand what the xml method does and what the pitfalls are but it's NOT a dangerous trap waiting for the unsuspecting user. 

Expressing caution is good but users adapting products to the xml system is not a big deal as long as they pay attention to the file structures.

Vic

[Ebs 114]

@simbol https://www.prepar3d.com/SDKv4/sdk/add-ons/add-on_packages.html says

Sound - Refers to a component that adds an additional sound directory that Prepar3D can use to resolve sound files.

Now, granted what the docs say and what really happens can be completely different but I haven't tested it enough to find out.

 

[simbol 5,773]

Just now, Ebs said:

@simbol https://www.prepar3d.com/SDKv4/sdk/add-ons/add-on_packages.html says

Now, granted what the docs say and what really happens can be completely different but I haven't tested it enough to find out.

Trust me, this is how my AI Lights effects are being implemented.

Simbol

[SimonC 116]

Thinking a little further about what you wrote above:
 

Quote

 

Here is where people do mistakes, inside the XML they place entries for Effects, Texture and Sounds, this instruct PDV4 to override Sounds, Effects and Textures using filenames, what does this mean?, let me illustrate an example?

 

This indeed is correct if you use direct path, as in "Effects" and not absolute path, as in D:\MyPlanes\PlaneA\Effects".

If only Effects was used, then I do understand that the last XML would take precedence. But not if absolute paths are used.

[simbol 5,773]

Just now, SimonC said:

Thinking a little further about what you wrote above:
 

This indeed is correct if you use direct path, as in "Effects" and not absolute path, as in D:\MyPlanes\PlaneA\Effects".

If only Effects was used, then I do understand that the last XML would take precedence. But not if absolute paths are used.

Yes Simon, but not everybody understands it, and they do it wrong! in hence why I am trying to bring awareness.

Best Regards,

Simbol