20,741
edits
Canvas ND framework: Difference between revisions
Jump to navigation
Jump to search
m
→Custom ND Styles
m (→Custom ND Styles: http://forum.flightgear.org/viewtopic.php?f=4&t=12903&p=206852&hilit=canvas+airbus#p206852) |
|||
| Line 202: | Line 202: | ||
== Custom ND Styles == | == Custom ND Styles == | ||
Note that | Note that setup instructions above will initially just give you a Boeing-centric ND, because it is currently being developed by the 747/777 maintainers primarily - please use the issue tracker to file feature requests for missing features. | ||
Over time, the framework will grow and become more flexible,so that also specifics of non-Boeing aircraft can be properly emulated. But obviously this will take a while. We invite aircraft developers to help extend and refine the framework accordingly. | |||
Design-wise, the ND code still isn't quite there yet, so I would still postpone any custom implementations - it is better to coordinate things with Gijs and Hyde to keep on improving the existing ND, rather than re-implementing an airbus-specific one at the moment. Simply because things are very much in flux still - there's quite a bit of refactoring pending, and it seems that neither of us is going to tackle this anytime soon. | Design-wise, the ND code still isn't quite there yet, so I would still postpone any custom implementations - it is better to coordinate things with Gijs and Hyde to keep on improving the existing ND, rather than re-implementing an airbus-specific one at the moment. Simply because things are very much in flux still - there's quite a bit of refactoring pending, and it seems that neither of us is going to tackle this anytime soon. | ||
| Line 214: | Line 216: | ||
For the time being, please disregard the custom implementations (e.g. an Airbus version) until the NavDisplay/MapStructure frameworks have matured a little more - i.e. maybe given it another 3 months. | For the time being, please disregard the custom implementations (e.g. an Airbus version) until the NavDisplay/MapStructure frameworks have matured a little more - i.e. maybe given it another 3 months. | ||
The thing is, even if someone were to come up with a 100% correct/working A320 implementation now, the framework itself would not yet be sufficiently generalized - some of the recent additions are making things more complicated here, such as the inflated update() method, the Boeing-specific constructor and hard-coded assumptions in the newMFD() method. | ''The thing is, even if someone were to come up with a 100% correct/working A320 implementation now, the framework itself would not yet be sufficiently generalized - some of the recent additions are making things more complicated here, such as the inflated update() method, the Boeing-specific constructor and hard-coded assumptions in the newMFD() method.'' | ||
None of this is really difficult to fix, but these things need to be tackled first - otherwise, we'll have too many "construction sites" eventually. | None of this is really difficult to fix, but these things need to be tackled first - otherwise, we'll have too many "construction sites" eventually. | ||
| Line 222: | Line 224: | ||
We appreciate any help in maintaining and updating these frameworks, but currently these are not yet as flexible (aircraft-agnostic) as they need to be. | We appreciate any help in maintaining and updating these frameworks, but currently these are not yet as flexible (aircraft-agnostic) as they need to be. | ||
Speaking in non-coding terms: When we refactored the ND code, we explicitly wanted to support different makes/models for different aircraft using a single back-end and code base. And that's something that is already prepared in the design in several places, and it may seem straightforward to people not familiar with the code. | '''Speaking in non-coding terms: When we refactored the ND code, we explicitly wanted to support different makes/models for different aircraft using a single back-end and code base. And that's something that is already prepared in the design in several places, and it may seem straightforward to people not familiar with the code. | ||
Here, you could say that the ND itself is the 3D model, while the "style" is analogous to a "livery" (texture pack). | Here, you could say that the ND itself is the 3D model, while the "style" is analogous to a "livery" (texture pack). | ||
| Line 228: | Line 230: | ||
The way things are implemented, we prepared support for "livery packs", and for easily creating new styles without having to touch the code. | The way things are implemented, we prepared support for "livery packs", and for easily creating new styles without having to touch the code. | ||
However, currently there's still some work that needs to be done, and Gijs, Hyde and Soitanen have added features that need to be integrated properly first - you could say that they're working on the "3D model" still, so it's not such a good idea to create lots of "liveries" (styles) currently | However, currently there's still some work that needs to be done, and Gijs, Hyde and Soitanen have added features that need to be integrated properly first - you could say that they're working on the "3D model" still, so it's not such a good idea to create lots of "liveries" (styles) currently.''' | ||
So it would be better to wait a little here and provide plenty of feedback in the meantime - if you really want to, you can get involved in the ND/MapStructure efforts themselves, but I would not yet suggest to come up with a totally new ND implementation - unless you're also prepared/willing to do the necessary groundwork, i.e. Nasal-space refactoring - the latter will mostly affect the new/newMFD/update functions - so not too difficult to understand if you are interested. | So it would be better to wait a little here and provide plenty of feedback in the meantime - if you really want to, you can get involved in the ND/MapStructure efforts themselves, but I would not yet suggest to come up with a totally new ND implementation - unless you're also prepared/willing to do the necessary groundwork, i.e. Nasal-space refactoring - the latter will mostly affect the new/newMFD/update functions - so not too difficult to understand if you are interested. | ||