Alabeo and possibly carenado issues with add-on.xml method? P3dv4, missing some sounds/actions

[theskyisthelimit 48]

I think i've run into the first visible issue with doing things using this method.

I created a folder v:\p3d addons\aircraft\alabeo  (and another up there in the root of aircraft for carenado)..

When i run the installer for either publisher i set the path to their root folder, alabeo or carenado. (i do this for every craft.. same root folder install location, alabeo, carenado etc)

Take for instance the c404 alabeo..
it then puts effects, sound, simobjects\airplanes in the root folder among others.

I created either by hand or via Lorby's tool.. the addon xml with the entries for gauges, sound etc..

For the sound folder it might have subfolders.. like Sound\ALASoundPAC404 or Sound\ALASoundDA42  and no files in the root of Sound.. but the add-on xml points to Sound (no subfolder).

When i load the aircraft, one example, if you open the door while flying, you should hear the whipping of the wind effect.. using the addon xml method it doesnt generate the sound.  Also.. in at least one of my test planes I wasnt getting full aileron movement, but when i installed it directly in the p3dv4 folder i was.

Wondering if i should be changing something here

I tried creating multiple sound entries pointing to each subfolder but that didnt work either.
It keeps those subfolders when it installs into the root of p3dv4 as well (and works obviously).

Thanks in advance

[simbol 5,767]

Hello,

By using the .XML method you have altered the order and preferences of how P3D V4 will resolve the required sound, effects, gauges and textures for the entire simulator environment, not only for any particular add-on.

You are now experiencing a conflict name resolution for your sounds and maybe even for other files that you are not noticing "yet", this is the reasons why you are hearing wrong sounds or missing some, the simulator is just loading a different sound set as intended by the developer.

This is the reasons why I have been warning people to be very carefully about using this technique, please note I am a PD3 Developer, I fully understand the consequences of the .XML method, I am using it for a new freeware add-on that I am about to release this week, and from what I have been reading on this forums, either people has been told wrongly how to use it or they understood it wrong.

I will try to explain it again, but if you require further help with your particular case please feel free contact me privately, I am more than happy to examine all your .XML files and attempt to find a solution to your problem.

If you add a Sound section to any .XML and add it to your C:\users\xxx\documents\prepard 3D V4 Add-ons\ and use the .XML technique you will instruct your flight sim simulator to "override the file name resolution ordering" for sounds.

Same thing applies for effects, gauges, etc. when you use this Technique, and it all gets very confusing when you start doing this with multiple .XML as I am sure you and other have done.

Sound name = SoundA.Wav

The sound is shared with 3 carenado planes, each plane has the same sound file, installed on their corresponding subdirectores, however the sounds are "different" as they only have the same name.

You go ahead and prepare a .XML, you add a section of Sounds for each plane, now you believe that the sim should find the sound for each plane, but you are wrong this is what actually happens:

1) The sim loads the first .XML, it says there is a section for sounds on F:\plane1\Sound.

2) The sim loads the second .XML, it says there is a section for sounds on F:\plane2\Sound.

3) The sim loads the third .XML, it says there is a section for sounds on F:\plane3\Sound.

The result is as follow:

Priority to load Sounds:

Priority 1:

F:\plane3\Sound.

Priority 2:

F:\plane2\Sound.

Priority 3:

F:\plane1\Sound.

Note: Priority 1 has a higher value, it overrides the rest.

You load the sim and select plane 1, it has instructions to load SoundA.WAV. the sim uses the priority logic this is what happens:

SoundA.WAV its found inside 3 directories, but Plane3\Sound has a higher value so your plane1 is now using SoundA.WAV from Plane3.

The logic will happen with Textures, Gauges, Effects, etc. More over this will slow down your sim since it has to check each file it founds on its logic path!, the more paths you add the worse it gets.

I hope this makes it clearer for you guys, you should not add the sound, effects, textures, etc. section! if you want to move a plane, you should install the plane to F:\xxx and you should only create an XML file with the section <SimObjects> this tells the sim to find alternative planes on that area, the sounds, effects, textures and gauges that belong to the plane will be loaded from the subdirectores as long as the developer designed the add-on this way, if it hasn't then your add-on cannot be installed using this technique.

Best wishes,

Simbol

 

 

 

 

 

 

[theskyisthelimit 48]

40 minutes ago, simbol said:

Hello,

By using the .XML method you have altered the order and preferences of how P3D V4 will resolve the required sound, effects, gauges and textures for the entire simulator environment, not only for any particular add-on.

You are now experiencing a conflict name resolution for your sounds and maybe even for other files that you are not noticing "yet", this is the reasons why you are hearing wrong sounds or missing some, the simulator is just loading a different sound set as intended by the developer.

This is the reasons why I have been warning people to be very carefully about using this technique, please note I am a PD3 Developer, I fully understand the consequences of the .XML method, I am using it for a new freeware add-on that I am about to release this week, and from what I have been reading on this forums, either people has been told wrongly how to use it or they understood it wrong.

I will try to explain it again, but if you require further help with your particular case please feel free contact me privately, I am more than happy to examine all your .XML files and attempt to find a solution to your problem.

If you add a Sound section to any .XML and add it to your C:\users\xxx\documents\prepard 3D V4 Add-ons\ and use the .XML technique you will instruct your flight sim simulator to "override the file name resolution ordering" for sounds.

Same thing applies for effects, gauges, etc. when you use this Technique, and it all gets very confusing when you start doing this with multiple .XML as I am sure you and other have done.

Sound name = SoundA.Wav

The sound is shared with 3 carenado planes, each plane has the same sound file, installed on their corresponding subdirectores, however the sounds are "different" as they only have the same name.

You go ahead and prepare a .XML, you add a section of Sounds for each plane, now you believe that the sim should find the sound for each plane, but you are wrong this is what actually happens:

1) The sim loads the first .XML, it says there is a section for sounds on F:\plane1\Sound.

2) The sim loads the second .XML, it says there is a section for sounds on F:\plane2\Sound.

3) The sim loads the third .XML, it says there is a section for sounds on F:\plane3\Sound.

The result is as follow:

Priority to load Sounds:

Priority 1:

F:\plane3\Sound.

Priority 2:

F:\plane2\Sound.

Priority 3:

F:\plane1\Sound.

Note: Priority 1 has a higher value, it overrides the rest.

You load the sim and select plane 1, it has instructions to load SoundA.WAV. the sim uses the priority logic this is what happens:

SoundA.WAV its found inside 3 directories, but Plane3\Sound has a higher value so your plane1 is now using SoundA.WAV from Plane3.

The logic will happen with Textures, Gauges, Effects, etc. More over this will slow down your sim since it has to check each file it founds on its logic path!, the more paths you add the worse it gets.

I hope this makes it clearer for you guys, you should not add the sound, effects, textures, etc. section! if you want to move a plane, you should install the plane to F:\xxx and you should only create an XML file with the section <SimObjects> this tells the sim to find alternative planes on that area, the sounds, effects, textures and gauges that belong to the plane will be loaded from the subdirectores as long as the developer designed the add-on this way, if it hasn't then your add-on cannot be installed using this technique.

Best wishes,

Simbol

 

 

 

 

 

 

Again i get what you are saying here, but i dont think this works like this entirely, please explain otherwise.

What i mean is, there are other vendors/publishers using the same method for their aircraft.. take a2a for example.. they define their own effects/gauges/simobjects.. but no sounds from what i can see.  Everything goes to the root of A2A just like i've done for these other two.. i dont break aircraft down by folder.. i put all publishers files in the same single folder.. so there is ONE effects, gauges, sound, simobjects for each folder.

Same for scenery.. there are many vendors that have addons for scenery in the xml..

If i understand what you are trying to say here, that for these publishers, they are forcing the sim to ignore the built in root files when it sees the xml paths for Everything?  I was under the impression that it only directs the addon to the separate files (and overrides root files).. it doesnt block the sim from being able to use root sounds or root effects for other addons not in the xml method.

So again in my case.. ill simplify my pathing here for ease.. i have something like:

V:\alabeo  

then V:\alabeo\sound
                       \sound\aircraftxyzfolder
                      \sound\aircraftxyzzzzfolder etc
                     \simobjects
                     \effects    etc

and v:\carenado  with the same type of subfolders.

It was my understanding that alabeo craft in simobjects under the alabeo custom folder would then pull the sound folder at the root and find the right sound file it needs and not look to the p3d root sound folder if it finds what it needs.  (basically like overwriting the defaults without doing so)

Again i'm not creating one craft per folder.. but one publisher and many craft under that with the same basic folders under there.

I have no issue pointing the installer to the p3dv4 folder as intended, if i cant get this working correctly, its just more ideal for backups to have them in their own area.  A2a is no problem, but that might be because they already fully employ the xml method.

I'm pretty sure others on here have done this successfully, i may just be missing a step or arrangement.

And the way i have the sim so far, i have only stock xmls in the document folder for scenery (i had created xml entries for everything previously but i only use that to test out things and move back the folders as needed to stock).. only addons in there custom so far are the aircraft.

 

edit: here is an example of the addon method for realair, which i went through and did and didnt observe any weird behavior so far, but i dont think there was a sound folder involved there either.

edit: here is a thread on the p3d forums that seems to indicate an issue with the sound folder in this method, or related to carenado

[simbol 5,767]

Hi again,

I will check your examples later, but the problem is not where you put the files, is the way the .xml are created and the logic the sim applies. That is what people is not understanding.

This method was created for developers to deliver add-on's in a different way and avoid overriding LM base files, conflicts with other add-on's, etc. For example an App like REX HD Textures, they need their add-on to override the default halo.bmp, but they cannot overwrite your default halo.bmp file, instead they will instruct the sim via the XML to use their textures with a higher priority.

As I said, I am more than happy to help you, but some time it is very hard to explain these things over text. You can contact me private or alternatively you can read the SDK documentation for PDV4, maybe that will help us to be on the same page.

Best Regards 

Simbol 

 

 

[vgbaron 3,482]

@Simbol - 

Sorry - I believe you are NOT correct in this example. Have you looked at the Carenado file structure?

If you installed the Carenado a/c into the default P3D folder - the contents of the Sound, Fonts, Effects and Gauges folders would be ADDED to the existing P3D folders. Therefore, the evaluation of the files would be exactly the same as having been added using the xml method.

*IF* the complete file structure for the "sounda.wav" file were the same, several things could happen:

the file would be overwritten and/or P3D would flag the file as a duplicate - then the user has to decide

In the case of Carenado the file structure is unique so there is no conflict. Many of the Carenado sound files are accessed specifically by the carenado sound gauge dll.

The same goes for the fonts and effects.

There is a reason that LM is using this method and it is the method that they prefer.

The only problem that can arise is if the developer and/or the user makes a mistake in application. There are several products installed this way that APPEAR to work but there are subtle issues, mainly coming from indirect folder references ( ../../) etc.

Vic

[simbol 5,767]

Hi Vic,

Sadly I can see I cannot express the logic correctly so people understand my point, the file structure is not the problem, it is how the xml is interpreted by PD3V4.

In any case the important thing here is to help theskyisthelimit, so I hope someone else can step in if my advise is not useful.

All the best 

Simbol.

[vgbaron 3,482]

Simbol - your advice is VERY useful - please continue. I *think* I see your point now. I'm focusing on the file structure and not the parsing priority and it's the priority that would cause the problem.

In any case, I will bow to your expertise - I am no longer current in my programming skills so there may be many things that are not obvious to me.

Not the first time I've been wrong and certainly not the last!  

So again, please continue to provide your expertise here!

Vic

[theskyisthelimit 48]

Guys.. i'd like to see the sdk portion that talks about xml files taking priority over others when it comes to aircrafts (i cant seem to find a reference in there on this).. not that i doubt anyone, would like to read up.  I know priorities are handled by layer settings for groups of addons in one xml file, but thats scenery.

On the issue with sound.. i think, 90% sure.. this is a carenado/alabeo issue.. that in some way they have the craft hardcoded to only look to the root for the files.. (that other p3d thread i linked has mentioned this issue).. so i guess two options.. install as normal intended and not worry about it.. or maybe use a symbolic link from the sound folder to the sound folder at the root if that even works, but its half baked since files still end up in the root of the p3d folder, defeating the goal of isolation.

I think this may be defeat on any addon publisher that has this issue and has a sound folder, until they do things more in spec with what LM was hoping would be done.

 

[vgbaron 3,482]

Yes, they are hardcoded to the P3D root. Their gauge calls the sound files via 'Sound/Carenado/xxxSound/xxxx.wav'. Either install as Simbol suggests - all in root folder other than Simobjects or possibly the symbolic link.

this from the Add On Packages section of the SDK may be what Simbol is referencing:

"For each add-on package being processed, its add-on components, found inside the package, are processed in the order they are read. By default, add-on components processed via packages will take precedence over any add-on components not found in a package (i.e. entries in add-on configuration files)."

Vic

[simbol 5,767]

2 hours ago, theskyisthelimit said:

Guys.. i'd like to see the sdk portion that talks about xml files taking priority over others when it comes to aircrafts (i cant seem to find a reference in there on this).. not that i doubt anyone, would like to read up.  I know priorities are handled by layer settings for groups of addons in one xml file, but thats scenery.

On the issue with sound.. i think, 90% sure.. this is a carenado/alabeo issue.. that in some way they have the craft hardcoded to only look to the root for the files.. (that other p3d thread i linked has mentioned this issue).. so i guess two options.. install as normal intended and not worry about it.. or maybe use a symbolic link from the sound folder to the sound folder at the root if that even works, but its half baked since files still end up in the root of the p3d folder, defeating the goal of isolation.

I think this may be defeat on any addon publisher that has this issue and has a sound folder, until they do things more in spec with what LM was hoping would be done.

 

http://www.prepar3d.com/SDKv4/LearningCenter.php open the left navigation side and find the entry Add-on's, be aware it is a deep read.

Some of many key text paragraphs people are not understanding or are unaware:

1)

When Prepar3D loads, there is a discovery phase where new add-on packages inside each of the discoverable add-on folders are found and cached. Add-on packages can be found and loaded upon startup if they are placed one directory level deep inside an add-on discovery folder. Any add-ons that were cached but could no longer be found are subsequently cleaned up.

For each add-on package being processed, its add-on components, found inside the package, are processed in the order they are read. By default, add-on components processed via packages will take precedence over any add-on components not found in a package (i.e. entries in add-on configuration files).

These explanation is heavy, but it just tries to explain how things takes precedence, now I just developed an add-on that need this overriding precedence mechanisms, and I did over 500 tests not only with the .XML method but also the command parameters to configure the precedence, my previous explanation before about how things get overridden is also based on experience.

2)

Overview

This document describes the Prepar3D preferred method for development and installation of add-on material. (it means is not the only one, PMDG 737 for V4 didn't)

Add-on Compilation Settings

For add-on libraries and executables, it is recommended that all software add-ons be developed using Visual Studio 2015. Further, the Platform Toolset should be set to v140 and the Targeted Framework should be .NET Framework Version 4.6.2. These settings will help ensure consistency and compatibility for all new development.

As you see, you cannot just convert everything into a package, it needs the requirement above. Failing to do so will cause random CTD on Prepard3D V4.

3)

Add-on Content Error Reporting

While developing add-on content, it is essential that you turn on Content Error Reporting to verify that your content is pragmatically correct ensuring the best possible experience for the end user.

Again we developers need to ensure that any tool to be installed as an add-on package is prepared correctly, it is not just adding an .XML file.

Conclusions / Advise

If you want my advise, I wouldn't fiddle with XML files, but if you want / must the correct way is:

A) Ensure the utility you want to move was recompiled as specified on point 2, Note that fixing LODs, textures, etc., do not count, things need to be recompiled, and tested using the new SDK V4, Visual Studio 2015 settings, etc. I am seeing lots of developer with problems inside the PD3V4 SDK forum because they used VS 2013 or VS 2017!

B) Ensure the add-on you want to move has content error reporting as per LM requirements.

C) Do the XML Correctly, example:

You want PlaneA moved to F:\xxxxxx\PlaneA

Extra PlaneA Sounds are on F:\xxxxx\PlanesA\Sound

Extra PlaneA Gauges are on F:\xxxxx\PlanesA\Gauges

You know that extra PlaneA is 100% compatible with Add-on's packages

The correct XML File is:

<?xml version="1.0"?>
-<SimBase.Document id="add-on" version="4,0" Type="AddOnXml">
<AddOn.Name>PLANE A</AddOn.Name>
<AddOn.Description>PLANE A bla bla bla</AddOn.Description>
-<AddOn.Component>
                       <Category>SimObjects</Category>
                       <Path>F:\xxxxx\</Path>
</AddOn.Component>
</SimBase.Document>

Now the simulator understand you want to declare another location to load a plane, it will load automatically all the sub-folders that are necessary for such a Plane since it was developed to be compatible as a package add-on, so you don't need to add the sound section, you don't need to add the gauges, etc.

Also If you now add Plane A inside the standard default sim object folder (C:\Program Files\Lockheed Martin\Prepar3D v4\SimObjects\Airplanes), you will notice that it is ignored since the path F:\xxxxx has planeA and it has a higher preference to be loaded.

If you add a section for Gauges, Effects or Sounds you are sending wrong instructions to PD3 V4, it will interpret these commands to assign areas that should be used to load sounds, effects and gauges in preference to any other folder across the entire simulator environment.

Only a developer might understand this, but this is the equivalent of configuring  SET Environment variables under the OS, when you configure the PATH environment variables the system use these to search for files, the search is done in sequence (path 1, path 2, path 3), as soon as it finds a file with that name the search stops and that file that will be used, it doesn't matter if there are other possibles files further down the line, more over it doesn't know which is the correct file.

When you add a section for Sounds pointing to f:\xxxx\carenado\sounds, the sim will use that path in preference to any default sim sounds folders, so if you have planeB that needs to load soundA.WAV from the base sim sound folder but there is a soundA.WAV inside of carenado\sounds, the simulator use the carenado sound in preference, now plane B is loading Phenom 300 engines sounds when indeed it was a glider...

This is what I mean about wrong .XML configuration files, you guys are instructing areas to search for files, which will instruct the simulator to override "local" files existent on many of other utilities / add-on;s and as a consequence it is a matter of time to get you into trouble.

I hope I am actually explaining this well, it is very hard to explain these things over text! we should Skype really, in fact we should be flying! I am off to sleep.

Best Wishes,

Simbol

 

 

 

 

 

 

[vgbaron 3,482]

Thank you for the detail. Now I understand your point and I agree with you.

Thanx again,

 

Vic

[Cargostorm 151]

13 hours ago, simbol said:

This is what I mean about wrong .XML configuration files, you guys are instructing areas to search for files, which will instruct the simulator to override "local" files existent on many of other utilities / add-on;s and as a consequence it is a matter of time to get you into trouble.

Simbol, you gave a lot of EXTREMLY useful information here. We were told here in the forum (even by experienced moderators) to use the add-on.xml method. Obviously, if applied wrong, it may have severe effects as some files take over preference on other files. In fact, one has to evaluate if a plane comes with a gauge, sound, effects folder, how to put it into the sim the right way.

I always thought the add-on.xml method would merge the information with the default files of the sim, but obviously it is much more complicated and there are some major points to consider when installing an addon this way. Anyway, it is better to leave that area to the developers instead of fiddling with files. And even PMDG has choosen to avoid the add-on.xml method and integrates its planes the "traditional" way.

[WarpD 824]

The method being claimed as the "correct" method above... doesn't install an addon, instead it defines an additional SimObjects folder.  Now, for all intents and purposes this isn't an invalid way to support adding addon aircraft without placing them in the core sim folders.  However, it's not the preferred method nor does it actually address the sound issue being discussed regarding Alabeo and Carenado aircraft. It would probably also require you to create a seperate location for a Gauges folder and possibly a Sound folder (if files are intended for there).  That would require you to use the command-line feature of Prepar3D three separate times to define these folders.  The definition of these three additional paths to be used by Prepar3D would be a 'global' definition.  You could place additional aircraft into the location you defined for SimObjects and Prepar3D would see them as installed.  Same goes for gauges and sound files.  However, there is the caveat that this method does not survive a reinstallation (uninstall/reinstall) and you would have to run the command-line passing the correct xml files in the command line to reinstall all of those folders.

Using the new addon installation requirements is something that only the developers can ensure is done correctly.  If the developer has a path to a sound file hard coded into their gauge... you're not going to get around it.  Any type of file access the developer needs for their addon can have this issue.  It's probably why PMDG has not changed how they install their aircraft (my supposition only).

Thing is, I suspect sooner or later developers are going to get "locked out" of the core sim folders... somehow.  For those unwilling to adapt... it will be a rather abrupt wall.

[n4gix 4,947]

On ‎9‎/‎13‎/‎2017 at 3:10 PM, vgbaron said:

Yes, they are hardcoded to the P3D root. Their gauge calls the sound files via 'Sound/Carenado/xxxSound/xxxx.wav'. Either install as Simbol suggests - all in root folder other than Simobjects or possibly the symbolic link.

Just to clairify some things, there are two entirely separate 'sound systems' being used by many third-party aircraft (both freeware and payware).

One is the default sound system that every aircraft uses. Those sound files are contained in the aircraft's ..\sound folder.

The second is a custom sound module that allows the developer to assign unique sound effects to switches, knobs, levers, et cetera via XML scripting compiled into the model itself.  These custom sound modules are identifiable by the fact that a panel.cfg entry is present to load the sound module and specify some additional parameters such as the path to the actual .wav files, and possibly number of sounds. As an example, here is a typical entry using the custom sound module I created:

gauge01=Milviz_Sound!FBGS_XMLSound,  0,0,1,1,SimObjects\\Airplanes\\Beech_Baron_B55 Milviz\\panel\\B55 XML SND#22

Notice that the above entry shows the folder path for the custom sound folder is "relative" to the default ..\SimObjects folder. Obviously then using the preferred P3D method will not work since the path does not exist! Until P3Dv3 this was never a problem for any developer.

One of the methods my original sound module allows is for the use of a CFG file alongside of the sound module where the absolute path may be specified. However this requires that the installer know where the user actually installed the aircraft so the correct .CFG entry can be made.

[Config]
FilePath=C:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\Beech_King_Air_350i Milviz\sound\B350
Sounds=19

Since I had to refactor the code to support 64bits anyway, Doug Dawson and I have now changed the method by which paths are determined such that the custom sound folder is relative to the sound module itself wherever it is installed.  However, this will require all developers who licensed my sound module to update their aircraft and installers to use the new system.

I don't know who's sound module Carenado/Alabeo uses, but they are without doubt faced with the same issue. By the way, this same "relative path" issue arises for any custom modules that a developer uses, so they will have to address this as well. Until such time as this happens though, I recommend to use the "traditional method" of installing in the root SimObjects folder.

[WarpD 824]

1 hour ago, n4gix said:

Until such time as this happens though, I recommend to use the "traditional method" of installing in the root SimObjects folder.

Uh... no.  Absolutely not.  Developers need to fix their flawed approach.