ABOUT PROJECTBLOG COMMUNITY TERMS of Use BARON 58 SimVimPanel ArdSimX SimVimCockpit HOME

<<<      Why are custom datarefs used so excessively?

Of course, most developers of "pay-ware" aircrafts for X-Plane nowadays are using a lot of their own functions in their aircraft models. And, this can require a "custom" dataref for every such function.

But I think, this is not a good practice when some aircraft developer uses custom datarefs here and there, regardless of whether they are needed or not, even if 90% of their panel functions can be controlled using standard datarefs!

This is understandable when you create some functions in your airplane model to reproduce the work of one of the systems that is not included in the standard X-Plane functionality, or there is no acceptable standard dataref or command to use for this.

But most of custom datarefs are used only for the purpose of animation of various elements in the virtual cockpit or on the visual outside model, and even in this case you can use standard datarefs for some of such elements.


For example, your airplane has a function such as "open an umbrella to protect against rain". When a pilot activates the switch (rotary switch) "Wiper ON" the umbrella should open over your cockpit along with wipers activation. :)

So, you create the new dataref and name it "my_super_plane/systems/umbrella_on" that takes values between 0.0 and 1.0 and pass this value to the function "UmbrellaOpenNow".

Good, I understand that. But why don't simply use a standard X-Plane dataref "sim/cockpit2/switches/wiper_speed" (which value can change between 0.00 and 1.00) and pass its value to your function?

Animated controls (switches)

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.


Example

One of the worst case 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 wich sends the custom command to open 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.






© Copyright 2012-2018 - SimVim Design