onox wrote in Sun Jan 25, 2015 6:26 am:Hooray, do you have a link to the exact precise code that creates that 2nd black Canvas Dialog in the 2nd screenshot?
do you just mean/need the Canvas dialog, then refer to the "Canvas Snippets" article
If you mean the Canvas dialog + the ND shown there, it's a conventional ND with a GUI placement
To see how this is set up, refer to the top of MapStructure.nas which sets up a test map and opens the whole thing in a GUI dialog.
If you want to have a full ND, you'll need to do the same thing with the ND setup code (as per the wiki instructions).
If you just need a separate window for an existing ND, it's just another placement - if you want a standalone ND, agnostic to the type of aircraft used, you need to set up the ND first and then attach it to the Canvas GUI dialog. The code doing this sort of thing is part of the MapStructure framework and also shown on the wiki (not sure if that's back already or not ...)
However, what I did have to do back then for the standalone ND was setting its properties up using the property browser - these days, you would probably want to procedurally create a handful of ND buttons and add those to the top of the Canvas showing the ND, analogous to the "Canvas/MapStructure Debugger" shown above (PUI)
BTW: IF you are specifically referring to the standalone Canvas ND using AI traffic as the data "source", I actually posted the corresponding snippet of code, too:
viewtopic.php?p=193660#p193825Most of this should still be applicable, but may need to be reviewed/updated to match ND/MapStructure changes that were implemented in the meantime.
But the general idea is still the same, even though some symbols/names may have changed - but nothing too difficult to update by looking at an arbitrary ND.nas file (e.g. 777/747) and fixing up properties/APIs.
As you can see, the MapStructure/ND APIs are sufficiently encapsulated to allow arbitrary traffic to be used as position/data source, including AI traffic - but also MP traffic.
Someone with your Nasal understanding should be able to adapt the corresponding code pretty quickly.
So far, it seems that the navDB overhead is comparatively small - according to tikibar's recent findings, we're seeing rendering/rasterization taking some time, i.e. on the Canvas side (especially related to projection handling, which Gijs is hoping to address eventually) - and a while ago, Zakalawe said that supporting concurrent navdb queries would be problematic probably, and I guess he's in the best position if/how his code could be adapted. Overall, the navdb should be "read-only" at run-time, so should be conceptually straightforward to query concurrently - but I guess there are some hard-coded restrictions involved (e.g. static variables and so on) that might make this a little tricky. In addition, the navcache isn't implemented as a conventional SGSubsystem for the time being - this could prove to be both challenging and useful, simply because the navDB is merely an API and not a proper subsystem that is actually updated.
In essence, the whole notion of having a single-threaded "singleton" navdb kinda violates the whole concept of having a "database" in the first place - I mean, if this were a conventional mySQL database, it could obviously be accessed from hundreds of clients (processes/threads) concurrently - and I don't see any hard design restrictions why the underlying FG DB shouldn't also be safely accessed from multiple "clients".
In fact, in a multi-instance FlightGear setup (think multiplayer/multi-machine setup), having a common (or synchronized) navDB would be an important factor, e.g. imagine navaid info varying (frequencies, identifiers etc)