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.
First, thanks to everyone who has filed bug reports for the first X-Plane 11 public beta. One of the reasons to have a public beta is to get information about bugs that we don’t see “in-house” (e.g. literally in-house since everyone at Laminar Research works at home). We’re still a small company with a limited number of total computers, so feedback from the field is critical to us.
This post will list the status of a few of the more common issues that we have seen reported in the public beta that will be addressed in beta 2, which should be out next week.
Installing More Scenery: the X-Plane 11 installer had a bug that would cause it to hang when adding and removing scenery; this is now fixed! Download a new installer from our website and you’ll be able to edit what scenery is installed. The new installer is version 4.01r1.
I Can’t Type My Product Key: a small number of users have reported the product key entry field freezing in the installer. This appears to be tied to a specific GPU (the Intel HD 520) and possibly to specific drivers. If you see this bug, please contact tech support; we don’t have this hardware, so we need people to help test a fix. (Intel GPUs present a particular problem because you can only get them with a new motherboard; you can’t just drop a new GPU into a PC.)
Out-of-Date Nav Data: this isn’t really a bug; the FMS will (correctly) tell you that the sample nav data that ships with X-Plane is older than the current AIRAC cycle. You do not have to buy a navigraph subscription to fly; simply press “clear” on the FMC keypad to get rid of the message.
Crash After GPS/FMS Flight: fixed for beta 2!
Sparkling Cessna VOR Gauges: NVidia users reported all sorts of sparkly strange artifacts on the VOR steam gauges; this was caused by degenerate UV maps in the 3-d model. This is a subtle problem that artists sometimes hit,so I’ll write up a separate blog post for modelers on how to avoid this. Beta 2 will fix this, and the sim now features a new debugging mode to help artists detect this case.
Purple Planes: (or other colors in Plane-Maker) – that’s what uninitialized memory looks like in your GPU – fixed for public beta 2.
Wrong Joystick Configuration: Tyler has fixed a ton of bugs for this; we’re programming beta 2 to ignore beta 1’s joystick preferences; this forces everyone to recalibrate and ensures that the misconfigured prefs from beta 1 don’t stick around and cause further confusion and bug reports. Once we have stable joystick configuration, we won’t have to do this anymore.
Transparent Panels in Third Party Planes: I removed a v10 legacy code path from v11 that, as it turns out, everyone still needs – it’s back for public beta 2. I’ll write more about this in a separate post, but for now v10 aircraft should look less strange than before.
Supported Hardware: Beta 2’s diagnostics for what hardware is supported should be a lot better than beta 1. If public beta 2 tells you your hardware isn’t supported but beta 1 worked without hacking (E.g. command line work-arounds, OpenGL interceptors, ignoring the fact that everything on screen is pure red) then please do file a bug – it’s important feedback.
Threaded Nvidia Driver: I now know what you have probably known for a while: you have to turn the multi-threaded driver option off on NVidia hardware for X-Plane to function well. What is happening is: X-Plane is launching enough threads to use all of your cores for background processing, water processing, scenery loading, etc. and then the threaded driver is launching more threads. The result is too many threads fighting for too few cores.
What is astonishing here is how bad things get – when my i5 gets into “slow” mode with too many threads, it goes from 34 fps to 4.3 fps! I expected a slow-down proportional to the overloading of the cores plus a little bit of overhead for all the thrash. What actually happens is a lot more like “the machine grinds to a halt”.
Bottom line: the multi-threaded driver should be off – like you are already doing. I am looking at whether we can programmatically set this from within X-Plane.
Beta 2 should be out within a day or two – we’re working on final touches now. There are more bug fixes not listed here, and more bugs being fixed that aren’t in beta 2, and more bugs that aren’t fixed yet, so please be patient – we’re squashing bugs as fast as we can stomp.
Today X-plane 11 went public beta! Here’s what that means:
Anyone can get a beta copy of X-Plane 11. You don’t have to be in our private beta program, you don’t have to have a special beta key, you don’t have to sign an NDA. If you want to try the public beta, go ahead.
Users who pre-purchased X-Plane 11 can use the full simulator; users who did not can use the demo.
X-Plane 11 is still quite full of bugs. That’s why it is labeled as a public beta and why the release notes list a number of known open bugs.
So at this point we are in a situation that is not that different from a regular public beta. If you want to try the new stuff, you can do so, but if you want to get flying, you may need to wait for a later beta. Bug reports can be filed in the bug report form,
I’ll post more in the next few days, but for now if you email and don’t hear much back, please bear with us – a major release is like a flood, and everyone’s in-box is buried right now.
Starting with X-Plane 11, all aircraft must be installed in a folder within “Aircraft”.* We’re taking this opportunity to normalize where Aircraft are installed (all other files have to go in ‘the right’ folder, e.g. Weapons, Airfoils, Custom Scenery, etc.). This will let us search a much smaller footprint of files to find installed aircraft, which speeds up the UI.
Our aircraft are in a folder called “Laminar Research” within Aircraft; my suggestion is that vendors (and a lot of you are already doing this) have your own folder in Aircraft where aircraft go.
The goal is to have a file structure where it is not necessary to reorganize where files live or deconflict, so that automatic updaters (ours and third parties) can find the files they installed. The old folders-with-categories-of-aircraft are now gone.
You can make any set of folders within Aircraft you want, and when you search in the UI, you can search by folder names. But we also provide a bunch of other ways to find aircraft, e.g. type, studio, number of engines, or file name search.
*If you thought X-Plane already required it, well…nope – X-Plane 10 will load an aircraft anywhere in the X-Plane folder. This is only true for Aircraft – everything else has to go in the right bucket.
There’s an old joke in finance: if you owe the bank $100, you have a problem. If you owe the bank $100,000,000, the bank has a problem.
This holds true for X-Plane add-ons: if one-add on has a problem, it is the add-on maker’s problem if the add-on stops working. But if every add-on has a problem, we have to change X-Plane to solve the problem. This is what happened with SASL/Gizmo and the 64-bit move: we built 64-bit Lua support directly into X-Plane so that LuaJIT (which is used in most major aircraft add-ons for X-Plane) would keep working.*
This brings me to what might be my least favorite dataref ever: sim/weapons/x (and friends).
The sim/weapons datarefs gave you access to various flight-model data of 25 weapons attached to the user’s plane in X-Plane. The array dim doesn’t make a ton of sense – the last entry is an unused dummy slot for Plane-Maker editing and should never have been exposed.
What if there are no weapons on the aircraft? It turns out that variable behind the dataref would sit there and do nothing, so authors used these as “scratch pad” datarefs to implement cockpit tricks on aircraft that didn’t use weapons.
“Gave”? Yes, the past tense is intentional – virtually all of these datarefs are gone in X-Plane 11.
Now if reading this has caused you to hyperventilate, stop and read the dumb joke at the top of this post again. If you were the only add-on maker who abused the weapon location datarefs for misc cockpit data, I’d tell you that you did a dumb thing and you should go fix your add-on.
But as it turns out, many add-on makers all did the same thing, so in X-Plane 11, the location datarefs point to dummy variables that continue to provide the same behavior for aircraft with no weapons. So add-ons using weapons for scratch-pads can keep doing this for a bit.
What Happened to Weapons
For X-Plane 11 we have a fairly major internal revision of the weapon system, a hybrid** of the X-Plane 10 desktop and X-Plane 10 mobile weapon systems. The internal changes were significant enough that the old datarefs do not work and would need to be completely re-engineered in a backward compatibility layer.
What We Need To Know
If your add-on uses weapon datarefs other than X, Y, Z as scratch pads, please email me a list of the other sim/weapons datarefs you do use, so we can increase the amount of scratch-pad stuff.
If your add-on uses the weapon datarefs for some actual intended purpose, please email me and let me know what you were doing. Providing dataref backward compatibility isn’t out of the question, but it’s not something we want to do unless there is a real demand for it. The old weapon datarefs were part of Sandy and me just dumping everything into datarefs, so my guess is that a lot of the data in there is of no use to anybody.
Don’t Abuse Datarefs
I’ve said this before and I’ll say it again: do not abuse datarefs. If something appears to be unused, that does not mean “dump random data into it.” Use a dataref for its intended purpose only, and write values that make sense given its docs. If the docs don’t say what the dataref is for, back away slowly.
What if you need more dataref storage? For X-Plane 11, my recommendation is XLua.*** X-Lua is an extremely simple, portable, light-weight plugin to run Lua scripts that lets you create new datarefs and commands, and interact with the sim. Our art team uses it to do animation behaviors in the cockpit that are too weird to put into X-Plane itself. Once X-Plane 11 is out we’ll make an official binary distribution of XLua in case people want to use it.
* This isn’t a perfect example because we also had to do this work ourselves because 64-bit LuaJIT support can only be implemented in the host app, not plugins.
** This hybrid still has some rough edges from fusing the two systems together, and is not always described charitably within the company. You can think of it as one of those alien-human hybrids from X-Files.
*** Why XLua and not Gizmo or SASL? If you were using Gizmo or SASL you wouldn’t be saying “but I need more dataref storage”, you would have already made your own. So XLua addresses the authors who don’t need/want these heavier, more complex plugins that are aimed at larger scale add-ons.
