X-Plane 11.10 Beta 1 Is Here

To get it, make sure you have an X-Plane install you can scrap, have a stiff drink, and check "get betas" in the installer.

Release notes are here. I'll try to post more over the weekend about some of the new stuff, but there's a lot, and we've probably left things off the initial notes. For now, since it's beta 1, our main concern is "does it work at all?"

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in News | 75 Comments

Public Beta This Week

We've been working on bug fixes like crazy, and over the last week or two we've run a small internal beta of 11.10 to try to get the biggest, nastiest bugs out.  So far it looks like we're on schedule to put out a public 11.10 this week.

Besides fixing bugs, there are still a few irons in the fire for 11.10 that might go into the beta after public beta 1:

  • Sidney and I have one more set of performance optimizations that are a "maybe" for 11.10 - we'll try them and if they blow up the beta, they can wait for 11.20.
  • Jörg has fixed a lot of weapon-related issues - you can actually author fighter planes now - but weapon cam is still inoperative and probably will be in beta 1.
  • We are working on VR in parallel to 11.10, and we may be able to release some authoring interfaces for aircraft in 11.10 to get aircraft developers a head start.

A bunch of stuff for developers and artists is already done and 'in the can' for beta 1:

  • The new plugin API 3.0 will be fully available in beta 1.
  • The G1000 will be available in beta 1, and the G1000-based Cessna is included in the install.
  • New art for airport authors is in place.

In preparation for this beta, Jennifer ran off to Las Vegas. We might reasonably disagree on how to interpret that.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development | 26 Comments

Beta Testing 101

X-Plane 11.10 is the first major version release with a lot of code changes and new features. By design, this version has a lot of big changes in it that we've held back for weeks or even months. This also means it is more likely to be unstable and buggy, especially for the first few beta releases.

We've recently progressed to internal beta testing. Now we should have a public beta sooner rather than later, so I wanted to bring back out some great tips on beta testing that Chris wrote way back in 2012. Nearly all of the info remains as relevant today as it did 5 years ago, and I've included his best practice tips below. Continue reading

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Testing | 86 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.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Scenery, X-Plane Usage Data | 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.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Scenery | 17 Comments

New Plugin Packaging for the SDK 3.0

This is a small feature but for plugin developers it may make a huge difference in work-flow.

In the plugin system up to version 2.1 (everything we've shipped through X-Plane 11.05) plugins are packed like this:

my_plugin/
my_plugin/64/mac.xpl
my_plugin/64/win.xp

This has one problem: every plugin on your install is either named mac.xpl, win.xpl, or lin.xpl.

And as it turns out, pretty much every debugging tool ever assumes that each DLL will have its own unique name because it'd be crazy to do otherwise. The decision to make the file name in the fat plugin structure the OS was a really dumb one by me.

With version 3.0 of the SDK, you can now pack like this:

my_plugin/mac_x64/my_plugin.xpl

and with that format, each plugin's name makes its DLL unique.

This should fix a bunch of things:

  • You'll be able to start X-Plane via X-code to debug your plugin without all hell breaking loose.
  • Back traces on Windows debugging tools should make the plugin executing clear even without symbols.
  • Any kind of memory map dump (including those in Apple crash reports) will unambiguously show what plugin code is loaded into what memory address.

The existing 2.0 format (fat plugins shown above) and 1.0 format (thin plugins, supported only in the global plugins folder) will continue to work indefinitely - they're still there.

But if you are going to target X-Plane 11.10 and use the new plugin system features, you may want to use the new packaging and save yourself some debugging chaos.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Plugins | 10 Comments

XPlane2Blender v3.4.0-beta.5 arrives

Download here:

https://github.com/der-On/XPlane2Blender/releases/tag/v3.4.0-beta.5

Change Log

New Features

Build Version Numbers

XPlane2Blender's new version number system will allow us to debug .blend and .obj file even faster. It should also make making updates to the data model easier to implement.

  • Every exported .obj file's footer contains information about the addon version, when it was compiled, and why. For example: 3.4.0-beta.5+1.20170922151901

A break down of the components

  • 3.4.0: The traditional Blend addon number
  • beta: The type of build cycle we're in. Other choices you may see are dev (a developer build), alpha, rc (for full release)
  • 5: the build type version we're on. Since this is beta 5, the build type version is 5.

The elements after the + are generally less meaningful to the average user

  • 1: The version of the data model (the properties and settings for XPlane2Blender, used for comparing changes
  • 20170922151901: The "build number" date this source code was packaged and released in the form of YYYYMMDDHHMMSS in UTC.

Communication

The build version number is partially shown (elements after the + are hidden) in the scene settings under Composite Normal-Textures, potentially along with warnings about the stability of the build you are using.

Examples

When starting this version of the beta, you will see this:
scene_version_comminucation

A future stable version of 3.4.0 for the general public will show this:
scene_version_communication_rc_ex
Notice the green check mark and lack of any warnings.

In a future pre-alpha cycle for 3.4.1, two types of people will see the following:
scene_version_communication_dev_ex

  1. A developer writing and testing unreleased code
  2. Someone who didn't head the warning against using such code, or get scared off by the nuclear symbol and extra warning about a lack of a build number

It is the worst case scenario for stability and traceability, hence the nuclear symbol.

Why the extra warning about a lack of a build number?

A lack of a build number indicates that you do not have a good dialog (e-mail, chat, this release page, or other channels) with a knowledgeable and attentive developer. This means your work is more likely to be run through a bad version of the code and damaged, or your bugs will be harder to diagnose and repair.
scene_version_comminucation_rc_no_build_nmbr
In this case, despite the code appearing to come from a stable era of the code near a release, there is potential for something to be wrong and have very poor ways of tracing what it could be - hence the lack of green check mark and big red warning symbol.

If you see some new pre-alpha feature you'd like to try, just ask us about it first. Going forward, we want to start with a dialog about potential dangers, testing, and intentions of an incomplete feature rather than an autopsy later on. Don't be scared, we always love hearing from users before there is a problem, not after!

Build Version History

Also, all .blend files will be keeping a log of every different version of XPlane2Blender that they are opened and saved with. This is automatic and needs no involvement from the user. Those who are curious can look in the Plugin Development Tools section at the bottom of the scene settings and see the history of their file.

Note: This does not record any history data about Blender versions, other addon versions used, timestamps opened or saved, or changes made to it (including XPlane2Blender settings changes). It is purely useful as a debugging tool, and is not fool proof.
build_history

This .blend file started as a legacy 3.4.0 pre-beta.5 file, and was then with a copy of 3.4.0-beta.5, with no build number. Then it was used with 3.3.12, then finally, used with a build of 3.4.0-beta.5 created on 09/18/2017 at 01:27:30am.

One could use this information to guess what transformations the data could possibly have gone through along each step of its journey.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Plugins | 1 Comment

Aircraft shadows and icons in 11.10

With 11.10 there is a new way aircraft only shadows are done, as well as how aircraft icons are generated. The big change is how we calculate the volume of the aircraft which up until now was based on all OBJ files that the aircraft ships with, including things like ground- and fuel trucks, stairs etc. The reason this is undesirable is because the greater the volume of the aircraft, the worse its realtime shadow quality will be because we use the volume of the aircraft to calculate our shadow map area. The bigger that area, the worse the shadow quality and the more pixelated it will look like. In an ideal world, the aircraft volume tightly hugs around the actual aircraft and we get the best shadow quality possible. With 11.10, hopefully this ideal world is finally here!

Why and how we failed before

Before 11.10 the aircraft volume was based on the volume of, well, the aircraft. However, this includes things such as the aforementioned ground trucks, fuel trucks and what have you, that artificially blow up the volume calculation. The problem is, all these objects are technically part of the aircraft (eg. we move them around with the aircraft), but they are for the most part invisible and most people wouldn't actually consider them to be part of the aircraft proper.

In 11.05 we added a change to also consider the physical volume which kind of has the right size for the plane but doesn't include OBJs. It is based on the physical size of the plane only, which sounds like it's the right thing. However, as it turns out, this volume breaks badly for things such as helicopters because the rotor of some third party helicopters are attached OBJs and won't be considered part of the physical volume of the helicopter.

At this point I should probably also quickly note what happens if the shadow volume is too small: Everything that gets clipped by the shadow volume will cast a shadow into infinity and beyond due to the way the shadow mapping works. This is especially bad for the helicopters that now have very quickly rotating bits that are constantly clipped by the shadow volume resulting in shadows flickering all over the place.

In short: What we want is a shadow volume that is as tight as possible around the aircraft for shadow quality, but not too tight because that also leads to problems.

What's new in 11.10

In 11.10 the algorithm to compute the shadow volume has been completely changed. Instead of trying to jiggle around with the physical volume and the volume of all OBJs together and then coming up with a sane value, X-Plane now looks at what is actually being rendered. We start out with the physical bounding volume as before, but then we look at what is actually rendered! For that, we go through every OBJ that is marked as casting shadows and run the OBJ engine as if we were to render the whole thing. So OBJ animations as well as kill datarefs etc are considered. This happens during the first frame, so everything is set up the way it would be during normal rendering. Everything that is visible will be marked as such and the shadow volume will be expanded to include this OBJ.

The result is a volume with a tight fit around what is actually visible and therefore considered "aircraft". Everything else is not included in the shadow volume and therefore stops casting shadows altogether. Of course, this is only in aircraft only shadow mode and is not used when scenery shadows are on. In that case, everything is handled like it was before and everything that is supposed to cast shadows does cast shadows. So, if you see missing shadows in aircraft only shadow mode, this is probably due to this change.

To visualize the differences, here are 4 screenshots showing the quality difference as well as the new shadow volume:

 

One thing that should be noted though is that going forwards these kinds of extra OBJs should really be done via the new drawing API in the 3.0 SDK! This allows us to very accurately determine the size of the aircraft but it also means that culling will become more accurate. The old method will of course continue to work, but it's not the best or most efficient way to approach ground vehicles and other ground clutter.

Aircraft icons

The calculated volume for the whole aircraft with attached OBJs was also used for the aircraft icon generation. This led to some weird cases where the camera was positioned in such way that the aircraft was incredibly tiny due to the fact that we tried to get "everything" in at once. So far the recommendation was for authors to create a version of their aircraft without all the extra OBJs attached, but now that we have an adequate measure of the aircraft volume this is fixed as well! Aircraft icons should be correctly generated now with the camera positioned to capture the plane at the right distance.

There is one more fix for aircraft icons: Some authors created aircraft that did some clever culling based on where the pilots head is and then using the kill dataref to prevent parts of the aircraft from being rendered. Reading the view dataref now correctly reports the camera as being an external camera so that those custom culling solutions work with the aircraft icon generator. If your aircraft still doesn't generate proper icons after 11.10, please file a bug report and let us know!

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft | 26 Comments

Plugin Compatibility and New XPLM 3.0 Features

Tyler posted about some of the new features coming to the X-Plane SDK version 3.0 API (available with 11.10 once we find the last bug and move it somewhere else). Here's how compatibility works for the windowing system.

First, since the 2.0 SDK, XPLMCreateWindowEx has taken all of its arguments in a structure, a XPLMCreateWindow_t. That structure, in turn has a structSize variable that is meant to be initialized like this:

XPLMCreateWindow_t my_win = { 0 };
my_win.structSize = sizeof(my_win);
my_win.froblinator = xplmFull_Of_Eels; // etc.
XPLMCreateWindowEx(&my_win);

Now when we revise the SDK, the size of the XPLMCreateWindow_t structure grows when you #define XPLM300. This results in new plugins compiled with the new SDK sending in a large struct (with more callbacks) and older plugins compiled against the old SDK sending in a small struct.

This is how the SDK "knows" what SDK you are using and provides new behavior to new plugins but provides compatible behavior to existing plugins, compiled years ago.

(This technique isn't in any way new or unique to the X-Plane SDK - you can tell by the coding conventions that it is cough, cough, borrowed from the Win32 SDK.)

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Plugins | 8 Comments

Improving AI Aircraft

AI planes face two major issues in X-Plane 11:

  1. AI aircraft are often way more resource-intensive than they need to be. Users are fine paying a performance penalty to load, say, a super detailed 3-D cockpit model for their own aircraft, but for AI planes, where you’re never going to be in the cockpit, there’s no reason for that sort of thing. A significantly “dumbed down” version of the same aircraft would allow users to load more AI planes at once, with no visible downsides during normal use.
  2. Many aircraft, for one reason or another, simply won’t function at all when used as AI planes. This is most commonly due to one of two issues:
    • reliance on third-party plugins (which only work for the user’s plane)
    • lack of support from X-Plane for flying aircraft like this (for instance, the X-Plane AI doesn’t know how to fly gliders, seaplanes, or rockets)

As a user, this is really frustrating, because it’s difficult or impossible to know in advance which aircraft will work as AI planes and which will either a) just sit on the runway, never able to take off, and/or b) tank your frame rate.

Coming in X-Plane 11.10: AI-Only and User-Only Aircraft

In the upcoming X-Plane 11.10 beta, we’ve added two new options to Plane Maker’s Author window: “supports user flight” and “supports AI flight.” By default, all aircraft support user flight, and do not support use as AI aircraft.

If a plane is configured for AI flight only, it will never be shown in the normal aircraft grid—only in the AI aircraft window.

If a plane is configured for user-flight only (or if it’s a pre–11.10 aircraft with no “supported flight type” info), it will be hidden in the AI aircraft window by default, but for the sake of backward compatibility with old planes, users will still be able to reveal them by checking a box labeled “Show aircraft without AI support.”

The upshot for aircraft authors

In the Glorious Future, we envision third parties shipping two versions of their aircraft:

  • one marked user only, which include all the bells and whistles, plugin-enhancements, and as much detail as possible
  • one marked AI only, which is stripped down for performance, only using plugin enhancements that have been tested in AI configurations.

The result will be a faster, more consistent, less error prone experience for users.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft | 19 Comments