Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G


Jump to: navigation, search

Howto:Extend Nasal

2,362 bytes added, 17:19, 27 June 2012
Wrapping Classes as Nasal Objects (ghosts)
= Wrapping Classes as Nasal Objects (ghosts) =
'''To be written by Hooray & Zakalawe. For the time being, it's a good idea to take a look at the FGPositioned wrappers for the navdb to see how this is done in Nasal, see [https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/NasalPositioned.cxx $FG_SRC/Scripting/NasalPositioned.cxx].''
Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29032.html<pre>One problem is that functions like airportinfo() already do *way* too much, and making it do more will not help. We need to stop exposing *functions* to Nasal, and start exposing *objects*, with properties.  Notably, amongst the airportinfo() structure is a runways hash, which contains data that depends on the Airport Scenery data - this means it can trigger the lazy loading of that data, and hence require a disk access. I've noticed the same problem with the map dialog. Most people accessing airportinfo() only want one or two pieces of info, but we compute the whole lot each time. I realise that making proper Nasal ghosts for FGPositioned, FGNavRecord, FGRunway, FGAirport is more work, but it would be the right path to putting the Nasal API on parity with the C++ one, and would enable a huge amount of FMS/digital charting/ATC functions to be built in Nasal. If that sounds impossible, then I'd strongly advocate creating separate special purpose-functions in the short term, that do *one* thing, and be more easily subsumed if/when we properly expose the C++ types to Nasal. Yes I'd like to second the idea of returning objects (with attributesand methods for doing interesting things), I'm guessing we don't need toabstract it too far from what is provided underneath. However I really like the idea of getting back an array of airportswithin some radius of a centre lat/lon pair, and/or within a boundingbox (2 or 4 lat/lon pairs), and if the same could be done with othernavigation elements in nav.dat it would be most excellent! Well, this is exactly what all the query methods on FGPositioned do - the problem is, they return FGPositioned subclasses, which aren't much use to Nasal right now! Exposing the FGPositioned query interfaces (and the related, specialised versions on FGAirport, FGNavRecord, etc) would be quite quick, but it's pointless until the results are useful / interesting to Nasal.. One interim step - it would be possible to wrap the query methods, but write code (exactly as airportinfo() is currently implemented!) to map the FGPositioned subclasses to a 'static' naHash. That's easier than creating proper naGhosts, and could have a forwards-compatible APi when the ghosts are written. </pre> For the time being, it's a good idea to take a look at the FGPositioned wrappers for the navdb to see how this is done in Nasal, see [https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/NasalPositioned.cxx $FG_SRC/Scripting/NasalPositioned.cxx]. There's a plan to eventually unify all those helpers and provide them as part of the FGNasalSys class, so that they automatically become available to all users of the Nasal subsystem.
= Passing Pointers to Nasal scripts =

Navigation menu