From wiki.flightgear.org

This article is a stub. You can help the wiki by expanding it..

This is meant to become a summarized list of all feature requests/suggestions related to the FlightGear Nasal scripting system, it is largely based on Feature Requests / Proposals / Ideas (where all related items were deleted) and may not be up to date with the most recent developments in CVS, your help in updating and maintaining this list is appreciated!

For a detailed introduction to writing custom extension functions in order to extend the Nasal interpreter in FlightGear, please see Howto:Extending Nasal.

Nasal Core

• Add a Nasal function that ensures that other scripts have loaded already (i.e. something like include, require, import:dependency resolution) to avoid having to use properties or even timers for this purpose (see [1] [2] [3] [4] and [5]) Another thing to keep in mind is permission handling (i.e. checking for read permissions when opening Nasal modules in order to avoid issues like these [6]).

http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26385.html

FlightGear Integration

• add possibility to re-init the nasal interpreter, so that it reloads any modified script files, so that developers can test their modified scripts more easily, without having to exit/restart FG
• Add a callback to play sound files without relying on the current XML based sound system. agreed to be useful by several core developers: [7] [8]
• fully expose the navigational database API to Nasal scripts, so that scripts can query the navdb and work with navigational data (navaids, fixes, airports etc)
• given the fact that an increasing number of more complex components in FlightGear is being implemented using the Nasal scripting subsystem (which happens also to be the first choice for non-programmers for obvious reasons), and due to the possible challenges (when implementing low-level systems) resulting from the way the interpreter is currently integrated/run in FlightGear (i.e. sequentially, framerate-limited: difficult to provide reliable low-latency timing/update rates), it might be worth to consider providing an additional, alternative/separate interpreter context for FlightGear-related efforts that do not necessarily have to be run directly within the native interpreter context (because they may not need to access internals beyond what the PropertyTree already provides), that way it should become possible to run more sophisticated "scripts" in a semi-standalone fashion while also providing decent and reliable update intervals. This could for example be achieved, by either running one interpreter in a different thread (that would only communicate with the main thread/FG core using the property tree as IPC mechanism (i.e. deemed to be only a provider/consumer of PropertTree nodes) or possibly even by using a separate process for such a different interpreter instance, where the communications could likewise be handled using the PropertyTree exclusively, in that case however making use of the networking facilities already provided by FlightGear, to enable getting/setting properties across process boundaries. Eventually, such a facility might support additional efforts, where users/non-programmers want to implement time-critical components in FG, using FG means but to whom implementing such projects in C/C++ may not be a viable option, or even a showstopper-because they may lack the required familiarity with the core source code, C/C++ programming experience or both. In such a scenario, even a "stripped down" interpreter, be it run separately as a thread or process, would still be a much more feasible option than going the C/C++ route for most users. (Also see Modularizing, parallelizing and distributing FlightGear
• "Another thing that would work well (to improve runtime performance) is to proxy all nasal script invocations to a Nasal helper thread - again this assumes scripts basically interact with the sim via properties (which they already do) and that any system functions they call are thread safe - not very hard to do. As more and more functions get moved to nasal, this might become a very easy way to balance the CPU usage."