But here's a question on a related subject. How do we handle declaration of Nasal code? The ability to write inline handlers is great, but limited to small functions. The ability to drop module files into the Nasal directory is great too, for globally useful code.
But sometimes you have non-trivial code that is nonetheless context-specific. The obvious example (as Melchior pointed out to me this morning) is per-aircraft scripts. We don't to have to drop a c172.nas file into the global namespace if we're flying a bo105. My answer to this issue this morning was this:
I'm thinking about a property-space configuration, where you could do something like:
<nasal> <import> <module-name>bo105</module-name>
<source-file>bo105.nas</source-file> <!-- Either a file -->
<!-- Or inline source code: -->
<script><[CDATA[ ...nasal source code... ]]></script>
</import> </nasal>
And the Nasal subsystem would then step through all the "/nasal/import" entries it found in the property tree and load the appropriate modules at initialization.
I'm still a bit fuzzy this morning, but I want to point out that the current scheme of dropping in aircrafts by extracting them into their own directory should be preserved.
The best way I can think of right now is setting property pointing to a directory in the <aircraft>-set.xml which nasal could check for the presence of .nas scripts.
e.g. <scripting-dir>Aircraft/bo105/Scripts</scripting-dir>
Erik
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
