To be honest, it's been a few years since we came up with that code, so off the top of my heads some comments:
- I would suggest to always look at related layers, i.e. layers that have similar functionality and then "harvest" useful code there (like you did already with the flight path/leg layer)
- sometimes different layers have different parts of code that may come in handy
- it may help to run "grep" to search for useful bits
- for instance, the flight path layer (FLT) is using the history() API currently and it needs to use an aircraft's position - so it's using something like "aircraftpos.controller" in $FG_ROOT/Nasal/canvas/map
- this is yet another layer of abstraction, basically this encapsulates all related calls - that way, it's possible to use a different positional source (for instance, MapStructure maps/layers are designed to work with arbitrary position sources, including MP/AI traffic but also instant replay) - that way it's possible to easily debug/stress test MapStructure layers, for instance by hooking up a map (or even a full ND) to an existing AI/MP node in the property tree (think AI traffic like the tanker or an actual MP pilot flying at any given moment in time)
- we used this extensively during development of the framework, because we needed a way to easily iterate, without having to startup an aircraft or perform takeoffs and landings etc
- there may be remaining hard-coded getprop() calls referring to /position in some layers - but in general, these are intended to be replaced by the code in aircraftpos.controller - it's a simple hash actually.
- there you will also find hard-coded assumptions about layers that must be updated permanently or "quickly" - this is a vector of layer names that are regularly updated, i.e. that don't update based on some condition (like the other layers)
- look specifically for this:
- Code: Select all
# Layers which get updated every frame
var update_instant = [
"APS",
];
# Update at a slightly lower rate, but still
# unconditionally
var update_quickly = [
"TFC", "FLT",
];
Basically this file contains the highest level logic to control a map and its associated layers and MVC components.
Note however, this all predates the addon framework, so we don't currently have an API to append new layers to the controller.
But that should be fairly easy to add (and it would be a good idea too).
Speaking in general your code is really looking good, and I am looking forward to seeing your layer in action.
Please do keep us posted, and do feel free to add your addon/MapStructure layer to the newsletter or the list of MapStructure layers.
As a matter of fact, it would actually be cool to see a dedicated tutorial about creating new MapStructure layers like this one from scratch, that also goes into the details that we omitted when we wrote the original docs (several years ago!).
Before I forget it, to recolor individual legs, you either need to keep a vector of active legs (as canvas elements/objects) or use a dedicated "symbol controller", I think you could implement this by using a "Model" wrapper (MVC) to keep track of all your legs (one leg per model) and then you can implement custom heuristics for coloring/recoloring or styling in general.
I don't remember if we have animated symbols in the main repo or not - but basically, it's the same method: keep track of the canvas element (path element) that resembles a leg, and then hook it up to some heuristic to apply a color palette. We had this working long ago, including blinking symbols and symbols that would permanently scale up/down - but I believe that might have been one of those prototype layers rather than something useful enough to get committed to the official repo (?)
I also think that there are other addon developers that might be interested in learning how to use MapStructure to add custom functionality.
For instance, ThomasS created the "GroundServices" addon that adds a dedicated layer for ground networks - so that might be another useful piece of code to look at.
And please feel free to get in touch if there are remaining questions or if this answer isn't yet addressing all your questions.
I am not sure if you have fgdata commit access or not, but if you find that some stuff in MapStructure.nas needs to be extended for your use-case, I'd suggest to reach out to Stuart (developer of the FG1000 and pretty familiar with MapStructure) or Richard (also familiar with the code) - alternatively, look up who's recently been making canvas related fgdata additions to $FG_ROOT/Nasal/canvas via "git log" to find an active maintainer (jsb would seem like another potential candidate to help with getting changes integrated).
PS: In GRID.lcontroller (written by Stuart IIRC) you should find a hash called df_options (for default options) that should contain stuff that can be overridden by passing different options (e.g. granularity of the GRID)