X-Plane 10.50 beta 1 is live! You can download it by running the X-Plane installer and clicking “get betas”, but you will not be auto-updated for it. As is normal with our betas, there is not a Steam beta of it, nor will there be until we are at release candidates. (But Steam users can install a second copy of the free demo and update that to beta.)
Before continuing, I would like you to assume the lotus position and repeat the following mantra over and over until inner peace floods your body:
The comments section of the developer blog is not a bug reporter.
The comments section of the developer blog is not a bug reporter.
The comments section of the developer blog is not a bug reporter.
The comments section of the developer blog is not a bug reporter.
Ah…don’t you feel more calm already? I certainly do! Seriously though, the bug reporter is here; please use it! I cannot emphasize how much easier it is for us to triage bugs when they all show up in the same place. Random threads in forums about bugs get lost and don’t get fixed.
Release notes are here, but they are not necessarily complete yet. X-Plane 10.50 contained a huge amount of code change, so the notes probably need a few editing passes; something that Austin wouldn’t let meI didn’t want to hold up the beta for.
With any early beta of a major patch, I suggest that early adopters install it on a copy of their X-PLane folder and not the one they use to fly. This goes double for 10.50 because Jennifer, our Q/A head, is out of the office on a road trip. She was able to do a little bit of checking and we’ve tried to spot check it, but this release is more like the beta process from two years ago and not like 10.40 or 10.45. I suspect we’ll have the early stuff knocked out in a week.
There are already a few dumb bugs that have popped up: for some reason taxi lines are totally missing. I’m not sure when that happened because they were around for most of the beta. I’m also looking at a crash that JAR Designs sent me that looks like it could be pretty destabilizing (e.g. I broke the rendering engine). So…consider yourself warned.
Finally, our plan is to do one more airport collection from the gateway toward the end of the beta before we call 10.50 final. In the past we’ve done one airport collection per release, but for a long patch (e.g. 10.30, 10.40, 10.50) by the time we go final, hundreds of gateway submission are ready to go. We’re planning to take another batch in a few weeks, which will let people get fixes in to airports where the problems were revealed in 10.50 (e.g. even with the fixed 10.50 ATC the airport doesn’t work right).
First, it was great to see everyone who came to FSConn 2016! Here’s a video of the conference: if there is another video that has better stabilization I’ll try to post it.
Now about X-Plane 10.50: I did just fix my last beta-stopping bug. So in theory the first beta will be live tomorrow.
But that’s only theory! If the beta isn’t live, please refrain from being the 700th person to post “any ETA on the beta” to the comments section. The actual release date of builds is unpredictable because the existence of release-stopping bugs is unpredictable. (If we could be 100% sure there were no bugs, we wouldn’t need betas at all.)
We’ve been working for the last few weeks to get X-Plane 10.50 ready for public beta. My goal was to get 10.50 posted before I go to FlightSimCon 2016, but it looks like it’s going to be Monday or Tuesday of next week by the time it’s live.
A bunch of us (including Austin, who is presenting) will be at the Conference, and most certainly at the bar after – if you’re there, come say hi. We’ll be talking about the latest stuff in X-Plane 10.50, and possibly some stuff from the lab as well.
Getting the Planes Moving
As part of the ATC tune-up for X-Plane 10.50, Austin and I have worked on a number of features and bug fixes that should hopefully improve the rate of arrivals and departures at our airports. The current code can get pretty backed up, and we’ve had complaints from users about very long taxi times. (Ironically, this totally happens in real life, but I understand that you don’t want a simulation of KDFW when a thunderstorm passes through or KLGA on a Friday afternoon of a long weekend.)
Here are a few of the changes that help move traffic:
The AI drive better. And the better they drive, the less likely they are to bring traffic to a standstill.
ATC has a more realistic estimate of the speed of the AI aircraft. In 10.45, X-Plane launches AI aircraft as if they were real pilots at O’Hare. The actual AI drives more slowly and tries to err on the side of safety; by giving aircraft bigger margins of safety, ATC avoids go-arounds.
Simultaneous parallel-runway operations are now supported for VFR weather. One reason for go-arounds is that 10.45 has the hard-ball IFR rules (think socked-in) for runway separation, which means that very close parallel runways can’t operate at the same time. This is no longer a constraint on a nice day.
ATC uses same-runway-separation rules. These rules let ATC launch aircraft faster when they turn off the runway heading or when the aircraft are small. This means that if a C172 departs on a 10,000 foot runway, you don’t have to wait (five hours) for it to get to the far end of the runway.
There’s one more thing that really helps expedite traffic that you can do: make custom ATC taxi routes in WED for your airport. Having clean, correct taxi layouts with well-planned runway flows makes a huge difference in terms of ATC efficiency and AI operations.
To help you do this, we’re adding more tools to WED to easily edit and understand ATC data and diagnose problems. WED 1.5 should be in beta in the next few weeks and has these enhancements. We will also put together articles showing some common problems with ATC layouts and the best way to author them in WED.
He even got on slash-dot! Anyway, if you want to see a short six minute explanation of why we are being sued, here you go.
And to state the obvious, we are not discontinuing any of our products, we are not dropping Android as a platform, and we are in no way backing down because of the lawsuit. As you can tell from the video and Austin’s posts, Austin has some strong feelings about standing up to patent trolls.
First, we are making progress toward X-Plane 10.50. I sent out a private beta a few days ago; how soon we get to public beta will depend on how buggy the private beta turns out to be. (I am assuming that it will have zero bugs, because I have decided to not write any more bugs in my code. So…there, I fixed it.)
Coming in 10.50: X-Plane supports new manipulators.
In 10.50 you can add scroll wheel to any of the existing manipulators that takes one dataref. This is done via a second directive that sets the amount the dataref changes when the wheel moves.*
There are six new manipulators (they form a set) to support knobs and three-way switches. Each one takes a pair of commands and provides a consistent UI experience.
The no-op manipulator now takes a tool-tip, which lets you make tool tips for gauges and other unclickable geometry.
I want to make two things clear here:
This is support for these manipulators in the engine. This means that we can use them in our aircraft and third parties can use them in their aircraft. Adding these manipulators is a separate task, one we are working on, but which won’t be complete as of 10.50.
Third parties are welcome to use the new manipulators, and they are welcome to follow our internal usage guidelines. They are also welcome to keep doing what they are doing; none of this is binding, everything is opt-in. Nothing about this breaks compatibility with any existing aircraft.
Why Did We Add These?
We’ve had a long term internal goal of making the 3-d cockpit as usable and user-friendly as possible. We’ve reached a point where 3-d cockpits are the norm, and all of our new aircraft development is 3-d only. But you can’t deny that 2-d cockpits are incredibly usable from a user interface standpoint. How do you make 3-d usable?
We already have view presets to let you get to a particular cockpit view easily. Once you have a good view of the surface you want to interact with, the next step is to have a mouse gesture that’s easy to use.
This is where the new manipulators come in. Rather than describing a mouse gesture (drag, click, etc.) they describe a type of physical hardware, one of a rotating knob, left-right multi-way switch or up-down multi-way switch.
Because the manipulators describe the physical hardware and not how the UI should work, we can change the interaction mode based on user preferences, available hardware, etc.
One of the big UI questions is: should you change a knob by clicking and holding or dragging? I built a test airplane with some of each and the company was split down the middle. By using knob manipulators (and not click or drag manipulators) we can change the way knobs work in the cockpit for all airplanes with one change of the code, rather than having our art team redo every single manipulator in every single airplane.
I don’t know whether we’ll use dragging or clicking-based knobs – or whether a user preference will be exposed. But by having a higher level manipulator type we make this a small programming problem and not an unmanageable authoring problem.
(The new knob manipulator automatically uses the scroll wheel – since we know it’s a knob, we can figure out how the wheel should work. The new command to add scroll wheel to legacy manipulators is necessary to provide the data the sim needs to make the user interaction good.)
The new higher level manipulators also give us flexibility for new input devices. For example, if we someday want to support multi-touch tablets and track-pads, we could map a pinch-rotate gesture to a knob – since we know the manipulator really is a round knob (and not just ‘something that you drag’) we can know that a rotating gesture makes sense.
How Do I Add Them?
The new manipulators are already supported in code in the Blender 2.7, Blender 2.49 and and AC3D. The manipulators are released in the newest Blender 2.7 exporter; I need to post newer 2.49 exporters. I do not know if/when there will be a public release of the AC3D exporter, but I can probably find the time at some point to do one more compile.
All aspects of the new manipulators are opt-in; if you don’t change your airplane, its functionality should not change.
What Aircraft Use Them
I’ve buried the lead a little bit here: X-Plane 10.50 will have a heavily upgraded Kingair C90 and Baron B58 that will use the new manipulators. We have not (yet) upgraded the rest of the fleet, and this upgrade will happen over a very long time-span. The goal of 10.50 is to lay the groundwork and make cleaner user interfaces possible by making the new manipulators available to our art team and third parties.
The guidelines I’ve been advocating for our artists are:
Large things that move a lot like throttles are dragged via an axis that tracks the actual 3-d motion.
Yokes track via a 2-d XY manipulator.
Anything that toggles or has only two states is a single click, particularly for small things.
Rotary knobs and rheostats use the new knob manipulators. The mouse wheel can turn them.
Linear switches with three or more positions use the new left-right and up-down switch manipulators. The mouse wheel can click them.
There’s no reason why third parties have to use these guidelines; I post them only to show how we are thinking about usability. A more “3-d” approach is possible, e.g. drag a banana switch up and down to toggle it; my view is that for Laminar’s default fleet, which are the first aircraft users are going to use, single clicks provide a more direct and less surprising user experience.
For power users, having single clicks for switches may also mean you can get more done in the cockpit faster. (In real life, a pilot can reach up and flip four metal banana switches on the overhead panel very, very quickly.) We’ll still use dragging for big 3-d motions.
*This feature targets one-wheel clicking Windows-style mice. 2/3 of our users are on Windows, and Apple has shipped a wide variety of strange input devices, so the one-axis clicking mouse wheel is the most consistent hardware target for us to aim at. And frankly, I think it’s the most useful since you get clear ‘detents’ as you scroll things – good for changing a radio by one notch.
When we put out the request for comments on publishing X-Plane usage data four and a half months ago, I had the best of intentions for creating nice, web-based, automatically-published, interactive graphs & charts with all the data we have.
Unfortunately, I’ve been head-down working on top-secret features for X-Plane Desktop (believe me, when you see this stuff, you’ll understand why!), and my analytics data project has just languished (and will continue to languish for many months more as I finish the Desktop features).
So, after a gentle kick in the pants, I’m publishing the data as I have it. It’s not pretty, but I think it will still be useful to third-party developers. We have a handful of easy-to-digest charts, plus a whole bunch of raw data at the bottom of the post for those that are interested.
Note that all data in these charts are for users of the full version only—I’ve filtered out demo users.
Do let me know in the comments if you have questions about the data!
Aircraft
Hardware
Raw Data
There are two files here: hardware data, and aircraft data. Each contains all the information we have since September 2015, for paying customers only (no demo users). I’ve provided two formats for each file: an XLS, and a simple CSV.
Signs in the hierarchy are shown as a rendered preview of what the sign will look like.
When you click on it (as if it was text) you get a WYSIWYG editor with two “text” fields where signs can be directly typed, and a palette where signs can be added by clicking.
I just fixed a problem in DDSTool: DDSTool was calculating mipmaps in sRGB space instead of linear space. This was wrong, but didn’t make a huge difference when grinding day-time textures.
It does make a big difference for LIT textures though. Let me show you.
Old: darker lit textures
New: brighter lit textures
That’s a night LIT scene (at PHNL I think) with some new autogen from X-Plane 10.50. (To answer your question, some of the AG has LIT textures, but not 100% of objects do.)
In the lower left corner are thumbnails of the raw textures – what is interesting about them is that they show the smaller-sized images in the mipmap pyramid of the image. And you can see that in the old image, the small thumbnail of the buildings is almost completely black – the building light has been lost with down-sizing.
Note that the buildings are a little bit darker in the old grind on the left but the tiny thumbnail is much darker. That’s because making mipmaps is a recursive process – each next-smallest-size mipmap is processed from the previous image; by the time we get to a really small size image, if we have lost brightness, the effect has really built up.
The result was that in the old grinds, as you flew away from the buildings, they’d get darker. In the new grinds, they stay at consistent brightness.
What Changed: the Math
Here’s the funny thing about images in sRGB color space (which is what X-Plane uses) – the mid-point between black (0) and white (255) is not 127 or 128. That’s too dark! The actual right color is 188 – pretty bright!
This happens because sRGB images are encoded in a non-linear manner for even perceptual spacing for humans, and our eyes are more sensitive at lower light levels. But the average between two pixels should be the average of the actual amount of light coming from the pixels. The half-way point of sRGB is too dark because a lot of numeric space in sRGB is spent in the dark regions.
The problem is that lit textures are made up of a few really bright pixels and a lot of black; when averaged together the wrong way the smaller sized images end up too dark, making slushy, dark, munged night lit textures at small sizes.
The solution (in the new DDSTool code) is to convert the colors to linear space, down-size the image and convert them back. There’s no change to how you use the tool – the images just look better at small size.
