X-Plane 10.30 Beta 5 Is Out
It should fix the crash on startup for 32-bit Mac that was in beta 4.
It should fix the crash on startup for 32-bit Mac that was in beta 4.
A few notes on beta 4, which went live today:
One last note on METARs: when X-Plane finds a METAR with “unlimited” visibility (e.g. 9999, CAVOK, etc.) it will look at the temperature-dewpoint spread to determine the humidity, and then pick a visibility distance that is lower when humid and higher when dry. So under truly dry conditions you should get a less hazy view, while visibility will continue to be constrained on humid days.
Update: the 32-bit Mac version of beta 4 won’t run due to a build configuration problem. We’re working on it now, but I’m guessing it will be 36 hours before we get beta 5 posted. 🙁
Beta 3 just went live. Release notes are still here – the document grows! When the beta is done I’m going to have it printed and use it as a weapon to squash house flies. Bug reporter is still here. Bug reporter is still not the comments section in this post.*
The short summary is: Philipp crushed a huge pile of GPS bugs, and I crushed none of the cloud-related bugs. So please read the bug fix list carefully before you report. We try to make sure there’s a bug list bullet for every single fix in the beta, so that you don’t have to waste your time (or ours!) re-reporting a bug that isn’t fixed. If you reported (hypothetically 🙂 that cloud performance makes you weep (and not in a good way), there’s no need to re-report, I haven’t gotten to it yet.
If you have not tested your payware add-on with X-Plane 1030, please do so ASAP! We do not have a pile of known issues with third party drawing, so if you see something, say something. (We have a number of possible bugs that aren’t reproducible yet – so your bug report might be what lets us get to the bottom of things efficiently. Only you can prevent forest fires!)
* This post comes with an extra helping of snarkiness…Chris and I made the really poor decision to try to debug part of the X-Plane airport gateway deployment from 11:30 PM to 3:30 AM land night. Since we both have small children who didn’t get the memo and woke up at their normal time, I am, at this point, pretty much unaware of what I am typing.
I’m a little slow at blogging this, but 10.30 beta 2 is out – beta 1 users received an auto-update notice.
Please report bugs here. Starting now I am going to delete comments that are bug reports. I really can’t be any more clear about this: please report bugs in the bug report form and not on the blog post.*
The release notes are here. I broke up the bug fix section by beta so you can see what is new in beta 2.
I have already received reports that the “fix” to the slow local map is not actually a fix at all. Unfortunately my C drive lost sectors (again) so I am behind in investigating both this and general performance complaints. I’ll need to rebuild the machine before I can get to these things.
* Why am I being such a jerk about this? Two reasons:
So bugs posted to forums, blogs, email, these are at best slowing down the beta process and at worst getting lost. (Especially forums – since I don’t read them, they are by definition lost.)
And as a final rant: emailing with “should I file a bug about X” is inefficient for everyone. It takes as long for you to write the email as to file the bug. It takes us time to read the email, answer, then get the bug. Just file the bug!
The next X-Plane 10.30 beta should be out tonight (or maybe tomorrow morning); the release notes are already updated with the latest fixes, and we’re just waiting on upload.
There were some “boneheaded” bugs in beta 1 – things that just didn’t work, should have worked, and were easily fixed; we have addressed all of those that were reported for beta 2. Despite about half a dozen boneheaded bugs, I actually think the quality of public beta 1 – relative to the amount of source change – was pretty strong. Remember that 10.30 has perhaps 2x the amount of code change of a normal major patch, so if there isn’t too much nuclear then I think we’re doing okay.
Aircraft Authors: please test beta 2! I think we may be able to keep 10.30’s beta period down to 4 weeks, which is a lot shorter than normal. And the remaining bugs are all in clouds and performance, so please do not wait to test your aircraft. Eugeny contacted me on problems with the A320 Neo on beta 1, and we have X-Plane fixed for beta 2. Don’t wait!
Performance: there have been all sorts of performance comments from users. I think there are three separate things going on:
I am investigating both points 2 and 3, but neither are fixed for beta 2; we wanted to get some of the stupid things fixed ASAP (e.g. the ATIS not working).
To make matters worse, my PC’s SATA controller seems to have finally lost it’s mind. Philipp had to cut the Windows build, and this has halted me from investigating AMD performance problems. (In my initial tests I couldn’t repro anything but now I’m stuck.)
Clouds: The other area of bug fixing on my plate that simply isn’t addressed in beta 2 is the cloud locations; several users have correctly reported that the bases of the clouds are simply not where they expect. Since there is an unfortunate link between rendering settings and fixing this bug (if the puffs we use to visualize clouds change, it effectively moves the cloud bases) I have to fix both cloud performance and cloud bases at the same time.
The expected behavior for the clouds, I think, is that if you set a stratus layer with no storms and fly an ILS, you should “break out” (that is, make visual contact with the runway environment) right around the elevation set in the weather screen. (This is not what is happening now, which is why there is an open bug.) If you set more ‘creative’ weather, X-Plane will start to vary things and you won’t get “reliable” break-outs.
METARs: One last note on weather: if you find that X-Plane has misinterpreted a METAR (and my sympathy is with X-Plane, because METARs just contain the most random stuff in them sometimes), then please be sure to include in your bug report:
X-Plane 10.30 does have a new METAR parser so we’re trying to catch the bugs.
Airports and DSFs: we are looking at including both some fixed DSFs and additional 3-d airports in 10.30. Both depend on the tech being ready; the airport gateway is in the deployment phase and if it goes smoothly, we could be ready to post airports. I’m still trying to get to the bottom of DSF bugs, but I am close. If either of these content updates miss 10.30, we’ll release them in a small patch as soon as possible.
The first public beta of X-Plane 10.30 is here. To get it, go to update an installation of X-Plane and click the “get betas” check-box of the X-Plane installer or demo installer. (As this is a first beta, you should probably run 10.30 on a copy of your main X-Plane folder; it’s premature to run 10.30 as your main install.)
Release notes here. Bug reporter here. Do not report bugs on the blog comments.
We do not read the various third party X-Plane forums. If you find a bug and you discuss it on the org or avsim or fs.com for 10 pages and do not report the bug in the form, we do not know about it. Please do not assume that someone else will report the bug – you’d be amazed how often everyone thought someone else would make the real report.* Also, while I’m ranting, please do not link to forums that require logins or memberships with bug reports; a forum discussion is not a clean bug report!
The release notes are four pages long, so let me try to summarize what we’ve done. There are really four major areas of this beta:
Here are some numbers: from X-Plane 10.11 to X-Plane 10.25, we had 404 commits in GIT, including betas and patches. From X-Plane 10.25 to X-Plane 10.30 beta 1, we have 1113 commits, and we haven’t even run the public beta. This is a big release in terms of work!
If you are making a third party aircraft, please do test your aircraft with 10.30 and report a bug if we broke something! You can also begin work on supporting the new GPS.
But, for the love of all that is beta, please do not release 10.30 aircraft! We’re in public beta and the way the new features work are likely to change. During 10.20 we had developers release 64-bit plugins mid-beta, and they had to immediately redo their release because the beta changed. The safe time to release a 10.30 aircraft will be when 10.30 goes final – no sooner!
(If you are releasing a new product during beta, release it for X-Plane 10.25, then please report a bug if it doesn’t work with the beta.)
* If you are part of a discussion with ten people on a website and you all see a bug, you can pick one person to be ‘the reporter’ – what drives me nutty is when everyone assumes someone else will report and, with no coordination, no one ever does. There have been a number of times recently that I’ve discussed a bug with a third party author and heard “we’ve known about this on XYZ website for months.” I’m sorry, but there are too many third party web-sites and not enough hours in the day for the dev team to scan every forum post for hidden bug reports.
I was going to write this post yesterday, and I’m glad I didn’t, because my estimated release time was off by a day. But 10.30 is now cut and is being mirrored out to our servers. If things go without hitch, we can hit “go” tomorrow.
In the meantime, you can read about what we did here – after a little bit of cleanup I was able to cut the notes down to ten pages. Aircraft authors, you’ll want to read the docs on the new GPS and other cockpit issues.
(10.30 is probably better documented as an early beta than any previous beta we have done, both in terms of completeness and detail of changes and release notes, and in terms of new docs on new features.)
Perhaps I am too optimistic, but: rendering solid, opaque objects that look realistic in real-time (read: for games and rendering engines) is rapidly becoming a solved problem. I look at the bleeding edge of the top-tier shooters as a preview of the direction for the field of real-time rendering*, and for the last year, physically based rendering (PBR) has been front and center.
I’ll write more about PBR in another post, but the short version is that, in PBR, the equations for light interacting with materials in a rendering engine are modeled more closely on real-world physical equations; the goal is something that is very accurate to real world optics, and produces realistic results over its entire range of inputs.
PBR is made possible by increased computing power on the GPU. (And here when I say computing power I really do mean computing, or ALU power; PBR requires more math per pixel to calculate for a wider range of optical effects, often with more expensive but better approximations of the underlying optics.) We now have big enough GPUs to do “real physics” (well, real-ish) when it comes to light and solid objects. This is a huge step forward when you consider that a decade ago, calculating lighting equations per-pixel was marginal and had to be done in the wrong color space for speed.**
So for solid objects like airplane fuselages, runways, buildings, baggage trucks, etc., we have physics.
Then there are clouds, and the air, and rain and fog. For those we have magic.
By magic, I do not mean something truly magical, something outside the realm of what is possible with computer graphics. Rather, I mean the definition a professional magician like Penn Jilette might use: trickery. To quote Penn***:
The only secret in magic, there’s only one, and that is, the secret must be ugly. You cannot have a beautiful secret…So, in magic, what you want is an idea that is not beautiful…If I have to say, he’s lying about that, and there’s gaffer’s tape over behind there, and, ah, they’re not actually telling you the exact truth here, and it gets so…you don’t get an a-ha.
But there’s another side to magic: to make the trick look magical, the magician has to practice – the trick is a craft, and it can be finely honed. That’s why, before Teller does the Red Ball trick, Penn has to tell you how it’s done; you can’t appreciate the workmanship if you don’t know how much workmanship went in. The secret of the trick may be ugly, but the craftsmanship can be beautiful.****
Clouds, fog, atmospheric scattering – in X-Plane (and pretty much all rendering engines), these are not physics, they are magic, meaning they are tricks. The sky is a hemisphere around your head, like in The Truman Show. The color of the clouds are just painted onto textures with photoshop.
It’s trickery, but I feel no shame in these things, because the real physics are approximately a gajllion times more expensive than we can possibly afford on today’s hardware. A single square meter of ground (on an overcast day) might be lit by 10^18 photons per second – a lot more when the sun comes out, and each of those photons can take a different path through the atmosphere, bouncing off molecules multiple times before arriving at a surface. The actual optics of clouds and the atmosphere is incredibly complex.
The hard work and craft of the trickery is in making all of the tricks work together to make a unified effect, and this is where some of my time has been spent over the last few days. It is frustrating work because there isn’t a right answer (the way there might be in the programming of physics equations); instead it is a series of tricks and compromises that try to make an illusion as convincing as possible given limited resources.
Whenever I describe the code behind atmospheric scattering, clouds and fog to Chris, he is always horrified by the complexity, by the layers of tricks. But such complexity matches Teller’s the definition of a functional magic trick:
Make the secret a lot more trouble than the trick seems worth. You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest.
If clouds and scattering weren’t so much trouble, they wouldn’t be magic.
https://www.youtube.com/watch?v=FFq-fn-nSZI
* The field of real-time rendering includes computer programs that produce graphics at high framerates, like games and CAD programs. This contrasts it with the movie industry, where they can spend two years with a giant render farm to produce 90 minutes of final output.
** In 2004, we had the GeForce FX series and the Radeon 9700. The 9700 was insanely powerful for its time, but it only had a 24-bit internal floating point path, a 96 instruction shader limit, etc.; you could do per-pixel calculations but burning shader instructions to work in linear space wasn’t on anyone’s mind. The Geforce FX series was significantly less powerful. This chapter wasn’t published until 2007 – 3 years later.
*** The link is to a Radio Lab story about a man who tries to understand how his grandparents performed a mentalism act on the radio – it’s a good listen!
**** In Fool Us, many times Penn and Teller knows exactly how the trick was done, but still praise the magician for their presentation – because they know how the trick was done, they know how hard it is to do it well. Within the show, they seem to have a preference for tricks that are not easy and require skill to perform.
Robin, Tyler and I have been going through the airports that have been sent in since X-Plane 10.25; the good news is that there are over 350 batches sent in!*
But – I had to throw thirteen of them overboard; they were using OpenSceneryX. For airports that are going to be sent to the gateway and become part of the default airport file for X-Plane, you can’t use third party libraries! Everything you use has to ship with X-Plane.
WED 1.3 has user interface features to help hide third party libraries, but in this case you’d think that having the objects in the opensceneryx/ folder would have been a hint.
It’s not a coincidence that this was the same thirteen entries not sent in the right format; WED 1.2.1 won’t do an export for the global database with third party libraries, and this will be true with WED 1.3 as well, where the export is uploaded directly to the gateway.
My previous post described the dangers of relying on art controls for an add-on that needs to be forward compatible with future versions of X-Plane; the short version is that art controls are an internal tool and not a public SDK, so we don’t try to maintain compatibility with updates.
So I figured I’d blog about the other dangerous way to build an add-on: creating an add-on by modifying X-Plane’s files.
All of the well-supported forward compatible ways to make add-ons (scenery packs, aircraft, and plugins) work by adding new files to X-Plane, usually in a folder specific to your add-on (a scenery pack, an aircraft folder, or a fat plugin). This is very intentional – it ensures that add-ons don’t clash with our installer/updater over ownership of specific files.
But if you make an add-on that requires the user to replace one of our files with your own, all bets are off, and future patches of X-Plane will probably both screw up your add-on and be an updater nightmare for your users. The best bet is to avoid modding our files.
The library system lets you virtually replace our files without actually touching them by mapping your own art assets to a given library path. This is the right way to customize the scenery; editing the files on disk is not a good choice. We may move files around within our own art assets in an update, but the library paths remain the same. Thus building a library replacement is relatively safe; hacking the library scenery packs inside “Resources/default scenery” is not.
You should also use the library when you want to use our art assets; do not copy our art assets out of X-Plane into your scenery pack. If you use the library, improvements to the art assets are automatically transferred to your scenery pack.
Here are some files that really aren’t meant to be modified in an add-on:
These files are all really part of X-Plane’s implementation and change regularly as we try to improve the sim.
You might notice that there is no way to directly use X-Plane’s textures in your add-on. At best you can use the .ter or .pol file that references them.
This is intentional! Our artists may need to remap the location of elements within a texture as part of a future sim change, and when this happens, add-ons reference the texture would show the wrong part of the image. That’s why add-ons can only reference some asset that itself references the texture; if we change the texture, we change our .pol files or .ter files or what-have-you to compensate for the UV map change.
Austin and I get a steady stream of “can we just get access to X for our add-on” where X is some part of the sim that the add-on maker would like to re-use. Unfortunately most cases where internals aren’t public are because we can’t safely share them; X-Plane is an application first and a library or platform second, and in many of these cases, to share these internal parts of X-Plane would be to commit to not ever making them better, which we don’t want to do.