<<<      Custom planes and your "hardware" cockpit

Custom planes problems

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.

Why are custom datarefs used so excessively nowadays?

In short - because of virtual cockpit 3D graphics and seeming simplicity of lua scripts usage.

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...

Animated controls (switches and knobs)

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.

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 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:

1. make the real cover as 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 has 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.

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 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.

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.

Choosing aircraft model for your home cockpit.

Custom/payware planes

Some of custom aircraft models may be very nice and good looking, with detailed external view and realistic cockpit with animated controls and correctly working systems and, most importantly, may have realistic flight dynamics (or may not). But, even if you will not use the virtual panel view you still need to have the list of special "custom" commands and datarefs and have to use them instead of standard (if the custom model doesn't allow to use them).

Real plane behaviour?

Flight dynamics of such airplanes can be usually better then "standard" or freeware, but not always as good as it can be. Some of the good freeware planes may have very realistic flight dynamics and this is all you need for the aircraft when building you cockpits is to have realistic behaviour (and maybe detailed external view sometimes, especially if you make left/right side view screens), and, sometimes, special programmed behaviour of some aircraft systems.

If you are building a real panel/cockpit, using external software for instruments (or making hardware gauges) you don't need the detailed and animated virtual 3D panel views, or even 2D panel. The "good-looking" plane and detailed and animated 3D panel of such aircraft could be very demanding to computer resources and can reduce your frame rate drastically.

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.

Using standard or other freeware models

There are many freeware planes for X-Plane, and you can find some suitable for you, with appropriate (more or less realistic) flight dynamics.

Then you can remove the 2D/3D Panels (all instruments, textures, some .obj files) because all of this is not needed if you build a physical cockpit with an instrument panel. Or, you can use the "Forwards with Nothing" view during flight. (Optionally you can remove the panel from forward view but leave the side views).

If you're not satisfied with its flight behaviour you can improve it, and this is not so hard to do, having all the necessary characteristics of the real aircraft on hand, of course.

You can choose an appropriate free aircraft model or one of those included in X-Plane and correct the characteristics and flight dynamics of this plane in PlaneMaker if you think you need to improve them. Find any available technical data, dimensions and manuals for your chosen aircraft and use these to edit the data in PlaneMaker or even make your own model.

Create dynamic models of your aircraft yourself

First, you need to make the "physical" model in PlaneMaker from scratch or take any simple, free airplane and re-make it's flight behaviour to be much more real.

Note: you don't need any additional 3D software to make aircraft with realistic aerodynamic characteristics.

To get a more-or-less realistic aerodynamics model the 'physical' airframe should represent the actual aircraft's outer structure, including wings and all bodies which interact with the air. For this you need to draw the fuselage and other bodies cross-sections, assign all sizes, surface areas and airfoils, wheel sizes and positions.

NOTE: this is not a visual 3D model! This is more an aerodynamic model, although you can make it good looking enough with appropriate textures.

Then you need to enter all physical characteristics, such as engines type and power, fuel tanks, weights, instrument limits, etc.

There are plenty of such parameters in PlaneMaker, and the more real characteristics you will add to your model the more authentic aircraft you will get.

Having done this you will get a ready to fly aircraft, that will have flight dynamics as close to real as much of the parameters of this airplane you would adjust correctly in PlaneMaker.

If you want to have some "good-looking" outside airplane model, this can be done separately by creating a 3D model of your plane. Again, this is not necessary, only needed if you want to create screenshots or videos of your flights, or need to have detailed parts of the airplane visible from the cockpit (e.g. for the left or right side view).

Plane Maker Manual

You can read the Plane Maker Manual on the X-Plane developer website.

Custom planes adapted for SimVim

We started adding all Laminar and some other planes into SimVim database as defaults, so you can simply use any parameter names from the configurator as usual.

Here is the link to the reference tables, where you can see what parameters have been mapped already to default SimVim names, that can be assigned in the configurator once and used with different models of the same plane.

© Copyright 2012-2018 - SimVim Design