Hi,

I am so grateful for this tool as it is the only scenery management software that seems to work with the Add-On.xml system and also the scenery.cgf system.  I have noticed some behavior in P4AO (using version 1.08) that has been driving me a little bit crazy.

The two issues seem to be related to how P4AO handles the add-on.xml files when pressing "save".

Specifically:

• An XML header

  <?xml version="1.0" encoding="utf-8"?>

  is added at the top of the file and this can cause some issues with Aivlasoft's EFB when that line is read. I base this observation also on the example given here - http://www.prepar3d.com/SDKv4/sdk/add-ons/add-on_packages.html - where no XML header is included.
• Specifically for FSDreamTeam/FlightBeam sceneries, it would seem that P4AO rearranges the contents of the file such that the "Texture" component is placed ahead of the "Scenery" component.  The result of this is that Aivlasoft's scanning routing won't see that there is a scenery folder for that entry and it fail to find the scenery and register it.

I am posting here rather than at Aivlasoft as it seems that these modifications are made here with P4AO.

Thanks!

Hello Jeff,

the line "<?xml" is called the Text Declaration, see the W3C spec:

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

As per the specification, every XML parser reading an XML file must be able to understand this, otherwise the program is not implemented correctly. It can be omitted when the XML file has a specific encoding, but only then. Nevertheless, every app claiming to read xml files must be able to understand both options and correctly determine the encoding. In case of P4AO the declaration is necessary, because the tool forces the UTF-8 encoding with ByteOrderMark.

About texture and scenery - the sequence in which these addon components appear should be of no consequence. I would imagine that Aivlasoft may rather have a problem with those addon-xmls that target the "\scenery" and "\texture" subfolders directly, as opposed to defining a "scenery area", which per MS/LM spec has subfolders "Scenery" and "Texture" in it. If you change the sequence of texture and scenery manually, does Aivlasoft work?

Edit: as a work around you could use the P4AO feature that temporarily creates a compete scenery.cfg that contains all sceneries, no matter if they were declared in the cfg or in xml files. The EFB would then read this temporary file and find all the sceneries. After that the P4AO restores your original cfg file.

Best regards

 

 

Hi Oliver,

Thanks for your reply.  Thanks for the point out for the W3C spec.  Question: do these files need to be UTC-16 (UCS-2 LE BOM in Notepad++) like the I've read about other new files?  I agree that I should contact the Aivlasoft folks about the read order as the developer does profess to reading the folder and files directly.  However, I ask here because my testing says that when I press SAVE in P4AO, the AddOn.Component elements are reorganized.  I was wondering if just the layer could be changed rather than other portions.  I realize that you offer a full solution for creating and managing these files, so I just thought I'd ask here.

5 hours ago, ahuimanu said:

Question: do these files need to be UTC-16 (UCS-2 LE BOM in Notepad++) like the I've read about other new files?

Hello Jeff,

no. An XML file has the encoding that is specified in the Text Declaration, in this case UTF-8. W3C spec has something to say about encoding too, its just a few lines down on the linked page.

Sequence: only scenery components can be layered in a specific order, the others (like textures) don't even have that parameter.

Thanks Oliver.

The original backup file that you save when P4AO first encounters the file contains the found sort order of the elements of the addon.xml file.  Is it possible to retain that original order?

 

14 hours ago, ahuimanu said:

The original backup file that you save when P4AO first encounters the file contains the found sort order of the elements of the addon.xml file.  Is it possible to retain that original order?

Hello Jeff,

The backup file is the original. It is not saved, it is copied. Its internal sequence can only be retained if it is not changed by the user - there are two opposing requirements here.

Addon.components other than scenery don't have an "original order", they are just lookup paths for the simulator to find files of a specific type. This "sequence" never existed on the ESP platforms, and it doesn't matter now either. Unfortunately I stopped using the Aivlasoft EFB quite a while ago, and I don't have any of the sceneries installed that you mentioned. Are you 150% certain that the component sequence makes a difference? What if there is yet another addon.component above the scenery entry, like Effects or SimObjects?

Besides, if it doesn't matter to the simulator, personally I think it is dangerous to rely on a certain order. As there is no rule for this sequence you could encounter the same issue with every new addon that you get, if the developer decides to implement his own order of things.

Best regards