X-Plane 11.20 Release Candidate 4
Fourth Time’s a charm. RC4 is out and and fixes issues with the 747 autopilot. Hopefully this one is a keeper. Steam build coming Real Soon Now™.
Fourth Time’s a charm. RC4 is out and and fixes issues with the 747 autopilot. Hopefully this one is a keeper. Steam build coming Real Soon Now™.
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
Third time’s charm? Maybe? RC3 fixes plugin issues we were seeing in RC2. Thanks to the plugin developers who tested our repaired XPLM DLLs yesterday. We’ll update Steam to RC3 soon if this build isn’t on fire.
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!
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!
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.
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?
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.
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
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.
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:
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
Doing so makes the X-Plane community stronger, and supports the creation of add-ons that might otherwise not have existed.
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. 🙂
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.
This is absolutely a concern for us. Webviews in X-Plane present two major attack surfaces:
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:
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.
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:
Plugin developers, Beta 5 includes a few new VR-specific APIs in the XPLMDisplay header.
The complete list of VR-specific APIs is now:
XPLMEnableFeature("XPLM_USE_NATIVE_WIDGET_WINDOWS", 1)I’ve updated the VR sample plugin to take advantage of all the new stuff here, minus the widget API—really, once you enable native widget windows, your widget window becomes “just another XPLM window” as far as the display APIs are concerned.