X-Plane 11.11 Release Candidate 1 Available For Testing

X-Plane 11.11 is available for testing - to get it, run the X-Plane 11 installer, pick "Update X-Plane" and make sure "Get Betas" is checked.   Two big fixes:

  • This build should fix crashes for AMD users.
  • This build restores functionality for FltPlan.go and a number of other iOS moving map apps that.

Release notes are here.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in News | Leave a comment

Private VR Beta Testers

UPDATE: After receiving around 70 requests, we are closing applications for private beta testing at this time.


X-Plane's native VR is nearly ready for beta. Possibly as soon as next week, we will be moving into private beta testing of VR-capable builds. We are looking for a small number of volunteers to participate in the initial private beta.

Continue reading

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Testing | 34 Comments

X-Plane 11.10 Is Here!

X-Plane 11.10 went final Thursday night - you'll be notified to update. Jennifer has a good write-up of the high level features here, or you can read the release notes.

11.10 was a big patch for us - new airports, new autogen, new lego bricks, the G1000, joystick profiles, London landmarks, and significant engine enhancements to both the physics and rendering engines.

We may do an 11.11 patch next week - we have a few bug fixes that didn't make the RC. Jennifer gets a lot of bug reports over the weekend, so we'll evaluate Monday.

VR Is Coming!

The rendering engine work in 11.10 gets the sim "VR-ready", and Chris has been working on the actual VR features of the app in parallel to the 11.10 release.

The next major patch of X-Plane will be 11.20; it will feature native VR support for the Oculus Rift and Vive on Windows, and the beta is coming very soon.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, News | 182 Comments

How to Make Sound Cones in FMOD Using X-Plane

An author asked me how to make a sound cone in FMOD for X-Plane.

For example, our Cessna features recordings of the engines from four different mic positions (front, left, right, and back) - our engine sound event contains four sub-sound events, with sound cones modulating when the sound can be heard.  Think of a 90 degree cone sticking out from the engine to the front, the right, etc. Only if the listener is in the sound cone can you hear it.

Here's the trick: X-Plane provides two special parameters that give you the bearing of the listener relative to the event. From this you can create your attenuation shapes.

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

What Is The Sound of One Annunciator Warning?

In X-Plane 11.10, annunciator sounds automatically play even if you are using FMOD. This is confusing, particularly compared to 11.05 - here's what's going on.

We have two categories of sounds that are not handled by FMOD as of 11.10:

  • Radio sounds (where you have no way in FMOD to create the exact sound that's going to happen, because it's based on the ATC system or speech synthesis).
  • Cockpit warning bells and other "event" sounds that are triggered directly from the flight model code.

We are planning to make this second set of sounds FMOD-accessible in the future, but to do so we need to create a system for "events" in X-Plane that is accessible to plugins and the authoring interfaces.

My current thinking is that an "event" system would let plugins subscribe to notifications of events, wire up sound events to sim events, and create new events via the plugin system. We may even be able to eventually play particle effects in response to events. The events would have path names (similar to commands and datarefs) for flexibility.

I had hoped to get to this in 11.10 but we just didn't have time, so this will have to wait for a future patch. When we do have sound events we'll have a way to indicate in an FMOD .snd file that (1) you want to wire up sound to particular sim events and (2) you don't want the built-in sounds anymore.

Here's the current set of sounds that are played even if FMOD is in use. If you don't want them, include silent waves in your aircraft's "sounds" folder.

alert/10ft.wav
alert/20ft.wav
alert/30ft.wav
alert/40ft.wav
alert/50ft.wav
alert/100ft.wav
alert/200ft.wav
alert/300ft.wav
alert/400ft.wav
alert/500ft.wav
alert/1000ft.wav
alert/altitude_alert.wav
alert/autopilot_disco.wav
alert/autopilot_fail.wav
alert/dash_OUTER.wav
alert/dot_MIDDLE.wav
alert/dash_MIDDLE.wav
alert/dot_INNER.wav
alert/dash_MORSE.wav
alert/dot_MORSE.wav
alert/gear_warn_1.wav
alert/gear_warn_2.wav
alert/mini.wav

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

X-Plane 11 Airport Usage Data

We had a request for information on the popular airports, so here's a small addendum to the usage data from a couple weeks ago. We don't currently track whether the airport is a default, Gateway airport or an add on, but we do have it on our radar to track the most popular add ons in the future.

We've filtered out demo users again, and this information is for the entire life of X-Plane 11 (1 Nov 2016 to 21 Nov 2017) since we've never published airport data before. I've only pulled the top 50 airports for this list, but we track 11,281 locations. Continue reading

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in X-Plane Usage Data | 9 Comments

Heavy Metal

hate finding out about these kinds of bugs late in the beta. But this one was pretty big.

X-Plane uses a "metalness" material model. Metalness is a fairly standard material model that recycles the albedo of your material to implement both dialectrics (non-metals) and metals.  It works like this:

  • Non-metal: diffuse light is tinted by the albedo texture. Specular light is not tinted.
  • Metal: there is never diffuse light.  Specular light is tinted by the albedo texture.

In other words, since metals don't have a diffuse component, we recycle the albedo to save texture space.

The bug in 11.05 is that for a pure metal, the albedo was tinting ambient light but not the sun itself.  A third party developer sent me a test model that showed the problem - here's the before and after.

That weird set of colors on the top of the helicopter body is due to the white sunlight being added to the red body.  The red aircraft body is lit by ambient light reflected directly off of the environment.  The runway stripes are not visible because the metal is about 30% rough, diffusing the reflection.

(One of the confusing things about PBR models if you are not used to them is that the environment itself can cast both diffuse light and specular reflections off of a material, and if the material is rough, it can be hard to tell them apart.  Diffuse light is always widely diffused, no matter how glossy the surface.)

Alex and I took a look at some of our legacy aircraft and found that fixing the lighting didn't make too much of a difference for metals that are not tinted.

Since our aircraft don't have any "tinted" metal there isn't much change. Note that in real life heavily tinted metals aren't common.  The cases you might have are:

  1. Approximations of metals with complex spectrum-dependent fresnel like gold.
  2. Composite paint, e.g. like for your car, with fleks of metal and translucent dielectric polymer mixed together - that's the case where this really helps.

As I wrote this up I realized that the spot lights are still wrong in beta 8 - they'll be fixed for RC1 unless people really need the old model, in which case we'll have to put some versioning in.  My guess though is that anyone doing composite paint realized it was impossible in 11.05 and hasn't shipped anything like that yet.

In these comparisons we are under an airport light viewing various materials.  In the multi-color case the bottom row of materials are various "metals" with light tinting to simulate copper, iron, gold, etc.

In the second set of cases (all red) we have a 2-d grid: metal on the bottom, dialectric on top and rough on the left and glossy on the irght.  Note that the reflection of the overhead light is reddish for the metals and white for the plastics in 11.10 (correct) but all white in 11.05 (incorrect).

 

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Modeling | 30 Comments

X-Plane 11.10b8 and the State of X-Plane 11.10 Betas

A few betas went by and I didn't have a chance to write things up. The short version:

  • 11.10b8 just went up - release notes here.
  • We're mostly down to small bug fixes - no more big flight model changes.
  • The next build will probably be 11.10rc1.
  • We'll get Steam updated in the next few days - Philipp's been traveling a lot.

There are no remaining major enhancements that have to go into this beta. Here's how some of the big technology changes played out:

  • The new manipulators are in - I'll write up a separate post tomorrow on those.  They went into beta 6 (hence all of the weirdo bugs) and are now fully working.
  • All of the new weapons code is in - dataref access to weapons is restored. Jörg has a few crash bugs to nail down with networking and weapons, but that's it.
  • Audio events had to wait - I'll write that up in a separate post. They're something we wanted, but realistically we never had time for them in 11.10.
  • The last round of performance enhancements for graphics is going to wait for the next release patch.

The bad news is: AMD users aren't running 11.10's fastest path due to problems with our current code and drivers. The good news is: the next round of enhancements do work with AMD cards, so we can get back to treating them normally. That code is now looking reasonably stable, but it wasn't stable early enough to make it into 11.10.  I think it will be available in beta this year though.

Finally, there was an open question of how to use glScissors in a plugin with the new UI features (e.g. floating windows, multi-monitor, 150% UI, etc). As of beta 8 this is fully possible; I just need to get the sample code to Tyler to post.

Two flight model notes for aircraft authors - the executive summary of all of these is pretty much "it should just work and you don't have to do anything."

Steering Gear Rate Limiting

X-Plane 11.10 has an option to rate limit how fast gear that steer can turn. This is a good thing - in the real plane you just can't turn that tiller very fast, but if you have a $20 Microsoft Sidewinder from 2002 with the throttle tab broken off (for example) you can twist it to full deflection almost instantly.  When this happens, X-Plane turns the wheels instantly, and since they're not at a 70 degree angle to your movement path, they skid like Ken Block landing a Baron. Once the wheel is in skid it has pretty much no ability to turn the plane and you just skid.

With rate limiting, the wheel will turn a little bit, and be able to put out side force, helping the plane begin to rotate.  As this happens, you can turn more and gradually angularly accelerate the aircraft into a turn.

So ... rate limiting is good - you should use it!  But the compatibility code in beta 7 was pretty broken - it set the minimum rate to 1.0, which is way too slow for a bunch of aircraft.

Beta 8 fixes this - the minimum rate is 0 (meaning no limiting) and this is the default for 11.05 planes.

Here's the warning: if you saved your aircraft in an earlier beta, you've baked in the long gear deflect time - you'll have to go into Plane-Maker and turn the value back down again.

Just One Turbo-Prop Model

X-Plane 11.10 had two options for free turbine turbo-prop engine models: the "v10" and "v11" models; all 11.05 planes showed "v10" when loaded in Plane-Maker.

We've backed this out - there's just one model, "turbo-prop (free)" in beta 8, and if you picked the v11 model, we'll mark it back to v10 for you. (You shouldn't be shipping aircraft saved in a beta anyway, but we check for this in the sim itself too.)

Here's the back-story: X-Plane models the compressor turbine speed of a free prop turbine like the PT-6 as "N1" and the prop turbine speed as "N2". Austin has come to regret this decision, as the prop turbine is a lot more like the turbine that drives a bypass fan in a high-bypass jet engine, and the compressor turbine is a lot like the turbine that drives the core in a high-bypass jet engine.

So Austin cut a new version of the engine model with N1 as the prop and N2 as the compressor, exactly backward from 11.05.

The thing is: while the new model matches Austin's brain, it doesn't match any aircraft ever made, and swapping N1 and N2 in an add-on is a pretty expensive update. Realistically we're not going to ever deprecate the old model for the new one in any time frame if this much rework is needed.

So we're keeping the new model 'in the lab' and not releasing it for now, as it doesn't have significant changes in how it models the engine itself yet. This frees Austin up to improve it on his own schedule and frees us up from having to maintain another point of version compatibility. Since the new model doesn't have any enhancements (other than renaming N1 to N2 and vice versa) you're not losing out as an aircraft developer here.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, News | 60 Comments

XPlane2Blender v3.4.0-beta.6

XPlane2Blender v3.4.0-beta.6

Change Log

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

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

This Changes Nothing in Your Blend files!

Seriously! No Blender data should change!

However, It Could Change Your OBJs

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

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

What Lights Are Affected?

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

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

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

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

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

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

This is just one step to a more WYSIWYG XPlane2Blender.

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft & Modeling, Development, Modeling, Scenery, Tools | 7 Comments

Usage Data Update for November 2017

Here are the results of the latest usage data as of 05 October, 2017. If you'd like to compare, here is the last usage data result from February 2017.

It took me a bit longer than I would have liked to compile the graphs while working around the 11.10 beta, but we now have a handful of easy-to-digest charts, plus the raw data at the bottom of the post for those that are interested. Continue reading

  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in X-Plane Usage Data | 45 Comments