This is a tiny feature coming in X-Plane 10.50, but it will make a big difference for a few key plugin use cases: X-Plane will provide the current world model-view, projection, and aircraft model-view matrices to plugins via datarefs.
If you aren’t a plugin developer, or you don’t like matrices, or you don’t write your own OpenGL code, then the rest of this post is going to be boring, so go watch FrooglePete interviewing two funny looking guys. [Edit: link fixed – why that was pointing to airport flattening is totally beyond me!]
For the three of you still here: three matrices will be available:
- The OpenGL projection matrix – that’s the one that is currently set up when your 3-d draw callback is called.
- The OpenGL modelview matrix – we call it the “world” matrix, it maps the official X-Plane OpenGL coordinate system to eye coordinates, and it is also set up when your plugin is called.
- The Aircraft modelview matrix – this is a matrix that maps aircraft coordinates (0,0,0 = CG, +X = right wing, -Z = nose) to eye coordinates.
You already are using two of these, the third is new. So who would even care? There are two use cases for this.
Stop Calling glGetFloatv!
Calling glGetXXX is bad. Modern Windows GL drivers send GL commands to a worker thread for execution, freeing up the rendering thread to keep going, improving framerate. But every time you ask OpenGL a question, our thread has to wait for that driver thread to catch up, slowing everybody down. The rule is simple: don’t call glGetXXXX.*
But there’s one case where your plugin might really need glGet: to get the current matrices for culling 3-d drawing.
This is where the datarefs come in – by reading our datarefs instead of calling glGetFloat, you can get the transform matrices without stalling the driver.
(If you have other glGetXXX that you can’t get rid of, ping me and I’ll try to find a work-around.)
Drawing On the Aircraft Without Jitter
The third matrix (the aircraft model-view matrix) is the matrix you would get if you translated to the aircraft’s location and then rotated around its orientation.
Here’s the key difference: when we do that calculation, we do the calculation in double-precision. We do this because the OpenGL origin can be tens of thousands of meters away from the aircraft, which in turn can be very, very close to the camera. In that situation, precision loss from single-precision floating point when multiplying together two very large matrices (that result in a very small matrix) results in apparent jitter when drawing.
The problem is: even if you wanted to do this calculation yourself in double precision, you can’t – the world matrix isn’t available to plugins in double precision.
So starting in X-Plane 10.50, the aircraft matrix is simply provided.
I did an experiment where I attached a green cube to an aircraft and then drew a blue cube at the same location from a plugin. With glTranslate/glRotate there was a ton of Z artifacts and slop that changed per frame because the two cubes were in slightly different positions. With the aircraft matrix, the green cube was invisible (except when disabling the plugin) because the blue cube overdrew it pixel-perfectly.
- What about glGetError? Call this only in debug mode (to catch mistakes in your GL code); use #if to make sure you’re not calling glGetError in release mode.
I’ve been way behind on blog posts over the last few weeks. Basically, the more we are doing, the less I manage to blog about what we are doing. (Instead I put off writing a blog post until it’s really late and then decide at 11 pm that I’m too tired and I’ll do it tomorrow.)
So here’s a partial list of X-Plane 10.50 features. This is not even remotely complete, it’s just some “headline” features that I can think of now; the release notes will be comprehensive.
New Autogen: We have new US tall building art assets that will make cities look better.
apt.dat 1050 with Static Aircraft and New Models: A new revision of the apt.dat file provides information on parking spots so that we can place static aircraft models inside X-Plane, based on the library and rendering settings. X-Plane 10.50 will ship with a bunch of additional static aircraft models, and third parties can add more via the lbirary. WED 1.5 will have new features to edit this information.
For airports created before WED 1.5 (which is nearly all of the approved airports), we are working on tech to auto-upgrade the gateway airports to use the new static aircraft; third party scenery will simply not participate in the new feature until updated by the authors.
Global Winds Aloft: X-Plane 10.50 will use global NOAA data for winds aloft, rather than a US-only data source.
ATC Fixes: X-Plane 10.50 has a number of ATC bug fixes to make ATC a lot more usable. No more “you are off course!”
New Manipulators: We have added a few new manipulator types as part of an effort to make 3-d cockpits more usable. Yes, the scroll-wheel is accessible. (We have not rebuilt every 3-d cockpit in our fleet. The feature here is the capability in the engine, for us and third parties to use.)
Update King-Air and Baron: we have, however, redone the Kingair and Baron, fixing a number of issues and getting them to a whole new level for IFR flight. These planes use the new manipulators for their 3-d cockpits.
More Airports from the Gateway: as with all releases, we’ll include the latest airports from the X-Plane airport gateway.
Those are just the “big” things – there’s some huge number of other changes, some of which may be really important to some of our users. I still have about half a dozen items on my todo list to get to a 10.50 beta, so I haven’t worked up complete release notes yet.
X-Plane 10.45 fixed one of the big “ecosystem” problems with the global airports by excluding airport objects by ICAO code. This makes the global airports much less likely to conflict with custom scenery, even if that custom scenery lacks exclusion zones.
For 10.50, I am looking at another change to how we manage airports that should help gateway authors: per airport control of flattening.
As of X-Plane 10.45, airport flattening is a user setting; a user can pick to have all airports flat, or all airports follow the terrain contours.
This is a rather silly setup. One size does not fit all for airport flattening, and the author of the airport is more likely to know how the airport will look with/without flattening than a user who is flying to that airport. It certainly isn’t efficient to have everyone in the X-Plane community set flattening individually without authors being able to set up their airport the way they want.
From what I’ve seen, there are two legitimate uses of airport flattening.
- To fix bugs in the underlying terrain, e.g. if the DSF is screwed up, then the airport may need to flatten it to make the airport usable at all. We want this to be the exception, not the rule. (X-Plane 10 is more buggy than past X-Plane releases WRT bumpy runways, so this may sound funny right now, but overall we aim to have users be able to fly with non-flat runways.)
- To accommodate highly customized airports where the 3-d models depend on a flat surface.
In X-Plane 10.50, it should be possible (using a new version of WED) to mark an airport as “always flatten”. The expected usage is:
- Users leave “runways follow terrain contours” on, all of the time.
- Authors mark individual airports as needing flattening, e.g. to fix bugs or accommodate custom scenery.
There is one use case that isn’t handled well by this: if an airport needs different flattening based on different base meshes, there is no way to tag that in the airport. But I view this as a fairly difficult problem to solve with existing technology – we would need a 2-d grid matching every custom version of an airport against every version of the mesh ever to exist.
Fixing the Mesh
Please note that this feature is not a replacement for being able to customize mesh elevation at a local airport from an overlay. “Mesh patching” is what we want to be able to do in the long term, but for X-Plane’s engine, it also means a lot of complicated internal changes to how the rendering engine works; customizing flattening is something I can ship now in 10.50 that at least helps.
Flattening is also not a replacement for fixing bugs in the base meshes themselves; one trend I have observed over my decade+ working on X-Plane (!) is that the accuracy of source data keeps getting better. Ten years ago it would be silly to say “how about if everyone just uses the real world values for their scenery and it will just work”. At this point that’s not actually a pipe dream, it is often completely manageable. So my hope is that someday we can reach a point where the terrain is just accurate and everyone uses it.
As of right now I have this code working in X-Plane but I do not have a build of WED that supports it. We are still in the middle of working on 10.50 apt.dat features, so I’m hoping to post something on that soon.
In my previous post, I posted a screenshot of X-Plane 10.50 with the new autogen update we are working on. This is an AG update that includes a bunch of buildings, particularly tall ones; I’ll post a lot more detail no that in a separate post.
One of the main questions in the blog comments was: “how are you getting this pic with 30 fps? Did you get new hardware?”
Well, I did get new hardware; a few months ago I finally swapped in the first-gen 5K iMac with the R295X GPU or whatever it is. (I thought this was latest but I see now Apple has revised the machine and bumped the GPU up a generation.) So that’s a machine with a bit more kick than my older 2008 Mac Pro.
But more importantly: X-Plane’s autogen engine is really fast. It hits the instancing path almost all of the time and as a result it can draw a lot of autogen at reasonable fps.
When X-Plane 10.0 shipped, I could run the autogen + roads maxed out my old Sandy Bridge PC – that was before optimization on hardware five years ago. I think this is one of the things that X-Plane 10 does really well that people tend not to notice; that code path was hot from day 1!
There’s a third thing going on here: I picked my rendering settings to promote AG + framerate; you can do that too. I see a lot of users running with relatively low autogen density and poor fps due to other settings. And clearly people like lots of buildings.
So here are some tips on how to get a lot of autogen and decent framerate.
- Make sure you haven’t overloaded VRAM. As long as everything that needs to be in VRAM, you’re done; there’s no “better”- you just need to not be overloaded. The way to do this is to turn texture res way down, tune up the system, and then at the end increase texture res until framerate suffers; then turn it down one notch. Remember to restart each time to get accurate texture use.
- Start with the GPU underloaded – small window, no clouds, low FSAA. You can turn those up later after you get the CPU utilized. (If the GPU is bogged down you can’t even see what you are doing.) Note that when you do go to crank GPU settings, do this first and crank texture res last, as the high GPU settings burn “extra” VRAM for off-screen buffers.
- Turn down settings that chew up CPU. Considering turning off AI aircraft and turn the cars way way down. If you use a payware aircraft that eats CPU (and many of them do) you may want to keep it so you can see what your “real” performance will be; saving 10 fps by throwing out the aircraft isn’t great if you want to actually fly.
- Turn down settings that amplify the cost of AG. This might be the most important one; in those pics, shadows are in “overlay” and water reflections are way down. When those settings go up, every autogen building is drawn for shadows and reflections, not just in the scene, making the AG many times more expensive. I suggest shadows on the aircraft in 3-d and the second lowest reflection setting.
You Can’t Always Get What You Want
The other day I was forwarded a very (cough) angry customer email; the customer had a gamer-class PC, turned everything in X-Plane up to max, got about 5 fps, and went absolutely ballistic. We see emails like this over and over and over and over again. “How much @#$@# money do I have to spend to turn everything up?”
In the long term, our plan is to change the rendering settings so a high-end gamer-class PC can run with every single slider topped out; if you want some of the super high settings in some areas of the sim by turning down other areas, this will be possible only by hacking the config files, not by the UI. The current rendering settings scheme is simply not friendly to users.
With that in mind, I look at what combinations of settings we can max out in hardware (to the point where the artists intended things to be) and still have good fps. My current view is:
- The AG system itself is there – you can have all of the AG, and assuming you don’t run out of VRAM, the artists aren’t going to create “more dense” AG, just more variety.
- AG + shadows is still not there, and this my next goal for optimization. My intention is to make shadows fast enough that a gamer class PC can run max shadows and max autogen at 30 fps. We’re no there, but I believe this is possible, and I believe that it is possible using OpenGL.*
- The cars are also not there – they’re just too big of a penalty. I certainly think we could get 2x to 3x the car density for the performance cost that the low setting cars have – and that would be a good place to be.
* Computers also just get faster over time, so I suppose I could solve this by taking a ten year sabbatical. 🙂 Seriously though, if the cars would run at playable fps at medium res, I’d be okay to let hardware improvements get us to really dense traffic.
Update: some answers about performance, hardware and settings.
A user asked me to write a little bit about Vulkan. My first reaction was to not post anything for a simple reason: Vulkan is a feature for me, not for you. That is, Vulkan does not make you (the user of X-Plane’s) life directly better; instead it makes my development job easier and it makes it possible for me to create a better X-Plane.
Some day if we end up running on multiple drivers (e.g. Vulkan and OpenGL and Metal), you may not be able to tell the difference between the Vulkan and OpenGL version; the sky won’t be more blue, the clouds won’t be more puffy. I can’t think of any features exposed by Vulkan that aren’t in OpenGL 4.x with extensions now — we already have sparse memory, tessellation and compute in OpenGL. (But then, you might actually be able to tell because framerate might be higher.)
Anyway, having finished reading the (700+ page – that’s what down time in the airport is for) Vulkan spec last week, the rest of this post is my view on Vulkan as a 3-d graphics developer. This is definitely an “inside baseball” kind of post, so if you want to go surf cat videos, I won’t be offended!
The Problems with OpenGL
For an application like X-Plane, Vulkan is an improvement over OpenGL; to understand why we have to look at the problems with OpenGL as an API that allows applications to communicate with 3-d hardware drivers. There are a few:
- OpenGL’s approach to multi-core and threading are antithetical to performance. This is really the straw that broke the camels back for me and OpenGL. Developers who know me know that I’m not a “burn it down and start from scratch” kind of guy*. But the threading model in OpenGL requires drivers to hurt performance with safety checks and locks that an application can’t get away from. This isn’t something you can just fix with an extension.
- OpenGL’s object and binding model also make multicore performance difficult. The use of a “current” object in a context and the ability to radically change objects after they are built mean lots of driver paths require internal locks.
- OpenGL’s compatibility is its greatest strength and greatest weakness. The original plan to rebuild the object model in OpenGL 3.0 died before it was released. Instead the ARB came up with a plan to optionally deprecate APIs. Every vendor of OpenGL except for Apple has chosen to keep backward compatibility with everything. That’s great for keeping old apps working, but it means every change to OpenGL is expected to work with everything else there ever was, ever.
- OpenGL requires that shaders be compiled by the driver. This means an application is exposed to idiosyncrasies in the compiler of each driver we ship with. This isn’t as bad as it used to be, but writing shaders is still a matter of write-once, check everywhere.**
How Vulkan Helps: The design principles behind the Vulkan API address all of these issues.
- The biggest single feature of Vulkan is its new multi-core friendly threading model. Vulkan is “externally” synchronized, which basically means applications can do whatever they want, but have to talk to different parts of the driver from different threads. To use an analogy: OpenGL is filled with traffic lights. Vulkan doesn’t even have stop signs, and it’s up to two drivers to not be on the same road at the same time. (As application developers, this is a great setup, as we know what roads we are on and can plan to not have collisions.)
- The object model clearly separates expensive creation operations from inexpensive usage operations. Expensive object creation can be done on worker threads or at initialization time. Objects can’t be radically reconfigured once they are built, so the small changes that are allowed to existing objects aren’t slow.
- Shaders are compiled ahead of time into an intermediate representation; no more shader compile fails after a driver update.
Vulkan is a smaller, lower level API with clear performance guidelines and a focus on multicore from day one. This is a good fit for what we need with X-Plane.
The Problems with the OpenGL Ecosystem
The OpenGL ecosystem is the collection of all of the companies and programmers working with OpenGL. This includes the vendors of graphics chips who create OpenGL drivers (NVidia, AMD, Intel, Imagination, Qualcomm, ARM), OS vendors who provide OpenGL interfaces (Apple and Google), the major game engine developers that have the ear of the hardware vendors (think Unreal Engine 4, Unity, etc.), the major CAD application developers, etc.
More serious for OpenGL than the problems of the API is the state of the ecosystem.
- OpenGL’s API is underspecified: there is no comprehensive conformance test for OpenGL, so we can’t really know if an OpenGL driver works or is buggy.
- OpenGL’s API is underspecified: no performance guarantees or even recommendations are made. If you ever look at the tech blog Chris and I maintain, it’s full of posts about the latest witchcraft I’ve found to make vertex throughput go faster. That stuff isn’t part of the GL spec, yet you have to know it to build a real-time graphics application.
Given the lack of specifics, application developers and driver writers end up locked in a sort of death-spiral:
- Driver writers observe the behavior of applications and change the driver behavior to work around applications. This can include trying to improve performance and trying to bandage around broken behavior. (Since games are the typical benchmark for new graphics cards, NVidia and AMD are hugely incentivized to make games run faster by any means possible.)
- App developers observe the behavior of the drivers and change application behavior to work around driver issues. In X-Plane’s case this often means intentionally not using the optimal code path for driver stack X because it is slow. If the driver team ever fixes code path X, X-Plane still isn’t using it; when the driver team looks at performance they then decide to improve code path Y (that we are using, the backup plan) because that is what will make our app benchmark faster.
How Vulkan Helps: Vulkan helps by being much more highly specified in terms of both conformance and performance.
- Vulkan is a much smaller, simpler API – OpenGL has simply become too complicated to completely test. With Vulkan, we can hope to test the entire driver.
- Vulkan is being built with an open source test suite from day 1, with the goal being to build up a huge number of tests so we can know that a given driver is correct.
- The Vulkan API is very clear about what operations are fast and what operations are slow. An application that uses the fast API can expect fast performance on those code paths. Guessing is not required.
Downsides to Vulkan
For smaller OpenGL application developers like Laminar Research, I can think of just one down-side; it’s one that I haven’t seen a lot of application developers talk about, probably because it requires admitting that we (the app developers) might not be as smart as those driver guys.
OpenGL is a higher level API; OpenGL applications leave some of the hard problems of 3-d graphics up to the driver. This means that some of these very hard, very important performance problems are being solved by a team of engineers from the company that built the hardware. They have resources, they know everything about the particular hardware they are coding for, and performance is job one.
Vulkan is a low level API; with Vulkan, some of those hard problems will be solved by Chris.
Ha ha…no, I’m totally kidding. We don’t let Chris play with pointers or any other sharp objects. That code will be written by me, and it’s a safe bet that I know less about the hardware than the driver team and have less time to do pure performance work then all of the engineers at Nvidia or AMD who work on the OpenGL stack.
This is a calculated risk for Vulkan as an eco-system. The hope is that (1) with specific information about performance as part of an API, us application developers won’t screw things up too badly and (2) because we (the application developers) know more about our specific applications, we can optimize performance in ways the driver guys can’t because they don’t have the bigger picture. One of the hardest problems in a graphics API is conveying intent; OpenGL drivers spend a ton of code trying to guess what the application is trying to do. Vulkan solves this problem by letting the application make performance decisions itself.
Next Steps
If you know OpenGL but don’t know a lot about how 3-d graphics hardware really works, reading the Vulkan spec is a little bit like believing that Santa Claus brings your presents down the chimney and then [spoiler alert] one day reading a 700+ page PDF that explains how your parents actually buy the presents a month or two in advance, wrap and hide them, and then sneak them under the tree while you are asleep.
For X-Plane, the Vulkan spec makes clear what types of operations future drivers will support, what will be done for us, and what we have to do ourselves. This gives us a good framework to then incrementally build next-generation rendering code in X-Plane that is “Vulkan-friendly” – even if it is still using OpenGL. My guess is that this new code will be faster than the code it replaces even before we change drivers.
Once we have the rendering code restructured and modernized, we can then set it up to run on Vulkan or OpenGL, taking advantage of the Vulkan pathways where they exist.
One final thought: I have no idea how the actual experience of coding for Vulkan will be. It may be that everything “just works”, or it may be an exercise in frustration. Once we’ve been through a full port I’ll post a post-mortem, but I think it’s too soon for anyone out there to have good realistic feedback on a full Vulkan porting experience from OpenGL.***
* And when people suggest ground up rewrites I usually link to this.
** For what it’s worth, the driver shader bugs I see (and the ones that really take up my time) are bugs in the back end of the compiler, where optimized machine code for the GPU are generated. Vulkan isn’t going to fix this; Vulkan removes the front end of the compiler from the driver but not the back end.
*** Yes, there are games running on Vulkan now. But if your game is already running on multiple APIs, that’s different from porting a straight OpenGL app. The final spec and roduction drivers haven’t been out long enough for anyone to be able to say “I ported half a million lines of OpenGL code to Vulkan and here’s the result.”
Ondrej has posted a public thread about the new version of the Blender 2.7 exporter here.
The 3.3 release is the first release where we (Laminar Research) have worked closely with Ondrej to build what we hope will be one of the future cornerstones of modeling for X-Plane.
If you are currently using Blender 2.49 or AC3D, I expect that 2.73 will provide the best way forward for modeling in X-Plane.
New Stuff
The new release has a few major features, all aiming to create a new modern work-flow:
- All animation bugs are fixed. (At least,we think – if you find one, please report it ASAP!) This means animation is WYSIWYG. Armatures are supported for animation as well as animated data block containers.
- The exporter understands all modern OBJ features, including ones scheduled for release in X-Plane 10.50.
- Instancing is handled via a single option with exporter validation, so you don’t have to know how instancing works to get instancing.
- The material rules are validated, and materials are found automatically; you can simply model as you want and Blender will do its best to export it or tell you if there is a problem.
- Specular and Normal maps are ‘merged’ together from two separate sources. This lets you set specularity and normal maps in separate material channels in Blender for a more WYSIWYG approach. It also means no more messing with Photoshop to combine these layers.
The goal of many of these is to hide the idiosyncrasies of X-Plane’s modeling format and provide a cleaner, more artist-friendly view of modeling.
Regarding instancing: the model we have adopted is the one we used internally on the 2.49 exporter: you (the artist) tag an export as either “instanced” or not.
- If instancing is on, the exporter writes only data to the OBJ that will be hardware-instanced by X-Plane. If you do something that cannot be instanced, like animation, you get an export error telling you what you have to remove.
- If instancing is off, the exporter writes the object normally.
The win here is that you don’t have to know the (complicated) instancing rules; set instancing for the scenery objects you need to make fast in bulk (e.g. a luggage cart, a house, something that will be used many times in a small area) and you’ll get optimal output.
Optimization – Coming Soon
The goal of the 3.3 release was to set up an environment where authors could work using the new work flow. We have not finished optimizing the OBJ output.
If you are using the existing 2.7 exporter for airplane work, the output should be similar in performance. If you are using the 2.49 exporter, the new output is (like the current 2.7 exporter) not as well optimized.
In a future update, we will tighten up the generated OBJ code; this should not affect anyone other than producing better OBJs.
Compatibility
The new exporter should be fully work-flow compatible with the previous Blender 2.7 exporter; if you find your existing project does not work, please file a bug!
Our plan is to create a migration tool for Blender 2.49 projects; this will forward-convert the datarefs on annotations, manipulators, and object properties from 2.49 to 2.73 format. This lets authors using 2.49 move forward to 2.73 and have a migration path for existing content. (This work is not started yet, but is planned – we have our own aircraft we need to keep working on.)
Things have been quiet with the mobile product recently but that’s only because we have been working on some new features that we didn’t want to talk about until we had them running reasonably well on a variety of devices. Well, we have made some great progress and now I’m happy to start talking about it.
What’s the big secret?
So what have we been working on…..? Taking the entire X-Plane 10 Desktop flight model and aircraft systems! That means all of the physics, all of the systems, all of the datarefs, as well as 99.9% of the panel system and instruments*. I cannot emphasize enough how unprecedented this is on a mobile device…and it will be free of course. Read on for specifics…
Flight Model History
Let’s rewind time back to 2007 when the original iPhone was being released. We had about 25MB of memory to work with and a very limited processor. There was absolutely no choice but to prune the flight physics and all of the systems back to the bare minimum. This has been our mobile product’s foundation for the past 9 years…a reasonably good approximation of flight physics and systems that is adequate for mobile devices…but very limiting for us as developers and also a bit limiting for users as well. Lately, we’ve been moving over pieces of the desktop flight model a little bit at a time (for example, Airliners required a better slat and flap system) but it’s time consuming and tedious.
Where we’re headed…
Over the last couple of months we’ve been reorganizing our systems and now have most of the desktop systems running on our mobile product…even on the older devices that we support like the original iPad Mini/iPad 2/iPhone 4s. We’re still actively integrating the systems so it’s not ready for release just yet, but a lot of the work is done.
So what does this mean for users? Archimedes said “Give me a lever and a place to stand and I will move the earth.” The mobile product sharing the flight model and systems with desktop is a HUGE….MASSIVE….LEVER. It means that mobile instantly gets an FAA Approved flight model…the same one that real pilots train on. An instantly improved autopilot, no more bounced landings (unless you fly like Ben…in which case you’ll still bounce ;)) full electrical, hydraulic, engine, prop, fuel, radios, navigation, pressurization, starter, trim and gear systems.
With all of those systems available in their entirety, it means that the beautiful 3D cockpits that our artists have been developing can come to life with interactivity to touch and manipulate all of the same systems that you can on desktop. Start/Shutdown the aircraft the right way, tune all of the radios, operate the full autopilot etc.
This is the symbiotic relationship that we’ve been talking about since the launch of V10 Mobile. Mobile feature development will improve the Desktop product, and Desktop features will trickle down into the Mobile product.
When is this happening?
Soon? I expect much of this to be done and the first update to happen by the spring for iOS and Android. It will not be done in one release but over several.
The release schedule and contents are still not completely concrete at this point but if I were to take a guess, I’d say that the first release will include the complete flight model. This will be an incremental update for end users because while the flight dynamics will change, the interaction will not change much. It will have the same simple 3 button autopilot and minimal interactivity with the 3D cockpit.
The second and subsequent releases will start to expose much of this new system to users. I would expect to see a new 2D autopilot UI that exposes the complexity of the desktop autopilot…heading, altitude, speed, LNAV, VNAV etc. I would also expect that some of the aircraft panels will have been updated with manipulators that allow you to start touching all kinds of buttons and knobs.
With this kind of leverage, we can release new features faster than ever before. I’ll have more details on that specifically when the time is appropriate.
*We will not have a working 430/530 on mobile in the short term nor will we have a few very uncommon and extreme instruments.
Yesterday we had a bit of a digital download fire-drill: over a dozen Mac users filed bugs or contacted tech support to say that X-Plane couldn’t get their machine ID.
When X-Plane’s copy protection doesn’t work, that becomes the top thing on the priority list, full stop; we never want to see a paying customer unable to use X-Plane.
I contacted a number of users to request detailed information, and from those who I have heard back from, the answer has been consistent: the problem mysteriously vanished just as quickly as it appeared. Some of the users reported making the problem go away by reinstalling or rebooting, but each “work-around” was different, and some users made no changes, making me think the problem fixed itself.
So…the whole thing is a total mystery. While I’m happy to see users flying again as quickly as possible, not knowing what went wrong is disconcerting.
If you are on a Mac and you still can’t use your product key, please do contact tech support by email!
Update: turns out there’s a real explanation – see the comments section. I’m at least relieved that our code didn’t mysteriously go AWOL for one day.
X-Plane 10.45 has been released; if you have run X-Plane you already know that.
This release has another big update to the global airports and updated navigation data. Here’s a complete list of everything changed.
One new feature of 10.45 that may change how you use X-Plane: the global airports no longer conflict with custom scenery – even if you have custom scenery that doesn’t have proper exclusion zones.
So if you have been disabling the global airports due to conflicts, you don’t need to do this anymore. You can use your custom scenery and keep the global airports around.
We are already well into X-Plane 10.50 development – we’ve actually been doing significant 10.50 work for a while now. I’ll have more posts on that soon – right now we are aiming to have 10.50 in public beta in a few weeks.*
* That’s a vague time estimate because it’s not super accurate. Feature work is not complete for 10.50, so it’s hard to know when it will really be done. Our goal isn’t to get 10.50 into beta at a certain date; it is to make X-Plane better as efficiently as possible.
Posted in News
by
Ben Supnik |
