Ted and I have been working on a new version of XPlane2Blender for Blender 2.5. The new version mostly focuses on bug fixes and optimizations to get perfect WYSIWYG output from Blender to X-Plane with optimal OBJ code.
If you use the version 3.3.x of this exporter and would like to try test builds, please email me. We have a suite of test cases that we run the exporter through to confirm that it is operating properly, but it’s also useful to run it on real-world examples to see if there are cases we missed.
We have received at least 5 bugs for WorldEditor that seem to have similar characteristics
Inexplicable crash to desktop with no error message
Happening on Windows 10, not reproduceable on Windows 7, Linux, or WINE
Happens shortly after using the Truck Destination tool
In short, until we get a new beta out that officially fixes the issue, try downloading this nightly build of WED. Also, see all the bugs that are marked as duplicate and related to WED-780.
What happened?
Windows Tool Tips and You
Tool tips are those little pop ups that appear when you hover your mouse over UI elements. Sometimes their text includes helpful tips, sometimes they include data; it is whatever we program them to have.
Hovering the mouse over a cell in the WED hierarchy pane makes a tool tip appear with its content as its text.
The code to do that is located in xptools\src\GUI\GUI_Window.cpp:1252-1272. Windows passes a message to WED saying the user has hovered over some UI element, we hand over some text to a data structure (NMTTDISPINFO), Windows uses the data to display the tool tip.
Look at line 1272. This is the line that does the copying our tip string into the szText for Windows to display.
//wcs = wide-char-string = Unicode string, cpy means copy, _s means "more secure" version of the function
wcscpy_s(
di->szText, //The data in here will show up in
80, //Our stupid magical number
convert_str_to_utf16(tip).c_str() //convert our UTF-8 string to UTF-16 to please Bill Gates
);
This line was the source of the crashes.
What’s so special about the number 80 and “_s”?
Window’s gives you a free “no-work” string, szText, for your tool tip text that is 80 characters long. If you want a longer tool tip, you’ll have to do a bunch of (not well documented) work.
What makes this a “secure” string function is it immediately ends the program if you attempt to copy more than the specified 80 characters into the new string. This information is overwhelmingly under-documented. In addition, the crash doesn’t included any information about the cause, even in debug mode!
How did this go on for so long without getting caught?
Amazingly, we’ve never really had this be a problem, or previous versions of Windows have had this function not crash. One reason why this is now getting reported is due to the Truck Destination tool’s Truck Types property. When you add up enough of those strings and hover your mouse over them, it quickly ends up being much longer than 80 characters.
With enough selected types, this easily reaches beyond 80 characters.
It is also possible we’ve just been getting lucky with our memory, always having strings getting corrupted exactly just right.
It is also possible that all our data is short, with abbreviations being so common in aviation, its normally hard to reach more than 80 characters.
Maybe no one reported a bug (please report your problems so we can fix them!)
Please comment if you have some ideas of why this doesn’t seem to happen on Windows 7, but does on Windows 10. Maybe this “secure” function isn’t as secure as we all think it is.
The solution: truncation!
Our easy fix for this is to chop a string off at 77 characters and append a “…” at the end. Hopefully no-one will mind this.
Thanks to a video sent in by a user, this was a pretty easy WED bug to find and solve. The hard part was weeding through all the bug reports that seemed shrouded in unrelated but related mystery. No one was realizing their most trusted friend, the mouse and common tool-tip, were causing the problem.
If you reported a bug, and this helps, please comment and contact us so we can clean out all the mysterious non-mysteries and get back to triaging bugs that have not been fixed!
Thank you for your patience as always as we try our best to make WED the best we can, and thank you to the people who report their problems instead of suffering through it, making a work around, or assuming their simply doing it wrong: You make the product better for everyone, including the developers!
While everyone looks at the new UI in awe, X-Plane 11 also had a few important changes under the hood. With Aerosoft Navdata Pro now also supporting X-Plane 11 beta, let’s talk about one of the most boring technical features of X-Plane 11: The completely redesigned database for navigational data, which makes it much easier for data providers like Aerosoft and Navigraph to supply data updates for the X-Plane navigational facilities, while preserving scenery compatibility.
The most important goal when designing the new database was to eliminate the duplication between data in X-Plane’s world and X-Plane’s navigation systems to leave less room for subtle inconsistencies. I also wanted to address compatibility of navdata updates and global scenery (mostly concerning localizers at airports). Other improvements were the integration of SBAS path points (needed for LPV approaches) and RNP service volumes. Last but not least I wanted the ability to work with ARINC424 data directly, and eliminate most of the subtle encoding differences that result from different providers generating files with slightly different converters.
The specification of the database was finalized in September, and both Navigraph and Aerosoft were provided the tools they needed to create navdata for X-Plane 11 in the new format. Actually, we are not limited to those “big two” – as the tool is available for everyone, open-data purists can actually generate their own navdata for the US and Canada using the FAA’s file.
With the great power of the unified database comes great responsibility: The navigational data can only be as good as the world scenery it is placed in, especially the airports. Some of X-Plane’s airports in the default scenery have not kept up with the pace the real world is evolving at: runways are renamed (due to magnetic shift), extended, built or closed and X-Plane’s airport scenery is only as good as the community who cares for it. To make their life easier, we are currently working on a big automated scenery update on the server side. We will rename several thousand runways all over the world on the scenery gateway soon, and this will solve the most annoying issue people are currently facing with the new database: runways not being found because they have been renumbered.
This automatic scenery update is however only part of the solution – because we can only rename runways we have! If an airport is extended in the real world because new runways are built, we rely on the scenery gateway and its incrediblecommunity for updated airports.
I took the time to write an even more boring technical article on how everything works together in X-Plane 11: Navdata in X-Plane 11. If you are an end-user, you don’t need to bother, because here’s the TL;DR: It’s awesome. It gives you RNP approaches for airliners, and LPV approaches for GA aircraft.
Writing this article though, when I compare it to the new UI, I can’t help but feel like the poor guy in this webcomic because this is exactly how the end-user will experience the change: Most won’t even notice.
A user asked me whether we would ever have a conditional directive in the OBJ format to let an author vary the look of the object based on weather. My answer:
Definitely not – this is definitely not the intention of conditionals!
The goal of conditionals is to allow authors to cope with multiple “rendering modes” of the engine, where:
The look of the sim is radically different between the rendering modes and
The performance cost of working around the lower rendering mode is expensive.
So for example, when shadows are off, you have to use some ATTR state change to drop a fake shadow on an object. This kills instancing, so when shadows are on (and the sim needs more performance), leaving that double shadow is not only ugly, but slow.
The conditional works by fully “stripping” those commands for shadowing from the object, then re-analyzing it.
So the win of conditionals is that you do not pay for what you don’t use, because everything is done on load – it’s like shipping two highly optimized objects.
But the down-side is: conditionals require scenery to reload, which is slow, disruptive and annyoing. This is why we would never use them for something that is dynamically changing in the sim, like weather or time of day.
We do want to have weather effects, but our approach is going to be very different: to have a “weather map” texture on the object (same UV as the object) indicating what sections of the texture will receive changes to their material due to weather effects. This will allow the object to look progressively more wet over time without a reload as the rain falls.
I would just like to add that this is one of my favorite WED releases not only because it’s a really strong release (we started with the goal of just supporting X-Plane 11 but ended up with fixes to long-time bugs, really solid validation, new authoring features for serious users, editing improvements, and complete support for the new X-Plane 11 apt.dat format) but also because of how little of the work I did. This release was a real team effort, with volunteers from the X-Plane community and LR developers all working on new WED features.
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 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.
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.
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.
