Category: News

11.01 and Immediate Work

With X-Plane 11.00 out the door, we have a few immediate things we are working on:

X-Plane 11.01: I’m hoping to have it beta early this coming week. We’ll roll the Linux DVD bug fixes into it, as well as rendering bug fixes that didn’t make 11.00, and a little bit of cleanup of the aircraft SDK.

Almost everything for the aircraft SDK is harmless cleanup, but there is one change in 11.01 that really should have made 11.00: the gamma curve on prop discs is still not correct in X-Plane 11.00. I am going to fix that ASAP for 11.01 so that third party developers can have stability.

Like most gamma corrections, your old prop disc might be too bright (because the old alpha blending tended to lose energy). With energy conserved, you might want to tone it down a little bit. I think this is the only gamma change that “got away” but I’m still investigating various cracks and crevices.

(The 2-d panel and panel texture will continue to have its traditional gamma-incorrect blending, matching X-Plane 10, 9, 8, etc.)

Documentation: we have a lot to update; I’ll try to get on FMOD docs as soon as possible. The X-Plane plugin SDK website needs a serious overhaul and may be in “temporary” mode for a week or two.

Developer Support: Philipp and I have been flooded with emails and requests from third parties involving their add-ons. I can’t speak for Philipp, but I’m probably back logged an entire month. If you’ve emailed us with some kind of issue, please be patient – there are a lot of you and not a lot of us.

I’ll post more details on 11.01 when we get closer to a beta.

Linux and Aerosoft DVDs (and Fixed Apps)

Yesterday we received multiple reports that the Aerosoft X-Plane 11 DVD set does not work with Linux. It turns out that there’s something strange about how the DVDs are authored that makes the file names on Linux go all lower-case, which causes both the simulator and the installer to not be able to use the DVDs.

We have fixes for these problems that will be rolled into a new installer and the next update of X-Plane; in the meantime you can get them here for Linux now:

• X-Plane 11 Installer for Linux with DVD Fix.
• X-Plane 11 Application (Linux) with DVD Fix.

To install from the DVD, download this installer, run it, and insert your DVD, this installer from the net will install the contents of the DVDs normally.

Once you have installed X-Plane, replace your normal X-Plane-x86_64 app with the one attached here (placing the new app in your “X-Plane” folder) to run using the DVD to get out of demo mode.

You can use these two apps until we issue replacements; 11.01 should go beta early next week and contain “official” versions of these fixes, at which point you can just use the official version.

(Thanks to Daniel for his patience and helpfulness in trouble-shooting this remotely!)

X-Plane 11.0 Release Candidate 1….

…is available to test.  May the good lord have mercy on our souls.

I Wear My Sun Glasses at Night

And so should you if you use beta 16. X-Plane 11 public beta 16 is out now and fixes a whole pile of bugs. It also introduces one new big one: in HDR mode the overhead panel of the cockpit is totally lit up. Alex reported this to me about an hour after the beta went live; it’s caused by changing where in the drawing process the moon is drawn.

This will be fixed for a beta 17 in the next 24 hours; you can work around it by turning your effects down to medium. Please do not report this bug, as it’s already being fixed. (Do report anything else you find though!)

There are some things fixed in beta 16 though!

• Clouds should be faster. If you are having performance problems with the clouds, please re-report a bug against beta 16.
• We fixed a lot of bugs for authors. Third party developers: please read the release notes carefully – we’ve tried to document every change we’ve made. The new FMS should be a lot more compatible, as should various parts of the flight model.
• A number of rendering artifacts are fixed: sky banding, etc.

Beta 17 (to fix the lit up cockpit) will likely be the last beta of the X-Plane 11.0 series.

Trying To Solve Three Things At Once

We’re reaching the end-game with X-Plane 11.0 public betas. Right now I am working to try to solve three problems at once:

1. Users of the beta really want to see rendering issues solved ASAP. Besides the constant chorus of “you know your sky looks like hell” in the comments section, the cloud code has serious performance tuning problems that I have been working on. We definitely want faster clouds in the next beta so it is a useful beta.
2. We are trying to get the flight model locked down ASAP. We’ve received a number of really good bug reports in the last week and fixed a bunch of compatibility issues; the sooner we get those fixes out, the sooner authors can confirm their planes work.
3. There are some issues that really need to be resolved in 11.0 because fixing them mid-version (where backward compatibility requirements are much stricter) is a lot harder.

You can see where this is going – those things are totally at odds with each other. The longer we take to fix rendering artifacts, the longer aircraft authors have to wait for key flight model fixes. If we don’t fix cloud perf, the build isn’t useful. And if we go try to put more changes in (item 3) to get things fixed “at 11.0” we risk the flight model being more buggy.

I’ve sent private builds of beta 16 to third parties over the last few days in an attempt to confirm that we are fixing bugs and not creating them – my hope is that this will make beta 16 a much more usable beta and not a step backward. I also made some progress on cloud tuning last night; I don’t know if it will be the end of perf improvements for clouds but it should be a lot better. From the feedback I’ve received, the fixes from last night need to go out before we can tell what else is going wrong with cloud performance.

(Unfortunately there are a huge number of configurations that interact with cloud performance: number of monitors, resolution of monitors, FX level, reflection level, and position of camera, terrain type, cockpit and of coarse the weather itself all interact to affect final performance!)

I’m hoping to have beta 16 out Monday or Tuesday.

One Last Change

The changes to the flight model and systems code for beta 16 are all in the direction of better compatibility (e.g. they fix a bug new to X-Plane 11 or make X-Plane 11 more like X-Plane 10) with one exception: snapping of autopilot vales.

X-Plane 10 introduced a new, accidental, unwelcome behavior: it snaps certain datarefs (E.g. the autopilot VVI and altitude) to a fixed grid every frame. If you use DataRef Editor to set the autopilot altitude to 10,001 feet, it will jump back to 10,000.

The goal of this code was to allow panel knobs to freely spin an autopilot value for smooth animation – if the physical display in the cockpit is an animated mechanical roller, not snapping to the grid makes it look like it’s turning. When the user finishes spinning the knob, it “lands” on an even number like 10050 feet, just like the real aircraft would.

The behavior of always rounding the value to a nearest amount was an accident of how the code was structured. The down-side of this is that it makes it very difficult* for plugins to freely animate the dataref themselves, e.g. if the knob is being driven by a custom manipulator or command or some internal plugin path.

This rounding was new to X-Plane 10 (X-Plane 6, 7, 8 and 9 did not do this) but we kept it for the life of X-Plane 10 so that the dataref behavior would at least be consistent.

I have code that I am planning to put into beta 16 that puts the behavior back the way X-Plane 9 and earlier was: the value of these datarefs will be rounded to a grid only when Plane is done twiddling them. If you write to them with a plugin or manipulator, you’ll get exactly what you ask for – at least until the user touches a built-in panel instrument or command or some other pure X-Plane path.

This change is a little bit scary – there may be plugins or add-ons intentionally writing not-rounded values and counting on X-Plane to round them. This is a change that we can put in one beta and remove in the very next one if it turns out to cause too much chaos.**

But I am certainly hoping we can make the change – having X-Plane only round when needed makes a much better and more convenient interface for add-ons – add-on authors can get exactly what they want without having to wrestle with an octopus.

* Not impossible – just very difficult. To work around the problem, you have to inject your own values in a hook after X-Plane and manually track what the value should have been so that you don’t get fooled by X-Plane constantly snapping the value. There are a number of “unwritable” datarefs where you can write them by just shouting louder than X-Plane, but I strongly recommend against using this to make your add-on work. If you need to do this, contact us about what dataref you are fighting about – there might be a better way.

** This is going to be one of those cases where if one or two add-ons is broken by the change, we’ll declare it as “this is how X-Plane 11.0 is”, but if 100 add-ons are broken, we’ll put it back and I’ll have to go drown my sorrows. See also the usual joke about owing the bank $100,000,000.00 and all that.

X-Plane 11.0 Beta 14 and the State of Various SDKs

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:

1. 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.
2. Some datarefs and commands are not available in X-Plane 11. This is a normal part of the evolution of the sim.
3. 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.

Public Beta 10, Metal Scenery, and Painted CDUs

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.