In short: 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. 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.
When you are going to build your home cockpit, do not take any virtual plane as a base for your panel! If you want to build Baron 58, for example, you need to get all information about the real B58 plane and build your cockpit based on the real panel, not some virtual plane cockpit!
After you build your cockpit, you can choose any B58 model to fly on, either free or commercial, or even create a great flight model by yourself.
Of course, developers can use additional functions in their plane models to simulate some of the aircraft functionality that is not supported by X-Plane. And, this requires some "custom" datarefs for such functions. But often custom datarefs are used by plane developers regardless of whether they are needed or not, even if 90% of their panel functions can be controlled using existing standard datarefs!
Actually, most of the custom datarefs and commands included in the plane model are 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.
For example, 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 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 two) 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?
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!
Please let them all be "toggle" switches, don't make them as a slow-motion scene in a cartoon movie!
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.
It's incredibly wrong to do this - 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).
Cockpit panels in many modern "custom-made" planes look very good, but act like a cartoon movie.
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 worst cases we've seen so far is one aircraft model having a switch under a safety cover. Not only was the dataref this switch operated blocked from outside writing and could only be operated by the switch finishing its animation, but the program blocked the switch operation while the safety cover in the virtual cockpit was down.
What's worse, the switch could only be operated once the safety cover fully finished its animation moving up.In short, the only way to use the intended function from hardware cockpit was:
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.
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.