by Hooray » Sun Dec 01, 2013 6:00 pm
Gijs committed the NavDisplay part of this now, thank you!
Also, some people reported lag, that will undoubtedly improve once MapStructure is adopted and once Tom/Zakalawe provided a better positioned query API - but in the meantime it may help to use a less aggressive timer, I suggest to change the ND constructor/newMFD method, so that this can be configured by the aircraft developer, look for the maketimer() call in navdisplay.mfd and turn it into a variable - add the variable to the method, and default it to the current value - that way, you can override it in your ND.nas file
In the long run, the right thing to do, would updating different elements using smarter heuristics, i.e. not just at frame rate - MapStructure will help with that, but isn't yet quite finished... but if in doubt: it should be safe to commit MapStructure changes even during the code freeze because it only affects the aircraft using it, i.e. 744 or possibly 777, as long as the aircraft developers are okay with it, as per Torsten's policy regarding code freeze vs. aircraft changes (see lessons learned).
I hope that Hyde will find some time to commit his own 777 changes, so that we have a 2nd aircraft using the framework, which is good to ensure that things are working properly. Otherwise, I am handing navdisplay.mfd over to the two of you for the time being, and hope that you find some time to discuss missing features - feel free to add lots of comments to the file, which will help me when looking at it again.
If you don't know where/how to add something, just use the update() method for now, and I will fix things later on. Regarding the shared/common SVG file, I suggest to introduce a prefix for each manufacturer/type, so that aircraft developers can all use a single file and look up the required elements - that would allow us to use it for Airbus etc too - no need to reinvent the wheel, just add custom/special stuff to it if required.
PS: did you change anything else ?