Encoding of add-on.xml

[steve40 7]

I've just spent a few hours troubleshooting a CTD issue which I have traced to the structure of utf-8 encoded add-on.xml compared to Windows-1252 encoding.

I have been participating in the beta testing of ORBX's new ObjectFlow 2 DLL.

The original add-on.xml supplied by ORBX works perfectly, and is as follows:

<?xml version="1.0" encoding="Windows-1252"?>
<SimBase.Document Type="AddOnXml" version="4,0" id="add-on">
    <AddOn.Name>Orbx ObjectFlow 2</AddOn.Name>
    <AddOn.Description>Allows Orbx scenery to display dynamic content.</AddOn.Description>
    <AddOn.Component>
        <Category>DLL</Category>
        <Path>C:\Users\Steve\AppData\Local\Orbx\FTXCentral\v3.2.2.5\Orbx_ObjectFlow_x64.dll</Path>
        <DllStartName>module_init</DllStartName>
    	<DllStopName>module_deinit</DllStopName>
    </AddOn.Component>
</SimBase.Document>

Now, I used Addon Organizer v1.09 to re-create the add-on.xml file, and this was the result:

<?xml version="1.0" encoding="utf-8"?>
<SimBase.Document Type="AddOnXml" version="4,0" id="add-on">
  <AddOn.Name>Orbx ObjectFlow 2</AddOn.Name>
  <AddOn.Description>Allows Orbx scenery to display dynamic content.</AddOn.Description>
  <AddOn.Component>
    <Category>DLL</Category>
    <Path>C:\Users\Steve\AppData\Local\Orbx\FTXCentral\v3.2.2.5\Orbx_ObjectFlow_x64.dll</Path>
    <DLLStartName>module_init</DLLStartName>
    <DLLStopName>module_deinit</DLLStopName>
  </AddOn.Component>
</SimBase.Document>

The above caused P3D to CTD reproducibly during the splash screen, while the DLL was loading, before the scenery catalogue was indexed.

After a lot of testing, I solved the problem by adding this additional line to the file:

    <DLLType>PDK</DLLType>

It's odd that this line only seems necessary when the file is utf-8 encoded.

Anyway, I thought I should report it. I don't think it's a bug in Addon Organizer, maybe it's a P3D issue or DLL issue. I have other DLLS that load fine using a utf-8 encoded add-on.xml, but those DLLs don't require the DLLStartName or DLLStopName parameters (e.g. FSDT Addon Manager, bglmanx.dll).

Cheers

[Lorby_SI 2,042]

Hello Steve,

thank you for the find. Not sure how this could be related to encoding, but you never know.

The spec is relatively clear:

Quote

The DLLType determines how the add-on library is initially launched. If the DLLType is not set (i.e. Empty String), then the default start, "entry point", and stop, "exit point", functions, described in their respective sections, are used. The list of non-default DLLTypes are:
SimConnect
PDK

When using these types above, the default DLLStartName and DLLStopName change, unless overridden. Please be aware, the DLLStartName's function parameters for each of the parameters are also different:
Default (Empty String): This start function does not have any function arguments.
SimConnect: This start function has a single function argument which is a pointer to a constant character array or const char*.
PDK: This start function has a single function argument which is a pointer to the Prepar3D PDK interface or P3D::IPdk*.

If they really mean it literally, then the initialization procedure may be called incorrectly if no DLLType is set. But that should happen regardless of encoding, unless the "empty" part is initialized differently.

Best regards

Edit: btw, latest version is 1.12. You should get it, quite a few bugs have been fixed.

[steve40 7]

I had read the SDK, but oddly, the DLL still worked correctly without specifying the DLLType parameter if the file was encoded in Windows-1252. Maybe it is a quirk of P3D. At least I know how to deal with it now. I've also updated Addon Organizer to 1.12, thanks. Your tool keeps getting better and better. Cheers.

[Lorby_SI 2,042]

6 hours ago, steve40 said:

Maybe it is a quirk of P3D.

If P3D reacts differently to the same file in a different encoding it most certainly is.

But what worries me is, that the fact that the ISO encoding works feels wrong. The way I read the spec, you have to add the DLLType when you want to overwrite the startup and shutdown methods. So the UTF behavior would be correct, but the CP1252 would be a glitch. ???

Best regards

[steve40 7]

Hi Oliver,

I've found the root cause.

I took the original CP-1252 add-on.xml and retested it. It worked as expected.

Then I used a hex editor (UltraEdit) to load the file and save it as utf-8. It still worked, even without specifying the DLLType.

Then I used Addon Organizer to recreate the add-on.xml with exactly the same parameters. It crashed the sim. The only difference was that Addon Organizer added this line to the file:

    <DLLType />

When I deleted this line, the sim stopped crashing! I guess P3D cannot parse that statement. That explains why I was able do get the file to work using Addon Organizer by specifying an actual DLL type - it was able to parse "<DLLType>PDK</DLLType>" because it doesn't terminate with a "/>". Cheers

[Lorby_SI 2,042]

45 minutes ago, steve40 said:

Hi Oliver,

I've found the root cause.

I took the original CP-1252 add-on.xml and retested it. It worked as expected.

Then I used a hex editor (UltraEdit) to load the file and save it as utf-8. It still worked, even without specifying the DLLType.

Then I used Addon Organizer to recreate the add-on.xml with exactly the same parameters. It crashed the sim. The only difference was that Addon Organizer added this line to the file:

    <DLLType />

When I deleted this line, the sim stopped crashing! I guess P3D cannot parse that statement. That explains why I was able do get the file to work using Addon Organizer by specifying an actual DLL type - it was able to parse "<DLLType>PDK</DLLType>" because it doesn't terminate with a "/>". Cheers

Hi Steve,

thanks for the find! That is correct, P4AO would add an empty tag, which looks like what you discovered, that is perfectly acceptable XML notation. In fact, the XML is not of my own design. I just provide the data. The XML file itself is created by the built-in .Net XML serialization logic, provided by Microsoft. The fun part is, that "empty" doesn't seem to be the same as "empty". The spec says "... an empty string...", which is what the tag symbolizes (if you don't have content, it is allowed to cut the XML tag short by including the closing / )

I will see what I can do, it should be possible to suppress the tag, when it is empty. That doesn't make it right of course, but if the simulator prefers it this way. Nevertheless, this is something that LM should address.

Best regards

[Lorby_SI 2,042]

Hi Steve,

fixed with version P4AO 1.13 which is available for download - now. So the spec means "null" when it says "empty string", that is good to know.

Would you mind testing this with the ORBX DLL? I don't have that one, so I can't be 100% sure that the issue is indeed fixed.

Many thanks in advance and best regards

[steve40 7]

Hi Oliver,

That was fast :)

P4AO v1.13 works, the DLLType string is suppressed when the type isn't specified, and the sim no longer crashes (and ObjectFlow 2 is working).

Cheers.

[Lorby_SI 2,042]

4 hours ago, steve40 said:

Hi Oliver,

That was fast :)

P4AO v1.13 works, the DLLType string is suppressed when the type isn't specified, and the sim no longer crashes (and ObjectFlow 2 is working).

Cheers.

Great, thank you for checking!

This is one of those interesting things about computers - that there is more than one kind of "empty" ;o)

Best regards