Nasal scripting language

From FlightGear wiki
(Redirected from Nasal)
Jump to: navigation, search


FlightGear offers a very powerful functional scripting language called Nasal, which supports reading and writing of internal FlightGear properties, accessing internal data via extension functions, creating GUI dialogs and much more. Please see the right navigation bar to get additional information.

# to be saved in $FG_ROOT/Nasal/hello.nas
  print( "Hello World!" );

Vim-nasal-syntax-highlighting.png


Recent Efforts

Name Description Status Notes
canvas-hackers Canvas related efforts active get in touch if you'd like to get involved Nasal & Canvas knowledge required, and Git basics
flightgear-autogen scenery/autogen related efforts active get in touch if you'd like to get involved C++ & Nasal knowledge required, and Git basics


Tutorials & Missions

  • set up a gitorious repo with shared access for all contributors [1] 30}% completed
  • helicopter missions 70}% completed (Marius_A [2])
  • Walk View support 80}% completed (Marius_A [3])
  • AI scenarios support 10}% completed (Marius_A [4])
  • NPC support 70}% completed (DFaber [5])
  • self-steering AI vehicles 50}% completed (DFaber [6])
  • extend the framework to support reloading/restarting tutorials at runtime Priority 50}% completed (Marius_A [7])
  • support dynamic mission objectives instead of just static positions Not done Not done [8] [9]
  • investigate supporting Nasal blocks for having multiple instances of an AI/model i.e. for vehicle/NPC control [10] Not done Not done
  • investigate supporting optional Canvas areas for showing mission objectives via MapStructure (Hooray & ludomotico[11]) 30}% completed [12]
  • procedurally-created Canvas GUI dialogs, e.g. for interaction with NPCs and mission briefings Not done Not done
  • allowing startup time and environmental settings (weather/METAR string) to be stored as part of the tutorial (e.g. for CAT3 approaches at night time) Not done Not done


Canvas MapStructure

Type Work item Progress
Layer FIX 80}% completed
LOD support LOD handling (i.e. range awareness) needs to be finalized and applied to all existing symbol files 60}% completed
New Layer Navaids (meta layer for VOR, DME, NDB) Done Done
Traffic Layer TFC 90}% completed
New Layer DATA (needs label decluttering[13]) Not done Not done
New Layer HISTORY Done Done
New Layer cached GRID (lat/lon) [14] 20}% completed
New Layer tiled maps/SAT (online[15], [16]) 10}% completed
Controller zoom Done Done
New Controller interactive/editing [17] 10}% completed
New Controller magnetic (see navdisplay.mfd & unify!) Not done Not done
New Controller center on acft (see navdisplay.mfd & unify!) Not done Not done
New Controller acft hdg up (see navdisplay.mfd & unify!) Not done Not done
New Controller panning/translating (see $FG_ROOT/canvas/map/generic-canvas-dialog.xml) Not done Not done


Canvas NavDisplay

  • allow layers to be configured per aircraft issue 1388
  • use switches hash to procedurally create a GUI dialog with buttons for each toggle_action (TFC,CTR,WXR etc) Not done Not done
  • make sure that the frameworks with properly with time-warp, sim-rate speed-up and replay Not done Not done
  • remove (old) disabled layers Done Done
  • use MapStructure options hash to encode things like nav/comm stuff (anything referencing /instrumentation/) Not done Not done
  • make the timer update interval configurable via constructor Not done Not done
  • consider adding hooks to generalize those huge conditionals in update() some more Not done Not done
  • use foreach() to hide()/show() or setVisible() groups of symbols Not done Not done
  • make this more aircraft agnostic by getting rid of 747/Boeing specific assumptions Not done Not done
  • unify switch/case|default handling (again, huge conditionals in there) Not done Not done
  • on_update() helper should probably support global listeners and timers, too - i.e. via a hash spec ? Not done Not done
  • the whole symbol lookup needs to cleaned up (getElementById etc) Not done Not done
  • introduce a common "compute" field in the update/predicate hash and make its results available to is_true/false etc Not done Not done
  • use io.include to include boeing specific stuffDone Done (see navdisplay.styles for now)
  • NDSourceDriver should be generalized and combined with MapStructure's aircraftpos.controller Not done Not done
  • the radio/autopilot listeners need to be set up in the lcontroller file, they're just empty stubs for now Not done Not done
  • there are 3 foreach loops in newMFD() setting up symbols currently-we only need ONE: loop 2+3 should be removed and use the loop #1 method Not done Not done
  • clean up the ctor and generalize the newMFD() method Not done Not done
  • move stuff out of the update() method into the aircraft-specific configuration hash Not done Not done
  • generalize/extend on_update() method to support other (global) properties and/or listeners/timers to run predicates Not done Not done
  • identify opportunities for improving the framework Not done Not done
  • support multiple routes (WPT/RTE), as per the Nasal Flightplan API (Hooray) Not done Not done
  • move the config hash out of the navdisplay.mfd file and use io.include instead Not done Not done
  • document SVG symbols currently assumed to be available in the ctor Not done Not done
  • consider using some of the SGCondition/StateMachine stuff in SG Not done Not done


References