Quick note: 10.31r2 is up on servers now. Please try it!! We think this is a keeper 10.31 – it has just a few more bug fixes. A list of fixes is here.
Quick note: 10.31r2 is up on servers now. Please try it!! We think this is a keeper 10.31 – it has just a few more bug fixes. A list of fixes is here.
If you develop 3-d models for X-Plane using Blender 2.49 on OS X, do not upgrade to OS X 10.10 (Yosemite). Something changed in the OS that causes the python scripts to not load, which means you won’t be able to export.
(As a side note, I am of the opinion that if you use your computer for work, you should not install major OS upgrades without investigating first. If Apple is going to break support for something intentionally, it will be in a major version. Once you install the new OS, going back is hard. So why jump in so fast? These days I don’t believe that any one OS update is so much better than what was there before that it trumps keeping your productivity software working. But then, as Chris points out, I am older than dirt.)
Update: Chris found a way to make Blender 2.49 work with Yosemite. For reasons unclear to us, the Python 2.5 framework that comes with the OS in Yosemite is just a symlink to version 2.6 (rather than the real Python 2.5). If you delete the symlink and put in place the old 2.5 binary from an older OS, Blender starts working again. I’ll post instructions when we have something written up in readable form, but this is a tricky mod at best – you have to change admin-writeable files in your library.
Update #2: Hi guys, Chris here. Here’s an outline of the steps that you’ll need to take…and you’ll need to be an administrator of course since you’ll be running sudo. A basic disclaimer….you should have a full bootable and recent backup of your system anytime you mess with system files (even though this should be relatively straight forward). These instructions worked for us but you should follow them at your own risk.
to get a full directory listing. If you see 2.5 -> 2.6, you have a symlink from 2.5 to 2.6 which is what’s causing Blender to use the wrong Python version. IF YOU DON’T SEE THIS, YOU DON’T HAVE A PROBLEM!
sudo rm -rf 2.5
sudo cp -R some/path/to/the/good/2.5 .
sudo chown -R root 2.5 sudo chgrp -R wheel 2.5
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.
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.
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:
This is too much uncertainty to solve ‘by hand’. So my plan is:
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!
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).
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.
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 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.
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.
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.
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.
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:
Your exclusion zone pack will filter out 3-d from packs “below” it (including the global airports) and leave your payware clean and unobstructed.
There are a few things I strongly recommend you _not_ do in trying to resolve scenery conflicts:
* 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.