EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

This is a small feature but for plugin developers it may make a huge difference in work-flow.

In the plugin system up to version 2.1 (everything we’ve shipped through X-Plane 11.05) plugins are packed like this:

my_plugin/
my_plugin/64/mac.xpl
my_plugin/64/win.xp

This has one problem: every plugin on your install is either named mac.xpl, win.xpl, or lin.xpl.

And as it turns out, pretty much every debugging tool ever assumes that each DLL will have its own unique name because it’d be crazy to do otherwise. The decision to make the file name in the fat plugin structure the OS was a really dumb one by me.

With version 3.0 of the SDK, you can now pack like this:

my_plugin/mac_x64/my_plugin.xpl

and with that format, each plugin’s name makes its DLL unique.

This should fix a bunch of things:

  • You’ll be able to start X-Plane via X-code to debug your plugin without all hell breaking loose.
  • Back traces on Windows debugging tools should make the plugin executing clear even without symbols.
  • Any kind of memory map dump (including those in Apple crash reports) will unambiguously show what plugin code is loaded into what memory address.

The existing 2.0 format (fat plugins shown above) and 1.0 format (thin plugins, supported only in the global plugins folder) will continue to work indefinitely – they’re still there.

But if you are going to target X-Plane 11.10 and use the new plugin system features, you may want to use the new packaging and save yourself some debugging chaos.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

10 comments on “New Plugin Packaging for the SDK 3.0”

  1. In what order will X-Plane search for plugin binaries? Will it be possible to distribute a plugin that has a version compiled for SDK 2.1 at the old path and a version for SDK 3.0 at the new path? This would be great for plugins that need to support XP10 and XP11 at the same time.

        1. Based on all the activity, it feels like “Real Soon Now”

          Maybe Minyana? Unfortunately Minyana doesn’t mean tomorrow, it just means ‘not today’….

  3. Great features !
    I was having issues (as a user) with too much groundroute ( so too much win.xpl ).
    Some plane, features & sound couldn’t work properly because of : Error Code = 1114.
    I’ve clean this by deleting somes groundroute in airport. Now everything is back on track ! 🙂
    Good job !

  4. As soon as I can test on 11.10b1 I plan on testing the following Plugin Packaging to see if it will work over XP10 & 11.

    plugins/Xchecklist/lin.xpl 32bit
    plugins/Xchecklist/mac.xpl 32bit
    plugins/Xchecklist/win.xpl 32bit
    plugins/Xchecklist/64/lin.xpl
    plugins/Xchecklist/64/mac.xpl
    plugins/Xchecklist/64//win.xpl
    plugins/Xchecklist/lin_x64/Xchecklist.xpl
    plugins/Xchecklist/mac_x64/Xchecklist.xpl
    plugins/Xchecklist/win_x64/Xchecklist.xpl

    Bill

    1. Hi Ben,

      I really do not understand why you need to complicate the naming of the folders.
      If until today we placed all plugins in “plugins/name/64” can’t we just use
      plugins/Xchecklist/x64/lin_Xchecklist.xpl
      plugins/Xchecklist/x64/win_Xchecklist.xpl
      plugins/Xchecklist/x64/mac_Xchecklist.xpl

      I don’t want to sound petty, but I think this naming convention should be as readable as the “proposed” one and also have same advantages in debug tools too, and we will have less folders to “maintain” 🙂

      Cheers
      Saar

  5. Looking forward to getting 11.10b1 to start working with the new UI api’s and these plugin changes!

Comments are closed.