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.
OK the new engine modeling for X-Plane 11 is great, but what good is an engine to us pilots without a propeller?
X-Plane has historically done an excellent job of estimating the THRUST of propellers, typically to within just a few percent… but what about the SPIRALING SLIPSTREAM? This has been an area where X-Plane has been much weaker… I just don’t see any good solid references for determining the spiraling slipstream angles for propellers…
and it’s a real shame because the spiraling slip-stream hitting the vertical stab is so responsible for the left-turning tendency in single-engine props.
BUT, can we do better? How would we estimate the slipstream angle, exactly?
Well, as it turns out, there is a pretty darn cool way to do it, which is going into X-Plane 11 Beta-4: A spinning prop is just a spinning pair or trio or quartet of wings (as X-Plane has long understood) and those wings have LIFT and DRAG.
The LIFT from the propeller blade is referred to as THRUST. The DRAG on the propeller blade is what opposes rotation and makes them so darn hard to TURN. Read More
OK I overhauled and upgraded the jet engine model as well.
Here is how it works: For SUBSONIC dynamics, I curve fit maximum engine thrust ratio to static max thrust as a function of density altitude, Mach number, and engine bypass ratio. This is pretty easy and boring and I have been doing this for years.
But here is where it starts to get good: As the inlet is dragged by an over-speeding airplane above it’s critical Mach number, normal shocks will now form across the inlet, DECIMATING the efficiency of the engine and robbing you of thrust.
No arbitrary losses above your critical Mach number, the normal shock, only a few atoms thick, slows all air that hits it across the space of a few atoms, dumping a huge amount of the incoming streams valuable kinetic energy and turning it instead into HEAT.. the last thing you want coming into the front of your engine.
So that is for subsonic inlets being dragged above their critical Mach number. What about supersonic inlets?
OK this gets good: As we move through Mach 1, we transition from the subsonic curve fit for subsonic engines to the pressure-recovery of the total energy of the airstream. Here is where this gets interesting: The faster you go, the higher the Mach number of air incoming to the inlet, and the more energy is available from the airstream to turn into THRUST!
So, the faster you go, the more thrust you get! This is one reason that supersonic jet airplanes just keep speeding up, and up, and up, and up!
Planes like the F-4 Phantom, for example, take about FIVE MINUTES to get from Mach 1 to Mach 2 (a long time because the thrust only builds as the speed builds) but darn they hit Mach 2 and are still slowly accelerating!
Now, nothing this good lasts forever. At some point, the aircraft speed overwhelms the inlets’ ability to accept the shockwaves, and losses occur. We simulate this with a normal shock, and the inlet efficiency gradually moves from ideal (total pressure recovery) to the worst possible (normal shock) as the inlet moves to and then past it’s maximum allowable Mach number.
Here’s the equation for the losses across the normal shock, by the way:
So, if you open the F-4 Phantom in Plane-Maker, go to the engines window, and then the Jet Curves tab on the right, you will be able to SEE EVERYTHING that I just talked about.
On the left, at Mach 0, you see the static thrust for each altitude.
Then as you move right to Mach 0.5, the thrust falls as the turbine can’t deliver much ‘oomph’ due to the rapid inflow of air… like trying to climb a rope ladder while the rope is falling, trying to get thrust from an airstream always coming at you is simply an uphill battle that does not work too well. So the thrust FALLS as you speed up.
Then, above Mach 0.5 or so, something interesting happens: the energy in the oncoming airstream becomes significant, and the inlet starts decelerating that incoming airstream, using that deceleration to INCREASE the air pressure inside the inlet, which actually helps the inlet do the job FOR the engine! Now, that thrust starts BUILDING!
Now as we move to Mach-1, it’s crazy-time. The airstream pushing at the airplane is packing HUGE energy from all that speed, and nice, efficient, oblique shocks start capturing all that energy, slowing and pressurizing that air efficiently, and handing that high-pressure to the engine. A well-designed inlet at this point might develop MORE thrust than the engine itself… the job of the engine is simply to pressurize the inlet here. And, the faster we go, the farther to the right we move on those curves, and the greater the thrust becomes as we speed up. This is a recipe for an airplane that just never seems to stop accelerating. Enter the F-4. And the SR-71.
But, at some point, the shockwaves overpower the design of the inlet, and we start heading to the (terrible) efficiency of the normal shock. Here you see the curves dropping thrust hugely, on the fast-side of the max expected Mach number for the inlet.
So, you can see the thrust curves in Plane-Maker and now know what forms them. Set the reference Mach number on the lower left for you inlet on your plane to get the thrust peak right around the top speed for your airplane.
And then finally, MAXIMUM thrust is not the only thing here: We also need thrust variation with N1, and DRAG from the engine at idle at various speeds. Those things have been tuned and tested as well.
For testing:
I have a full Citation Mustang POH with aircraft speeds and power settings, to test and tune the low subsonic flight regime for jets, and a recently de-classified F-4 Phantom Pilots Operating Handbook with subsonic and supersonic deceleration times (to tune the DRAG) and acceleration times (to tune the THRUST) to test and tune the high subsonic and supersonic flight envelopes of jet engines. All of the math above checked out very well with the POH’s for these airplanes… much of the accel/decel timing on the F-4 Phantom to within 1 second to get to and from various subsonic and supersonic speeds at full and idle thrust.
And a quick little detail: Low/high jet engine bypass types: GONE! Now we ONLY go off the bypass RATIO that you entered! This lets cool things like exhaust smokiness and engine mass for mass distribution all be floating point with bypass ratio for infinite variation, which is nice.
So, jet simulation has been improved now for V11, especially in the supersonic regime… because getting that F-4 PERFECT is just going to be soooooooo cool!
Thanks to a few hundred hours of flight experience in my Lancair Evolution so far, I am really improving the flight model in X-Plane in the area of PT-6 engines, electrical, and pressurization systems! And, while in the systems code, I’ve improved a lot of other systems simulations as well, which is always fun.
So, here is the new stuff done for 11.00 so far in the flight and systems modeling area! Read More
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.
The title says it all: it’s too soon to update your add-on to X-Plane 11.
Here is why: if your add-on does not work with X-Plane 11, you (and we) do not know if this is because of an intentional removal of functionality (some of which has happened) or because of a bug.
If the problem is a bug and you modify your add-on to work around the bug, it’s very likely that a future public beta will simply break this new work and you would have been better off with the old functionality.
Updating to X-Plane 11 and the public beta need to follow some specific steps:
Testing and discovery. If you have an add-on, please do test it and report bugs and incompatibilities. X-Plane is incredibly complex and there are almost infinite combinations of features used in add-ons, so we can’t just look at the code and go “oh, X will work, Y will not” – sometimes we get surprised. The bug feedback we’ve gotten so far has been great.
Official Statements of Deprecation. We (LR) will provide solid guidance on things that are specifically removed and may require updates.
Updating add-ons. Once you know that an old feature is gone that you relied on, it is “safe” to invest in updating the add-on to use new tech, because you know the old feature is gone for good.
We have tried to keep good notes internally and we’ll get them posted as soon as we can. In the meantime, please hold off on reinventing parts of add-ons until it’s safe to do so.
Here is a short list of a few things that are and are not deprecated that have come up a lot with third party planes.
A few things on the “gone” list:
LIT panel backgrounds: _LIT panel backgrounds are gone in X-Plane 11. They look bad and have been obsolete since X-Plane 8. If you used the _LIT panel for 2-d lighting, make a -2 or -3 or -4 2-d overlay for lighting. If you need 3-d lighting, use 3-d cockpit lights in PlaneMaker.
3-d Panels: The panel texture, when used in a 3-d cockpit, is always built out of a day and night texture in X-Plane 11. If you used ATTR_cockpit_region or GLOBAL_cockpit_lit you were already getting this behavior in X-Plane 10. If you use GLOBAL_cockpit without ATTR_cockpit_region, your panel will be lit when it was not before.
The fix for authors is to put 3-d lights into the cockpit in Plane-Maker to cast light on the panel, and to use real instrument lighting (glass or additive/mechancial o the instruments themselves).
Gamma: X-Plane 11 does not support the old Mac 1.8 gamma from OS X 10.5.8 and 2008. If you have PNGs at 1.8 gamma you’ll need to convert them to sRGB. If you have DDS at 1.8 gamma, re-grind them with the latest X-Grinder. All authoring for X-Plane 11 (and 10) should be sRGB.
All of these removed features have had better replacements for at least five years, the replacement techniques are fully compatible with X-Plane 10 (or even 9), and produce significantly better results than the old techniques.*
Here are some things that are not supposed to be broken:
XPLMNavigation API: the XPLMNavigation API is now “powered” by the new FMS on aircraft saved in X-Plane 11’s Plane-Maker; however, our intention is full API compatibility. There are some known cases in X-Plane 11 public beta 2 where working XPLM code will fail with the new XPLM. Philipp has some fixes that should help in public beta 3 and beyond.
If we find that there are uses of the XPLM API that we cannot support, we’ll post docs in the future, but to start with we’re assuming that these are compatibility bugs.
Other Panel Stuff: other than two-texture 3-d panels and lit backgrounds, nothing else is deprecated in the panel system; transparency in panels was fixed in public beta 2. If you use ATTR_cockpit_region or GLOBAL_cockpit_lit in X-Plane 10 with no _LIT panel background, you should see identical results in X-Plane 11; if you don’t, please report a bug.
If you are looking at upgrading your add-on now, hopefully this list gives you some guidance as to where to spend time vs. where to wait.
Finally, the dataref list that ships with X-Plane 11 public betas reflects the included beta list. If a dataref has been removed and your add-on depends on it, please file a bug and try to describe what problem you were trying to solve with that dataref. We may be able to restore it or provide a reasonable work-around.
* One of my concerns about the public beta has been the number of aircraft I have seen that were developed or updated in the last year or two and yet use authoring techniques that were in the “obsolete but supported” bucket for X-Plane 10. The window of compatibility where we provide support for old and new features doesn’t help if people don’t migrate.
