Update, 2/23/21: we are no longer accepting applications – thanks to the tons of people who have contacted us! We are in the process of going through resumes, code samples, and interviews now.
We’re looking to add a senior developer to the Laminar Research team in the coming weeks.
As an X-Plane developer, you would work on both our desktop and mobile simulators, and you’d have quite a bit of latitude to work on the projects you find most interesting. At various points, you might find yourself doing things like:
- UI development
- Low-level performance optimization
- Improvements to the X-Plane SDK used by third parties
- Rendering engine work
- Platform-specific OS integrations
(We don’t expect you to come into the role with deep knowledge of all those things. We like to hire “T-shaped developers,” people with deep knowledge in one or two areas, who can be flexible and pick up new stuff in other areas as the need arises.) Read More
[This post is a “behind the scenes” look at the tech that makes up the X-Plane massive multiplayer (MMO) server. It’s only going to be of interest to programming nerds—there are no takeaways here for plugin devs or sim pilots.]
[Update: If you’re interested in hearing more, I was on the ThinkingElixir podcast talking about this stuff.]
In mid-2020, we launched massive multiplayer on X-Plane Mobile. This broke a lot of new ground for us as an organization. We’ve had peer-to-peer multiplayer in the sim for a long time, but never server-hosted multiplayer. That meant there were a lot of technical decisions to make, with no constraints imposed by existing code.
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:
The new, always-up-to-date X-Plane usage data “dashboard.”
Like our blog posts, this is based on data collected from paying users of X-Plane 11 who have opted-in to data collection.
Unlike our blog posts, though, this updates daily based on live usage of the simulator!
Have a look, and if you spot any bugs or want to see something else, let me know in the GitHub project’s issue tracker.
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.
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.
- 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):
- 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. 🙂
I’m headed to the annual Game Developers’ Conference in San Francisco next week.
If any folks from the flight sim community are going to be there as well, I’d love to meet up and talk shop—hit me up on Twitter (@TylerAYoung), or send me an email (my email is my first name at X-Plane.com).
EDIT: See the recording of the Q&A session here on YouTube!
We’ve been posting about this on social media for a bit, but realized we hadn’t talked about it here.
Today at 11 am Eastern (16:00 UTC; click here for time zone math) we’ll be doing another live Q&A on our YouTube channel. We’ll be taking questions in the YouTube comments, but if you can’t make it live, we’ll try to answer a few questions from the comments on this post.
In case you missed the first, second, and third (part 1 & part 2) rounds of this, this is a streaming broadcast featuring:
- Austin Meyer, owner & creator of X-Plane
- Ben Supnik, desktop product manager
- Chris Serio, mobile product manager
- Alex Unruh, art director
- …and a handful of other special X-Plane friends.
Over the weekend, I published a Python package called
xplane_airports. This serves two major use cases:
- Parsing the airport data (
apt.dat) files used by X-Plane, and asking questions like “does <some airport> support <some feature>?”
- Nicely wrapping the X-Plane Scenery Gateway’s API to get information about the airports available there. This includes the ability to download scenery packs and manipulate them just like you would an
apt.dat on disk.
If you’re doing any sort of automated analysis or manipulation of X-Plane airports, this should be a huge help.
It’s available via
$ pip install xplane_airports
And there’s a ton of documentation in the project’s README on GitHub.
Bug reports, feature requests, & pull requests are all welcome. 🙂
As you may have seen on our social media, we have new joystick features coming in the next major update. There are two major features here:
- Custom response curves
- Special (semantic) ranges for certain axis types
The first may be of general interest, while the second is almost exclusively useful to hardware makers and custom cockpit builders.
Custom response curves
For as long as I can remember, X-Plane has had a “control response” setting, which makes your controls respond non-linearly. More of your joystick’s range is mapped to the center of the your pitch/roll/yaw axis’s center, and less of the range is devoted to the extremes. This gives you fine-grained controls in the region where the controls are typically used, at the expense of more coarse controls at the limits.
In X-Plane 11, these settings live in the Control Sensitivity window (launched from the bottom of the Settings > Joystick screen), and they will continue to be there in the 11.30 update.
The problem with the existing control response setting, though, is that it applies to all joystick hardware you might plug in. You get just three values—pitch, roll, and yaw—that apply to every axis of that type, no matter the device. Moreover, if you have a different type of axis whose input you want to curve (e.g., throttle, tiller, etc.), you’re simply out of luck.
So, in 11.30, we’re adding support for setting custom curves on any axis type. When applied to a pitch, roll, or yaw axis, this will override the global control response curve; applied to other axis types, it will support new functionality not previously available.
These curves are incredibly powerful. They can do things like:
- Manually configure a null zone
- Create a smooth curve (a straightforward replacement for the old “control response” setting)
- Create really complex curves, with loads of control points, and your choice of interpolation method (linear, or one of two methods of smoothing)
But the fun doesn’t stop there!
New semantic ranges
There’s a new component to the curve editor that bears calling out explicitly.
When you’re editing a response curve for certain axis types (throttle, prop, or mixture), you’ll have the option of also configuring the ranges for certain axis-specific behaviors:
- Beta & reverse ranges for throttles
- Feather range for prop controls
- Cutoff range for mixture controls
X-Plane has always set these ranges automatically based on the aircraft model you were flying. For the first time, though, you can configure it yourself to match your hardware.
These are aimed primarily at hardware builders who have physical detents on their controls—you can make X-Plane’s idle point exactly match your throttle’s physical detent, for instance. This makes it possible to build really nice throttle-prop-mixture quadrants that play nicely with X-Plane.
If you’re a commercial hardware maker, and you’d like X-Plane to correctly configure your hardware by default for your users, you can set up both the axis & button assignments and the semantic axis ranges from the settings UI, then click the “Create Default Configuration File” button. Send the file it creates to me (my email is my first name at X-Plane.com) and I’ll get it shipping in the next release.
We’re looking to add a junior UI developer to the team in the near future.
About the position
We need a junior developer to come do user interface work for us. As you may know, the Plane Maker and Airfoil Maker user interfaces did not get the same overhaul that X-Plane itself did for version 11, and we’d like to change that. That’s a major undertaking, and you, dear applicant, could be responsible for it in its entirety.
Beyond that, X-Plane itself has a “long tail” of UI improvements that we’d like to see. You could be the one to move these improvements from “The Glorious Future™” schedule into reality.
Our UI is built on a custom widget-based framework that is only now starting to reach maturity. So, while a lot of your work will involve putting together existing pieces, there will definitely be problems you can only solve by writing completely new UI components. Read More
I’ve gotten a handful of emails from third-party devs recently asking the question:
I have a bunch of XPWidget-based windows. When will I be able to use them with fancy new features like UI scaling, pop-out support, VR support, etc.?
Happily, the answer is: now!
I really buried the lede on this one, but back in X-Plane 11.20, as part of adding plugin support for VR windows, we added a new “mode” for XPWidget-based plugins. It all starts with a call to opt-in to the “modern” window APIs like this:
From this point forward, all widget windows you create will be backed by a modern XPLM window, and can therefore be used with all the new XPLMDisplay APIs. All you have to do from there is call XPGetWidgetUnderlyingWindow() get the XPLMWindowID of your window to pass to those APIs.