Talking to Plugins

We're continuing to integrate X-Plane 11.10 (with mixed success!); we'll get more info on 11.10 posted once we're in beta.  11.05r2 will come out as soon as I get my hard drive fully restored - from the looks of the comments this should be Real Soon Now™.

This post is for plugin developers - if you don't write plugins, I suggest cat pictures instead.

For as long as there has been OBJ animation, X-Plane has called the XLMGetDataXXX APIs from inside the OBJ engine as drawing is taking place. These calls eventually show up in your plugin in your dataref read callback. You might even see X-Plane code on the stack if you put a break-point in your read accessors.

This design has two major draw-backs:

  1. It's bad for multi-core. Since the plugin API is single-threaded, operations requiring us to know the animation state of an object (drawing, collision testing, etc.) require us to be on the main thread. So this doesn't scale well.
  2. It's inefficient. We might have to draw your aircraft several times - one or more times for reflections, one or more time for cascading shadow generation, and once to draw (or more for multi-monitor). The work to fetch those datarefs is done multiple times, even though we don't want different answers between drawing passes.

(In fact, it's worse than that - if you have the same dataref used in multiple animations, we just request the dataref over and over...not real clever.)

X-Plane 11.10 changes this for the first time: we are starting to collect the entire set of datarefs we need to draw a model in a single burst. We can then save these dataref results and reuse them.

This is just the beginning of a series of changes to make the rendering engine multicore-friendly. Hopefully it won't affect any add-ons* - this should have no effect unless you are doing highly illegal things with the SDK.

I am hoping we'll see some performance benefit by not spending as much time in plugin code, but I don't have numbers yet.

* Plugins that read the object-draw-location datarefs to do multiplex their datarefs on multiple models should still work; we set those object-location datarefs before we collect all of the datarefs for your model.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn

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.
This entry was posted in Development. Bookmark the permalink.

19 Responses to Talking to Plugins

  1. ChrisOak says:

    you are genius!

  2. Steve.Wilson says:

    Ah. Someone else that understands talking to plugins. I knew I wasn't talking to myself as I pound the keys in hopes that my keystrokes would magically become new functionality within X-Plane. I'm not mad after all. At least, not much...

    Thanks, Ben. An update to the SDK is due, as is an update to the SDK glue between X-Plane and our wild and crazy machinations. Thanks for going into detail in these blogs. It's going to be a process. And no fun when it breaks. But if you keep us vigilant, hopefully the impact to our customers will be benign. The cool thing is that our "stuff" might actually start to work better if it's more efficient, and no one can complain about that!

  3. Abe says:

    Great news! I am curious to know if you are seeing crash reports with the latest NVIDA drivers. Sim started to crash on 11.05r1. I do not see any crash reports in the output folder. Thanks!

  4. Since the theme is Prugins, I can say something about it.

    I currently adapt the "FSTramp" DLL add-on from the FSX world to the X-Plane world. It is an instant rendered 3D world map, flight planner and FMS. In this work I missed a function in the SDK plugin painfully. It is the immediate positioning of the aircraft on a runway or a parking space, but also the positioning of the aircraft at any point on the earth's surface, e.g. on a water surface. Lat, Lon, Alt and Heading should be sufficient as positioning data.

    The immediate positioning should also be possible in flight. Around the globe. So far I only succeeded for short distances. In the case of longer distances, the aircraft will hang obliquely in the air. I am making these air jumps with the following unsatisfying program code:

    double outX, outY, outZ;
    XPLMWorldToLocal(m_SkipTo.m_fLat, m_SkipTo.m_fLon, m_Aircraft.m_fAlt, &outX, &outY, &outZ);

    XPLMDataRef rfLocalX = XPLMFindDataRef("sim/flightmodel/position/local_x");
    XPLMDataRef rfLocalY = XPLMFindDataRef("sim/flightmodel/position/local_y");
    XPLMDataRef rfLocalZ = XPLMFindDataRef("sim/flightmodel/position/local_z");

    XPLMSetDatad(rfLocalX, outX);
    XPLMSetDatad(rfLocalY, outY);
    XPLMSetDatad(rfLocalZ, outZ);

    Perhaps someone can accept this topic and expand the SDK. Or I have not understood the SDK correctly and someone gives me support.

    • Saar says:


      I suggest you open a topic in developer forum.
      You can also send an e-mail directly to Ben, if he has time he responds.

      Please do remember that there is the physics aspect when moving a plane. You can read about it in the XPSDK wiki site. Regarding positioning, I always end up moving the plane to the closest ICAO(There is function for that) and than positioning the plane in lat/long location relative to that ICAO.

      From what I know there is no SDK functionality for direct positioning on runways or in air. I believe you need to calculate everything by yourself.
      Maybe the next SDK will expose more functionality for controling plane positioning.

      Good Luck

      • Helge Schroeder says:

        Thanks for the answer. Pampered by Prepar3d and the Lockheed Martin service, it is really not easy to find and understand the hidden Internet resources and connections. The plugin SDK, to be found at, is only one of the many examples.

  5. Bruno says:

    Apologies again for the unrelated post.

    Yesterday, as the weather was "interesting" in LPPR, I took my 737 there for an ILS approach. Real weather, real time (night time). There were 2 layers of broken clouds from 500 feet to 2000 feet, roughly.

    I think you can guess where this is going... I was able to see the city lights and the airport perfectly until I was at 2000 feet... then zero visibility until 500 feet, then visibility again.

    These "see-through" clouds are so unrealistic, I'd rather have totally opaque clouds at night than this.

    Just making sure this doesn't get forgotten.


  6. Onrej T. says:

    Long talk about OBJ's, but what about weather API to be more friendly for 3rd party developers so we could finally get some reasonable weather and cloud formations depiction in our otherwise beloved sim? Can we expect it soon? 🙂

  7. SNowblind_7 says:

    Sorry to ask here, I saw on a last comment about weather datarefs, but I did not find anymore this coment. Is there a way to check if the real weather was updated?

    • stef Maurel says:

      Dear Snow,

      Ben already replyed to me on this question. Here is his reply :

      Yes! The sim sends _itself_ the command "sim/operation/load_real_weather" when a rescan is needed. So intercept (but do not OVERRIDE) this command and you can know it happened, whether from a plugin or the sim itself.

      I hope it coud help you, it works for me from 11.0.2.


  8. Javier says:

    When will the issue with shadows fixed? They work really bad with many buildings, very jaggy even in 4k and with AA.

  9. Christophe says:

    Hi guys,

    While we talk about plugins: is it possible to think about "sandboxing" an aircraft ?
    I use this term because when you change from an aircraft to an other, sometimes - not always, you have to restart XPlane to be able to use properly the second aircraft.

    It's like one of them (the first or the second) didn't init/use properly one or more variables.

    So, I guess that it could be better if an aircraft is always loaded in a fresh sandbox initialized by default data refs by LR itself like when we load the sim from scratch.

    Any thought ?

    Thanks !

    • Ben Supnik says:

      Hi Cristophe,

      It would be a nice protection to have, but it's not easily retrofitted into the current design. Unfortunately when we designed a lot of the interfaces to the sim, we didn't take plugin developer mistakes into account. And even as I can see the benefit of such a feature, it feels weird to work on a feature whose goal is to make a poorly-written add-on seem like a well-written one.

      • Christophe says:

        I understand your point of view but I was not pushing this sandbox idea to "fix" the poorly written add-on 🙂

        It's a pity when you have a add-on with the half avionics down just because we use another one just few minutes before.

        The idea is more like publishing a contract to the good ones: whatever the previous running addon creates/destroys/updates/breaks/... into the sim, be safe, your freshly created sandbox is perfect for your run and you will not suffer from the damages from the previous one.

        It's a different viewpoint of the very same problem 🙂

  10. richard says:

    good evening when relased x-plane 11.10 beta 1 ?

  11. Elios says:

    yeah any updates on when even 10.05 is going final?

Comments are closed.