I’ve been quiet on the blog both because I was out sick for a few days but also because Sandy and I have been bashing pretty heavily on plugins, trying to determine the best way to prevent plugins from conflicting with each other.  The way 32-bit plugins link on OS X/Linux allows one plugin to interfere with another one’s code, which causes support problems in-field.  We are looking for any way we can to minimize this for 64-bit plugins.

The short of it is this:

  • Name & shame is probably not going to work for DLL linkage.  (It will work if you crash!)
  • Beta 11 should ship with a new XPLM implementation.
  • You should not be shipping 64-bit plugins now.  You should expect to retest your plugins against the next beta, and possibly even recompile your 64-bit Mac plugin

I cannot emphasize this enough: it’s not over until it’s over.  Just because 64-bit plugins appear to be working does not mean that we have worked out all of the bugs and won’t be making radical changes.  Once we are out of beta, things should be very stable, but during beta, this is our only time to get things right.

The last plugin ABI lasted over a decade, so it’s important that we get 64-bit right.

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.

3 comments on “Beta 11 Will Have Major SDK Changes”

  1. Talking about plugins.
    X-Plane has an UDP ouput system, which is limited in terms of number of variables (data refs). Also the byte conversion thing is a little hard for most people to use.

    Then there are all these plugins from outside developers, SASL, Pyton script, UIPCX, flyWithLUA and more. Sometimes working sometimes not.
    Respect for the people making those for free, but it would be very nice if X-plane had a simple native way of data output/input directly linked to datarefs. Based on simple text or string and an UDP TCP server or/and plain textfile.

    1. It’s sort of astonishing to me that the community hasn’t produced such a thing, given that the tools to do so have been around for a full decade.

  2. It probably has something to do with the fact thst if I need a plugin for XYZ feature to work I’d just write the plugin, as opposed to writing an overall plugin methodology. I suppose it would take far longer to write a framework rather than just getting my XZY feature to work.

Comments are closed.