ABOUT, PROJECTS BLOG, NEWS COMMUNITY TERMS of Use BARON 58

<<<      Custom planes and your "hardware" cockpit

Custom planes problems

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.


That is what we are trying to do with SimVimCockpit - to have the configurator database filled with unified names for all controls, independant of plane type and especially model manufacturer.


Why are custom datarefs used so excessively nowadays?

In short - "because we can" and because of virtual cockpit fancy 3D graphics. 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 some plane developers use custom commands 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 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...)

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

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


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.

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.




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 airplane when building you cockpits - to have realistic behaviour (and maybe detailed external view sometimes, especially if you make left/right side view screens).

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 to add all laminar and some other planes in the SimVim database as defaults, so you can simply use any parameter names from the configurator as usual.

Here is the link to the reference diagrams, where you can see what parameters have been mapped 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