At some point, Nasals' primary/only mechanisms to deal with any FlightGear code were the property tree and so called fgcommands:
http://wiki.flightgear.org/Property_treehttp://wiki.flightgear.org/BindingsIn addition, Nasal comes with its own standard library of functions implemented in C, including an API to expose existing C/C++ functions to Nasal (and vice versa)
The corresponding mechanism is documented at:
http://wiki.flightgear.org/Howto:Extend_NasalMeanwhile, this mechanism can be considered to be a legacy thing, because it's been wrapped by a high-level implementation, called "cppbind", this goes beyond just exposing procedural APIs in the sense that also fully object-oriented APIs are exposed (think classes and objects):
http://wiki.flightgear.org/Nasal/CppBindThe CppBind framework is primarily, and extensively, used by the Canvas system and any code related to it, including some non Canvas code written by the same developer (TheTom).
What you're hinting at, and what sounds like "magic" to some (admittedly there IS a language barrier) could be best summed up by pointing you to SWIG.
Note that SWIG is supported by Python (and many other scripting languages, including Perl and Lua), and that an outdated adaption for Nasal does exist.
Nasal the language, and its integration are documented in the repositories - e.g. the original 2004 document still being here:
https://sourceforge.net/p/flightgear/fl ... Nasal.htmlThe most recent docs created by Andy are kept here:
https://github.com/andyross/nasal/tree/master/wwwIn addition, $FG_ROOT/Docs contains a rather extensive technical overview about some of Nasal's internals, written by Philosopher and myself:
https://sourceforge.net/p/flightgear/fg ... format=rawRegarding SWIG (it not being magic), in the light of multicore hardware and distributed setups, the real power lies elsewhere, i.e. in some form of IPC like HLA (or even just Emesary)
Besides, as a matter of fact, even predating the whole IPC idea, we did have full APIs modeled on top of the property using merely the notion of listeners, which is very much superior to low-level scripting bindings (even in the SWIG sense), because those are inevitably language specific, and add to our workload - whereas subsystems like the AI system (or even Canvas) are fully scriptable without any of the underlying C++ having to be aware of it, just by abusing the SGPropertyChangeListener API to model a complete API on top of the property tree, where you can tell C++ code to do something for you just by creating/updating properties in a well-defined structure using certain naming/typing conventions and a certain hierarchy - for instance, that is how the bombable system gets away with using Nasal scripting to exploit the AI system, despite it not containing a single line of dogfighting related code - and despite it not having been significantly maintained/updated in years.
Basically, imagine a listener-based API modeled on top of the proeprty tree to be like a remote control that doesn't bother who presses the corresponding buttons or for what reason - in fact, it usually doesn't know anything about its "user" other than that there is a mailbox with a few envelopes containing instructions that it tries to parse, and if they make sense, it changes some internal state and so on
One of the key lessons to be learnt from this is that FlightGear could/would be in excellent shape, regardless of Nasal if it had more subsystems using primarily/solely the property tree to expose internal APIs for arbitrary purposes - because at that point, the concrete use-case no longer matters, which is why Durk's original AI code can be used via C++, Nasal - but also via httpd (Phi) or telnet (props).
Equally, you can render/create and update a Canvas texture without necessarily having to use any Nasal code - simply by directly modifying the property tree.
Which is to say that _any_ existing subsystem using this approach can automatically be used from another scripting language that exposes the underlying API, aka the FlightGear property tree - which I understand, bugman's FGPythonSys is already doing (?)
In other words, if a subsystem can be used/controlled via the property tree (browser) and/or telnet, you can also access it from any scripting language that has property tree bindings.