Canvas ND framework: Difference between revisions

[[File:Canvasready.png|right]]

{{infobox subsystem

|description  = [[Canvas]]/[[Nasal]] driven NDs

|status      = Under active development as of 12/2013

|developers  = [[User:Gijs]] (since 11/2013)

}}

Extending the framework should normally require very little in terms of coding - typically, people can simply take an existing feature/symbol, copy & paste the code section and customize it according to their needs (e.g. different SVG element id, different animations, different properties) - symbols can be easily changed by providing a separate SVG file, or by creating a new one via Inkscape.

[[File:777-200-ND-Controls.png|thumb|Screen shot showing the control panel of the 777-200ER for controlling the Canvas-based [[NavDisplay]]]]

== Adding the navigation display to your aircraft ==

Note that the latest ND code is currently only available in Git and not in the latest stable release.  

# Add a surface object to your 3D model and apply a place holder texture to it. You can refer to the 747-400 and 777 for examples.

# Add the file to the <nasal> block in your aircraft's [[Aircraft-set.xml|-set.xml]] file.

# In order to customize the ND for your specific aircraft, change a few options in your ND.nas file:

## the node behind <code>addPlacement</code> is the name of the object in your 3D model. For multiple independent NDs, each ND should have its own object (and thus placement node). The 777 for example has a "ndScreenL" and a "ndScreenR".

That's the only thing you need to do right now. future changes will be in navdisplay.mfd and will be automatically available to you once they're committed/merged, no changes needed in your ND.nas at all, except for additional switches/buttons that may be created, and which would obviously need to be mapped to your cockpit hot spots.

== Gallery ==

Navigation display MAP mode.png|MAP mode

Navigation display centered MAP mode.png|Centered MAP mode

<syntaxhighlight lang="xml">

</syntaxhighlight>

Or here again for the range selection:

<syntaxhighlight lang="xml">

</syntaxhighlight>

<syntaxhighlight lang="xml">  

</syntaxhighlight>

* $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-3_4

* $FG_ROOT/Nasal/canvas/map/ND/nd.airbus-4_0

{{FGCquote

=== 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]

=== Encapsulating Properties ===

{{FGCquote

   }}

}}

=== Post 3.2 ===

Gijs has already begun to clean up the update() method, and navdisplay.mfd is now back down to under 800 lines of code. Hooray will need to revisit adding support for '''switches''' (i.e. a helper class) and corresponding display modes.