FlightGear wiki - User contributions [en]

Howto:Dynamic Liveries via Canvas

2014-09-17T22:37:27Z

Algernon: /* Canvas Code */

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

{{FGCquote
|The code is already in place for the "dirtying" effect - it's a fairly simple linear introduction of the dirt texture, becoming less transparent the more the aircraft flies without being washed. Being washed also includes rain - continued exposure to precipitation will "wash away" dirt by making the dirt layer more transparent according to the heaviness of the weather. It's been tried on the APU smudge, and whilst the values will need to be tweaked, it already works pretty much to my expectations and satisfaction.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218792#p218792
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 17</nowiki>
}}
}}

{{FGCquote
|But in the long-term, I would prefer turning this into a Nasal class that can manage multiple Canvases per aircraft, so that we can also re-implement the existing livery system accordingly, so that it stops interfering with canvas. Which would also mean that people can reuse the same class for placing bullet holes or doing other fancy things (e.g. immatriculation)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218789#p218789
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 17</nowiki>
}}
}}

== Proof of Concept: Exhaust dirt ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt streaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

<gallery mode="packed">
Two-layers.jpg|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks
Dynamic-Textures-First-Try.jpg|A first (failed) attempt to put a canvas onto a model object in place of its texture.
Ef2000dyn1.jpg|The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.
File:Ef2000dyn2.jpg|Changing the dialog window size to be the same size as the texture fixed the issue - note that the fuselage sections are free of dirt (except the APU exhaust smudge, which is a special case) where as the wings and tail have integral dirt in the texture.
File:Ef2000dyn3.jpg|A full-screen illustration using the updated Canvas code to make the canvas independent of the window, but with the window still displaying the canvas. Here, only the base "clean" paintwork texture is added to the fuselage element.
File:Ef2000dyn4.jpg|After creating a canvas with the base "clean" paintwork texture, another child is added containing the dirt layer transparency. The effect is seen both in the dialog window and on the airframe.
</gallery>

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using raster images and nested canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line did not seem to make any difference to the texture on the named model object ("Fuselage"). When the native XML/Nasal livery object was commented out, the image was successfully displayed on the fuselage, but incorrectly sized and apparently without UV mapping (see image below).

<syntaxhighlight lang="nasal">
# Create a standalone Canvas (not attached to any GUI dialog/aircraft etc)
var myCanvas = canvas.new({
"name": "Livery Test", # The name is optional but allow for easier identification
"size": [2048, 2048], # Size of the underlying texture (should be a power of 2, required) [Resolution]
"view": [2048, 2048], # Virtual resolution (Defines the coordinate system of the canvas [Dimensions]
# which will be stretched the size of the texture, required)
"mipmapping": 1 # Enable mipmapping (optional)
});

# create our top-level/root group that contains all other Canvas elements
var root = myCanvas.createGroup();

# Add a placement by replacing the textured face "Fuselage" in the 3D model
# This replaces the texture on the aircraft and attaches the Canvas texture
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);

# And another, if required
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000-dirt.png")
.setSize(2048,2048);

# Create a Canvas dialog window to hold the canvas and show that it's working
# the Canvas is now standalone, i.e. continues to live once the dialog is closed!
var window = canvas.Window.new([512,512],"dialog");
window.setCanvas(myCanvas);
</syntaxhighlight>

== Original Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

Howto:Dynamic Liveries via Canvas

2014-09-17T22:15:43Z

Algernon: /* Proof of Concept */

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

{{FGCquote
|The code is already in place for the "dirtying" effect - it's a fairly simple linear introduction of the dirt texture, becoming less transparent the more the aircraft flies without being washed. Being washed also includes rain - continued exposure to precipitation will "wash away" dirt by making the dirt layer more transparent according to the heaviness of the weather. It's been tried on the APU smudge, and whilst the values will need to be tweaked, it already works pretty much to my expectations and satisfaction.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218792#p218792
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 17</nowiki>
}}
}}

{{FGCquote
|But in the long-term, I would prefer turning this into a Nasal class that can manage multiple Canvases per aircraft, so that we can also re-implement the existing livery system accordingly, so that it stops interfering with canvas. Which would also mean that people can reuse the same class for placing bullet holes or doing other fancy things (e.g. immatriculation)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=218789#p218789
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 17</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt streaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

<gallery mode=packed>
Two-layers.jpg|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks
Dynamic-Textures-First-Try.jpg|A first (failed) attempt to put a canvas onto a model object in place of its texture.
Ef2000dyn1.jpg|The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.
File:Ef2000dyn2.jpg|Changing the dialog window size to be the same size as the texture fixed the issue - note that the fuselage sections are free of dirt (except the APU exhaust smudge, which is a special case) where as the wings and tail have integral dirt in the texture.
File:Ef2000dyn3.jpg|A full-screen illustration using the updated Canvas code to make the canvas independent of the window, but with the window still displaying the canvas. Here, only the base "clean" paintwork texture is added to the fuselage element.
File:Ef2000dyn4.jpg|After creating a canvas with the base "clean" paintwork texture, another child is added containing the dirt layer transparency. The effect is seen both in the dialog window and on the airframe.
</gallery>

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line did not seem to make any difference to the texture on the named model object ("Fuselage"). When the native XML/Nasal livery object was commented out, the image was successfully displayed on the fuselage, but incorrectly sized and apparently without UV mapping (see image below).

<syntaxhighlight lang="nasal">
# Create a standalone Canvas (not attached to any GUI dialog/aircraft etc)
var myCanvas = canvas.new({
"name": "Livery Test", # The name is optional but allow for easier identification
"size": [2048, 2048], # Size of the underlying texture (should be a power of 2, required) [Resolution]
"view": [2048, 2048], # Virtual resolution (Defines the coordinate system of the canvas [Dimensions]
# which will be stretched the size of the texture, required)
"mipmapping": 1 # Enable mipmapping (optional)
});

# create our top-level/root group that contains all other Canvas elements
var root = myCanvas.createGroup();

# Add a placement by replacing the textured face "Fuselage" in the 3D model
# This replaces the texture on the aircraft and attaches the Canvas texture
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);

# Create a Canvas dialog window to hold the canvas and show that it's working
# the Canvas is now standalone, i.e. continues to live once the dialog is closed!
var window = canvas.Window.new([512,512],"dialog");
window.setCanvas(myCanvas);
</syntaxhighlight>

== Original Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

File:Ef2000dyn4.jpg

2014-09-17T22:14:05Z

Algernon: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=A full-screen demonstration using the updated Canvas code to make the canvas independent of the window, but with the window still displaying. After creating a canvas with the base "clean" paintwork texture, another child is added containing the dirt layer transparency. The effect is seen both in the dialog window and on the airframe.}}
|date=2014-09-18 00:11:09
|source={{own}}
|author=[[User:Algernon|Algernon]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

File:Ef2000dyn3.jpg

2014-09-17T22:13:54Z

Algernon: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=A full-screen demonstration using the updated Canvas code to make the canvas independent of the window, but with the window still displaying. Here, only the base "clean" paintwork texture is added to the fuselage element.}}
|date=2014-09-18 00:10:49
|source={{own}}
|author=[[User:Algernon|Algernon]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

Howto:Dynamic Liveries via Canvas

2014-09-17T21:38:24Z

Algernon: /* Proof of Concept */

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt streaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

<gallery mode=packed>
Two-layers.jpg|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks
Dynamic-Textures-First-Try.jpg|A first (failed) attempt to put a canvas onto a model object in place of its texture.
Ef2000dyn1.jpg|The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.
File:Ef2000dyn2.jpg|Changing the dialog window size to be the same size as the texture fixed the issue - note that the fuselage sections are free of dirt (except the APU exhaust smudge, which is a special case) where as the wings and tail have integral dirt in the texture.
</gallery>

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line did not seem to make any difference to the texture on the named model object ("Fuselage"). When the native XML/Nasal livery object was commented out, the image was successfully displayed on the fuselage, but incorrectly sized and apparently without UV mapping (see image below).

<syntaxhighlight lang="nasal">
# Create a Canvas dialog window to hold the canvas and show that it's working
var window = canvas.Window.new([512,512],"dialog");

# Create a Canvas in the window and create a containing group called root
var myCanvas = window.createCanvas();
var root = myCanvas.createGroup();

# Add a placement by replacing the textured face "Fuselage" in the 3D model
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);
</syntaxhighlight>

== Original Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

File:Ef2000dyn2.jpg

2014-09-17T21:35:08Z

Algernon: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Changing the dialog window size to be the same size as the texture fixed the issue - note that the fuselage sections are free of dirt (except the APU exhaust smudge, which is a special case) where as the wings and tail have integral dirt in the texture.}}
|date=2014-09-17 23:32:12
|source={{own}}
|author=[[User:Algernon|Algernon]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

Howto:Dynamic Liveries via Canvas

2014-09-17T20:48:04Z

Algernon: /* Canvas Code */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

[[File:Two-layers.jpg|325px|thumb|right|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks]]

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt streaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line did not seem to make any difference to the texture on the named model object ("Fuselage"). When the native XML/Nasal livery object was commented out, the image was successfully displayed on the fuselage, but incorrectly sized and apparently without UV mapping (see image below).

<syntaxhighlight lang="nasal">
# Create a Canvas dialog window to hold the canvas and show that it's working
var window = canvas.Window.new([512,512],"dialog");

# Create a Canvas in the window and create a containing group called root
var myCanvas = window.createCanvas();
var root = myCanvas.createGroup();

# Add a placement by replacing the textured face "Fuselage" in the 3D model
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);
</syntaxhighlight>

[[File:Dynamic-Textures-First-Try.jpg|325px|thumb|right|A first (failed) attempt to put a canvas onto a model object in place of its texture.]]
[[File:Ef2000dyn1.jpg|325px|thumb|right|The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.]]

Howto:Dynamic Liveries via Canvas

2014-09-17T20:44:44Z

Algernon: /* Proof of Concept */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

[[File:Two-layers.jpg|325px|thumb|right|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks]]

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt streaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line does not seem to make any difference to the texture on the named model object ("Fuselage").

<syntaxhighlight lang="nasal">
# Create a Canvas dialog window to hold the canvas and show that it's working
var window = canvas.Window.new([512,512],"dialog");

# Create a Canvas in the window and create a containing group called root
var myCanvas = window.createCanvas();
var root = myCanvas.createGroup();

# Add a placement by replacing the textured face "Fuselage" in the 3D model
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);
</syntaxhighlight>

[[File:Dynamic-Textures-First-Try.jpg|325px|thumb|right|A first (failed) attempt to put a canvas onto a model object in place of its texture.]]
[[File:Ef2000dyn1.jpg|325px|thumb|right|The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.]]

File:Ef2000dyn1.jpg

2014-09-17T20:42:22Z

Algernon: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.}}
|date=2014-09-17 22:37:16
|source={{own}}
|author=[[User:Algernon|Algernon]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

Howto:Dynamic Liveries via Canvas

2014-09-17T18:24:18Z

Algernon: /* Proof of Concept */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

[[File:Two-layers.jpg|325px|thumb|right|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks]]
[[File:Dynamic-Textures-First-Try.jpg|325px|thumb|right|A first (failed) attempt to put a canvas onto a model object in place of its texture.]]

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt steaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line does not seem to make any difference to the texture on the named model object ("Fuselage").

<syntaxhighlight lang="nasal">
# Create a Canvas dialog window to hold the canvas and show that it's working
var window = canvas.Window.new([512,512],"dialog");

# Create a Canvas in the window and create a containing group called root
var myCanvas = window.createCanvas();
var root = myCanvas.createGroup();

# Add a placement. I believe the second argument relates to model objects, so I have attempted to place it on the object named Fuselage. I don't understand this bit too well, Hooray can you help?
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);
</syntaxhighlight>

Howto:Dynamic Liveries via Canvas

2014-09-17T18:21:26Z

Algernon: /* Proof of Concept */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

[[File:EF2000-canvas.ac in Blender.jpg|400px|right|EF2000-canvas.ac in Blender, showing the Texture allocations thus far]]
[[File:Two-layers.jpg|325px|thumb|right|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks]]
[[File:Dynamic-Textures-First-Try.jpg|325px|thumb|right|A first (failed) attempt to put a canvas onto a model object in place of its texture.]]

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt steaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line does not seem to make any difference to the texture on the named model object ("Fuselage").

<syntaxhighlight lang="nasal">
# Create a Canvas dialog window to hold the canvas and show that it's working
var window = canvas.Window.new([512,512],"dialog");

# Create a Canvas in the window and create a containing group called root
var myCanvas = window.createCanvas();
var root = myCanvas.createGroup();

# Add a placement. I believe the second argument relates to model objects, so I have attempted to place it on the object named Fuselage. I don't understand this bit too well, Hooray can you help?
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);
</syntaxhighlight>

Howto:Dynamic Liveries via Canvas

2014-09-17T18:19:55Z

Algernon: /* Model Work */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt steaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===

To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

{{-}}

=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line does not seem to make any difference to the texture on the named model object ("Fuselage").

<syntaxhighlight lang="nasal">
# Create a Canvas dialog window to hold the canvas and show that it's working
var window = canvas.Window.new([512,512],"dialog");

# Create a Canvas in the window and create a containing group called root
var myCanvas = window.createCanvas();
var root = myCanvas.createGroup();

# Add a placement. I believe the second argument relates to model objects, so I have attempted to place it on the object named Fuselage. I don't understand this bit too well, Hooray can you help?
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);
</syntaxhighlight>

Howto:Dynamic Liveries via Canvas

2014-09-17T18:15:07Z

Algernon: /* Proof of Concept */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt steaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===
[[File:EF2000-canvas.ac in Blender.jpg|400px|right|EF2000-canvas.ac in Blender, showing the Texture allocations thus far]]
To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.
[[File:Two-layers.jpg|325px|thumb|left|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks]]
{{-}}
=== Canvas Code ===
From the code snippets above and [[Howto:Using_raster_images_and_nested_canvases]], I've put together my first attempt at some Canvas code. It appears that the canvas is the right size, and both .jpg and .png textures are loaded. But the placement line does not seem to make any difference to the texture on the named model object ("Fuselage").

<syntaxhighlight lang="nasal">
# Create a Canvas dialog window to hold the canvas and show that it's working
var window = canvas.Window.new([512,512],"dialog");

# Create a Canvas in the window and create a containing group called root
var myCanvas = window.createCanvas();
var root = myCanvas.createGroup();

# Add a placement. I believe the second argument relates to model objects, so I have attempted to place it on the object named Fuselage. I don't understand this bit too well, Hooray can you help?
myCanvas.addPlacement({"node": "Fuselage"});

# Put a raster image into the canvas
root.createChild("image")
.setFile("Aircraft/EF2000/Models/EF2000.png")
.setSize(2048,2048);
</syntaxhighlight>

File:Dynamic-Textures-First-Try.jpg

2014-09-17T18:14:48Z

Algernon: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=A first (failed) attempt to put a canvas onto a model object in place of its texture.}}
|date=2014-09-17 20:12:43
|source={{own}}
|author=[[User:Algernon|Algernon]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

Howto:Dynamic Liveries via Canvas

2014-09-17T17:29:08Z

Algernon: /* Model Work */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt steaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===
[[File:EF2000-canvas.ac in Blender.jpg|400px|right|EF2000-canvas.ac in Blender, showing the Texture allocations thus far]]
To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.
[[File:Two-layers.jpg|325px|thumb|left|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks]]

File:Two-layers.jpg

2014-09-17T17:18:28Z

Algernon: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks}}
|date=2014-09-17 19:17:11
|source={{own}}
|author=[[User:Algernon|Algernon]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

Howto:Dynamic Liveries via Canvas

2014-09-17T17:09:32Z

Algernon: /* Proof of Concept */

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt steaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===
[[File:EF2000-canvas.ac in Blender.jpg|400px|right|EF2000-canvas.ac in Blender, showing the Texture allocations thus far]]
To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

Howto:Dynamic Liveries via Canvas

2014-09-17T17:08:24Z

Algernon:

[[File:Canvas-livery-demo-using-ogle.png|left|400px|A screen shot showing the ogel aircraft whose livery is dynamically changed using the [[Canvas]] system - in this case, we're simply rendering a [[MapStructure]] map onto the face of the pilot using ~10 lines of Nasal/Canvas code.]]

== Objective ==
Demonstrate how to modify/animate liveries using Nasal/Canvas.

== Example ==
{{Note|This assumes that you're using the ogel aircraft and that the face texture can be looked up using the name '''Head'''.
The map shown here is just an example, this could obviously be anything, including raster/svg images, custom OpenVG/ShivaVG paths, osgText etc.
To implement a dirt texture, you'd want to use the corresponding texture ID and then overlay a static dirt texture using some kind of random scheme, e.g. by adding texture maps/sub regions to the exhaust area. See [[Canvas Image]] for details.
In its current form, this will simply apply the texture mapping used in the 3D mode "as is". In other words, all texture-mapped faces should be accessible from Nasal/Canvas and can be modified/animated.
In comparison to a pure shader-based approach this is likely to have a little more overhead, while not requiring effects/shaders (but RTT/FBOs due to Canvas) - also, this approach is agnostic to the underlying rendering pipeline, i.e. should also work for Rembrandt aircraft, without having to be customized. }}

<syntaxhighlight lang="nasal">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas();

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

# add a new placement using a texture identifier (see $FG_ROOT/ogel/Models/SinglePiston.ac or existing liveries)
myCanvas.addPlacement({"node": "Head"});

# now, let's add some content to our canvas (this could be really anything)
# animations are handled via timers/listeners (not shown here, hidden in the depths of MapStructure)
var TestMap = root.createChild("map");
TestMap.setController("Aircraft position");
TestMap.setRange(25);

TestMap.setTranslation( myCanvas.get("view[0]")/2,
myCanvas.get("view[1]")/2
);
var r = func(name,vis=1,zindex=nil) return caller(0)[0];

foreach(var type; [r('APT'), r('VOR') ] )
TestMap.addLayer(factory: canvas.SymbolLayer, type_arg: type.name, visible: type.vis, priority: type.zindex,);
</syntaxhighlight>

== Background ==
{{FGCquote
|Does anyone know if it's possible for FG to work with a texture which consists of two images, and manipulate those images seperately? The application here is airframe dirt - I'm trying to find out if I can have one texture for the aircraft livery, and another for accumulated dirt, which would gradually become less transparent as the airframe hours increase. I am aware of the questionable advisability of using alpha channels excessively in FG, this is just an experiment at the moment.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217613#p217613
|title=<nowiki>Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|there are probably several ways to do something like this, effects/shaders and even Canvas can be used to combine textures and adjusting alpha via Nasal. 
So it's mainly a matter of your exact requirements and what kind of solution you'd prefer.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217614#p217614
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Sep 01</nowiki>
}}
}}

{{FGCquote
|The aircraft gets dirtier with more flights hours. Some code to do this is already in place, and tested on the other dirt application, the APU exhaust blackening on the port wing root. This is a localised and distinctive stain which you see on most Typhoons, so there I have just used a duplicate of the vertices and faces in that locality, placed a little away from the airframe, and used an alpha texture and the material transparency animation. It works a charm, and doesn't seem to have problems with alpha flashing. For the airframe, this probably isn't a viable approach. Part of the textures set for the airframe has a transparent dirt layer which has been tailored to the model to feature streaks from particular vents or around extensions like underwing pylons, so it would be desirable to be able to use this. This additional layer must remain unchanged through livery switches, and then be gradually introduced over time according to the property updated by the same Nasal function that dirties the APU exhaust while it's running (the airframe starts to gets dirtier over 80kts or something for the all over dirt). And if at all possible, it should be Rembrandt compatible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| The idea of a canvas airframe texture is a fascinating one, and might be considered almost heretical over at FGUK! ;) But although I'm finding Canvas a bit inaccessible at the moment, if I can achieve combined textures with controllable transparency that works equally well with or without Rembrandt, I'd certainly be interested in using this idea as an entry point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217721#p217721
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Algernon</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|Canvas should work fairly well actually - Tom added support for pretty much "arbitrary" placements, so that canvas textures can be placed anywhere on the aircraft, but also in the scenery (and obviously also in GUI dialogs/windows). We once toyed with the idea of also making effects and shaders available to Canvas - Tom also mentioned this once on the devel list, and we have code doing this for the whole canvas - even though Tom said that it would be better to support this "per-element". Obviously, that would bring a ton of flexibility to Canvas-based efforts like yours. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|most code snippets recently added to the wiki are about different use-cases - i.e. not specifically about airframe textures/liveries, but then again - the Canvas doesn't care at all where you use a certain texture - in other words, you could prototype the whole thing using a GUI dialog and once you are satisifed with the outcode you would use another placement to show the texture elsewhere. The good thing about your particular use case is that it low-bandwidth, i.e. the texture probably doesn't need to be updated per frame - so performance issues due to Nasal/Canvas overhead should not be a factor. 
I think you could certainly prototype the whole thing fairly quickly - and if/once effects and shaders become available to Canvas, your approach could be updated accordingly.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|For starters, you could look at this: [[Howto:Using_raster_images_and_nested_canvases#Example:_Showing_a_Splash_Screen]] 
 
This will open an existing splash screen image and show it in a Canvas dialog. 
You can copy/paste the code to load a few different images, to learn more about Canvas image handling, see: [[Canvas_Image]] 
 
Note that you can also use/apply sub-textures and overlay/transform those arbitrarily - i.e. a lot of fancy stuff without having to know anything about effects or shaders :) 
 
You can also overlay individual images using the "z-index" attribute: [[Canvas_Element#z-index]] 
And then, you can basically do pretty much anything using the core Nasal APIs documented at: [[Canvas_Nasal_API]] 
To adjust transparency, you'll want to use the alpha channel. 
 
To animate the livery/texture, you'd basically use a timer/listener to change the texture's canvas property tree - i.e. by hiding/showing some sub-texture, or transforming groups/elements.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| the whole method came up as an idea - this isn't currently being used anywhere as far as I know. But it would seem that we're mainly missing people who want to experiment a bit. 
Canvas was never designed for creating/modifying "liveries" obviously - but canvas is very good at one thing: creating/modifying arbitrary textures at run-time and adjusting pretty much arbitrary parameters by setting a few properties. 
 
Thus, I'd consider Canvas more like a "toolbox" whose tools may not be directly designed for this particular purpose, but which are sufficiently generic and which can still be used "creatively" - e.g. there are some things that are only possible per-canvas, and not per "element" (group, image, paths, text, map) - in such cases, you typically need to use a workaround by using multiple canvas and referencing them via the canvas:/// markup as another raster image. We used this method a few times to implement "workarounds" - so in general, the implementation is pretty generic and even "recursive". 
 
We don't currently have any support for effects/shaders in 3.2 (or git) - but whenever you add a canvas-based texture to any of your models, you're adding a layer of indirection - so while some static textures may not be easily changed at run-time in some C++ subsystems, Canvas is all about managing dynamic textures - which in turn may consist of static textures (or variations of those).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
|I don't know if we have placement-related docs anywhere, but you could take a look at any aircraft using a dynamic Canvas-based texture, the c172p-canvas should be a fairly lighweight example compared to the 777/747 probably
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217722#p217722
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

{{FGCquote
| I guess with some more feedback/brainstorming, we can probably explore and see what's possible already, and what might be missing to support this particular "livery" use-case in the most generic fashion. Like I said, support for shaders/effects is relatively straightforward to add - Tom and I both have experimental code doing this kind of thing (per canvas only here) -and this would be useful for other purposes, too (think FLIR/night vision support etc).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=217737#p217737
|title=<nowiki>Re: Two Images to a Texture</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Sep 03</nowiki>
}}
}}

== Proof of Concept ==
To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt steaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

''This section will be updated as the implementation continues.''

=== Model Work ===
[[File:EF2000-canvas.ac in Blender.jpg|400px|right|EF2000-canvas.ac in Blender, showing the Texture allocations thus far]]
To start with, I cloned the EF2000's model and made a copy called "EF2000-canvas.ac", cloned the model XML file in the same way, and changed the paths appropriately to create a completely separate model for this experiment. The model objects which will be subject to the dynamic effects - effectively, the painted surfaces - were isolated from items like the canopy glass, gear and engines and given the same material, named '''CanvasPaint''' and consisting of an image texture: a livery in Air Superiority Grey but without the dirt layer already included. My first experiment will be to create a canvas and try to apply it to the mesh.

File:EF2000-canvas.ac in Blender.jpg

2014-09-17T17:01:08Z

Algernon: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=An illustration of the materials settings in Blender to prepare the airframe for a dynamic Canvas-driven livery}}
|date=2014-09-17 18:59:34
|source={{own}}
|author=[[User:Algernon|Algernon]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-3.0}}

FlightGear Newsletter August 2014

2014-08-20T02:49:32Z

Algernon: /* Eurofighter EF2000 */

{{Newsletter-header|August 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|3.2 Released}} 
{{Newsletter-cover-header|Development news}} 
{{Newsletter-cover-item|FGCamera 1.0 Released}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery corner}} 
{{Newsletter-cover-item|Yongphulla Domestic Airport - VQ10}} 
{{Newsletter-cover-header|Other}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}} 
{{Newsletter-cover-item|Beechcraft B1900D template}} 
{{Newsletter-cover-header|Multiplayer events}} 
|}
</div>
==3.2 Released==
The FlightGear development team is delighted to announce that the long awaited v3.2 release of FlightGear, the free, open-source flight simulator has been released on  INSERT FINAL RELEASE DATE HERE. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include ...

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

FlightGear features more than 400 aircraft, a worldwide scenery database, a multi-player environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

Download FlightGear v3.2 for free from [http://www.flightgear.org FlightGear.org]

FlightGear - Fly Free!
''Read more at: [[Next Changelog|Version 3.2 Changelog]]''

==Development news==
===FGCamera 1.0 Released===
{{#ev:youtube|DMZB7QXpR9I|250|right|FGCamera v1.0 in action}}
FGCamera v1.0 is available to download. Features of current version:
* 4 camera types:
** Virtual cockpit,
** Aircraft (look-at),
** Aircraft (look-from),
** World (look-from);
* Arbitrary number of preset views;
* Smooth/discrete transition between the views of the same camera type.

v1.0 has graphical user interface to create and manage camera views:

<gallery widths=200px heights=200px>
Fgcamera main dialog.jpg|Main dialog with cameras management tools.
Fgcamera new camera dialog.jpg|Dialog used to create new cameras. Four camera types are available
Fgcamera camera settings dialog.jpg|Settings for currently selected camera
</gallery>
Read more at updated [http://wiki.flightgear.org/FGCamera FGCamera wiki article].

==Scenery corner==
===Yongphulla Domestic Airport - VQ10===
High mountains, deep valleys, strong winds and sometimes the rain may appear as something like snow. You are at the bhutanese '''[[Yongphulla Airport|Yongphula Domestic Airport]]''' (VQ10) at a height of 2573 metres. After [[Paro Airport|Paro]], also this airport has been improved. Besides the Terminal and Apron, shared models and other little things have now been added. [[TerraSync]] has it all! Have a nice flight in the Kingdom of Bhutan.
<gallery mode=packed heights=240px>
VQ10 Yongphula Airport.jpg|Yonghula Airport
VQ10 Yongphula Apron.jpg|Tower and Terminal of Yongphula
</gallery>

==In the Hangar==
===Beechcraft B1900D template===
A new template for the [http://wiki.flightgear.org/Beechcraft_B1900D B1900D] is available in the [http://liveries.flightgear.org/paintkits.php Paintkits] section of the [http://liveries.flightgear.org/ flightgear liveries database website]. The template comes in svg format (best used with [http://www.inkscape.org inkscape]) features:
* full rivets, panel lines and stencils details in vector format
* ambient occlusion layer
* dirt layer
Some B1900d liveries made with this template are available to download in the [http://liveries.flightgear.org/aircraft.php?limit=25&display=2&page=0&id=21 flightgear liveries database website]

===Eurofighter EF2000===
{{#ev:youtube|_MaxljfrPBY||right|A brief in-cockpit demo of the EF2000's FCS}}
A big milestone has been achieved in the ongoing development of the EF2000, which I (Algernon) have been project managing since branching from the Eurofighter Typhoon project some years back: finally, after a lot of fiddling, a completely computerised Flight Control System which can simulate its real-life counterpart, with surface control fully autonomous and with an autopilot-based processor interpreting pilot input and commanding the system to fly its maximum performance envelope to obey, but not exceed safety or design limits. While a lot of these features are not yet implemented, we have established a working practice for the core system which allows extra elements to be introduced simply and effectively. I have heard it said that FG is incapable of simulating such systems, and I hope here we have proved otherwise, and, a bit self-indulgently, that maybe this will be the first truly fly-by-wire aircraft in FlightGear! (I am of course prepared to stand corrected there...)

Particular thanks for this objective go to StuartC, who designed the basis of the FDM, and Tomaskom, whose help in fields where I am not much of a master (like mathematics) has been invaluable. Many updates are planned for the EF2000, including a whole new custom paintjob with many liveries, and it is hoped a final, V2.0 release may be available in the later part of the year. You can also get hold of a pre-release copy if you visit the [http://fguk.eu/index.php/forum/index FGUK Forum] and register your interest, for testing purposes - your feedback will be appreciated. Pre-releases will probably not be available until at least September 2014.

Other points being addressed in the V2.0 release are:

* New modular Nasal approach and many new scripts. Upgraded to Eno audio management.
* New UV map for N-SCOT, leading to sexy new textures and liveries and hopefully a paintkit too
* Improvements to helmet-mounted display and HUD for improved navigation, target acquisition and weapons management
* Disintegration, explosion, real damage and real maintenance
* External lighting redesigned
* Experimental and deprecated code bumph removed

FlightGear Newsletter August 2014

2014-08-18T12:14:02Z

Algernon: /* In the Hangar */

{{Newsletter-header|August 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|3.2 Released}} 
{{Newsletter-cover-header|Development news}} 
{{Newsletter-cover-item|FGCamera 1.0 Released}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery corner}} 
{{Newsletter-cover-item|Yongphulla Domestic Airport - VQ10}} 
{{Newsletter-cover-header|Other}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}} 
{{Newsletter-cover-item|Beechcraft B1900D template}} 
{{Newsletter-cover-header|Multiplayer events}} 
|}
</div>
==3.2 Released==
The FlightGear development team is delighted to announce that the long awaited v3.2 release of FlightGear, the free, open-source flight simulator has been released on  INSERT FINAL RELEASE DATE HERE. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include ...

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

FlightGear features more than 400 aircraft, a worldwide scenery database, a multi-player environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

Download FlightGear v3.2 for free from [http://www.flightgear.org FlightGear.org]

FlightGear - Fly Free!
''Read more at: [[Next Changelog|Version 3.2 Changelog]]''

==Development news==
===FGCamera 1.0 Released===
{{#ev:youtube|DMZB7QXpR9I|250|right|FGCamera v1.0 in action}}
FGCamera v1.0 is available to download. Features of current version:
* 4 camera types:
** Virtual cockpit,
** Aircraft (look-at),
** Aircraft (look-from),
** World (look-from);
* Arbitrary number of preset views;
* Smooth/discrete transition between the views of the same camera type.

v1.0 has graphical user interface to create and manage camera views:

<gallery widths=200px heights=200px>
Fgcamera main dialog.jpg|Main dialog with cameras management tools.
Fgcamera new camera dialog.jpg|Dialog used to create new cameras. Four camera types are available
Fgcamera camera settings dialog.jpg|Settings for currently selected camera
</gallery>
Read more at updated [http://wiki.flightgear.org/FGCamera FGCamera wiki article].

==Scenery corner==
===Yongphulla Domestic Airport - VQ10===
High mountains, deep valleys, strong winds and sometimes the rain may appear as something like snow. You are at the bhutanese '''[[Yongphulla Airport|Yongphula Domestic Airport]]''' (VQ10) at a height of 2573 metres. After [[Paro Airport|Paro]], also this airport has been improved. Besides the Terminal and Apron, shared models and other little things have now been added. [[TerraSync]] has it all! Have a nice flight in the Kingdom of Bhutan.
<gallery mode=packed heights=240px>
VQ10 Yongphula Airport.jpg|Yonghula Airport
VQ10 Yongphula Apron.jpg|Tower and Terminal of Yongphula
</gallery>

==In the Hangar==
===Beechcraft B1900D template===
A new template for the [http://wiki.flightgear.org/Beechcraft_B1900D B1900D] is available in the [http://liveries.flightgear.org/paintkits.php Paintkits] section of the [http://liveries.flightgear.org/ flightgear liveries database website]. The template comes in svg format (best used with [http://www.inkscape.org inkscape]) features:
* full rivets, panel lines and stencils details in vector format
* ambient occlusion layer
* dirt layer
Some B1900d liveries made with this template are available to download in the [http://liveries.flightgear.org/aircraft.php?limit=25&display=2&page=0&id=21 flightgear liveries database website]

===Eurofighter EF2000===
{{#ev:youtube|_MaxljfrPBY||right|A brief in-cockpit demo of the EF2000's FCS}}
A big milestone has been achieved in the ongoing development of the EF2000, which FGUK's Algernon has been project managing since branching from the Eurofighter Typhoon project some years back: finally, a completely computerised Flight Control System which can simulate its real-life counterpart, with surface control fully autonomous and with an autopilot-based processor interpreting pilot input and commanding the system to fly its maximum performance envelope to obey, but not exceed safety or design limits. While a lot of these features are not yet implemented, we have established a working practice for the core system which allows extra elements to be introduced simply and effectively. I have heard it said that FG is incapable of simluating such systems - I hope here we have proved otherwise, and indeed that maybe this will be the first truly fly-by-wire aircraft in FlightGear!

Particular thanks for this milestone go to StuartC, who designed the basis of the FDM, and Tomaskom, whose help in fields where I am not much of a master (like mathematics) has been invaluable. Many updates are planned for the EF2000, including a whole new custom paintjob with many liveries, and it is hoped a final, V2.0 release may be available in the later part of the year. You can also get hold of a pre-release copy if you visit the [http://fguk.eu/index.php/forum/index FGUK Forum] and register your interest, for testing purposes - your feedback will be appreciated. Pre-releases will probably not be available until at least September 2014.

Other points being addressed in the V2.0 release are:

* New modular Nasal approach and many new scripts. Upgraded to Eno audio management.
* New UV map for N-SCOT, leading to sexy new textures and liveries and hopefully a paintkit too
* Improvements to helmet-mounted display and HUD for improved navigation, target acquisition and weapons management
* Disintegration, explosion, real damage and real maintenance
* External lighting redesigned
* Experimental and deprecated code bumph removed

FlightGear Newsletter August 2014

2014-08-18T12:10:25Z

Algernon: /* In the Hangar */

{{Newsletter-header|August 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|3.2 Released}} 
{{Newsletter-cover-header|Development news}} 
{{Newsletter-cover-item|FGCamera 1.0 Released}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery corner}} 
{{Newsletter-cover-item|Yongphulla Domestic Airport - VQ10}} 
{{Newsletter-cover-header|Other}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}} 
{{Newsletter-cover-item|Beechcraft B1900D template}} 
{{Newsletter-cover-header|Multiplayer events}} 
|}
</div>
==3.2 Released==
The FlightGear development team is delighted to announce that the long awaited v3.2 release of FlightGear, the free, open-source flight simulator has been released on  INSERT FINAL RELEASE DATE HERE. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include ...

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

FlightGear features more than 400 aircraft, a worldwide scenery database, a multi-player environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

Download FlightGear v3.2 for free from [http://www.flightgear.org FlightGear.org]

FlightGear - Fly Free!
''Read more at: [[Next Changelog|Version 3.2 Changelog]]''

==Development news==
===FGCamera 1.0 Released===
{{#ev:youtube|DMZB7QXpR9I|250|right|FGCamera v1.0 in action}}
FGCamera v1.0 is available to download. Features of current version:
* 4 camera types:
** Virtual cockpit,
** Aircraft (look-at),
** Aircraft (look-from),
** World (look-from);
* Arbitrary number of preset views;
* Smooth/discrete transition between the views of the same camera type.

v1.0 has graphical user interface to create and manage camera views:

<gallery widths=200px heights=200px>
Fgcamera main dialog.jpg|Main dialog with cameras management tools.
Fgcamera new camera dialog.jpg|Dialog used to create new cameras. Four camera types are available
Fgcamera camera settings dialog.jpg|Settings for currently selected camera
</gallery>
Read more at updated [http://wiki.flightgear.org/FGCamera FGCamera wiki article].

==Scenery corner==
===Yongphulla Domestic Airport - VQ10===
High mountains, deep valleys, strong winds and sometimes the rain may appear as something like snow. You are at the bhutanese '''[[Yongphulla Airport|Yongphula Domestic Airport]]''' (VQ10) at a height of 2573 metres. After [[Paro Airport|Paro]], also this airport has been improved. Besides the Terminal and Apron, shared models and other little things have now been added. [[TerraSync]] has it all! Have a nice flight in the Kingdom of Bhutan.
<gallery mode=packed heights=240px>
VQ10 Yongphula Airport.jpg|Yonghula Airport
VQ10 Yongphula Apron.jpg|Tower and Terminal of Yongphula
</gallery>

==In the Hangar==
===Beechcraft B1900D template===
A new template for the [http://wiki.flightgear.org/Beechcraft_B1900D B1900D] is available in the [http://liveries.flightgear.org/paintkits.php Paintkits] section of the [http://liveries.flightgear.org/ flightgear liveries database website]. The template comes in svg format (best used with [http://www.inkscape.org inkscape]) features:
* full rivets, panel lines and stencils details in vector format
* ambient occlusion layer
* dirt layer
Some B1900d liveries made with this template are available to download in the [http://liveries.flightgear.org/aircraft.php?limit=25&display=2&page=0&id=21 flightgear liveries database website]

===Eurofighter EF2000===
{{#ev:youtube|_MaxljfrPBY||right|A brief in-cockpit demo of the EF2000's FCS}}
A big milestone has been achieved in the ongoing development of the EF2000, which FGUK's Algernon has been project managing since branching from the Eurofighter Typhoon project some years back: finally, a completely computerised Flight Control System which can simulate its real-life counterpart, with surface control fully autonomous and with an autopilot-based processor interpreting pilot input and commanding the system to fly its maximum performance envelope to obey, but not exceed safety or design limits. While a lot of these features are not yet implemented, we have established a working practice for the core system which allows extra elements to be introduced simply and effectively.

I have heard it said that FG is incapable of simluating such systems - I hope here we have proved otherwise, and indeed that maybe this will be the first truly fly-by-wire aircraft in FlightGear!

Particular thanks for this milestone go to StuartC, who designed the basis of the FDM, and Tomaskom, whose help in fields where I am not much of a master (like mathematics) has been invaluable. Many updates are planned for the EF2000, including a whole new custom paintjob with many liveries, and it is hoped a final, V2.0 release may be available in the later part of the year. You can also get hold of a pre-release copy if you visit the [http://fguk.eu/index.php/forum/index FGUK Forum] and register your interest, for testing purposes - your feedback will be appreciated. Pre-releases will probably not be available until at least September 2014.

FlightGear Newsletter July 2014

2014-08-01T22:40:55Z

Algernon: /* FGUK Mach Loop Challenge */

{{Newsletter being written}}

== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

{{FGCquote
|Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. 
 
'''Possible things to write about could be:''' 
- New planes that are released. 
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). 
- New FG releases (this is not very often, but it should be in the letter if so). 
- New forum features/subforums and other news from the forum. 
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) 
- Events that will be held within a short periode or (links to) screenshots of the latest event(s). 
- The first 3 or 5 pictures of a screenshot contest. 
 
If you got other idea's, post in this topic so we could extend the list. 
I don't really know what's best way to provide the letter. But we have some options: 
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). 
- emails send to all forum-users (I don't really like this myself). 
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org] 
- or even something else 
 
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
|title=<nowiki>Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. 
 
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? 
 
But if you are willing to get a newsletter rolling, that would be awsome.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>curt</nowiki>
|date=<nowiki>Tue May 27</nowiki>
}}
}}

{{FGCquote
|Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>MaverickAlex</nowiki>
|date=<nowiki>Thu May 29</nowiki>
}}
}}

{{FGCquote
|Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Thu Aug 21</nowiki>
}}
}}

{{FGCquote
|Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? 
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Oct 03</nowiki>
}}
}}

== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.

For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes). 
 
(see the [http://i.imgur.com/dqMzBS4.png linked image])
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
|title=<nowiki>Re: osgText backdrop</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon Jul 07</nowiki>
}}
}}

<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date: Mon Jul 7 18:26:16 2014 +0200

Canvas: add backdrop option to text

diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
void setLineHeight(float factor);
void setFill(const std::string& fill);
void setBackgroundColor(const std::string& fill);
+ void setOutlineColor(const std::string& backdrop);

SGVec2i sizeForWidth(int w) const;
osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
}

//----------------------------------------------------------------------------
+ void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+ {
+ osg::Vec4 color;
+ setBackdropType(osgText::Text::OUTLINE);
+ if( parseColor(backdrop, color) )
+ setBackdropColor( color );
+ }
+
+ //----------------------------------------------------------------------------
// simplified version of osgText::Text::computeGlyphRepresentation() to
// just calculate the size for a given weight. Glpyh calculations/creating
// is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas

addStyle("fill", "color", &TextOSG::setFill, text);
addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+ addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
addStyle("character-size",
"numeric",
static_cast<
</syntaxhighlight>

<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date: Mon Jul 7 18:27:50 2014 +0200

Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {

setColorFill: func me.set('background', _getColor(arg)),
getColorFill: func me.get('background'),
+
+ setBackdropColor: func me.set('backdrop', _getColor(arg)),
};

# Path
</syntaxhighlight>

== FGCanvas Updates ==
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
|Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: 
 
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. 
 
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - 
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than 
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

The whole discussion dates back to the early FGPanel days:

{{FGCquote
|I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
|title=<nowiki>Re: FSWeekend 2010</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Tue Nov 02</nowiki>
}}
}}

{{FGCquote
|Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: 
 
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: 
 
[[FGCanvas]] 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]] 
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: 
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". 
 
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
|title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

=== A Canvas based GNS 530 GPS ===
{{FGCquote
|After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this: 
 
[[File:Gns530-prototype-07-2014.png|300px]]
 
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of. 
 
Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. Still, I think it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]]...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215254#p215254
|title=<nowiki>Garmin gns530</nowiki>
|author=<nowiki>cbendele</nowiki>
|date=<nowiki>Wed Jul 23</nowiki>
}}
}}

=== Nasal: Making safer base-class calls ===
There's a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:

<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>

To pass a custom namespace environment, you can use this:

<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>

Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>

You can also declare the variable expression inline:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>

== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Upcoming version (FGCamera v1) will have new camera mode: "world-view".

{{#ev:youtube|hebx8WdXHa0}}

== Scenery corner ==
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
{{-}}
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]]]
Programming in Nasal on Windows can now be a lot friendlier with [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]. 
Provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion. 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
{{-}}

== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in Fligthgear. There are currently 4 Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
{{-}}

== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. 
It all began as a question about a parachute which ended by brainstorming of the best approach, you can read the related thread here: 
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim 
 
Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see [http://forum.flightgear.org/viewtopic.php?f=49&p=215650&sid=97b2010406d31b6fc2fabc7cf8b1c8f8 Parachute for YASim (Thrusters & Nasal)]. 
Currently there is a reference implementation in a special version of the V-1 flying bomb: 
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb 
The drone (Firebee) for which the parachute was requested is not yet publicly available. 
You can also get an idea of it's stabilization properties from this video: 
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi
{{-}}

== In the hangar ==
=== Mainair Flash 2 Alpha ===
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
[[File:Flash2a_in_Air2.png|400px]]

=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM||right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations. 
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: 
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
{{-}}

== Multiplayer Events ==
=== FGUK Mach Loop Challenge ===
'' Saturday 9th August 2014 - Llanbedr Airfield (EGOD) - 1900 G/U/Z''
{{-}}
{{#ev:youtube|XK0Y1sfijLY||right|A trip around the loop with the Vulcan B2}}
[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. The world-famous low flying route in North Wales, on the doorstep of FGUK's Llanbedr headquarters, is a 26 mile course threading the valleys and hills around Machynlleth. Can you consistently lower your time and beat the other pilots around the course without breaking the sound barrier and startling the sheep?

A custom AI scenario displays the route with fly-through pointers, checks for adherence to the rules, and announces and records your time - just hand in your score file, and you will be included in the results when published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and [https://twitter.com/FlightGearUK Twitter account]. As always at the Mach Loop, there will be photography and video and the event will be streamed live on our [https://www.youtube.com/channel/UCBb-2WXJuAOVh8QvsdVNrrQ YouTube channel].

Recommended choices to fly the loop competitively are Supersonic single and twin seaters, but you can bring anything within reason that doesn't make you a danger to others. Assemble at FGUK Llanbedr (EGOD) at 1900 G/U/Z (8pm BST). If you're planning to bring something unusual, we ask you to notify us in the forum to make sure all the models are visible to the camera.

A full briefing for pilots will be published on Sunday, along with the definitive AI scenario for the competition. Check the [http://fguk.eu/index.php/12-flight-articles/saturday-flight-articles/21-saturday-9th-august-mach-loop-challenge ongoing event article] and the [http://fguk.eu/index.php/forum/saturday-night-flying/4659-flightnight-9-8-14-mach-loop-challenge?start=40#16865 forum thread] to keep up to date.

FlightGear Newsletter July 2014

2014-08-01T22:35:24Z

Algernon: /* Multiplayer Events */

{{Newsletter being written}}

== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

{{FGCquote
|Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. 
 
'''Possible things to write about could be:''' 
- New planes that are released. 
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). 
- New FG releases (this is not very often, but it should be in the letter if so). 
- New forum features/subforums and other news from the forum. 
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) 
- Events that will be held within a short periode or (links to) screenshots of the latest event(s). 
- The first 3 or 5 pictures of a screenshot contest. 
 
If you got other idea's, post in this topic so we could extend the list. 
I don't really know what's best way to provide the letter. But we have some options: 
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). 
- emails send to all forum-users (I don't really like this myself). 
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org] 
- or even something else 
 
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
|title=<nowiki>Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. 
 
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? 
 
But if you are willing to get a newsletter rolling, that would be awsome.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>curt</nowiki>
|date=<nowiki>Tue May 27</nowiki>
}}
}}

{{FGCquote
|Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>MaverickAlex</nowiki>
|date=<nowiki>Thu May 29</nowiki>
}}
}}

{{FGCquote
|Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Thu Aug 21</nowiki>
}}
}}

{{FGCquote
|Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? 
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Oct 03</nowiki>
}}
}}

== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.

For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes). 
 
(see the [http://i.imgur.com/dqMzBS4.png linked image])
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
|title=<nowiki>Re: osgText backdrop</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon Jul 07</nowiki>
}}
}}

<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date: Mon Jul 7 18:26:16 2014 +0200

Canvas: add backdrop option to text

diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
void setLineHeight(float factor);
void setFill(const std::string& fill);
void setBackgroundColor(const std::string& fill);
+ void setOutlineColor(const std::string& backdrop);

SGVec2i sizeForWidth(int w) const;
osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
}

//----------------------------------------------------------------------------
+ void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+ {
+ osg::Vec4 color;
+ setBackdropType(osgText::Text::OUTLINE);
+ if( parseColor(backdrop, color) )
+ setBackdropColor( color );
+ }
+
+ //----------------------------------------------------------------------------
// simplified version of osgText::Text::computeGlyphRepresentation() to
// just calculate the size for a given weight. Glpyh calculations/creating
// is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas

addStyle("fill", "color", &TextOSG::setFill, text);
addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+ addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
addStyle("character-size",
"numeric",
static_cast<
</syntaxhighlight>

<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date: Mon Jul 7 18:27:50 2014 +0200

Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {

setColorFill: func me.set('background', _getColor(arg)),
getColorFill: func me.get('background'),
+
+ setBackdropColor: func me.set('backdrop', _getColor(arg)),
};

# Path
</syntaxhighlight>

== FGCanvas Updates ==
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
|Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: 
 
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. 
 
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - 
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than 
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

The whole discussion dates back to the early FGPanel days:

{{FGCquote
|I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
|title=<nowiki>Re: FSWeekend 2010</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Tue Nov 02</nowiki>
}}
}}

{{FGCquote
|Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: 
 
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: 
 
[[FGCanvas]] 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]] 
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: 
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". 
 
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
|title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

=== A Canvas based GNS 530 GPS ===
{{FGCquote
|After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this: 
 
[[File:Gns530-prototype-07-2014.png|300px]]
 
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of. 
 
Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. Still, I think it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]]...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215254#p215254
|title=<nowiki>Garmin gns530</nowiki>
|author=<nowiki>cbendele</nowiki>
|date=<nowiki>Wed Jul 23</nowiki>
}}
}}

=== Nasal: Making safer base-class calls ===
There's a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:

<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>

To pass a custom namespace environment, you can use this:

<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>

Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>

You can also declare the variable expression inline:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>

== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Upcoming version (FGCamera v1) will have new camera mode: "world-view".

{{#ev:youtube|hebx8WdXHa0}}

== Scenery corner ==
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
{{-}}
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]]]
Programming in Nasal on Windows can now be a lot friendlier with [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]. 
Provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion. 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
{{-}}

== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in Fligthgear. There are currently 4 Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
{{-}}

== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. 
It all began as a question about a parachute which ended by brainstorming of the best approach, you can read the related thread here: 
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim 
 
Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see [http://forum.flightgear.org/viewtopic.php?f=49&p=215650&sid=97b2010406d31b6fc2fabc7cf8b1c8f8 Parachute for YASim (Thrusters & Nasal)]. 
Currently there is a reference implementation in a special version of the V-1 flying bomb: 
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb 
The drone (Firebee) for which the parachute was requested is not yet publicly available. 
You can also get an idea of it's stabilization properties from this video: 
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi
{{-}}

== In the hangar ==
=== Mainair Flash 2 Alpha ===
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
[[File:Flash2a_in_Air2.png|400px]]

=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM||right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations. 
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: 
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
{{-}}

== Multiplayer Events ==
=== FGUK Mach Loop Challenge ===
'' Saturday 9th August 2014 - Llanbedr Airfield (EGOD) - 1900 G/U/Z''
{{-}}

[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. The world-famous low flying route in North Wales, on the doorstep of FGUK's Llanbedr headquarters, is a 26 mile course threading the valleys and hills around Machynlleth. Can you consistently lower your time and beat the other pilots around the course without breaking the sound barrier and startling the sheep?

A custom AI scenario displays the route with fly-through pointers, checks for adherence to the rules, and announces and records your time - the results will be published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and [https://twitter.com/FlightGearUK Twitter account]. As always at the Mach Loop, there will be photography and video and the event will be streamed live on our [https://www.youtube.com/channel/UCBb-2WXJuAOVh8QvsdVNrrQ YouTube channel].

Recommended choices to fly the loop competitively are Supersonic single and twin seaters, but you can bring anything within reason that doesn't make you a danger to others. Assemble at FGUK Llanbedr (EGOD) at 1900 G/U/Z (8pm BST). If you're planning to bring something unusual, we ask you to notify us in the forum to make sure all the models are visible to the camera.

A full briefing for pilots will be published on Sunday, along with the definitive AI scenario for the competition. Check the [http://fguk.eu/index.php/12-flight-articles/saturday-flight-articles/21-saturday-9th-august-mach-loop-challenge ongoing event article] and the [http://fguk.eu/index.php/forum/saturday-night-flying/4659-flightnight-9-8-14-mach-loop-challenge?start=40#16865 forum thread] to keep up to date.

FlightGear Newsletter July 2014

2014-08-01T22:31:20Z

Algernon: /* Multiplayer Events */

{{Newsletter being written}}

== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

{{FGCquote
|Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. 
 
'''Possible things to write about could be:''' 
- New planes that are released. 
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). 
- New FG releases (this is not very often, but it should be in the letter if so). 
- New forum features/subforums and other news from the forum. 
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) 
- Events that will be held within a short periode or (links to) screenshots of the latest event(s). 
- The first 3 or 5 pictures of a screenshot contest. 
 
If you got other idea's, post in this topic so we could extend the list. 
I don't really know what's best way to provide the letter. But we have some options: 
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). 
- emails send to all forum-users (I don't really like this myself). 
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org] 
- or even something else 
 
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
|title=<nowiki>Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. 
 
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? 
 
But if you are willing to get a newsletter rolling, that would be awsome.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>curt</nowiki>
|date=<nowiki>Tue May 27</nowiki>
}}
}}

{{FGCquote
|Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>MaverickAlex</nowiki>
|date=<nowiki>Thu May 29</nowiki>
}}
}}

{{FGCquote
|Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Thu Aug 21</nowiki>
}}
}}

{{FGCquote
|Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? 
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Oct 03</nowiki>
}}
}}

== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.

For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes). 
 
(see the [http://i.imgur.com/dqMzBS4.png linked image])
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
|title=<nowiki>Re: osgText backdrop</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon Jul 07</nowiki>
}}
}}

<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date: Mon Jul 7 18:26:16 2014 +0200

Canvas: add backdrop option to text

diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
void setLineHeight(float factor);
void setFill(const std::string& fill);
void setBackgroundColor(const std::string& fill);
+ void setOutlineColor(const std::string& backdrop);

SGVec2i sizeForWidth(int w) const;
osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
}

//----------------------------------------------------------------------------
+ void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+ {
+ osg::Vec4 color;
+ setBackdropType(osgText::Text::OUTLINE);
+ if( parseColor(backdrop, color) )
+ setBackdropColor( color );
+ }
+
+ //----------------------------------------------------------------------------
// simplified version of osgText::Text::computeGlyphRepresentation() to
// just calculate the size for a given weight. Glpyh calculations/creating
// is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas

addStyle("fill", "color", &TextOSG::setFill, text);
addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+ addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
addStyle("character-size",
"numeric",
static_cast<
</syntaxhighlight>

<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date: Mon Jul 7 18:27:50 2014 +0200

Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {

setColorFill: func me.set('background', _getColor(arg)),
getColorFill: func me.get('background'),
+
+ setBackdropColor: func me.set('backdrop', _getColor(arg)),
};

# Path
</syntaxhighlight>

== FGCanvas Updates ==
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
|Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: 
 
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. 
 
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - 
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than 
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

The whole discussion dates back to the early FGPanel days:

{{FGCquote
|I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
|title=<nowiki>Re: FSWeekend 2010</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Tue Nov 02</nowiki>
}}
}}

{{FGCquote
|Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: 
 
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: 
 
[[FGCanvas]] 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]] 
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: 
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". 
 
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
|title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

=== A Canvas based GNS 530 GPS ===
{{FGCquote
|After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this: 
 
[[File:Gns530-prototype-07-2014.png|300px]]
 
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of. 
 
Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. Still, I think it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]]...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215254#p215254
|title=<nowiki>Garmin gns530</nowiki>
|author=<nowiki>cbendele</nowiki>
|date=<nowiki>Wed Jul 23</nowiki>
}}
}}

=== Nasal: Making safer base-class calls ===
There's a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:

<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>

To pass a custom namespace environment, you can use this:

<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>

Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>

You can also declare the variable expression inline:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>

== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Upcoming version (FGCamera v1) will have new camera mode: "world-view".

{{#ev:youtube|hebx8WdXHa0}}

== Scenery corner ==
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
{{-}}
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]]]
Programming in Nasal on Windows can now be a lot friendlier with [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]. 
Provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion. 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
{{-}}

== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in Fligthgear. There are currently 4 Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
{{-}}

== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. 
It all began as a question about a parachute which ended by brainstorming of the best approach, you can read the related thread here: 
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim 
 
Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see [http://forum.flightgear.org/viewtopic.php?f=49&p=215650&sid=97b2010406d31b6fc2fabc7cf8b1c8f8 Parachute for YASim (Thrusters & Nasal)]. 
Currently there is a reference implementation in a special version of the V-1 flying bomb: 
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb 
The drone (Firebee) for which the parachute was requested is not yet publicly available. 
You can also get an idea of it's stabilization properties from this video: 
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi
{{-}}

== In the hangar ==
=== Mainair Flash 2 Alpha ===
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
[[File:Flash2a_in_Air2.png|400px]]

=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM||right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations. 
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: 
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
{{-}}

== Multiplayer Events ==
[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. The world-famous low flying route in North Wales, on the doorstep of FGUK's Llanbedr headquarters, is a 26 mile course threading the valleys and hills around Machynlleth. Can you consistently lower your time and beat the other pilots around the course without breaking the sound barrier and startling the sheep?

A custom AI scenario displays the route with fly-through pointers, checks for adherence to the rules, and announces and records your time - the results will be published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and [https://twitter.com/FlightGearUK Twitter account]. As always at the Mach Loop, there will be photography and video and the event will be streamed live on our [https://www.youtube.com/channel/UCBb-2WXJuAOVh8QvsdVNrrQ YouTube channel].

Recommended choices to fly the loop competitively are Supersonic single and twin seaters, but you can bring anything within reason that doesn't make you a danger to others. Assemble at FGUK Llanbedr (EGOD) at 1900 G/U/Z (8pm BST). If you're planning to bring something unusual, we ask you to notify us in the forum to make sure all the models are visible to the camera.

A full briefing for pilots will be published on Sunday, along with the definitive AI scenario for the competition. Check the [http://fguk.eu/index.php/12-flight-articles/saturday-flight-articles/21-saturday-9th-august-mach-loop-challenge ongoing event article] and the [http://fguk.eu/index.php/forum/saturday-night-flying/4659-flightnight-9-8-14-mach-loop-challenge?start=40#16865 forum thread] to keep up to date.

FlightGear Newsletter July 2014

2014-08-01T19:56:21Z

Algernon: /* Multiplayer Events */

{{Newsletter being written}}

== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

{{FGCquote
|Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. 
 
'''Possible things to write about could be:''' 
- New planes that are released. 
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). 
- New FG releases (this is not very often, but it should be in the letter if so). 
- New forum features/subforums and other news from the forum. 
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) 
- Events that will be held within a short periode or (links to) screenshots of the latest event(s). 
- The first 3 or 5 pictures of a screenshot contest. 
 
If you got other idea's, post in this topic so we could extend the list. 
I don't really know what's best way to provide the letter. But we have some options: 
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). 
- emails send to all forum-users (I don't really like this myself). 
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org] 
- or even something else 
 
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
|title=<nowiki>Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. 
 
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? 
 
But if you are willing to get a newsletter rolling, that would be awsome.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>curt</nowiki>
|date=<nowiki>Tue May 27</nowiki>
}}
}}

{{FGCquote
|Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>MaverickAlex</nowiki>
|date=<nowiki>Thu May 29</nowiki>
}}
}}

{{FGCquote
|Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Thu Aug 21</nowiki>
}}
}}

{{FGCquote
|Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? 
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Oct 03</nowiki>
}}
}}

== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.

For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes). 
 
(see the [http://i.imgur.com/dqMzBS4.png linked image])
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
|title=<nowiki>Re: osgText backdrop</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon Jul 07</nowiki>
}}
}}

<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date: Mon Jul 7 18:26:16 2014 +0200

Canvas: add backdrop option to text

diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
void setLineHeight(float factor);
void setFill(const std::string& fill);
void setBackgroundColor(const std::string& fill);
+ void setOutlineColor(const std::string& backdrop);

SGVec2i sizeForWidth(int w) const;
osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
}

//----------------------------------------------------------------------------
+ void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+ {
+ osg::Vec4 color;
+ setBackdropType(osgText::Text::OUTLINE);
+ if( parseColor(backdrop, color) )
+ setBackdropColor( color );
+ }
+
+ //----------------------------------------------------------------------------
// simplified version of osgText::Text::computeGlyphRepresentation() to
// just calculate the size for a given weight. Glpyh calculations/creating
// is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas

addStyle("fill", "color", &TextOSG::setFill, text);
addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+ addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
addStyle("character-size",
"numeric",
static_cast<
</syntaxhighlight>

<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date: Mon Jul 7 18:27:50 2014 +0200

Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {

setColorFill: func me.set('background', _getColor(arg)),
getColorFill: func me.get('background'),
+
+ setBackdropColor: func me.set('backdrop', _getColor(arg)),
};

# Path
</syntaxhighlight>

== FGCanvas Updates ==
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
|Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: 
 
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. 
 
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - 
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than 
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

The whole discussion dates back to the early FGPanel days:

{{FGCquote
|I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
|title=<nowiki>Re: FSWeekend 2010</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Tue Nov 02</nowiki>
}}
}}

{{FGCquote
|Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: 
 
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: 
 
[[FGCanvas]] 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]] 
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: 
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". 
 
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
|title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

=== A Canvas based GNS 530 GPS ===
{{FGCquote
|After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this: 
 
[[File:Gns530-prototype-07-2014.png|300px]]
 
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of. 
 
Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. Still, I think it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]]...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215254#p215254
|title=<nowiki>Garmin gns530</nowiki>
|author=<nowiki>cbendele</nowiki>
|date=<nowiki>Wed Jul 23</nowiki>
}}
}}

=== Nasal: Making safer base-class calls ===
There's a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:

<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>

To pass a custom namespace environment, you can use this:

<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>

Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>

You can also declare the variable expression inline:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>

== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Upcoming version (FGCamera v1) will have new camera mode: "world-view".

{{#ev:youtube|hebx8WdXHa0}}

== Scenery corner ==
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
{{-}}
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]]]
Programming in Nasal on Windows can now be a lot friendlier with [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]. 
Provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion. 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
{{-}}

== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in Fligthgear. There are currently 4 Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
{{-}}

== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. 
It all began as a question about a parachute which ended by brainstorming of the best approach, you can read the related thread here: 
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim 
 
Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see [http://forum.flightgear.org/viewtopic.php?f=49&p=215650&sid=97b2010406d31b6fc2fabc7cf8b1c8f8 Parachute for YASim (Thrusters & Nasal)]. 
Currently there is a reference implementation in a special version of the V-1 flying bomb: 
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb 
The drone (Firebee) for which the parachute was requested is not yet publicly available. 
You can also get an idea of it's stabilization properties from this video: 
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi
{{-}}

== In the hangar ==
=== Mainair Flash 2 Alpha ===
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
[[File:Flash2a_in_Air2.png|400px]]

=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM||right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations. 
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: 
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
{{-}}

== Multiplayer Events ==
[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. The world-famous low flying route in North Wales, on the doorstep of FGUK's Llanbedr headquarters, is a 26 mile course threading the valleys and hills around Machynlleth. Can you consistently lower your time and beat the other pilots around the course without breaking the sound barrier and startling the sheep?

A custom AI scenario displays the route with fly-through pointers, checks for adherence to the rules, and announces and records your time - the results will be published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and [https://twitter.com/FlightGearUK Twitter account]. As always at the Mach Loop, there will be photography and video and the event will be streamed live on our [https://www.youtube.com/channel/UCBb-2WXJuAOVh8QvsdVNrrQ YouTube channel].

Recommended choices to fly the loop competitively are Supersonic single and twin seaters, but you can bring anything within reason that doesn't make you a danger to others. Assemble at FGUK Llanbedr (EGOD) at 1900 G/U/Z (8pm BST). If you're planning to bring something unusual, we ask you to notify us in the forum to make sure all the models are visible to the camera.

FlightGear Newsletter July 2014

2014-08-01T19:35:21Z

Algernon: /* Multiplayer Events */

{{Newsletter being written}}

== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

{{FGCquote
|Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. 
 
'''Possible things to write about could be:''' 
- New planes that are released. 
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). 
- New FG releases (this is not very often, but it should be in the letter if so). 
- New forum features/subforums and other news from the forum. 
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) 
- Events that will be held within a short periode or (links to) screenshots of the latest event(s). 
- The first 3 or 5 pictures of a screenshot contest. 
 
If you got other idea's, post in this topic so we could extend the list. 
I don't really know what's best way to provide the letter. But we have some options: 
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). 
- emails send to all forum-users (I don't really like this myself). 
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org] 
- or even something else 
 
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
|title=<nowiki>Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. 
 
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? 
 
But if you are willing to get a newsletter rolling, that would be awsome.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>curt</nowiki>
|date=<nowiki>Tue May 27</nowiki>
}}
}}

{{FGCquote
|Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>MaverickAlex</nowiki>
|date=<nowiki>Thu May 29</nowiki>
}}
}}

{{FGCquote
|Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Thu Aug 21</nowiki>
}}
}}

{{FGCquote
|Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? 
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Oct 03</nowiki>
}}
}}

== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.

For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes). 
 
(see the [http://i.imgur.com/dqMzBS4.png linked image])
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
|title=<nowiki>Re: osgText backdrop</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon Jul 07</nowiki>
}}
}}

<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date: Mon Jul 7 18:26:16 2014 +0200

Canvas: add backdrop option to text

diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
void setLineHeight(float factor);
void setFill(const std::string& fill);
void setBackgroundColor(const std::string& fill);
+ void setOutlineColor(const std::string& backdrop);

SGVec2i sizeForWidth(int w) const;
osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
}

//----------------------------------------------------------------------------
+ void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+ {
+ osg::Vec4 color;
+ setBackdropType(osgText::Text::OUTLINE);
+ if( parseColor(backdrop, color) )
+ setBackdropColor( color );
+ }
+
+ //----------------------------------------------------------------------------
// simplified version of osgText::Text::computeGlyphRepresentation() to
// just calculate the size for a given weight. Glpyh calculations/creating
// is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas

addStyle("fill", "color", &TextOSG::setFill, text);
addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+ addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
addStyle("character-size",
"numeric",
static_cast<
</syntaxhighlight>

<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date: Mon Jul 7 18:27:50 2014 +0200

Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {

setColorFill: func me.set('background', _getColor(arg)),
getColorFill: func me.get('background'),
+
+ setBackdropColor: func me.set('backdrop', _getColor(arg)),
};

# Path
</syntaxhighlight>

== FGCanvas Updates ==
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
|Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: 
 
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. 
 
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - 
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than 
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

The whole discussion dates back to the early FGPanel days:

{{FGCquote
|I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
|title=<nowiki>Re: FSWeekend 2010</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Tue Nov 02</nowiki>
}}
}}

{{FGCquote
|Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: 
 
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: 
 
[[FGCanvas]] 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]] 
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: 
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". 
 
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
|title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

=== A Canvas based GNS 530 GPS ===
{{FGCquote
|After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this: 
 
[[File:Gns530-prototype-07-2014.png|300px]]
 
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of. 
 
Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. Still, I think it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]]...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215254#p215254
|title=<nowiki>Garmin gns530</nowiki>
|author=<nowiki>cbendele</nowiki>
|date=<nowiki>Wed Jul 23</nowiki>
}}
}}

=== Nasal: Making safer base-class calls ===
There's a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:

<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>

To pass a custom namespace environment, you can use this:

<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>

Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>

You can also declare the variable expression inline:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>

== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Upcoming version (FGCamera v1) will have new camera mode: "world-view".

{{#ev:youtube|hebx8WdXHa0}}

== Scenery corner ==
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
{{-}}
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]]]
Programming in Nasal on Windows can now be a lot friendlier with [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]. 
Provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion. 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
{{-}}

== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in Fligthgear. There are currently 4 Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
{{-}}

== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. 
It all began as a question about a parachute which ended by brainstorming of the best approach, you can read the related thread here: 
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim 
 
Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see [http://forum.flightgear.org/viewtopic.php?f=49&p=215650&sid=97b2010406d31b6fc2fabc7cf8b1c8f8 Parachute for YASim (Thrusters & Nasal)]. 
Currently there is a reference implementation in a special version of the V-1 flying bomb: 
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb 
The drone (Firebee) for which the parachute was requested is not yet publicly available. 
You can also get an idea of it's stabilization properties from this video: 
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi
{{-}}

== In the hangar ==
=== Mainair Flash 2 Alpha ===
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
[[File:Flash2a_in_Air2.png|400px]]

=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM||right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations. 
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: 
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
{{-}}

== Multiplayer Events ==
[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. An AI scenario displays the route, checks for adherence to the rules, and announces and records your time - the results will be published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and [https://twitter.com/FlightGearUK Twitter account].

FlightGear Newsletter July 2014

2014-08-01T19:34:05Z

Algernon:

{{Newsletter being written}}

== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

{{FGCquote
|Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. 
 
'''Possible things to write about could be:''' 
- New planes that are released. 
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). 
- New FG releases (this is not very often, but it should be in the letter if so). 
- New forum features/subforums and other news from the forum. 
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) 
- Events that will be held within a short periode or (links to) screenshots of the latest event(s). 
- The first 3 or 5 pictures of a screenshot contest. 
 
If you got other idea's, post in this topic so we could extend the list. 
I don't really know what's best way to provide the letter. But we have some options: 
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). 
- emails send to all forum-users (I don't really like this myself). 
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org] 
- or even something else 
 
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
|title=<nowiki>Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. 
 
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? 
 
But if you are willing to get a newsletter rolling, that would be awsome.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>curt</nowiki>
|date=<nowiki>Tue May 27</nowiki>
}}
}}

{{FGCquote
|Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>MaverickAlex</nowiki>
|date=<nowiki>Thu May 29</nowiki>
}}
}}

{{FGCquote
|Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Thu Aug 21</nowiki>
}}
}}

{{FGCquote
|Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? 
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Oct 03</nowiki>
}}
}}

== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.

For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes). 
 
(see the [http://i.imgur.com/dqMzBS4.png linked image])
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
|title=<nowiki>Re: osgText backdrop</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon Jul 07</nowiki>
}}
}}

<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date: Mon Jul 7 18:26:16 2014 +0200

Canvas: add backdrop option to text

diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
void setLineHeight(float factor);
void setFill(const std::string& fill);
void setBackgroundColor(const std::string& fill);
+ void setOutlineColor(const std::string& backdrop);

SGVec2i sizeForWidth(int w) const;
osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
}

//----------------------------------------------------------------------------
+ void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+ {
+ osg::Vec4 color;
+ setBackdropType(osgText::Text::OUTLINE);
+ if( parseColor(backdrop, color) )
+ setBackdropColor( color );
+ }
+
+ //----------------------------------------------------------------------------
// simplified version of osgText::Text::computeGlyphRepresentation() to
// just calculate the size for a given weight. Glpyh calculations/creating
// is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas

addStyle("fill", "color", &TextOSG::setFill, text);
addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+ addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
addStyle("character-size",
"numeric",
static_cast<
</syntaxhighlight>

<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date: Mon Jul 7 18:27:50 2014 +0200

Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {

setColorFill: func me.set('background', _getColor(arg)),
getColorFill: func me.get('background'),
+
+ setBackdropColor: func me.set('backdrop', _getColor(arg)),
};

# Path
</syntaxhighlight>

== FGCanvas Updates ==
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
|Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: 
 
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. 
 
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - 
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than 
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

The whole discussion dates back to the early FGPanel days:

{{FGCquote
|I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
|title=<nowiki>Re: FSWeekend 2010</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Tue Nov 02</nowiki>
}}
}}

{{FGCquote
|Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: 
 
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: 
 
[[FGCanvas]] 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]] 
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: 
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". 
 
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
|title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

=== A Canvas based GNS 530 GPS ===
{{FGCquote
|After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this: 
 
[[File:Gns530-prototype-07-2014.png|300px]]
 
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of. 
 
Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. Still, I think it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]]...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215254#p215254
|title=<nowiki>Garmin gns530</nowiki>
|author=<nowiki>cbendele</nowiki>
|date=<nowiki>Wed Jul 23</nowiki>
}}
}}

=== Nasal: Making safer base-class calls ===
There's a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:

<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>

To pass a custom namespace environment, you can use this:

<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>

Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>

You can also declare the variable expression inline:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>

== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Upcoming version (FGCamera v1) will have new camera mode: "world-view".

{{#ev:youtube|hebx8WdXHa0}}

== Scenery corner ==
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
{{-}}
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]]]
Programming in Nasal on Windows can now be a lot friendlier with [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]. 
Provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion. 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
{{-}}

== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in Fligthgear. There are currently 4 Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
{{-}}

== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. 
It all began as a question about a parachute which ended by brainstorming of the best approach, you can read the related thread here: 
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim 
 
Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see [http://forum.flightgear.org/viewtopic.php?f=49&p=215650&sid=97b2010406d31b6fc2fabc7cf8b1c8f8 Parachute for YASim (Thrusters & Nasal)]. 
Currently there is a reference implementation in a special version of the V-1 flying bomb: 
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb 
The drone (Firebee) for which the parachute was requested is not yet publicly available. 
You can also get an idea of it's stabilization properties from this video: 
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi
{{-}}

== In the hangar ==
=== Mainair Flash 2 Alpha ===
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
[[File:Flash2a_in_Air2.png|400px]]

=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM||right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations. 
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: 
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]
{{-}}

== Multiplayer Events ==
[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. An AI scenario displays the route, checks for adherence to the rules, and announces and records your time - the results will be published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and Twitter account.

FlightGear Newsletter July 2014

2014-08-01T19:32:40Z

Algernon:

{{Newsletter being written}}

== 5 years of newsletters ==
[[File:Fgmagfiveyears.png]]

The newsletter started in July 2009. (more to write here, just so we don't forget about it)

{{FGCquote
|Would it be an idea to provide some sort of weekly or monthly newsletter? I often find out that there are new things I didn't new about or other users that don't follow all topics won't know if there's an awsome plane released. That's why I think we need a newsletter. 
 
'''Possible things to write about could be:''' 
- New planes that are released. 
- New scenery projects (like a new/redrawed airport, things like the corse scenery etc.). 
- New FG releases (this is not very often, but it should be in the letter if so). 
- New forum features/subforums and other news from the forum. 
- News from the wiki (only detailed and large tutorials, or new portals etc. so not every new article ofcourse) 
- Events that will be held within a short periode or (links to) screenshots of the latest event(s). 
- The first 3 or 5 pictures of a screenshot contest. 
 
If you got other idea's, post in this topic so we could extend the list. 
I don't really know what's best way to provide the letter. But we have some options: 
- a topic that's closed, only open for people that are making the letter (at the moment this sounds best to me). 
- emails send to all forum-users (I don't really like this myself). 
- a .pdf file with a link on the main page of [http://www.flightgear.org http://www.flightgear.org] 
- or even something else 
 
I would like to write the letter, but if there are other people to we might split stuff (someone for scenery news, someone else for aircrafts etc.). Please respond and vote in the poll. Tips/ideas are very much appreciated.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11211#p11211
|title=<nowiki>Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|The devel-list is great, I'm subscribed to, but not simple to read. It's more like the forum. Usually I don't want to or have time to read through all emails. So I delete most of it without reading anything more than the subject. We don't want to read a lot of topics if we only want to know what function is new and what it does. The the users (so not the developers) want something more ease to read/check. With some screenies of what they will get with a new function etc. So my idea was to make it especially for users. 
 
Events aren't listed on the pages you gave nor some other stuff we could place in the newsletter. In the letter all important news to know will be listed together. If we get this of the ground it could be a great way to reach users to (for events etc.). So I think the newsletter still will be a addition to the lists.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11216#p11216
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon May 26</nowiki>
}}
}}

{{FGCquote
|At one time a few years ago we attempted to launch a newsletter. We had two volunteers, but we never got even the first issue out. It's a lot of work so we need a pretty dedicated volunteer. I've heard of other folks using scribus, but even open-office writer would probably be just fine. Let's not get too caught up in the details of a print/publishing quality layout if we have to sacrifice time for content and just getting the newsletter out on a regular time frame. There are a bazillion ideas for articles. I could dust off my unpublished "yasim howto" for instance. That ended up being about 10 pages (so not newsletter material really) but I could trim it down to a teaser article and we could post the full version on the wiki or something? 
 
But if you are willing to get a newsletter rolling, that would be awsome.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11277#p11277
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>curt</nowiki>
|date=<nowiki>Tue May 27</nowiki>
}}
}}

{{FGCquote
|Gijs is right when it comes to being a Developer or a User of FG is Vastly different. I know when i first started here i had no clue about lots of developmental things, now i talk of writing .xml files, modelling nasal scripting. That is due to people describing things is basic easy to understand" Laymans" terms and not the kind of language that the DEvs use (understandably of course) 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=11368#p11368
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>MaverickAlex</nowiki>
|date=<nowiki>Thu May 29</nowiki>
}}
}}

{{FGCquote
|Since 16 to 3 voted for Yes I will release the first Newsletter as soon as possible.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=15619#p15619
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Thu Aug 21</nowiki>
}}
}}

{{FGCquote
|Why not simply start a new page on the wiki where anybody can provide contents, so that whenever it's time to send out a newsletter, the draft from the wiki could be taken? 
That way, it wouldn't be too much work for a single person - more like a "community-driven" newsletter, while this may appear to sort of defeat the purpose, not all newsletter recipients are necessarily also wiki users.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=18015#p18015
|title=<nowiki>Re: Newsletter</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Fri Oct 03</nowiki>
}}
}}

== Adding backdrop styling to Canvas (by Gijs) ==
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides.

For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now [http://forum.flightgear.org/viewtopic.php?f=71&t=23500&p=214278#p214275].
{{FGCquote
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes). 
 
(see the [http://i.imgur.com/dqMzBS4.png linked image])
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214268#p214268
|title=<nowiki>Re: osgText backdrop</nowiki>
|author=<nowiki>Gijs</nowiki>
|date=<nowiki>Mon Jul 07</nowiki>
}}
}}

<syntaxhighlight lang="diff">
commit 5cc0adc778bda1773189b0119d24fbaf5ecd4500
Author: Gijs de Rooy
Date: Mon Jul 7 18:26:16 2014 +0200

Canvas: add backdrop option to text

diff --git a/simgear/canvas/elements/CanvasText.cxx b/simgear/canvas/elements/CanvasText.cxx
index d99760a..3a986e1 100644
--- a/simgear/canvas/elements/CanvasText.cxx
+++ b/simgear/canvas/elements/CanvasText.cxx
@@ -39,6 +39,7 @@ namespace canvas
void setLineHeight(float factor);
void setFill(const std::string& fill);
void setBackgroundColor(const std::string& fill);
+ void setOutlineColor(const std::string& backdrop);

SGVec2i sizeForWidth(int w) const;
osg::Vec2 handleHit(const osg::Vec2f& pos);
@@ -97,6 +98,15 @@ namespace canvas
}

//----------------------------------------------------------------------------
+ void Text::TextOSG::setOutlineColor(const std::string& backdrop)
+ {
+ osg::Vec4 color;
+ setBackdropType(osgText::Text::OUTLINE);
+ if( parseColor(backdrop, color) )
+ setBackdropColor( color );
+ }
+
+ //----------------------------------------------------------------------------
// simplified version of osgText::Text::computeGlyphRepresentation() to
// just calculate the size for a given weight. Glpyh calculations/creating
// is not necessary for this...
@@ -546,6 +556,7 @@ namespace canvas

addStyle("fill", "color", &TextOSG::setFill, text);
addStyle("background", "color", &TextOSG::setBackgroundColor, text);
+ addStyle("backdrop", "color", &TextOSG::setOutlineColor, text);
addStyle("character-size",
"numeric",
static_cast<
</syntaxhighlight>

<syntaxhighlight lang="diff">commit 838cabd2a551834cbcac2b3edd21500409ff2e98
Author: Gijs de Rooy
Date: Mon Jul 7 18:27:50 2014 +0200

Canvas: add backdrop option to text

diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 8bc12d8..3047dbf 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -634,6 +634,8 @@ var Text = {

setColorFill: func me.set('background', _getColor(arg)),
getColorFill: func me.get('background'),
+
+ setBackdropColor: func me.set('backdrop', _getColor(arg)),
};

# Path
</syntaxhighlight>

== FGCanvas Updates ==
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]]
{{FGCquote
|Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system: 
 
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. 
 
If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - 
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than 
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

The whole discussion dates back to the early FGPanel days:

{{FGCquote
|I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people). It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
|title=<nowiki>Re: FSWeekend 2010</nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Tue Nov 02</nowiki>
}}
}}

{{FGCquote
|Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running: 
 
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below: 
 
[[FGCanvas]] 
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]] 
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are: 
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically". 
 
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
|title=<nowiki>FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

{{FGCquote
|I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
|title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Sun Jul 06</nowiki>
}}
}}

=== A Canvas based GNS 530 GPS ===
{{FGCquote
|After a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this: 
 
[[File:Gns530-prototype-07-2014.png|300px]]
 
I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of. 
 
Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. Still, I think it's far enough to present it here and let people try it and send critique and suggestions. Learn more at [[Garmin GNS530]]...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=215254#p215254
|title=<nowiki>Garmin gns530</nowiki>
|author=<nowiki>cbendele</nowiki>
|date=<nowiki>Wed Jul 23</nowiki>
}}
}}

=== Nasal: Making safer base-class calls ===
There's a lot of Nasal code floating around doing the equivalent of this when using multiple inheritance to make base class calls:

<syntaxhighlight lang="nasal">
object.parents[x].method();
</syntaxhighlight>
Internally, this works such that Nasal's inheritance mechanism relies on a so called '''parents''' vector that contains a list of classes that are used for field/method look-ups. This vector can be accessed using numeric indexes - thus, the correct value for '''x''' is directly affected by the way the parents vector is set up, i.e. its internal class ordering:

<syntaxhighlight lang="nasal">
var myClass = {parents:[FirstBaseClass, SecondBaseClass, ThirdBaseClass] };
</syntaxhighlight>

However, this practice of using indexed parents access to look up a base class should be considered a "hack" and discouraged, because it's not a particularly robust or even safe way to call a superclass, simply because it doesn't tell Nasal anything about the name of the class you're trying to call, but merely its index in the inheritance/lookup vector, which may be subject to change (e.g. due to refactoring). Thus, we encourage people to actually use Nasal's built-in '''call()''' API to accomplish the same thing in a more robust fashion:

<syntaxhighlight lang="nasal">
call(Class.method, [], me);
</syntaxhighlight>

This will tell Nasal that you want it to call a certain method in a particular class - and if that fails, you'll get better diagnostics (error messages), too. The main problem here is that the other approach is pretty vulnerable when restructuring your code, as it is heavily reliant on inheritance '''ordering''' - which is something that isn't exactly straightforward: code shouldn't "break" just because the inheritance ordering is modified. Thus, please try to use the latter idiom. If in doubt, just get in touch via the Nasal sub forum.

To pass argument to the method, just add them to the 2nd argument, i.e. the empty vector:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me);
</syntaxhighlight>

To pass a custom namespace environment, you can use this:

<syntaxhighlight lang="nasal">
var namespace = {};
call(Class.method, [nil,nil,nil], me, namespace);
</syntaxhighlight>

Which would be equivalent to this example using an anonymous namespace:
<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, {} );
</syntaxhighlight>

(If you want to preserve/modify the namespace, it makes sense not use an anonymous namespace though).

To do exception handling, you can pass an empty vector and check its size (>=1):
<syntaxhighlight lang="nasal">
var err = [];
call(Class.method, [nil,nil,nil], me, {}, err );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
</syntaxhighlight>

You can also declare the variable expression inline:

<syntaxhighlight lang="nasal">
call(Class.method, [nil,nil,nil], me, var ns={}, var err=[] );
if(size(errors))
print("There was some problem calling a base class method: Class.method()");
else {
print("Success, namespace is:");
debug.dump(ns);
}
</syntaxhighlight>

== FGCamera ==
Development of FGCamera continues. The script is being redesigned to be compatible with default view system.
Upcoming version (FGCamera v1) will have new camera mode: "world-view".

{{#ev:youtube|hebx8WdXHa0}}

== Scenery corner ==
=== Paro Int. Airport - VQPR ===
[[File:VQPR PARO AIRPORT.jpg|320px|right]]
{{#ev:youtube|itNY9YUmY3M||right|domestic flight from Bumthang to Paro}}
Works have been added to [[Paro Airport|Paro International Airport]] (VQPR) with terminal, tower, hangars and other buildings. Now users you can enjoy the apron lights, the reference points like Mr. Smiths House or other POIs like the Sangchen Choekhor Monastery. [[TerraSync]] has it all! It is not necessary to download any custom scenery. More information can be found on the wiki page: [[Paro Airport]]. This is the first airport of the Bhutanese Series. Three new domestic airports like Gelephu Airport (VQGP) are currently being developed. Work also continues on navaids for the Kingdom of Bhutan - of course only in the FlightGear-World. Everybody is invited to follow the stage of development at the designers wiki user page ([[User:Fgjosh|Fgjosh]]).
{{-}}
== Support for Nasal in Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]]]
Programming in Nasal on Windows can now be a lot friendlier with [http://gitorious.org/nasal-support/nasal-npp Nasal support for Notepad++]. 
Provides comprehensive syntax highlighting and class/function listing in a hierarchical fashion. 
Syntax highlighting is available for other editors as well, for more information see [[Howto:Syntax highlighting for Nasal]]
{{-}}

== Primary Flight Displays for Android Devices ==
Android devices are light, thin, and offer a very decent computing power and graphics processing. They are battery operated and can connect to other devices through WiFi (there is no need of cables). They are, in fact, perfect for integration in home-made cockpits. This new project offers the opportunity of extending their usage in the form of Primary Flight Displays and Navigation displays for airliners in Fligthgear. There are currently 4 Primary Flight Display (PFD) Apps in "early production" state: Basic, Boeing 777, Boeing 787-8, and Airbus 330. The Basic App is at this moment available in the Android Play Store. The other Apps will be uploaded during the next days provided that no serious problems are found in the Basic App. You are more than welcome to test it and give feedback! Visit the project website for more information: https://sites.google.com/site/flightgearandroid/

{{#ev:youtube|jd61x-_QNpM}}
{{#ev:youtube|Y6M9SyMZSCk}}
{{#ev:youtube|N1D--DZjvtE}}
{{-}}

== Parachute for YASim (Thrusters & Nasal) ==
[[File:V-1 Parachute.png|350px|thumb|V-1falling slowly with a parachute]]
Tomaskom developed a realistically behaving parachute for YASim aircraft. It is capable of a slow and stable fall and can recover the aircraft even from very severe rotations. 
It all began as a question about a parachute which ended by brainstorming of the best approach, you can read the related thread here: 
http://fguk.eu/index.php/forum/development-hangar/4546-external-reactions-forces-in-yasim 
 
Re-implementing the code elsewhere is very easy, most of it can be blindly copied with just some adjustments (trigger binding, chute area, ...). There is a thread on the main forum with HOWTO for implementation, see [http://forum.flightgear.org/viewtopic.php?f=49&p=215650&sid=97b2010406d31b6fc2fabc7cf8b1c8f8 Parachute for YASim (Thrusters & Nasal)]. 
Currently there is a reference implementation in a special version of the V-1 flying bomb: 
http://fguk.eu/index.php/hangar/viewdownload/11-other-objects-and-vehicles/400-v-1-flying-bomb 
The drone (Firebee) for which the parachute was requested is not yet publicly available. 
You can also get an idea of it's stabilization properties from this video: 
https://www.dropbox.com/s/81ns5ib5tf3y74t/V-1_Parachute.avi
{{-}}

== In the hangar ==
=== Mainair Flash 2 Alpha ===
The microlight [[Mainair Flash 2 Alpha]] is now weightshift controlled and has a new wing model.
* redesigned FDM with weightshift-control
* new wing model
* customizable controls
* weight and balance gui
* animated cockpit view
* animated pilot and an optional passenger
* emergency parachute
* multiplayer ready
* aerotow hitch
[[File:Flash2a_in_Air2.png|400px]]

=== Aero L-159 ALCA ===
{{#ev:youtube|uLojBI7ezdM||right|L-159 Disintegration}}
A first public version of the L-159 ALCA (Advanced Light Combat Aircraft) has been released. The aircraft is still in alpha stage and fairly incomplete (there are some changes to the model planned, so no texturing yet, no cockpit instruments), but it already has many advanced and sometimes unique features, most notably the disintegration animations. 
Some of the most important features include:
* Unique model disintegration animation (video on the right, see details here: http://forum.flightgear.org/viewtopic.php?f=4&t=23681)
* Cannons with realistic fire rate and tracers once every few rounds, visible/audible over MP (hit transmission is a work in progress)
* Fully automated fuel system with automatic source switching and fuel level balancing
* Carefully tuned lights including Rembrandt support, light intensity and flares fading in daylight. You may need to increase the Lights shader setting in order to see all effects with Rembrandt on.
* Most payload options modeled, including optional experimental fixed fuel probe
* I consider the FDM (YASim) almost complete and generally well tuned, handling changes a lot with heavy payload
Download available from the FGUK hangar: 
http://fguk.eu/index.php/hangar/viewdownload/8-military-jets/409-l-159-alca
[[File:L-159.png|300px|thumbnail|left|L-159 ALCA]]

== Multiplayer Events ==
[http://www.fguk.eu FGUK] will be taking the Mach Loop Challenge on Saturday 9th August, as flown by BAE in their Eurofighter simulator at Warton. An AI scenario displays the route, checks for adherence to the rules, and announces and records your time - the results will be published in the following week. More information and updates in the weeks either side of the 9th on FGUK's [https://www.facebook.com/FlightGearUK Facebook page] and Twitter account.

FlightGear Newsletter June 2014

2014-06-10T22:15:52Z

Algernon: /* FlightGear addons and mods */

{{newsletter}}
{{TOC_right|limit=2}}
{{Newsletter being written}}

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].

=== Logo Proposal ===
This is the new logo badge concept proposal for FlightGear designed by Michat.

[[File:Fglogo1.png]]
[[File:Fglogowiki.png]]
[[File:Fglogoforum.png]]

===MapStructure stress-testing ===

[[File:Map-canvas-mapstructure-performance.png|thumb|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611] ]]

{{cquote
|<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki> <nowiki>
Here, I am using the ufo @ksfo circling in a shuttle climb at >= 2000 kts GS and getting roughly 30 fps and 40-60 ms.</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Jun 03</nowiki>
}}
}}

=== 777 EFB Prototype by I-NEMO ===
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]

I-NEMO has started porting his 777/EFB prototype to [[Canvas]]

{{cquote
|<nowiki>As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:</nowiki> <nowiki>
</nowiki> <nowiki>
1) to do something to compensate for the lacking of an EFB inside the Seattle.</nowiki> <nowiki>
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki> <nowiki>
</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki> this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. </nowiki> <nowiki>
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.</nowiki> <nowiki>
</nowiki> <nowiki>
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki>I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

Learn more at [[Canvas EFB Framework]] ...

=== Canvas Garmin GPSMap196 Updates ===

[[File:Gpsmap196-canvas-panel-page.png|thumb|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]]]

=== Avidyne Entegra R9 ===

[[File:Extra500canvas.png|thumb|Work has begun to analyze, refactor and generalize useful parts of the [[Avidyne Entegra R9]] to help reuse some code in similar MFD efforts, like the [[Garmin GPSMap 196]] or [[Canvas EFB Framework]]]]

=== Towards an Aircraft-agnostic MFD Framework ===

[[File:Canvas-mfd-framework-prototyping.png|thumb|This is an adapted version of the [[Garmin GPSMap 196]] that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure.png|400px|thumb|This demonstrates how a purely XML-based MFD framework can instantiate dynamic [[MapStructure]] layers - none of this involves any [[Nasal]] coding now, it's just an XML file - to learn more, see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|400px|thumb|This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.]]

=== Canvas System ===

=== Missions & Adventures ===
[[File:Missionb.png|thumb]]

{{forum|79|Tutorials, Missions & Adventures}}

=== High Level Architecture ===

=== Usability Improvements ===

=== Getting your own ideas and features in FlightGear without having to be a coder ===

We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.
We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".

Continue reading at [[Implementing new features for FlightGear]]...

=== Getting involved as a programmer ===
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.

If you are interested in contributing as a core developer, please see [[Howto:Start core development]].

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

{{CppBind Ideas}}

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==
=== Damage and disintegration ===
{{#ev:youtube|OpwNaoO3xMQ|240|right|Tomaskom's V-1 used in anger over London}}
{{#ev:youtube|H4XDuLo35ks|240|right|Victor V2.0 damage script causing a catastrophic failure and fire}}
{{#ev:youtube|uLojBI7ezdM|240|right|L-159 disintegration}}
The development team at FGUK have been experimenting with modelling aircraft damage in a number of different ways. First of all, Tomaskom has used the particle system carefully to produce visually impressive fireballs and smoke columns with very little FPS impact. First seen in his V-1, we hope to adapt this to simulate realistic fireballs for ground impacts (where appropriate). For the moment, it explodes with the full force of a V-1's explosive payload. On the right is a video excerpt from the #FlightNight which Tom organised to debut the V-1, where we all had '''way''' too much fun bombing London. As you can see, the smoke is visible from quite a long way away from the impact, and despite two fires burning with huge smoke columns, and over ten multiplayer aircraft within model range, the frame rates are still more than acceptable. StuartC has already integrated the explosion and fireball into several development aircraft, and we expect eventually to combine it with the disintegration code and make the size of the explosion dependent on fuel load etc.

In a separate development, Algernon's work on the Victor V2.0(YASim) now includes modelled damage, a collection of Nasal scripts, some modified from existing FlightGear staples, which detects irregularities such as component failures, birdstrikes and combat weapon damage and adversely affects system performance and reliability accordingly. Unserviceability often follows, using the existing FlightGear failures system, and compatibility will be maintained as the failures system is improved. The damage script also calculates probabilites for chain reaction damage - for instance, an explosion or serious fire in one Victor engine will usually have an effect on the other. In extreme circumstances, an explosion will trigger further explosions and destroy the aircraft. The second video on the right shows a serious induced explosion on the Victor's number one engine at night. Some fine-tuning of the Rembrandt light has been carried out since this video was shot, so apologies for the visible cut-off.

Finally, and most spectacularly, Tomaskom has demonstrated the disintegration capabilities of his L-159, which is under development. Hopefully, he will explain all here before publication date.

=== Scenesetter ===
Scenesetter is a piece of code by Algernon, very early in development but already quite effective, which can effect changes to the time and weather from an AI scenario synchronously with other MP players. A crude proof of concept was used in the recent FGUK #FlightNight "British Weather", where pilots visited different airfields with various unpleasant flying conditions. Scenesetter pushes METAR strings to the FlightGear weather system based on the location of an associated Navaid, establishing a circular zone of a specified radius around it in which METAR will be changed. Start time can be specified too, either by providing a local start time or a local time offset (useful for Multiplayer use where players will not all start the AI scenario at precisely the same time).

== In the hangar ==

=== New aircraft ===

=== Updated aircraft ===

The Swedish fighter jet Saab JA-37 Viggen has been updated, since it was included in FG 3.0.0; More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.

[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
=== Translators required ===
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Community news ==
=== FlightGear on YouTube ===

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===

{{Volunteer Intro|mode=showlogo}}

=== Call for volunteers ===
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].

=== Did you know ===

[[Category:FlightGear Newsletter]]


[[Category:Changes after 3.00]]

FlightGear Newsletter June 2014

2014-06-09T12:26:41Z

Algernon:

{{newsletter}}
{{TOC_right|limit=2}}
{{Newsletter being written}}

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].

=== Logo Proposal ===
This is the new logo badge concept proposal for FlightGear designed by Michat.

[[File:Fglogo1.png]]
[[File:Fglogowiki.png]]
[[File:Fglogoforum.png]]

===MapStructure stress-testing ===

[[File:Map-canvas-mapstructure-performance.png|thumb|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611] ]]

{{cquote
|<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki> <nowiki>
Here, I am using the ufo @ksfo circling in a shuttle climb at >= 2000 kts GS and getting roughly 30 fps and 40-60 ms.</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Jun 03</nowiki>
}}
}}

=== 777 EFB Prototype by I-NEMO ===
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]

I-NEMO has started porting his 777/EFB prototype to [[Canvas]]

{{cquote
|<nowiki>As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:</nowiki> <nowiki>
</nowiki> <nowiki>
1) to do something to compensate for the lacking of an EFB inside the Seattle.</nowiki> <nowiki>
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki> <nowiki>
</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki> this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. </nowiki> <nowiki>
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.</nowiki> <nowiki>
</nowiki> <nowiki>
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki>I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

Learn more at [[Canvas EFB Framework]] ...

=== Canvas Garmin GPSMap196 Updates ===

[[File:Gpsmap196-canvas-panel-page.png|thumb|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]]]

=== Avidyne Entegra R9 ===

[[File:Extra500canvas.png|thumb|Work has begun to analyze, refactor and generalize useful parts of the [[Avidyne Entegra R9]] to help reuse some code in similar MFD efforts, like the [[Garmin GPSMap 196]] or [[Canvas EFB Framework]]]]

=== Towards an Aircraft-agnostic MFD Framework ===

[[File:Canvas-mfd-framework-prototyping.png|thumb|This is an adapted version of the [[Garmin GPSMap 196]] that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure.png|400px|thumb|This demonstrates how a purely XML-based MFD framework can instantiate dynamic [[MapStructure]] layers - none of this involves any [[Nasal]] coding now, it's just an XML file - to learn more, see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|400px|thumb|This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.]]

=== Canvas System ===

=== Missions & Adventures ===
[[File:Missionb.png|thumb]]

{{forum|79|Tutorials, Missions & Adventures}}

=== High Level Architecture ===

=== Usability Improvements ===

=== Getting your own ideas and features in FlightGear without having to be a coder ===

We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.
We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".

Continue reading at [[Implementing new features for FlightGear]]...

=== Getting involved as a programmer ===
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.

If you are interested in contributing as a core developer, please see [[Howto:Start core development]].

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

{{CppBind Ideas}}

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==
=== Damage and disintegration ===
{{#ev:youtube|OpwNaoO3xMQ|240|right|Tomaskom's V-1 used in anger over London}}
{{#ev:youtube|H4XDuLo35ks|240|right|Victor V2.0 damage script causing a catastrophic failure and fire}}
{{#ev:youtube|uLojBI7ezdM|240|right|L-159 disintegration}}
The development team at FGUK have been experimenting with modelling aircraft damage in a number of different ways. First of all, Tomaskom has used the particle system carefully to produce visually impressive fireballs and smoke columns with very little FPS impact. First seen in his V-1, we hope to adapt this to simulate realistic fireballs for ground impacts (where appropriate). For the moment, it explodes with the full force of a V-1's explosive payload. On the right is a video excerpt from the #FlightNight which Tom organised to debut the V-1, where we all had '''way''' too much fun bombing London. As you can see, the smoke is visible from quite a long way away from the impact, and despite two fires burning with huge smoke columns, and over ten multiplayer aircraft within model range, the frame rates are still more than acceptable. StuartC has already integrated the explosion and fireball into several development aircraft, and we expect eventually to combine it with the disintegration code and make the size of the explosion dependent on fuel load etc.

In a separate development, Algernon's work on the Victor V2.0(YASim) now includes modelled damage, a collection of Nasal scripts, some modified from existing FlightGear staples, which detects irregularities such as component failures, birdstrikes and combat weapon damage and adversely affects system performance and reliability accordingly. Unserviceability often follows, using the existing FlightGear failures system, and compatibility will be maintained as the failures system is improved. The damage script also calculates probabilites for chain reaction damage - for instance, an explosion or serious fire in one Victor engine will usually have an effect on the other. In extreme circumstances, an explosion will trigger further explosions and destroy the aircraft. The second video on the right shows a serious induced explosion on the Victor's number one engine at night. Some fine-tuning of the Rembrandt light has been carried out since this video was shot, so apologies for the visible cut-off.

Finally, and most spectacularly, FGUK aerodynamicist Tomaskom has demonstrated the disintegration capabilities of his L-159, which is under development. I can say little more than the third video on the right demonstrates, except that it's still a work in progress and a proof of concept, and we expect numerous different structural failures will be able to be modelled, hopefully in partnership with the damage script described above. We're pretty excited about this one!

=== Scenesetter ===
Scenesetter is a piece of code by Algernon, very early in development but already quite effective, which can effect changes to the time and weather from an AI scenario synchronously with other MP players. A crude proof of concept was used in the recent FGUK #FlightNight "British Weather", where pilots visited different airfields with various unpleasant flying conditions. Scenesetter pushes METAR strings to the FlightGear weather system based on the location of an associated Navaid, establishing a circular zone of a specified radius around it in which METAR will be changed. Start time can be specified too, either by providing a local start time or a local time offset (useful for Multiplayer use where players will not all start the AI scenario at precisely the same time).

== In the hangar ==

=== New aircraft ===

=== Updated aircraft ===

The Swedish fighter jet Saab JA-37 Viggen has been updated, since it was included in FG 3.0.0; More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.

[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
=== Translators required ===
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Community news ==
=== FlightGear on YouTube ===

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===

{{Volunteer Intro|mode=showlogo}}

=== Call for volunteers ===
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].

=== Did you know ===

[[Category:FlightGear Newsletter]]


[[Category:Changes after 3.00]]

FlightGear Newsletter June 2014

2014-06-09T12:26:07Z

Algernon:

{{newsletter}}
{{TOC_right|limit=2}}
{{Newsletter being written}}

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].

=== Logo Proposal ===
This is the new logo badge concept proposal for FlightGear designed by Michat.

[[File:Fglogo1.png]]
[[File:Fglogowiki.png]]
[[File:Fglogoforum.png]]

===MapStructure stress-testing ===

[[File:Map-canvas-mapstructure-performance.png|thumb|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611] ]]

{{cquote
|<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki> <nowiki>
Here, I am using the ufo @ksfo circling in a shuttle climb at >= 2000 kts GS and getting roughly 30 fps and 40-60 ms.</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Jun 03</nowiki>
}}
}}

=== 777 EFB Prototype by I-NEMO ===
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]

I-NEMO has started porting his 777/EFB prototype to [[Canvas]]

{{cquote
|<nowiki>As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:</nowiki> <nowiki>
</nowiki> <nowiki>
1) to do something to compensate for the lacking of an EFB inside the Seattle.</nowiki> <nowiki>
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki> <nowiki>
</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki> this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. </nowiki> <nowiki>
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.</nowiki> <nowiki>
</nowiki> <nowiki>
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki>I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

Learn more at [[Canvas EFB Framework]] ...

=== Canvas Garmin GPSMap196 Updates ===

[[File:Gpsmap196-canvas-panel-page.png|thumb|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]]]

=== Avidyne Entegra R9 ===

[[File:Extra500canvas.png|thumb|Work has begun to analyze, refactor and generalize useful parts of the [[Avidyne Entegra R9]] to help reuse some code in similar MFD efforts, like the [[Garmin GPSMap 196]] or [[Canvas EFB Framework]]]]

=== Towards an Aircraft-agnostic MFD Framework ===

[[File:Canvas-mfd-framework-prototyping.png|thumb|This is an adapted version of the [[Garmin GPSMap 196]] that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure.png|400px|thumb|This demonstrates how a purely XML-based MFD framework can instantiate dynamic [[MapStructure]] layers - none of this involves any [[Nasal]] coding now, it's just an XML file - to learn more, see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|400px|thumb|This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.]]

=== Canvas System ===

=== Missions & Adventures ===
[[File:Missionb.png|thumb]]

{{forum|79|Tutorials, Missions & Adventures}}

=== High Level Architecture ===

=== Usability Improvements ===

=== Getting your own ideas and features in FlightGear without having to be a coder ===

We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.
We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".

Continue reading at [[Implementing new features for FlightGear]]...

=== Getting involved as a programmer ===
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.

If you are interested in contributing as a core developer, please see [[Howto:Start core development]].

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

{{CppBind Ideas}}

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==
=== Damage and disintegration ===
{{#ev:youtube|OpwNaoO3xMQ|240|right|Tomaskom's V-1 used in anger over London}}
{{#ev:youtube|H4XDuLo35ks|240|right|Victor V2.0 damage script causing a catastrophic failure and fire}}
{{#ev:youtube|uLojBI7ezdM|240|right|L-159 disintegration}}
The development team at FGUK have been experimenting with modelling aircraft damage in a number of different ways. First of all, Tomaskom has used the particle system carefully to produce visually impressive fireballs and smoke columns with very little FPS impact. First seen in his V-1, we hope to adapt this to simulate realistic fireballs for ground impacts (where appropriate). For the moment, it explodes with the full force of a V-1's explosive payload. On the right is a video excerpt from the #FlightNight which Tom organised to debut the V-1, where we all had '''way''' too much fun bombing London. As you can see, the smoke is visible from quite a long way away from the impact, and despite two fires burning with huge smoke columns, and over ten multiplayer aircraft within model range, the frame rates are still more than acceptable. StuartC has already integrated the explosion and fireball into several development aircraft, and we expect eventually to combine it with the disintegration code and make the size of the explosion dependent on fuel load etc.

In a separate development, Algernon's work on the Victor V2.0(YASim) now includes modelled damage, a collection of Nasal scripts, some modified from existing FlightGear staples, which detects irregularities such as component failures, birdstrikes and combat weapon damage and adversely affects system performance and reliability accordingly. Unserviceability often follows, using the existing FlightGear failures system, and compatibility will be maintained as the failures system is improved. The damage script also calculates probabilites for chain reaction damage - for instance, an explosion or serious fire in one Victor engine will usually have an effect on the other. In extreme circumstances, an explosion will trigger further explosions and destroy the aircraft. The second video on the right shows a serious induced explosion on the Victor's number one engine at night. Some fine-tuning of the Rembrandt light has been carried out since this video was shot, so apologies for the visible cut-off.

Finally, and most spectacularly, FGUK aerodynamicist Tomaskom has demonstrated the disintegration capabilities of his L-159, which is under development. I can say little more than the third video on the right demonstrates, except that it's still a work in progress and a proof of concept, and we expect numerous different structural failures will be able to be modelled, hopefully in partnership with the damage script described above. We're pretty excited about this one!

PLEASE NOTE: I have been unable to post the videos at this moment. Hopefully this will be sorted out soon.

=== Scenesetter ===
Scenesetter is a piece of code by Algernon, very early in development but already quite effective, which can effect changes to the time and weather from an AI scenario synchronously with other MP players. A crude proof of concept was used in the recent FGUK #FlightNight "British Weather", where pilots visited different airfields with various unpleasant flying conditions. Scenesetter pushes METAR strings to the FlightGear weather system based on the location of an associated Navaid, establishing a circular zone of a specified radius around it in which METAR will be changed. Start time can be specified too, either by providing a local start time or a local time offset (useful for Multiplayer use where players will not all start the AI scenario at precisely the same time).

== In the hangar ==

=== New aircraft ===

=== Updated aircraft ===

The Swedish fighter jet Saab JA-37 Viggen has been updated, since it was included in FG 3.0.0; More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.

[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
=== Translators required ===
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Community news ==
=== FlightGear on YouTube ===

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===

{{Volunteer Intro|mode=showlogo}}

=== Call for volunteers ===
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].

=== Did you know ===

[[Category:FlightGear Newsletter]]


[[Category:Changes after 3.00]]

FlightGear Newsletter June 2014

2014-06-09T12:25:16Z

Algernon:

{{newsletter}}
{{TOC_right|limit=2}}
{{Newsletter being written}}

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].

=== Logo Proposal ===
This is the new logo badge concept proposal for FlightGear designed by Michat.

[[File:Fglogo1.png]]
[[File:Fglogowiki.png]]
[[File:Fglogoforum.png]]

===MapStructure stress-testing ===

[[File:Map-canvas-mapstructure-performance.png|thumb|stress-testing [[MapStructure]] using the ufo @ KSFO circling at 2000 kts in a climb, see [http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=211611#p211611] ]]

{{cquote
|<nowiki>Now that Hyde has committed Philosopher's latest changes, I'd be interested in getting some more feedback on performance.</nowiki> <nowiki>
Here, I am using the ufo @ksfo circling in a shuttle climb at >= 2000 kts GS and getting roughly 30 fps and 40-60 ms.</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211611#p211611
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Jun 03</nowiki>
}}
}}

=== 777 EFB Prototype by I-NEMO ===
[[File:777-EFB-MAIN.png|thumb|777-200ER EFB [http://forum.flightgear.org/viewtopic.php?f=71&t=23196]]]
[[File:777-EFB-AIRPORT-SEARCH.png|thumb|777-200 EFB AIRPORT SEARCH, see [http://forum.flightgear.org/viewtopic.php?f=71&t=23196&p=211410#p211410]]]

I-NEMO has started porting his 777/EFB prototype to [[Canvas]]

{{cquote
|<nowiki>As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:</nowiki> <nowiki>
</nowiki> <nowiki>
1) to do something to compensate for the lacking of an EFB inside the Seattle.</nowiki> <nowiki>
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.</nowiki> <nowiki>
</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki> this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be. </nowiki> <nowiki>
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.</nowiki> <nowiki>
</nowiki> <nowiki>
My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'. </nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

{{cquote
|<nowiki>I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...</nowiki>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=211550#p211550
|title=<nowiki>Re: 777 EFB status & plans ?</nowiki>
|author=<nowiki>I-NEMO</nowiki>
|date=<nowiki>Mon Jun 02</nowiki>
}}
}}

Learn more at [[Canvas EFB Framework]] ...

=== Canvas Garmin GPSMap196 Updates ===

[[File:Gpsmap196-canvas-panel-page.png|thumb|F-JJTH has updated the SVG file implementing the panel page for the [[Garmin GPSMap 196]]]]

=== Avidyne Entegra R9 ===

[[File:Extra500canvas.png|thumb|Work has begun to analyze, refactor and generalize useful parts of the [[Avidyne Entegra R9]] to help reuse some code in similar MFD efforts, like the [[Garmin GPSMap 196]] or [[Canvas EFB Framework]]]]

=== Towards an Aircraft-agnostic MFD Framework ===

[[File:Canvas-mfd-framework-prototyping.png|thumb|This is an adapted version of the [[Garmin GPSMap 196]] that is currently being developed by F-JJTH. Here, the whole instrument is entirely set up in XML space, including buttons/event handling, but also the embedded canvas region that serves as the 'screen'. The idea is to allow arbitrary MFDs to be specified in an aircraft-agnostic fashion, including displays like a PFD, [[NavDisplay]] or EFB. For details, please see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure.png|400px|thumb|This demonstrates how a purely XML-based MFD framework can instantiate dynamic [[MapStructure]] layers - none of this involves any [[Nasal]] coding now, it's just an XML file - to learn more, see [[Canvas Glass Cockpit Efforts]].]]

[[File:Canvas-mfd-framework-prototyping-with-mapstructure-with-kln89-skin.png|400px|thumb|This screen shot shows the texture of the hard-coded KLN89 instrument used as a skin/theme for the MFD instrument, with a MapStructure-powered map shown.]]

=== Canvas System ===

=== Missions & Adventures ===
[[File:Missionb.png|thumb]]

{{forum|79|Tutorials, Missions & Adventures}}

=== High Level Architecture ===

=== Usability Improvements ===

=== Getting your own ideas and features in FlightGear without having to be a coder ===

We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors, either by adding new features to FlightGear, or by improving other aspects of FlightGear as a whole (community, infrastructure, usability, end-user support, accessibility, funding etc). Unfortunately, this has caused some friction over time, because people were expecting their involvement to work differently, especially those primarily making suggestions and providing feedback through discussions are obviously getting fed up with the community of contributors not responding directly to such feedback.
Now, we do appreciate any community involvement obviously, but people who are serious about actually bringing certain changes to FlightGear will find that just making suggestions will typically not work too well, and that just participating in lengthy community discussions is usually fruitless. We've had some extremely heated discussions over the years, some debating interesting ideas - and many ending up being dozens of pages in size, containing hundreds of postings. Often, these contain lots of good ideas and suggestions, but sooner or later these suggestions become emotional and are no longer constructive - yet, we're dealing with them constantly, which is taking up resources, i.e. time and energy. In an open source project like FlightGear, which is entirely volunteer driven, time is the most precious resource we have to contribute. It is like a "currency" for the project, and whenever something (or someone) is taking up lots of time without anything materializing, this is draining resources from other areas, no matter if it's end-user support or development in some shape or form.
We are now trying to document how "bootstrapping" a feature or project works conceptually, i.e. implementing new features for Flightgear - to provide a perspective that enables people to better understand how to bring changes to FlightGear without having to do all the work on their own. Note that this doesn't mean that this is the only way to accomplish something, but this is a tested and proven way - which we didn't come up with, but which is just a convention that happens to "just work", which is an important aspect for a non-organized project like FlightGear, where development itself also primarily "just happens".

Continue reading at [[Implementing new features for FlightGear]]...

=== Getting involved as a programmer ===
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.

If you are interested in contributing as a core developer, please see [[Howto:Start core development]].

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

{{CppBind Ideas}}

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==
=== Damage and disintegration ===

The development team at FGUK have been experimenting with modelling aircraft damage in a number of different ways. First of all, Tomaskom has used the particle system carefully to produce visually impressive fireballs and smoke columns with very little FPS impact. First seen in his V-1, we hope to adapt this to simulate realistic fireballs for ground impacts (where appropriate). For the moment, it explodes with the full force of a V-1's explosive payload. On the right is a video excerpt from the #FlightNight which Tom organised to debut the V-1, where we all had '''way''' too much fun bombing London. As you can see, the smoke is visible from quite a long way away from the impact, and despite two fires burning with huge smoke columns, and over ten multiplayer aircraft within model range, the frame rates are still more than acceptable. StuartC has already integrated the explosion and fireball into several development aircraft, and we expect eventually to combine it with the disintegration code and make the size of the explosion dependent on fuel load etc.

In a separate development, Algernon's work on the Victor V2.0(YASim) now includes modelled damage, a collection of Nasal scripts, some modified from existing FlightGear staples, which detects irregularities such as component failures, birdstrikes and combat weapon damage and adversely affects system performance and reliability accordingly. Unserviceability often follows, using the existing FlightGear failures system, and compatibility will be maintained as the failures system is improved. The damage script also calculates probabilites for chain reaction damage - for instance, an explosion or serious fire in one Victor engine will usually have an effect on the other. In extreme circumstances, an explosion will trigger further explosions and destroy the aircraft. The second video on the right shows a serious induced explosion on the Victor's number one engine at night. Some fine-tuning of the Rembrandt light has been carried out since this video was shot, so apologies for the visible cut-off.

Finally, and most spectacularly, FGUK aerodynamicist Tomaskom has demonstrated the disintegration capabilities of his L-159, which is under development. I can say little more than the third video on the right demonstrates, except that it's still a work in progress and a proof of concept, and we expect numerous different structural failures will be able to be modelled, hopefully in partnership with the damage script described above. We're pretty excited about this one!

PLEASE NOTE: I have been unable to post the videos at this moment. Hopefully this will be sorted out soon.

=== Scenesetter ===
Scenesetter is a piece of code by Algernon, very early in development but already quite effective, which can effect changes to the time and weather from an AI scenario synchronously with other MP players. A crude proof of concept was used in the recent FGUK #FlightNight "British Weather", where pilots visited different airfields with various unpleasant flying conditions. Scenesetter pushes METAR strings to the FlightGear weather system based on the location of an associated Navaid, establishing a circular zone of a specified radius around it in which METAR will be changed. Start time can be specified too, either by providing a local start time or a local time offset (useful for Multiplayer use where players will not all start the AI scenario at precisely the same time).

== In the hangar ==

=== New aircraft ===

=== Updated aircraft ===

The Swedish fighter jet Saab JA-37 Viggen has been updated, since it was included in FG 3.0.0; More instruments, additional liveries, aerodynamic response to payload and tooltips on instruments. Option for automatic reverse thrust at touchdown, selection of HUD brightness, disabling of structural damage. The aircraft now also has multiplayer sounds and better cockpit view helps seeing the landing strip. Support for FG 2.8 by deleting a small section in an xml file. Also worth mentioning is countless bug-fixes and improvements, e.g. better handling at high altitudes and a bug fix in the lift force formula.

[[File:Saab JA-37 Viggen Blue Peter Livery.png|Blå Petter Livery for JA-37]]

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
=== Translators required ===
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Community news ==
=== FlightGear on YouTube ===

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===

{{Volunteer Intro|mode=showlogo}}

=== Call for volunteers ===
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].

=== Did you know ===

[[Category:FlightGear Newsletter]]


[[Category:Changes after 3.00]]

FlightGear Newsletter December 2012

2013-01-02T17:08:49Z

Algernon: /* FGUK's Saturday Night Flights */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release.''

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]].

=== Atmospheric Light Scattering ===

The atmospheric light scattering rendering framework received a major overhaul. Snow is now generated procedurally, which improves the performance if no snow is in the scene, but also allows the user to control the thickness of the snow layer - the shader can do a very light snow cover like in the winter textures all the way to a closed, thick snow layer.

A new runway effect shader, similar to the one in the default rendering scheme, shows a hires bumpmap for runway closeups and displays also snow drifts in high resolution on the runway if the terrain at this altiude is snow-covered. This is complemented by a high resolution grass texture for the green around the runway.

Major changes have been done to the ambient lighting of terrain and clouds in low light - the previous ambient light curve has been replaced by a light curve measured from a large set of photographs of sunsets. As a result, the color balance of cloud shadows in low sunlight is now much more realistic, and the effect of clouds casting a shadow on other clouds is now also effectively accounted for.

In the course of these changes, the framework is now also able to render moonlit scenes at night, however this is not currently integrated to be done automatically.

[[File:Light scattering dec12 10.jpg|300px|Procedural snow and hires snow drifts on the runway.]]
[[File:Light scattering dec12 05.jpg|300px|Early morning scene over the French Alps.]]
[[File:Light scattering dec12 13.jpg|300px|New color balance of clouds in low light]]

Combined and fully integrated with Advanced Weather, Atmospheric Light Scattering is now able to render highly realistic lighting and high-quality scenery texturing, rivaling the visual quality of FSX.

=== Random Buildings ===


=== Project Rembrandt ===
=== Canvas System ===


=== High Level Architecture ===
=== FlightGear an Android ===

=== Usability Improvements ===

=== Mailing list digest ===

(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list or the git logs)

=== Forum digest ===

=== Git digest ===

=== Getting involved as a programmer ===

Please see [[Howto:Start core development]]

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Snapshot releases ==
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].

The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].

== Translators required ==
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.

=== New aircraft ===

[[File:St10-splash.png|thumb|A small pleasant plane]]
[[File:Pc12-splash.png|thumb|A classic that was not yet in FG]]
[[File:Gannet-splash.png|thumb|Dual Turboprop. It should be noted]]
[[File:Whirlwind-splash.png|thumb|Aircraft without future due to engines]]
[[File:Yak-36-splash.png|thumb|Russian VTOL 1963]]
[[File:F19-splash.png|thumb|A canard of 1927]]
The Socata ST 10 Diplomate : A command of Samaliet that I modeled with a lot of fun. 
The Pilatus PC 12/47 : A request of C-VALL (a Canadian :) ) that I modeled for him. 
The Fairey Gannet : A rather ugly aircraft, but it takes all kinds to fly :) 
The Westland Whirlwind : An aircraft that had great potential, but the choice of engines was fatal :( 
The Yak 36 : A fantastic Russian VTOL modeled by Pierre Duval. 
The Focke Wulf F19 Ente : German experimental "tail-first" aircraft in the late 1920s.

=== Updated aircraft ===

==== Boeing 707-320C and 707-3J9C ====
[[File:707-320-flightdeck.png|thumb|707-320C flightdeck]]

The Boeing 707 has two new versions in Flightgear: [[Boeing_707-320|the 707-320C and the 3J19C]], which are downloaded and installed together as [[Boeing 707-320]]. The new version is based on the model of Innis Cunningham (already developed by Isaias Prestes). The gear and engines has been modified (with reversers), lights were added. The new versions have a detailed flightdeck, with working instruments, pedestal, etc. The FDM has ben re-writen in YASim.

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FlightGear on Google+ ===
The [https://plus.google.com/+flightgear FlightGear Google+ page] welcomed its 1000th plus this month! Please +1 us if you haven't already.

=== FlightGear on YouTube ===
The Viper project, that we mentioned in the [[FlightGear Newsletter January 2012#FlightGear users|January edition]] of the newsletter, is on airborne! Now we can see their good results.
{{#ev:youtube|8wcEz9SfcYQ}}
You'll find more videos on the official [https://sites.google.com/site/mf2012theviper/ Viper cockpit website].

Congratulations for that awesome project.

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
==== FGUK's Saturday Night Flights ====
[[File:FGUK-3rdNov12.jpg|270px|thumb|FGUK discovers there is nothing half so much worth doing than messing about in (flying) boats]]
[[File:FGUK-10thNov12.jpg|270px|thumb|Fast jets of FGUK leave the British winter behind for some fine-weather flying in Hawaii]]
[http://www.fguk.eu FGUK] rounded off November with four more memorable outings, forsaking the bleak winter scenery of the United Kingdom for the warmer climes of South and Pacific America before returning to the Lake District for some low flying exercises within easy flying distance of our home base of Llanbedr (EGOD).

We started the month by leaving the fast jets snug in their hangars and paddling out to board seaplanes and flying boats dating from the classic age of intercontinental flight to modern day transport and fire-fighting aircraft. The additional challenge of beginning our flight from Lake Titicaca, 12000 feet up on the Andean Altiplano, set regular FGUK fliers practicing hard during the preceding week, with some of the older aircraft requiring skill and patience to even start their engines in the thin air, and all pilots adjusting to the unusual and slightly tricky experience of taking off at altitude. Their efforts paid off, forming up around Flight Leader Algernon to skim the Andes before descending steadily down with the terrain to land in a flurry of surf off the Peruvian coast. This was almost certainly a collection of aircraft never seen flying together before, with a truly gargantuan Hughes H4 Hercules (the ''Spruce Goose'') joining Canopus, the first Short S.23 'Empire' flying boat, a Bombardier 415 water-bomber, classically-beautiful Consolidated Catalina PBY and Grumman Goose among others.

Next week saw a return to a more traditional FGUK theme, with assorted fast jets hammering across somebody else's airspace. Flight Leader Neilson chose Hawaii for this flight, in order to showcase the new scenery package included in FGFS 2.8; it attracted a varied selection of fighters and ground attack aircraft including several classics from Dave Culp's hangar, which FGUK now hosts and maintains. Two F4 Phantoms, two F-15s (one C and one E) and a brace of Tornado GR4s shattered the peace of the island for two hours, at speeds high enough to require a refueling at Hilo. As is becoming standard now for all flight planners, Neilson put a good deal of preparation into this flight, with an illustrated flight plan and a downloadable Route Manager route available in advance of the event, and as always, our multimedia artists got to work during the following week to collate and shape their collected stills and video clips into galleries and movies, which are available in the FGUK media forum (see the link below).

The chance to hone some slightly rusty skills came the following week, with a theme surround a single aircraft, and one which is both famously capable and notoriously tricky to handle - the physics-defying BaE Harrier. As one of the great British aircraft of all time, the Harrier is well represented in the FGUK hangar and the pilots had several incarnations to choose from for this high-speed, low-level, cross-continental mission from Chile to Port Stanley. Planned and led by N-SCOT, the flight plan had some tricky twists, including employing the Harrier's ace card feature: its ability to operate away from traditional flight infrastructure, in this case, a beach refueling. One vertical take-off later, and the squadron was skimming the waves, headed southeast for Stanley at 200ft AGL. Reports that the first round in the Victory public house was purchased by StuartC are apparently without substance.

The last week of November took us closer to home when Moli organised a flight to the Lake District in the North of England. Departing Walney Island airfield (coincidentally the site of the first ever FGUK flying event back in 2010) were Hawker Hunters, Vought F-8 Crusaders, and an FGR2 among others. The weather was typically damp and grey, but with cockpit heaters turned up the low-level blast through the valleys and over the lakes was a success.

FGUK welcomes pilots from all corners of the FG universe to fly with us on a Saturday at 2000hrs UTC. Please check the [http://www.fguk.eu/forum/saturday-night-flying Saturday Night Flying subforum on our website] to find out where we will be gathering and whether there are any recommendations or requirements for aircraft, and address any questions to us there. We hope to see you in the skies!

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten.

=== Call for volunteers ===
* The [[Flightgear On Android]] team is looking for testers
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter|2012 12]]

FlightGear Newsletter December 2012

2013-01-02T15:39:47Z

Algernon: /* FGUK's Saturday Night Flights */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release.''

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]].

=== Atmospheric Light Scattering ===

The atmospheric light scattering rendering framework received a major overhaul. Snow is now generated procedurally, which improves the performance if no snow is in the scene, but also allows the user to control the thickness of the snow layer - the shader can do a very light snow cover like in the winter textures all the way to a closed, thick snow layer.

A new runway effect shader, similar to the one in the default rendering scheme, shows a hires bumpmap for runway closeups and displays also snow drifts in high resolution on the runway if the terrain at this altiude is snow-covered. This is complemented by a high resolution grass texture for the green around the runway.

Major changes have been done to the ambient lighting of terrain and clouds in low light - the previous ambient light curve has been replaced by a light curve measured from a large set of photographs of sunsets. As a result, the color balance of cloud shadows in low sunlight is now much more realistic, and the effect of clouds casting a shadow on other clouds is now also effectively accounted for.

In the course of these changes, the framework is now also able to render moonlit scenes at night, however this is not currently integrated to be done automatically.

[[File:Light scattering dec12 10.jpg|300px|Procedural snow and hires snow drifts on the runway.]]
[[File:Light scattering dec12 05.jpg|300px|Early morning scene over the French Alps.]]
[[File:Light scattering dec12 13.jpg|300px|New color balance of clouds in low light]]

Combined and fully integrated with Advanced Weather, Atmospheric Light Scattering is now able to render highly realistic lighting and high-quality scenery texturing, rivaling the visual quality of FSX.

=== Random Buildings ===


=== Project Rembrandt ===
=== Canvas System ===


=== High Level Architecture ===
=== FlightGear an Android ===

=== Usability Improvements ===

=== Mailing list digest ===

(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list or the git logs)

=== Forum digest ===

=== Git digest ===

=== Getting involved as a programmer ===

Please see [[Howto:Start core development]]

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Snapshot releases ==
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].

The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].

== Translators required ==
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.

=== New aircraft ===

[[File:St10-splash.png|thumb|A small pleasant plane]]
[[File:Pc12-splash.png|thumb|A classic that was not yet in FG]]
[[File:Gannet-splash.png|thumb|Dual Turboprop. It should be noted]]
[[File:Whirlwind-splash.png|thumb|Aircraft without future due to engines]]
[[File:Yak-36-splash.png|thumb|Russian VTOL 1963]]
[[File:F19-splash.png|thumb|A canard of 1927]]
The Socata ST 10 Diplomate : A command of Samaliet that I modeled with a lot of fun. 
The Pilatus PC 12/47 : A request of C-VALL (a Canadian :) ) that I modeled for him. 
The Fairey Gannet : A rather ugly aircraft, but it takes all kinds to fly :) 
The Westland Whirlwind : An aircraft that had great potential, but the choice of engines was fatal :( 
The Yak 36 : A fantastic Russian VTOL modeled by Pierre Duval. 
The Focke Wulf F19 Ente : German experimental "tail-first" aircraft in the late 1920s.

=== Updated aircraft ===

==== Boeing 707-320C and 707-3J9C ====
[[File:707-320-flightdeck.png|thumb|707-320C flightdeck]]

The Boeing 707 has two new versions in Flightgear: [[Boeing_707-320|the 707-320C and the 3J19C]], which are downloaded and installed together as [[Boeing 707-320]]. The new version is based on the model of Innis Cunningham (already developed by Isaias Prestes). The gear and engines has been modified (with reversers), lights were added. The new versions have a detailed flightdeck, with working instruments, pedestal, etc. The FDM has ben re-writen in YASim.

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FlightGear on Google+ ===
The [https://plus.google.com/+flightgear FlightGear Google+ page] welcomed its 1000th plus this month! Please +1 us if you haven't already.

=== FlightGear on YouTube ===
The Viper project, that we mentioned in the [[FlightGear Newsletter January 2012#FlightGear users|January edition]] of the newsletter, is on airborne! Now we can see their good results.
{{#ev:youtube|8wcEz9SfcYQ}}
You'll find more videos on the official [https://sites.google.com/site/mf2012theviper/ Viper cockpit website].

Congratulations for that awesome project.

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
==== FGUK's Saturday Night Flights ====
[[File:FGUK-3rdNov12.jpg|270px|thumb|FGUK discovers there is nothing half so much worth doing than messing about in (flying) boats]]
[[File:FGUK-10thNov12.jpg|270px|thumb|Fast jets of FGUK leave the British winter behind for some fine-weather flying in Hawaii]]
[http://www.fguk.eu FGUK] rounded off November with four more memorable outings, forsaking the bleak winter scenery of the United Kingdom for the warmer climes of South and Pacific America before returning to the Lake District for some low flying exercises within easy flying distance of our home base of Llanbedr (EGOD).

We started the month by leaving the fast jets snug in their hangars and paddling out to board seaplanes and flying boats dating from the classic age of intercontinental flight to modern day transport and fire-fighting aircraft. The additional challenge of beginning our flight from Lake Titicaca, 12000 feet up on the Andean Altiplano, set regular FGUK fliers practicing hard during the preceding week, with some of the older aircraft requiring skill and patience to even start their engines in the thin air, and all pilots adjusting to the unusual and slightly tricky experience of taking off at altitude. Their efforts paid off, forming up around Flight Leader Algernon to skim the Andes before descending steadily down with the terrain to land in a flurry of surf off the Peruvian coast. This was almost certainly a collection of aircraft never seen flying before, with a truly gargantuan Hughes H4 Hercules (the ''Spruce Goose'') joining Canopus, the first Short S.23 'Empire' flying boat, a Bombardier 415 water-bomber, classically-beautiful Consolidated Catalina PBY and Grumman Goose among others.

Next week saw a return to a more traditional FGUK theme, with assorted fast jets hammering across somebody else's airspace. Flight Leader Neilson chose Hawaii for this flight, in order to showcase the new scenery package included in FGFS 2.8; it attracted a varied selection of fighters and ground attack aircraft including several classics from Dave Culp's hangar, which FGUK now hosts and maintains. Two F4 Phantoms, two F-15s (one C and one E) and a brace of Tornado GR4s shattered the peace of the island for two hours, at speeds high enough to require a refueling at Hilo. As is becoming standard now for all flight planners, Neilson put a good deal of preparation into this flight, with an illustrated flight plan and a downloadable Route Manager route available in advance of the event, and as always, our multimedia artists got to work during the following week to collate and shape their collected stills and video clips into galleries and movies, which are available in the FGUK media forum (see the link below).

The chance to hone some slightly rusty skills came the following week, with a theme surround a single aircraft, and one which is both famously capable and notoriously tricky to handle - the physics-defying BaE Harrier. As one of the great British aircraft of all time, the Harrier is well represented in the FGUK hangar and the pilots had several incarnations to choose from for this high-speed, low-level, cross-continental mission from Chile to Port Stanley. Planned and led by N-SCOT, the flight plan had some tricky twists, including employing the Harrier's ace card feature: its ability to operate away from traditional flight infrastructure, in this case, a beach refueling. One vertical take-off later, and the squadron was skimming the waves, headed southeast for Stanley at 200ft AGL. Reports that the first round in the Victory public house was purchased by StuartC are apparently without substance.

The last week of November took us closer to home when Moli organised a flight to the Lake District in the North of England. Departing Walney Island airfield (coincidentally the site of the first ever FGUK flying event back in 2010) were Hawker Hunters, Vought F-8 Crusaders, and an FGR2 among others. The weather was typically damp and grey, but with cockpit heaters turned up the low-level blast through the valleys and over the lakes was a success.

FGUK welcomes pilots from all corners of the FG universe to fly with us on a Saturday at 2000hrs UTC. Please check the [http://www.fguk.eu/forum/saturday-night-flying Saturday Night Flying subforum on our website] to find out where we will be gathering and whether there are any recommendations or requirements for aircraft, and address any questions to us there. We hope to see you in the skies!

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten.

=== Call for volunteers ===
* The [[Flightgear On Android]] team is looking for testers
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter|2012 12]]

FlightGear Newsletter December 2012

2013-01-02T15:38:17Z

Algernon: /* FGUK's Saturday Night Flights */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release.''

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]].

=== Atmospheric Light Scattering ===

The atmospheric light scattering rendering framework received a major overhaul. Snow is now generated procedurally, which improves the performance if no snow is in the scene, but also allows the user to control the thickness of the snow layer - the shader can do a very light snow cover like in the winter textures all the way to a closed, thick snow layer.

A new runway effect shader, similar to the one in the default rendering scheme, shows a hires bumpmap for runway closeups and displays also snow drifts in high resolution on the runway if the terrain at this altiude is snow-covered. This is complemented by a high resolution grass texture for the green around the runway.

Major changes have been done to the ambient lighting of terrain and clouds in low light - the previous ambient light curve has been replaced by a light curve measured from a large set of photographs of sunsets. As a result, the color balance of cloud shadows in low sunlight is now much more realistic, and the effect of clouds casting a shadow on other clouds is now also effectively accounted for.

In the course of these changes, the framework is now also able to render moonlit scenes at night, however this is not currently integrated to be done automatically.

[[File:Light scattering dec12 10.jpg|300px|Procedural snow and hires snow drifts on the runway.]]
[[File:Light scattering dec12 05.jpg|300px|Early morning scene over the French Alps.]]
[[File:Light scattering dec12 13.jpg|300px|New color balance of clouds in low light]]

Combined and fully integrated with Advanced Weather, Atmospheric Light Scattering is now able to render highly realistic lighting and high-quality scenery texturing, rivaling the visual quality of FSX.

=== Random Buildings ===


=== Project Rembrandt ===
=== Canvas System ===


=== High Level Architecture ===
=== FlightGear an Android ===

=== Usability Improvements ===

=== Mailing list digest ===

(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list or the git logs)

=== Forum digest ===

=== Git digest ===

=== Getting involved as a programmer ===

Please see [[Howto:Start core development]]

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Snapshot releases ==
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].

The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].

== Translators required ==
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we adopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.

=== New aircraft ===

[[File:St10-splash.png|thumb|A small pleasant plane]]
[[File:Pc12-splash.png|thumb|A classic that was not yet in FG]]
[[File:Gannet-splash.png|thumb|Dual Turboprop. It should be noted]]
[[File:Whirlwind-splash.png|thumb|Aircraft without future due to engines]]
[[File:Yak-36-splash.png|thumb|Russian VTOL 1963]]
[[File:F19-splash.png|thumb|A canard of 1927]]
The Socata ST 10 Diplomate : A command of Samaliet that I modeled with a lot of fun. 
The Pilatus PC 12/47 : A request of C-VALL (a Canadian :) ) that I modeled for him. 
The Fairey Gannet : A rather ugly aircraft, but it takes all kinds to fly :) 
The Westland Whirlwind : An aircraft that had great potential, but the choice of engines was fatal :( 
The Yak 36 : A fantastic Russian VTOL modeled by Pierre Duval. 
The Focke Wulf F19 Ente : German experimental "tail-first" aircraft in the late 1920s.

=== Updated aircraft ===

==== Boeing 707-320C and 707-3J9C ====
[[File:707-320-flightdeck.png|thumb|707-320C flightdeck]]

The Boeing 707 has two new versions in Flightgear: [[Boeing_707-320|the 707-320C and the 3J19C]], which are downloaded and installed together as [[Boeing 707-320]]. The new version is based on the model of Innis Cunningham (already developed by Isaias Prestes). The gear and engines has been modified (with reversers), lights were added. The new versions have a detailed flightdeck, with working instruments, pedestal, etc. The FDM has ben re-writen in YASim.

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FlightGear on Google+ ===
The [https://plus.google.com/+flightgear FlightGear Google+ page] welcomed its 1000th plus this month! Please +1 us if you haven't already.

=== FlightGear on YouTube ===
The Viper project, that we mentioned in the [[FlightGear Newsletter January 2012#FlightGear users|January edition]] of the newsletter, is on airborne! Now we can see their good results.
{{#ev:youtube|8wcEz9SfcYQ}}
You'll find more videos on the official [https://sites.google.com/site/mf2012theviper/ Viper cockpit website].

Congratulations for that awesome project.

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
==== FGUK's Saturday Night Flights ====
''A work in progress''
[[File:FGUK-3rdNov12.jpg|270px|thumb|FGUK discovers there is nothing half so much worth doing than messing about in (flying) boats]]
[[File:FGUK-10thNov12.jpg|270px|thumb|Fast jets of FGUK leave the British winter behind for some fine-weather flying in Hawaii]]
[http://www.fguk.eu FGUK] rounded off November with four more memorable outings, forsaking the bleak winter scenery of the United Kingdom for the warmer climes of South and Pacific America before returning to the Lake District for some low flying exercises within easy flying distance of our home base of Llanbedr (EGOD).

We started the month by leaving the fast jets snug in their hangars and paddling out to board seaplanes and flying boats dating from the classic age of intercontinental flight to modern day transport and fire-fighting aircraft. The additional challenge of beginning our flight from Lake Titicaca, 12000 feet up on the Andean Altiplano, set regular FGUK fliers practicing hard during the preceding week, with some of the older aircraft requiring skill and patience to even start their engines in the thin air, and all pilots adjusting to the unusual and slightly tricky experience of taking off at altitude. Their efforts paid off, forming up around Flight Leader Algernon to skim the Andes before descending steadily down with the terrain to land in a flurry of surf off the Peruvian coast. This was almost certainly a collection of aircraft never seen flying before, with a truly gargantuan Hughes H4 Hercules (the ''Spruce Goose'') joining Canopus, the first Short S.23 'Empire' flying boat, a Bombardier 415 water-bomber, classically-beautiful Consolidated Catalina PBY and Grumman Goose among others.

Next week saw a return to a more traditional FGUK theme, with assorted fast jets hammering across somebody else's airspace. Flight Leader Neilson chose Hawaii for this flight, in order to showcase the new scenery package included in FGFS 2.8; it attracted a varied selection of fighters and ground attack aircraft including several classics from Dave Culp's hangar, which FGUK now hosts and maintains. Two F4 Phantoms, two F-15s (one C and one E) and a brace of Tornado GR4s shattered the peace of the island for two hours, at speeds high enough to require a refueling at Hilo. As is becoming standard now for all flight planners, Neilson put a good deal of preparation into this flight, with an illustrated flight plan and a downloadable Route Manager route available in advance of the event, and as always, our multimedia artists got to work during the following week to collate and shape their collected stills and video clips into galleries and movies, which are available in the FGUK media forum (see the link below).

The chance to hone some slightly rusty skills came the following week, with a theme surround a single aircraft, and one which is both famously capable and notoriously tricky to handle - the physics-defying BaE Harrier. As one of the great British aircraft of all time, the Harrier is well represented in the FGUK hangar and the pilots had several incarnations to choose from for this high-speed, low-level, cross-continental mission from Chile to Port Stanley. Planned and led by N-SCOT, the flight plan had some tricky twists, including employing the Harrier's ace card feature: its ability to operate away from traditional flight infrastructure, in this case, a beach refueling. One vertical take-off later, and the squadron was skimming the waves, headed southeast for Stanley at 200ft AGL. Reports that the first round in the Victory public house was purchased by StuartC are apparently without substance.

The last week of November took us closer to home when Moli organised a flight to the Lake District in the North of England. Departing Walney Island airfield (coincidentally the site of the first ever FGUK flying event back in 2010) were Hawker Hunters, Vought F-8 Crusaders, and an FGR2 among others. The weather was typically damp and grey, but with cockpit heaters turned up the low-level blast through the valleys and over the lakes was a success.

FGUK welcomes pilots from all corners of the FG universe to fly with us on a Saturday at 2000hrs UTC. Please check the [http://www.fguk.eu/forum/saturday-night-flying Saturday Night Flying subforum on our website] to find out where we will be gathering and whether there are any recommendations or requirements for aircraft, and address any questions to us there. We hope to see you in the skies!

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten.

=== Call for volunteers ===
* The [[Flightgear On Android]] team is looking for testers
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter|2012 12]]

FlightGear Newsletter December 2012

2012-12-10T21:20:55Z

Algernon: /* FGUK's Saturday Night Flights */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release.''

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]].

=== Atmospheric Light Scattering ===

The atmospheric light scattering rendering framework received a major overhaul. Snow is now generated procedurally, which improves the performance if no snow is in the scene, but also allows the user to control the thickness of the snow layer - the shader can do a very light snow cover like in the winter textures all the way to a closed, thick snow layer.

A new runway effect shader, similar to the one in the default rendering scheme, shows a hires bumpmap for runway closeups and displays also snow drifts in high resolution on the runway if the terrain at this altiude is snow-covered. This is complemented by a high resolution grass texture for the green around the runway.

Major changes have been done to the ambient lighting of terrain and clouds in low light - the previous ambient light curve has been replaced by a light curve measured from a large set of photographs of sunsets. As a result, the color balance of cloud shadows in low sunlight is now much more realistic, and the effect of clouds casting a shadow on other clouds is now also effectively accounted for.

In the course of these changes, the framework is now also able to render moonlit scenes at night, however this is not currently integrated to be done automatically.

[[File:Light scattering dec12 10.jpg|300px|Procedural snow and hires snow drifts on the runway.]]
[[File:Light scattering dec12 05.jpg|300px|Early morning scene over the French Alps.]]
[[File:Light scattering dec12 13.jpg|300px|New color balance of clouds in low light]]

Combined and fully integrated with Advanced Weather, Atmospheric Light Scattering is now able to render highly realistic lighting and high-quality scenery texturing, rivaling the visual quality of FSX.

=== Random Buildings ===


=== Project Rembrandt ===
=== Canvas System ===


=== High Level Architecture ===
=== FlightGear an Android ===

=== Usability Improvements ===

=== Mailing list digest ===

(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list or the git logs)

=== Forum digest ===

=== Git digest ===

=== Getting involved as a programmer ===

Please see [[Howto:Start core development]]

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Snapshot releases ==
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].

The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].

== Translators required ==
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.

=== New aircraft ===

=== Updated aircraft ===

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FlightGear on YouTube ===

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
==== FGUK's Saturday Night Flights ====
''A work in progress''
[[File:FGUK-3rdNov12.jpg|270px|thumb|FGUK discovers there is nothing half so much worth doing than messing about in (flying) boats]]
[[File:FGUK-10thNov12.jpg|270px|thumb|Fast jets of FGUK leave the British winter behind for some fine-weather flying in Hawaii]]
[http://www.fguk.eu FGUK] rounded off November with four more memorable outings, forsaking the bleak winter scenery of the United Kingdom for the warmer climes of South and Pacific America before returning to the Lake District for some low flying exercises within easy flying distance of our home base of Llanbedr (EGOD).

We started the month by leaving the fast jets snug in their hangars and paddling out to board seaplanes and flying boats dating from the classic age of intercontinental flight to modern day transport and fire-fighting aircraft. The additional challenge of beginning our flight from Lake Titicaca, 12000 feet up on the Andean Altiplano, set regular FGUK fliers practicing hard during the preceding week, with some of the older aircraft requiring skill and patience to even start their engines in the thin air, and all pilots adjusting to the unusual and slightly tricky experience of taking off at altitude. Their efforts paid off, forming up around Flight Leader Algernon to skim the Andes before descending steadily down with the terrain to land in a flurry of surf off the Peruvian coast. This was almost certainly a collection of aircraft never seen flying before, with a truly gargantuan Hughes H4 Hercules (the ''Spruce Goose'') joining Canopus, the first Short S.23 'Empire' flying boat, a Bombardier 415 water-bomber, classically-beautiful Consolidated Catalina PBY and Grumman Goose among others.

Next week saw a return to a more traditional FGUK theme, with assorted fast jets hammering across somebody else's airspace. Flight Leader Neilson chose Hawaii for this flight, in order to showcase the new scenery package included in FGFS 2.8; it attracted a varied selection of fighters and ground attack aircraft including several classics from Dave Culp's hangar, which FGUK now hosts and maintains. Two F4 Phantoms, two F-15s (one C and one E) and a brace of Tornado GR4s shattered the peace of the island for two hours, at speeds high enough to require a refueling at Hilo. As is becoming standard now for all flight planners, Neilson put a good deal of preparation into this flight, with an illustrated flight plan and a downloadable Route Manager route available in advance of the event, and as always, our multimedia artists got to work during the following week to collate and shape their collected stills and video clips into galleries and movies, which are available in the FGUK media forum (see the link below).

The chance to hone some slightly rusty skills came the following week, with a theme surround a single aircraft, and one which is both famously capable and notoriously tricky to handle - the physics-defying BaE Harrier. As one of the great British aircraft of all time, the Harrier is well represented in the FGUK hangar and the pilots had several incarnations to choose from for this high-speed, low-level, cross-continental mission from Chile to Port Stanley. Planned and led by N-SCOT, the flight plan had some tricky twists, including employing the Harrier's ace card feature: its ability to operate away from traditional flight infrastructure, in this case, a beach refueling. One vertical take-off later, and the squadron was skimming the waves, headed southeast for Stanley at 200ft AGL. Reports that the first round in the Victory public house was purchased by StuartC are apparently without substance.

''Still to come: A rainy flight in the Lakes, planned events for December, and how to get involved.''

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten.

=== Call for volunteers ===
* The [[Flightgear On Android]] team is looking for testers
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support
* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter|2012 12]]

FlightGear Newsletter December 2012

2012-12-10T17:48:11Z

Algernon: /* FGUK's Saturday Night Flights */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release.''

== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]].

=== Atmospheric Light Scattering ===

The atmospheric light scattering rendering framework received a major overhaul. Snow is now generated procedurally, which improves the performance if no snow is in the scene, but also allows the user to control the thickness of the snow layer - the shader can do a very light snow cover like in the winter textures all the way to a closed, thick snow layer.

A new runway effect shader, similar to the one in the default rendering scheme, shows a hires bumpmap for runway closeups and displays also snow drifts in high resolution on the runway if the terrain at this altiude is snow-covered. This is complemented by a high resolution grass texture for the green around the runway.

Major changes have been done to the ambient lighting of terrain and clouds in low light - the previous ambient light curve has been replaced by a light curve measured from a large set of photographs of sunsets. As a result, the color balance of cloud shadows in low sunlight is now much more realistic, and the effect of clouds casting a shadow on other clouds is now also effectively accounted for.

In the course of these changes, the framework is now also able to render moonlit scenes at night, however this is not currently integrated to be done automatically.

[[File:Light scattering dec12 10.jpg|300px|Procedural snow and hires snow drifts on the runway.]]
[[File:Light scattering dec12 05.jpg|300px|Early morning scene over the French Alps.]]
[[File:Light scattering dec12 13.jpg|300px|New color balance of clouds in low light]]

Combined and fully integrated with Advanced Weather, Atmospheric Light Scattering is now able to render highly realistic lighting and high-quality scenery texturing, rivaling the visual quality of FSX.

=== Random Buildings ===


=== Project Rembrandt ===
=== Canvas System ===


=== High Level Architecture ===
=== FlightGear an Android ===

=== Usability Improvements ===

=== Mailing list digest ===

(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list or the git logs)

=== Forum digest ===

=== Git digest ===

=== Getting involved as a programmer ===

Please see [[Howto:Start core development]]

== Release ChangeLog ==
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

== Interview with a contributor (NAME) ==
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''

* How long have you been involved in FlightGear?
* What are your major interests in FlightGear?
* What project are you working on right now?
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: [[Interview questions]].

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

== Snapshot releases ==
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].

The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].

== Translators required ==
{|
|[[File:en.gif]]
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].
|-
|[[File:de.gif]]
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File:nl.gif]]
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File:es.gif]]
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|}

== Nasal for newbies ==

== New software tools and projects ==

== FlightGear addons and mods ==

== In the hangar ==

All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.

=== New aircraft ===

=== Updated aircraft ===

=== Liveries ===

== Scenery corner ==
=== Airports ===

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==

== Suggested flights ==
== Aircraft reviews ==

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FlightGear on YouTube ===

=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
==== FGUK's Saturday Night Flights ====
''A work in progress''
[[File:FGUK-3rdNov12.jpg|270px|thumb|FGUK discovers there is nothing half so much worth doing than messing about in (flying) boats]]
[[File:FGUK-10thNov12.jpg|270px|thumb|Fast jets of FGUK leave the British winter behind for some fine-weather flying in Hawaii]]
[http://www.fguk.eu FGUK] rounded off November with four more memorable outings, forsaking the bleak winter scenery of the United Kingdom for the warmer climes of South and Pacific America before returning to the Lake District for some low flying exercises within easy flying distance of our home base of Llanbedr (EGOD).

We started the month by leaving the fast jets snug in their hangars and paddling out to board seaplanes and flying boats dating from the classic age of intercontinental flight to modern day transport and fire-fighting aircraft. The additional challenge of beginning our flight from Lake Titicaca, 12000 feet up on the Andean Altiplano, set regular FGUK fliers practicing hard during the preceding week, with some of the older aircraft requiring skill and patience to even start their engines in the thin air, and all pilots adjusting to the unusual and slightly tricky experience of taking off at altitude. Their efforts paid off, forming up around Flight Leader Algernon to skim the Andes before descending steadily down with the terrain to land in a flurry of surf off the Peruvian coast. This was almost certainly a collection of aircraft never seen flying before, with a truly gargantuan Hughes H4 Hercules (the ''Spruce Goose'') joining Canopus, the first Short S.23 'Empire' flying boat, a Bombardier 415 water-bomber, classically-beautiful Consolidated Catalina PBY and Grumman Goose among others.

Next week saw a return to a more traditional FGUK theme, with assorted fast jets hammering across somebody else's airspace. Flight Leader Neilson chose Hawaii for this flight, in order to showcase the new scenery package included in FGFS 2.8; it attracted a varied selection of fighters and ground attack aircraft including several classics from Dave Culp's hangar, which FGUK now hosts and maintains. Two F4 Phantoms, two F-15s (one C and one E) and a brace of Tornado GR4s shattered the peace of the island for two hours, at speeds high enough to require a refueling at Hilo. As is becoming standard now for all flight planners, Neilson put a good deal of preparation into this flight, with an illustrated flight plan and a downloadable Route Manager route available in advance of the event, and as always, our multimedia artists got to work during the following week to collate and shape their collected stills and video clips into galleries and movies, which are available in the FGUK media forum (see the link below).

The chance to hone some slightly rusty skills came the following week, with a theme surround a single aircraft, and one which is both famously capable and notoriously tricky to handle - the physics-defying BaE Harrier. As one of the great British aircraft of all time, the Harrier is well represented in the FGUK hangar and the pilots had several incarnations to choose from for this high-speed, low-level, cross-continental mission from Chile to Port Stanley. Planned and led by N-SCOT, the flight plan had some tricky twists, including employing the Harrier's ace card feature: its ability to operate away from traditional flight infrastructure, in this case, a beach refueling. One vertical take-off later, and the squadron was skimming the waves, headed southeast for Stanley at 200ft AGL. Reports that the first round in the Victory public house was purchased by StuartC are apparently without substance.

=== Virtual airlines ===
=== FlightGear events ===

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten.

=== Call for volunteers ===
* The [[Flightgear On Android]] team is looking for testers
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support
* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===

[[Category:FlightGear Newsletter|2012 12]]

File:FGUK-3rdNov12.jpg

2012-12-10T16:38:35Z

Algernon: /* {{int:filedesc}} */

=={{int:filedesc}}==
{{Information
|description={{en|1=FGUK pilots fly seaplanes and flying boats from Lake Titicata, 12000ft up in the Andes, down to the coast of Peru in November 2012}}
|date=2012-12-10
|source=FGUK Media Forum
|author=Neilson, an FGUK Contributor
|permission=
|other_versions=
|other_fields=
}}

=={{int:license-header}}==
{{FAL}}

FlightGear Newsletter December 2012

2012-12-10T16:37:06Z

Algernon: /* FGUK's Saturday Night Flights */

File:FGUK-10thNov12.jpg

2012-12-10T16:25:01Z

Algernon:

=={{int:filedesc}}==
{{Information
|description={{en|1=Fast jets of FGUK line up after flying in Hawaii, 10th December 2012}}
|date=2012-12-10
|source=FGUK Media Forum
|author=StuartC of FGUK
|permission=
|other_versions=
|other_fields=
}}

=={{int:license-header}}==
{{FAL}}

FlightGear Newsletter December 2012

2012-12-10T16:06:49Z

Algernon: /* Multiplayer */

File:FGUK-3rdNov12.jpg

2012-12-10T15:44:12Z

Algernon:

=={{int:filedesc}}==
{{Information
|description={{en|1=FGUK pilots fly seaplanes and flying boats from Lake Titicata, 12000ft up in the Andes, down to the coast of Chile in November 2012}}
|date=2012-12-10
|source=FGUK Media Forum
|author=Neilson, an FGUK Contributor
|permission=
|other_versions=
|other_fields=
}}

=={{int:license-header}}==
{{FAL}}

Eurofighter Typhoon: Development Documentation

2012-05-06T17:34:48Z

Algernon:

== Generic Multiplayer Properties ==

{| class="prettytable" border="1px" cellspacing="0" cellpadding="2"
!ID !! Property || Type(*) || Allocation
|-
|10100 || "sim/multiplay/generic/string[0]" || STRING ||
|-
|10101 || "sim/multiplay/generic/string[1]" || STRING
|-
|10102 || "sim/multiplay/generic/string[2]" || STRING
|-
|10103 || "sim/multiplay/generic/string[3]" || STRING
|-
|10104 || "sim/multiplay/generic/string[4]" || STRING
|-
|10105 || "sim/multiplay/generic/string[5]" || STRING
|-
|10106 || "sim/multiplay/generic/string[6]" || STRING
|-
|10107 || "sim/multiplay/generic/string[7]" || STRING
|-
|10108 || "sim/multiplay/generic/string[8]" || STRING
|-
|10109 || "sim/multiplay/generic/string[9]" || STRING
|-
|10110 || "sim/multiplay/generic/string[10]" || STRING
|-
|10111 || "sim/multiplay/generic/string[11]" || STRING
|-
|10112 || "sim/multiplay/generic/string[12]" || STRING
|-
|10113 || "sim/multiplay/generic/string[13]" || STRING
|-
|10114 || "sim/multiplay/generic/string[14]" || STRING
|-
|10115 || "sim/multiplay/generic/string[15]" || STRING
|-
|10116 || "sim/multiplay/generic/string[16]" || STRING
|-
|10117 || "sim/multiplay/generic/string[17]" || STRING
|-
|10118 || "sim/multiplay/generic/string[18]" || STRING
|-
|10119 || "sim/multiplay/generic/string[19]" || STRING
|-
|10200 || "sim/multiplay/generic/float[0]" || FLOAT
|-
|10201 || "sim/multiplay/generic/float[1]" || FLOAT
|-
|10202 || "sim/multiplay/generic/float[2]" || FLOAT
|-
|10203 || "sim/multiplay/generic/float[3]" || FLOAT
|-
|10204 || "sim/multiplay/generic/float[4]" || FLOAT
|-
|10205 || "sim/multiplay/generic/float[5]" || FLOAT
|-
|10206 || "sim/multiplay/generic/float[6]" || FLOAT
|-
|10207 || "sim/multiplay/generic/float[7]" || FLOAT
|-
|10208 || "sim/multiplay/generic/float[8]" || FLOAT || "/canopy/position-norm"
|-
|10209 || "sim/multiplay/generic/float[9]" || FLOAT
|-
|10210 || "sim/multiplay/generic/float[10]" || FLOAT
|-
|10211 || "sim/multiplay/generic/float[11]" || FLOAT
|-
|10212 || "sim/multiplay/generic/float[12]" || FLOAT
|-
|10213 || "sim/multiplay/generic/float[13]" || FLOAT
|-
|10214 || "sim/multiplay/generic/float[14]" || FLOAT
|-
|10215 || "sim/multiplay/generic/float[15]" || FLOAT
|-
|10216 || "sim/multiplay/generic/float[16]" || FLOAT
|-
|10217 || "sim/multiplay/generic/float[17]" || FLOAT
|-
|10218 || "sim/multiplay/generic/float[18]" || FLOAT
|-
|10219 || "sim/multiplay/generic/float[19]" || FLOAT
|-
|10300 || "sim/multiplay/generic/int[0]" || INT
|-
|10301 || "sim/multiplay/generic/int[1]" || INT || "/gear/gear[0]/tyre-smoke"
|-
|10302 || "sim/multiplay/generic/int[2]" || INT || "/gear/gear[1]/tyre-smoke"
|-
|10303 || "sim/multiplay/generic/int[3]" || INT || "/gear/gear[2]/tyre-smoke"
|-
|10304 || "sim/multiplay/generic/int[4]" || INT
|-
|10305 || "sim/multiplay/generic/int[5]" || INT
|-
|10306 || "sim/multiplay/generic/int[6]" || INT
|-
|10307 || "sim/multiplay/generic/int[7]" || INT
|-
|10308 || "sim/multiplay/generic/int[8]" || INT
|-
|10309 || "sim/multiplay/generic/int[9]" || INT
|-
|10310 || "sim/multiplay/generic/int[10]" || INT || "/engines/engine[0]/afterburner"
|-
|10311 || "sim/multiplay/generic/int[11]" || INT
|-
|10312 || "sim/multiplay/generic/int[12]" || INT
|-
|10313 || "sim/multiplay/generic/int[13]" || INT
|-
|10314 || "sim/multiplay/generic/int[14]" || INT
|-
|10315 || "sim/multiplay/generic/int[15]" || INT
|-
|10316 || "sim/multiplay/generic/int[16]" || INT
|-
|10317 || "sim/multiplay/generic/int[17]" || INT
|-
|10318 || "sim/multiplay/generic/int[18]" || INT
|-
|10319 || "sim/multiplay/generic/int[19]" || INT
|}

Eurofighter Typhoon: Development Documentation

2012-05-06T17:32:32Z

Algernon:

== Generic Multiplayer Properties ==

{| class="prettytable" border="1px" cellspacing="0" cellpadding="2"
!ID !! Property || Type(*) || Allocation
|-
|10100 || "sim/multiplay/generic/string[0]" || STRING ||
|-
|10101 || "sim/multiplay/generic/string[1]" || STRING
|-
|10102 || "sim/multiplay/generic/string[2]" || STRING
|-
|10103 || "sim/multiplay/generic/string[3]" || STRING
|-
|10104 || "sim/multiplay/generic/string[4]" || STRING
|-
|10105 || "sim/multiplay/generic/string[5]" || STRING
|-
|10106 || "sim/multiplay/generic/string[6]" || STRING
|-
|10107 || "sim/multiplay/generic/string[7]" || STRING
|-
|10108 || "sim/multiplay/generic/string[8]" || STRING
|-
|10109 || "sim/multiplay/generic/string[9]" || STRING
|-
|10110 || "sim/multiplay/generic/string[10]" || STRING
|-
|10111 || "sim/multiplay/generic/string[11]" || STRING
|-
|10112 || "sim/multiplay/generic/string[12]" || STRING
|-
|10113 || "sim/multiplay/generic/string[13]" || STRING
|-
|10114 || "sim/multiplay/generic/string[14]" || STRING
|-
|10115 || "sim/multiplay/generic/string[15]" || STRING
|-
|10116 || "sim/multiplay/generic/string[16]" || STRING
|-
|10117 || "sim/multiplay/generic/string[17]" || STRING
|-
|10118 || "sim/multiplay/generic/string[18]" || STRING
|-
|10119 || "sim/multiplay/generic/string[19]" || STRING
|-
|10200 || "sim/multiplay/generic/float[0]" || FLOAT
|-
|10201 || "sim/multiplay/generic/float[1]" || FLOAT
|-
|10202 || "sim/multiplay/generic/float[2]" || FLOAT
|-
|10203 || "sim/multiplay/generic/float[3]" || FLOAT
|-
|10204 || "sim/multiplay/generic/float[4]" || FLOAT
|-
|10205 || "sim/multiplay/generic/float[5]" || FLOAT
|-
|10206 || "sim/multiplay/generic/float[6]" || FLOAT
|-
|10207 || "sim/multiplay/generic/float[7]" || FLOAT
|-
|10208 || "sim/multiplay/generic/float[8]" || FLOAT
|-
|10209 || "sim/multiplay/generic/float[9]" || FLOAT
|-
|10210 || "sim/multiplay/generic/float[10]" || FLOAT
|-
|10211 || "sim/multiplay/generic/float[11]" || FLOAT
|-
|10212 || "sim/multiplay/generic/float[12]" || FLOAT
|-
|10213 || "sim/multiplay/generic/float[13]" || FLOAT
|-
|10214 || "sim/multiplay/generic/float[14]" || FLOAT
|-
|10215 || "sim/multiplay/generic/float[15]" || FLOAT
|-
|10216 || "sim/multiplay/generic/float[16]" || FLOAT
|-
|10217 || "sim/multiplay/generic/float[17]" || FLOAT
|-
|10218 || "sim/multiplay/generic/float[18]" || FLOAT
|-
|10219 || "sim/multiplay/generic/float[19]" || FLOAT
|-
|10300 || "sim/multiplay/generic/int[0]" || INT
|-
|10301 || "sim/multiplay/generic/int[1]" || INT || "/gear/gear[0]/tyre-smoke"
|-
|10302 || "sim/multiplay/generic/int[2]" || INT || "/gear/gear[1]/tyre-smoke"
|-
|10303 || "sim/multiplay/generic/int[3]" || INT || "/gear/gear[2]/tyre-smoke"
|-
|10304 || "sim/multiplay/generic/int[4]" || INT
|-
|10305 || "sim/multiplay/generic/int[5]" || INT
|-
|10306 || "sim/multiplay/generic/int[6]" || INT
|-
|10307 || "sim/multiplay/generic/int[7]" || INT
|-
|10308 || "sim/multiplay/generic/int[8]" || INT
|-
|10309 || "sim/multiplay/generic/int[9]" || INT
|-
|10310 || "sim/multiplay/generic/int[10]" || INT || "/engines/engine[0]/afterburner"
|-
|10311 || "sim/multiplay/generic/int[11]" || INT
|-
|10312 || "sim/multiplay/generic/int[12]" || INT
|-
|10313 || "sim/multiplay/generic/int[13]" || INT
|-
|10314 || "sim/multiplay/generic/int[14]" || INT
|-
|10315 || "sim/multiplay/generic/int[15]" || INT
|-
|10316 || "sim/multiplay/generic/int[16]" || INT
|-
|10317 || "sim/multiplay/generic/int[17]" || INT
|-
|10318 || "sim/multiplay/generic/int[18]" || INT
|-
|10319 || "sim/multiplay/generic/int[19]" || INT
|}

Eurofighter Typhoon: Development Documentation

2012-05-06T16:50:49Z

Algernon: Created page with " == Generic Multiplayer Properties == {| class="prettytable" border="1px" cellspacing="0" cellpadding="2" !ID !! Property ..."

== Generic Multiplayer Properties ==

{| class="prettytable" border="1px" cellspacing="0" cellpadding="2"
!ID !! Property || Type(*)
|-
|10100 || "sim/multiplay/generic/string[0]" || STRING
|-
|10101 || "sim/multiplay/generic/string[1]" || STRING
|-
|10102 || "sim/multiplay/generic/string[2]" || STRING
|-
|10103 || "sim/multiplay/generic/string[3]" || STRING
|-
|10104 || "sim/multiplay/generic/string[4]" || STRING
|-
|10105 || "sim/multiplay/generic/string[5]" || STRING
|-
|10106 || "sim/multiplay/generic/string[6]" || STRING
|-
|10107 || "sim/multiplay/generic/string[7]" || STRING
|-
|10108 || "sim/multiplay/generic/string[8]" || STRING
|-
|10109 || "sim/multiplay/generic/string[9]" || STRING
|-
|10110 || "sim/multiplay/generic/string[10]" || STRING
|-
|10111 || "sim/multiplay/generic/string[11]" || STRING
|-
|10112 || "sim/multiplay/generic/string[12]" || STRING
|-
|10113 || "sim/multiplay/generic/string[13]" || STRING
|-
|10114 || "sim/multiplay/generic/string[14]" || STRING
|-
|10115 || "sim/multiplay/generic/string[15]" || STRING
|-
|10116 || "sim/multiplay/generic/string[16]" || STRING
|-
|10117 || "sim/multiplay/generic/string[17]" || STRING
|-
|10118 || "sim/multiplay/generic/string[18]" || STRING
|-
|10119 || "sim/multiplay/generic/string[19]" || STRING
|-
|10200 || "sim/multiplay/generic/float[0]" || FLOAT
|-
|10201 || "sim/multiplay/generic/float[1]" || FLOAT
|-
|10202 || "sim/multiplay/generic/float[2]" || FLOAT
|-
|10203 || "sim/multiplay/generic/float[3]" || FLOAT
|-
|10204 || "sim/multiplay/generic/float[4]" || FLOAT
|-
|10205 || "sim/multiplay/generic/float[5]" || FLOAT
|-
|10206 || "sim/multiplay/generic/float[6]" || FLOAT
|-
|10207 || "sim/multiplay/generic/float[7]" || FLOAT
|-
|10208 || "sim/multiplay/generic/float[8]" || FLOAT
|-
|10209 || "sim/multiplay/generic/float[9]" || FLOAT
|-
|10210 || "sim/multiplay/generic/float[10]" || FLOAT
|-
|10211 || "sim/multiplay/generic/float[11]" || FLOAT
|-
|10212 || "sim/multiplay/generic/float[12]" || FLOAT
|-
|10213 || "sim/multiplay/generic/float[13]" || FLOAT
|-
|10214 || "sim/multiplay/generic/float[14]" || FLOAT
|-
|10215 || "sim/multiplay/generic/float[15]" || FLOAT
|-
|10216 || "sim/multiplay/generic/float[16]" || FLOAT
|-
|10217 || "sim/multiplay/generic/float[17]" || FLOAT
|-
|10218 || "sim/multiplay/generic/float[18]" || FLOAT
|-
|10219 || "sim/multiplay/generic/float[19]" || FLOAT
|-
|10300 || "sim/multiplay/generic/int[0]" || INT
|-
|10301 || "sim/multiplay/generic/int[1]" || INT
|-
|10302 || "sim/multiplay/generic/int[2]" || INT
|-
|10303 || "sim/multiplay/generic/int[3]" || INT
|-
|10304 || "sim/multiplay/generic/int[4]" || INT
|-
|10305 || "sim/multiplay/generic/int[5]" || INT
|-
|10306 || "sim/multiplay/generic/int[6]" || INT
|-
|10307 || "sim/multiplay/generic/int[7]" || INT
|-
|10308 || "sim/multiplay/generic/int[8]" || INT
|-
|10309 || "sim/multiplay/generic/int[9]" || INT
|-
|10310 || "sim/multiplay/generic/int[10]" || INT
|-
|10311 || "sim/multiplay/generic/int[11]" || INT
|-
|10312 || "sim/multiplay/generic/int[12]" || INT
|-
|10313 || "sim/multiplay/generic/int[13]" || INT
|-
|10314 || "sim/multiplay/generic/int[14]" || INT
|-
|10315 || "sim/multiplay/generic/int[15]" || INT
|-
|10316 || "sim/multiplay/generic/int[16]" || INT
|-
|10317 || "sim/multiplay/generic/int[17]" || INT
|-
|10318 || "sim/multiplay/generic/int[18]" || INT
|-
|10319 || "sim/multiplay/generic/int[19]" || INT
|}

Eurofighter Typhoon: Flight Manual

2012-05-04T12:11:51Z

Algernon:

''This document is a work in progress. We aim to produce a concise guide to flying the Eurofighter Typhoon and operating its systems. Keep checking back - as things are added to the aircraft, so they'll be documented here - we hope to make these updates in a timely manner, ideally when new versions of the aircraft are released.

'''Please note that some versions of the aircraft are not currently undergoing development, owing to limitations within earlier versions of FlightGear, and functions described in this document may not exist or work as described. To make the most use of the aircraft's newest features, please use the latest versions of both FlightGear and the Typhoon'''

== Introduction ==
The [[Eurofighter Typhoon]] is an agile, multirole combat aircraft designed upon relaxed stability principles.

=== Acknowledgements ===
Eurofighter Typhoon for FlightGear was developed by Maverick Alex, DFaber, Almursi, Algernon, Aster and other contributors.
This document initialised by --[[User:Algernon|Algernon]] 16:28, 28 June 2011 (EDT)

=== Develop & Customise ===
See [[Eurofighter Typhoon: Development Documentation]]

== Flight Controls ==
The aircraft is controlled via stick, throttle and rudder pedals, whose motions are processed by the Flight Control System and appropriate signals are passed to the flight control surfaces, the canards, flaperons and rudder.

=== Flight Control System ===

The FCS can be bypassed, but this is not recommended under normal flight conditions.

=== Ground Controls ===
On the ground, the Typhoon is steered by a castering nosewheel whose maximum angle and steering ratio decreases as ground speed increases. The main gear is equipped with speed brakes and parking brakes, and ground braking is assisted at ground speeds above 50kts by the canard, which rotates fully forward to act as an air brake.

== Avionics ==
===Head Up Display===
===Multi-Fuction Head Down Displays===
===Manual Data Entry Facility===
The MDEF is located on the left glareshield, above and left of the left-hand MFHDD. It consists of a bank of Autopilot Keys (diagonal and top-right, and SubSystem Keys. The 12 keys on the left select the desired page to be displayed on the 12 softkeys on the right, through which the navigation, defensive and communications equipment is programmed and controlled. Available pages are:
*'''MIDS''': Multi-function Information Display System - select MIDS page
*'''NAV''': Navgiation Subsystem - Access Route Manager ('''RTE MGR'''), adjust route, lock altitude hold to Route Manager altitude instructions ('''NAV ALT''')
*'''AIDS''': Navigation Aids - Select steering bug to heading, Nav (Route Manager) Mode ('''NAV MODE''') or Tacan Mode ('''TACN MODE'''); switch Tacan power.
*'''NIS''': NATO Identification Systems - not yet functional
*'''INT''': Interrogator - select interrogator on or standby ('''INT SBY/ON'''), select interrogation mode (available modes are Modes 1, 2, 3A, 4A and S, plus Mode C.
*'''XPDR''': Transponder - select transponder on or standby ('''XPDR SBY/ON'''), select modes to on or standby, enter codes for Modes 1 & 3A ('''1/3A CODE''')
*'''XMIT''': Transmitters - switch aircraft radio systems between normal and silent modes for stealth operations.
*'''RAD1''': Radio 1 - Channel and function select; select Radio 1 as active radio ('''RAD1 ACTV/MON''')
*'''RAD2''': Radio 2 - Channel and function select; select Radio 2 as active radio ('''RAD2 ACTV/MON''')
*'''DAS''': Defensive Aids Subsystem
*'''MISC''': Miscellaneous Functions

== Navigation ==
=== Nav Aids ===
Navigational assistance is provided by the Navigation Computer, guiding the pilot along a heading, route or beam using information from the two primary navigation systems, [[Route Manager]] (NAV) and [[TACAN]]. Course information is displayed on the HUD, ASI and MFHDDs, as well as commanding the autopilot when engaged in track mode. The course to steer is indicated by the steering bug, an incomplete circle located on the HUD heading ribbon. If the required course is beyond the scope of the ribbon, the bug will park indicating the direction in which to steer. The bug can be hidden by pressing the BUG OFF softkey in the AIDS subsystem; it will reappear when either navigation system is selected.

Control of navigational aids is through the AIDS subsystem page on the MDEF. Switching between NAV and TACAN modes is controlled by pressing NAV MODE or TACN MODE; the selected system is indicated by a lit button.

'''NAV Mode''' directs the flight along a route of waypoints, which can be created, saved and loaded in Route Manager. Waypoints can contain altitude instructions as well as lateral fix information. NAV Mode functions are controlled through the NAV subsystem softkeys. When a route is active in Route Manager, next waypoint information (Waypoint ID, bearing, rang and time-to-target) is displayed in the lower left section of the HUD.

'''TACN Mode''' directs the flight towards a TACAN or VORTAC station, or another aircraft equipped to transmit TACAN. TACAN functions are controlled through the AIDS subsystem softkeys. When the TACAN transceiver is active, the TACAN channel is displayed on the lower right section of the HUD; additional information (TACAN station ID, bearing and distance) is displayed when the selected TACAN station is in range.

=== Autopilot ===
Autopilot modes are selected using the keys located at the top of the MDEF. There are two lateral and two vertical modes, three advanced modes and an autothrottle. Any active autopilot mode is indicated by a lit AP button; clicking this button cancels the lateral and vertical modes. The autothrottle is activated and deactivated using the AT button, which is lit when the autothrottle is operating.
==== Lateral Modes ====
There are two principal lateral modes, Heading ('''HDG''') and Track ('''TRK'''), selectable on the MDEF. Heading mode directs the aircraft on a set magnetic heading. Track Mode directs the aircraft according to the instructions of the navigation computer.
==== Vertical Modes ====
==== Advanced Modes ====
Autoclimb ('''CLM''') automatically gains altitude at the most efficient climb rate to the set altitude. Auto Attack ('''ATK''') flies automatically in pursuit of another aircraft, selected by the targeting computer. ''These modes are not yet functional''

== Radar ==
=== CAPTOR ===
=== Transponder ===
=== Interrogator ===

== Communications ==
The Typhoon has two VHF radios, Radio 1 and Radio 2, which are managed by the '''Communications and Audio Management Unit (CAMU)''' and operated via the MDEF and MIDS panels. There are ten channels available: Ch1 and Ch2 are preset to the two FGCom global frequencies, Ch 3 - Ch 8 can be user preset (data is stored in the Data/channels.xml file), and there are two manual frequency channels, M1 and M2, settable in the Typhoon RadioComms dialog. The radio controls support the optional [[User:Tuxklok|dual FGCom configuration]], where two channels can be monitored and one selected as active for transmission. If not installed, only RAD1 is available for use.

Channel information is displayed on the COMM page of the MIDS display, and the pilot can scroll through channels and select the active radio using the MIDS softkeys. Direct channel selection can be made using the RAD1 and RAD2 pages of the MDEF. The channel list can be viewed on any HDD on the FREQ page, and selected channels are also shown on the MIDS HOME page.

Eurofighter Typhoon: Flight Manual

2011-11-13T05:13:44Z

Algernon: /* Acknowledgements */

''This document is a work in progress. We aim to produce a concise guide to flying the Eurofighter Typhoon and operating its systems. Keep checking back - as things are added to the aircraft, so they'll be documented here - we hope to make these updates in a timely manner, ideally when new versions of the aircraft are released.

'''Please note that some versions of the aircraft are not currently undergoing development, owing to limitations within earlier versions of FlightGear, and functions described in this document may not exist or work as described. To make the most use of the aircraft's newest features, please use the latest versions of both FlightGear and the Typhoon'''

== Introduction ==
The [[Eurofighter Typhoon]] is an agile, multirole combat aircraft designed upon relaxed stability principles.

=== Acknowledgements ===
Eurofighter Typhoon for FlightGear was developed by Maverick Alex, DFaber, Almursi, Algernon, Aster and other contributors.
This document initialised by --[[User:Algernon|Algernon]] 16:28, 28 June 2011 (EDT)

=== Develop & Customise ===
See [[Eurofighter Typhoon: Development Documentation]]

== Flight Controls ==
The aircraft is controlled via stick, throttle and rudder pedals, whose motions are processed by the Flight Control System and appropriate signals are passed to the flight control surfaces, the canards, flaperons and rudder.

=== Flight Control System ===

The FCS can be bypassed, but this is not recommended under normal flight conditions.

== Avionics ==
===Head Up Display===
===Multi-Fuction Head Down Displays===
===Manual Data Entry Facility===
The MDEF is located on the left glareshield, above and left of the left-hand MFHDD. It consists of a bank of Autopilot Keys (diagonal and top-right, and SubSystem Keys. The 12 keys on the left select the desired page to be displayed on the 12 softkeys on the right, through which the navigation, defensive and communications equipment is programmed and controlled. Available pages are:
*'''MIDS''': Multi-function Information Display System - select MIDS page
*'''NAV''': Navgiation Subsystem - Access Route Manager ('''RTE MGR'''), adjust route, lock altitude hold to Route Manager altitude instructions ('''NAV ALT''')
*'''AIDS''': Navigation Aids - Select steering bug to heading, Nav (Route Manager) Mode ('''NAV MODE''') or Tacan Mode ('''TACN MODE'''); switch Tacan power.
*'''NIS''': NATO Identification Systems - not yet functional
*'''INT''': Interrogator - select interrogator on or standby ('''INT SBY/ON'''), select interrogation mode (available modes are Modes 1, 2, 3A, 4A and S, plus Mode C.
*'''XPDR''': Transponder - select transponder on or standby ('''XPDR SBY/ON'''), select modes to on or standby, enter codes for Modes 1 & 3A ('''1/3A CODE''')
*'''XMIT''': Transmitters - switch aircraft radio systems between normal and silent modes for stealth operations.
*'''RAD1''': Radio 1 - Channel and function select; select Radio 1 as active radio ('''RAD1 ACTV/MON''')
*'''RAD2''': Radio 2 - Channel and function select; select Radio 2 as active radio ('''RAD2 ACTV/MON''')
*'''DAS''': Defensive Aids Subsystem
*'''MISC''': Miscellaneous Functions

== Navigation ==
=== Nav Aids ===
Navigational assistance is provided by the Navigation Computer, guiding the pilot along a heading, route or beam using information from the two primary navigation systems, [[Route Manager]] (NAV) and [[TACAN]]. Course information is displayed on the HUD, ASI and MFHDDs, as well as commanding the autopilot when engaged in track mode. The course to steer is indicated by the steering bug, an incomplete circle located on the HUD heading ribbon. If the required course is beyond the scope of the ribbon, the bug will park indicating the direction in which to steer. The bug can be hidden by pressing the BUG OFF softkey in the AIDS subsystem; it will reappear when either navigation system is selected.

Control of navigational aids is through the AIDS subsystem page on the MDEF. Switching between NAV and TACAN modes is controlled by pressing NAV MODE or TACN MODE; the selected system is indicated by a lit button.

'''NAV Mode''' directs the flight along a route of waypoints, which can be created, saved and loaded in Route Manager. Waypoints can contain altitude instructions as well as lateral fix information. NAV Mode functions are controlled through the NAV subsystem softkeys. When a route is active in Route Manager, next waypoint information (Waypoint ID, bearing, rang and time-to-target) is displayed in the lower left section of the HUD.

'''TACN Mode''' directs the flight towards a TACAN or VORTAC station, or another aircraft equipped to transmit TACAN. TACAN functions are controlled through the AIDS subsystem softkeys. When the TACAN transceiver is active, the TACAN channel is displayed on the lower right section of the HUD; additional information (TACAN station ID, bearing and distance) is displayed when the selected TACAN station is in range.

=== Autopilot ===
Autopilot modes are selected using the keys located at the top of the MDEF. There are two lateral and two vertical modes, three advanced modes and an autothrottle. Any active autopilot mode is indicated by a lit AP button; clicking this button cancels the lateral and vertical modes. The autothrottle is activated and deactivated using the AT button, which is lit when the autothrottle is operating.
==== Lateral Modes ====
There are two principal lateral modes, Heading ('''HDG''') and Track ('''TRK'''), selectable on the MDEF. Heading mode directs the aircraft on a set magnetic heading. Track Mode directs the aircraft according to the instructions of the navigation computer.
==== Vertical Modes ====
==== Advanced Modes ====
Autoclimb ('''CLM''') automatically gains altitude at the most efficient climb rate to the set altitude. Auto Attack ('''ATK''') flies automatically in pursuit of another aircraft, selected by the targeting computer. ''These modes are not yet functional''

== Radar ==
=== CAPTOR ===
=== Transponder ===
=== Interrogator ===

== Communications ==
The Typhoon has two VHF radios, Radio 1 and Radio 2, which are managed by the '''Communications and Audio Management Unit (CAMU)''' and operated via the MDEF and MIDS panels. There are ten channels available: Ch1 and Ch2 are preset to the two FGCom global frequencies, Ch 3 - Ch 8 can be user preset (data is stored in the Data/channels.xml file), and there are two manual frequency channels, M1 and M2, settable in the Typhoon RadioComms dialog. The radio controls support the optional [[User:Tuxklok|dual FGCom configuration]], where two channels can be monitored and one selected as active for transmission. If not installed, only RAD1 is available for use.

Channel information is displayed on the COMM page of the MIDS display, and the pilot can scroll through channels and select the active radio using the MIDS softkeys. Direct channel selection can be made using the RAD1 and RAD2 pages of the MDEF. The channel list can be viewed on any HDD on the FREQ page, and selected channels are also shown on the MIDS HOME page.

Eurofighter Typhoon: Flight Manual

2011-11-13T05:04:05Z

Algernon: /* Manual Data Entry Facility */

''This document is a work in progress. We aim to produce a concise guide to flying the Eurofighter Typhoon and operating its systems. Keep checking back - as things are added to the aircraft, so they'll be documented here - we hope to make these updates in a timely manner, ideally when new versions of the aircraft are released.

'''Please note that some versions of the aircraft are not currently undergoing development, owing to limitations within earlier versions of FlightGear, and functions described in this document may not exist or work as described. To make the most use of the aircraft's newest features, please use the latest versions of both FlightGear and the Typhoon'''

== Introduction ==
The [[Eurofighter Typhoon]] is an agile, multirole combat aircraft designed upon relaxed stability principles.

=== Acknowledgements ===
Eurofighter Typhoon for FlightGear was developed by Maverick Alex, DFaber, Almursi, Algernon and other contributors.
This document initialised by --[[User:Algernon|Algernon]] 16:28, 28 June 2011 (EDT)

=== Develop & Customise ===
See [[Eurofighter Typhoon: Development Documentation]]

== Flight Controls ==
The aircraft is controlled via stick, throttle and rudder pedals, whose motions are processed by the Flight Control System and appropriate signals are passed to the flight control surfaces, the canards, flaperons and rudder.

=== Flight Control System ===

The FCS can be bypassed, but this is not recommended under normal flight conditions.

== Avionics ==
===Head Up Display===
===Multi-Fuction Head Down Displays===
===Manual Data Entry Facility===
The MDEF is located on the left glareshield, above and left of the left-hand MFHDD. It consists of a bank of Autopilot Keys (diagonal and top-right, and SubSystem Keys. The 12 keys on the left select the desired page to be displayed on the 12 softkeys on the right, through which the navigation, defensive and communications equipment is programmed and controlled. Available pages are:
*'''MIDS''': Multi-function Information Display System - select MIDS page
*'''NAV''': Navgiation Subsystem - Access Route Manager ('''RTE MGR'''), adjust route, lock altitude hold to Route Manager altitude instructions ('''NAV ALT''')
*'''AIDS''': Navigation Aids - Select steering bug to heading, Nav (Route Manager) Mode ('''NAV MODE''') or Tacan Mode ('''TACN MODE'''); switch Tacan power.
*'''NIS''': NATO Identification Systems - not yet functional
*'''INT''': Interrogator - select interrogator on or standby ('''INT SBY/ON'''), select interrogation mode (available modes are Modes 1, 2, 3A, 4A and S, plus Mode C.
*'''XPDR''': Transponder - select transponder on or standby ('''XPDR SBY/ON'''), select modes to on or standby, enter codes for Modes 1 & 3A ('''1/3A CODE''')
*'''XMIT''': Transmitters - switch aircraft radio systems between normal and silent modes for stealth operations.
*'''RAD1''': Radio 1 - Channel and function select; select Radio 1 as active radio ('''RAD1 ACTV/MON''')
*'''RAD2''': Radio 2 - Channel and function select; select Radio 2 as active radio ('''RAD2 ACTV/MON''')
*'''DAS''': Defensive Aids Subsystem
*'''MISC''': Miscellaneous Functions

== Navigation ==
=== Nav Aids ===
Navigational assistance is provided by the Navigation Computer, guiding the pilot along a heading, route or beam using information from the two primary navigation systems, [[Route Manager]] (NAV) and [[TACAN]]. Course information is displayed on the HUD, ASI and MFHDDs, as well as commanding the autopilot when engaged in track mode. The course to steer is indicated by the steering bug, an incomplete circle located on the HUD heading ribbon. If the required course is beyond the scope of the ribbon, the bug will park indicating the direction in which to steer. The bug can be hidden by pressing the BUG OFF softkey in the AIDS subsystem; it will reappear when either navigation system is selected.

Control of navigational aids is through the AIDS subsystem page on the MDEF. Switching between NAV and TACAN modes is controlled by pressing NAV MODE or TACN MODE; the selected system is indicated by a lit button.

'''NAV Mode''' directs the flight along a route of waypoints, which can be created, saved and loaded in Route Manager. Waypoints can contain altitude instructions as well as lateral fix information. NAV Mode functions are controlled through the NAV subsystem softkeys. When a route is active in Route Manager, next waypoint information (Waypoint ID, bearing, rang and time-to-target) is displayed in the lower left section of the HUD.

'''TACN Mode''' directs the flight towards a TACAN or VORTAC station, or another aircraft equipped to transmit TACAN. TACAN functions are controlled through the AIDS subsystem softkeys. When the TACAN transceiver is active, the TACAN channel is displayed on the lower right section of the HUD; additional information (TACAN station ID, bearing and distance) is displayed when the selected TACAN station is in range.

=== Autopilot ===
Autopilot modes are selected using the keys located at the top of the MDEF. There are two lateral and two vertical modes, three advanced modes and an autothrottle. Any active autopilot mode is indicated by a lit AP button; clicking this button cancels the lateral and vertical modes. The autothrottle is activated and deactivated using the AT button, which is lit when the autothrottle is operating.
==== Lateral Modes ====
There are two principal lateral modes, Heading ('''HDG''') and Track ('''TRK'''), selectable on the MDEF. Heading mode directs the aircraft on a set magnetic heading. Track Mode directs the aircraft according to the instructions of the navigation computer.
==== Vertical Modes ====
==== Advanced Modes ====
Autoclimb ('''CLM''') automatically gains altitude at the most efficient climb rate to the set altitude. Auto Attack ('''ATK''') flies automatically in pursuit of another aircraft, selected by the targeting computer. ''These modes are not yet functional''

== Radar ==
=== CAPTOR ===
=== Transponder ===
=== Interrogator ===

== Communications ==
The Typhoon has two VHF radios, Radio 1 and Radio 2, which are managed by the '''Communications and Audio Management Unit (CAMU)''' and operated via the MDEF and MIDS panels. There are ten channels available: Ch1 and Ch2 are preset to the two FGCom global frequencies, Ch 3 - Ch 8 can be user preset (data is stored in the Data/channels.xml file), and there are two manual frequency channels, M1 and M2, settable in the Typhoon RadioComms dialog. The radio controls support the optional [[User:Tuxklok|dual FGCom configuration]], where two channels can be monitored and one selected as active for transmission. If not installed, only RAD1 is available for use.

Channel information is displayed on the COMM page of the MIDS display, and the pilot can scroll through channels and select the active radio using the MIDS softkeys. Direct channel selection can be made using the RAD1 and RAD2 pages of the MDEF. The channel list can be viewed on any HDD on the FREQ page, and selected channels are also shown on the MIDS HOME page.

Eurofighter Typhoon: Flight Manual

2011-11-13T05:01:50Z

Algernon: /* Communications */

''This document is a work in progress. We aim to produce a concise guide to flying the Eurofighter Typhoon and operating its systems. Keep checking back - as things are added to the aircraft, so they'll be documented here - we hope to make these updates in a timely manner, ideally when new versions of the aircraft are released.

'''Please note that some versions of the aircraft are not currently undergoing development, owing to limitations within earlier versions of FlightGear, and functions described in this document may not exist or work as described. To make the most use of the aircraft's newest features, please use the latest versions of both FlightGear and the Typhoon'''

== Introduction ==
The [[Eurofighter Typhoon]] is an agile, multirole combat aircraft designed upon relaxed stability principles.

=== Acknowledgements ===
Eurofighter Typhoon for FlightGear was developed by Maverick Alex, DFaber, Almursi, Algernon and other contributors.
This document initialised by --[[User:Algernon|Algernon]] 16:28, 28 June 2011 (EDT)

=== Develop & Customise ===
See [[Eurofighter Typhoon: Development Documentation]]

== Flight Controls ==
The aircraft is controlled via stick, throttle and rudder pedals, whose motions are processed by the Flight Control System and appropriate signals are passed to the flight control surfaces, the canards, flaperons and rudder.

=== Flight Control System ===

The FCS can be bypassed, but this is not recommended under normal flight conditions.

== Avionics ==
===Head Up Display===
===Multi-Fuction Head Down Displays===
===Manual Data Entry Facility===
The MDEF is located on the left glareshield, above and left of the left-hand MFHDD. It consists of a bank of Autopilot Keys (diagonal and top-right, and SubSystem Keys. The 12 keys on the left select the desired page to be displayed on the 12 softkeys on the right, through which the navigation, defensive and communications equipment is programmed and controlled. Available pages are:
*'''MIDS''': Multi-function Information Display System - not yet functional
*'''NAV''': Navgiation Subsystem - Access Route Manager ('''RTE MGR'''), adjust route, lock altitude hold to Route Manager altitude instructions ('''NAV ALT''')
*'''AIDS''': Navigation Aids - Select steering bug to heading, Nav (Route Manager) Mode ('''NAV MODE''') or Tacan Mode ('''TACN MODE'''); switch Tacan power.
*'''NIS''': NATO Identification Systems - not yet functional
*'''INT''': Interrogator - select interrogator on or standby ('''INT SBY/ON'''), select interrogation mode (available modes are Modes 1, 2, 3A, 4A and S, plus Mode C.
*'''XPDR''': Transponder - select transponder on or standby ('''XPDR SBY/ON'''), select modes to on or standby, enter codes for Modes 1 & 3A ('''1/3A CODE''')
*'''XMIT''': Transmitters - switch aircraft radio systems between normal and silent modes for stealth operations.
*'''RAD1''': Radio 1 - Channel and function select; select Radio 1 as active radio ('''RAD1 ACTV/MON''')
*'''RAD2''': Radio 2 - Channel and function select; select Radio 2 as active radio ('''RAD2 ACTV/MON''')
*'''DAS''': Defensive Aids Subsystem
*'''MISC''': Miscellaneous Functions

== Navigation ==
=== Nav Aids ===
Navigational assistance is provided by the Navigation Computer, guiding the pilot along a heading, route or beam using information from the two primary navigation systems, [[Route Manager]] (NAV) and [[TACAN]]. Course information is displayed on the HUD, ASI and MFHDDs, as well as commanding the autopilot when engaged in track mode. The course to steer is indicated by the steering bug, an incomplete circle located on the HUD heading ribbon. If the required course is beyond the scope of the ribbon, the bug will park indicating the direction in which to steer. The bug can be hidden by pressing the BUG OFF softkey in the AIDS subsystem; it will reappear when either navigation system is selected.

Control of navigational aids is through the AIDS subsystem page on the MDEF. Switching between NAV and TACAN modes is controlled by pressing NAV MODE or TACN MODE; the selected system is indicated by a lit button.

'''NAV Mode''' directs the flight along a route of waypoints, which can be created, saved and loaded in Route Manager. Waypoints can contain altitude instructions as well as lateral fix information. NAV Mode functions are controlled through the NAV subsystem softkeys. When a route is active in Route Manager, next waypoint information (Waypoint ID, bearing, rang and time-to-target) is displayed in the lower left section of the HUD.

'''TACN Mode''' directs the flight towards a TACAN or VORTAC station, or another aircraft equipped to transmit TACAN. TACAN functions are controlled through the AIDS subsystem softkeys. When the TACAN transceiver is active, the TACAN channel is displayed on the lower right section of the HUD; additional information (TACAN station ID, bearing and distance) is displayed when the selected TACAN station is in range.

=== Autopilot ===
Autopilot modes are selected using the keys located at the top of the MDEF. There are two lateral and two vertical modes, three advanced modes and an autothrottle. Any active autopilot mode is indicated by a lit AP button; clicking this button cancels the lateral and vertical modes. The autothrottle is activated and deactivated using the AT button, which is lit when the autothrottle is operating.
==== Lateral Modes ====
There are two principal lateral modes, Heading ('''HDG''') and Track ('''TRK'''), selectable on the MDEF. Heading mode directs the aircraft on a set magnetic heading. Track Mode directs the aircraft according to the instructions of the navigation computer.
==== Vertical Modes ====
==== Advanced Modes ====
Autoclimb ('''CLM''') automatically gains altitude at the most efficient climb rate to the set altitude. Auto Attack ('''ATK''') flies automatically in pursuit of another aircraft, selected by the targeting computer. ''These modes are not yet functional''

== Radar ==
=== CAPTOR ===
=== Transponder ===
=== Interrogator ===

== Communications ==
The Typhoon has two VHF radios, Radio 1 and Radio 2, which are managed by the '''Communications and Audio Management Unit (CAMU)''' and operated via the MDEF and MIDS panels. There are ten channels available: Ch1 and Ch2 are preset to the two FGCom global frequencies, Ch 3 - Ch 8 can be user preset (data is stored in the Data/channels.xml file), and there are two manual frequency channels, M1 and M2, settable in the Typhoon RadioComms dialog. The radio controls support the optional [[User:Tuxklok|dual FGCom configuration]], where two channels can be monitored and one selected as active for transmission. If not installed, only RAD1 is available for use.

Channel information is displayed on the COMM page of the MIDS display, and the pilot can scroll through channels and select the active radio using the MIDS softkeys. Direct channel selection can be made using the RAD1 and RAD2 pages of the MDEF. The channel list can be viewed on any HDD on the FREQ page, and selected channels are also shown on the MIDS HOME page.