2013/9/23 James Turner <zakal...@mac.com>

> I would greatly prefer you NOT do this, because the internal format of the
> cache (eg, the fact it's a SQL DB) is deliberately opaque.

Sure I'm aware of this, and please feel free to change the internals at any
moment without notice (as a last resort I can add an option to the script
to create its own DB based on navdata - just don't see the reason for this
at the moment).  Moreover I view the script as a temporal stub until the
information is available somewhere inside FG, my current knowledge of FG
internals is insufficient to implement it there myself, and having it dirty
way is better than nothing.

Related to this, it would be nice if the function to query magvar for
arbitrary location would have a Nasal binding (or magvar field in the
output of geodinfo() or airportinfo(), but this is less efficient if one
needs only magvar (and less flexible in the case of airportinfo(), though
in most cases you need to know declination exactly there)).  This will
allow reporting magnetic runway headings in the Airport dialog which I
presume is implemented in Nasal.

  Tomash Brechko
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
Flightgear-devel mailing list

Reply via email to