20,741
edits
Howto:Extend Nasal: Difference between revisions
Jump to navigation
Jump to search
m
→Background
m (→Background) |
|||
| Line 339: | Line 339: | ||
proper naGhosts, and could have a forwards-compatible APi when the ghosts are | proper naGhosts, and could have a forwards-compatible APi when the ghosts are | ||
written. | 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> | </pre> | ||