Everyone who builds or ever tried to build a home cockpit for X-Plane and wanted to fly some of the fancy "just like real" payware aircraft models, could spend most of the time figuring out what the "custom" commands and datarefs are, where to find them for this plane and how to use/adapt them to the input/output control interface.
This is not an issue when you are flying "on-screen" only, you just buy the aircraft model, copy it to X-Plane folder and fly it, not bothering about how it's all made "inside". Some of these planes are very good for flying in virtual cockpit (for example in VR glasses), but for cockpit builders they can become a real headache.
You may start to hate all those "custom" planes which have hundreds (if not thousands) of custom commands and datarefs when building the real cockpit. Customized/payware aircraft models with "highly realistic" virtual cockpit most likely will not help you build your real home cockpit, but rather prevent you from doing it quickly and without problems.
Everyone can agree that in aviation there aren't that many controls that present only in one specific aircraft model, most of them are unified. For example, "Landing Lights" control switch is present in every plane, so we need only ONE command like this for ALL planes.
But almost every payware/customized plane developer adds their own custom commands even for such a simple thing! As a result, if we take any 10 different models (from different developers) of the same plane we will see thousands of datarefs/commands instead of tens/hundreds...
This is sad... If such data/naming structure would be present in real aviation - it would be chaos and lots of disasters!
It started when X-plane team once allowed to add custom commands/datarefs. As an alternative, a simulator could simply have all the needed command names for controls that could be found in any cockpit, with new ones gradually added, and some mechanism to allow programmers to link their own functions to these commands, if they need to.
Actually, most of the custom datarefs and commands included in the plane model can be created only for the purpose of animations of various elements in the virtual cockpit, nothing more! Custom commands are used to control these virtual switches and then custom function just sets some standard X-Plane dataref values (that could be done directly with standard commands).
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...)
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).
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.
One of the problematic case for cockpit builders is when aircraft model has a switch under a safety cover. In some planes the custom dataref that is operated this switch can not be changed from outside writing untill the cover animation finishing and it is fully open.In short, the only way to use the intended function from hardware cockpit was:
That' why we have included such useful functionality to SimVimCockpit as automatic opening for all virtual switch cover guards on startup or every 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.
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 SimVimCockpit 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.
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.
SimVimCockpit 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 mapping diagram for your plane.
Note: a realistic and highly detailed 3D model (exterior view) does not affect the flight dynamics of your plane in any way! Only the 'physical' model of the airframe that has been built in PlaneMaker does! (and some of the custom scripts can improve flight behaviour).Talking about realistic flight dynamics model of the chosen aircraft, you can build it by yourself in PlaneMaker specifically for your cockpit.