If you have been doing work with manipulators during beta.1, please download this new one and review the notes! Download the latest here: io_xplane2blender_3_4_0_b3.zip
Fixes
#ATTR_layer_group_draped causing KeyErrors
Reverts bad change to manipulators properties*
Adds
“.beta.3” will be printed on all OBJs. This is not permanent, expect something better in the future
What happened to the manipulators?
A poor decision to change the Manipulator Type (Drag XY, Push, Command Knob, Toggle, Delta, etc) means that if you changed the type of manipulator between beta.1 (or 7fe534ad1f906b7853827 if you constantly check out the latest cutting edge commits [which I do not recommend for this exact reason]), this beta will make those changes irrelevant.
Example, suppose on 8/1/2017 you create a switch and set the manipulator type to Toggle, then with beta.1 you change the type to Push. Beta.3 will show the type as Toggle. All you need to do is go back to the switch and change the type back to Push. The rest of the values you set will still be there. If you created manipulators during the beta, they will be set back to the default “Drag XY” type and will need to be fixed.
This is an unfortunate lesson to be learned, and if you are facing a lot of tediousness (30 manipulators to hunt down and change) or potential errors (you can’t remember how many or which ones you changed) please contact me!
I will personally help you recover the changes you made during beta.1 – present.
Posted a few minutes ago: WorldEditor 1.6 release candidate 1. RC1 has a bunch of key bug fixes, is gateway-ready now, and can edit X-Plane 11 truck routes.
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!
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.
