Blog

X-Plane 11.20 Escaped Captivity

X-Plane 11.20 is, of course, final! Like all good Klingon software, it was not so much released – rather it escaped captivity, leaving a trail of blood in the path of all whom opposed it.

I am aware of two plugin-related issues we are tracking:

  1. Some legacy plugins with widget UIs are missing buttons when the UI is at 150% or 200% scaling. We have a fix for this, but for now you can work around the problem by turning off UI scaling in the graphics settings tab.
  2. Some Mac plugins compiled against libstdc++ crash with the Steam version (but not the non-Steam version).

Philipp and I are still discussing what to do about this second thing, but if your plugin is in this category (so far we’ve seen it with HeadShake and X-Ivap), my suggestion is: compile and link against clang’s libc++ on OS X – it’s the native Mac C++ runtime and the one that’s going to work well in the long term.

We’ll release an 11.21 release candidate either late this week or early next week, once we collect the bug fixes that got away.

EDIT: HeadShake has been fixed by SimCoders!

Posted in Development by | 26 Comments

Better Fuselage Dynamics Through Science

It turns out that my teachers in college, a ton of engineering textbooks, and the internet in general all seem to understand what wings do. Also my airplane has wings, and those wings are designed to interact with the air as much as possible, so I can flight-test my airplane at any time (and I constantly do) to collect information about what the wings in said airplane do. And then I use the information from the several sources listed above to really dial in the flight dynamics in X-Plane. Without question, on my death-bed I will look back on my many flights flown while frantically scribbling down notes and flying the airplane at the same time fondly. This is a challenge that not enough people get to enjoy, and then turning that knowledge into a simulator that then turns into money for me… well, let’s just say I have very little to complain about. Read More

Posted in Aircraft & Modeling by | 29 Comments

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

Meet the X-Plane Team at FlightSimExpo

X-Plane will be attending FlightSimExpo 2018 in Las Vegas, NV on June 8-10. Nearly the entire team will be there–they’re even letting me attend this event!

Members from the development team, such as Austin Meyer and Ben Supnik, will be presenting the latest news and behind-the scenes-information on our work on X-Plane on Saturday, June 9 at 10:15 am.

We’ll also have a booth open all weekend so you can stop by to say hello. Add-on developers should come by and pick our development team’s brains while we’re all in one place!

 

Posted in News by | 16 Comments

Deleting Your Missing Scenery Packs Is Not a Bug (But Is Kind of Dumb)

We received a last minute bug report that X-Plane 11.20r2 deletes scenery packs from scenery_pack.ini. This is true! It is also by design, not a bug, the same as X-Plane 10, and not particularly brilliant on my part.

scenery_packs.ini persists the order of your packs (putting newly discovered packs “in front” in alphabetical order upon discovery) and maintains enable-disable status. But it does not retain any other information. The file is totally rewritten on every run and the following otherwise useful stuff tends to get destroyed in the process.

  • Comments and notes to yourself
  • Whitespace and formatting
  • Any scenery packs that can’t be found

Unfortunately this means that if you symlink to an external drive that is unmounted and run X-Plane, your scenery pack order gets lost. This definitely does suck.

In a future version, I can fix this. But we’re not going to mess with it now during RC because it’s totally not changed or broken compared to all past versions of X-Plane since we introduced the scenery_packs.ini file.

For now: you can lock the file as a hack-around to preserve your well-created order while your remote drive is unmounted – when you re-mount and restart, your order isn’t lost. But in this order, new packs aren’t persisted to the file, although they will be used.

If there’s things you want the scenery_packs.ini file to do, commenting on this post would be on-topic. One thing to consider: if we can’t drop missing packs, how do we know a pack was uninstalled? How does the file ever get cleaned?

Posted in Development by | 44 Comments

X-Plane 11.20r2 Available

X-Plane 11.20r2 is up – we’re just killing off the last show-stopping bugs – full notes here. Steam build should be available Real Soon Now™ – it’s already uploaded and just waiting to make we didn’t blow something up.

Posted in News by | 29 Comments

X-Plane 11.20r1 Available

Before Ben left on his family trip (and he was very adamant that it was not a “vacation” because the kids were going along) we got an X-Plane 11.20r1 build ready for possible release this week. Tyler and I must feel lucky because we’ve gone ahead and pulled the trigger to make this build public now.

This means that we need you to test your add ons now–seriously we mean it–speak now or forever hold your peace. All our features and changes that are going in 11.20 are in*, and the only changes we will put in from here on out are any regression bugs you bring to our attention. Read More

Posted in News by | 75 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