20,741
edits
Howto:Add new fgcommands to FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Howto:Add new fgcommands to FlightGear (view source)
Revision as of 12:52, 10 February 2012
, 10 February 2012→Background
m (→Background) |
|||
| Line 1: | Line 1: | ||
= Background = | = Background = | ||
So called "fgcommands" are FlightGear extension functions which can be invoked in a number of different ways, such as embedded in various XML files (in the form of "action" bindings), but also via Nasal scripts using the fgcommand() extension function. In addition, it is also possible to invoke fgcommands using the telnet/props interface, so that a simple form of "Remote Procedure Calling" can be implemented, i.e. triggering code via telnet to be run inside the FlightGear process. | So called "fgcommands" are FlightGear extension functions which can be invoked in a number of different ways, such as embedded in various XML files (in the form of "action" bindings), but also via Nasal scripts using the fgcommand() extension function. In addition, it is also possible to invoke fgcommands using the telnet/props interface, so that a simple form of "Remote Procedure Calling" can be implemented, i.e. triggering code via telnet to be run inside the FlightGear process. | ||
Compared to Nasal extension functions, the nice thing about "fgcommands" is that they are not just available to Nasal scripts, but that they can also be used by lots of other FlightGear systems directly without resorting to scripts and registering listeners, such as in the form of GUI bindings, mouse/keyboard handlers and so on. | |||
Of course, there are some disadvantages too: fgcommands always need their arguments wrapped in a property tree structure. This is because they don't have any concept of Nasal and its internal data structures. | |||
So there is a certain marshaling/conversion overhead involved here. While this is certainly negligible for simple commands that are run rarely, this overhead may add up once a certain fgcommand gets called repeatedly at a high rate. In such cases it may be more efficient to let the command work with argument lists (vectors) rather than ust a single argument, so that multiple tasks can be completed by a single invocation. | |||
An overview of fgcommands currently available and supported is provided in [http://gitorious.org/fg/fgdata/blobs/master/Docs/README.commands $FG_ROOT/Docs/README.commands]. | An overview of fgcommands currently available and supported is provided in [http://gitorious.org/fg/fgdata/blobs/master/Docs/README.commands $FG_ROOT/Docs/README.commands]. | ||
| Line 46: | Line 52: | ||
fgcommand("null"); | fgcommand("null"); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Regarding the syntax of the fgcommand() function: the first parameter is the name of the command that you'd like to run, the second parameter points to an optional property node that contains all the required parameters, that are separately set up. | |||
= Argument processing = | = Argument processing = | ||