Category: Plugins

Our shaders don’t like to be touched

X-Plane has always shipped with the shaders visible to everyone as plain text in the Resources/shader directory. Partly this was due to making it convenient to load the shaders into OpenGL itself, but we also don’t have anything to hide there either so it doesn’t make much sense to try to hide them. You are more than welcome to look and poke at our shaders and if you learn something about X-Plane in the process, that’s awesome!

However, the one big caveat to that is that we never considered the shaders to be part of the publicly accessible interface and they are in no way stable across versions. X-Plane is an actively developed product and we are making a lot of changes to the codebase, including the shaders, so you should never ever distribute a plugin or tool that modifies the shaders. Since we give no guarantee that our shaders will remain stable across versions, you’ll always be left worrying that we might break your add-on.

Additionally, there is a big change to the shader system coming in 11.30 that will definitely break all existing plugins that are modifying shaders. This blog post will cover the upcoming changes and hopefully convince everyone that the shader system is in flux and not to be relied upon as a basis for add-ons. Read More

Posted in Development, Plugins by | 30 Comments

Widget Windows, You Fancy Now!

I’ve gotten a handful of emails from third-party devs recently asking the question:

I have a bunch of XPWidget-based windows. When will I be able to use them with fancy new features like UI scaling, pop-out support, VR support, etc.?

Happily, the answer is: now!

I really buried the lede on this one, but back in X-Plane 11.20, as part of adding plugin support for VR windows, we added a new “mode” for XPWidget-based plugins. It all starts with a call to opt-in to the “modern” window APIs like this:

XPLMEnableFeature("XPLM_USE_NATIVE_WIDGET_WINDOWS", 1);

From this point forward, all widget windows you create will be backed by a modern XPLM window, and can therefore be used with all the new XPLMDisplay APIs. All you have to do from there is call XPGetWidgetUnderlyingWindow() get the XPLMWindowID of your window to pass to those APIs.

Posted in Plugins by | Comments Off on Widget Windows, You Fancy Now!

Plugin Developers: Please Try This Fix

X-Plane 11.20r2 has only one bug that we are trying to fix: a bug in the plugin SDK that can cause some plugins to crash when creating and destroying windows.

Tyler and I dug into this and found that the fix was a bit more intrusive than we wanted for this late in an RC.

So: if you are a plugin developer and you are working with the new SDK, either for VR compatibility, to use the new 3.x APIs, or just because you are updating the plugins, and you have time this weekend, please email me and I can send you our new fixed XPLM DLLs.

My hope is to get half a dozen plugin developers to bang on them over the weekend, so that when we cut 11.20r3, it really will be the release.

Edit: RC3 is live – thanks to everyone who helped!

Posted in Development, Plugins by | 4 Comments

Let’s Talk About CEF (Some More)

The CEF post generated a lot of controversy, and rather than replying directly in the comments (and doing a bunch of copy & paste), I thought I’d collect my responses to the major objections here.

Objection: Nobody wants to browse the web in X-Plane!

Yes and no. I agree that, unless you’re in VR, a full-fledged web browser is totally useless. Nobody wants to be browsing cat pictures while flying. But CEF is really not designed to power a traditional web browser.

Consider this list of a bunch of other applications that nobody wants a web browser in:

  • Spotify
  • Adobe Acrobat
  • Evernote
  • The Steam client
  • The Atom text editor
  • The GitHub desktop client
  • WhatsApp

What do all those applications have in common? They’re built on CEF, or the closely related Electron project.

My point is this: the primary use case for CEF is not to build a full-fledged browser—it’s to support things like HTML5 user interfaces, which massively lower the bar for creating nice, easy-to-use plugins. It could also support things like displaying PDF charts or other electronic flight bag features—things that are theoretically possible without a webview, but which have such a high barrier to entry that nobody wants to tackle them.

We are always looking for ways to both

  • get more people involved in creating X-Plane add-ons, and
  • give existing plugin developers better tools so that they can create things they couldn’t have before.

Doing so makes the X-Plane community stronger, and supports the creation of add-ons that might otherwise not have existed.

Objection: This is a waste of time. What you should be working on is [some other feature].

As I mentioned previously, CEF is being used in X-Plane right now to enable in-app upgrades. This is obviously the most boring non-feature we could ever ship, and I understand why power users (people who might have bought X-Plane 11 on day 1!) are irritated.

The reality is: some features we ship for end-users*, and some we ship to “pay the bills.” Paying the bills is boring, but important: having X-Plane be financially successful ensures that we can continue improving the sim (ahem, in ways that end users actually care about!) for decades to come. In this particular case, we have reason to believe the current purchasing process is convoluted enough that it’s losing us sales. In-app upgrades will increase sales by some (small) percentage, so even though it’s not a direct improvement to the sim for existing users, it’s funding future development.

One more thing worth mentioning on the topic of “I wish you’d do x instead” is that we have a handful of full-time developers now, with people specializing in very different areas, so we tend to have a lot of features in progress at any one time. It’s certainly not the case that, say, Sidney stopped working on improving performance while I was off integrating CEF. 🙂

Objection: I don’t want X-Plane plugins using webviews!

The reason we’re having this discussion is that plugin developers are already using CEF—and they’re doing so in ways that are incompatible with other developers’ implementations.

It’s certainly an option for us to bury our heads in the sand and ignore this—we could force users to choose between, say, installing a Flight Factor plane and installing a fancy new web-based plugin (or using future X-Plane core features). Ultimately, though, this hurts both the end users who would have otherwise chosen “all of the above,” and it hurts the add-on makers who lose sales because users were forced to choose.

We can’t stop add-on makers from using webviews, but we can make sure that doing so doesn’t lead to a compatibility nightmare for end users.

Objection: CEF represents a massive security hole!

This is absolutely a concern for us. Webviews in X-Plane present two major attack surfaces:

  1. The possibility of running untrusted code (e.g., a nefarious site exploits a browser vulnerability to execute harmful code on your machine)
  2. The possibility of sending data somewhere you didn’t want it to go (e.g., a nefarious site masquerades as your bank’s web site, and sends your login info to bad guys)

We’re still in the “exploration” phase here, trying to understand plugin developers’ needs, but there are a lot of ways we could mitigate these threats. A few possibilities, listed from most extreme to least:

  1. Don’t allow remote connections at all; plugin-created webviews could only load local assets (HTML, JS, etc.) that were bundled with the plugin
  2. Disable JavaScript entirely
  3. Require plugins to provide a whitelist of URLs that are deemed safe to send & receive data from
  4. Disable JavaScript loaded from external (or non-whitelisted) domains
  5. Allow user preferences to control the above policies (or even disable webviews entirely)

Objection: CEF will slow the sim down. This is bloatware!

That’s for measurement to decide! In our tests, having CEF displaying static pages while flying didn’t slow down the sim by any amount we could measure. And since CEF doesn’t run on the main X-Plane thread, the OS can schedule CPU-intensive things like page loads around X-Plane’s work. There is definitely some memory overhead involved (a few hundred megabytes), but considering the existing footprint of X-Plane, it’s not a crazy amount.

And, like everything in X-Plane, if you want to tune it to get the last drop of performance, you’d be free to avoid using features & add-ons that depend on webviews.

Objection: Don’t use CEF—You should use WebKit, Gecko, Servo, etc. instead.

I did a lot of research and test implementations (on Windows, I went so far as to use Trident, the underlying engine to Internet Explorer!), and the only webview framework I found that meets X-Plane’s requirements was CEF.

* Aside: What does 11.20 include for end-users? A few highlights from the release notes:

  • VR support
  • New Sydney, Australia landmarks
  • A new Aerolite 103 model
  • An overhauled Columbia 400
  • 1,315 airports with new 3-D scenery
Posted in Plugins by | 23 Comments

Let’s Talk About CEF

In the X-Plane 11.20b1, we’re shipping a web browser for the first time. We’re using the Chromium Embedded Framework (CEF)—essentially the same guts as Chrome, wrapped inside X-Plane.

For the time being, it’s being used in one place only*: to support in-app upgrades, so that if you have the demo, you can buy the full version of X-Plane without having to go to the web site. The web view is seamless—you can’t tell by looking at the app that it’s not just part of the native X-Plane user interface.

While its present use is quite limited, if all goes well, we’d like to expand its use elsewhere in the sim—in The Glorious Future™, we could potentially use it to load online charts and the like.

But, there’s a hitch!

There’s not a good way to load two copies of CEF at a time. And, since some plugins (like the ones used in the new Flight Factor A320 Ultimate) depend on a version of CEF provided by a (global) plugin, we have to disable X-Plane’s web browser functionality in the presence of that plugin. This isn’t a big deal right now—after all, if you’ve installed payware, you probably already own the sim anyway—but it will be a shame if, in The Glorious Future™, you have to choose between your payware and core X-Plane functionality.

The situation is even worse than you might expect: CEF absolutely doesn’t support multiple initialization calls in the lifetime of an app—you can’t initialize it, shut it down, then re-initialize it. That means it’s not even possible for plugin authors to be good citizens and “relinquish” CEF to X-Plane, such that you could at least use X-Plane’s browser whenever you’re not using an add-on that depends on it. It’s all or nothing! In fact, you’ll have to uninstall the CEF plugin before X-Plane can use a web view itself.

There are two possible fixes here:

  1. At some point in the future, we provide access to CEF via the plugin SDK. If we did, it would have to be to the C API only—no fancy C++ wrappers for you. Speaking as someone with the memory of writing for the C API fresh in his mind, let me say: this isn’t a whole lot of fun, and it’s rife with the potential for memory leaks. Moreover, this would break any existing addons that depend on CEF—they would be forced to migrate to the SDK version of the API.
  2. We could (theoretically) compile an X-Plane-specific version of CEF that would not conflict with the version plugins are using. This would require renaming all the Objective-C symbols on Mac, and renaming the DLL on Windows. I’ve not investigated this for feasibility, but it’s certainly theoretically possible. This would allow X-Plane’s version of CEF to coexist with (one) plugin-provided copy, albeit at double the CPU and memory cost.

Having us expose CEF via the SDK is not an unequivocal win. CEF is notoriously incompatible between versions—you can more or less guarantee that even minor updates will break compatibility of the API somewhere. That means X-Plane would be stuck at a fixed version of CEF for at least the lifetime of a major version to prevent breaking plugins. X-Plane 11.20 uses CEF release 3202; it would be at least the next major version before we updated CEF to a newer version. There are two major downsides to this:

  1. When X-Plane updates to that newer version, it would break plugins compiled against old versions of the SDK that depend on CEF. That’s a lot more aggressive than our normal deprecation policy, and it makes CEF plugins a potential maintenance headache for plugin devs.
  2. If your add-on really, really needs features from the latest and greatest CEF release, you’re out of luck—wait a couple years (!!) and maybe we’ll update.

So, here’s what I’d like to hear from plugin devs:

  1. Are you currently, or are you planning to use CEF in the future?
  2. Would you be willing to use the C version of the CEF API only?
  3. Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?

If you don’t mind telling me a bit about your intended use cases, that’d be very helpful as well!

EDITED TO ADD: There’s a third option here that I didn’t consider: X-Plane could provide a “wrapper” around CEF that offers “just” a browser surface, and simple interfaces like the ability to change the URL programmatically. This has the advantage that we could update CEF regularly without breaking the API (though there’s always the risk that a new version of Chromium would change how it handles your HTML + CSS + JS). The disadvantages are twofold:

a) If a plugin developer really, really needs the full power of the CEF API, they’re out of luck (or we’re back to square one with respect to having to disable core X-Plane functionality in order to support the plugin).

b) New XPLM APIs are a massive tax on our development time. Every time we need to make a change, we have to go test a dozen plugins… then go through an extensive beta… then inevitably hear about a show-stopping bug we introduced three hours after a release goes final. 😀 In contrast, providing a (major-version-stable), transparent copy of CEF costs us very little dev time; time that would otherwise be spent maintaining the XPLM API can be spent on, like, major features.

* Aside: This is actually how we test a lot of new tech in X-Plane: we find a single, relatively out-of-the-way place to make use of it, ship it in a major version update, and wait to see if it blows up. Betas catch a lot of bugs, but not all, so this is a way of hedging our bets when it comes to code that hasn’t been battle-hardened. This is how we worked the bugs out of the user interface framework (Plane Maker’s panel editor was the testbed), the X-Plane 11 particle system (behind the scenes, it was used for some very minor effects in X-Plane 10.51), and more.

Posted in Development, Plugins by | 48 Comments

Plugins: Do Not Register Drawing Callbacks That Do Not Draw

Plugin developers: the title says it all – don’t register a drawing callback that doesn’t actually draw anything.

When I write it like that, it sounds a little bit silly, but some plugins register a drawing callback on startup, because they might draw something – but then only do the drawing when certain things happen. I am guilty of this myself – libxplanemp registers its drawing callbacks at init time even if there are no multiplayer planes to draw.

Most plugins did this for simplicity and to avoid any strange rules about when you could register things – the original 1.0 SDK was a lot pickier than what we have now. And back in 1537 when the French invaded Flanders, the cost of a no-op a draw callback was pretty cheap – just the cost of the function call-out and a few instructions of book keeping.

Over time, as X-Plane’s renderer has become more complex, this has become not the case. X-Plane now does some significant work to save and restore GL state when we hit a drawing callback, and that overhead is going to become significantly more expensive when we move to Vulkan/Metal.

To optimize this, Tyler modified the drawing callback code in 11.10 – starting with 11.10 if we find that no plugin has registered a given drawing callback, we skip the entire process, including the OpenGL book keeping.

So if your plugin goes in and registers a callback for every single drawing callback type then we have to fall back to the slow path, carefully stashing our GL state and prepping for your running at each drawing callback point.

Here’s my guidance:

  1. Never register for a drawing callback you’re not going to use.
  2. Do delay registering for a drawing callback until it is possible to need it.
  3. Don’t try to optimize your drawing callbacks by registering and de-registering per frame.

So as an example, it would be reasonable for a multiplayer API to register a drawing callback when the first airplane enters the system and then keep it around until the last airplane goes away, even if that airplane is off screen.

(The reason for that last rule is: if we have to make an expensive graphics transition once we discover that drawing callbacks will be needed, we don’t want to get thrashed by drawing callbacks disappearing and then re-appearing over and over.)

Posted in Development, Plugins by | 13 Comments

Manipulators and VR Part 1: From Mouse to Mechanism

For airplane authors, the biggest question VR brings up is: what do I have to do to my aircraft to make this work? This is the first of three posts explaining not only how manipulation works with VR, but why we made our decisions and how we got here. Bear with me – this will end with specific recommendations for what to do with your aircraft.

A Long Time Ago…

Old-timers like me will remember that when the 3-d cockpit first came out, almost all of the “brains” of it were powered by clicking on the 2-d panel, which was “mapped” to the 3-d cockpit.  X-Plane would find out where your mouse click intersected the 3-d cockpit, find the texture location on that triangle, and map that back to the 2-d panel.

This seemed pretty cool when it came out 15 years ago, but as authors started making more sophisticated 3-d cockpits, it became clear that we needed a way to specify how the mouse worked directly with the 3-d cockpit shape, because the mapping back to the 2-d wouldn’t allow the user to do basic things like dragging a throttle.

Thus in X-Plane 9 we added the first set of manipulators – tags on the 3-d mesh of a cockpit specifying what happens when the user clicks on it. The manipulator could specify a dataref to modify, a command to actuate, and some data about what kind of mouse click operation was happening.

The key words here are mouse click. The original manipulators were designed entirely in terms of a mouse on a 2-d screen; they were designed to be exactly as powerful as a 2-d panel system, which was of coarse also totally mouse-centric. The relationship between the generic instruments and the original manipulators is pretty tight.

Moving to Mechanisms

The good part of the original manipulator system was that it was very flexible – mouse-centric handlers were a low level tool around which authors could do whatever they wanted.

The down-side of this design was that mouse-centric handlers were a low level tool around which authors could do whatever we want. We examined our own default fleet of a dozen or so aircraft and found that no two aircraft’s cockpits operated the same way, and almost all of them had at least some aspect that was hard to use – a poor manipulator choice for the job.

Knobs were, in particular, quite difficult – the original 2-d panel system used click-and-hold over a knob to actuate it, but authors working in 3-d had often used drag actions to do knobs, and the drag actions would respond differently depending on camera angle. We received approximately 8,452,124 bug reports that the knobs in the 747 were hard to use specifically because of this.

So during X-Plane 10, we added some new manipulators to X-Plane, and they had a very different philosophy: the manipulator described what was happening in the simulated aircraft, and X-Plane picked a mouse behavior to make that work. The new manipulators described knobs that turned and switches that either flipped left-right or up-down.  These manipulators reacted to the scroll wheel automatically because X-Plane knows what the knob is and therefore what a reasonable scroll-wheel interaction should be. (By comparison, with the old-style manipulators, the author has to specify what a reasonable scroll-wheel action is.)

Real Interaction Things Before It Was Cool

As it turns out, mechanism-centric manipulators are a lot better for VR than mouse-centric ones. Consider two cases:

  • The 2-d axis manipulator (ATTR_manip_drag_xy) specifies what happens when the mouse moves up-down and left-right, relative to the screen. What on earth does that mean in VR? Even if we made something that tracks up-down and left-right relative to the screens of the HMD, the results would be completely weird because the “thing” in the cockpit would not move the way your hand was moving. With a mouse, a mis-match between mouse and aircraft isn’t surprising, but in VR, it’s weird to reach out and touch something and have it behave the wrong way.
  • The knob manipulator. It describes a knob that does things when turned clockwise or counter-clockwise.  This is pretty easy to deal with – you click it with your controller and turn your wrist clock-wise or counter-clockwise and it turns.  Because we know what the mechanism is (and not just what the mouse should do) we can make a good decision about how to handle this manipulator in VR.

As it turns out, we ran into this problem of not doing what to do with the mouse, and needing to know what the mechanism was before we even started looking at VR. The exact same problem (“I want to touch the 3-d cockpit as if it was a thing and have it respond in the expected way”) exists in VR and on X-Plane Mobile!

Because X-Plane mobile runs on a touch screen and you have your physical finger on a switch, there are a lot of cases where the switch has to track really well and work the right way.  If the switch goes up and down, you want to flick your finger up to turn the switch on; if it goes left-right you want to flick left and right, and anything else is astonishing.

So X-Plane mobile set us on this path toward mechanism-based manipulators, and VR further drove us in that direction, since both have the same physical, non-mouse environment where a user directly interacts with the 3-d cockpit.

Guidance For Authors

So as an author, what should you do when working on a 3-d cockpit? My answer is: use some of the manipulators, but not others, to model the way things work in 3-d.

Use these manipulators ALWAYS

These manipulators are the best way to create certain physical mechanisms – use them every time this case applies to your aircraft.

ATTR_manip_drag_axis. Use this for a physical mechanism that slides along a linear path, like the throttle handle of a Cessna.

ATTR_manip_drag_rotate. Use this for a physical mechanism that rotates around a fixed point, like the throttle handles of a 737, or a trim wheel.  (Prefer this to the old technique of putting a drag axis along the edge of the throttle handles.)

ATTR_manip_noop. Use this to make a manipulator that blocks the mechanism behind it from being touched, e.g. the safety guard plate over a switch.

ATTR_manip_command. Use this for push buttons that actuate momentarily while a button is held down, like a button to motor a starter that you push in and hold down.

ATTR_manip_command_knob, ATTR_manip_command_switch_up_down, ATTR_manip_command_switch_left_right. Use these for knobs and switches with 3 or more positions that rotate or move. Pick the right manipulator for the mechanism!

ATTR_manip_axis_knob, ATTR_manip_axis_switch_up_down, ATTR_manip_axis_switch_left_right. These provide an alternative to the above manipulators when you must use a dataref. We recommend commands over datarefs any time you have a choice; the command system provides better interoperability between custom plugins, custom aircraft, and custom hardware.

ATTR_manip_command_switch_left_right2, ATTR_manip_command_switch_up_down2, ATTR_manip_command_knob2. Use these for knobs and switches with exactly two positions. You can use these to get a simple click-to-toggle with the mouse (quicker and easier for mouse users) while getting real 3-d movement in VR.

Use These Manipulators Sometimes

These manipulators are not perfect fits with physical motions and may require tweaking for VR, but they’re the best options we have now for certain problems. Try to use something from the always list instead if you can. Do not use these manipulators if the mechanism you are simulating matches something from the list above.

ATTR_manip_drag_xy. This is the only 2-axis drag we have, and is the best choice for eye-ball vents and the yoke. The yoke is special-cased in VR and should be based off of a 2-d xy manipulator. We are looking into more powerful multi-dimensional manipulation in VR, but this work won’t be complete for 10.20.

ATTR_manip_command_axis. This manipulator runs a command once based on moving a lever down or up. You should probably use a drag axis or command up-down switch, but there may be some odd mechanisms in aircraft where this manipulator is a good fit. It should not be your first-choice go-to manipulator.

ATTR_manip_push, ATTR_manip_radio, ATTR_manip_toggle. These manipulators can serve as alternatives for push-button style controls when you absolutely have to write to a dataref and not use a command.  WARNING: Do not ever use these manipulators for things that move, e.g. don’t use these for banana switches, spinning knobs, or things like that.

Do not use these manipulators

These manipulators were for mouse-centric movement and should be replaced with knob or switch manipulators.

ATTR_manip_delta, ATTR_manip_wrap. These were designed to simulate knobs by click-and-hold – use the knob manipulators instead.

ATTR_manip_drag_axis_pix. This was designed to simulate a knob by click-and-drag – use the knob manipulators instead.

We Love Commands

As you may have noticed from this list and the ever-growing size of X-Plane’s built-in command list, we love commands – they have become our go-to mechanism for our aircraft. Commands have a few advantages over data-refs:

  1. There is a clear design in the plugin system for changing a command’s behavior. So a third party aircraft can easily “take over” the existing engine start command.  This is very, very difficult to accomplish via datarefs.
  2. Commands can be mapped directly to joystick and keyboard hardware. There is no way to bind a joystick to a dataref.*
  3. Commands can be mapped to sound to capture the act of the user “doing” the thing, regardless of whether it works. For example, if you want the click of the starter switch regardless of whether the starter motor engages (maybe the battery is dead), commands make this easy to do. Often there is no dataref for ‘the user is trying but it’s not working’.

In X-Plane 11 we’ve been moving to commands to get our planes ready for VR, the new manipulators, and FMOD sound all at once.

In the next post I’ll cover some of the issues specific to VR and the 3-d cockpit.

 

 

* Developers who write plugins that provide external interfaces to X-Plane: make sure you have a way to provide access to commands and not just datarefs!  There are things you can do only with commands and not datarefs.

Posted in Cockpits, Development, Plugins, VR by | 12 Comments

New Plugin Packaging for the SDK 3.0

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.

Posted in Development, Plugins by | 10 Comments

XPlane2Blender v3.4.0-beta.5 arrives

Download here:

https://github.com/der-On/XPlane2Blender/releases/tag/v3.4.0-beta.5

Change Log

New Features

Build Version Numbers

XPlane2Blender’s new version number system will allow us to debug .blend and .obj file even faster. It should also make making updates to the data model easier to implement.

  • Every exported .obj file’s footer contains information about the addon version, when it was compiled, and why. For example: 3.4.0-beta.5+1.20170922151901

A break down of the components

  • 3.4.0: The traditional Blend addon number
  • beta: The type of build cycle we’re in. Other choices you may see are dev (a developer build), alpha, rc (for full release)
  • 5: the build type version we’re on. Since this is beta 5, the build type version is 5.

The elements after the + are generally less meaningful to the average user

  • 1: The version of the data model (the properties and settings for XPlane2Blender, used for comparing changes
  • 20170922151901: The “build number” date this source code was packaged and released in the form of YYYYMMDDHHMMSS in UTC.
Communication

The build version number is partially shown (elements after the + are hidden) in the scene settings under Composite Normal-Textures, potentially along with warnings about the stability of the build you are using.

Examples

When starting this version of the beta, you will see this:
scene_version_comminucation

A future stable version of 3.4.0 for the general public will show this:
scene_version_communication_rc_ex
Notice the green check mark and lack of any warnings.

In a future pre-alpha cycle for 3.4.1, two types of people will see the following:
scene_version_communication_dev_ex

  1. A developer writing and testing unreleased code
  2. Someone who didn’t head the warning against using such code, or get scared off by the nuclear symbol and extra warning about a lack of a build number

It is the worst case scenario for stability and traceability, hence the nuclear symbol.

Why the extra warning about a lack of a build number?

A lack of a build number indicates that you do not have a good dialog (e-mail, chat, this release page, or other channels) with a knowledgeable and attentive developer. This means your work is more likely to be run through a bad version of the code and damaged, or your bugs will be harder to diagnose and repair.
scene_version_comminucation_rc_no_build_nmbr
In this case, despite the code appearing to come from a stable era of the code near a release, there is potential for something to be wrong and have very poor ways of tracing what it could be – hence the lack of green check mark and big red warning symbol.

If you see some new pre-alpha feature you’d like to try, just ask us about it first. Going forward, we want to start with a dialog about potential dangers, testing, and intentions of an incomplete feature rather than an autopsy later on. Don’t be scared, we always love hearing from users before there is a problem, not after!

Build Version History

Also, all .blend files will be keeping a log of every different version of XPlane2Blender that they are opened and saved with. This is automatic and needs no involvement from the user. Those who are curious can look in the Plugin Development Tools section at the bottom of the scene settings and see the history of their file.

Note: This does not record any history data about Blender versions, other addon versions used, timestamps opened or saved, or changes made to it (including XPlane2Blender settings changes). It is purely useful as a debugging tool, and is not fool proof.
build_history

This .blend file started as a legacy 3.4.0 pre-beta.5 file, and was then with a copy of 3.4.0-beta.5, with no build number. Then it was used with 3.3.12, then finally, used with a build of 3.4.0-beta.5 created on 09/18/2017 at 01:27:30am.

One could use this information to guess what transformations the data could possibly have gone through along each step of its journey.

Posted in Development, Plugins by | 1 Comment

Plugin Compatibility and New XPLM 3.0 Features

Tyler posted about some of the new features coming to the X-Plane SDK version 3.0 API (available with 11.10 once we find the last bug and move it somewhere else). Here’s how compatibility works for the windowing system.

First, since the 2.0 SDK, XPLMCreateWindowEx has taken all of its arguments in a structure, a XPLMCreateWindow_t. That structure, in turn has a structSize variable that is meant to be initialized like this:

XPLMCreateWindow_t my_win = { 0 };
my_win.structSize = sizeof(my_win);
my_win.froblinator = xplmFull_Of_Eels; // etc.
XPLMCreateWindowEx(&my_win);

Now when we revise the SDK, the size of the XPLMCreateWindow_t structure grows when you #define XPLM300. This results in new plugins compiled with the new SDK sending in a large struct (with more callbacks) and older plugins compiled against the old SDK sending in a small struct.

This is how the SDK “knows” what SDK you are using and provides new behavior to new plugins but provides compatible behavior to existing plugins, compiled years ago.

(This technique isn’t in any way new or unique to the X-Plane SDK – you can tell by the coding conventions that it is cough, cough, borrowed from the Win32 SDK.)

Posted in Development, Plugins by | 8 Comments