X-Plane 11.0 public beta 14 is out. This one is a bit of a two-steps-forward, two-steps-back. Some notes:
You won’t need a ton of thrust to start moving anymore – Austin was able to remove that hack from the tire model based on some new ideas for modeling low speed tire physics that get around a years-old problem.
The Cessna apparently wanders around the runway like a drunken moose.
Max’s new cloud art is in. Under some views and conditions, you may get significantly better performance.
Under other views, they may kill your GPU. I’m looking into this.
Most importantly, I broke Plane-Maker, so public beta 15 will be out in 24 hours, and I’m going to sit in the corner and have a time-out for a few minutes. If we have a fix for the Cessna in that time frame, we’ll ship both, otherwise I’ll get a patch out to fix Plane-Maker and we’ll get to tires soon.
The State of Various SDKs
SDK stands for software development kit, but the term is now used more generally for the various interfaces, tools, and file format standards to make add-ons of any kind for X-Plane, even if there is no program (software) involved. I’ve been getting a lot of questions about what’s safe to start developing on top of, and what’s going to be ready for third parties. Here’s a quick update on the status of some of the V11 SDKs.
FMOD + Sound
FMOD-based sound is one of the biggest new features for third party developers in X-Plane 11. Here’s the status:
FMOD support is feature complete in public beta 14. Therefore we expect to have X-Plane sound “third party ready” by the time we go final with 11.0.
There’s a lot to document about FMOD. I have already started the beginnings of full documentation, but it will take time to get it on paper. I’m hoping to have draft FMOD docs that you can use shortly after we go final.
There’s a lot of details to get right in making an FMOD-enhanced aircraft; please do not ship an FMOD-enhanced aircraft before the docs come out – there’s a very high chance of doing something wrong if you’re just trying to guess how the system works from our Cessna project.*
When we ship, we will have bare bones tools for working with FMOD, but we will publish everything we had when we did the Cessna, and this setup is adequate for creating production aircraft. Fortunately, most of the work is done in FMOD Studio, a rich, full featured sound editing environment. It’s great to use.
The ‘thin’ side is X-Plane support: the sound attachment file (.snd) that links FMOD events to your aircraft has to be built in a text editor. We also have some graphical debugging and it is possible to attach a live mixer to X-Plane while you fly. All of this will be covered in the docs.
In the long term, we’d like to make the sound attachment system visual and have it run inside X-Plane while you fly.
What you can do now: learn how to use FMOD! Download the FMOD studio editor (it’s a free download) and start working with its sound design tools.
Graphics – Aircraft, Scenery and Modeling
I still have a list of graphic artifacts, but I think the overall operation of the new lighting system is as it will be for shipping 11.0. You can start using the new material model now; until the exporters have direct support, you can always add the NORMAL_METALNESS directive by a text editor or add it to a PNG comment.
Probably the biggest weakness of the new lighting model right now is the lack of detailed control over the interior of aircraft; I expect we’ll have new techniques to cope with this in future updates, but they won’t be mandatory aircraft changes. Unfortunately I don’t have good work-arounds right now for aircraft where the interior lighting is unacceptably weird.
What you can do now: tune the brightness and alpha levels of translucent textures – they need to be adjusted for X-Plane 11’s linear blending. Fix any panel problems introduced
Aircraft Physics and Systems
One of our biggest pushes right now is to try to get to “done” on the aircraft physics and systems code. The engines should be done – we don’t have known open bugs. The tire modeling is still problematic as of public beta 14; Austin has a fix for the bad behavior of the Cessna in beta 15.
What you can do now: test your aircraft’s physics model with X-Plane 11. If you have a fleet of aircraft, pick one particular aircraft and carefully update it for X-Plane 11. If you find out that there’s a physics problem after we go final, we’re going to have a lot less flexibility to fix things.
We run the physics engine on our own fleet (and we don’t use plugins to modify the physics) but that’s a limited set of aircraft. If you have good data about how your aircraft doesn’t work right with our flight model and good input data in Plane-Maker, we’d like to hear about it.
Weapons
The weapons SDK is the one area where we have moved temporarily backward from X-Plane 10. X-Plane 11 features a new unified weapons system that takes technology from both X-Plane 10 desktop (for physics) and X-Plane 10 mobile (for multiplayer simulation). Unfortunately, we haven’t had time to create an appropriate dataref interface to these weapons.
Getting the interface to weapons finished is on our short list for after 11.0 ships; I do expect that the list of datarefs may be different for 11.xx than it was for X-Plane 10. The new system has new capabilities that make the old “fixed index of weapons” model not a great fit.
Unfortunately, this means that if your add-on depends on plugin-controlled weapons, you’re stuck in a holding pattern until we can post a new interface that we can maintain.
Plugins
As of public beta 14, plugins should just work – we’ve closed the remaining plugin API and major dataref bugs. There are a few areas of fine print:
You can’t use drawing callbacks in the map in X-Plane 11 – the totally rewritten map doesn’t use the same coordinate systems, so there is no way we can make old code work.
Some datarefs and commands are not available in X-Plane 11. This is a normal part of the evolution of the sim.
Multi-monitor support has a pile of bugs when you put X-Plane’s menu bar on the second monitor. If your plugin works normally except in this condition, it’s probably an internal X-Plane bug you’re seeing.
Note that to control toe brakes in X-Plane 11, you now need to set an override. Once you do, you completely own the toe brakes – you can look at the raw joystick input datarefs if you want to write a plugin that “processes” toe brake inputs to create some kind of effect.
What You Can Do: Check the command and dataref lists that are in Resources/plugins. If you need a command or dataref that has been dropped (and is not weapons related), contact us to discuss your use case and we’ll figure out what to do. If you are still seeing plugin bugs, file them now!
What we will not have done for 11.0 is entirely new plugin functionality to expose new X-Plane 11 specific features. We will need to do a major API revision to allow plugins to undock windows (like our GPS and map does), to expose some of the new FMS capabilities (expect a limited API) and to restore map customization functionality.
Particle FX
The particle system SDK is kind of done, mostly. We use it in the shipping mobile product, and the editor is available in the desktop product now. I still have two features left to do that Austin considers “must-have”; I expect to get them in shortly after we go final, at which point we can start providing documentation. (One of those features is the ability to control aspects of the particle system from multiple datarefs – that will change the UI enough that it’s not worth writing docs now and then changing them.)
My suggestion is to stand by on this – it won’t take that long to get the system to a “tinker with it” stage.
* I am quite impressed with how far some people have gotten without docs! But shipping an add-on that “seems” to work but violates the SDK rules makes a compatibility mess later.
X-Plane 11.00 public beta 13 is out, and hopefully it has restored engine operation that beta 12 broke. If you are developing an aircraft and your engines don’t work right in public beta 13, please let us know.
X-Plane 11.00 public beta 10 is out today – if you are an X-Plane 11 user, you should get an auto-update.
Linux Users: Beta 10 won’t run on Linux. Something went wrong with the build process, truncating the last 1/3 of the executable. I’ve been building X-Plane releases for over a decade now, and I have literally never seen this happen. I’ll get this fixed as soon as I can. In the meantime, you can download the correct executable here. You may need to chmod it to run it. Correct MD5 signature is 985dc19a246f303fbb0d484937cfab7c.
Update: Beta 11 is out and fixes the bad Linux version of X-Plane. If you hand-installed the fixed version, you’ll need to tell the installer to replace the previous version you downloaded.
As we get toward the end of the public beta program, one thing we’re trying to do is get our interfaces in order for creating airplanes and scenery with X-Plane. Beta 10 brings two new features for authors.
Metalness in Scenery. Finally, you can now use NORMAL_METALNESS in any art asset that uses the standard shader. That means facades, roads, forests, draped polygons, line-work, draped objects, and anything else I forgot can all mark their normal maps for the metalness work-flow and use the blue channel to specify the metal/dialectric property.
What about BLEND_GLASS? Sorry, not only is BLEND_GLASS limited to objects, but it is limited to objects that are attached to airplanes and set to glass-interior or glass-exterior lighting. Basically the airplane rendering code has a special “blending” pass that runs outside deferred rendering, only for glass, and only aircraft have access to it.
Someday we may have scenery-system access, which would let us finally solve translucency problems in control towers, etc., but until that happens, BLEND_GLASS simply won’t work in those cases. So that’s a scenery system extension for another da – it won’t be in 11.0.
One more note on the scenery system: When X-Plane 11 calculates the smaller mip-maps for a normal map, it will increase the roughness of a normal map’s alpha channel based on the bumpiness of the’s normals themselves. In other words, if you burn rivets into your normal map, it will mark those spots as rough in the reduced-res version where the normals aren’t visible.
This process runs on PNGs; you can also convert your normal map to an RGBA-format DDS and pre-build the mipmap chain yourself with DDSTool; if you do this, you can customize the roughness of the lower mips. If you find your bumpy models look “too shiny” from far away, this can help. If you find a case where X-Plane’s reduction doesn’t do a good job but your hand-built mipmap works well, please let me know!
2-D GPS Units
Public beta 10 features pre-made 2-d instruments for the X430, X530, and FMS CDU, all with the bezel and buttons attached and fully functional; simply drag them onto your 2-d panel and fly.
These new 2-d instruments exactly match the pop-up window versions of the instruments, and this gives you a way to customize the pop-up window’s appearance. Simply customize the 2-d instrument’s textures the way you would any other pre-made instrument, and the popup window will match its appearance. You can use this technique to customize the popup even if you don’t use the 2-d instrument on your panel.
We now have both 2-d and “screen-only” versions of both GPSes and the CDU. The screen-only version is meant for use in a 3-d cockpit, where panel space is only used for screens. The 2-d versions are meant for users building their own 2-d panels at home and as a way to skin the popup windows.
If you are building an advanced 2-d panel, you can either use the pre-made 2-d instruments or use the screens and build your own bezels out of generic instruments.
Plane-Maker 11.0 does not provide access to the legacy FMS and GPS – while they will work in v10 aircraft for compatibility, new aircraft must be authored with one of the new GPS or FMS choices. Our goal is to set a time-frame for deprecating the old FMS/GPS code and getting to an entirely modern GPS/FMS implementation.
Can I pop up my plugin windows? Not yet, and not for 11.0. This is a high priority for us for the next X-Plane SDK revision, but it isn’t quick to do; we need to write a bunch of new code to expose some of the new UI tricks to plugins.
Public beta 9 is now live – this should fix null texture crashes (we hope – if you still see one in beta 9, please do report it with log files!) and has a performance improvement we’ve been working on for AMD Windows hardware.*
10.52: We do have a back-port to X-Plane 10 for this fix; had we figured this out any later we probably wouldn’t have brought it back. I had 10.52 (which is just 10.51 with an external visual sync fix) staged on the servers when we figured out what to do for AMD cards. My new plan is to recut 10.52 with the AMD fix. This will probably not happen until at least mid February due to other deadlines that come first.
Physics: Austin’s flight model changes for bodies shadowing control surfaces is not in public beta 9; it should be ready for the next beta. While I don’t know exactly how much more beta we have, my hope is that we get to RCs in a few weeks.
Scenery: I have a mostly recut scenery set, but it still has one bad tile. Besides fixing the bad DSF tile, I am still working on how the installer will handle the update. Digital download customers will be able to download this updated global scenery; we are working to make the download separate from sim updates, so that you don’t have to download a 50 GB scenery update to get a 26 MB sim update.
The good news is: the new scenery set will meet our size requirements even with northern latitude included. So we don’t have to decide between DVDs and Alaska; we can do both.
Alpilotx also has an import of tall buildings outside the US from OSM – this is a really great improvement, particularly for European cities.
Servers: we moved the master copy of X-Plane to a new server, and we’ve gotten some reports of poor download speed from users. At this point we think that this is a temporary slow-down as the content delivery network re-caches the simulator, but we’ll keep monitoring the situation and work with our CDN provider if problems persist.
Clouds: I am still fighting with cloud performance, so this work is not in a public beta yet, because it’s not quite ready for prime-time.
* The short version, for OpenGL nerds, is that we’re using system memory and not an orphaned VBO, to source the quads for text. Because we draw a lot of text and the draw sizes are very small, we appeared to be exhausting the number of orphaned buffers the driver could provide, leading to stalls. I am working on a more advanced solution to the problem, but in the mean time, using system memory for small draws fixes the problem.
X-Plane 11.0 public beta 8 went up over the weekend. If you are seeing problems with the flight model, please report bugs ASAP so Austin can look at them! I think we are approaching the end of some major flight model updates; the last thing Austin is looking at is better body shadowing, which he will probably write up shortly.
Over the weekend, with the help of some very patient users, we found the cause of poor performance on some AMD hardware*. I have a prototype fix, and I hope to have it in X-Plane some time this week. This fix will only affect users who were seeing super-lousy performance on very light configurations.
In the most recent betas, the threaded driver no longer totally kills X-Plane performance. But it does still slow things down a little bit on some computers – I see 5% fps loss with the threaded driver on. My suggestion for now is: try it both ways and run with whatever works best for your machine; this bug is affected by both your particular CPU and the kind of work-load your settings induce in X-Plane.
I am still working on improving cloud performance, and a recut of the DSF tiles is rendering as I type. The first priority for the new DSF tiles is to fix blatantly broken tiles (e.g. YSSY) and get the file size down so we can put Alaska and friends back.
* I wouldn’t call the AMD problem a bug on either our part or AMD’s – it’s more in the category of “OpenGL makes no promises as to what might be fast, so app developers have to debug on all shipping hardware and try not to do painful things.
I would just like to add that this is one of my favorite WED releases not only because it’s a really strong release (we started with the goal of just supporting X-Plane 11 but ended up with fixes to long-time bugs, really solid validation, new authoring features for serious users, editing improvements, and complete support for the new X-Plane 11 apt.dat format) but also because of how little of the work I did. This release was a real team effort, with volunteers from the X-Plane community and LR developers all working on new WED features.
Framerate should be back to where it was in beta 3. Betas 4/5 were not deleting smoke particles, so over time the total number of particles in the world would grow indefinitely, until the particle system was using most of the CPU.
Flashing in the cockpit should be fixed. The environment maps for the new lighting use alpha in the interior render to indicate areas where exterior light comes through, e.g. the windows of the plane. Due to using the wrong variable, on every other recomputation of the environment map, the alpha channel would be left opaque, effectively covering the windows in black paper and darkening the cockpit.
Finally, perhaps most importantly, this beta features a rebuild of the XPLM, the DLL that loads plugins. Besides modernizing the XPLM to use the newest compilers, this rebuild fixes the interface with X-Plane for popup menus (needed to get menu check boxes and disabling to work) and for keyboard focus (e.g. so you don’t get two blinking insertion points at the same time when editing text in a plugin).
Plugin authors: the expected behavior for the keyboard in X-Plane 11 is:
You cannot get any access to the keyboard when X-Plane has a modal dialog box over the screen (E.g. free flight configuration). This matches X-Plane 10’s no-plugins-when-the-airplane-is-not-showing policy.
Plugin pre-window keyboard sniffers have highest precedence – with great power comes great responsibility – use them with caution.
At any given time only one of X-Plane or a plugin can have keyboard focus. So if you take keyboard focus for an XPLM display window or XPWidget, X-Plane’s floating UI (e.g. the flight planner window) will defocus. If the user re-focuses a flight plan window, you will have your focus removed!
Plugin post-window keyboard sniffers get keys when (1) a plugin window does not have focus and (2) X-Plane doesn’t use the keyboard for UI. X-Plane command bindings run last.
If you find a bug with keyboard focus and your add-on, please compare behavior in v10 and v11, and please be specific about what you are doing! Plugin keyboard handling can be very complicated and hard to tease apart.
Finally, based on data from Austin and Marty, I have slightly recalibrated the fog settings. The sim is now foggier in ultra-low visibility (think: RVR1000) and notably less foggy in intermediate (e.g. 10-15 sm) visibility. I am still looking at fog in ultra-clear days (e.g. 50 sm vis).
If you guessed “X-Plane 11.00 public beta four”, you are right. 🙁 I screwed up the shaders, and they work on AMD cards and OS X but not NVidia cards.
So: public beta three is the official public beta again, and we’ll have a new public beta five out tonight that will fix this.
If you got the broken beta four (in the hour it was out before we caught this) you can re-run the updater by hand and force yourself back to beta 3, or just wait for beta 5 and then let auto-update do its thing. Unfortunately there’s no work-around in-app.
This one is definitely a big omelette on my face; I regularly swap through all of the major driver stacks on my PC and Mac to try to make sure the shaders work everywhere. In this case, I had “one little last change” that I only tested in some places, and sure enough, it looked innocent, but failed only on the configs I hadn’t tested.
Update: beta 5 is out and works on NVidia Hardware – just run the sim and let it auto-update. Beta 5 does have interior cockpit flashing – until we fix this, you can set the reflection detail to its lowest setting to work around this.
Chris just released X-Plane 10.4 for mobile today, and it’s got something pretty cool that we’ve been working on for a while: complete interaction with the 3-d cockpit!
I worked on the original X-Plane app for the original iPhone with Austin years ago, and when we were working on this, I kept looking at the 737 on my iPhone 6 and thinking “this doesn’t seem real”.
It’s not that the 737 doesn’t seem real – it’s that it looks too real. I didn’t think we’d see this kind of detail on a mobile device.
Over the last year we unified the flight model and physics engine of the two products, and that makes this kind of update possible; X-Plane 10 mobile has been running the full X-Plane flight model, and now that you can touch the planes, you can see that all of those systems really do work.
X-Plane 11.00 public beta 2 is out. Full release notes are here – please do read them to see what is changed. For beta 2, the team closed 39 bugs (plus however many we fixed but screwed up the fix version or fixed but were never in the database), so we’ve tried to keep detailed notes but a lot changed.
As always, please report bugs to the bug reporter – this gets your report into the official triage process.
Please do not report bugs in the comment section – No one spends any time trying to gather bug reports from the comment section.
