Prepar3D Addon Organizer 1.00 released

[Lorby_SI 2,036]

10 hours ago, tremor595 said:

Hi Lorby,

would it be possible to implement an option to choose where a new addon's xml will be created, so that it must not be in the user/documents folder. I think at the moment that's the only location where your tool places new xml's? And of course if we could choose a destination folder it would be useful if your tool then also would make an package entry in the add-ons.cfg with the desired path.

Reason i ask is because yesterday i reinstalled my A2A aircraft and their new (again) updated V4 installers let you now choose a preferred installation folder anywhere you like and then also the package and path was added to the add-ons.cfg in C:\ProgramData\Lockheed Martin\Prepar3D v4.

For example i installed to E:\Addons\Aircraft\A2A where the corresponding xml also is now.

I then installed my RealAir Legacy the same way, of course manually, with adding an xml directly to the RealAir Legacy folder and adding an package entry to the add-ons.cfg under C:\ProgramData\Lockheed Martin\Prepar3D v4.

I personally would like to have my addons together with their corresponding xml's all in my E:\Addons\Aircraft\... and E:\Addons\scenery\... structure. And therefore an option in your tool would be very handy.

Or are there any drawbacks in doing it this way??

 

Thanks!

 

 

 

 

Hi,

Currently the Addon Organizer uses the "auto-discover" method of P3D, so your addons will be rediscovered in case that you decide to completely uninstall the sim, including its various config files in "Program Data" and "AppData\Roaming". (the add-ons.cfg for that is in "AppData\Roaming"). So the drawback would be, that should you decide to do the full uninstall, or should the one single add-ons.cfg config file in "ProgramData" get screwed up, you have no reference to the addons that don't have their add-on.xml in "\Documents\...".

Giving the user a choice in which add-ons.cfg he wants to place his addon package is possible, but it is a major rework in quite a few areas. For example, should you decide to "hard code" your add-on.xml like you describe, then it cannot be in "\Documents\Prepar3d V4 Add-ons", otherwise the simulator would discover it twice. So the app has to be made aware of where the add-on.xml actually is in relation to the config file that it was added to, including error message windows etc.
I have evaluated this feature a while back, but decided against it. Still, should I have some time on my hands, I will look into it again.

Best regards

[Ray Proudfoot 8,927]

Hi Oliver,

I've updated to v1.01 and also have MakeRwys v4.8.2.0. All my FSDT and FB airports are correctly recognised by Addon Organiser.

When I run MakeRwys it creates MakeRwys_scenery.cfg and this does contain all the FSDT and FB airports. But crucially each of the paths in those entries includes \scenery.

This means external programs such as Electronic Flight Bag won't find those airports unless \scenery is removed from the path.

I know this isn't a Addon Organiser problem but I'm trying to work out the best way of excluding \scenery from each of the 11 entries I have. Can each add-on.xml be edited to remove \scenery or will that mess up their loading in P3D?

I'll also ask Pete Dowson about MakeRwys but he's away for a week so thought I'd start here. I've also posted the question in the sticky topic in the P3D forum.

[sgreen91 182]

Is the updated version working?  The last time I used this P3D would not start it would just CTD.  Had to remove all addons as it kept saying there was no valid scenery.cfg file.  After about 2 hours of removing core files and repairing its working again.

[srcooke 52]

1 hour ago, Ray Proudfoot said:

Hi Oliver,

I've updated to v1.01 and also have MakeRwys v4.8.2.0. All my FSDT and FB airports are correctly recognised by Addon Organiser.

When I run MakeRwys it creates MakeRwys_scenery.cfg and this does contain all the FSDT and FB airports. But crucially each of the paths in those entries includes \scenery.

This means external programs such as Electronic Flight Bag won't find those airports unless \scenery is removed from the path.

I know this isn't a Addon Organiser problem but I'm trying to work out the best way of excluding \scenery from each of the 11 entries I have. Can each add-on.xml be edited to remove \scenery or will that mess up their loading in P3D?

I'll also ask Pete Dowson about MakeRwys but he's away for a week so thought I'd start here. I've also posted the question in the sticky topic in the P3D forum.

There appears to be some change affecting discovery from v0.99 where the FSDT/FB scenery's are discovered.

Installed v1.02 and these scenerys are not listed, reverting to 0.99 ( the last install I have available ) all is ok.

I had already removed the extended /scenery path previously from the FSDT/FB entries

[Lorby_SI 2,036]

4 minutes ago, srcooke said:

There appears to be some change affecting discovery from v0.99 where the FSDT/FB scenery's are discovered.

Installed v1.02 and these scenerys are not listed, reverting to 0.99 ( the last install I have available ) all is ok.

Hello Stephen,

not listed where? What simulator?

I have just installed FSDTs Geneva on P3D V3, and I can't detect any issues anywhere with the addon organizer (on 1.02).

- The scenery is visible in the main list
- When exporting the scenery library, this entry doesn't have the \Scenery part.

Right this moment I can't reproduce any of the issues - ??

Best regards

[Ray Proudfoot 8,927]

11 minutes ago, srcooke said:

There appears to be some change affecting discovery from v0.99 where the FSDT/FB scenery's are discovered.

Installed v1.02 and these scenerys are not listed, reverting to 0.99 ( the last install I have available ) all is ok.

I had already removed the extended /scenery path previously from the FSDT/FB entries

Hi Stephen,

No problems here with 1.02 and my FSDT and FB airports. All correctly identified and included in the exported scenery.cfg although it does contain the \scenery element.

What version of P3D are you running? v3.4 here.

[srcooke 52]

My mistake Oliver in not running Makerwys twice after updating AddonManager to v1.02

Even with the additional \scenery path v1.02 with makerwys v4.82 produces the correct output.

[Lorby_SI 2,036]

1 hour ago, sgreen91 said:

Is the updated version working?  The last time I used this P3D would not start it would just CTD.  Had to remove all addons as it kept saying there was no valid scenery.cfg file.  After about 2 hours of removing core files and repairing its working again.

Why didn't you contact me?

Even if you forgot to run the backup process, P4AO automatically makes a backup copy of your original scenery.cfg (and all the other files that it touches) right next to it. So if anything goes wrong, you just delete the broken scenery.cfg and revert back to the original by renaming the "scenery.cfg.orig" back to "scenery.cfg".

Best regards

[tremor595 20]

6 hours ago, Lorby_SI said:

Hi,

Currently the Addon Organizer uses the "auto-discover" method of P3D, so your addons will be rediscovered in case that you decide to completely uninstall the sim, including its various config files in "Program Data" and "AppData\Roaming". (the add-ons.cfg for that is in "AppData\Roaming"). So the drawback would be, that should you decide to do the full uninstall, or should the one single add-ons.cfg config file in "ProgramData" get screwed up, you have no reference to the addons that don't have their add-on.xml in "\Documents\...".

Giving the user a choice in which add-ons.cfg he wants to place his addon package is possible, but it is a major rework in quite a few areas. For example, should you decide to "hard code" your add-on.xml like you describe, then it cannot be in "\Documents\Prepar3d V4 Add-ons", otherwise the simulator would discover it twice. So the app has to be made aware of where the add-on.xml actually is in relation to the config file that it was added to, including error message windows etc.
I have evaluated this feature a while back, but decided against it. Still, should I have some time on my hands, I will look into it again.

Best regards

Thanks for detailed explanation!

So if I sort things the "hard code" way I should regularly backup the add-ons.cfg from ProgramData so I can copy it back after a P3D reinstall and I'll have everything in place again.

I will think about both options again but it seems the hard code way offers less restricted folder order or xml placement.

 

[Ray Proudfoot 8,927]

Oliver,

I've sent you a PM. I have a problem with v1.03 of Addon Organiser.

[Lorby_SI 2,036]

Hello Ray,

right, that was my mistake. I somehow thought that I had "normalized" all those paths - turns out that I didn't.

Version 1.04 is online now.

Best regards

[Ray Proudfoot 8,927]

Thanks Oliver. I'll download tomorrow and check it out.

[Boeing or not going 578]

Lockheed Martin documented a standard for encoding: xml files have UTF-8 encoding. The addon organizer uses UTF-8-BOM

[Lorby_SI 2,036]

7 hours ago, 777200lrf said:

Lockheed Martin documented a standard for encoding: xml files have UTF-8 encoding. 

Hi,

actually, no, they didn't. The written (=documented) specification says nothing of that kind: "Learning Center -> SDK -> Add-ons -> Add-on Packages". In fact, the way that they describe the add-on.xml, it must be ASCII, because it is missing the Text Declaration ("<?xml....Encoding=..."). Their own XML files don't have a uniform encoding, there are all kinds, UTF-8 with and without BOM, CP1252.

What an XML file is, and what it looks like, is specified by the W3C:

http://www.w3.org/TR/REC-xml/

Quote

4.3.3 Character Encoding in Entities

Each external parsed entity in an XML document may use a different encoding for its characters. All XML processors MUST be able to read entities in both the UTF-8 and UTF-16 encodings.

Quote

Entities encoded in UTF-16 MUST and entities encoded in UTF-8 MAY begin with the Byte Order Mark described by Annex H of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding signature, not part of either the markup or the character data of the XML document. XML processors MUST be able to use this character to differentiate between UTF-8 and UTF-16 encoded documents.

For safety reasons, I decided to use the standard UTF-8 spec, which includes the Byte Order Mark (BOM) at the beginning. Done this way, no parser, be it P3D or an editor, has to try and figure out the encoding, because the BOM makes it plain.

Best regards

[steve40 7]

Hi Oliver,

May I make a small suggestion. Could you please swap the Cancel and Submit buttons on the Add Scenery and Add Component pages so that the Submit button is on the left? I find it more intuitive that way because most programs usually have the cancel buttons to the right of the OK/Save buttons. Also, it would be consistent with the main screen, where you have the Save button on the left and the Close button on the right. Cheers.