In the past, our posts breaking down X-Plane usage data have been… well… intermittent at best. Not because we don’t think sharing this stuff is important—it absolutely is—but simply because gathering the data, putting it into nice charts, and writing up a blog post took time away from developing X-Plane itself.
Whenever we encounter a problem like this, we try to pull back and take the humans out of the process. Out of that philosophy, let me present to you:
We have fixed the two high visibility bugs reported over the last couple days, and now have beta two out. This build should have fixed the cloud rendering issue as well as the scenery pack typo.
If you had installed beta 1, you should be auto-prompted to update. It is also live on Steam.
It has been some time! I have been working as hard as I can on the
converter (to great applause so far!), but, there have still been some
features and fixes developed along the way. By now it was time to
collect and release them!
As always This is a beta. It makes data model changes which may still have bugs. Make backups!
Features
“Cast Shadow (Local)”
Previously, you could only set “Cast Shadow” to be on or off for “Scenery” and “Instanced Scenery” export types. This would, for the whole object, turn on and off shadows. Now, “Cast Shadow” has been removed from the OBJ settings and “Cast Shadow (Local)” has been placed in the material settings. With this, individual meshes can have shadows or not and it works for Aircraft and Cockpit objects too!
The first public beta for X-Plane 11.35 is now available! (Steam is staged and will be released shortly.) This is an update that includes new Gateway airports, FMOD sound for the Boeing B737-800 and KingAir C90B, improved aircraft systems, and landmark scenery packs for New York and Washington D.C.
Aircraft developers will want to review Philipp’s notes on the:
Update: We are aware of a cloud rendering bug with anti-aliasing. The work around for now is to turn off or use the lowest setting of anti-aliasing.
We are working on b2 to fix this issue and will be holding the wide release of the Steam beta for the fix. If you really, really, really want to use b1 with this known issue, you can email me directly at my first name @x-plane.com and I’ll get you into the private Steam beta.
As you may have heard, we’ll be at FlightSimExpo 2019 in Orlando this weekend! If you are attending, please stop by our booth and drop in on our talk Saturday afternoon. We’ll be qualifying people for a VR landing contest too.
For developers: Austin, Philipp, Chris and I will all be there – find us to talk about developing add-ons for X-Plane!
We’d like to point your attention especially to the new “2D” or “3D” meta-tag for export targets of 11.30 or higher. This tag tells the X-Plane GUI to list the airport as “2D” or “3D”.
Before X-Plane 11.35, the information in the “Features” column in the X-Plane airport selection menu came from any scenery in a user’s Custom Scenery directory, rather than being an entry in the system-wide apt.dat in the Resources/default scenery/default apt dat/ directory. The assumption was any addon airport would always be 3D. But starting with X-Plane 11.33, all global airports, even those with 2D-only layouts, were now included in the Global Airports –which made the X-Plane GUI effectively list every airport as “3D”.
At export, WED 2.1 will analyze the scenery for 3D content and look for the existence of the meta-tag “GUI label”. If the export target is 11.30 or higher it will warn if the tag is missing or improperly set, ultimately leaving it up to the designer how they want the airport to be listed in X-Plane. If the target is “Gateway”, it will forcibly create or update this meta-tag to always be set correctly according to the actual scenery exported.
In order to fix the 2D/3D display in X-Plane 11.35 and later for any scenery not submitted via the Gateway, authors will need to manually add the tag via “Airport->Add Meta Data” and then re-exported to a target of X-Plane 11.30 or higher.
X-Plane 11.34r1 is now available as a beta for those who update via the Laminar Research installer. We expect to make it available on Steam in the next 24 hours or so. This update includes a Plane Maker UI fix and a couple crash fixes.
Gateway airports live in two locations in the X-Plane install folder: 3D airports live in Custom Scenery, while 2D airports live in Resources. X-Plane 11.33 now includes all airports in the Custom Scenery Global Airports folder.
This could cause issues with how your Custom Scenery pack displays. We saw this with the KSEA demo area — the 2D non-customized Gateway pack suppressed our KSEA Demo Area pack for some users.
We are fixing this for X-Plane 11.33r2, but as a general recommendation: please make sure that any custom airports you have installed are higher in the scenery_packs.ini file than the “Global Airports” pack that comes with X-Plane. This way the gateway airports won’t hide your custom scenery.
We have a small handful of web sites (mostly WordPress, but with one custom Node.js+Express app) that we’re looking to hire someone to provide ongoing maintenance for, including bug fixes, new features, dependency updates, etc.
This would be part time (ideally about 10 hours a week) and remote, working whatever hours you prefer. We’d like to start by dividing your time in half between WordPress and Node, but we may shift that balance as time goes on.
This is something we have an ongoing need for, so if you’re a freelancer, this is an easy way to add some stability to your schedule for potentially years.
About the sites you’d be working on
On the WordPress side, we version the themes and all essential plugins in Git, and deploy them via Git push to WP Engine’s servers. We have automated tests in place for a lot of the essential sales functionality, so that you can deploy to a staging environment, test it, then deploy to production once all the tests pass. Our sales site runs on WooCommerce, with a small handful of custom plugins to deal with weird stuff specific to our business.
Our Node app (the Scenery Gateway) is a glorified CRUD frontend for users to upload scenery for the flight simulator. We have a reasonable amount of documentation on the organization of this app and its integration tests—see the README for more info.
Qualifications
A qualified candidate will have:
Outstanding judgement and ability to self-direct. We won’t be looking over your shoulder constantly, so we’ll expect you to be able to prioritize issues, manage your time, and make responsible decisions on the future of these projects.
Experience working remotely.
Experience in both JavaScript and WordPress development. (You don’t need to have written Node.js or Angular.js specifically—experience with React, Ember, Knockout, Vue, <insert JS flavor of the week> are fine.)
Excellent written communication skills in English.
Long-term availability for roughly 10 hours a week.
What to expect from us
We won’t be doing any sort of grueling interviews for this position—we expect to hire based solely on seeing your past experience, plus maybe a Slack chat or two.
We do our best to cultivate long-term relationships with contractors—we want you to love working with us. With that in mind, we will:
Pay you competitively.
Pay you on time, every time.
Respect you as a professional.
How to apply
If this is sounds like a good fit for you, please shoot me an email with the following (my email is my first name at X-Plane.com):
Some code samples/a GitHub link/your Stack Overflow account/etc.—anything that would demonstrate your knowledge of both WordPress & JavaScript stuff.
One or more references we could contact about past freelancing work you’ve done (doesn’t have to be web related)—we’re basically looking to have a third party confirm that you have good judgement, good communication skills, etc.
Fair warning: I expect to get an absolute flood of emails here, so I won’t be able to respond to every one. I’m planning to make a hiring decision two weeks from today (on May 13th), so if you’re interested, please let me know ASAP. 🙂
Since my last Vulkan update, we now have the full sim running natively with Vulkan and Metal! There is still a pretty big list of random things turned off or bypassed to make this happen, but we can fly in the cockpit and use the sim.
Here’s some stuff that is now working:
Using regular and HDR rendering, and SSAO on metal.
Flying with Vulkan on AMD, NVidia, and Intel drivers.
Hardware stereo rendering on OS X – this never existed before Metal because the Mac GL drivers didn’t support it. Hardware stereo rendering is necessary for VR support.
MSAA on Metal – with the restructuring of our code, you’ll be able to change MSAA settings without restarting. I don’t know if this code works on Vulkan right now; it might.
Here’s some stuff that does not work yet:
Plugins are bypassed right now. We have not yet written the plugin-OpenGL-interop layer.
VR only works when using OpenGL as the driver; we need to write some new VR code to pass Metal and Vulkan frames directly to the OVR and Rift APIs.
Screenshots/Movie capture are a work in progress – that’s what I’ve been working on this week.
We still have a number of visual bugs, so screenshots are an important feature so we can run our automated test system. The test system takes hundreds of screenshots of the sim in many configurations and compares them to 11.30 to catch bugs introduced by the new Vulkan and Metal back-ends. Clearly I’ll have to fix my color problems first.
One fun aspect of this port: Metal and Vulkan copy Direct3D’s convention where the viewport Y axis points down and not up. This resulted in a whole series of weird “it’s upside-down again” bugs, most of which have been fixed.
The world is drawn correctly but the atmosphere around it is upside down.
(That airplane might look silly, but at least all of the image is consistently upside down. That’s because the only remaining upside down code is the movie/screenshot capture code itself.)
We should have some performance numbers to post next week; right now our primary focus is fixing bugs, particularly bugs that bring the whole machine down.
Here are a few more pics of things that have gone wrong during development.
