Sorry, if I was overwhelming you. That was not my intention.
It's not so much ideas or "vision" as such, but rather seeing overlapping developments going on, i.e. stuff that people are currently working on that could be useful from the ground services adddon perspective, but also looking at your own development and realizing that this could be useful for stuff that other folks are working on.
Turning your MapStructure related changes into dedicated "layers" is just one part of that, because that would mean that these layers could be more easily reused without people having to have your grasp of Nasal knowledge
- the registerLayer()/unregisterLayer() API was just an idea to expose a vector (or even just a hash) of layers that are to be updated "quickly" (=regularly), regardless of other update semantics.
- Regarding the groundnet parsing overhead - I do not think that this will show up at all, because these layers are only instantiated when actually used - so that instruments/dialogs not using your layer will not even do any parsing. Apart from that, if this is pure parsing and building a Nasal-space data structure only, you can use thread.newthread(callback) to run an arbitrary Nasal callback in a background thread, as long as it is not using any of the FlightGear specific extension functions (namely fgcommands, the property tree and any of the Canvas APIs).
- Like you say, exposing the groundnet at the property tree level would also be possible - and even that could be accomplished using a Nasal space workaround (until the C++ folks have come up with a patch to do just that) - imagine having a down-stripped version of your current code that will do the parsing/processing in a background thread, build the data structure and the populate the property tree afterwards - that could be a standalone component, one that could be replaced if/when the corresponding task is moved to C++ code.
- A generic AI layer would definitely seem possible, but we have already seen all sorts of different "filtering" requirements, including people wanting to implement radar/radio propagation semantics to exclude certain traffic that would be hidden behind a mountain range etc.
- Like you say, the generic AI layer could be generalized a little more and could also have optional support for becoming an "UI" layer with support for interactive functionality (as in Nasal/Canvas tooltips, or context menus for selected nodes on the map)
Regarding the major change you have in mind, my suggestion would be to proceed according to your own goals and priorities - I mean, like I just mentioned on the wiki, you have already made enormous progress with your latest code, and it is much cleaner and much better organized than pretty much everything I have seen in that department over the course of the last couple of years -I mean, it even has built-in unit tests apparently ...
Then again, my recommendation would be to get in touch with the devel list, it is foreseeable that your addon should be added to FGAddon sooner or later (assuming it is GPL?) - thus, it would make sense to get it committed there, which also means that its development will be more prominent, and more people will be tracking its development and actually help with testing, and possibly feature requests/patches.
Besides, it is worth noting that there are quie a few related features, you mentioned already the "jetways" functionality.
I would suggest to look up the recent discussions related to that - and get it touch with the developer/s who came up with that code (I believe it was primarily skyop, not sure though):
https://sourceforge.net/p/flightgear/ma ... /34725917/I do think that the most recent consensus on the devel list was to keep this stuff in Nasal space, but extend the underlying C++ code in the AI system to better support these use-cases.
I think that it was James who mentioned that he'd be willing to "mentor" people to do just that, referring to:
https://sourceforge.net/p/flightgear/ma ... /35491165/James Turner wrote:There’s zero need for anything to hit the disk in this process, or duplicate any XML files - but it needs some C++ coding, it can’t be done entirely from Nasal.
So, we need a volunteer to port the jetways logic to some C++ to create the instances (the per-jetway logic can stay in Nasal as needed). I’m happy to coach / assist.
Thus, my take on the matter is that it would make sense to reach out to the people involved in the original Nasal code, because that is what your code is using, too. And then see if they're still around or not, and work out a way to come up with the requirements for the corresponding C++ changes to support these kinds of use-cases better.
As a matter of fact, Durk himself mentioned on various ocassions that he'd be supportive of generalizing the original AI code accordingly, so that some of its hard-coded and built-in assumptions could be better customized or disabled completely (referring for instance to the Bombable/dog-fighting use-case):
viewtopic.php?p=134970&#p134970Durk wrote:Note that I won't oppose other ideas, and if you have nasal code that would require certain components of the AI system to be shutdown, or need specific hooks to interface certain C++ components with nasal bindings, than I would certainly be willing to support that.
Speaking in general, I am however not sure if Durk is currently around or actively involved at the code level. Thus, my recommendation would be to look up James' comments involving the jetways/AI discussion, because he's been around for a number of years now, and he's basically the most likely person to help with reviewing/integrating such changes, because he belongs to the camp of the few people not just wanting to see less Nasal code running in the main loop, but also offering to actually do the corresponding C++ work to provide alternatives that are accessible to Nasal coders.
Other than that, my suggestion would be to keep on working with such a clean structure, and maybe even introduce a dedicated folder for code/modules that may sooner or later become a part of $FG_ROOT/Nasal.
From a functionality standpoint, I can however foresee that it would be great if you could get in touch with the OSM2City folks, because that's the primary other ground-traffic application in FlightGear that already provides the equivalent of a "groundnet", and that's the kind of feature that could help make your work really popular among folks, so that C++ level additions will sooner or later be really required.
The other power-feature being integration with the so called "Traffic Shader" that Thorsten, i4dnf and others worked out a while ago (also apparently using OSM2city data these days).
http://wiki.flightgear.org/Traffic_Shader