|
|
Line 303: |
Line 303: |
| Also, the implementation of the SGPropertyNode bindings in [https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/nasal-props.cxx nasal-props.cxx] contains additional examples. | | Also, the implementation of the SGPropertyNode bindings in [https://gitorious.org/fg/flightgear/blobs/next/src/Scripting/nasal-props.cxx nasal-props.cxx] contains additional examples. |
| --> | | --> |
| == Background ==
| |
| Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17546.html
| |
| <pre>
| |
| Absolutely agreed that making as much data as possible
| |
| available is valuable - as you say, I'm always amazed by the neat
| |
| things people do in nasal scripts. [...]
| |
| I'm still thinking on different ways to make the core datasets a
| |
| bit more 'lazy'.
| |
| </pre>
| |
|
| |
| 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.
| |
| </pre>
| |
|
| |
| Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29034.html
| |
| <pre>
| |
| Yes I'd like to second the idea of returning objects (with attributes
| |
| and methods for doing interesting things), I'm guessing we don't need to
| |
| abstract it too far from what is provided underneath.
| |
|
| |
| However I really like the idea of getting back an array of airports
| |
| within some radius of a centre lat/lon pair, and/or within a bounding
| |
| box (2 or 4 lat/lon pairs), and if the same could be done with other
| |
| navigation elements in nav.dat it would be most excellent!
| |
| </pre>
| |
|
| |
| Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29035.html
| |
| <pre>
| |
| 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>
| |
|
| |
| Quoting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37134.html
| |
| <pre>
| |
| I'm overhauling how we expose FMS related data to Nasal, to hopefully make
| |
| FMS/CDU construction in Nasal easier, but also re-using the C++ code we already
| |
| have, since many systems tie into the data.
| |
|
| |
| Along the way, I'm learning a lot about the easiest way to expose C++ data to
| |
| Nasal, and I'm also trying to reduce code duplication. So where we have an
| |
| fg-command for an operation, I'll try to wrap the command in a nice Nasal
| |
| syntax. (With some exceptions).
| |
|
| |
| As part of this, there's various features that I'd like to clean up, but I need
| |
| to be careful about compatibility. I'll list them below, but in general the
| |
| question is how conservative or aggressive I can be in changing this stuff now,
| |
| given it's 50 days until freeze - and more than 100 until release.
| |
|
| |
| The things I'd propose to remove / change / break:
| |
|
| |
| 1)
| |
| on navinfo() results, I want to remove the 'distance' and 'bearing'
| |
| values, since these depend on the query position, and can be computed easily
| |
| *if necessary* by the new courseAndDistance method. (Which works for any
| |
| waypoint / navaid / airport / geo.Coord / etc)
| |
|
| |
| [as far as I can tell, nothing in fgdata uses this feature anyway]
| |
|
| |
| 2)
| |
| on airportinfo() results, I'd like to make the runways hash be a
| |
| function, instead of a child hash. This will mean it can be generated lazily,
| |
| and since airports have many runways, and we have quite a lot of data in the
| |
| runways hash, it would save a ton of hash-building.
| |
|
| |
| In practice the only change to code would be calling apt.runways()
| |
| instead of apt.runways, but that will still break aircraft that use the old
| |
| syntax...
| |
|
| |
| [the only users of this data I can find in fgdata are GUI dialogs which
| |
| are easy to fix, and actually would benefit from a revised API to get a single
| |
| runway by ident, which I plan to add - but I assume this is the feature other
| |
| FMS/CDU scripts are most likely using ....]
| |
|
| |
| 3)
| |
| The route-manager has an internal 'command' API to manipulate the route
| |
| - this is used by the route-manager dialog. With the new Nasal functions, this
| |
| could be replaced with nicer Nasal calls. The question is if anyone has code
| |
| which is using this API - it's been around for a long time. Again, in fgdata,
| |
| no one is.
| |
|
| |
| 1) is low risk, I will almost certainly do it.
| |
| 2) I would really like to do, but it really depends on the fall-out.
| |
| 3) is less important, since the old interface can remain in parallel
| |
| </pre>
| |
|
| |
| == A standard interface for mapping C++ classes to Nasal objects (Status 2013: implemented in cppbind) == | | == A standard interface for mapping C++ classes to Nasal objects (Status 2013: implemented in cppbind) == |
|
| |
|