Changes

Jump to: navigation, search

Howto:Extend Nasal

2,539 bytes added, 17:42, 27 June 2012
m
Background
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>
18,391
edits

Navigation menu