I have a lot to cover here – a little for everyone I think.
10.25 Release Candidate 1 Is Up
If you are a third party developer using 10.22, and you haven’t participated in 10.25 betas, please go do so now. You can get the beta by running the installer and clicking “get betas”. (If you run the beta, you are auto-notified to update.)
This build sneaks in object-killing in Plane-Maker; thanks to the aircraft developers who took time to privately test this feature last week!
A Fix to the Plugin SDK
This section is just for the programmers. I investigated a three-way conflict between X-Plane 10.25, Gizmo 64-bit and the new 64-bit XSquawkBox, and what I found was a bug in the C++ wrappers that ship with the X-Plane SDK headers. XSquawkBox was using them, but they were not correctly updated for 64-bit.
They are now. So if you use the “XPC” C++ wrappers in your plugin, please go get the new headers!
I’ve written about this before on the X-Plane dev email list, but the short of it is that ‘long’ as a datatype is not safe for plugin use. A long is 64-bits on Mac/Linux but 32-bits on Windows. If you use long, your data structures change size, which is never what you want.
The SDK widget APIs sometimes store widget IDs (which are pointers) in integer slots. in order for this to work, the slots must be 64 bits wide. The old SDK (and XPC wrappers) use ‘long’ for this, but the correct type is intptr_t. The SDK made this change a while ago, the XPC wrappers made this change now, and you should be sure that your plugin isn’t using “long” with the SDK.
The failure mode of mixing ‘long’ and ptrs on Windows is exciting: the upper 32 bits of the address of the widget get cut off; as long as you allocate your widgets early, your widget address is probably less than 2^32, and you are okay. But if your plugin loads later, your widget IDs (which are secretly ptrs to structs) will be > 2^32 and converting them to long changes the address, crashing the sim.
This is exactly why Gizmo appeared to be “crashing” XSquawkBox: XSquawkBox was using ‘long’; if Gizmo ran first and allocated memory (which Gizmo is well within its rights to do!) then XSquawkBox’s widget IDs would be greater than 2^32 and the ‘long’ bug would kick in.
(I don’t know when Wade will release an updated XSquawkBox, and I do not plan to discuss XSquawkBox any more on this blog. You can follow XSB here.)
Whose Bug Is It Anyway?
The XSquawkBox + Gizmo crash illustrates an important point: if two add-ons work by themselves but crash when used together, we can’t know which add-on is at fault without more investigation.
In this case, the bug was in XSquawkBox. But before I investigated on my computer, Ben Russell reported to me that removing some initialization code from Gizmo also “fixed” the problem (in that it made the symptoms disappear). Yet we know from investigation in the code that XSquawkBox had the bug (using long for pointers on Windows).
The moral of the story is: if two add-ons crash together, we can’t know which add-on is fault by which add-on changes to “fix” the problem. It is very common in the OpenGL world for the driver team to change the driver to work around buggy apps, and for apps to work around problems in buggy drivers. A change to code might be a fix for a bug, but it might be a work-around, avoiding a bug that still exists.
Here’s my take-away point: identifying a conflict between two programs is a way to narrow down a bug, but it is not a fix. We (Laminar Research) almost always ask you to remove add-ons when you see a crash. This is not a fix! We want you to remove add-ons to identify the conflict between X-Plane and a particular add-on (or between two add-ons). The next step is for us to figure out why the add-on might crash X-Plane or vice versa. Typically we prefer to contact the add-on maker directly to get technical information. What we are looking for is an identified conflict with the minimum number of variables.
We’re on release candidate three of WorldEditor 1.2.1. RC3 fixed export of 970 airport files to include frequencies and fixed a bug where you could end up with a two-point hole in a polygon (which would then cause the airport to fail validation).
Hopefully this is the last RC and we can call WED 1.2.1 done shortly.
Huge thanks to Wade for getting the beta going, and to Christian for writing brand new Mac audio support!
Besides being big news for VATSIM users (who were stuck in 32-bit land from now on), 64-bit support is a great fit for XSB because it uses a lot of memory for CSLs, and thus was never very happy as a 32-bit plugin.
This announcement is just that; an announcement. XSquawkBox is not a Laminar Research product. Please do not report bugs to us (Laminar Research). Thanks!
Update: Wade says that this build is time-limited. This is the first public build; he’ll release a time-unlimited build once he’s sure he has the bugs out. So think of this as a public beta.
X-Plane 10.25 beta 3 is now available. If you already have 10.25b1 you will be prompted to auto-update. This build adds some new dry-climate urban textures; here is a comparison.
10.22
10.25b2 with dry urban
If we don’t find any more show-stopping bugs, there will be one release candidate, with some updated level-of-detail distance internal settings.
In the future, I will try to write up the scope of changes for the beta-run when the first beta comes out, so you don’t have to ask “will you fix X in this beta?” For small betas, we try to have all intended fixes available in beta 1, but sometimes (such as with dry urban textures) the fixes go into later betas because they are not ready).
10.25b2 is Dead On Arrival. This happens periodically to betas – they pass internal tests, I upload them, and then immediately find something bad wrong with them that is a show stopper.
So for now 10.25b1 is the current beta (again) – just re-run the updater if you accidentally got beta 2 in the 10 minutes that it was available. Beta 3 will be up as soon as I can get a new beta cut; due to the time it takes to sync our servers, that might be late tonight.
See the beta wiki for what was in beta 2 – beta 3 will be all that plus it should actually work.
X-Plane 10.25 beta 1 is now live on the servers. Release notes here, bug reporter here. Please do not submit beta bugs on this post. There are a few big features of this update that I want to mention in a little bit more detail than the release notes go into.
Community-Created Airports
This is the first release to include airports with 3-d buildings submitted by the community. We have received over 250 submissions so far; last I counted there were over 35,000 objects placed in those airports.
If you are working on an airport that you have not submitted, do not panic; we will continue to collect airports and release patches regularly to get them to all users. We are also working on web resources, documentation and training to help make the creation process more accessible.
(A few pictures of default airports at moderate settings, airports picked at random.)
In these pictures I have tried to align the far views with the airnav overview pictures so you can get a sense of how closely people can and can’t match the real world with the airport library elements.
Urban Terrain
For the longest time, our cities have looked like a big green blob. We have been working on this for a while; the problem is actually a three-part one.
The urban terrain we shipped wasn’t very good – in some cases it wasn’t even meant to be released.
The application of urban terrain to cities errs on the side of vegetation (and not concrete) in the DSFs, due to problems with the DSF zoning algorithm.
The autogen footprints don’t persist when rendering settings are turned down.
The urban terrain in 10.25 beta 1 addresses problem (1) for wet climates. I am hoping we’ll get a working dry-climate urban terrain set before the beta is over, but that is still in progress.
What about the other issues? We have a fix for (2) in our DSF generator, so recut cities will have better far-view balance than the first generations do. We have ideas on how to fix (3) for a future update.
In these pictures you can see a far view of New York City in 10.22 (shipping now), 10.25 (new wet urban terrain), and 10.25 with a recut DSF fixing zoning, based on the current DSF generation code we hope to use.
Wide view of NYC area as ships in 10.22.
Wide view of NYC area with new urban wet terrain from 10.25 beta 1.
Wide view of NYC with 10.25 urban wet terrain and recut DSF.
Hopefully you can see from these images that while the new urban terrain helps, it works best when the zoning bugs are fixed in the DSF as well.
Edit: to be clear, 10.25 does not ship any DSF recuts. We have not yet shipped recut tiles. The NY City pictured is a recut DSF I made for myself last night for code testing purposes; it illustrates improvements to the DSFs due to new data and bug fixes in the generation algorithms.
I just posted a beta of WED 1.2.1; hopefully it will only take one beta to get this quick “bug fix” patch done.
Some usability fixes:
Locked and hidden items don’t cause clicks to select their parents.
The interior of an airport boundary is not selectable – it never should have been.
The marquee tool will never select the “world” entry on the hierarchy.
The click hot spots of handles don’t shrink at low zoom – they were doing that before, which made clicking hard.
(Basically Chris tried to use WED and got really annoyed*, so we dug in and fixed some of the smaller annoyances. The ones we left (like how locking works) need a major rework and can’t go into a bug fix.)
1.2.1 also filters out the private and deprecated library items (once you have X-Plane 10.25, beta coming “real soon now”). This should make the library display a lot cleaner. Also, hidden airports won’t export or fail validation, which is what you would expect.
The only other changes are a bug fix for exporting polygons on a DSF edge, and a bunch of changes to help Robin collect global airports.
If you are using WED 1.2r4 to make airports, please try 1.2.1b1 this weekend, and file bugs here.
* Which was difficult to differentiate from his normal state.
Now that the final season of Breaking Bad is over, we can finally all get back to work on X-Plane!
I kid – while it is true that we maintained an internal betting board on the ending of the fifth season of breaking bad, we’ve actually all been heads down working on new code for the last few weeks. A few bits of status update:
It looks like we will cut a 10.25 with new art assets after all. Currently in the queue: Albert’s new terrain textures, a few library tweaks to get the sim ready for DSF recuts, revised urban terrain textures for cold wet climates, and texture optimization for the airport scenery library.
About those urban terrain textures: Alex has revised urban terrain textures for cold wet climates, and they’re a nice improvement over what we shipped. Our goal is to use the new revised urban textures for all climates, but we don’t have the variants yet. I’m going to put the cold-wet ones into 10.25; we’ll get the rest out when they are available. (Why delay a fix for New York just because we don’t yet have a fix for San Diego?)
I’m working with Robin to try to get some user-submitted lego-brick airports into the update.
Alex has a bunch of partly done autogen work, but based on my last discussion with him, it looks like it needs to go into a bigger AG update and can’t be distributed in pieces, because a lot of the autogen shares common textures and objects for performance.
10.25 won’t be a big code change – we’ll have a fix for Foreflight compatibility and a few other small bug fixes, but 10.30 will be the next major code-changing release. The goal of 10.25 is just to get art out.
Alpilotx is re-importing OSM data this weekend; I’m not sure what the time frame will be for DSF recuts, but my goal is to make sure that 10.25 can run recuts. This way we can push recuts before 10.30 if that’s how things get done.
…are greatly exaggerated. I was out of the office last week on vacation (for the first time in 2.5 years) and didn’t bother to post first. Austin and Chris were also out on vacation for at least a week each.
We are not dead, we are not out of business, and we are definitely not stopping development of X-Plane 10! Austin has been working on X-Plane since approximately 1637 (well, the 90s at least) and he is not going to stop now.
Stuff We’re Working On
I am still working with Alpilotx and others on DSF recuts. This work is moving forward, but my side at least is going slowly because I am also working on other features that are pre-release and have not been announced.
I also had some time to do some OpenGL modernization over the last two weeks before vacation. This code does not directly improve X-Plane, but it sets us up to improve performance: once we have more modern code we can get access to newer GPU features.
Upcoming Releases
At this point I am looking at two releases:
Some kind of short-beta release to roll out new terrain textures, some of the userr-submitted lego-brick airports, and possibly a few small bug fixes.
Then a long-beta release, where we could put a major feature or two, and also ship code that needs more serious testing (e.g. the OpenGL modernization).
Over the last few years that I have been working on X-Plane, the time between major patches has been steadily increasing. Back in X-Plane 7 or 8, we might have a major patch every three months; with X-Plane 10 that interval is more like six months. I think this longer time between major betas is good for X-Plane 10:
It lets us run longer 8-week betas without being in beta perpetually. This gives third party developers more time test.
Fewer larger patches means less work for third parties, since a major patch means retesting add-ons.
X-Plane 10 is a much bigger product than X-Plane 6 – it needs a longer development cycle.
Still On Fire?
The other factor making it seem quiet around here (besides slower major betas and the occasional time off is that we are finally moving out of fire-fighting bug-fix mode into doing structured development. When we were fixing bugs in X-Plane 10.0 as fast as possible, a bug fix was followed by a beta and announcements as quickly as possible.
Now that we have a stable 64-bit build out, we’re writing code that looks to build the future of X-Plane, rather than just fixing its past. So the quiet you hear now should hopefully turn into good features in the future.
X-Plane 10.22 release candidate two is now officially final – if you did not participate in the beta program, you will get the update via auto-update. This build provides X-Plane-managed memory allocation for Lua-based plugins on Windows, which should help the problem of Lua plugins running out of memory.
If you have add-ons based on SASL 1.0 64-bit, you will need to get an update from the airplane vendor that uses SASL 2.0! Please do not report SASL 1.0 64-bit crashing on Windows; this is a known problem with SASL 1.0 64-bit that was fixed with SASL 2.0 64-bit.
