I'm really pleased I posted this now.  I thought I was the only one and didn't understand offensive initials not allowed was going on.

Seems I'm not the only one that doesn't understand, nor the only one thats frustrated with developers;-)

Puts us mere mortals (users) in a REALLY difficult position....  LM says 'this is how you must do it', yet 99% of developers don't actually allow us to do as LM advises:-(

So when things go wrong, and error messages start to appear, thats a complete no win situation for the end user!

In my opinion, LM did something basically wrong here. Having two competiting addon installation methods can only lead to trouble. They should have either left things as they were before (scenery.cfg) or completely switched to the new method (add-on.xml) requiring all add-on maker to mantadory follow that method (and, preferred, provided them conversion tools within the SDK).

Kind regards, Michael

13 minutes ago, pmb said:

(and, preferred, provided them conversion tools within the SDK

Hello Michael,

Check this out: Learning Center -> SDK -> Add-ons -> Add-on Instructions for Deveolopers and -> Add-on Configuration Files

Quote

This document describes the Prepar3D preferred method for development and installation of add-on material.

Quote

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

Quote

User Account Control (UAC) restricts access to the Program Files folder and to program install locations. Ideally, Prepar3D's base installation folder and the files contained in that folder, should never be modified. If additional content is installed in Prepar3D's installation folder, or if files in Prepar3D's installation folder are modified, the additional content/changes could be deleted or corrupted during Prepar3D upgrades and reinstalls.

Quote

Although the recommended way of distributing add-on components is by creating an Add-on Package which is automatically discovered, it is possible to manage the installation of each add-on components via command line switch arguments to the installed Prepar3D executable. Developers can use this feature to add, remove, activate, or deactivate components of add-on content.

All of this has been in place since P3D V3.0. It has just been ignored by all developers except RealAir for 2.5 years.

Best regards

1 hour ago, Jim Young said:

I have not even atttempted to use the add-on.xml method for installing aircraft and so far no developer has used it.

Just adding a little info.

As Lorby said, Aerosoft is currently doing this with the A318/A319 Beta, and Leonardo is doing this with the Maddog Beta. Both work great.

 

40 minutes ago, Lorby_SI said:

Hello Michael,

Check this out: Learning Center -> SDK -> Add-ons -> Add-on Instructions for Deveolopers and -> Add-on Configuration Files

All of this has been in place since P3D V3.0. It has just been ignored by all developers except RealAir for 2.5 years.

Best regards

Then it would have been consequent to just block the old method. No one will make such changes without a need. I suppose addon makers would have cried out loudly about no longer supporting Prepar3d, but in the end they would have given in. 

I think I understand the advantages of the new method, but parallel usage of both is a pain for all parties.

Kind regards, Michael

@DaveCT2003 - Well, I'm happy to hear some developers are using the SDK.  I make a huge error by stating "so far no developer has used it".  Should have, "to my knowledge, no developer has used it". 

Does ORBX installation place files anywhere OTHER the ORBX folder?

I'm thinking maybe the '\\\Scenery\World\scenery' folder ?

Global and the HD Trees overwrite textures.

Kind regardes, Michael

20 minutes ago, Dougal said:

Does ORBX installation place files anywhere OTHER the ORBX folder?

I'm thinking maybe the '\\\Scenery\World\scenery' folder ?

FTX elevation adjustments are in there.

I think that terrain.cfg is altered too, as are the Autogen definition xmls.

Best regards

1 hour ago, DaveCT2003 said:

Aerosoft is currently doing this with the A318/A319 Beta, and Leonardo is doing this with the Maddog Beta. Both work great.

 

... and FSLabs has done that with their A320-X for P3D v4, works fine as well.

With some exceptions, it appears that most developers are spending a lot of their time jumping on the X-plain money wagon and that company DTG who are using up resources trying to suck the last nickle off the floor or FSX. If you look at the last 3 or 4 months of AVSIM as well as other Sim sites it is all about X-plain and FSW. If you are a GA guy and Prepar3d V4 then pretty much left out in the cold at this point. I think our questions and confusion at this point can be answered by following the methods used by our police detectives. You just follow the money and the answers appear.

Well as a developer I did use the .xml method after reading the SDK for weeks.

Unfortunately some users decided it was a good idea to override my instalation software (which uses the .Xml method) and revert back to copying stuff inside the Sim.

So as I said before this goes both ways! We developers are not the only ones responsible of this new technology being successful.

If a developer implements it then let it be!, don't overwrite default P3D files please!

Regards 

Simbol 

Personally, I prefer the Scenery Library method.  I have to move priorities around a lot so until a version of the XML method allows that in the Scenery Library I will stick to what works best for me.  Yea, it means I have to tinker with FSDT, FlightBeam, etc. to work in the Library so be it.  I just wish developers would offer an option for the simmer as to which method they would like to install with. 

1 hour ago, pmb said:

Then it would have been consequent to just block the old method

Personally I think that this "block" can never work. There is no failsafe against a developer or user just overwriting files. And the sim itself depends upon the logic that it reads whatever files it finds. It would be an insane effort to change that logic now to make the sim look only for "good" files, for example by keeping a database of every single file that has ever been installed and ignoring the rest. 

Where your point has merit is where scenery is concerned. But the "XML method" is not (only) about scenery, it covers every type of addon content. LM probably could have gotten rid of the scenery.cfg, but they decided not to. They wrote the spec - and if developers ignore it, then this constitutes a tweak, plain and simple. The platform producer doesn't have to cover every angle so users and devs can't manipulate the product. The days where that was possible are long gone, products are too complex today. Besides - many people like the tweaking aspect. So you can go outside of the box and do some really cool stuff, that wouldn't be possible on a closed platform.

Best regards

40 minutes ago, simbol said:

Well as a developer I did use the .xml method after reading the SDK for weeks.

Unfortunately some users decided it was a good idea to override my instalation software (which uses the .Xml method) and revert back to copying stuff inside the Sim.

So as I said before this goes both ways! We developers are not the only ones responsible of this new technology being successful.

If a developer implements it then let it be!, don't overwrite default P3D files please!

Regards 

Simbol 

Couldn't agree more!