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.
Thanks Ben. Interesting insight into the workings of a complicated program that delivers the dynamics and physics of flight. To the casual user like me, it’s like the magician pulling the rabbit from a hat trick.
Keep the magic coming Ben, your work is much appreciated. Looking forward to number 11.
Will X-Plane 11 have support for anti-servo trim tabs? The reason I ask is the BD-5J is suppose to have them, so I’d like to emulate them properly in my freeware aircraft. Looking forward to taking advantage of any new features I can.
For those that don’t know what a servo or anti-servo trim tab is, a description can be found on wikipedia (search for “Servo_tab”). Most planes use a servo-trim tab, but there are a few which have their trim tabs rotate in the opposite direction.
Talk to Austin about this…
XLua for sceneries?
Not in this version. Scenery plugins are always loaded and thus must take special precautions when allocating Lua memory. XLua does not do this and thus is not appropriate to embed in scenery packs.
Ben, thank you so much for open sourcing XLua!
I’m a recently (1 year) “converted” simmer and developer from “the other” sims and X-Plane always felt like a “community project” to me, from the great online documentation, to the amazing ease of extension of the product, to the incredible tooling that is available and finally to this blog that gives us insight on how things are made and why.
Just wanted to say thank you, and hope things will continue to be like this for the 11.x run 🙂
Hi, Would XPlane 11 benefit much from living on a SSD as apposed to an old HDD ?
I don’t have numbers on this. But generally it should help load time but not fps.