One thing of particular note for aircraft authors in this update: we added datarefs to read the contents of the X-Plane default FMS Control and Display Unit (CDU) screen. You can read more about this addition here.

The post X-Plane 11.35b5 is Out appeared first on X-Plane Developer.

If you haven’t already, this would be a great beta to test your add ons in to ensure we haven’t broken them. If we have, get at us via the bug report form and be sure to include a copy of your add on.

Edit: 11.35b3 is live on Steam too now.

The post X-Plane 11.35b3 appeared first on X-Plane Developer.

Please note that this is a major update and the minimum system requirements have now changed to: 64 bit versions of Windows 7/10, OSX 10.9, or Linux with GLIBC 2.23.

Major features include:

• Automatic background maps via OpenStreetmap and ESRI Orthoimagery
• New overlay layer featuring NAVAIDs and airport layout
• Adjustable text size
• Support for runway suffixes S, T and W
• Supports new XP11.30 apt.dat format with 8.33kHz channels for ATC frequencies
• Numerous bug fixes

For detailed information on the changes, see Michael’s write up here, or the README.WorldEditor file in the download.

The post World Editor 2.0 is here! appeared first on X-Plane Developer.

This RC has two simple fixes that are non-breaking and totally awesome.

• #347: Optimization that brings export time down by a third to a half. The file size remains the side and nothing is needed to activate it. Using the “Optimize” checkbox was not optimized this time around.
• #350, #351: Two animation bugs that would cause strange offsets when using bones. You may or may not have experienced this. Again, there is nothing to do to activate this, it is part of every export.

If you run into problems, please file a bug. If you do not notice a decreased export time with large models, also please tell us. We’d love to benchmark this on more data.

The post XPlane2Blender v3.4.0-rc.2 is out! appeared first on X-Plane Developer.

The complete list of VR-specific APIs is now:

• XPLMGetWindowGeometryVR()
• XPLMSetWindowGeometryVR()
• XPLMWindowIsInVR()
• A two-step process for allowing widget-based plugins to go to VR:
  1. Opt-in to the “modern” window APIs:
     XPLMEnableFeature("XPLM_USE_NATIVE_WIDGET_WINDOWS", 1)
  2. Use XPGetWidgetUnderlyingWindow() get an XPLMWindowID to pass to the XPLMDisplay APIs
• A new positioning mode to pass to XPLMSetWindowPositioningMode(): xplm_WindowVR
• Two new messages sent to your XPluginReceiveMessage() callback, useful for knowing when to move your window in and out of VR:
  • XPLM_MSG_ENTERED_VR
  • XPLM_MSG_EXITING_VR—Note that when moving back to the 2-D monitor, you’ll also want to reposition the window—if you just change your positioning mode, the window will be offscreen.

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.

The post New VR APIs Are Available Now appeared first on X-Plane Developer.

****EDIT2: We’ve found the issue affecting Vive and WMR. We’re testing a fix internally and will release an update hopefully in the next 24 hours. Please do not submit any more bug reports about Vive/WMR resolution.

11.20 VR4 is Live on the servers. Aside from the usability fixes that Ben already mentioned, the major ‘feature’ in VR4 is…Oculus users will no longer need SteamVR. If you downloaded it just for X-Plane, go ahead and remove it. It will no longer be necessary.

As we said we would do from the very beginning, we investigated the relative performance of X-Plane through the native Oculus SDK versus SteamVR and what we found, through data collection, is that the overall experience for Oculus users was better by going through the Oculus SDK directly. I know many of you are thinking “Duh! I told you that a month ago ya big dummy!” and yes…yes you did. Fortunately/Unfortunately, we try not to make engineering decisions based on gut feelings and anecdotal evidence when we have a way to collect actual numbers. We wanted to tackle a majority of the usability issues affecting everyone before we looked into performance.

In the various A/B tests that we performed, we found that going to the Oculus SDK directly got us about 25% improvement in frame rate. This does not necessarily indicate that there’s anything wrong with SteamVR itself. There are several factors influencing the performance in VR. First, Oculus has their “home”, that little bachelor pad where you hang out while waiting for games to load. SteamVR has their “home” as well. When you use SteamVR, BOTH are running on your machine. Those houses are not free and X-Plane is already CPU bottlenecked so anything consuming CPU resources is going to directly affect performance. (I noticed an Autodesk updater in my task manager that was stealing 5% of my CPU consistently. That too was decreasing my performance….every bit matters!). Going directly to the Oculus SDK removes the SteamVR house from the equation.

Sure, getting 25% improvement is a huge win, but that’s NOT the biggest win. The biggest win, in my opinion, is that Asynchronous Space Warp (ASW) works MUCH better even at very low frames rates down to about 22.5fps. It appears as though the timing of the frames is critical for ASW to work properly. Being at 22.5, 30, 45, 90fps feels smooth! Being in between those frame timings seems to make ASW lose its mind creating an annoying judder; the opposite of what ASW is supposed to be doing for us. Oculus seems to be V-Syncing us to hit those intervals, allowing their algorithms to make reliable timing decisions and predictions. It’s my suspicion that SteamVR was just not hitting those intervals, causing ASW to flip out.

TLDR; Performance for Oculus will be on par with what Vive users have been seeing all along. The smoothness of the rendering seems consistent even down to 22.5fps. If you’re a Vive user, you will still, of course, need SteamVR as that IS your native SDK. If you’re a WMR user, you will still need SteamVR. I have not seen any reprojection issues with WMR like we have with Oculus. Supposedly the upcoming versions of SteamVR have some performance improvements coming for WMR users as well so we’ll be sticking with SteamVR for all headsets other than Oculus. That can always change in the future…based on data.

The post X-Plane 11.20 VR4 Is Live appeared first on X-Plane Developer.

Electric and remote gyro systems

Back in April, I flew a Mooney M20J with a KCS55A HSI in it, and realised that it was impossible to model in X-Plane correctly, so I got to work. See the manual for an explanation of this popular HSI/remote gyro system.

I’ve written a usage guide on the new datarefs and commands that I added, along with some more detailed explanation of all the different gyro systems X-Plane simulates, in this guide for aircraft developers. I also talked about the systems at length in a Youtube live stream earlier this year.

Separate GPSS autopilot mode

This is a feature that many add-on aircraft already simulate to some degree, but by means of more or less reliable plugin trickery. The X-Plane 11 default 737 and 747 are no exception. With X-Plane 11.10, a separate GPS steering mode for the autopilot becomes a standard feature.
The new datarefs and commands are explained in detail here.

Screen-only popup instrument windows

Several people who build home-cockpit setups have asked about removing the bezels from the popup displays, so they can have only the screen of a GNS430/530, FMS or G1000 instrument to put on an external monitor, with a hardware bezel around it. While this can already be achieved through some clever hacking in the Miscellaneous.prf file, we now offer a more straightforward way to do this: The popup and pop-out windows now get their bezel graphics from the library system, so you can override the bezel graphics. How to override the bezel with nothing, if your bezel is made of hardware? Simply supply a 1×1 pixel blank .png as a bezel graphic, and X-Plane will know that you really want no bezel at all. In the case of a bezel-less 430, you’d put a 1×1 pixel png as the “cockpit/radios/GPS FMS/Garmin_430_2d.png” resource of your plane.

The post Three lesser known aircraft features for 11.10 appeared first on X-Plane Developer.

Download here:

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

Change Log

Bug Fixes

• #294 – A case where autodetect off was not fully trusting the author for Aircraft exports
• An uncaught spelling mistake __upgradeLocRot vs __updateLocRot. The fix for the updater altering the animation types was written for object’s dataref animations and bone’s dataref animation troubles. However, with this spelling mistake and Blender’s uncanny ability to eat exceptions from addons, it wasn’t realized until later that bone’s weren’t also getting updated. Fortunately, the updater can be run-again without fear of messing something else up.

At the bottom of the Scene Settings, check “Plugin Development Tools”. Use the Re-run Updater tool at the bottom: Put in 3.3.9 in Fake Version, and click the button. You should see your bone values corrected, as long as you successfully reverted any bad changes from v3.4.0-beta.1. Please e-mail me if you have problems!

Improvements

• Some spelling and capitalization in the UI. Great care has been taken to ensure that none of the actual value or order of the addon properties has changed!

The post XPlane2Blender v3.4.0-beta.4 arrives appeared first on X-Plane Developer.

So far so good (aside from one big breaking problem)!

Fixes

#289 periodic filename_ext error notifications.
#288, 292 loc/rot/show/hide upgraded improperly

Add X-Plane Layers button for new projects now longer hidden

Adds

• Re-run updater button – USE WITH CAUTION! – to force re-running the updater as if the file was previously saved with a different version of XPlane2Blender

See the next release here, download the .zip here. As always on-topic feedback is appreciated!

The post XPlane2Blender v3.4.0-beta.2 is out! appeared first on X-Plane Developer.

This post is a request for comments from programmers who write plugins that used to draw to the map—it is not a place for general feature requests for the map, or for off topic comments. (And off topic comments will be deleted.)

Background: What broke the map drawing in the first place?

Long story short, the map has changed drastically since the X-Plane 10 version—it didn’t just get a fresh coat of paint.

The biggest obstacle to backward compatibility comes from the fact that we now use an honest-to-God cartographical map projection for map coordinates. Moreover, the map projection changes for different map types—the normal map UI uses a transverse Mercator projection, while the GPS units use a stereographic projection. For that reason alone, just “splatting” old drawing code on top of the new map would not give you the results you want… the old OpenGL local (x, y, z) coordinates do not have a straightforward mapping to the new projected latitude/longitude locations.

A second major change is the fact that the map can now rotate to match the heading of the user’s aircraft. Unless you like the possibility of your map labels being printed upside down, this requires awareness of the map’s rotation and the fact that north isn’t necessarily “up”.

The final big change comes from the draw order. The map is now very strongly divided into layers, and we draw in 3 stages:

1. Backgrounds (e.g., terrain)
2. Icons (e.g., airports, NAVAIDs, etc.)
3. Labels

An individual layer can draw in any or all stages. (For instance, the airports layer draws both airport icons and labels for each icon.) We draw each stage from the bottom layer up, beginning with the terrain at the bottom, then the NAVAIDs & airports somewhere in the middle, and then finishing with the aircraft at the very top. This layering ensures that bigger or less important elements don’t cover up smaller or more important elements—your aircraft, for instance, will always be visible (and selectable), even if it’s in the exact same place as a fix or NAVAID. Likewise, the label for your element will always be visible even if the actual icon is obscured by something above it. (In practice, of course, readability is going to be poor if you have labels overlapping, but that’s not really solvable without much more powerful cartographical tools than we have now.)

While it’s not essential that plugin drawing code respect the layering draw order, it would certainly be nice—it would allow you to ensure that a) your plugin-drawn layer doesn’t cover more important info, and b) less important info doesn’t cover your layer.

Proposed API

With all that in mind, our proposed API for map drawing looks like this:

• Plugin code would call the SDK to create a new map layer. To do so, you would provide:
  • An optional drawing callback for OpenGL drawing (which would be layered beneath all built-in icons & text, but above things like X-Plane’s terrain drawing).
    • OpenGL drawing here is more or less a “free for all,” with one exception: manipulating the Z buffer is not allowed, due to our reliance on the Z buffer as a means of preserving layer ordering.
  • An optional icon callback, where you would provide a set of PNG icons to be drawn, along with their heading, opacity, etc., and X-Plane would “splat” them onto the map above all built-in icon types except the aircraft
  • An optional label callback, where you would provide a set of strings for X-Plane to draw above all built-in labels except the aircraft label
  • An optional “prepare cache” callback, called whenever the map’s total bounds change (e.g., when the scenery loader loads new DSFs). This allows you to keep your drawing callbacks fast, since you can cache only the data you need for drawing in the current area.
  • A flag to indicate whether you’d like your new layer to be disablable from the UI (if so, we would add a checkbox to the right-hand sidebar like we have now for the flight path and compass rose)
• Drawing, icon, & label callbacks would receive:
  • The currently visible bounds of the map
  • The current zoom level of the map
  • The map units per unit of UI coordinates (useful for drawing text at a fixed size regardless of map scale)
    • If your layer is drawing in the standard X-Plane map window, this is map units per boxel; if you’re drawing within the GPS unit, it’s map units per “virtual device pixel,” whose size in real screen pixels is of course fluid since the user can move the camera relative to the GPS in the panel.
  • The map’s current mode (currently one of either sectional, low enroute, and high enroute)
  • An opaque handle that provides access to the new projection APIs. The projection APIs would provide the following functions:
    • project a latitude & longitude into map coordinates for drawing
    • unproject an (x, y) pair of map coordinates into a latitude & longitude
    • get the scale, in map coordinates, of 1 meter at a given (x, y)
    • get the heading (in degrees clockwise from “up”) corresponding to north on the map for a given (x, y)—this is necessary since the X-Plane 11 map can be rotated to match your aircraft’s orientation
• Relative ordering of plugin-created layers would not be guaranteed. So, if you had two plugins which drew the same icon in the same place, but one drew in red and the other in blue, we would make no guarantees about which color the user saw. (And, indeed, some users may see red and others may see blue.)

Questions we have

While the proposal above meets what we believe the needs of third-party developers to be, we almost certainly haven’t considered every use case for this API. (And it’s possible we’re missing important features even for the use cases we have considered!)

To that end, here are some question you, dear plugin developer, can answer for us:

• What’s your use case for the map drawing API?
• Does the proposal above sound workable for your use case? (If not, what’s missing, or what would you change?)
• Do you like the idea of allowing plugin developers to specify whether their new layer is togglable from the standard map UI? (If not, why, and what policy would you like to see instead?)
• Do you have a use case for click selection and click-and-drag functionality in your plugin-created map layers? (This isn’t on the table for the initial update to the map API, but it’s a possibility for future updates.)

The post RFC: Plugin-Drawn Map Layers in X-Plane 11 appeared first on X-Plane Developer.