We posted an X-Plane 11.01 release candidate today.
The good news: it fixes the XPLM navigation buffer overruns that were crashing plugins. So that should be a big win for people using plugins with the beta.
The bad news: we found and fixed the flashing cloud shadows bug after the RC went out.
So we’ll do an RC2 with the cloud shadow fix over the weekend. We have a bunch of bugs we kicked to an 11.02, so that we could get the 11.01 fixes to everyone. We’re also looking to make WED 1.6b2 uploadable to the gateway so we can push out more gateway airports.
X-Plane 11.0 shipped with all new Physically Based Rendering – the lighting and material model is based on the real physics of light interacting with dielectrics and metals (kind of) to make rendering look more realistic with less art tuning.
But…X-Plane’s night lighting in X-Plane 11.00 is not physically correct – the night lights ignore the materials and do what X-Plane 10 did.
X-Plane 11.01 betas fix this. In the pictures below you can see side-by-side comparisons of the same scene with the 11.00 lighting and the new physical night lighting for 11.01. The array of balls floating around the Cessna is a test project I use with a 2-d grid of materials (metal on the bottom, rough on the right).
Materials 11.00
Materials 11.01
737 11.00
737 11.01
737 beacon 11.00
737 beacon 11.01
747 11.00
747 11.01
One of the effects of this is increased accuracy of light location – that is, you can really tell where the lights are by the reflections they cast on specific materials.
Here are some material comparisons with the day seen included so you can see what the original materials were. Observe the rim of the engine cowlings on the 737 and 747, and of coarse the entire fuselage on the MD-82.
737 Day
737 11.00
737 11.01
MD-82 Day
MD-82 11.00
MD-82 11.01
747 Day
747 11.00
747 11.01
There’s no authoring change needed or work to do for third parties – if you were modeling your aircraft to look correct during the day, 11.01 makes the night lighting look better.
X-Plane 11.01 beta 1 is out now – to get it you have to check “get betas”. Since we now have a stable release version, my suggestion is: don’t check the box unless you are an add-on developer or are willing to deal with some beta-crazy. We try to make sure that every beta works, and things are less crazy here now that 11.00 is out, but you can read the release note history and see that dead betas still happen regularly.
Linux Users: if you use the Aerosoft DVD and have been using the special posted build of the sim to unlock the DVD, please use 11.01 beta 1 – the Linux fix is incorporated.
I’ll post some pics of some of the graphics changes in 11.01 in another post.
A note on the various SDKs: we made a real push to get the various authoring SDKs stabilized for 11.00, but there were things we missed. Most of the authoring SDK changes in 11.01 are:
Removal of old datarefs and features that didn’t work anyway and hadn’t been “cleaned out”.
One exception where an authoring rule is actually changed: during the betas and in 11.00r1, the prop disc is blended using incorrect gamma, matching X-Plane 10 behavior. Not changing this was an accident; all other alpha blending in 3-d is gamma-correct in X-Plane 11.
For 11.01 I chose to change the prop disc now to make everything completely consistent across all interfaces for the rest of the X-Plane 11 run. This isn’t ideal, but running the prop discs with incorrect blending would be a performance penalty for the entire rest of the version run (we’d have to change rendering passes in Metal/Vulkan to support this) so I figured best to rip the bandaid off quick.
As with all gamma-correct blending, the most likely problem with this that the mid-alpha parts of your texture appear too bright in 11.01b1. Incorrect blending loses energy, so the natural authoring work-around is to make things too bright to compensate; now that you are seeing too much light energ you may have to back things off. Looking at our Cessna, the white paint on the prop disc is a little bit too bright with the change.
In other SDK notes: I’m part way through writing draft FMOD notes – one that’s done, Jennifer can turn that into something human-readable. We will probably do an 11.02 to collect gateway airports; WED 1.6b2 is out now but it’s not approved for gateway use yet; we’re waiting to get some test time on it. If 11.01 goes final before gateway airports can be pushed, we’ll do a separate patch to get those airports released.
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.
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:
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!)
Normally we try not to pre-announce new features before they are complete, but it’s been kind of an open secret around the company that we are working on native VR capabilities for X-Plane. Austin mentioned it on a Facebook Live stream, and Chris posted pictures of un-boxing his OcRift and Vive.
So today I’m going to show you a sneak preview of something that I’m just too excited not to post: X-Plane 11’s new Pirate-VR™ mode*.
There are two major challenges to integrating VR with a general purpose flight simulator:
Performance. X-Plane typically runs at 30-40 fps on a high-end system on a single monitor. How do we render a stereo image to two eyes without cutting frame-rate in half?
Usability. How do users interact with the complex cockpit buttons and switches using 3-d “wand”-type controllers that ship with today’s VR head-mounted displays?
Pirate-VR™ mode solves both of these problems.
When rendering to the head-mounted display, we simulate an eye-patch over the left eye.
By blacking out the left eye, we are able to recover quite a bit of framerate and run a stereo render at over 40 fps; minor optimization should get us to something fluid for the HMD.
In Pirate-VR™ mode, both of your hands are replaced by large metal hooks. Since it is pretty much impossibly to safely operate the over-head panel of an MD-82 with hooks for hands, we can skip 3-d interaction testing on most of the cockpit, simplifying VR interaction quite a bit.
I can’t announce when Pirate-VR™ will ship, but for scallywags who will be joining us at FlightsimCon in Hartford** this year, I think we’ll have something you’ll really want to get your hooks into.
* Yes, it is, of coarse, pronounced “Vee-ARRRRRRRRRR!”
** Update: my wife points out that the correct pronunciation is HARRRRRRRRtford.
X-Plane 11.00 is out! Release candidate 1 is it. It’s out the door!
If you’ve been waiting for Steam – you can now get X-Plane 11 on Steam.
If you already own X-Plane 11 from our website and you had installed the release candidate 1 patch a day or two ago, there’s nothing new to download – you have the latest version of X-Plane, and it won’t auto-prompt you until we have a patch.
If you’re waiting on DVDs, the materials have been sent off to the duplicator, so my totally-uninformed-guess is maybe a week or two.
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.
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:
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.
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.
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.
