I tried to rush through X-Plane 10.50 beta 2 over Friday and Saturday, in an attempt to get past a number of high profile crash bugs and installer errors quickly, despite having our Q/A person out of the office.
This didn’t work too well – beta 2 introduced a new stupid bug (the airplane lights are always on), and of course there are still plenty of other bugs.
So my plan now is to slow down a little bit and try to take time to verify beta 3 a bit before releasing it, which means it won’t make it out until mid next week. There are bugs we’ve found in beta 2 that are not quick fixes that are still quite severe, so it’s time to measure twice, cut once, not take two steps forward and one step back.
In the meantime:
To everyone who has reported bugs via the bug reporter, thank you! We’ve gotten a lot of bug reports, which is great – it gives us a rapid picture of what’s working and what’s not.
To everyone who has also posted their bug report in the comments section, please stop doing that! I have deleted a number of recent comments that were either “I also posted this bug to the bug reporter, but (bug report goes here)” or “this is not a bug report but (“bug report goes here”). We really need the bug reports in a single place where we can carefully track them. That place is not the blog comment section.
Tall Buildings and Data
I believe that X-Plane 10.50 beta 2 fixed the bug where the tall autogen was missing from the installer. Unfortunately this means that if you still don’t see tall buildings, it’s because the DSF doesn’t contain tall building information. A good check is to go to New York City – if it’s tall with max autogen, it’s the underlying DSF data, not the autogen.
The tall building height data that is in the global scenery DSFs now came from a mix of FAA data and user collected data from a very long time ago. Therefore tall buildings are very likely to be missing or in the wrong place outside of the US. Our future plan (which alpilotx has already made progress on; I need to examine some of the files he sent me) is to use OSM for the height data too, which should be a huge improvement.
While we do plan to use OSM data to provide DSF height data, that is not going to happen soon, and is not going to happen for X-Plane 10.50.
In the meantime, I will try to post soon the DSF information on how the height data is encoded. This will at least give third party developers the option to create DSFs that take advantage of the new autogen.
The good news is: 10.50 beta 2 is out, and it fixes a pile of big problems with beta 1.
The bad news is: it has its own problems – apparently some of the airplane lights are on all the time. This will have to get fixed in beta 3.
If you get a crash on startup, you’ll need to run the installer to get beta 2 – auto-update might not run due to the crash.
A quick note on scenery: I was able to fix one scenery-related crash in beta 1, but there are others still in the code. If you are seeing scenery crashes, I need a Log.txt showing the problem -and- info about what scenery and what settings you combined to get the crash. With the complete reproduction information, I can fix the crash.
So…beta 1 is buggy as a bed in New York. I’m going to list these here in the hope of stemming the tide of bug reports:
These are broken in beta 1 and will be fixed in beta 2 – I’ve already fixed the code.
The new autogen is missing! 🙁 There was a bug in the code that makes the installation; 10.50b1 diligently installs the old autogen.
Crashes with some custom scenery.
Missing taxi lines – they’ll be back.
Floating objects – I did see this one during pre-beta; it’s now fixed.
The static aircraft are also not working; I am investigating this now, but I expect to have it fixed for 10.50 beta 2.
Finally, users are reporting crashes on startup with plugins; if you have this on OS X, please include the Apple crash report and not just Log.txt. I’m not sure what’s going on here, but it’s almost certainly a bug in 10.50b1 – we’re not changing any plugin compatibility rules, and the set of plugins affected is quite wide. (This bug is also not easily reproduced; I haven’t seen it with any plugins, it was not reported in private beta, and in one case the developer of a crashing add-on can’t crash his own add-on.)
Beta 2 will be out some time in the next few days.
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.
I’ve been way behind on blog posts over the last few weeks. Basically, the more we are doing, the less I manage to blog about what we are doing. (Instead I put off writing a blog post until it’s really late and then decide at 11 pm that I’m too tired and I’ll do it tomorrow.)
So here’s a partial list of X-Plane 10.50 features. This is not even remotely complete, it’s just some “headline” features that I can think of now; the release notes will be comprehensive.
New Autogen: We have new US tall building art assets that will make cities look better.
apt.dat 1050 with Static Aircraft and New Models: A new revision of the apt.dat file provides information on parking spots so that we can place static aircraft models inside X-Plane, based on the library and rendering settings. X-Plane 10.50 will ship with a bunch of additional static aircraft models, and third parties can add more via the lbirary. WED 1.5 will have new features to edit this information.
For airports created before WED 1.5 (which is nearly all of the approved airports), we are working on tech to auto-upgrade the gateway airports to use the new static aircraft; third party scenery will simply not participate in the new feature until updated by the authors.
Global Winds Aloft: X-Plane 10.50 will use global NOAA data for winds aloft, rather than a US-only data source.
ATC Fixes: X-Plane 10.50 has a number of ATC bug fixes to make ATC a lot more usable. No more “you are off course!”
New Manipulators: We have added a few new manipulator types as part of an effort to make 3-d cockpits more usable. Yes, the scroll-wheel is accessible. (We have not rebuilt every 3-d cockpit in our fleet. The feature here is the capability in the engine, for us and third parties to use.)
Update King-Air and Baron: we have, however, redone the Kingair and Baron, fixing a number of issues and getting them to a whole new level for IFR flight. These planes use the new manipulators for their 3-d cockpits.
More Airports from the Gateway: as with all releases, we’ll include the latest airports from the X-Plane airport gateway.
Those are just the “big” things – there’s some huge number of other changes, some of which may be really important to some of our users. I still have about half a dozen items on my todo list to get to a 10.50 beta, so I haven’t worked up complete release notes yet.
X-Plane 10.45 has been released; if you have run X-Plane you already know that.
This release has another big update to the global airports and updated navigation data. Here’s a complete list of everything changed.
One new feature of 10.45 that may change how you use X-Plane: the global airports no longer conflict with custom scenery – even if you have custom scenery that doesn’t have proper exclusion zones.
So if you have been disabling the global airports due to conflicts, you don’t need to do this anymore. You can use your custom scenery and keep the global airports around.
We are already well into X-Plane 10.50 development – we’ve actually been doing significant 10.50 work for a while now. I’ll have more posts on that soon – right now we are aiming to have 10.50 in public beta in a few weeks.*
* That’s a vague time estimate because it’s not super accurate. Feature work is not complete for 10.50, so it’s hard to know when it will really be done. Our goal isn’t to get 10.50 into beta at a certain date; it is to make X-Plane better as efficiently as possible.
First, X-Plane 10.45 release candidate 2 is out. There was a bug in RC1 where the instructor’s operator station (IOS) couldn’t change aircraft over the network. I’m hoping we don’t have any other last-minute fire-drills; the IOS bug was reported the day I was going to call RC1 final.
I keep on telling myself during the day “I’ll blog some developer news later when I’m too tired to code” and (shockingly) at 10 pm, after the second round of coding after the kids have gone to bed, I find myself too tired and go “meh, I’ll blog tomorrow.”
So in an attempt to post something rather than keep delaying…
Spock And Friends
The Vulkan API was released today. Vulkan is the third new next generation 3-d graphics API (the other two are Metal for OS X and iOS and DirectX 12 for Windows). Vulkan should be available on Windows, Linux and Android devices. The specification is 651 pages long, so I have some light reading to do.
Faster Cockpit Lights
FlightFactor sent me a test case to look at a while ago – a possible bug in the Blender 2.49 exporter. While exploring the performance of the test case, I discovered that the code that runs ATTR_lit_level in a cockpit OBJ was a lot less performant. (If you don’t create 3-d cockpits, ATTR_lit_level lets you turn the brightness of a 3-d model’s night texture up and down based on a dataref; it is crucial for creating cockpit lighting animations, including annunciators.)
I ripped out a pretty huge pile of code in the process, and I am hoping we’ll see a performance boost. On the mobile product (this code is shared on mobile and desktop) the changes cut the number of driver calls we make down by about 25%. (That doesn’t mean a 25% speed-up – not all calls are equal, but it shows that there was a real win in there.) My measurements of the ATTR_lit_level test case run the OBJ itself 10x faster. (Again, that doesn’t mean 10x the framerate – it means this one very small part of X-Plane runs 10x faster). Once the work is done I’ll post some performance numbers. This code is targeted at X-Plane 10.50.
