All aircraft in the X-Plane 12 world cast a wake turbulence – a wing cutting through the air in X-Plane 12 leaves a vortex in the air that swirls inward over the wingtip, and sinks slowly as it dissipates energy over time. The strength of the vortex and its lifetime depends on the lift force generated by the wing (i.e. a wing that has to lift a 172 does not create a strong vortex, whereas a wing that supports a 747 surely does). Over the course of its life, the vortex sinks slowly and is displaced by the prevailing wind.
Flying through such a vortex can be dangerous! If you cross the vortex left by an airliner while flying a 172 yourself, be prepared to be tossed around or even flipped upside down. If you do the same with roles reversed, you might see a slight bump just enough to ripple the surface of your coffee (be sure not to do this in an A350 as spilled coffee can cause in-flight engine shutdowns).
Wakes left by AI aircraft
AI aircraft in X-Plane run the full flight model. That is, each wing is calculated using the same methods and with the same accuracy as for the user aircraft. Thus the amount of energy left in the wake vortex is clearly known, it just comes from the flight model. Therefore, if ATC clears that 747 to take off before you, be sure to stay above their flight path until you can turn away from it. For landing, stay above the preceding planes path and touch down slightly further down the runway than they did to stay safe.
Wakes left by online traffic, live traffic, and other plugins
For aircraft that are not run by the X-Plane flight model, such as other players’ aircraft from an online network, or real-world traffic injected from a plugin like Live Traffic using data from an ADS-B exchange, X-Plane makes a best effort guess based on the data provided by the plugin. The plugin can tell X-Plane how heavy the aircraft is, and its wing area and wingspan. In the absence of this data, X-Plane will fall back on a fairly conservative light aircraft estimate, assuming a Learjet-sized aircraft weighing 10 tons with a 12m wingspan. This means you are not going to get flipped upside down in your 737 if you end up flying through a wake left by an old plugin. This is to minimize user frustration with existing online flying plugins. Since the wakes are technically an extension of the TCAS override API used by plugins since X-Plane 11.50, all plugins that show traffic in X-Plane 11.50 are compatible with wake turbulence generation and will gain that base functionality automatically when used in X-Plane 12.
Wake turbulence data for plugin authors
Plugins can use new datarefs starting with X-Plane 12 to inform X-Plane of physical properties of the non-player aircraft that are then used for a more accurate strength and duration of the wake. By writing to the new datarefs, a plugin providing traffic data can upgrade from the “generic Learjet wake” to an accurate wake representative of the aircraft they are actually drawing.
Learn about wake turbulence avoidance
In X-Plane, you can cheat and make the wake left by an aircraft visible by having it drawn in the sky in a color scheme showing its danger (from red over orange and yellow down to green) so you can avoid it (or fly through it on purpose to experience the effect). Wake visualization is just one of the many graphical flight model outputs available. Press Ctrl+M to toggle graphical flight model output in X-Plane. By repeatedly pressing Ctrl-M you can cycle through all the visualizations available, while a small white label tells you what you are looking at. Keep toggling until you see “Wake Turbulence” displayed and marvel at the air disturbance waiting to make your day interesting.
You can also use X-Avion on your iPad to have wake turbulence danger zones visualized – this works in real airplanes using ADS-B data, and it works in X-Plane when driving X-Avion over network.
As you saw at Flightsim Expo, X-Plane 11.30 offers a wide range of new features for airplane authors, who wish to make their airplane engines and systems more realistic. This post links to the documents with technical details that are of interest to aircraft authors mostly. End-users are encouraged to try the Cessna 172, King Air C90 and Boeing 737 of X-Plane 11.30 to experience more fidelity in true-to-life autopilot and other system simulation.
Oxygen System
X-Plane has two separate oxygen systems, bottled/compressed O2 and chemical oxygen that can be used for both general aviation aircraft and airliners with separate crew and pax oxygen. How to set up the system for you airplane is explained here: //developer.x-plane.com/article/the-x-plane-oxygen-system/
Besides engine-driven vacuum pumps, X-Plane can now also simulate venturi-powered vacuum systems as found on vintage aircraft and electrical backup pumps that are sometimes found in slightly better equipped general aviation aircraft. The interaction of all the pumps, manifolds and instruments is explained here: //developer.x-plane.com/article/vacuum-systems/
Propeller-driven aircraft can have distinct behavior of the prop governors reaction to engine failure or loss of oil pressure. Depending whether your plane is a single or multi-engine, whether it is driven by piston engines or propeller turbines, and wether the turbines are of the free-rotating or single-spool design, the equipment might be drastically different. X-Plane now features negative torque sensing in addition or instead of auto-feather, overspeed governors and fuel topping governors, to make turboprop aircraft even more true-to-life: //developer.x-plane.com/article/propeller-feathering-systems/
X-Plane now comes with a few pre-configured autopilots for airplane designers to chose from, and offers more flexibility in creating a custom one.
General Aviation Autopilots
X-Plane 11.30 adds support for single- and dual-axis rate-based autopilots, control over the trim servo, and a separate static system for an altitude pre-selector.
Airliner Autopilots
Airliner autopilots learn new auto-throttle modes, Control Wheel Steering, have two independent flight directors and up to three channels for auto land. They can optionally even have a directional servo for CAT 3 landing rollout guidance.
The documentation for tuning the autopilot constants has been clarified and expanded with new sections about the new autopilot functions in 11.30: //developer.x-plane.com/article/x-plane-autopilot-params/
Finally, have a look at the X-Plane airliner autopilot in action, performing an auto land in a gusting cross wind:
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.
These smaller features are likely to be overshadowed by the release of the G1000 for default aircraft in 11.10, so I decided to dedicate a blog post to promote the articles I’ve written – you can find them among all the guides for aircraft developers: //developer.x-plane.com/docs/aircraft/
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.
With X-Plane 11.02 the built-in GPS and FMS units for X-Plane 11 aircraft will also display heliports and seaplane bases. While this change is obviously needed badly for the helicopter flying community, improperly configured fixed-wing aircraft might suddenly feel themselves confronted with unsuitable options in the nearest airport selection pages and on the moving map.
Filter criteria
Every X-Plane aircraft has three parameters for airport and runway filtering that can be used to configure the moving map. These settings have existed for a long time, influenced which airports were displayed on the moving map, and kind of worked with the X-Plane 10 GPS as well. X-Plane 11 completely broke those settings for airplanes using the new X430/530 GPS, and not all aircraft authors go through the trouble of setting them up correctly.
X-Plane 11.02 correctly filters airports for GPS and FMS use as well as for the moving map based on these parameters. Because the GPS now also displays heliports and seaplane bases, it is important to set these filter parameters correctly in Plane Maker, to prevent unecessary clutter on the map.
The three settings are:
Only Airports on Map – If not checked, the GPS and moving maps will show helipads and seaports. Check when you do not want those to show up in the nearest airport list on the GPS
Only Paved Runways on Map – If not checked, the GPS and moving maps will show airports with no solid runways like grass, gravel and water surfaces
Minimum Runway Length to Show on Map – This will filter out airports where the longest runway is shorter than this distance
Note that the these settings work on a per-airport basis. That means:
At an airport with both runways and helipads, the helipads will still be shown regardless of setting.
At an airport with both paved and grass or water runways, both runways will still be shown.
In other words, airports are filtered out if they ONLY have helipads, or ONLY soft runways
For seaplanes, leave the “Only Airports” box unchecked but enter a runway length number in order to supress the heliports.
If you already set these parameters in the past and they worked in X-Plane 10, there’s nothing for you to do. If you never bothered to set them, and suddenly see places inappropriate for landing show up in your built-in GPS, that is why.
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.
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 incrediblecommunity 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.
Despite many of the Lufthansa Pilots being on strike, Ben made it to Paderborn for the 13th FlightSim Conference in Germany. The event was held at the Paderborn airport, where the airport fire brigade pulled out two of their fire engines to the tarmac – the freed up hangar space was then used as the exhibition floor.
The FS Konferenz starts with a developer’s dinner, were FSX and X-Plane developers drink beer together talk about the development experience, then has a day of public exhibition, talks and interaction with users and ends in the traditional “captain’s dinner”.
We are extremely satisfied with this year’s conference. Not only were there more exhibitors and more visitors than last time, but also the impact of X-Plane is growing steadily. This became evident not so much in the public exhibition space, but in the little ad-hoc sessions we had with other developers. FSX developers who would not have touched X-Plane with a ten foot pole a few years ago were now asking us questions: How do I make a great landclass scenery? How do I make my add-on work with the X-Plane weather engine? How can I make 3d grass next to the taxiway in a way performance doesn’t suck? How do I program a gauge for X-Plane?
I think we are in for a round of new add-ons that will finally come to X-Plane.
Users with newer Ubuntu versions have reported they can’t get X-Plane to start after the update to 10.30, while it worked fine with 10.25.
Since 10.30, X-Plane links to libudev to discover devices like the Oculus Rift on Linux, and that has caused a few hiccups with some of your Linux installations out there.
No, this post is NOT about the Oculus Rift on Linux!! If you want to know the current state of Oculus Rift development, go and read this one. Though there’s a little update: At OC1, Oculus confirmed they still want to support Linux. They didn’t say when, though.
Back to libudev. X-Plane for Linux is built on a very old Linux distro, Ubuntu 10.04LTS server, which is horrendously outdated by now. But it has the advantage that binaries built on that an old version, will work with basically ANY distro out there today. Basically, the older the distro is we choose for building, the more distros users can run the binary on.
The problem with libudev0 though is, it is so old, that modern distros just don’t ship it anymore! You can only get the newer libudev1. As a work-around, you can simply sym-link libudev.so.0 to libudev.so.1 to make X-Plane find the newer version.
Starting with X-Plane 10.31, we will remove the load-time dependency on libudev again so everything is back to working like it was on 10.25.
In the future, we will load libudev dynamically based on the version the Oculus SDK requires (This is when an Oculus runtime is available for Linux, which currently isn’t).
Summary:
X-Plane 10.30: you need to create a symlink if it doesn’t work
X-Plane 10.31: no need for a symlink because we won’t depend on libudev at all
X-Plane 10.x: X-Plane will ONLY require libudev when you are using the Oculus Rift
As many of you are aware, we have been showing custom versions of X-Plane with support for the Oculus Rift at different shows and conferences. Naturally you want to get your hands on it as quickly as possible, and some of you have engaged in lively discussions on the forums and in the Steam community, which is why I’d like to give you a quick update on the current state of development.
First of all a big “thank you” to Bob from RC Simulations, who provided us with a DK2. His order was in the first batch, and he generously lent it to us until ours got delivered a few days ago.
The good news is that my DK2 now sort-of works with X-Plane on my Mac and PC. Now hold your breath, because the “sort-of” is an important part of the story. The bad news is that Oculus recently introduced some fundamental changes into the way the display of the Rift is exposed to the operating system. The changes were quite disruptive and haven’t even made it to Mac and Linux yet.
The latest SDK from Oculus comes with a proprietary display driver for Windows, to allow for a smoother display with less motion blur because it runs at 75Hz (instead of the 60Hz of virtually every computer monitor nowadays). This driver apparently works okay for Direct-X based games, but doesn’t work at all with openGL applications like X-Plane. For Mac and Linux, not even an unstable driver is available as of now.
On Windows, if we try to use the low-latency “Direct-to-Rift” mode, we get a Blue Screen of Death. It is a well-known problem of the latest Oculus SDK, that it doesn’t work with openGL. Any title with native DK2 support you find out there runs on DirectX, which also means it is a Windows-only title.
A user on the org forum posted this Star Trek quote:
“The needs of the many outweigh the needs of the few” (or “the one”).
suggesting we should’t wait for Oculus to provide Mac and Linux support and instead release a Windows beta RIGHT NOW.
In case it’s not entirely clear from I wrote above, the platform availability is not the problem! Even if we were to release Windows-only, we’d still need working openGL support in the Oculus display driver.
Using the DK2 in “Extended Desktop” mode like the DK1 is not really an option. Due to the DK2 running at 75Hz, and your primary monitor at 60Hz (unless you still have one of those heavy CRT monitors) you will get terrible vsync. It is dropping frames left and right (regardless of your actual frame rate!) causing what people on the Oculus forums refer to as “DK2 judder”. In fact, DK1 looks better than DK2 right now, given we can only use the “Extended” mode, and that is just lame.
I am heading out to Oculus Connect later this week, where I hope to get some insight into the what and when of openGL support, the roadmap for their drivers and if we are ever going to see native DK2 support on Mac and Linux.
As of now, I have to tell you that for anything but DirectX-based games, the Oculus SDK is so beta that it is not even alpha. We will have to wait for future versions of the Oculus SDK to fix those issues.
X-Plane has been lacking a decent navigation solution for general aviation aircraft for a long time. The built-in GNS430 instrument could only do direct-to navigation and not use X-Plane’s FMS plans, making long IFR flights inconvenient.
In X-Plane 10.30 we are introducing a new generation of the X-Plane 430 GPS navigator, modeled more closely after the Garmin 430W that is very popular in general aviation aircraft. The 430W is a popular aftermarket GPS replacement in many older general aviation aircraft, because it is approved for WAAS approaches and thus an easy upgrade to allow flying instrument approaches at lots of smaller airports without ILS.
The new X-Plane unit can create and fly multi-leg flightplans in addition to the direct-to function:
You can create directs or flight plans using a worldwide database of airports, fixes and navaids:
Loading or saving the route works using the X-Plane FMS format. Many online services for virtual flight planning are compatible with that:
You can then navigate along your flight plan using one of different map views that provide situational awareness:
While flying under VFR, stay alert to any Bravo, Charlie, Delta or special use airspace in the United states (open database, user-expandable):
You will be warned when you are about to violate an airspace:
using the nearest airport function you always know your nearest alternatives for landing (though we all know X-Avion does a much better job at that!)
With a little help from your friend, knowing when to start your descend becomes easy:
Before landing, always know who to call:
For IFR approaches, load precision and non-precision approaches from a world-wide, updatable database:
Review approach transitions and initial approach fixes:
and then load any approach and transition into your flight plan:
Under ATC (read: when flying online) the vector-to-final function will often be used instead of a transition:
The X-Plane 430 is there to help you stay alert to common errors in approach navigation:
The GPS is capable of flying non-precision GPS-approaches with a localizer-like guidance and varying CDI sensitivity:
If you don’t see the runway at the minimum descend altitude, continue to the missed approach point and the flight plan sequencing will go into suspend. At the missed approach point, if you still don’t see the runway, begin your missed approach:
and then get help choosing the right entry to the missed approach holding:
The new GNS430 is a drop-in replacement for the old one, so every X-Plane aircraft equipped with the GNS430 automagically becomes more IFR-capable with the 10.30 update. We also provide an additional instrument in style of the bigger GNS530, that designers can use in their aircraft starting with Plane-Maker 10.30. It also allows for dual installations that can either use separate flight plans or cross-fill.
The interaction of the GPS with the rest of the panel, especially the CDI and the autopilot, has been improved, offering a few more options for aircraft designers. Two additional posts explaining the new options in Plane-Maker will follow shortly.
The database from which approaches are loaded is provided by Aerosoft. A current database will be provided once with X-Plane 10.30, and further updates will be available on a subscription basis.
You might have noticed stupid COM frequencies in some screenshots. This is not a bug, but a feature: X-Plane 10.30 supports 8.33kHz channel spacing, that is now mandatory in the European upper airspace and will become more important over the next few years.
For the inevitable question “will it have X and does it simulate Y?” I do have one answer:
I chose the feature-set for the 10.30 release carefully to fulfill two requirements:
It must simulate the functions I use every day. After spending about 40 hours flying a C172P with this equipment, I have developed some pattern in day-to-day use. The simulated equipment must have the functions I use every day.
It must simulate what I need for my IFR checkride preparation. I’m currently studying for the instrument rating. All IFR GPS functions that are needed during the lessons must be simulated so I can use X-Plane to practice at home.
This does not cover all functions of the real unit, but it covers what the pilot absolutely needs every day.
