On 23 Sep 2013, at 15:19, Tomash Brechko wrote:
> 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 momen
2013/9/23 James Turner
> I think you should investigate the magvar() function:
>
Great, just what I need!
As ever, the problem here is we have no way to auto-document what's exposed
> to Nasal.
>
Could it be some special format comments in the C++ code and an extraction
script to update
http:
Hi,
2013/9/23 James Turner
> 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
On 23 Sep 2013, at 13:58, Tomash Brechko wrote:
> I use fgdata from git repo and so have a fresh copy of apt.dat.gz. I noted
> that apt data is actually ahead of what is fetched with TerraSync: some
> airports (at least UHPB, UIAE, UIUB, UIIB, but likely much more) present in
> apt.dat.gz (a
Hello,
I use fgdata from git repo and so have a fresh copy of apt.dat.gz. I noted
that apt data is actually ahead of what is fetched with TerraSync: some
airports (at least UHPB, UIAE, UIUB, UIIB, but likely much more) present in
apt.dat.gz (and thus shown in Atlas) but not in the scenery (fgfs
-
5 matches
Mail list logo
