The FMOD Starter Template Is Available

The FMOD development guide now contains a link to the FMOD starter project generator.

If you want to make an aircraft that is FMOD enhanced, you must start with this starter project! If you already have an FMOD project, please copy the events into this new starter project.

When can an FMOD project be shared?

  • Use only one starter project for an entire family of .acf files that share an ACF folder. These ACF files will share the master bank in the FMOD folder, so you need one project for all aircraft. (Each aircraft gets its own .snd file in the FMOD folder.)
  • You must use a new starter project fore each aircraft in a new folder - you should never have a single project with banks copied into two different FMOD folders!

We are working on more documentation on how to use FMOD, but with the sample project, you have everything you need to create an FMOD-enhanced aircraft.


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

X-Plane 11.01 Released

X-Plane 11.01 is now final, both via our installer and Steam. We're going to do one more bug fix release (11.02); at this point it looks like Gateway airports will go into a separate 11.05 release to give authors a little bit more time to work with WED 1.6, but we're still discussing this internally.

In terms of timelines and releases:

  • Small bug fixes, fixes for aircraft SDKs, and small, tactical performance improvements will make it into X-Plane 11.02.
  • Big things like an XPLM revision to pop out windows, fixing the weapon API, the G1000, and more invasive performance improvements as we move toward next-gen rendering APIs will have to wait for 11.10.

That's a lot of stuff in that second bullet point - there is basically no chance that all of that will make it into 11.10; we have enough long term efforts going on at once that some will go into 11.10 and some into 11.20 or something later. I don't even know which of those things will be in 11.10 - basically, what's ready around when we get to 11.10 will be released, and we'll do another release when more features build up.

 


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

We Have FMOD Documentation

Hot off the presses - first draft today: new docs on Using FMOD With X-Plane Aircraft and a file format spec for those .snd files you need to tie FMOD To your aircraft.

This is a first draft, so please: use the comments section to ask questions about FMOD only. I'm going to do something a little bit unusual and delete off-topic comments on this post so the entire comments thread is FMOD specific. FMOD integration with X-Plane is complicated, so it would be really useful to know what needs more explaining.

There is one more piece of the FMOD puzzle that is missing - Tyler is working on it now and hopefully we'll have it live soon: the FMOD starter project.

The short version is: to get an FMOD project that will properly integrate with X-Plane and other third party FMOD aircraft, you need to get a starter project from us - it will come with the mix buses already in place and set up for X-Plane to use them; you can just add signal processing, etc.

What makes this tricky is: everyone needs a unique starter project or else multiple FMOD aircraft won't be able to coexist. (And that would be sad - one of the really cool thing about FMOD-enhanced aircraft is that you can finally hear the AI aircraft. It adds a ton of depth and realism.)

Tyler is working on a download link that dynamically creates a unique FMOD starter document to avoid FMOD conflicts between AI aircraft. I'll post when this is up and running.

In the meantime, the docs hopefully answer some questions about how aircraft like the Cessna work.

Right now FMOD can only be used to add sound to aircraft, but we are looking at adding FMOD to scenery, as well as our own ground vehicles.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Aircraft & Modeling, Development | 26 Comments

X-Plane 11.01: Lighting the Fog

X-Plane 11.01 release candidate two is now available - on Steam too! We hope this is the one.

Here's one more before-and-after view - the new fog applied correctly to lighting spill and billboards.

11.01 should go final too and then we'll move on to 11.02 - we have more bug fixes to get out and a performance improvement for NVidia Windows hardware.


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

X-Plane 11.01 RCs

We posted an X-Plane 11.01 release candidate today.

  • The good news: it fixes the XPLM navigation buffer overruns that were crashing plugins. So that should be a big win for people using plugins with the beta.
  • The bad news: we found and fixed the flashing cloud shadows bug after the RC went out.

So we'll do an RC2 with the cloud shadow fix over the weekend. We have a bunch of bugs we kicked to an 11.02, so that we could get the 11.01 fixes to everyone. We're also looking to make WED 1.6b2 uploadable to the gateway so we can push out more gateway airports.


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

Let’s Get Physical At Night

X-Plane 11.0 shipped with all new Physically Based Rendering - the lighting and material model is based on the real physics of light interacting with dielectrics and metals (kind of) to make rendering look more realistic with less art tuning.

But...X-Plane's night lighting in X-Plane 11.00 is not physically correct - the night lights ignore the materials and do what X-Plane 10 did.

X-Plane 11.01 betas fix this. In the pictures below you can see side-by-side comparisons of the same scene with the 11.00 lighting and the new physical night lighting for 11.01.  The array of balls floating around the Cessna is a test project I use with a 2-d grid of materials (metal on the bottom, rough on the right).

One of the effects of this is increased accuracy of light location - that is, you can really tell where the lights are by the reflections they cast on specific materials.

Here are some material comparisons with the day seen included so you can see what the original materials were. Observe the rim of the engine cowlings on the 737 and 747, and of coarse the entire fuselage on the MD-82.

There's no authoring change needed or work to do for third parties - if you were modeling your aircraft to look correct during the day, 11.01 makes the night lighting look better.


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

X-Plane 11.01b1: Fixing Cockpit Light Levels

A number of blog comments have been (cough, cough) rather vocal about the cockpit lighting being too bright in the cockpit at dusk. As it turns out, this was a shader bug! Here's some before and after:

To get a sense of the bug and the fix, look at the panel of the Baron and the wall of the building behind it. These surfaces are both bright-albedo rough reflectors facing in the same direction. You'd expect roughly similar direct lighting levels* for the same surface, and yet in the 11.00 pictures, the cockpit panel is way brighter.

X-Plane uses atmospheric scattering equations to calculate the sun's direct sun color - the sun light becomes "reddish" at low angles because the blue light has been scattered out more, by going through more air than at higher sun angles.

But we can't always use this formula! When you view a weapon in the weapon preview screen, where in the world is it? What time is it? The answer is: no one knows, so we just render with proxy lights and not the full atmospheric model.

The bug was: we were using proxy lighting colors and not the actual scattering-based lights to calculate the interior of the airplane, causing huge direct-lighting mismatches between the interior and exterior of the aircraft. If you had a part-interior, part-exterior model (e.g the air-stairs of the plane folded up inside the cabin) you might see a huge lighting difference.

11.01 correctly uses scattered sunlight in the airplane too, resulting in much less "electric" sunsets.

 

* Assuming no cockpit shadows - if you really want to put back cockpit shadows after this fix, um, go ahead, but I continue to think that the shadows look too awful due to the very low sun angle, and the direct light isn't a problem now that it's fixed.


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

X-Plane 11.01 Beta 1 and the SDKs

X-Plane 11.01 beta 1 is out now - to get it you have to check "get betas". Since we now have a stable release version, my suggestion is: don't check the box unless you are an add-on developer or are willing to deal with some beta-crazy. We try to make sure that every beta works, and things are less crazy here now that 11.00 is out, but you can read the release note history and see that dead betas still happen regularly.

Linux Users: if you use the Aerosoft DVD and have been using the special posted build of the sim to unlock the DVD, please use 11.01 beta 1 - the Linux fix is incorporated.

I'll post some pics of some of the graphics changes in 11.01 in another post.

A note on the various SDKs: we made a real push to get the various authoring SDKs stabilized for 11.00, but there were things we missed. Most of the authoring SDK changes in 11.01 are:

  • Bug fixes.
  • Removal of old datarefs and features that didn't work anyway and hadn't been "cleaned out".

One exception where an authoring rule is actually changed: during the betas and in 11.00r1, the prop disc is blended using incorrect gamma, matching X-Plane 10 behavior. Not changing this was an accident; all other alpha blending in 3-d is gamma-correct in X-Plane 11.

For 11.01 I chose to change the prop disc now to make everything completely consistent across all interfaces for the rest of the X-Plane 11 run. This isn't ideal, but running the prop discs with incorrect blending would be a performance penalty for the entire rest of the version run (we'd have to change rendering passes in Metal/Vulkan to support this) so I figured best to rip the bandaid off quick.

As with all gamma-correct blending, the most likely problem with this that the mid-alpha parts of your texture appear too bright in 11.01b1. Incorrect blending loses energy, so the natural authoring work-around is to make things too bright to compensate; now that you are seeing too much light energ you may have to back things off. Looking at our Cessna, the white paint on the prop disc is a little bit too bright with the change.

In other SDK notes: I'm part way through writing draft FMOD notes - one that's done, Jennifer can turn that into something human-readable. We will probably do an 11.02 to collect gateway airports; WED 1.6b2 is out now but it's not approved for gateway use yet; we're waiting to get some test time on it. If 11.01 goes final before gateway airports can be pushed, we'll do a separate patch to get those airports released.


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

WED 1.6b2 available now

The latest WED 1.6 beta is now available to test.

This version includes multiple bug fixes, such as Ted's fix to crashes caused by long tool tip text, and fixes when using orthophotos. See the included README file for the full change log, and, as always, let us know about bugs and problems on the Scenery Tools bug reporter.


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Scenery, Tools | 13 Comments

Experiencing unexpected crashes to desktop on WED on Windows 10? Here’s why…

We have received at least 5 bugs for WorldEditor that seem to have similar characteristics

  • Inexplicable crash to desktop with no error message
  • Happening on Windows 10, not reproduceable on Windows 7, Linux, or WINE
  • Happens shortly after using the Truck Destination tool

In short, until we get a new beta out that officially fixes the issue, try downloading this nightly build of WED. Also, see all the bugs that are marked as duplicate and related to WED-780.

What happened?

Windows Tool Tips and You

Tool tips are those little pop ups that appear when you hover your mouse over UI elements. Sometimes their text includes helpful tips, sometimes they include data; it is whatever we program them to have.

Hovering the mouse over a cell in the WED hierarchy pane makes a tool tip appear with its content as its text.

The code to do that is located in xptools\src\GUI\GUI_Window.cpp:1252-1272. Windows passes a message to WED saying the user has hovered over some UI element, we hand over some text to a data structure (NMTTDISPINFO), Windows uses the data to display the tool tip.

Look at line 1272. This is the line that does the copying our tip string into the szText for Windows to display.

//wcs = wide-char-string = Unicode string, cpy means copy, _s means "more secure" version of the function
wcscpy_s(
di->szText, //The data in here will show up in
80, //Our stupid magical number
convert_str_to_utf16(tip).c_str() //convert our UTF-8 string to UTF-16 to please Bill Gates
);

This line was the source of the crashes.

What's so special about the number 80 and "_s"?

Window's gives you a free "no-work" string, szText, for your tool tip text that is 80 characters long. If you want a longer tool tip, you'll have to do a bunch of (not well documented) work.

What makes this a "secure" string function is it immediately ends the program if you attempt to copy more than the specified 80 characters into the new string. This information is overwhelmingly under-documented. In addition, the crash doesn't included any information about the cause, even in debug mode!

How did this go on for so long without getting caught?

Amazingly, we've never really had this be a problem, or previous versions of Windows have had this function not crash. One reason why this is now getting reported is due to the Truck Destination tool's Truck Types property. When you add up enough of those strings and hover your mouse over them, it quickly ends up being much longer than 80 characters.

"Baggage Loader" + "Baggage Train" + "Fuel Truck (Jets)" + ""Fuel Truck (Liners)" + "Fuel Truck (Props)" = 81 characters in total.

With enough selected types, this easily reaches beyond 80 characters.

  • It is also possible we've just been getting lucky with our memory, always having strings getting corrupted exactly just right.
  • It is also possible that all our data is short, with abbreviations being so common in aviation, its normally hard to reach more than 80 characters.
  • Maybe no one reported a bug (please report your problems so we can fix them!)

Please comment if you have some ideas of why this doesn't seem to happen on Windows 7, but does on Windows 10. Maybe this "secure" function isn't as secure as we all think it is.

The solution: truncation!

Our easy fix for this is to chop a string off at 77 characters and append a "..." at the end. Hopefully no-one will mind this.

This new fix will soon make it into a beta and a release. Until then we have this nightly build available.

Final Thoughts

Thanks to a video sent in by a user, this was a pretty easy WED bug to find and solve. The hard part was weeding through all the bug reports that seemed shrouded in unrelated but related mystery. No one was realizing their most trusted friend, the mouse and common tool-tip, were causing the problem.

If you reported a bug, and this helps, please comment and contact us so we can clean out all the mysterious non-mysteries and get back to triaging bugs that have not been fixed!

Thank you for your patience as always as we try our best to make WED the best we can, and thank you to the people who report their problems instead of suffering through it, making a work around, or assuming their simply doing it wrong: You make the product better for everyone, including the developers!


  • Facebook
  • Reddit
  • Twitter
  • LinkedIn
Posted in Development, Scenery, Tools | 22 Comments