Why don't you address the common complaints that prevent X-Plane from being the next sim of choice for everyone? For example, the lack of airport buildings.

 

The lack of actual 3-d airport buildings has been a gaping hole in X-Plane for a very long time; it’s important to us not only because we hear about it immediately from FSX converts, but also from users who are entirely new to flight simulation. As we increase the detail in all parts of the scenery, the lack of airports becomes more of a glaring hole.

 

(Of course, experienced flight simulation enthusiasts know to get airports from freeware and payware vendors, and it’s not unusual for me to see an X-Plane log report from a user with over 2000 scenery packs installed! But the first impression and demo impression of X-Plane are very important, so world-wide airports that come with the simulator are really important.)

 

The good news is that, after a lot of work, we’ve finally “closed the loop” on our community-contributed airports program. We started by enhancing the simulator’s engine: buildings extruded around a polygon (“facades” in X-Plane terms) can have huge amounts of 3-d detail in X-Plane 10. We then added real-time shadows and real 3-d night lighting.

 

Tom Kyler then built a library of airport “lego brick” buildings - these are high quality, detailed buildings that look good close up, but are also carefully optimized to not kill framerate. They have variable detail with rendering settings for all ranges of computers, and the library is designed to let us add more variety and detail in the future.

 

We then enhanced WorldEditor, our free cross-platform scenery-editing tool. The new 1.2.1 release contains everything an author needs to easily place the lego brick buildings at an airport. When we released WED 1.2.1 we received over 250 user-made airports for the first collection round.

 

When I went looking through the user submissions, I was blown away not only by the quantity of airports that our users created in a short time, but by the quality. Our users did some really incredible work. That first batch of airports contains over 38,000 individual 3-d object placements!

 

We are now working on a website to let users upload airports to share, download and look at the latest uploads, etc. It’s clear that there is a ton of interest, and Robin Peel (who has managed the crowd-sourced airports in X-Plane for a very long time) needs more infrastructure to handle the increased load. We’re working on the submission process and policies now; I’m hoping we’ll have the site live next year.

 

If I can add one final thought on airports: when I first started poking at X-Plane, as a user, back around 2000 or so, the level of detail in scenery and airplanes was much lower. As a result, I could dabble in everything - livery painting, 3-d modeling and scenery, add-on plugins, you name it. Fast forward over a decade and it now takes a team of several developers to make one high quality airliner; the stakes have really been raised considerably.

 

So one reason why I am so excited about the new lego-brick airports (and using OpenStreetMap data for the global scenery) is that it gives users a way to create with X-Plane without having to become experts in 3-d modeling and photoshop. For me, the ability to add stuff to X-Plane as a hobbyist is as important as the ability to fly.

 

What about ATC?

 

Our goal with X-Plane 10 was to build the foundation for an ATC system that we could continue to add to for many years; this is similar to what we did for the scenery system in X-Plane 8.0; build a foundation. We wanted to make sure the system would be able to gracefully gain additional features and additional levels of realism.

 

Our short term goal with ATC is to fix a few nasty bugs and usability issues that can interrupt the IFR flight experience. I think that a few bug fixes are going to go a long way in terms of usability.

 

Once we can get IFR flight working without problems, then we’ll look at adding in additional types of flight (e.g. pattern work, cross-country VFR, non-towered airports), improving the depth of the simulation experience, and opening up the ATC system to third parties. There are a ton of ways to customize the ATC system that remain to be explored; third parties can modify airspace, modify ground operation routes, add new controller voice packs, and even apply real-world audio files based on the instructions being issued.

 

For users who want a more immersive and realistic experience, it’s tough to beat an online network like Pilot’s Edge of VATSIM; there’s just something about having a real human being on the other end of the microphone that adds depth of simulation beyond what we can do with an AI algorithm.

 

Will we have the chance to better fine tune prop turboprop and jet engines, trying to adapt them to their RW counterparts, and BTW, do you plan to change the logic of the free-running turboprop model so that we do not see FF changes with RPM changes, at constant alt and throttle settings?

 

I’m not a physics guy, so I can’t comment on the specifics of turbo-prop performance. We have ideas for what we want to do with the engine model, but it is also possible now (and not uncommon) for third party add-ons to model engines themselves today via the plugin system.

 

Will we get a better default GPS, with more functionalities, including route editing, etc...?

 

Yes! Perhaps the most frequent feature request we get is for a more complete GPS simulation. One of X-Plane’s core constituencies is real-world pilots who practice real-world IFR on a home simulator.

 

Before I worked for Laminar Research, I was in an aviation sciences program as a pre-amble for ATC training. While I was taking IFR ground school, I would practice my scan, approaches, and other real-world steam-gauge IFR in X-Plane - the instrument simulation was smooth and realistic, including the subtle way you lose your gyros after a vacuum system failure.

 

Fast forward ten years and in-cockpit GPS is ubiquitous; we hear from more and more pilots “I need a GPS to simulate what I have in the real airplane.”

 

The good news is that we have already made significant progress in this area, and in 2014, X-Plane 10 will get a major upgrade to its built-in GPS. This will be a big help for pilots who need to practice modern, GPS-driven IFR flight.

 

Will the changes made to the flight dynamics model allow for a better / more plausible behavior of prop aircraft, namely by having more yaw than bank as a consequence of the prop spiraling slipstream effects, and thus accounting for the infamous "torque bug"?

 

I can’t comment on any particular reported bugs without digging into all of the specifics first. We are always working to improve the flight model, including real-world flight tests to try to isolate real-world behavior.

 

X-Plane has been in development for years now, and the current sound engine leaves a lot to be desired. Can we expect a new engine in the near future?

 

We do have some ideas about how to improve X-Plane’s sound interface, but unfortunately they’re not on the short list; we have other feature work that is higher priority. For now third party aircraft add-ons can generate their own sound using X-Plane’s plugin system.

 

What is your road map for Autogen improvements? Do you plan to do regional specific autogen during X-Plane 10's run or is this a goal for X-Plane 11?

 

We are working now to add more variety and detail to the autogen artwork. X-Plane 10’s autogen is completely new - it is both a clean slate compared to X-Plane 8 and 9, and it is completely new in terms of what an autogen system tries to accomplish.

 

Most autogen systems work by planting 3-d on top of a ground texture; this creates nice plausible scenery, because the 3-d and the ground texture make sense together, e.g. a house sits at the end of a picture of a drive-way on the ground. But this kind of ‘terrain’ autogen doesn’t work well when you go to add real-world road-grid data to a city. The real-world roads conflict with the pictures of roads in the autogen tiles.

 

We started using real-world road data back in X-Plane 8; since then the amount of data on OpenStreetMap has just exploded; we can get really high quality road data for most populated areas that have flight simulation users, and the data set is growing rapidly. So we wanted an autogen system that could produce visually high quality results while continuing to use vector road data that is getting better every year.

 

X-Plane 10’s autogen gives us both dynamically generated autogen (with 3-d that matches the ground) and cities based on real-world road grids. It does this by filling autogen areas with a number of small tiles instead of treating the entire terrain as one big tile. The individual small tiles have rules for how they can be positioned and manipulated; the actual autogen happens individually on each tile.

 

The result is autogen that looks like it was hand-built to fit the local area, even if the roads wind or curve or the blocks are funny shaped. But to get this level of articulation, the artist has to build the autogen in smaller pieces and provide rule information for how the autogen tiles can be moved around. This is why we have to create all-new autogen for X-Plane 10, a process that is still in progress.

 

I think region-specific autogen is still a ways off; although it is a high priority for us, it’s just a huge job. There is a big opportunity for third party developers here too; the autogen system can be customized via library scenery packs, so a third party can easily improve or replace our autogen, globally or regionally.

 

Seasonal textures are one of the features most requested by users. What is your roadmap about it? Are you considering implementing it using shaders (like FlightGear is now experimenting) instead of conventional textures sets?

There are actually three separate aspects to the feature.

 

Engine support for season-based textures is a relatively simple feature in X-Plane; I suspect we will get it done in the next few patches. The only reason it hasn’t been done yet is that we don’t have seasonal textures to use with the engine yet.

 

Creating seasonal variants of our entire (large) default land-class texture set is a much more complicated problem; besides the work of creating the textures, there’s the question of how realistic the seasonal model should be. A four seasons model may not be appropriate for parts of the world other than the US and Europe. We’ve looked at this a little bit but we do not yet have a climate model we are happy with.

 

Finally, there’s snow; to me snow isn’t a seasonal feature, it’s a weather feature, and to me it is more important than seasons. Winter is cold, but snow and ice change how your airplane flies. For snow, I don’t see us doing a straight texture-substitution, although this has already been available in the past as a third party add-on.

 

Our ideas on snow and ice involve shaders and dynamic effects; we tend to look at the first-person-shooter games (and not FSX) for inspiration as to what is possible now.

 

Our approach to terrain is somewhere between FSX (all texture sets) and FlightGear (experimenting with procedural texturing). Our terrain starts with image-based reference material (similar to FS X) and then goes through shader processing to create more variety, detail, and to apply the textures dynamically to the terrain. I don’t see us ever going full-procedural; our artists get too much mileage out of being able to use pictures of “real stuff”, but at this point the shading aspect is also critical - the GPU has too much power and flexibility to ignore.

 

What is the long-term strategy of X-Plane? In other words, apart from the nitty-gritty bugfixing and small-scale additions, what extensions do you plan, say, during the next 2-3 years?

 

We shipped X-Plane 10 with major rewrites and changes to quite a few sub-systems: the rendering engine, autogen, ATC, lighting and weather all got serious overhauls.

 

Immediately following the release, we focused our effort on bug fixes, stability, and general improvements to usability; this effort ended with the move to 64-bit with X-Plane 10.20; with a 64-bit simulator, we have the memory space to run with high settings and a lot of add-ons without running out of memory.

 

We are now working to improve what we started, particularly on the scenery front, with additional autogen artwork, updated DSF terrain tiles, and user-created lego brick airports. The next few releases will mostly focus on adding polish and finish to areas where we’ve already made major generational changes, as well as performance improvements.

 

I think once we are done with “improve what we have”, we’ll be able to put in some engine enhancements that we’ve had our eyes on for a while, but areas where we have already done significant work have first priority.

 

Has LR ever considered outsourcing portions of the sim to be developed by other teams of developers and thus allow you to focus on core improvements, especially with regard to common areas of complaints (regional autogen, lack of landmarks, A/I traffic, seasonal artwork)?

 

We have in the past looked at buying off-the-shelf libraries for parts of our simulator, but often our technology needs are pretty specific. The size of the internal development team has been steadily growing from release to release, which also gives us more capacity to build content internally.

 

Interfacing aircraft controls is considered by some to be difficult. LR has remained firm on not implementing mouse wheel manipulators yet with XP10 several "by popular demand" improvements to the sim have been made. Will LR consider any new options for users to improve their ability to control their aircraft; not just mouse wheel manipulators but persistent and easily configurable control layout configurations similar to what FSUIPC offers to the MSFS community?

 

X-Plane’s virtual cockpit system has a lot of options to control user interaction; we actually added additional modes of 3-d cockpit manipulation in an early patch to X-Plane 10 to give authors more options.

 

The big task that remains is to go back over our own internal fleet and apply consistent standards to how the virtual cockpits are manipulated, using the latest mouse-manipulation options and consistent modes of mouse-manipulation between planes.

 

A common observation of X-Plane is that it seems geared more towards intermediate or advanced simmers, or real-life pilots. To that end, what is Laminar Research's goal/mission statement when it comes to X-Plane - specifically, will the focus remain more towards the engineering and aeronautics niche of simming, or will it become more inclusive of more casual simmers? Follow-up: If inclusion of casual simmers is desired, what steps are currently planned for X-Plane 10 to meet that goal?

 

I think there are things we can and should do to reach a wider audience of flight simulation users and limits to how wide of an audience we can reach.

 

The big thing we can do is to make X-Plane easier to use. There’s no reason why we can’t have a clear user interface, simple, quick and painless hardware configuration, a product that is more likely to work out of the box, easy and fast updates, etc. We’ve already made some progress on this front in X-Plane 10 with the QuickFlight screen and other UI enhancements; our work on the joystick subsystem set the groundwork up to make hardware configuration simpler and more flexible.

 

What I don’t see us doing is simplifying the laws of physics or changing X-Plane from a simulator into a game. If you fly a single engine prop in X-Plane without rudder, you will yaw.

 

One reason why we picked the P-180 as the startup aircraft for X-Plane 10 was that the props rotate in opposite directions, which make it easier for new users to fly without rudder. The Cirrus Jet (the default aircraft for X-Plane 9) was similarly easy to fly with just the mouse. So I think we can make user experience decisions that make the product accessible without making it unrealistic or untrue to real-world aviation.

 

What are the top 10 features, complaints, or requested fixes submitted by users. What priority has been assigned to them; or if they've been rejected, why and perhaps what would it take to change your minds?

 

I can’t comment on the internal scheduling or project planning for X-Plane; our overall policy is to announce new features when they are ready (or nearly ready) to ship.

 

One of the reasons why we keep unfinished and speculative tech quiet is that it can be very hard to predict when a feature will ship. We originally thought we would ship realtime shadows for X-Plane 9 - we even had a working implementation. But the quality was really poor…bad enough that people would have assumed they were looking at a bug.

 

So we put the code on the shelf and came back to it - after significant rework we shipped real-time shadows in X-Plane 10. Had we said “X-Plane 9 will have real-time shadows”, inevitably users would have been disappointed when X-Plane 9 did not have the feature. But because we did not announce it, users instead were happy to see the other features (real-time reflections, volumetric fog, etc).

 

My take-away from the experience is that new code, code that has never been developed in the flight simulation market, can be very hard to predict from a schedule perspective, so the best thing is to not over-promise.

 

With that in mind, one of the biggest requests we get from users is for better GPS navigation, something that we have already made significant progress on this front; in 2014 we’ll have a serious GPS upgrade for X-Plane.

 

In terms of requesting features, communicating with us and changing our minds, I can say a few things:

• - We do like to hear from users about what they are interested in! User feedback is important to us and is one reason why the emails of the development team are public.
  

• - Please don’t repeat yourself. Once you’ve requested a feature, sending the request over and over doesn’t make the case stronger - it just makes us grumpy.
  

• - We want to know what you want, but not how you want it done. So “snow in the winter” is a good feature request; “a seasonal winter texture” is not so good. Snow in the winter can be coded via shaders, not just with a texture, so we want to know what end result you are looking for, not one particular implementation (which might not be the best implementation).
  

• - We want to know why you want a feature, but don’t bother to tell us how easy it will be to code or how much money we will make. We get a fair number of feature requests that mention (as a reason why we should code the feature) that it should be easy to code, or that we’ll make a ton of money if we code it. These assessments are just speculation, so they don’t convince us of anything but they do take away from the main point of a feature request.
  

Will there be multiple undockable window views for a single PC with a hefty graphics card in the future? Will there be a licensing option for cockpits which may use as many as 10 PC's? Buying 10x X-plane copies is a bit heavy since it is still effectively one user.

 

I don’t know the answer to that; I can say that as GPUs become more powerful, we are looking at the future of multi-monitor. Unfortunately it’s not as simple as “put a bunch of views on one GPU”. X-Plane aims to provide top-end settings that work well with one big GPU on one big screen, similar to what you might have in a game. This doesn’t leave a lot of GPU left over for multiple monitors. Multiple GPUs could communicate with multiple cores, but then you start to share total bus and memory bandwidth.

 

Simply put, duplicating some parts of a PC isn’t the same as duplicating the entire PC (which is our current visualization system). Still, the technology in this space is changing rapidly, so we do think new solutions will be possible one day.