Hi,
just briefly (based on skimming a few postings on the first page of this thread), and to provide a little background information/context:
- the error shown on the first page of the thread shows a conventional "vector out of bounds" error, that's a standard Nasal thing - it's unrelated to MapStructure per se, it just says that some kind of API call returned something that was either not a vector or the vector didn't have the right size (length, number of elements).
- as far as I can tell, this is not specific or related to the MapStructure side of things, because everybody who responded to that posting said quite clearly that this showed up in recent binaries, the MapStructure stuff hasn't changed in years as far as I am aware.
- MapStructure itself evolved indeed "organically" as Gijs has alluded to, i.e. he came up with the ND code orignally, and it was highly specific to a single aircraft, and didn't support different aircraft, multiple independent instances or any kind of code reuse.
- Subsequently, a few of had the discussion whether/how to address these goals, i.e. to make Gijs code more modular and better reusable, what happened then, was that the ND code was basically copied/pasted to a different file and all mapping/charting related aspects of it were moved into a MVC-based architecture with different files for "layers of symbols", with a handful of generic classes to provide support for different kind of layers and symbols.
- The next thing that needed changing was to support "generic" handler so that different aircraft (cockpits) but also other means (UI dialogs) could be used to "control" those maps consisting of layers and layers consisting of symbols.
- Thus, what must have really happened here is that some kind of underlying system implemented in C++ changed either its behavior, or some edge case isn't properly handled.
Either way, fixing this is not difficult, but it's actually not the task of the MapStructure framework - I suppose that either front-end using those APIs, will trigger the same issue.
But the Nasal "fix" is simply to handle this case more gracefully, e.g. by doing a typeof()=="vector" check, that's it.
If in doubt, you can always shoot a PM to the people involved in writing the original code (or use the wiki to get in touch) - we are usually happy to provide answers, even if we are not currently around. You can look up the history of a file by looking at the commits logs, or the wiki pages documenting the framework.
PS: All that being said, please do feel free to rewrite whatever MapStructure code you'd like to see re-done, I would just suggest to tread carefully here: Be sure to really try to understand what the MapStructure framework is trying to do, how it came to be, and how it is structured to accomplish these goals, i.e. what it is doing, why and how. As Gijs said, nothing is set in stone here - but it doesn't make that much sense to redo (or even just ignore) MapStructure without understanding its scope and surrounding context. I'd even go as far as saying that you are unlikely to accomplish those goals, without going doing some kind of similar path (using a similarly decoupled approach). As far as I am aware though, the FG1000 remains the most "state of the art" avionics suite that satisfies these modularity/reuse requirements, and it too, happens to use the MapStructure framework.
Back when all this "happened", we were literally faced with a massive piece of code written single-handedly by Gijs, who never really shared his progress/approach until he considered it ready for primetime - so we saw some awesome looking screenshots/videos and loved the functionality, but all other aircraft developers wanting to reuse that instrument elsewhere, simply couldn't do so - and that also applied to people wanting to create/use similar displays, e.g. elsewhere in the UI. This, too, required support for certain changes - such as styling/theming support, so that different types of aircraft/displays could use different symbology. We came up with a fairly lightweight framework that ended up using delegates for many/most things, i.e. inversion-of-control (IOC), so that whatever code ends up calling those APIs, could highly customize the framework without having to touch any of the underlying files necessary - artix proved this extensively by creating how own set of Airbus related MapStructure files.
By the way, given the state of affairs today, such a framework would probably be best written using Richard's Emesary Framework (see the wiki).
Finally, most Canvas related Nasal code we've seen over the years suffers from pretty much the same limitations that the original ND/PFD code suffered from, and that MapStrucuture successfully addressed - however, in the process of coming up with that framework, we also learnt a number of important lessons over time, like Gijs said already - basically, the way we have come to expose/use and support the Canvas framework, is far too low-level for the average aircraft/cockpit/avionics developer, i.e. people without a corresponding IT/CS/SE background, that is why we ended up arriving at the conclusion, that we should stop writing "frameworks" for such purposes, but instead expose the sc::Element interface at the Nasal level, analogous to sc::Widget - so that new, custom, elements could be prototyped/implemented in scripting space, and registered with sc::Group as custom elements - this would neatly address many/most long-standing issues, and would make tons of "framework code" entirely obsolete quickly, while also providing a sane migration path for people (think versioning, but also profiling/optimizing elements, by moving certain functionality back into native code).
The full background can be found here:
http://wiki.flightgear.org/Canvas_Devel ... FlightGear