20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
m
→Backward Compatibility
mNo edit summary |
|||
| Line 375: | Line 375: | ||
* $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-3_4 | * $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-3_4 | ||
* $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-4_0 | * $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-4_0 | ||
{{FGCquote | |||
|Overall, we may sooner or later support backward compatibility by using something like io.include() with a nested version number and/or API call, it is not exactly difficult. For now, it would require just a few lines of code. The real challenge is that the code is very much evolving still, so it would be premature to implement something like that currently, especially because there's still many features missing so that establishing feature parity would be difficult at best - once things stabilize, and once multiple styles/aircraft are supported, we could/should revisit that. But unless someone else steps up to implement a working scheme, I am not currently interested in establishing such an API, at a time when things are being constantly refactored - we are seeing a handful of related efforts currently. And even Gijs mentioned a few times that he's still hoping to add new features - so adding API-level versioning/backward compatibility would probably become pretty awkward soon, and it would also involve other parts that don't actively support backward compatibility - Tom is using a getprop("/sim/version") check in api.nas - so it is possible, but only makes sense once the dust settles. | |||
At least for the time being, I'd estimate that it might take another 2-3 release cycles until this should be re-considered, unless we'll see more ND contributions rolling in shortly. | |||
If you do want to work out some kind of BC scheme, you are obviously invited to post your thoughts, I won't object any suggestions and will surely help review them to get them committed - but I'd probably not target 3.0, but instead 3.2 so that you have some kind of baseline to work with. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221158#p221158 | |||
|title=<nowiki>Re: What's going on with the Navdisplay</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Sat Oct 18</nowiki> | |||
}} | |||
}} | |||
=== Getting rid of Aircraft Dependencies === | === Getting rid of Aircraft Dependencies === | ||
* the constructor/newMFD() methods still contain a few hard-coded assumptions due to the origins of the code, but those can be also moved into some kind of construct() field in the hash, or you can simply use the method I suggested, i.e. hiding unneeded symbols. But you're right, that the most proper solution would be identifying non-generic code that contains hard-coded assumptions and moving that into some kind of construct() field that is simply invoked by the new/newMFD() methods. Doing that would not be difficult, it would be just copy & paste - i.e. copy from the navdisplay.mfd file into the style file, by adding a corresponding hash field entry there - and calling it instead. Takes under 3 minutes[http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=214897#p214835] | * the constructor/newMFD() methods still contain a few hard-coded assumptions due to the origins of the code, but those can be also moved into some kind of construct() field in the hash, or you can simply use the method I suggested, i.e. hiding unneeded symbols. But you're right, that the most proper solution would be identifying non-generic code that contains hard-coded assumptions and moving that into some kind of construct() field that is simply invoked by the new/newMFD() methods. Doing that would not be difficult, it would be just copy & paste - i.e. copy from the navdisplay.mfd file into the style file, by adding a corresponding hash field entry there - and calling it instead. Takes under 3 minutes[http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=214897#p214835] | ||