As described here, every assigned SimVimX keywords (parameters) is "mapped" to a specific X-Plane command(s), dataref values with different options, or to SimVIm/X function programmed in the plugin (using X-Plane and SimVimX datarefs). And, if the loaded plane model is one of the default X-Plane models or a free model with no custom datarefs, all the controls and outputs you assigned will work fine right away.
The SimVimX data structure allows to have the configurator database compact, having unified names for all controls, independant of plane type and especially model developer.
What about datarefs and command in X-Plane?
In real aviation there are almost no "unique" controls that are found only in one specific aircraft, most of them are unified for all aircraft. The same control switches are represented on each plane, so we could only expect ONE set of commands for ALL planes, as was originally done in X-Plane, which can potentially have all the necessary command names for the controls found in any cockpit. The X-Plane development team can gradually add more commands / data for new functions that can be used by aircraft developers directly in their plane models.
But, most of aircraft developers create hundreds of their own "custom" commands/datarefs for every simplest function though they even have no any reason for this, because they would easily use existing X-Plane commands/datarefs instead, for most functions. As a result, if we take any 10 different virtual aircraft models of the same plane (from different developers) we will see thousands of datarefs/commands instead of tens (maybe hundreds).
Real panel control and virtual plane data
Let's see for example how a simple toggle switch assigned to SimVImX parameter for some aircraft system works with different aircraft models which can be one of the X-Plane standard, or free downloadable model or payware model.
1. Simplest and most preferred case. The aircraft developer uses only position bitmaps for the switch image, and the standard X-Plane dataref is used as refernce value for changing the switch image on the screen (0=OFF, 1=ON). Also, for toogle operation the related standard X-Plane command or two (up/dn) commands may be used.
The real switch assigned to the SimVimX parameter works as is, turning the aircraft system on or off, and the virtual switch image is also changed:
Also, the SimVimX may have a specific function programmed for this system
2. Custom, common function. X-Plane has implemented this functionality, but the virtual plane model uses its own custom commands/datarefs for it.
In this case the SimVimX/RSC parameter may need to be converted to the custom aircraft data, but no necessary.
3. Custom, special function. X-Plane has not implemented this functionality, but the virtual plane model includes it and uses its own commands/datarefs for it. In this case the SimVimX parameter should be converted to the custom aircraft data.
If the SimVimX has this functionality programmed in the plugin, the conversion can not be needed.
4. SimVimX programmed function. If X-Plane has not yet implemented this feature, and the virtual plane model does not include it either, the RSC parameter works with a function programmed in the SimVimX plugin, and this function may have different behaviour depending on the aircraft type or equipment model type.
5. A virtual plane model has no any cockpit interior, no instrument panels, no virtual switches and annunciators, and no custom scripts. As example, you can download the "barebone" King Air C90 in the Download section. In this case every assigned parameter, for any input/output will work either with standard X-Plane functions or with a function programmed in the SimVimX plugin, with external SimVimPanel program or hardware gauges:
Why are custom datarefs used so excessively in some aircraft models?
Most often because of the eye candy 3D graphics, and most of the custom datarefs and commands are created only for the purpose of animations the elements in the virtual cockpit, nothing more! Custom commands are used to control virtual switches and then custom function just sets some standard X-Plane dataref values, that could be done directly with standard commands and 90% of their panel functions can be controlled using existing X-Plane datarefs!
Of course, developers may simulate some aircraft features that X-Plane does not support. And, sure, this requires adding custom datarefs for such features, but there are very few of them.
So you have to find and use all these unnecessary custom commands in your hardware panel instead of the standard ones, just to watch how cool all these switches/knobs/levers are animated on screen.
For example, a developer wants to add some specific function for wipers to his aircraft model, that should be activated by the switch/knob "Wiper ON".
1. He creates a new custom dataref "my_super_plane/systems/MY_WIPER_Animation" that takes values between 0.00000 and 1.00000 and is linked to the animation on the 3D model, and writes the function "MY_WIPER_Animation" that gradually changes this dataref's value over time.
2.In addition, developer creates another dataref "my_super_plane/switches/MY_Animated_Wiper_Switch_Position" (for the switch animation) and a couple of custom commands for this switch, or worse - a single toggle command "my_super_plane/switches/MY_Wiper_Switch_Toggle" that activates the switch/knob animation.
Okay, but why not just use the standard commands (which are always paired) for the switch and the standard (customizable in PlaneMaker) X-Plane dataref "sim/flightmodel2/misc/wiper_angle_deg" to use its values for the animation in the model?
(OK, at least, plane developers could leave the standard dataref accessible for writing along with their custom datarefs...)
Animated controls,switches, knobs (to developers)
Why make animated toggle switch in the virtual cockpit? It is "TOGGLE"!
People don't have to even notice in real life that the switch is moving through all these positions, all these few millimeters.
No, in real life I just move my finger and the switch momentally changes its position! Who ever had any complaints about the "good old" 2-picture method of switch display? Click once - switch up, click again - switch down - that's all that's needed. The same thing (even worse!) for buttons - even two states (pushed, released) are almost excessive to display on screen.
Please let them all be "toggle" switches, don't make them as a slow-motion scene. Cockpit panels in many modern "custom-made" planes look incredible realistic (what is not needed for cockpit builders), but act like a cartoon movie:
It's not good to do all these animations - first, you have to spend much time to write the functions for all animated controls, second - you make a tons of "custom" datarefs for your plane, and the worst thing - some of you restrict the standard datarefs usage, by overwriting their values based on your animations!
Making your panel with standard controls, using standard datarefs doesn't make your work worse (is my opinion even better, as you aren't doing anything "overkill" and keeping good compatibility).
Hardware cockpit and custom datarefs
Keep in mind, the cockpit builders don't need any virtual cockpit, not 3D, not 2D. If the panel view is turned off, they won't see any animations, but they need to find out a particular aircraft model's custom commands and datarefs to make their cockpit work with it!
Unfortunately, when an aircraft developer focuses too much attention on making an animated virtual cockpit, it can create problems for people building a physical cockpit. In most cases, it involves the aircraft's scripts overwriting a value of a standard dataref, and often completely disabling it for outside writing.
Apart from forcing the cockpit builders to use custom commands in their configuration, it's quite inconvenient when the dataref changes its value, for example, only after some virtual cockpit element finishes its animation.
Let the movie end before you touch me!
One problematic case for cockpit builders is when an aircraft model has a switch under a safety cover. In some planes the custom dataref that is operated with this switch can not be changed externally until the cover animation has finished and it is fully open.
In short, the only way to use the intended function from the hardware cockpit was:
1. make the real cover as a switch which sends the custom command to open the virtual cover,
2. wait a couple of seconds, then flip the real switch that sends the command to flip the virtual switch (which also may have a 1-second animation).
This made it hard for the user who reported it to use a real switch in his cockpit. A cockpit builder just needs a real safety cover that is raised by finger and a real switch under this cover, without linking any of it to virtual cockpit animations.
That' why the SimVimX plugin includes such useful functionality as automatic opening for all virtual switch cover guards on startup and configuration reload for any custom aircraft - so they won't interfere with the functioning of real switches in your cockpit.
Now you won't need to use extra unnecessary inputs for passing your real cover guard positions to the simulator.
Toggle switch and single "toggle" command
Often, when making virtual cockpits, developers use only one command to control on-screen toggle switches with mouse clicks for both "On" and "Off" positions (single "toggle" command). That means, when you click it once the virtual switch is jumping to On position and returns back to Off position on the second click.
It's OK for virtual panel. The problem is to implement it for a real toggle switch in you cockpit, which needs two separate "On" and "Off" commands or a writable dataref available.
If the dataref that stores this switch position is "read-only" we are bound to use this "toggle" command for both positions and additionally monitor the dataref value in the plugin to synchronize the position of the real switch with the simulator switch.
This "crutch" is already implemented in SimVimX plugin, that can synchronize a switch position in your cockpit when using such single toggle command by monitoring corresponding read-only dataref in the virtual cockpit.
Multiposition switch and single "up(left)" or "down(right)" commands
The same problem (even worse) when the custom virtual panel has only a couple of command for rotary switch direction and one read-only dataref that takes the switch position number.
SimVimX correctly processes any "up/down", "left/right" types of commands used in some planes for rotary and 3-position switches (as well as single "toggle" commands for toggle switches). All you need is select appropriate parameter from the configurator table accordingly with input diagram for your plane.
