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
All feedback appreciated.
James
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
