Category: Scenery

XPlane2Blender v3.4.0-beta.6

XPlane2Blender v3.4.0-beta.6

Change Log

One big massive bug fix! (and some optimizations!)

#264 caused some people’s lights to be put in the wrong place. The fix involved Ben coming up with awesome math to put things back in their place by a certain offset, and then us creating a way to parse the light.txt file that controls much of the lighting in X-Plane.

This Changes Nothing in Your Blend files!

Seriously! No Blender data should change!

However, It Could Change Your OBJs

XPlane2Blender is now more consistently WYSIWYG! Meaning that if you point a spotlight at a wall, it should show up pointing in that direction, regardless of what a named spill light thinks or the parameters of a param light think.

This is good news for new authors and authors suffering from the bug, but depending on how you’ve been making your lights appear rotated, it could result in needing to change the rotation or parentage of existing lights.

What Lights Are Affected?

All of the following conditions must be true for a light to be affected by this change

  1. Be a Blender non-point light, for instance a spot light
  2. The light’s XPlane Type must be Named or Param
  3. The light’s XPlane Name must be found in the lights.txt file inside the addon’s new resource folder

In rare edge cases, special and less used lights will be excluded from auto correction.

So, as you can see its either somewhat common or very specific which lights are affected. So, if your eyes haven’t glazed over yet,

Please Send Reports Of How This Affects You – Good, Neutral, Or Bad!

We try our best for backwards compatibility and a bug free existence, but we don’t know everyone and their situation until they say hi! If you are faced with large hurdles to continued productivity, please file a bug! Preferably with before and after pictures and .blend files. Automated fixes may be developed for people affected.

This is just one step to a more WYSIWYG XPlane2Blender.

Posted in Aircraft & Modeling, Development, Modeling, Scenery, Tools by | 7 Comments

Break ALL the airports! Correcting runways in WED 1.7 and X-Plane 11.10

X-Plane 11.10 brings a few changes to how airports, the airport gateway, and navdata interact.
Many pilots who try to fly realistic IFR operations with the X-Plane built-in GPS or FMS will have encountered this dreaded window already:

runway 12L not found at Vero Beach Municipal airport

The reason for this is that coded instrument flight procedures (CIFP) come from very reliable sources – Jeppesen or LIDO (depending on whether you get your data updates from Navigraph or Aerosoft), while the runways on X-Plane’s airports come from a community driven, open database: The X-Plane airport gateway.

Unfortunately, the airport gateway community is not always fast when it comes to runway renames or airport expansions, which happen all the time all over the world. The most common reason for a runway rename is a shift in magnetic variation: Runways are named for their cardinal direction relative to magnetic north. While the runway’s orientation with regard to true north is fixed[citation needed], the orientation measured against magnetic north changes over time, as the magnetic pole moves and local magnetic declination changes. Now when the magnetic course of runway 11L changes from 114 to 115 degrees, airports paint new numbers on their runways. 11L-29R becomes 12L-30R. Jeppesen knows about this and changes the runway name in all their data, which ends up in a data update for X-Plane. Meanwhile, the scenery author community over at the airport gateway of course has more exiting things to develop then a runway rename.

To make things worse, runway renames are super annoying in WED. After you renamed the runway from 11L to 12L, you had to go through ALL your flows, ALL your taxiroutes, and ALL your airport signs to change the name EVERYWHERE.

In the past, we have partially solved this problem by running mass renames of runways in the gateway database rather than through WED. If you see a change on an airport made by a user named “WEDbot” (like at this airport) that is usually such a batch-rename.

With X-Plane 11.10 and WED 1.7 there are some big changes that greatly improve the interaction between X-Plane airport data, navdata, WED, and the airport gateway.

Easy runway rename in WED

WED 1.7 has a function that changes all flows, routes and signs for you when you rename a runway end. This makes bringing an airport up-to-date a nearly foolproof operation even for a WED-dummy like me. You don’t need to be a scenery wizard to simply fix an airport anymore.

Silent runway rename in X-Plane

If you have navdata from Aerosoft or Navigraph, and a runway in the X-Plane airport matches a runway coming from the navdata, but the name has changed, X-Plane 11.10 now silently renames the runway at runtime for you. Which means, even if a 11L is painted on the runway, the FMC can load the procedure for 12L and get you there. This only works if the scenery is properly georeferenced and the runway is actually in the right spot – if the scenery was made incorrectly and the runway is not at the right coordinates, this obviously doesn’t work.

Silent threshold fix in X-Plane

Not all scenery authors correctly place displaced thresholds. A bit of confusion exists over when to use the white arrows or the yellow chevrons – and which counts into the runway length and which doesn’t. I teach my student pilots “the only thing you can do on yellow chevrons is crash – anything but crashing on that area is illegal.” Hence this area doesn’t count for runway length. Again, if you work off a properly georeferenced orthophoto, you won’t have any problems. Unfortunately, if you misplace where the (displaced) threshold is, this coordinate problem can feed back into the instrument procedures of this runway. For example, for many non-precision approaches the MAPt of the procedure coincides with the runway threshold, so if those coordinates are off, so will be your missed approach point. With X-Plane 11.10, if a runway in the airport scenery matches a runway coming from your updated navdata, but the threshold is laterally offset from where it should be according to instrument procedure data, X-Plane silently moves the threshold coordinates the GPS/FMS works off to the correct location. This works if the scenery is “good enough” in that the majority of the runway pavement is where it should be, and the thresholds are only off in the direction of the runway. If the whole scenery is ill-referenced, meaning the runway is off other than along its major axis, this obviously doesn’t work.

Silent and not-so-silent feedback

If you have enabled anonymous data collection in X-Plane, whenever your X-Plane silently applies a runway name or runway threshold location fix in the background, it also sends a packet of data to our analytics server, telling us the airport you were approaching and what was up with the runways. Collecting this data from a wide range of X-Plane 11 users will allow us to generate a heatmap, i.e. the most important airports that need the gateway communities’ love. Note that this data is collected only if you are running navdata that is current – we are not collecting reports based on historical data.

Only if both of the above fail, which means the airport has both a problem with its runway numbering and is ALSO poorly georeferenced (runways are in the wrong location geographically) the situation is beyond fix for the new runway logic. Only in this case you will see the dreaded dialog, because the runway simply does not exist in X-Plane, at least not where it should be. In this case, you will be able to submit an automatic report to the gateway website if the problem exists with current navdata. Note that this dialog will come up whether you have enabled data collection or not – but you can still chose to close it without actually posting the report if you don’t want to.
Only this kind of “all is lost” reports are actually visible on the gateway website and the XSG bug database. This allows artists to see the only airports that are actually so outdated that they cannot be fixed automatically. The automatically fixable scenery errors no longer clutter up the gateway airport bugbase.

Any downsides?

The downside to all these changes is that they all actively work to keep the X-Plane default scenery up to speed with the airport changes in the real world. This means that over time, as our global airports follow the real world in terms of runway renames, airport construction, expansions, etc… it will become less useable without up-to-date navdata. That’s the price we have to pay for “as real as it gets”.

Break ALL the scenery!

Poorly georeferenced scenery has a problem beyond affecting the missed approach points of non-precision approaches. It also affects the ability to use the new SBAS (satellite based augmentation system) approaches that are comparable in accuracy to ILS. I always prefer to fly the LPV approach if given the choice. However, the FAS block (final approach segment) comes from the navdata, which means it guides you precisely to where the runway is in the real world. If the X-Plane scenery is poorly referenced, the approach will dutifully fly you into the grass in X-Plane, if this is where the runway would have been in the real world. This is obviously a problem for serious training scenarios. Therefore, X-Plane 11.10 can be started with the commandline option –accurate_runways which will dynamically rewrite the actual scenery in X-Plane after loading an approach, both moving the runway into the correct geo-location and also changing the numbers written on the runway if needed. This obviously only works on default scenery with the procedurally generated runway textures. It will not change custom scenery that uses draped polygons for photorealistic runway textures. Moving the runway into the correct location will obviously also disconnect it from any incorrectly placed taxiways. Also, using this option increases load times for selecting an instrument procedure significantly, since it has to rebuild the airport scenery. So this option is really only there to help you keep limping along with broken scenery, if your operation absolutely requires accurate runways and you can live with some broken taxiways. It is therefore not available as an “official” setting. Do not come to us to complain about the jarring results – make a proper fix in WED instead! The results can be quite disruptive, but at least the approach won’t guide you into the grass:

This LPV approach required the runway to be moved quite dramatically. See the taxiway that was parallel to the runway in the scenery.
A closer look at the situation above. This is an extreme example. This airport scenery had the orientation of the runway badly wrong. Note where the threshold was originally placed by the author where the taxiway now ends in the grass.

Posted in Development, Scenery, X-Plane Usage Data by | 28 Comments

Do Not Reference Libraries By File Path

This is never okay in a library.txt file:

EXPORT  lib/something.obj ../opensceneryx/object.obj

This is a library path that refers to a file outside its own pack by using ../ to go up a directory and hopefully find that OpenSceneryX is installed, at which point it assumes that it knows the internal layout of OpenSceneryX and exports the object.

Do not do this.

This will become a warning as soon as I can write some code.

This will eventually stop working completely, because it’s a terrible idea that I have said multiple times should never be done.

Posted in Scenery by | 17 Comments

XPlane2Blender v3.4.0-beta.3 is out!

If you have been doing work with manipulators during beta.1, please download this new one and review the notes! Download the latest here:


  • #ATTR_layer_group_draped causing KeyErrors
  • Reverts bad change to manipulators properties*


“.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 in Aircraft & Modeling, Development, Scenery, Tools by | 5 Comments

Blender Exporter Testers

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.


Posted in Development, Tools by | 12 Comments

WED 1.6b2 available now

The latest WED 1.6 beta is now available to test.

This version includes multiple bug fixes, such as Ted’s fix to crashes caused by long tool tip text, and fixes when using orthophotos. See the included README file for the full change log, and, as always, let us know about bugs and problems on the Scenery Tools bug reporter.

Posted in Scenery, Tools by | 13 Comments

Experiencing unexpected crashes to desktop on WED on Windows 10? Here’s why…

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
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.

"Baggage Loader" + "Baggage Train" + "Fuel Truck (Jets)" + ""Fuel Truck (Liners)" + "Fuel Truck (Props)" = 81 characters in total.
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.

This new fix will soon make it into a beta and a release. Until then we have this nightly build available.

Final Thoughts

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!

Posted in Development, Scenery, Tools by | 22 Comments

The most boring feature of X-Plane 11 – New Navdata

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.

Work on the new database started in April 2016, when I got in touch with FAA representatives at the FAA Aviation Safety Center at SUN ‘n FUN where the External Data Initiative (EDAi) was launched. Preliminary work was completed by end of April, and feedback was provided to the FAA at the EDAi stakeholder meeting in Washington (the whole trip was quite a memorable experience). I cannot emphasize enough how valuable the open data initiative of the FAA is – this is an example of your taxpayer money at work.

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 incredible community 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.

Posted in Development, File Formats by | 34 Comments