You can get X-Plane 10.51r1 by running the installer, picking update, and checking “get betas”. Here’s a full bug fix list.
10.51 brings in a bunch of airports from the gateway that were built with WED 1.4.1 during the 10.50 beta process. It also has a few key fixes:
- If your aircraft’s airfoils have goofy values, it’s an error but you can still fly the plane.
- External visuals should be smoother when rolling the plane.
- Various window positioning and mouse clicking bugs are fixed.
- No more “colocated points” errors for ATC routes ending at ramps.
- Turbulence reduced when using real weather.
WorldEditor 1.5 release candidate three is posted. Hopefully this one is a keeper. The show-stopping bug was: the error margin for near-but-not-connected taxi routes was too large, causing it to incorrectly flag parallel parking spots for aircraft. Two other minor bug fixes went in too.
If you find a bug in the release candidate, please report one ASAP on the X-Plane Scenery Gateway bug reporter.
I just posted WED 1.5 release candidate 2. If you grabbed RC1 and hit the crash on export on Windows, please grab this ASAP and file a bug if your crash is not fixed. Of the four or five crash reports I received, two contained reproduction materials and both were the same bug – a crash when exporting a ramp position with no airliners, Windows only. This is now fixed.
WorldEditor 1.5 release candidate 1 just went up today. Please try it soon; we’re going to make this the official version for uploading to the gateway if no one finds any problems. This build fixes the last known validation bugs and has a bunch of improvements in the validation text messages; Jennifer, Ted and Julian did a complete review of the error messages (there are over 75!).
X-Plane 10.51 release candidate 1 should go up Monday or Tuesday; it has new airports and a few hot fixes for problems we found after shipping.
If you are the author of payware that won’t open due to an airfoil self-check failure, this is just a warning in 10.51, so your users won’t be frozen out.
But you should also fix the problem, as the self check fails only if you enter physically impossible values for the airfoil.
Update: a number of users have reported crashes on export in the release candidate. If you see a WED crash on export or validate:
- Please include a link to the scenery pack causing the crash.
- If you are on Windows and can provide a link to a minidump, that would be really useful. (You’ll have to do a link – even zipped, the minidump files are huge.)
- If you see a crash on a Mac, include the full text of the Apple crash report.
- If your pack requires tons of libraries, please indicate what libraries are needed.
Update 2: WED 1.5 release candidate 2 is out and fixes this crash, which is a crash on validate of a ramp start with no airlines, Windows only.
WorldEditor 1.5 beta 4 is available for download. The only major change here is that we seriously backed off the requirement to have hot zones off of the approach and departure ends of runways; this requirement is now only 100m.
I believe that with beta 4, our validation requirements are now correct; please attempt to validate your WED airport in beta 4 and file a bug ASAP if you find a problem. Otherwise, our plan is to make WED 1.5 beta 4 the required version for Gateway upload.
The only other remaining task to finalize WED 1.5 beta 4 is for Ted, Jennifer and Julian to go through the 75+ (really!) validation messages and review them for clarity and helpfulness. If WED tells you it can’t upload your airport, you deserve to know why!
WorldEditor 1.5 beta 3 is now available on the WorldEditor download page.
Besides a number of new features, WorldEditor 1.5 has much stricter validation checking; our is to get to a point where, if WED will export it, your scenery pack doesn’t have problems. This has two implications for the beta.
You’re Not Validating My Work!
If you haven’t tried a WED 1.5 beta, you may be surprised by how many validation errors WED finds. In particular, Ted coded a hot zone and runway analyzer that catches mistakes with taxi routes. It turns out that it’s really, really hard to get hot zones perfect by hand; even experienced WED authors who know all of the hot zone rules usually miss a few just due to the shear number of hot zones in a large airport and human error.
We have also seen airports on the gateway where the author clearly did not understand how hot zones were supposed to work at all.
We put the validation in because X-Plane’s ATC absolutely cannot function without properly marked hot zones; they are the only way that the ATC understands how airplanes are operating in the movement area. I think a significant amount of “weird ATC behavior'” will go away as we get better airport data that passes validation, and it will make the remaining real bugs easier to spot.
It’s not fun discovering that you have a big pile of problems to fix in your airport. To that end, we have been working on the docs to make sure that the ATC system is clearly documented, and we are now working on the validation messages themselves to make them more clear. If you find some part of the docs themselves that aren’t clear or have mistakes, please file a bug on the X-Plane Scenery Gateway’s bug reporter.
To be clear: airports already uploaded to the gateway with WED 1.4.1 will remain there, even if they fail validation; we’re not removing airports. But if you want to upload new work once WED 1.5 comes out, you will need to fix existing validation problems.
Who Will Validate the Validator?
The validation code may not actually be correct! People reported a number of high profile validation bugs, and they have been fixed in beta 3. But this doesn’t mean we have found all of the problems.
Please run your airport through beta 3, and if it fails validation, read the docs. If it seems like what you did is valid but WED is saying it is not, please file a WED bug on the X-Plane Airport Gateway’s bug reporter.
When WED 1.5 goes final, it will become the required version to upload airports to the gateway, so we want to be sure that the validation code is enforcing what we want enforced.
X-Plane 10.50 is now final – X-Plane will prompt you to auto-update the next time you run. Steam users – 10.50 should be posted on Steam within a day or so.
We are working now on a new beta of WorldEditor 1.5, which I hope to have in a day or two.
You can find the release notes here.
I think I forgot to blog this when it happened, but: a few weeks ago Chris shipped a free update to X-Plane 10 Mobile, completing an odyssey that has been going on behind the scenes for a few months now: X-Plane 10 mobile runs the complete desktop flight model from X-Plane 10 global. We now have one flight model to rule them all.
This is big for X-Plane 10 mobile not only because it brings a lot of additional detail to the flight model, but because it makes it possible to implement new features a lot more easily, since the complete simulator is backing these features.
How did we get here? X-Plane for the iPhone started when Austin and I ported X-Plane 9 to the original iPhone. We had a working prototype in two weeks and a shipping product in four (after which we, like, slept).
We were able to do this so quickly because the original iPhone was such a tiny device. The final program used between 28 and 30 MB of RAM total for everything. That’s all the code, all of the scenery data, all of the flight model data, all of the 3-d objects, and even all of the textures! By comparison, X-Plane 10’s startup screen is 16 MB.
Because our RAM budget was so insanely tight, we produced the product by starting with a blank slate on iPhone and X-Plane 9, and we moved only what absolutely had to be moved over to mobile. So instead of taking the whole flight model and then cutting fat, Austin copied in only what he absolutely had to have for those first few planes.
The technique worked – by keeping such tight control over what made it in, we kept our RAM budget down. But it also meant that the resulting code was pretty different from X-Plane – it was like someone took a book, cut out a bunch of words and taped them together into a short story.
Mobile devices are a lot more powerful than they used to be – at this point the top-end mobile devices are just about on par with the bottom end of desktop hardware. X-Plane 10 Mobile took a lot of technology from X-Plane 10 Global, and for the first time started giving back technology to the desktop as well.
Since the products have started sharing common code, we decided to try to re-unify the flight model (by bringing the desktop flight model as a whole to mobile); this makes it easier to move things around and saves us development time. With this process now complete, Chris will be able to move faster in developing mobile features, and we’ll be able to use more of his code.
(I like mobile as a test lab for the desktop version of X-Plane. Since the product is closed, we can rapidly prototype systems without compatibility concerns; when we’re done we can take the system to the desktop and the code will be blazingly fast because it was tight enough to run on mobile devices.)
As an example of code movement between the two products: X-Plane 10 mobile’s user interface started its life as…the panel editor in Plane-Maker! When I rewrote the panel editor (in X-Plane 8) I wrote a quick & dirty OpenGL UI toolkit to get some of the features that Plane-Maker didn’t already have.
Chris took that code to mobile and built it out into a complete user interface solution, with a richer set of classes, DPI independence, gesture support, performance optimization, and real font support.
That code is coming back to desktop, giving us things like DPI independence (4K monitor users know why this is important), beautiful typography, and the right tools to make a really great looking user interface. It’s nice to loan a piece of code to mobile and get the same code back only better. I think flight model sharing will provide similar benefits.
WorldEditor 1.5 beta 2 is up – you can download it here. Please report WED bugs on the gateway’s bug base.
This version of WED has a lot more validation than past ones did, so expect your previously “good” airport to fail validation. In particular, WED now validates that hot zones have been properly used around all runways in the ATC taxi route network. Getting hot zones perfect is very, very hard to get right by hand; the validation tool is meant to help you find the problems.
Jennifer is working on comprehensive documentation on ATC taxi route authoring; I’ll link to it as soon as it’s done. Our hope is that with the new docs and validation, everyone can understand how to correctly set up ATC taxi routes, and get assistance from WED to get them right.
Update: docs are up!
As some have noticed, we are not accepting uploads to the gateway from WED 1.5 betas. The issue is: if the validation code has bugs, then WED could (due to a bug) force you to upload an incorrect airport to the gateway.
I don’t know when we will allow uploads, but my guess is that within two weeks we’ll have a WED RC or final version that is ready to use.
For now your best bet is to use WED’s new tools to get the bugs out of your taxi layout and flows.
As some of you know, it was my plan to end-of-life the AC3D exporter for X-Plane; the decision was based on having limited resources to develop exporters.
The good news is: Andy Colebourne of Inivis has taken over development of the plugin, and has released the latest version of it – you can find it here. I am linking our download page to his forum link for easy access.
The AC3D plugin shares OBJ import/export code with WED and the rest of the Laminar Research C++ tools; my goal is to not break Andy’s work when working on WED. We use this code not only for WED object preview and the AC3D plugin, but for internal tools that pack up art for the iPhone version of X-Plane, so hopefully there will be some good leverage between the AC3D plugin and other Laminar scenery tools.
