P3D v4 Add-on Autogen Bug in P3D 4.4 and 4.5 + Workaround

[Jeff Pollard]

Long post alert. [TL;DR: The Autogen add-on system seems to be busted in P3D 4.4 and 4.5. I think the issue is related to the fallback mechanisms. There is a work-around using the Autogen Configuration Merger tool (see post #4 below).]

I recently noticed that my autogen-based lights were not displaying at all in P3Dv4. I googled the issue and found several posts, on this forum and elsewhere, from other people seeing a similar problem. Instructions on how to properly integrate add-on autogen definition files are woefully lacking in the SDK, so I have been testing and troubleshooting the issue.

Although multiple concurrent add-on autogen folders can be configured, via at least 2 different integration methods, it would seem that P3D will only pick up a single add-on autogen folder, namely whichever one has the highest order of priority. All other add-on autogen is ignored. My tests indicate that this behaviour is the same in P3D 4.4 and 4.5. The question is, whether this limitation to a single add-on autogen folder is by design or, as I suspect, due to a bug in the P3D fallback prioritisation mechanism.

In order to fully explain what I think is happening, it is important to first clear up a few points relating to:

• The file and folder constraints for add-on autogen definition files.
• The 2 different methods available to integrate those add-on autogen files into P3D.
• How the 2 different integration methods work in combination with each other.
• The resulting prioritisation governing add-on autogen files within P3D.

Autogen file and folder constraints:

• Regardless of the integration method used, P3D expects the provision of an add-on autogen folder containing autogen files with standardised file names (i.e. "default.xml", "AutogenDescriptions.xml", etc). P3D will ignore autogen files with custom names (e.g. "MyDefault.xml", "MyAutogenDescriptions.xml").
• The add-on folder containing the add-on autogen files can have any name you like, it doesn't need to be named 'Autogen'. (For example, Orbx put theirs in "...\Orbx\p3dv4\Orbx Libraries\ORBX\Scripts\custom.gb_base").
• P3D expects the add-on autogen files to be additive, i.e. they should only include autogen definitions for new autogen classes, or for default P3D autogen classes that are intended to be redefined. There is no need for these files to contain any of the existing default P3D autogen definitions if they are not intended to be overridden.

Integration Method 1: Add-on.xml package:

• An Add-on.xml package including an Add-on Component with 'Category' set to 'Autogen', and 'Path' set to a folder which contains autogen definition files as described above.
• The path can be either absolute, or relative to the add-on.xml file location.
• The path must be to a folder, NOT a specific autogen xml file.
• The package can then be installed in 1 of 3 ways, corresponding to the location of the respective add-on.cfg file, Local, Roaming, or ProgramData (default):
  • Local:
    • Install the add-on package by running the appropriate P3D configuration command, e.g.:
      • Prepar3D.exe "-Configure: Category=Add-on Package, Operation=Add, Title=REVX_LIGHTS, FileLocation=Local, Path=C:\MyAddons\REVX_LIGHTS"
    • This will result in a corresponding add-on package entry in the 'Local' add-on.cfg file located at "...\Users\[username]\AppData\Local\Lockheed Martin\Prepar3D v4\add-ons.cfg".
  • Roaming:
    • Install the add-on package by either placing the add-on.xml file in a folder monitored by P3D for auto-discovery, or by running the appropriate P3D configuration command, e.g.:
      • Prepar3D.exe "-Configure: Category=Add-on Package, Operation=Add, Title=REVX_LIGHTS, FileLocation=Roaming, Path=C:\MyAddons\REVX_LIGHTS"
    • This will result in a corresponding add-on package entry in the 'Roaming' add-on.cfg file located at "...\Users\[username]\AppData\Roaming\Lockheed Martin\Prepar3D v4\add-ons.cfg".
  • ProgramData (Default):
    • Install the add-on package with either an add-on manager (e.g. Lorby-Si P4AO), or by running the appropriate P3D configuration command, e.g.:
      • Prepar3D.exe "-Configure: Category=Add-on Package, Operation=Add, Title=REVX_LIGHTS, Path=C:\MyAddons\REVX_LIGHTS"
    • This will result in a corresponding add-on package entry in the 'ProgramData' add-on.cfg located at "...\ProgramData\Lockheed Martin\Prepar3D v4\add-ons.cfg".
• The overall priority of the Autogen add-on component is governed by 2 factors:
  • 1: The location of the add-on.cfg file in which it is installed:
    • An add-on component defined in the Local add-on.cfg file will always have a higher priority than those defined in in the Roaming add-on.cfg file.
    • An add-on component defined in the Roaming add-on.cfg file will always have a higher priority than those defined in in the ProgramData (Default) add-on.cfg file.
  • 2: The corresponding package level within each add-on.cfg file:
    • [Package.0] has a higher priority than [Package.1], and so on.
  • Note: the scenery layer prioritisation system is separate and has no bearing the prioritisation of other category add-ons (including autogen).

Integration Method 2: autogen.cfg entry:

• An autogen.cfg entry can be created by running the appropriate configuration command, e.g.:
  • Prepar3D.exe "-Configure: Category=autogen, Operation=Add, Title=REVX_LIGHTS, Path=C:\MyAddons\REVX_LIGHTS\Autogen"
• The path must be set to a folder containing autogen definition files as described as above.
• The path must be to a folder, NOT a specific autogen xml file.
• The path must be absolute.
• This will result in a corresponding autogen entry in the autogen.cfg file located at "...\ProgramData\Lockheed Martin\Prepar3D v4\autogen.cfg".
• The overall autogen priority is governed by the corresponding Entry level in this file, e.g. [Entry.0] has a higher priority than [Entry.1].

Findings:

• An autogen folder added via an add-on.xml package does not need a corresponding autogen.cfg entry.
• An autogen folder added via a autogen.cfg entry does not need a corresponding add-on.xml package.
• If both integration methods are used concurrently to reference the same add-on autogen folder, then the priority derived from the add-on.xml package reference will override the priority derived from the autogen.cfg reference.
• Only 1 single add-on autogen folder will be picked up by P3D, namely whichever one has the highest overall level of priority as described above. All other add-on autogen folders will be ignored.
• Arno's Autogen Configuration Merger tool does not rectify this issue, as the ACM log indicates that the tool currently skips over add-on.xml Autogen folders, based on the assumption that P3D is already merging them correctly, which it isn't.

Temporary Workaround:

• Update: see post #4 below.

@arno: if my findings above can be reproduced by others, do you think it would be possible to make the ACM tool merge all add-on.xml-based Autogen components, rather than skip them?

@Everyone: perhaps someone with LM's ear could escalate the fallback prioritisation issue? (Although I suspect they already know about it, and that this is the same "fallback issue" that is preventing Orbx from setting up their Orbx Central v4 installer to fully utilise the addon.xml method, rather than continuing to bulldoze P3D's default files).

Cheers,
Jeff

 

[RicherSims]

That is indeed a bit of a kludge. (And I cannot expect my customers to follow those instructions! )

I noticed that some of my customers were reporting that no autogen showed up in 4,4+. I have always used P3D's auto discovery method by just dropping an add-on.xml in the users My Documents\Prepar3D v4 Add-ons folder. But whether it worked or not seemed to be totally random and I was unable to reproduce it if it didn't work. And as you said above, not even ACM helped.

I recently released some new products and I had assumed that there were compatibility issues between mine and some well known and widely used products that make changes to autogen "Global"ly.
This actually makes a lot more sense and I will try to investigate and reproduce later.

 

[Jeff Pollard]

That is indeed a bit of a kludge. (And I cannot expect my customers to follow those instructions! )

No of course, I realise my workaround is no good from a product development point of view, it was just a temporary way for me to get my lights back really.

If my findings are correct, then the only real solution is for LM to fix it. In the meantime, hopefully Arno can modify the behaviour of the ACM tool so that it also merges add-on.xml based Autogen into the default xml file.

Cheers
Jeff

 

[Jeff Pollard]

Update: There is a much easier work-around.

The latest ACM beta will pick up and merge custom default.xml files for add-on.xml based packages too, as long as all 4 of the following conditions are true:

• The add-on.xml file is referenced in the ProgramData variant of the add-on.cfg file (ACM does not currently seem to read the Local or Roaming variants of the add-on.cfg files).
• The add-on.xml file does not have its own 'Autogen' category component, or its 'Autogen' category component is disabled.
• The add-on.xml file has a 'Scenery' category component.
• The add-on's default.xml file is located in a sub-folder named 'Autogen' which is located in the same folder as the 'Scenery' sub-folder.

For example:

ACM will not pick up and merge a custom default.xml file from the following add-on folder structure:

C:\MyAddons\Addon1\Autogen\default.xml
C:\MyAddons\Addon1\Airport\Scenery\
C:\MyAddons\Addon1\Airport\Texture\

ACM will pick up and merge a custom default.xml file from the following add-on folder structure:

C:\MyAddons\Addon2\Airport\Autogen\default.xml <- Note the location. Any add-on components explicitly referencing this folder must be disabled.
C:\MyAddons\Addon2\Airport\Scenery\
C:\MyAddons\Addon2\Airport\Texture\

Hopefully Arno can update ACM so that it picks up and merges default.xml files in either of the above scenarios, but in the meantime product developers only need to patch their add-on.xml files so as to remove or disable any Autogen category components, and ensure that their default.xml file is located in a sub-folder named and located as described above.

Cheers
Jeff

 

[arno]

Hi Jeff,

If we are sure that the merging by P3D is broken I can of course modify ACM. In the latest build I have excluded the autogen entries that are in the add-on.xml to prevent double merges.

 

[Jeff Pollard]

If we are sure that the merging by P3D is broken I can of course modify ACM.

Thanks Arno.

Hi All.
I've created a small set of files to make sure this autogen bug is reproducible on all P3Dv4 systems. If anyone would be good enough to test this and provide confirmation / feedback here, that would be great. If you use Lorby-SI P4AO, it should only take a moment or two, and all changes are reversible.

Step 1: Temporarily disable any existing add-on Autogen components:

For this test, please first disable all other Autogen components (if any) from other add-ons, so as to rule out any interference. To do this in Lorby-Si P4AO:

• Go to the 'Other Addons' tab.
• Expand each Add-on.
• Temporarily disable any components with 'Category'='Autogen' by double-clicking on them (Note: disabled components can be re-enabled by simply double-clicking, once the test is complete).
• On the Packages tab, disabled components should now appear in red:

• Close Lorby-SI P4AO

Step 2: Unzip and add the test scenery folders:

In the zip file attached to this post (P3Dv4_AGN_Bug_Test.zip) are 4 folders:

• 'AGN_Test_Blue' contains:
  • An add-on.xml with an Autogen component for some blue lights.
  • A default.xml stub with the autogen definitions for some blue lights.
• 'AGN_Test_Green' contains:
  • An add-on.xml with an Autogen component for some green lights.
  • A default.xml stub with the autogen definitions for some green lights.
• 'AGN_Test_Red' contains:
  • An add-on.xml with an Autogen component for some red lights.
  • A default.xml stub with the autogen definitions for some red lights.
• 'AGN_Test_Scenery' contains:
  • An add-on.xml with:
    • A standard Scenery component with some AGN scenery tiles.
    • A global Scenery component with some BGL light library objects.

Unzip all 4 folders into the root of the Documents\Prepar3D v4 Add-ons folder:

Open Lorby-SI P4AO, and it should automatically detect the newly added add-on.xml packages.

On the Scenery tab, ensure that the 2 new AGN_Test scenery entries are at the top of the list, to ensure that any other scenery layers do not obscure them in the sim.

Step 3: Test the newly added autogen in P3D:

The test scenery comprises 3 autogen AGN tiles. 1 tile has red autogen lights, 1 tile has green autogen lights, and 1 tile has blue autogen lights.

The tiles are located right next to each other in the sim, just south of Geneva airport (LSGG):

Each of the 3 light colours has its own Autogen add-on component, each with its own default.xml file.

Expected behaviour: the sim should merge all 3 of the default.xml files from all 3 of the add-on Autogen components at run time, in which case all 3 sets of autogen lights should be visible at the same time:

Launch the sim, set the Airport to LSGG, and set Time Of Day to night. You should now see some autogen lights immediately to the right of the airport.

PASS: All 3 light colours are visible at the same time.
FAIL: Only 1 light colour is visible at a time.

My findings indicate that there is a bug which results in only the default.xml definitions from the Autogen component with the highest Package Order Priority being picked up and displayed in the sim.

Step 4: Change the Package Order Priority and then repeat the test:

You can confirm this behaviour by modifying the Package Order Priority of each light colour in turn, and seeing the effect in the sim.

Changes to the Package Order Priority can be made easily in Lorby-SI P4AO, on the Packages tab, by selecting a Package and clicking the Up and Down buttons.

My findings indicate that:

• If the AGN_Test_Red package is set to be highest in the list, then only the red lights will be displayed in the sim.
• If the AGN_Test_Green package is set to be highest in the list, then only the green lights will be displayed in the sim.
• If the AGN_Test_Blue package is set to be highest in the list, then only the blue lights will be displayed in the sim.

However, if the default.xml files from each add-on.xml are merged using the ACM workaround as described in my earlier post, then all 3 light colours are visible at the same time, as expected.

To reverse all changes from this test, in Lorby-SI P4AO:

• Delete all 4 AGN_Test packages from the Packages tab.
• Re-enable any of the existing package components disabled in Step 1.

Please take a moment to test these files in your sim, and confirm your results here.

Many thanks
Jeff

P.S. The above test should at least confirm the existence of a reproducible bug. Further troubleshooting indicates that the effect of this bug also depends on the order in which library objects are listed within AGN files, with only the first listed GUID being picked up by the sim, and only if this same GUID is defined in an add-on default.xml with the highest package order priority. I will detail my findings in a later post, in the hope that it may speed up the resolution of this bug.

 

[arno]

Hi Jeff,

Thanks for the detailed test, I'll try to run it here somewhere the coming days.

 

[Jeff Pollard]

One final observation: there are actually 2 parts to this bug.

The first part of the bug, as described in my earlier posts above, relates to package order priority. This part of the bug will affect any P3Dv4 users who have more than 1 add-on.xml based add-on with an Autogen component, which is presumably a fairly common scenario.

The second part of the bug relates to the order in which AGNLibraryObject GUIDs are listed within AGN tiles. It only applies if the AGNLibraryObject from 1 AGN tile are defined in more than 1 default.xml file. This is not a common scenario, so I'm only explaining it here in the hope that this info may shed some light on the root cause of the bug, or may help anyone who is trying to mitigate it.

This second part of the bug is pretty tricky to explain, so first here's a quick clarification of some terminology:

• Add-on AGN tile:
  • An autogen scenery file containing autogen object GUIDs and their geographical coordinates, listed in a particular order.
• Add-on default.xml file:
  • An additional external default.xml file, which defines those autogen object GUIDs.
• Add-on autogen component:
  • An 'Autogen' add-on component within an add-on.xml file, which specifies the path to that additional external default.xml file.
• Add-on package order priority:
  • The priority given to that add-on.xml file, across all 3 add-on.cfg files (Local, Roaming, ProgramData).

If an AGN tile contains a mixture of AGNLibraryObject GUIDs defined by more than 1 default.xml file, then only the first AGNLibraryObject GUID listed within that AGN tile will be picked up by the sim, and only if the corresponding add-on default.xml file for that AGNLibraryObject GUID has the highest package order priority.

I've attached a second set of test files to illustrate what I mean:

In my first test above, there were 3 adjacent AGN tiles, each tile containing multiple instances of only 1 AGNLibraryObject:

• 1 AGN tile contained red lights.
• 1 AGN tile contained green lights.
• 1 AGN tile contained blue lights.

But a typical AGN tile contains a mixture of multiple AGNLibraryObjects. So in this second test, the same 3 adjacent AGN tiles now each contain a mixture of 3 AGNLibraryObject GUIDs:

• Red lights (c6a62d08-82c0-49ed-b7db-cd57f750d408)
• Green lights (2e51a27a-23b9-4f88-9e19-0c5cff34e27f)
• Blue lights (22990a10-4e5a-4d7e-9594-f8026b49f499)

Here's the ScenProc script used to generate the AGN tiles:

#Import Shapefile​

ImportOGR|C:\MyShapefile\building.shp|*|*|NOREPROJ|DONTPROCESHOLES​

#Split Grid​

SplitGrid|AGN|*|FROMFILE="building.shp"​

#Place new points in the middle of each shape ​

PlacePointAtCenterPolygon|*|Integer;MyPnt|1|MyHdg​

#Replace new points by new polys​

PointToPolygon|MyPnt=1|10;10|0|Integer;MyPoly|1​

#Add a random value attribute to each poly​

AddAttribute|MyPoly=1|Double;MyRndVal|RND(1)​

#Add a colour ID attribute to each poly based on random value attribute​

AddAttribute|MyPoly=1 AND MyRndVal<0.33|Integer;MyRed|1​

AddAttribute|MyPoly=1 AND MyRndVal>=0.33 AND MyRndVal<0.66|Integer;MyGreen|1​

AddAttribute|MyPoly=1 AND MyRndVal>=0.66|Integer;MyBlue|1​

#Create a corresponding AGNLibraryObject for each poly based on the colour ID​

CreateAGNLibObject|MyRed=1|c6a62d08-82c0-49ed-b7db-cd57f750d408​

CreateAGNLibObject|MyGreen=1|2e51a27a-23b9-4f88-9e19-0c5cff34e27f​

CreateAGNLibObject|MyBlue=1|22990a10-4e5a-4d7e-9594-f8026b49f499​

#Export AGN tiles​

ExportAGN|P3D v2|C:\MyAGNTiles​

Within the resulting AGN tiles, all the instances of each AGNLibraryObject are listed in the order specified by the ScenProc script, i.e. all the red lights are listed first, then all the green lights, then all the blue lights. For example, the resulting 011222330120003an.agn tile is constructed as follows:

Location 011222330120003​

Variant -1​

GenericBuildingTexture Default​

RowHouseTexture Default​

BuildingHeights 1 0 0 0​

VegetationClasses 0 0​

VegetationDensity 0 0​

VegetationHeights 0 0 0 0​

AGNLibraryObject {c6a62d08-82c0-49ed-b7db-cd57f750d408} -0.130599021911621 -0.260376930236816 1 0 0.00886249542236328 0.00819015502929688​

AGNLibraryObject {c6a62d08-82c0-49ed-b7db-cd57f750d408} -0.429248809814453 -0.22775936126709 1 0 0.00886249542236328 0.00819015502929688​

[...]​

AGNLibraryObject {2e51a27a-23b9-4f88-9e19-0c5cff34e27f} -0.0405421257019043 -0.494736671447754 1 0 0.00886297225952148 0.00819015502929688​

AGNLibraryObject {2e51a27a-23b9-4f88-9e19-0c5cff34e27f} -0.455599784851074 -0.175858497619629 1 0 0.00886249542236328 0.00819015502929688​

[...]​

AGNLibraryObject {22990a10-4e5a-4d7e-9594-f8026b49f499} -0.194619655609131 -0.454272747039795 1 0 0.00886297225952148 0.00819015502929688​

AGNLibraryObject {22990a10-4e5a-4d7e-9594-f8026b49f499} -0.271945476531982 -0.329376220703125 1 0 0.00886297225952148 0.00819015502929688​

[...]​

As per my earlier test, each AGNLibraryObject is defined by its own add-on default.xml file (one add-on default.xml file for the red lights, one for the green, and one for the blue), and the path to each of those add-on default.xml files is specified by its own add-on.xml file (one add-on.xml file for the red lights, one for the green, and one for the blue).

If the add-on.xml file for the red lights is given the highest package order priority, then only the red lights from the AGN tiles will be displayed in the sim.

Therefore one would expect that, if the add-on.xml file for the green lights were given the highest package order priority instead, then only the green lights from the AGN tiles would be displayed, and same for the blue lights, but this does not appear to be the case.

In this scenario (all 3 AGN tiles having red lights listed first) my testing indicates that, if either the add-on.xml file defining the green lights or the the blue lights is given the highest package order priority instead, then NO lights are displayed in the sim.

However, if the ScenProc script is re-run such that the green lights are created first, then all the instances of the green AGNLibraryObject GUID are now listed first in the resulting AGN tiles:

#Create a corresponding autogen library object for each poly based on the colour ID​

CreateAGNLibObject|MyGreen=1|2e51a27a-23b9-4f88-9e19-0c5cff34e27f <- the order has been changed​

CreateAGNLibObject|MyRed=1|c6a62d08-82c0-49ed-b7db-cd57f750d408 <- the order has been changed​

CreateAGNLibObject|MyBlue=1|22990a10-4e5a-4d7e-9594-f8026b49f499​

For example, the resulting 011222330120012an.agn tile is now constructed as follows:

Location 011222330120012​

Variant -1​

GenericBuildingTexture Default​

RowHouseTexture Default​

BuildingHeights 1 0 0 0​

VegetationClasses 0 0​

VegetationDensity 0 0​

VegetationHeights 0 0 0 0​

AGNLibraryObject {2e51a27a-23b9-4f88-9e19-0c5cff34e27f} -0.194393157958984 0.0163307189941406 1 0 0.00886201858520508 0.00819015502929688​

AGNLibraryObject {2e51a27a-23b9-4f88-9e19-0c5cff34e27f} 0.29003381729126 0.0647087097167969 1 0 0.00886201858520508 0.00819015502929688​

[...]​

AGNLibraryObject {c6a62d08-82c0-49ed-b7db-cd57f750d408} 0.376339912414551 -0.258242607116699 1 0 0.00886249542236328 0.00819015502929688​

AGNLibraryObject {c6a62d08-82c0-49ed-b7db-cd57f750d408} 0.173724174499512 -0.331160545349121 1 0 0.00886297225952148 0.00819015502929688​

[...]​

AGNLibraryObject {22990a10-4e5a-4d7e-9594-f8026b49f499} 0.429755210876465 -0.17416524887085 1 0 0.00886249542236328 0.00819015502929688​

AGNLibraryObject {22990a10-4e5a-4d7e-9594-f8026b49f499} -0.10178279876709 -0.337213516235352 1 0 0.00886297225952148 0.00819015502929688​

[...]​

Using this new tile with greens listed first, if the add-on.xml file for the green lights is given highest priority, then only the green lights will be displayed in the sim.

The same applies for blue lights, where the 011222330120013an.agn tile has the blue lights listed first.

Therefore, if an AGN tile contains multiple AGNLibraryObject GUIDs defined by more than 1 add-on default.xml files, then only the first AGNLibraryObject GUID listed within that AGN tile will be picked up by the sim, and only if the corresponding add-on default.xml file for that AGNLibraryObject GUID has the highest package order priority.

The good news is that, even in this scenario, if the ACM workaround (described in post #4 above) is used to merge the 3 external default.xml files (red, green, and blue), then a mixture of all 3 light colours are displayed correctly in the sim.

Cheers
Jeff

 

[arno]

Hi Jeff,
Do you think your last bug also applies between the default autogen default.xml and an add-on default.xml? Or only between different addons?

 

[Jeff Pollard]

Hi Arno

Unfortunately yes, part 2 of the bug does seem to apply between the default autogen default.xml and an add-on default.xml.

For example:

3 AGN tiles, each containing 3 sets of AGNLibraryObject GUIDs (for 3 different light colours) listed in a different order:

• Tile 1: Red > Green > Blue
• Tile 2: Green > Red > Blue
• Tile 3: Blue > Red > Green

3 AGNLibraryObject Class definitions (for the 3 different light colours):

• Class 1. The red light's Class, defined in a 'red light' add-on default.xml with higher package priority.
• Class 2. The green light's Class, defined in a 'green light' add-on default.xml with lower package priority.
• Class 3. The blue light's Class, defined in the default autogen default.xml. (I believe P3D automatically gives these definitions the lowest priority).

In the above scenerio, ONLY the red lights from Tile 1 are displayed. NO blue lights from ANY tile are displayed (even from Tile 3 where the blues are listed first).

If I disable the 'red light' add-on, then ONLY the green lights from Tile 2 are displayed. Still no blues from ANY tile.

If I reenable the 'red light' add-on and disable the 'green light' add-on, then ONLY the red lights from Tile 1 are displayed. Still no blues from ANY tile.

If I disable both 'red light' and 'green light' add-ons, then ONLY the blue lights from Tile 3 are displayed. No blues from Tiles 1 and 2.

So I think the conclusion must be:

Firstly:
P3D processes AGNLibraryObject GUIDs in the order listed in an AGN tile. If it thinks an AGNLibraryObject GUID is undefined (due to the add-on autogen priority bug or otherwise), then it will not process any further AGNLibraryObject GUIDs from that AGN tile, regardless of whether they are defined in the default autogen default.xml or an add-on default.xml.

Secondly:
P3D gives a lower priority to AGNLibraryObject GUIDs defined in the default autogen default.xml. Consequently, for a given AGN tile, if P3D thinks any of the AGNLibraryObject GUIDs defined in an add-on default.xml are undefined (due to the add-on autogen priority bug or otherwise), then any AGNLibraryObject GUIDs defined in the default autogen default.xml will not be picked up, regardless of the order in which they are listed within the AGN tile.

Cheers
Jeff

 

[Jeff Pollard]

Do you think your last bug also applies between the default autogen default.xml and an add-on default.xml? Or only between different addons?

In fact, it even applies to the default autogen default.xml on its own. I've just double-checked this with another test:

Again, 3 AGN tiles, each containing 3 sets of AGNLibraryObject GUIDs (for 3 different light colours) listed in a different order:

• Tile 1: Red > Green > Blue
• Tile 2: Green > Red > Blue
• Tile 3: Blue > Red > Green

This time, there are no add-on default.xml definitions. Instead, all 3 AGNLibraryObject Classes (for the 3 different light colours) are ALL defined in the default autogen default.xml:

If I remove ONLY the red light's Class definition from the default autogen default.xml, then:

• Tile 1: Red > Green > Blue
  • Result: No lights are displayed.
  • Explanation: P3D can't find the red definition, so stops processing the rest of the AGN tile.
• Tile 2: Green > Red > Blue
  • Result: Only the green lights are displayed.
  • Explanation: P3D finds the green definition, but can't find the red definition, so stops processing the rest of the AGN tile.
• Tile 3: Blue > Red > Green
  • Result: Only the blue lights are displayed.
  • Explanation: P3D finds the blue definition, but can't find the green definition, so stops processing the rest of the AGN tile.

If I remove ONLY the green light's Class definition from the default autogen default.xml, then:

• Tile 1: Red > Green > Blue
  • Result: Only the red lights are displayed.
  • Explanation: P3D finds the red definition, but can't find the green definition, so stops processing the rest of the AGN tile.
• Tile 2: Green > Red > Blue.
  • Result: No lights are displayed.
  • Explanation: P3D can't find the green definition, so stops processing the rest of the AGN tile.
• Tile 3: Blue > Red > Green
  • Result: Both the red and the blue lights are displayed.
  • Explanation: P3D finds the blue and the red definitions, but can't find the green definition, so stops processing the rest of the AGN tile.

If I remove ONLY the blue light's Class definition from the default autogen default.xml, then:

• Tile 1: Red > Green > Blue
  • Result: Both the red and the green lights are displayed.
  • Explanation: P3D finds the red and green definitions, but can't find the blue definition, so stops processing the rest of the AGN tile.
• Tile 2: Green > Red > Blue.
  • Result: Both the red and the green lights are displayed.
  • Explanation: P3D finds the green and red definitions, but can't find the blue definition, so stops processing the rest of the AGN tile.
• Tile 3: Blue > Red > Green
  • Result: No lights are displayed.
  • Explanation: P3D can't find the blue definition, so stops processing the rest of the AGN tile.

Cheers
Jeff

 

[Thunderbolt]

Thanks for the detailed analysis Jeff!

We have been using ACM for quite some time now. It merged add-on.xml files flawlessly (when no autogen-tag is present) from the beginning.
Our Skiathos scenery is configured this way.

Unfortunately autogen has always been the biggest pain and the cause of the majority of support requests for us.

Recently we get more and more support requests since more developers seem to be adding
their autogen with the <Category>Autogen</Category> tag (or other methods) which override our autogen as part of the default.xml.
The Prepar3D SDK makes you believe that the autogen is added to all other autogen and NOT replaced. This is a big issue and as you can imagine, debugging and fixing this for customers is a lot of work.
Most of the time I send them new add-on.xml files for sceneries which specify the Autogen-Tag and let ACM do the work. But sometimes the fix is a lot more complicated,
also based on the amount of sceneries the customer has installed.

I heard that the autogen issue had been fixed with Prepar3D v4.5 but based on experience and your findings this is obviously not the case - correct?

I'm hoping that Prepar3D will fix this issue asap. If it does, we will make the new version mandatory for Skiathos since
I don't want to dedicate so much time on fixing autogen issues ;-)

 

[L_Rob]

Hi guys,

This just to say I believe that the LM team is aware of the reported problem.

 

[GaryGB]

Hi Rob:

Good to see you posting here again.

GaryGB

 

[kevinfirth]

Any update on this, or comms with LM about it? It doesn't appear to be been resolved in v5...

 

[See Michel]

For me it doesn't work in P3Dv5. Still not fixed from LM.

 

[See Michel]

Hi, I wanted to share my observations. I moved all autogen outside any add-on.xml. Only ORBX libs had been left that way, because I wanted to keep it installed in their library.
All other autogen was merged in the [root]\autogen folder by ACM. So far ok.
Now, bang...ORBX via add-on.xml superseed all other merged autogen. When I deactivate ORBX libs, all fine.
So LM has nothing fixed. Don't use a single autogen in any add-on.xml, or we will have problems.