Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Howto:Using Driver Hashes in Nasal

From FlightGear wiki
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.


Demonstrate how to put context specific functionality (APIs) into so called driver hashes to easily switch between different front-ends or back-ends respectively. The same mechanism can be used to easily provide support for backwards compatibility, by putting version specific implementation details into a corresponding driver hash (example to be added).

What is a driver hash

It's a conventional Nasal hash (imagine it like a namespace), which typically contains callbacks, i.e. functions. Driver hashes are usually nested in an outer hash, where a key can be used to look up the concrete implementation.

This is an empty hash named myDriverHash:

var myDriverHash = {

To populate the hash, we need to add keys to it - in this case, this can be best accomplisheed by adding strings to it, with a color specifying the value:

var myDriverHash = {

"key1": "value"


Different key/value pairs are separated using a comma:

var myDriverHash = {

"key1": "some value",
"key2": "another value",


Now, instead of adding key/value pairs directly to the hash, we can also add a nested hash:

var myDriverHash = {

"hash1": {},
"hash2": {},


Now, myDriverHash contains two keys, each pointing to another hash - which is empty for now, these can be accessed using the key to look up the field in the namespace:

var myDriverHash = {

"hash1": { value:1},
"hash2": { value:2},


print( myDriverHash["hash1"] );
print( myDriverHash["hash2"] );

Instead of using arbitrary names for the keys, we can also use names that are self-explanatory to tell the reader what the hash is trying to hide/encapsulate, for example:

var myDriverHash = {

"yasim": { some_property:1},
"jsbsim": { some_property:2},



We have an increasing number of similar features that are sometimes even mutually incompatible, often this applies to features for which different alternatives/approaches exist, for example:

  • JSBSim vs. YASim
  • Basic Weather vs. Advanced Weather
  • Rembrandt vs. ALS
  • Phi vs. PUI
  • osgEarth vs. the standard scenery engine
  • navdb vs. navigraph data use
  • online weather service vs. the local weather system
  • main aircraft vs. AI/MP aircraft
  • geodinfo() vs. the hard-coded terrain presampler


However, Nasal scripts may need to work with all of these components, regardless of the concrete implementation - this is where we commonly see spaghetti code using lots of nested if/elseif constructs to deal with the differences among these implementations.

But this is exactly where it pays off to simply encapsulate implementation specific details into a hash with callbacks that can be easily switched.

Use Cases

This kind of functionality could be used to support custom styling/theming for avionics that have otherwise overlapping/identical features, but mainly differ in terms of appearance/looks.


Let's imagine, we have a piece of Nasal code that needs to work with different FDMs (or autopilot/route manager configurations).

The YASim property may be named