X-Plane 10.31 Release Candidate 1 – A Few Fixes

X-Plane 10.31 release candidate one is now live.  To get it, you need to run the X-Plane installer and check “Check for new betas as well as updates” – 10.31 isn’t final so it won’t auto-notify you.

Please do get 10.31 Release Candidate 1 and try it.  We’d like to go final with it shortly.

The release notes are here - that’s basically a list of the bugs fixed.  Go read them if you want to know what is fixed!  (If the release notes don’t say it is fixed, then there is no change from 10.30.)

Report bugs here.

Please do not report bugs in the comment section – a little bit of me dies inside every time you do.

It looks like we have some bug fixes that will go into a 10.32, but for 10.31 I wanted to get out smaller fixes that we could ship quickly.  So hopefully 10.31r1 will be the only 10.31 patch and then we can get fixes in for 10.32 in another week or two.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 3 Comments

HDR + Instructor Screen = Yuck (But Only For a Few More Days)

Just a quick note: last night I fixed the bug in 1030 where the sky is corrupt when you use the instructor’s station and HDR together.  This is the last of the ‘quick’ fixes for 1031, so I’m hoping to have 1031 cut over the weekend.

When I first saw pics of this bug I thought it might have been an old driver, but the number of users seeing it made it clear that it was a real thing; as it turns out, it was a subtle OpenGL screw-up by me.  Frankly the amazing thing is that we’re not seeing it on every Windows driver.  (From what I can tell, the AMD drivers “helpfully” work around my error, hiding the bug.)

We’ll post release notes with the beta with a complete bug fix list.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development, News | 1 Comment

Dude, Where’s My Taxiway?

For about a year there has been a subtle bug in how X-Plane draws taxiways: if you build an S-curve shape out of a single bezier and it is almost perfectly symmetrical, X-Plane would go “nah, why bother” and replace it with a single straight line segment.*

So in 10.30 I fixed it, and the result was a bunch of broken airports with missing pavement.  (YMML is high on this list!)

It turns out that these airports have authoring errors – typically a segment of pavement that should be straight instead being formed by two overlapping beziers.  This is definitely wrong, but due to the bug, X-Plane would simplify the overlapping S curve into a single straight segment and the layout would work.  Only now that X-Plane correctly renders the S curve does the taxiway fail (because taxiways may not have overlaps).  So two wrongs may not make a right, but they do make a “hey, that looks okay, let’s ship it”.

Note that the overlaps depend on the rendering setting of X-Plane – a different S curve is formed at different rendering settings; the overlap that causes the taxiway to disappear may only appear at a particular rendering setting.

For 10.31 I am going to undo my bug fix. This doesn’t make me happy, but I think it is necessary:

  • We have no idea how many airports have their taxiways broken by this bug.
  • Authors have no easy way to detect this problem, other than re-testing every airport at every rendering setting.
  • Even if an airport looks okay at all rendering settings, future rendering settings may cause the problem.

This is too much uncertainty to solve ‘by hand’.  So my plan is:

  • Undo the code change for 1031.  YMML and friends comes back.
  • Develop validation code in WED to detect this kind of authoring error.
  • Ship that version of WED so new authoring work will be checked.
  • Run the WED code on all airports and make a list of ones that need repair.
  • Fix all of the known problems in the airport gateway.
  • Redo the code change so X-Plane is correct.

This isn’t going to be a quick process, but then it can’t be, because third parties have apt.dats shipping now that only work when X-Plane has the buggy taxiway code in place.  So we need to ship WED and then give third parties enough time to go back and check their layouts and fix them if necessary.

I expect to get a 10.31 beta with the taxiway code changed back this week.

For WED validation, I have some test code to detect errors but it isn’t ready yet.  The problem is that it’s not good enough to detect errors with overlapping beziers**; we have to consider two bezier curves near enough to each other that with the error in rendering introduced by WED’s rendering settings, we get an overlap.  (So authors, better be safe than sorry in creating your pavement.)

If there’s a moral to this story, I think it’s this: when we (LR) don’t provide good tools for authors to validate that their work is correct, the resulting body of work will end up with subtle errors.

 

* X-Plane renders beziers by measuring how far the mid-point of the curve is from the average of the ends.  As long as this distance is ‘too far’ and the iteration count isn’t too high, X-Plane divides the bezier in half and repeats the process.  In this way beziers are broken into enough line segments to approximate the bezier within a minimum error limit.  The rendering settings control the error limit.

The bug: if the curve was a ‘balanced’ S curve the mid point of the curve was the average of the end points and X-Plane went “great, no error” and stopped dividing.

** Which is already not an easy problem – the analytical solution for bezier intersection is a 9th order polynomial!

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development, News, Scenery, Tools, Uncategorized | 26 Comments

Linux and Libs – How to get 10.30 working again on Linux

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:

  1. X-Plane 10.30: you need to create a symlink if it doesn’t work
  2. X-Plane 10.31: no need for a symlink because we won’t depend on libudev at all
  3. X-Plane 10.x: X-Plane will ONLY require libudev when you are using the Oculus Rift

As for the sym-link work-around, avid Linux user and plugin developer Bill “Sparker” has created a thread on X-Plane.org where the appropriate paths for the symlinks are posted for a variety of different Linux distros.

UPDATE: The method described here works just as well and has the benefit of limiting the change to one application only.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Uncategorized | 8 Comments

No Oculus for the openGL guys yet

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 30 Comments

X-Plane 10.30 Is Out the Door

X-Plane 10.30 Lives!

Laminar Research, creators of the X-Plane flight simulator franchise, has released the latest update to X-Plane, version 10.30.

This latest release represents the largest and most significant X-Plane update to date.   It not only contains numerous fixes and performance improvements, but also some substantial additions to the product itself.  Foremost is the inclusion of the new GPS.  The previous versions of X-Plane also included a GPS instrument but it could only do direct-to navigation and could not implement a GPS approach.   With the recent introduction of GPS enabled approach systems at many airports, the new GPS in X-Plane will allow customers to practice actual GPS approaches using an instrument familiar to most general aviation pilots. The new GPS is a drop-in replacement for the old X-Plane GPS, so that with one click in Laminar’s PlaneMaker, old aircraft can be upgraded to the more IFR capable version.  The X-Plane 10.30  default aircraft come with the new GPS already installed.  The new GPS is based on the Garmin 430 and Garmin 530 and both variants are included.

The 10.30 update also includes major improvements to both the weather and scenery systems.   The system for the placement of autogen scenery has been refined so buildings, trees, and other objects more accurately reflect their real-world counterparts.

With the recent release of World Editor 1.3 and the Airport Scenery Gateway, hundreds of new highly detailed airports have also been included in this latest and major update to X-Plane 10.

We’ll have a 10.31 bug fix patch, probably in about a week, with a few straggler bugs that didn’t make the cut.  In the meantime, aircraft designers can start using the new GPS.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 25 Comments

Steam Users: X-Plane 10.30 Will Be Available “Real Soon”, I Hope

Once X-Plane 10.30 goes final*, we will also update X-Plane on Steam to version 10.30. The update for Steam users will be applied using Steam’s normal updating system, not the X-Pane updater.  (Basically if you installed via Steam, you update via Steam; if you installed via Laminar Research’s installer, you update via our installer.)

How soon will it be available?  I don’t know; this is the first patch we’ve done via Steam. We’ve done literally one hundred patches (including betas) for X-Plane 10, so we know how long it takes to cut a patch, upload it to the servers, etc.  For Steam, we’re just learning this now.  I am hoping it will only lag our installer by a few days at most, but Steam is new to us and partly out of our hands (in that it’s Steam’s servers doing the downloads).

* So far it looks like 10.30r2 will be final, but I will look at the submitted bugs tomorrow.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 10 Comments

Prioritizing Scenery and Exclusion Zones

Last year with X-Plane 10.25 we began to share 3-d lego brick airports. X-Plane 10.30 adds more, and with the X-Plane Airport Gateway now live, I’m sure we’ll have even more 3-d airports in the next update.

One thing this means: conflicts between payware airports and the global airports that ship with X-Plane will become the norm, not the exception. This blog post describes how to keep payware and the global airports from getting into each other’s hair.

Prioritization of Scenery Packs

X-Plane scenery packs are loaded in priority order; in order to ensure that you see your payware, the payware must be higher priority than the global airports. The system for prioritizing scenery packs changed in X-Plane 10.20, so please read this carefully!

Scenery packs in “Custom Scenery” are loaded in the order of scenery_packs.ini. Custom scenery packs at the top of the .ini file are loaded first and override packs below them.*

Any time X-Plane runs and finds a scenery pack not in the .ini, it adds it to the top of the file; therefore when you install new scenery, it starts at the highest priority level. Usually this is what you want.

The airports from the X-Plane Airport Gateway are in a scenery pack called “Global Airports” in your custom scenery – this pack should be higher priority than any base meshes but lower priority than any custom airports.

Exclusion Zones Are Needed

The runway and taxiway data for an airport comes from the highest priority scenery pack that includes that airport in its apt.dat. But 3-d objects are overlaid in an additive manner; in order to avoid conflicts between two sets of 3-d objects, the higher priority scenery pack must include one or more _exclusion zones_.

An exclusion zone is a rectangle in an overlay DSF that tells X-Plane to remove any 3-d in that area from lower priority packs. It lets an author “clean out” an area for later use.

Authors: all custom airports should be built with exclusion zones to protect them from other custom airports and the global airports that ship with X-Plane. If you are working on an airport and there is no 3-d in X-Plane, include an exclusion zone anyway – 3-d may appear in an update.

Users: if you have a custom airport and it does not have exclusion zones, all is not lost. Until the author updates the custom airport, you can do the following:

  • Build a scenery pack that contains _only_ an exclusion zone over the affected area in WED yourself.
  • Prioritize your scenery packs as follows:
  1. Payware – unmodified
  2. Your own “Exclusion zone”
  3. Global Airports – unmodified

Your exclusion zone pack will filter out 3-d from packs “below” it (including the global airports) and leave your payware clean and unobstructed.

Things Not To Do

There are a few things I strongly recommend you _not_ do in trying to resolve scenery conflicts:

  • Don’t modify, rename or delete the scenery packs that come with X-Plane. The updater is just going to try to restore them every time there is an update. You’ll be pushing the rock up the hill over and over again. Don’t delete individual airports out of Global Airports – the installer will just put them back.
  • Don’t constantly delete scenery_packs.ini. Some users have told me that they like to rename their folders to alphabetical, delete the .ini file and let it rebuild each time. But this violates the renaming rule and means updates won’t go well. Edit the .ini file to get things the way you want – it’s there for you to customize.

 

* Why did we pick this? The old way of customizing scenery packs (renaming them) didn’t work well with our updater – the updater would see the scenery pack (under its original name) gone and re-download the pack, wasting time, bandwidth, and creation chaos in the custom scenery folder. The scenery_packs.ini file lets users disable and re-prioritize scenery packs without having to rename anything.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 25 Comments

10.30r2 is Out and Will Probably Go Final

X-Plane 10.30r2 is out now.  You should go get this RC and try it.  I believe it is very likely to go final in the next week.

There are known bugs* in 1030r2 – the plan is to put 1030r2 out as final, then issue 10.31 in perhaps a week or two to mop up about a dozen bug fixes that didn’t make in.

  • By getting 10.30 out now, third parties can stop holding their breath and ship aircraft that use the new GPS.
  • By giving 10.31 another week or two we lower the risk profile on some of those extra bugs.
  • There’s always one big bug that gets reported as soon as we go final, so a 10.31 is inevitable; we might as well plan for it.

X-Plane 10.30 has had an incredibly long beta period, so our goal is to get it out now and unblock third parties.

* I know, you are shocked, right??

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 17 Comments

The Cloud Texture Layout Didn’t Change

I heard quite a bit from the cloud and weather tweakers when we started 1030.  At the beginning of the beta, I thought I’d have the visibility and fog improvements ready to go, and so I posted about possible changes.

Those features got pushed out to a future patch.  The cloud lighting did change.  So what was the total set of changes?

  • Scattering and lighting did not change, and there are no changes to art controls.  So hacks to atmospheric scattering are unaffected.
  • The format (size, color format, usage) of the cloud textures did not change – if you have a replacement cloud texture set, you can keep using it.
  • The actual default cloud textures did change – I beat them up a bit in PhotoShop.   Hence if you have custom cloud textures installed, the updater will yelp.
  • The lighting and placement of the cloud puffs has changed, so color choices for custom textures may have to be revisited.
  • Art controls to kill clouds are still there – but if you want our clouds gone, use the new override_clouds dataref!
  • There are new art controls controlling the (now redone) white-out effect.

So the total impact on cloud and atmosphere tweaks should be relatively low – but the lighting definitely changed on cloud puffs.

My expectation is that when the scattering art controls change (and they will change someday) it will be due to a change in the scattering code itself that will be “worth it”, e.g. a major iteration to improve the look of scattering itself.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 18 Comments