Blog

New VR APIs Are Available Now

Plugin developers, Beta 5 includes a few new VR-specific APIs in the XPLMDisplay header.

The complete list of VR-specific APIs is now:

I’ve updated the VR sample plugin to take advantage of all the new stuff here, minus the widget API—really, once you enable native widget windows, your widget window becomes “just another XPLM window” as far as the display APIs are concerned.

Posted in Uncategorized by | 8 Comments

X-Plane 11.20b5 Is Out

X-Plane 11.20b5 came out this week – notes here. Beta 5 fixed the rest of our open rendering engine/material bugs, including artifacts on orthophotos. If you are a scenery or aircraft developer, please check your aircraft or scenery against 11.20 beta 5 and make sure there are no rendering changes compared to 11.10. If it looks different than 11.10 in a bad way, we don’t know about it and it’s not going to be fixed if you don’t say something.

Over the last year we’ve been working quite a bit internally to automate testing. We still do a lot of hand-testing (that is, Jennifer flies the sim and then tells us we’re bozos) but we also have extensive infrastructure to script the sim. So we’re looking to automate the process of checking third party scenery for rendering artifacts, so we can catch more rendering bugs more often.

I’ll post once 11.20 is final about how to get your custom scenery into our test. My hope is that with automation, we can catch bugs faster and you (the third party author) can have your add-on tested without having to do the work yourself.

I’m OOTO next week but if things go well, we’ll have a release candidate when I get back.

Posted in News by | 9 Comments

Let’s Talk About CEF

In the X-Plane 11.20b1, we’re shipping a web browser for the first time. We’re using the Chromium Embedded Framework (CEF)—essentially the same guts as Chrome, wrapped inside X-Plane.

For the time being, it’s being used in one place only*: to support in-app upgrades, so that if you have the demo, you can buy the full version of X-Plane without having to go to the web site. The web view is seamless—you can’t tell by looking at the app that it’s not just part of the native X-Plane user interface.

While its present use is quite limited, if all goes well, we’d like to expand its use elsewhere in the sim—in The Glorious Future™, we could potentially use it to load online charts and the like.

But, there’s a hitch!

There’s not a good way to load two copies of CEF at a time. And, since some plugins (like the ones used in the new Flight Factor A320 Ultimate) depend on a version of CEF provided by a (global) plugin, we have to disable X-Plane’s web browser functionality in the presence of that plugin. This isn’t a big deal right now—after all, if you’ve installed payware, you probably already own the sim anyway—but it will be a shame if, in The Glorious Future™, you have to choose between your payware and core X-Plane functionality.

The situation is even worse than you might expect: CEF absolutely doesn’t support multiple initialization calls in the lifetime of an app—you can’t initialize it, shut it down, then re-initialize it. That means it’s not even possible for plugin authors to be good citizens and “relinquish” CEF to X-Plane, such that you could at least use X-Plane’s browser whenever you’re not using an add-on that depends on it. It’s all or nothing! In fact, you’ll have to uninstall the CEF plugin before X-Plane can use a web view itself.

There are two possible fixes here:

  1. At some point in the future, we provide access to CEF via the plugin SDK. If we did, it would have to be to the C API only—no fancy C++ wrappers for you. Speaking as someone with the memory of writing for the C API fresh in his mind, let me say: this isn’t a whole lot of fun, and it’s rife with the potential for memory leaks. Moreover, this would break any existing addons that depend on CEF—they would be forced to migrate to the SDK version of the API.
  2. We could (theoretically) compile an X-Plane-specific version of CEF that would not conflict with the version plugins are using. This would require renaming all the Objective-C symbols on Mac, and renaming the DLL on Windows. I’ve not investigated this for feasibility, but it’s certainly theoretically possible. This would allow X-Plane’s version of CEF to coexist with (one) plugin-provided copy, albeit at double the CPU and memory cost.

Having us expose CEF via the SDK is not an unequivocal win. CEF is notoriously incompatible between versions—you can more or less guarantee that even minor updates will break compatibility of the API somewhere. That means X-Plane would be stuck at a fixed version of CEF for at least the lifetime of a major version to prevent breaking plugins. X-Plane 11.20 uses CEF release 3202; it would be at least the next major version before we updated CEF to a newer version. There are two major downsides to this:

  1. When X-Plane updates to that newer version, it would break plugins compiled against old versions of the SDK that depend on CEF. That’s a lot more aggressive than our normal deprecation policy, and it makes CEF plugins a potential maintenance headache for plugin devs.
  2. If your add-on really, really needs features from the latest and greatest CEF release, you’re out of luck—wait a couple years (!!) and maybe we’ll update.

So, here’s what I’d like to hear from plugin devs:

  1. Are you currently, or are you planning to use CEF in the future?
  2. Would you be willing to use the C version of the CEF API only?
  3. Would you be able to accept the limitations and potential headaches (outlined above) of X-Plane-determined CEF versions and compatibility?

If you don’t mind telling me a bit about your intended use cases, that’d be very helpful as well!

EDITED TO ADD: There’s a third option here that I didn’t consider: X-Plane could provide a “wrapper” around CEF that offers “just” a browser surface, and simple interfaces like the ability to change the URL programmatically. This has the advantage that we could update CEF regularly without breaking the API (though there’s always the risk that a new version of Chromium would change how it handles your HTML + CSS + JS). The disadvantages are twofold:

a) If a plugin developer really, really needs the full power of the CEF API, they’re out of luck (or we’re back to square one with respect to having to disable core X-Plane functionality in order to support the plugin).

b) New XPLM APIs are a massive tax on our development time. Every time we need to make a change, we have to go test a dozen plugins… then go through an extensive beta… then inevitably hear about a show-stopping bug we introduced three hours after a release goes final. 😀 In contrast, providing a (major-version-stable), transparent copy of CEF costs us very little dev time; time that would otherwise be spent maintaining the XPLM API can be spent on, like, major features.

* Aside: This is actually how we test a lot of new tech in X-Plane: we find a single, relatively out-of-the-way place to make use of it, ship it in a major version update, and wait to see if it blows up. Betas catch a lot of bugs, but not all, so this is a way of hedging our bets when it comes to code that hasn’t been battle-hardened. This is how we worked the bugs out of the user interface framework (Plane Maker’s panel editor was the testbed), the X-Plane 11 particle system (behind the scenes, it was used for some very minor effects in X-Plane 10.51), and more.

Posted in Development, Plugins by | 48 Comments

More X-Plane, More WED, More Docs

After much bug fixing, X-Plane 11.20 beta 4 is out – here are the fixes. This beta fixes Linux performance, a few material rendering bugs for custom aircraft, and a bunch of X-Plane SDK bugs for VR.

We have a new WED 1.7.0 release candidate – hopefully the third time’s a charm!

And…we have docs on the vrconfig.txt file format. The VR config file is used to add VR-specific data to an aircraft, including:

  • Hot spots for seats (E.g. where does the pilot sit).
  • Extra data for manipulators.
  • Parameters for the yoke in VR.

Please do not ship your add-ons based on 11.20 VR tech – wait for us to go final. All file formats are subject to change during beta!

We are reaching the end of beta, for both WED and X-Plane. We’ll see, based on incoming bugs, whether we need a beta 5 before RC; hopefully WED 1.7.0r3 is a keeper.

Posted in News by | 65 Comments

Beta 4 and VR Docs Are Coming

We’ve been working on 11.20 beta 4 for a while now – the goal for beta 4 is to fix all of the SDK/authoring bugs and have docs for the new VR file formats. We’re making good progress; beta 4 should be this week, barring an unforeseen bugtastrophy. (Linux users: perf should be fixed with beta 4.)

We received a number of bug reports that beta 3 was showing large numbers of _vrconfig errors with third party aircraft. So this seems like a good time to re-iterate our policy on file format stability and betas.

  1. Don’t ever ship an add-on that uses an undocumented file format. You can’t guess what the fine print is from example aircraft.
  2. File formats are subject to change during beta, and are not stable until we go final. Don’t ship your add-ons against beta file formats.

In our case, the _vrconfig.txt file format changed in beta 3 and will change again in beta 4; as Chris wrote docs, he found issues that he is fixing.

Our priority during beta is not stability of your add-on, it is getting the file format right, so we’re not stuck with a buggy file format for the rest of time.

Once we go final, we’ll put compatibility code in to support the final version shipped in X-Plane when needed.

Similar logic applies to the SDK – it’s fantastic that people are using the latest SDK to test their plugins in VR, but don’t hit the “ship it” button until we’re final – it is always possible that the SDK will change in a way that breaks compatibility during the beta.

Posted in News by | 39 Comments

New Lego Bricks for Airport Designers

X-Plane 11 has had several fantastic updates to the library of lego-brick airport objects that ship with X-Plane. We’ve had new European-style objects, elements for small airports, and the terminal and jetway kits let you build really great looking airports that fit the exact shape of the real-world airport you are modeling.

In that context, I’m pleased to show you a sneak preview of the next set of lego-brick objects for gateway airport authors.

You can download a preview if the new lego bricks here.

Posted in Development by | 34 Comments

TGIF

A while back, during branch testing for X-Plane 11.20-something, I encountered this little gem:

Happy Friday!

Posted in Blooper Reel by | 13 Comments

X-Plane 11.20 Beta 3 Is Out

Release notes detail the bug fixes here. We have another set of bug fixes that will go into beta 4 next week.

We’ve received a number of bug reports from plugin developers trying to use the new plugin APIs. We’ll have another beta next week to address the rest of the open issues, including the ability to (finally) use widget-based UI in VR.

Beta 3 fixes the MFD brightness going crazy in the G1000 C172, and fixes shadow casting on transparent-alpha-textured objects, but we still have an open bug with panel brightness in a Carenado aircraft that looks like a low level rendering bug. 11.20 has a lot of change to the rendering engine to support VR, performance and our migration to Vulkan and Metal, so authors: please be on the lookout for changes to how your models render compared to X-Plane 11.11.

If beta 3 isn’t found to be a smoldering wreckage of poorly thought out C++ over the next day, we’ll post a Steam version of the beta.

Posted in News by | 54 Comments

X-Plane 11.20 Beta 2 Is Out

It’s like beta 1, but without the missing art asset. 🙂

We’re working on beta 3 now, which will have some fixes for rendering bugs. A few notes:

  • This is not going to be a typical eight-week beta. Please go check your add-ons this week.
  • The biggest area of code change for VR that affected other parts of X-Plane was the rendering engine. I’ve fixed 3 rendering bugs where I broke something while restructuring the renderer for VR, and none were surprising. Please check your aircraft or scenery pack for visual defects and let us know!

Steam users: we should have beta 2 up shortly.

Posted in News by | 17 Comments

WED 1.7r1

Release candidate builds for WED 1.7 are now available for testing. A big thanks to Michael for leading a lot of this development. He kept all this moving along at a much faster rate than if we’d been left to our own devices! Here is his summary of the changes you’ll find in this version:

Selection of items

When selecting any item in the map pane, WED now prioritizes the items by a what appears to be on top when viewing the scenery in X-plane. So if you click on any .OBJ in the middle of a taxiway – it always selects the .OBJ, line marking or ground painted taxi sign rather than the underlying taxiway. Similarly, it selects the facade or forest rather than anything that is flat and draped on the ground.

Technically, this means object type and LAYER_GROUP rather than WED hierachy based prioritization.

Exclusion zones and airport boundaries are now kindof “hollow” items, they can no more be selected by clicking inside of them, but only by their frame/outline or perimeter. That should greatly help with not having to lock or otherwise get those large area items out of the way.

All items can now be single-click selected, even if they are located within the area of an already select item. This eliminates the need to de-select (CTRL-D) e.g. a taxiway every time the last attempt to click select a .OBJ turned out to be just a bit to far away. And therefore accidentially selected the whole taxiway underneath it instead.

Drag-moves are now subject to some “stickyness” , i.e. the move/copy only starts after the drag exceeds a few pixels. This helps avoiding accidential very short distance drag-moves. Once the item has “broken free”, the item can be moved back to within a single pixel of the initial location, so small moves can still be achieved.

Several bugs that prevented adding bezier handles to nodes under some conditions or selecting very closely spaced items are fixed as well. All operations now require a click no closer than 4 pixels from the “correct” location. Any very closely located items having the same piority (like two nodes of the same polygon) are now selected using a “whatever is closest” strategy, rather than having overlapping bounding boxes prevent access to all but one of them.

Validation warnings and results browser

Some validation issues can now be a warning only, rather than a hard error. This allows WED to try more validation of frequently found problems, even at the risk of creating a few false alarms in rare cases. If such a warning is ignored for gateway submissions, the gateway moderator will determine on a case-by-case base if the issue can in fact be waived or still reject the scenery submission.

After validation, a full list of ALL validation issues will pop up, allowing to browse and zoom to / highlight all issues to help planning out the work required to pass validation. This also allows to select multiple validation errors to e.g. select ALL duplicate vertices in ALL polygons – allowing to fix all with a single editing operation.

New validations

Validation now catches all types of self-intersecting polygons. Previously there were certain cases of bezier-curves that caused taxiways/polygons to stop showing up at certain zoom levels or not at all in X-plane, despite they looked fine in WED or vice versa.

The coordinates and names of runways need to be exactly in sync with the CIFP data used by X-plane for FMC SID/STAR and GPS approaches. For this reason, gateway airports are occasionally edited by a script by “WEDbot” to achieve this, but any user re-submission that touches the airport may break this effort. WED now validates the runways against CIFP data oit obtains direct from the gateway server and requires the runway threshold to be within 10m of the exact location. Note this is the thereshold – the wide white bar only.

There is a separate warning only if the displaced part of the runway (the optional part from the end of the runway to the threshold – with the centerline arrows pointing towards the displaced threshold) mismatches official documentation. Some of the CIFP data mis-states that displaced distance, so it is a warning only. Please thoroughly verify such warnings against current orthoimagery and draw as per current real world markings.

A *lot* of ATC flows on the scenery gateway are non-functional because of misunderstandings how flows work. The most common mistake is to define one flow per runway and then expect that X-plane somehow finds all flows that fit the current weather pattern and uses them all togther. But that’s not how flows work. Validations will now try to find such duplicate condition flows (that are effectively never ever used) and will warn about it.

The airport naming is covered by several new errors (like ALL CAPTIALS – THATS SHOUTING IN THE INTERNET AGE !) and warnings if undesired elements are included in the names.

Smart runway rename

When a runway is re-named due to magnetic variation changes, not only the runway name, but also all ATC taxiroutes, flows and taxisigns need to be fixed up to reflect the changed designation. WED now will detect such edits of a runway “name” property, find all these references, update them and let you know. This greatly helps when the runway validation tells you it’s missing some runway at that airport – which usually means some existing runway was recently renamed due to magnetic variation changes.

More library item previews

Type 1 facades are now displayed in the library preview panel. Please be patient – the more complex “type 2” facades as used in all airport terminals and the new terminal kit are not showing, yet.

Many library items come with multiple variants that X-plane will select at random from when placed in the scenery. For such items, a button will show up to view each variant. But keep in mind – there is no way to tell X-plane to always use a specific one. Its just a true “FYI”, only  …

All forest/facade/object previews will show some textual information about their size and features available.

The World Map in the background now has 9x the resolution and shows true X-plane ground texture colors.

ATC taxi route names are displayed in the ATC TAxi & Flow view – please verify them for consistency, as the X-plane ATC uses and even speaks these names when providing taxi instructions.

Don’t import from the apt.dat for gateway airports

The apt.dat and .dsf formats are lossy, i.e. they contain less information and use less precision than a direct import of the airport from the scenery gateway. WED will now warn anytime it detects such an import for an gateway type airport.

Upon im/exporting to/from the gateway WED will now also show warnings if the gateway is currently not accepting new submissions for that particular airport.

Facade editing

Facades without roof’s or filled areas, like fences and skylights in the XP11.10 terminal-kit are now allowed to have 2 nodes only – previously facades of any type had to have 3 nodes minimum.

Two bugs were fixed, too – these prevented selecting certain wall types in the terminal-kit facades and displayed some facades as being “closed rings”, rather than line-type items in the map window.

Orthophoto import

Georeferenced image “geotiff” import used to require mercator projected, WGS84 referenced coordinates. On Linux and OSX it will now understand pretty much all coordinate systems defined in the EPSG standards – although WGS 84 lat/lon coordinates are still the preferred encoding.

Display speed and memory use

When zooming in at airports with very large, single piece taxiways, the WED display speed used to slow down significantly.

The 64-bit versions of WED (OSX & Linux. Windows is still 32 bits, only) used a lot of RAM with large sceneries, e.g. im/exporting the *whole* global airport scenery (thats what WED is used for at LR, all 28,000 airports in one scenery !) maxed out a 16GB RAM machine. Now its down to near half that and everybody else gets a small speed boost, too.

Preferences menu

Some user adjustable settings (like meter vs feet) are now moved to the File->Preferences (OSX: WED->Preferences) menu, stored in WED’s global preferences and no more loaded/stored with each individual scenery file.

Posted in News, Scenery, Tools by | 6 Comments