I’ve blogged in the past about the difference between key frames to animate changes to a dataref and key frames to animate an event. Simply put, key frames let you relate the position of your mesh to a dataref value, but they do not let you start a sequence of animations based on a change to a dataref.
In other words, you can make an aniamtion that puts the gear handle up when the gear dataref is 0 and down when the dataref is 1. If that dataref were ever 0.5 you’ d see something in the middle. (This dataref will always be 0 or 1 though.)
But you can’t use animation to make the handle slowly move from up to down over a few seconds when the dataref instantly jumps from 0 to 1. If the dataref moves instantly, so does your animation. There can be no time delay between the dataref and animation.
To get this “triggered sequence” effect, you need something else to detect the event and create a dataref that moves slowly. That something could be a plugin; X-Plane also provides a built-in mechanism: the “misc. slider”.
In an attempt to put the information somewhere useful, I have described the feature on the X-Plane wiki.
No Spare Datarefs (Usually)
In that last blog post I went on a rant about “spare” datarefs. Basically people would ask us to make some datarefs that did absolutely nothing, simply to wire parts of their panels and animations together.
And while I’m going off on a tangent about authoring and datarefs, we will not be adding any “spare” datarefs.
Well, the slider_on and slider_ratio datarefs are sort of “spare” datarefs – they’re 24 slots that have no default function.
I relented on my usual hard-line position on this (and a few other) datarefs for two reasons:
- These datarefs are tied to a real (albeit really simple) bit of simulation code – that is, the code that moves the sliders over time. We had to add these datarefs to make the slider mechanism accessible.
- Because sliders are an airplane feature, there is a logical scope: the person who writes the airplane gets to decide what the sliders do, and no one else gets to muck with them. (Since the cycle time is an aircraft file attribute, no one else could sanely hope to utilize them.)
I still maintain my original position that if you need a dataref that doesn’t exist at all, you should use a plugin to create it.
Someone in the X-Plane community can write a (really simple) open-source plugin whose sole purpose is to create trivial datarefs for aircraft use from a text configuration file, letting aircraft authors make as many datarefs as they need. (It is possible that this plugin exists and I just don’t know about it.)
Aircraft authors: to make sure that datarefs from differing add-ons do not have name conflicts, Sandy and I established a registry of plugin dataref prefixes. If you are going to add custom datarefs to your airplane, be sure to register a prefix, and only use that prefix. Do not start your datarefs with sim/XXX – that prefix is for X-Plane’s use only.
(Side note: the X-Plane SDK website has been under some kind of automated attack for the last week or so with lots of bogus user sign-ups. I haven’t had time to address this properly; if you are not registered on the SDK Wiki, I may not be able to approve new sign-ups for a few more days.)