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.
Posted in News
by
Ben Supnik |
In X-Plane 11, the new lighting and material model, which uses Physically Based Rendering, is always on. Even at the lowest settings!
In X-Plane 9, 10 and 11, we have introduced major changes to the lighting model at new versions, so we could have a reasonably stable lighting environment for the life of the product. Each time we introduce these new features, we need to decide if they are always on or optional.
My preference is “always on” when possible; having these kinds of big features be optional makes life difficult for authors, who can’t be sure how their content will look in the simulator.
When we introduced HDR with global night lighting in X-Plane 10, it was (and still is) an optional feature. This is because deferred rendering mode uses a lot of GPU memory bandwidth, and many Intel GPUs simply can’t handle this rendering load. Because Intel GPUs represent a non-trivial percent of our install base, we can’t make features that don’t run on Intel hardware mandatory. Thus HDR remains optional. (We checked this in X-Plane 11 and we still can’t make HDR mandatory. Maybe in X-Plane 12. 🙂
The new lighting model ties three features together: (improved) volumetric fog, atmospheric scattering, and physically based lighting equations with the new material model. These features are always on in X-Plane 11, and this makes life easier for our artists; the lighting environment is always the same no matter what the settings.*
With physically based rendering, we support lower end systems by reducing the quality of the effects, rather than by removing the effect entirely. Most of the cost of PBR is in calculating the processed reflection textures to make PBR work. At low settings we can reduce the texture resolution and remove detail.
This tuning is still in progress; testers who were in our private beta program know this because they saw significantly worse framerate in beta 1 than in the public beta. A lot of this performance tuning is finding ways to make the lower end settings do less work than the high-end settings.
I’ll post more next week on how to use the new PBR rendering, but for now this is posted and a good start.
* It makes life easier for me too by greatly reducing the number of combinations to debug.
I have seen this in the forums:
Tried X-Plane 11, ____ was wrong with it. Reinstalled and it [did/did not] fix it
You almost never need to reinstall X-Plane to fix these kinds of things. In particular, if you haven’t installed an add-on, you definitely never need to reinstall.
To get X-Plane back to its clean state, you can do this:
- Run the updater. If you’ve modified a file by accident it will ask if you want to replace it. Say yes.
- Delete all of the files in Output/preferences.
That’s all you have to do. Our installer just dumps files on your disk. It doesn’t set any registry settings or other hidden voodoo that can only be fixed by reinstall. So you can just clean out your prefs, make sure the files are up to date and not modified, and you’re good to go.
In particular, in beta 1, if something is messed up, reinstalling isn’t going to fix it; beta 2 is going to fix it! (Or maybe beta 3. 😉
(I think everyone reading this blog knows this, but you also don’t have to reinstall to get another 15 minute demo.)
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.
We posted the system requirements for X-Plane 11 today. Here’re a few notes on the requirements for X-Plane 11.
64-Bit Only
This should be a surprise to no one: X-Plane 11 will be 64-bit only. Add-ons have already gone 64-bit only, over 90% of our user base is already running 64-bit operating systems, and we need 64-bit to be able to utilize the RAM that we need and everyone already has.
Windows: No More XP or Vista
For Windows, we are dropping XP and Vista support and requiring Windows 7 or newer. XP has been end-of-lifed by Microsoft for a while and is therefore not safe to use (due to a lack of security updates).
OS X: Yosemite and Newer
For OS X, we are dropping a number of OS X versions and requiring Yosemite (10.10) or higher. Apple has increased the tempo for OS releases in the last few years, and they don’t provide new drivers to old operating systems, so we are pre-emptively cutting down the set of supported operating systems to cut down the number of different 3-d drivers we have to test.
Linux: Proprietary Drivers Required
On Linux, we will continue to support only the proprietary 3-d drivers from AMD and NVidia; these drivers use the same OpenGL stack, so they let us support Linux without the cost of additional 3-d driver testing. We don’t officially support the Mesa/Gallium stack for Intel GPUs, but X-Plane Linux users have done a bunch of work to make this unofficially work, and we do our best to not undo their work.
Graphics Cards
We’re setting the minimum graphics card at the AMD HD 5000-series line for the red team and the GeForce 400-series for the green team. This ensures that we only support cards with reasonably current drivers, DX11-class capabilities, etc. For Intel, you’ll need at least an HD2000 series or newer; figuring out your Intel motherboard graphics is really tricky because their numbering scheme is crazy, but if you don’t have at least some kind of “HD” graphics, you definitely can’t run.
We recommend a newer graphics card, e.g. at least from the DX12 or newer generations. When it comes to graphics, basically more is more, so whether you need a Titan or Fury or similarly monstrous card depends on things like how big your monitor is.
CPU
CPU requirements are the messiest part of the spec and the source of most of our internal discussion. Simply put, there really aren’t good ways for us to simply state what CPU is going to work well or not with X-Plane. X-Plane itself has a huge range of CPU uses based on configuration, and CPUs have a huge range of actual performance that can be hard to predict from some of the simple headline numbers. Clock rate is absolutely not indicative of performance, nor is core count.
A recommended system is pretty simple: we recommend the Intel i5 6600K, which is the current top-speed gamer targeted i5. You can go lower or older and lose significant performance, or you can go faster and really start to pay a lot more money. If you want to invest in 8 Xeon cores, it may help… but we aren’t going to go tell you to spend that kind of money for a little more performance.
Practical Recommendations
Here are my practical recommendations for X-Plane 11:
- If your machine is just barely getting by with X-Plane 10 at the lowest settings, and those hardware requirements seem high because your machine was built several years ago, you may need to upgrade for X-Plane 11. In this case, it could be a good time to upgrade OS and multiple components.
- If your machine runs X-Plane 10 well, it will almost certainly run X-Plane 11 in some form, with the exception of the very oldest graphics cards. (If you have one of those, I would say your definition for ‘run well’ is a lot lower than mine is.)
- If you need to purchase new hardware, I strongly recommend running X-Plane 11 on your existing hardware first and examining performance of the demo (when available) to see where you’ll need to upgrade.
Real hardware performance is hugely varied by what you are doing and your particular system components, so trying the demo will tell you more than we can hope to figure out from specs.
Now that we have announced X-Plane 11, I can finally post goofy screenshots and videos from v11 development. Sometimes a bug makes delightfully goofy results, and Austin liked this one so much he wanted me to share it.
I am working on 3-d water for X-Plane 11 – we have a working prototype, but I am not sure if this will make the shipping 11.0 product; it still has a lot of bugs and rough edges.
Traditionally in X-Plane if you don’t have terrain installed, you just get water. This isn’t really an intentional design decision; we just defined “no DSF” as “all water” so that we could avoid shipping DSFs for the huge chunk of the Earth’s surface that is covered with ocean.
But we always have airport data, so in X-Plane you would get an airport floating in the middle of the water! While this was completely goofy and is a huge source of tech support calls (which is why X-Plane 10.50 now offers to install scenery whenever you hit this case) you could, if you really wanted to, land at this water-world airport.
Until now. Now that the water is 3-d, the peaks of the waves actually cover the 3-d buildings and make the entire airport as usable as…well, as it really would be if built in the middle of the ocean.
(This is about the point in the post where I would insert a snarky climate change comment, but I’ll let XKCD do the talking.)
Scenery developers might wonder: why is it that when the water level falls the runway lights and signs are revealed – but where is the pavement? The answer is in the comments.
X-Plane 10.51 has now been officially released; you’ll be prompted to auto-update. 10.51 fixes a few bugs in 10.50 and updates the global airports.
There is one bug we are still tracking: a number of professional customers have reported worse external-visual tracking with 10.51 than with 10.45. If you see this on your setup, please file a bug; we are working with these pro customers individually to test possible fixes.
(We can’t easily reproduce this bug because the performance characteristics of multi-machine setups are very particular to the specific machines, rendering settings, and networking hardware involved.)
Posted in News
by
Ben Supnik |
The second release candidate of X-Plane 10.51 is up – I’m hoping this will be our final X-Plane 10.51. build. If you are having problems with 10.50, please use the installer with “gea betas” to get 10.51, then report a bug if you still have problems.
