There’s an old joke in finance: if you owe the bank $100, you have a problem. If you owe the bank $100,000,000, the bank has a problem.
This holds true for X-Plane add-ons: if one-add on has a problem, it is the add-on maker’s problem if the add-on stops working. But if every add-on has a problem, we have to change X-Plane to solve the problem. This is what happened with SASL/Gizmo and the 64-bit move: we built 64-bit Lua support directly into X-Plane so that LuaJIT (which is used in most major aircraft add-ons for X-Plane) would keep working.*
This brings me to what might be my least favorite dataref ever: sim/weapons/x (and friends).
The sim/weapons datarefs gave you access to various flight-model data of 25 weapons attached to the user’s plane in X-Plane. The array dim doesn’t make a ton of sense – the last entry is an unused dummy slot for Plane-Maker editing and should never have been exposed.
What if there are no weapons on the aircraft? It turns out that variable behind the dataref would sit there and do nothing, so authors used these as “scratch pad” datarefs to implement cockpit tricks on aircraft that didn’t use weapons.
“Gave”? Yes, the past tense is intentional – virtually all of these datarefs are gone in X-Plane 11.
Now if reading this has caused you to hyperventilate, stop and read the dumb joke at the top of this post again. If you were the only add-on maker who abused the weapon location datarefs for misc cockpit data, I’d tell you that you did a dumb thing and you should go fix your add-on.
But as it turns out, many add-on makers all did the same thing, so in X-Plane 11, the location datarefs point to dummy variables that continue to provide the same behavior for aircraft with no weapons. So add-ons using weapons for scratch-pads can keep doing this for a bit.
What Happened to Weapons
For X-Plane 11 we have a fairly major internal revision of the weapon system, a hybrid** of the X-Plane 10 desktop and X-Plane 10 mobile weapon systems. The internal changes were significant enough that the old datarefs do not work and would need to be completely re-engineered in a backward compatibility layer.
What We Need To Know
If your add-on uses weapon datarefs other than X, Y, Z as scratch pads, please email me a list of the other sim/weapons datarefs you do use, so we can increase the amount of scratch-pad stuff.
If your add-on uses the weapon datarefs for some actual intended purpose, please email me and let me know what you were doing. Providing dataref backward compatibility isn’t out of the question, but it’s not something we want to do unless there is a real demand for it. The old weapon datarefs were part of Sandy and me just dumping everything into datarefs, so my guess is that a lot of the data in there is of no use to anybody.
Don’t Abuse Datarefs
I’ve said this before and I’ll say it again: do not abuse datarefs. If something appears to be unused, that does not mean “dump random data into it.” Use a dataref for its intended purpose only, and write values that make sense given its docs. If the docs don’t say what the dataref is for, back away slowly.
What if you need more dataref storage? For X-Plane 11, my recommendation is XLua.*** X-Lua is an extremely simple, portable, light-weight plugin to run Lua scripts that lets you create new datarefs and commands, and interact with the sim. Our art team uses it to do animation behaviors in the cockpit that are too weird to put into X-Plane itself. Once X-Plane 11 is out we’ll make an official binary distribution of XLua in case people want to use it.
* This isn’t a perfect example because we also had to do this work ourselves because 64-bit LuaJIT support can only be implemented in the host app, not plugins.
** This hybrid still has some rough edges from fusing the two systems together, and is not always described charitably within the company. You can think of it as one of those alien-human hybrids from X-Files.
*** Why XLua and not Gizmo or SASL? If you were using Gizmo or SASL you wouldn’t be saying “but I need more dataref storage”, you would have already made your own. So XLua addresses the authors who don’t need/want these heavier, more complex plugins that are aimed at larger scale add-ons.
We posted the system requirements for X-Plane 11 today. Here’re a few notes on the requirements for X-Plane 11.
64-Bit Only
This should be a surprise to no one: X-Plane 11 will be 64-bit only. Add-ons have already gone 64-bit only, over 90% of our user base is already running 64-bit operating systems, and we need 64-bit to be able to utilize the RAM that we need and everyone already has.
Windows: No More XP or Vista
For Windows, we are dropping XP and Vista support and requiring Windows 7 or newer. XP has been end-of-lifed by Microsoft for a while and is therefore not safe to use (due to a lack of security updates).
OS X: Yosemite and Newer
For OS X, we are dropping a number of OS X versions and requiring Yosemite (10.10) or higher. Apple has increased the tempo for OS releases in the last few years, and they don’t provide new drivers to old operating systems, so we are pre-emptively cutting down the set of supported operating systems to cut down the number of different 3-d drivers we have to test.
Linux: Proprietary Drivers Required
On Linux, we will continue to support only the proprietary 3-d drivers from AMD and NVidia; these drivers use the same OpenGL stack, so they let us support Linux without the cost of additional 3-d driver testing. We don’t officially support the Mesa/Gallium stack for Intel GPUs, but X-Plane Linux users have done a bunch of work to make this unofficially work, and we do our best to not undo their work.
Graphics Cards
We’re setting the minimum graphics card at the AMD HD 5000-series line for the red team and the GeForce 400-series for the green team. This ensures that we only support cards with reasonably current drivers, DX11-class capabilities, etc. For Intel, you’ll need at least an HD2000 series or newer; figuring out your Intel motherboard graphics is really tricky because their numbering scheme is crazy, but if you don’t have at least some kind of “HD” graphics, you definitely can’t run.
We recommend a newer graphics card, e.g. at least from the DX12 or newer generations. When it comes to graphics, basically more is more, so whether you need a Titan or Fury or similarly monstrous card depends on things like how big your monitor is.
CPU
CPU requirements are the messiest part of the spec and the source of most of our internal discussion. Simply put, there really aren’t good ways for us to simply state what CPU is going to work well or not with X-Plane. X-Plane itself has a huge range of CPU uses based on configuration, and CPUs have a huge range of actual performance that can be hard to predict from some of the simple headline numbers. Clock rate is absolutely not indicative of performance, nor is core count.
A recommended system is pretty simple: we recommend the Intel i5 6600K, which is the current top-speed gamer targeted i5. You can go lower or older and lose significant performance, or you can go faster and really start to pay a lot more money. If you want to invest in 8 Xeon cores, it may help… but we aren’t going to go tell you to spend that kind of money for a little more performance.
Practical Recommendations
Here are my practical recommendations for X-Plane 11:
- If your machine is just barely getting by with X-Plane 10 at the lowest settings, and those hardware requirements seem high because your machine was built several years ago, you may need to upgrade for X-Plane 11. In this case, it could be a good time to upgrade OS and multiple components.
- If your machine runs X-Plane 10 well, it will almost certainly run X-Plane 11 in some form, with the exception of the very oldest graphics cards. (If you have one of those, I would say your definition for ‘run well’ is a lot lower than mine is.)
- If you need to purchase new hardware, I strongly recommend running X-Plane 11 on your existing hardware first and examining performance of the demo (when available) to see where you’ll need to upgrade.
Real hardware performance is hugely varied by what you are doing and your particular system components, so trying the demo will tell you more than we can hope to figure out from specs.
X-Plane 10.51 has now been officially released; you’ll be prompted to auto-update. 10.51 fixes a few bugs in 10.50 and updates the global airports.
There is one bug we are still tracking: a number of professional customers have reported worse external-visual tracking with 10.51 than with 10.45. If you see this on your setup, please file a bug; we are working with these pro customers individually to test possible fixes.
(We can’t easily reproduce this bug because the performance characteristics of multi-machine setups are very particular to the specific machines, rendering settings, and networking hardware involved.)
Posted in News
by
Ben Supnik |
WED 1.5.1 is now out – this is a quick bug fix patch to 1.5. Besides fixing a bug where the downloadable preview packs from the gateway were missing static aircraft info, there’s a nice usability enhancement:
When a polygon fails validation due to a zero length side (two adjacent nodes on top of each other) the validation command selects the second vertex in each pair. Just hit the delete key once and your polygon is fixed! (Thanks to Michael for submitting the patch to this.)
We already have some working WED code to support X-Plane 11’s dynamic ground vehicles; Ted is working on it and we’ll get it moved to the public servers at some point. I am aiming to have WED in public beta condition by the time X-Plane 11 ships.
Austin and I are back from Cosford (thanks to Scott, Richard and the JustFlight team for hosting us!) , and the cat is out of the bag: X-Plane 11 is coming this year. Austin and I gave a presentation on some of what’s coming in v11, and it’s up on Youtube.
https://www.youtube.com/watch?v=pPyydyyu3zE
Because of the size of the auditorium, we actually gave this talk twice; I believe this video was taken from the first talk, but there may be video of the second floating around. The content is not quite the same; in particular the Q & A went in separate directions.
Over the next week or two I will post some useful information about v11 for third party developers.
In the meantime: please do not email me asking for early beta access. We will be doing a beta program, and like X-Plane 10, we will try to get third party developers some early access to X-Plane 11 so that we can collect compatibility information and they can get oriented on how to update their aircraft.
But for now, please wait. Please do not post comments asking to be in the beta program. Right now my in-box is flooded and we’re not quite ready to triage these requests.
Posted in News
by
Ben Supnik |
WorldEditor 1.5 release candidate three is now the official WED build; you will need to use it to upload to the gateway, and you can now upload WED 1.5 projects to the gateway.
WorldEditor 1.5 supports the new static parking and ATC features of X-Plane 10.50, and adds a visual taxi sign editor. WED can be downloaded here and has full release notes with the app.
You can get X-Plane 10.51r1 by running the installer, picking update, and checking “get betas”. Here’s a full bug fix list.
10.51 brings in a bunch of airports from the gateway that were built with WED 1.4.1 during the 10.50 beta process. It also has a few key fixes:
- If your aircraft’s airfoils have goofy values, it’s an error but you can still fly the plane.
- External visuals should be smoother when rolling the plane.
- Various window positioning and mouse clicking bugs are fixed.
- No more “colocated points” errors for ATC routes ending at ramps.
- Turbulence reduced when using real weather.
WorldEditor 1.5 release candidate three is posted. Hopefully this one is a keeper. The show-stopping bug was: the error margin for near-but-not-connected taxi routes was too large, causing it to incorrectly flag parallel parking spots for aircraft. Two other minor bug fixes went in too.
If you find a bug in the release candidate, please report one ASAP on the X-Plane Scenery Gateway bug reporter.
I just posted WED 1.5 release candidate 2. If you grabbed RC1 and hit the crash on export on Windows, please grab this ASAP and file a bug if your crash is not fixed. Of the four or five crash reports I received, two contained reproduction materials and both were the same bug – a crash when exporting a ramp position with no airliners, Windows only. This is now fixed.
WorldEditor 1.5 release candidate 1 just went up today. Please try it soon; we’re going to make this the official version for uploading to the gateway if no one finds any problems. This build fixes the last known validation bugs and has a bunch of improvements in the validation text messages; Jennifer, Ted and Julian did a complete review of the error messages (there are over 75!).
X-Plane 10.51 release candidate 1 should go up Monday or Tuesday; it has new airports and a few hot fixes for problems we found after shipping.
If you are the author of payware that won’t open due to an airfoil self-check failure, this is just a warning in 10.51, so your users won’t be frozen out.
But you should also fix the problem, as the self check fails only if you enter physically impossible values for the airfoil.
Update: a number of users have reported crashes on export in the release candidate. If you see a WED crash on export or validate:
- Please include a link to the scenery pack causing the crash.
- If you are on Windows and can provide a link to a minidump, that would be really useful. (You’ll have to do a link – even zipped, the minidump files are huge.)
- If you see a crash on a Mac, include the full text of the Apple crash report.
- If your pack requires tons of libraries, please indicate what libraries are needed.
Update 2: WED 1.5 release candidate 2 is out and fixes this crash, which is a crash on validate of a ramp start with no airlines, Windows only.
