Addon Organizer no autodiscovery

[Akila 39]

i have noticed the tool doesn't find/discover/display any scenery (add-on.xml) that was placed under '%USERPROFILE%\Documents\Prepar3d v4 Files\add-ons' or '%USERPROFILE%\Documents\Prepar3D v4 Add-ons'

based on the LM documentation (Add-on Instructions for Developers / Creating an Add-on Package) the SIM should autodiscover those that were placed under that path (Prepar3D's default add-on discovery folder) . e.g. FSDG P3Dv4 installation take use of it and place the addon xml under "%USERPROFILE%\Documents\Prepar3D v4 Add-ons\FSDG-xxxxx-xxxxx" leveraging the autodiscover feature, even though the data files themselves are located at a custom/different directory/drive, without the need to add the XML reference in the addon CFG file. but the tool doesn't pick it up or leverage this autodiscover, hence it doesn't show you the full picture in the UI of the addons you have installed and are valid activated in Prepar3d 4, unless it was added to the add-on.cfg file, which doesn't reflect the reality (like the example above).

the funny thing is, if i create/add new scenery using the tool, it will add/create the XML file correctly under the %USERPROFILE%\Documents\Prepar3D v4 Add-ons, but it doesn't know to search for existing ones.

also what about if I add another discovery folder in addon CFG file, I don't think the tool will pick that up either.

 

Another thing i had noticed is (not related to the above issue): that is the files/folders that the add-on.xml points to do not exist,
the tool doesn't show any error or any different indication on that line in the scenery, but shows that everything is OK.

[Lorby_SI 2,038]

Hello Joel,

1.a The tool does not discover anything and it is not searching for scenery anywhere. It only reads the config files for scenery that the simulator itself discovered and can see. Everything else (=stuff that the simulator itself ignores) is irrelevant. If you install new content with an installer program, you have to run the simulator at least once, otherwise the tool cannot see it. Simulator autodiscovery only works in the \Documents\Prepar3d V4 Add-Ons folder, nowhere else.

1.b there are two files called add-ons.cfg. One in AppData\Roaming and the second one in PorgramData. First one contains autodiscovery, second one the fixed installation. These two, plus the scenery.cfg, are all the "picture" there is too see

2. P4AO does not check for any errors apart from file encoding. That is the simulators job - it has the content error log feature for this purpose.

3. This tool has been available for 8 months and has received almost 20 updates based on user feedback. I am reasonably sure that it works correctly.

Best regards

[Akila 39]

thank you for your reply, so my question is as follows.

if I install a scenery (e.g. FSDG) and i saw it added an add-on.xml to the following folder "%USERPROFILE%\Documents\Prepar3D v4 Add-ons\FSDG-xxxxx-xxxxx"
(the add-on.xml points to the right folders where the data is of course)
in theory that should be enough for the SIM to pick it up, but when i launch the tool it doesn't see this new installed scenery. the reason for that
as you explained is, that i need to run the SIM at least once before the tool would be able and see the new installed scenery.

so my question is: what happens (what files are added/changed, etc) when i run teh SIM, that then the tool can display the new installed scenery that
it could display it before i ran the SIM? 

[Lorby_SI 2,038]

Just now, Akila said:

so my question is: what happens (what files are added/changed, etc) when i run teh SIM, that then the tool can display the new installed scenery that
it could display it before i ran the SIM? 

The sim creates an entry in \AppData\Roaming\Lockheed Martin\Prepard3d v4\add-ons.cfg.

All autodiscovered content is in there, the sim updates this file every time it is run.

Best regards

[Akila 39]

14 minutes ago, Lorby_SI said:

The sim creates an entry in \AppData\Roaming\Lockheed Martin\Prepard3d v4\add-ons.cfg.

All autodiscovered content is in there, the sim updates this file every time it is run.

Best regards

1. in other words you trying to say that the tool only reads  \AppData\Roaming\Lockheed Martin\Prepard3d v4\add-ons.cfg (and its links / top reference / starting point) for it's list of sceneries added in XML method (none scenery.cfg based)?

2. it is interesting what you saying about the SIM updating the addon CFG file when i run the SIM for the 1st time after i install a scenery.
so in theory, if i run the SIM and it updates the add-ons.cfg, I no longer need the add-on.xml file at "%USERPROFILE%\Documents\Prepar3D v4 Add-ons\FSDG-xxxxx-xxxxx"
and i can delete it? as the add-on.cfg was updated already?
or the next time I will run the SIM it would be removed from the add-on.cfg because the XML is no longer there?

the update process from add-on.XML to add-on.CFG , is it only like Add/append thing, or it's a Sync (add/remove) thing?

[Lorby_SI 2,038]

8 minutes ago, Akila said:

1. in other words you trying to say that the tool only reads  \AppData\Roaming\Lockheed Martin\Prepard3d v4\add-ons.cfg (and its links / top reference / starting point) for it's list of sceneries added in XML method (none scenery.cfg based)?

2. it is interesting what you saying about the updates the addon CFG file when i run the SIM for the 1st time after i install a scenery.
so in theory, if i run the SIM and it updates the add-ons.cfg, I no longer need the add-on.xml file at "%USERPROFILE%\Documents\Prepar3D v4 Add-ons\FSDG-xxxxx-xxxxx"
and i can delete it? as the add-on.cfg was updated already?

No and no.

1. The P4AO tool processes this file, and the one in ProgramData, all the xml files that are referenced by the two, and the scenery.cfg.

2. The two add-ons.cfg files only tell the sim where all the xml files are. The xmls carry the relevant information, not the cfg.

Best regards

[Akila 39]

got ya.. thanks for clearing it out :))

[howevr 39]

Oliver,

I recently installed my 2 RealAir products using the latest RealAir P3D4 installers provided by Sean. I made an error in my chosen custom install location, so when the install was completed I manually moved the files to the correct folder. The add-on.xml file was within this folder. I then went searching for where RealAir had put it's entry in P3D4 on where to find the xml file. I used your Organiser thinking it would show me the entry but I was mistaken. I discovered the entry in C:\ProgramData\Lockheed Martin\Prepar3D v4\simobjects.cfg. I guess this location is used for addons installed in a custom folder and tell P3D4 where to find that addons xml file.

Is there a reason the Organiser does not check simobjects.cfg and pick up addons like RealAir.
If it helps this is how the entries looked in simobjects. I just edited the PATH.

[Entry.0]
PATH=P:\P3D4-Aircraft\RealAir\Legacy V2\SimObjects\Airplanes
TITLE=RealAir Legacy V2
ACTIVE=true
REQUIRED=false
[Entry.1]
PATH=P:\P3D4-Aircraft\RealAir\Turbine Duke V2\SimObjects\Airplanes
TITLE=RealAir Turbine Duke V2
ACTIVE=true
REQUIRED=false

TIA

Cheers

[Lorby_SI 2,038]

1 hour ago, howevr said:

I discovered the entry in C:\ProgramData\Lockheed Martin\Prepar3D v4\simobjects.cfg. I guess this location is used for addons installed in a custom folder and tell P3D4 where to find that addons xml file.

Is there a reason the Organiser does not check simobjects.cfg and pick up addons like RealAir.

Hello David,

the reason is, that the P4AO only cares about XML type addons. Entries in other .cfg files are not in the focus of this app. Generally speaking, they shouldn't even exist when there is an add-on.xml. The real issue here is, that these particular simobjects.cfg entries duplicate an XML entry - which is not correct. UT live does the same thing. It is completely superfluous, if you have an XML in place referencing the SimObjects, there is no need to put another reference into the SimObjects.cfg.

The P4AO tool was made to help you with the preferred method of installing addons. It is not one of those "swiss army knife" tools that try to control every aspect of the sim. Going there with a freeware app is not really attractive.

I will think about this particular issue for a while, see if I can cover it somehow. It would imply adding a dialog just like the one for the sceneries, but focused on SimObjects - and another one for textures, sounds, effects, shaders, etc. etc.. Making this generic is probably an effort of about 40 hours. But I really don't want to write a tool that predominantly corrects issues that other developers introduce - I would never see the end of it.

Best regards

[Lorby_SI 2,038]

1 hour ago, howevr said:

I discovered the entry in C:\ProgramData\Lockheed Martin\Prepar3D v4\simobjects.cfg. I guess this location is used for addons installed in a custom folder and tell P3D4 where to find that addons xml file.

No. This is a direct reference to a SimObjects folder, it has nothing to do with add-on.xml files.

This means, that with this entry the simulator will only find the aircraft model itself. Effects, Gauges etc are not referenced by this. They would have to be added to the effects.cfg and gauges.cfg respectively.

Best regards

[howevr 39]

29 minutes ago, Lorby_SI said:

the reason is, that the P4AO only cares about XML type addons. Entries in other .cfg files are not in the focus of this app. Generally speaking, they shouldn't even exist when there is an add-on.xml. The real issue here is, that these particular simobjects.cfg entries duplicate an XML entry - which is not correct. UT live does the same thing. It is completely superfluous, if you have an XML in place referencing the SimObjects, there is no need to put another reference into the SimObjects.cfg.

Thank you Oliver.

Your comment above and additional post made it clear what was going on and I now understand what is happening with these superfluous entries, thank you.

Cheers,

[Lorby_SI 2,038]

1 hour ago, howevr said:

Thank you Oliver.

Your comment above and additional post made it clear what was going on and I now understand what is happening with these superfluous entries, thank you.

Cheers,

Hello David,

I made a new version real quick, that will show the .cfg entries on the "Other Addons" tab too. But you can't do anything with them except "Activate/Deactivate". If there is a conflict with an add-on.xml, the cfg entry will turn orange so you can find and disable it.

1.28 b01 is available for download on the Lorby-SI website

Note: this handles only the entries from .cfg files. DLL/EXE programmatic addons will be added later.

Best regards

 

[Akila 39]

5 hours ago, Lorby_SI said:

 

I will think about this particular issue for a while, see if I can cover it somehow. It would imply adding a dialog just like the one for the sceneries, but focused on SimObjects - and another one for textures, sounds, effects, shaders, etc. etc.. Making this generic is probably an effort of about 40 hours. But I really don't want to write a tool that predominantly corrects issues that other developers introduce - I would never see the end of it.

Best regards

i would love to have such tool and even willing to pay for such (payware).

15 hours ago, Lorby_SI said:

No and no.

1. The P4AO tool processes this file, and the one in ProgramData, all the xml files that are referenced by the two, and the scenery.cfg.

2. The two add-ons.cfg files only tell the sim where all the xml files are. The xmls carry the relevant information, not the cfg.

Best regards

do you know why there are two add-on.cfg files, one in APPDATA and the other  in programData? what is the logic/idea behind it, having two?
isn't one supposed to be sufficient? 
What are the use cases of each add-on.cfg (APPDATA v.s programData)? when a developer would pick one upon the other, APPdata vs programData (use case)?

 

 

[Lorby_SI 2,038]

33 minutes ago, Akila said:

i would love to have such tool and even willing to pay for such (payware).

do you know why there are two add-on.cfg files, one in APPDATA and the other  in programData? what is the logic/idea behind it, having two?
isn't one supposed to be sufficient? 
What are the use cases of each add-on.cfg (APPDATA v.s programData)? when a developer would pick one upon the other, APPdata vs programData (use case)?

 

 

There are two add-ons.cfg files because these are two different use cases = two different program modules. One file is constantly re-written by a process that is doing the autodiscovery, the other is static, it is only updated when a developer/installer uses the P3D command line tools to install an addon. If there was only one file, LM would have to add a parameter so the parser can see which entry was discovered automatically and which entry has been added by an installer. This operation would be really unsafe, prone to failure, especially when you think about people making manual entries. Think of the lookup logic of the simulator like a multi-stage process. The first module makes autodiscovery, writes the results to the add-ons.cfg. The next module reads all cfg files (not only the add-ons.cfgs), extracts the path information and adds all paths to a long list of lookup paths for content. The next module uses this list to scan for content files (textures, BGLs, aircraft.cfg etc) and makes pools or lookup tables for them, etc. etc. until a structure emerges where the simulator can find a specific content file in the least amount of time. Each of these modules can be developed by a different person, in parallel even, making for shorter development cycles. Etc. Software architecture is a science all in itself.

AppData in general contains the configuration files that are specific for the Windows user that is currently signed in, whereas ProgramData is global. So I would put everything that could be different for every user account into AppData, while all configurations that always have to be there for the application and are not user specific, would be put into program data. This is just how the Windows specification says to handle it, no magic tricks. if P3D would be used correctly, then every user account of the same PC could have a totally different simulator setup, while still using only one installation. 

Best regards

[Akila 39]

so if i add manually (additional entry) a reference to an XML (add-on.xml is located outside the default P3D autodiscover folder, e.g. "d:\P3D_Addons\xxx") in the add-on.cfg at APPDATA, is there a risk of it being deleted/removed by the autodiscover process?