FlightGear wiki - User contributions [en]

Conditions

2015-05-21T04:22:18Z

Philosopher: yes you can use strings too. Note that it does not guarantee type conversion: if the left one is a string, there will be no numeric comparison

{{Stub}}
'''Conditions''' (or '''SGConditions''') in the SimGear library are a property-based representation of custom conditions based on comparing property values. They can be evaluated from both C++ and Nasal (see simgear/props/condition.hxx and [[$FG_ROOT]]/Nasal/props.nas). Comparison of string-typed properties involves lexicographic ordering, as specified by the C++ operators <tt><</tt> and <tt>></tt>.

== Usage ==
Conditions are supported in
* All [[bindings]], all [[animations]]
* State machines
* Various parts of [[HUD]]s, 2D panels
And several other places.

== Sample Expressions ==
This is a sample expression for checking if the throttle on the first engine is above half:
<syntaxhighlight lang="xml">
<condition>
<greater-than>
<property>/controls/engines/engine[0]/throttle</property>
<value type="double">0.5</value>
</greater-than>
</condition>
</syntaxhighlight>

== Supported elements ==
Each comparison (like less-than or greater-than-equals) requires either two <tt><property></tt> elements (the first with index=0 and the second with index=1) or a <tt><property></tt> (considered first) and <tt><value></tt> (considered second); booleans compare each of their child conditions. A <tt><condition></tt> element itself functions as an <tt><and></tt> element; that is, it can have several children, all of which must be true to make the whole condition true.
<syntaxhighlight lang="xml" enclose="div">
<and>
<or>
<not> 
<equals>
<not-equals>
<less-than>
<greater-than>
<less-than-equals>
<greater-than-equals>
<property> 
</syntaxhighlight>

== Related content ==
=== Readme file ===
* {{readme file|conditions}}

=== Source code ===
* {{repo link
| site = sf
| proj = flightgear/simgear
| path = next/tree/simgear/props/condition.hxx
| text = simgear/props/condition.hxx
}}
* {{repo link
| site = sf
| proj = flightgear/simgear
| path = next/tree/simgear/props/condition.cxx
| text = simgear/props/condition.cxx
}}

[[Category:FlightGear]]
[[Category:XML]]

Conditions

2015-05-21T04:17:06Z

Philosopher: /* Supported elements */ rephrase/grammar/code-language mix

{{Stub}}
'''Conditions''' (or '''SGConditions''') in the SimGear library are a property-based representation of custom conditions based on comparing property values. They can be evaluated from both C++ and Nasal (see simgear/props/condition.hxx and [[$FG_ROOT]]/Nasal/props.nas).

== Usage ==
Conditions are supported in
* All [[bindings]], all [[animations]]
* State machines
* Various parts of [[HUD]]s, 2D panels
And several other places.

== Sample Expressions ==
This is a sample expression for checking if the throttle on the first engine is above half:
<syntaxhighlight lang="xml">
<condition>
<greater-than>
<property>/controls/engines/engine[0]/throttle</property>
<value type="double">0.5</value>
</greater-than>
</condition>
</syntaxhighlight>

== Supported elements ==
Each comparison (like less-than or greater-than-equals) requires either two <tt><property></tt> elements (the first with index=0 and the second with index=1) or a <tt><property></tt> (considered first) and <tt><value></tt> (considered second); booleans compare each of their child conditions. A <tt><condition></tt> element itself functions as an <tt><and></tt> element; that is, it can have several children, all of which must be true to make the whole condition true.
<syntaxhighlight lang="xml" enclose="div">
<and>
<or>
<not> 
<equals>
<not-equals>
<less-than>
<greater-than>
<less-than-equals>
<greater-than-equals>
<property> 
</syntaxhighlight>

== Related content ==
=== Readme file ===
* {{readme file|conditions}}

=== Source code ===
* {{repo link
| site = sf
| proj = flightgear/simgear
| path = next/tree/simgear/props/condition.hxx
| text = simgear/props/condition.hxx
}}
* {{repo link
| site = sf
| proj = flightgear/simgear
| path = next/tree/simgear/props/condition.cxx
| text = simgear/props/condition.cxx
}}

[[Category:FlightGear]]
[[Category:XML]]

Howto:Use vectors and foreach loops to write shorter code

2015-01-07T15:19:50Z

Philosopher: use separate arguments to setprop() instead of concatenation

{{Nasal Navigation}}

* Last updated: 02/2012
* Contributors: Omega95, Hooray

Objective: Demonstrate how the use of [[Nasal]] vectors and foreach loops may help to create shorter and less redundant Nasal code.

Consider the following snippet of code, taken from [[Howto: Implement a Flight Management Computer in Nasal]].

<syntaxhighlight lang="nasal">
setprop("/controls/cdu[" ~ cdu ~ "]/l1-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/l2-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/l3-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/l4-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/l5-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/l6-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/l7-type", "click");
</syntaxhighlight>

As you can see, this is a fairly repetitive piece of code, which could be easily generalized, so that only a single setprop() call is used in a loop (foreach). It could be rewritten like this:

<syntaxhighlight lang="nasal">
var lines = ["l1-type", "l2-type", "l3-type", "l4-type", "l5-type", "l6-type", "l7-type"];
foreach(var line; lines) {
setprop("/controls/cdu", cdu, line, "click");
}

</syntaxhighlight>

Then, you could also use a small helper function (method):

<syntaxhighlight lang="nasal">
var init_lines= func {
var lines = ["l1-type", "l2-type", "l3-type", "l4-type", "l5-type", "l6-type", "l7-type"];
foreach(var line; lines) {
setprop("/controls/cdu", cdu, line, "click");
}
}
</syntaxhighlight>

The nice thing is, that we get less code, which is more general - i.e. it will be much easier to change things later on, so that support for more CDU/FMC lines could be added easily for example.

Now, when looking through the code in [[Howto: Implement a Flight Management Computer in Nasal]], we can find more code, which looks fairly similar:

<syntaxhighlight lang="nasal">
setprop("/controls/cdu[" ~ cdu ~ "]/r1-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/r2-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/r3-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/r4-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/r5-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/r6-type", "click");
setprop("/controls/cdu[" ~ cdu ~ "]/r7-type", "click");
</syntaxhighlight>

The only thing different here is that we have "r1..r7-type" rather than "l1..l7". So, we could just take our previous function and generalize it some more:

<syntaxhighlight lang="nasal">
var init_cdu_types= func(what) {
foreach(var w; what) {
setprop("/controls/cdu", cdu, w, "click");
}
}
</syntaxhighlight>

This could now be easily called during initialization to set up the properties like this:

<syntaxhighlight lang="nasal">
var lines = ["l1-type", "l2-type", "l3-type", "l4-type", "l5-type", "l6-type", "l7-type"];
init_cdu_types(lines);

var lines = ["r1-type", "r2-type", "r3-type", "r4-type", "r5-type", "r6-type", "r7-type"];
init_cdu_types(lines);
</syntaxhighlight>

Now, looking further through the code, there are more opportunities to generalize our little helper function:

<syntaxhighlight lang="nasal">
## Field Values
setprop("/controls/cdu[" ~ cdu ~ "]/display/l1-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/l2-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/l3-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/l4-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/l5-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/l6-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/l7-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/r1-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/r2-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/r3-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/r4-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/r5-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/r6-label", "");
setprop("/controls/cdu[" ~ cdu ~ "]/display/r7-label", "");
</syntaxhighlight>

The only thing that's different here, is the final setprop argument - which is empty in this case, so we could just change our function to support an additional argument:

<syntaxhighlight lang="nasal">
var init_cdu_types= func(what,value="click") {
foreach(var w; what) {
setprop("/controls/cdu", cdu, w, value);
}
}
</syntaxhighlight>

Note, that we have provided a default value here (which is "click"), so that the previous function calls don't need to be changed.

With the changes in place, our init code could be made even shorter:

<syntaxhighlight lang="nasal">
var lines = ["l1-type", "l2-type", "l3-type", "l4-type", "l5-type", "l6-type", "l7-type"];
init_cdu_types(lines);

var lines = ["r1-type", "r2-type", "r3-type", "r4-type", "r5-type", "r6-type", "r7-type"];
init_cdu_types(lines);

var lines = ["/display/l1-label", "/display/l2-label", "/display/l3-label", "/display/l4-label", "/display/l5-label","/display/l6-label", "/display/l7-label","/display/r1-label", "/display/r2-label", "/display/r3-label", "/display/r4-label", "/display/r5-label","/display/r6-label", "/display/r7-label"];
init_cdu_types(lines,"");
</syntaxhighlight>

Obviously, there are some more opportunities - such as automatically creating these vectors, too. Which is also trivial to do:

<syntaxhighlight lang="nasal">
var create_with_suffix = func(prefix,start,end,suffix) {
var result = [];
for (var i=start;i<=end;i+=1) {
var s= prefix ~ i ~ suffix;
append(result,s);
}
return result;
}
</syntaxhighlight>

So, now we have a helper function, which automatically creates these vectors. Which can be used like this:

<syntaxhighlight lang="nasal">
var left = create_with_suffix('l',1,7,'-type');
var right = create_with_suffix('r',1,7,'-type');

var display_right = create_with_suffix('display/l',1,7,'-label');
var display_left = create_with_suffix('display/r',1,7,'-label');

init_cdu_types(left);
init_cdu_types(right);
init_cdu_types(display_right);
init_cdu_types(display_left);
</syntaxhighlight>

[[Category:Nasal howto]]

Canvas snippets

2014-09-14T20:15:40Z

Philosopher: /* Canvas Input Dialog */ great idea!

{{Stub}}
{{WIP}}

{{Canvas Navigation}}

== Creating a Canvas GUI Window ==
{{Note|This example uses so called method chaining, if you're not familiar with the concept, please see: [[Object_Oriented_Programming_with_Nasal#More_on_methods:_Chaining|Method Chaining]].}}

[[File:Snippets-canvas-dialog.png|thumb|This is what the [[Nasal]]/[[Canvas]] snippet will look like once you pasted it into the [[Nasal Console]] and click "Execute".]]

<syntaxhighlight lang="nasal" enclose="div">
# 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().setColorBackground(1,1,1,1);

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

== Canvas Input Dialog ==

<syntaxhighlight lang="nasal" enclose="div">
# create a new InputDialog with a title, label, and a callback
canvas.InputDialog.getText("Input Dialog Title", "Please enter some text", func(btn,value) {
if (value) gui.popupTip("You entered: "~value);
});
</syntaxhighlight>

PLIB

2014-08-31T12:42:34Z

Philosopher: Library GPL -> Lesser GPL ;-), note on Canvas' eventual replacement (soon!) of PUI

'''PLIB''' (Portable Game Library) is a set of software libraries for writing games written by Steve J. Baker. [[FlightGear]] has used PLIB for most of its development. It is also used by the FlightGear related program [[Atlas]]. PLIB is open source and released under Lesser GNU Public License (LGPL).

[[FlightGear 1.0.0]] (released in 2007) was the last public release to use PLIB for the 3d scene graph, before the the transition to OpenSceneGraph ([[OSG]]). FlightGear still uses PLIB for various tasks, for example reading joystick inputs and showing a graphical user interface (GUI). In the latter usage, the PUI component of PLIB will be replaced in FlightGear with [[Canvas|Canvas 2D rendering subsystem]] and [[Nasal|Nasal scripting]] to improve the GUI beyond what PUI offers.

PLIB is needed when building [[FlightGear]].

== PLIB libraries ==
* Picoscopic User Interface Library (PUI)
* Sound Library (SL)
* Standard Geometry Library(SG)
* Simple Scene Graph Library (SSG)
* PUI Auxiliary Library (PUAUX)
* SSG Auxiliary Library (SSGA)
* Joystick wrappers (JS)
* Fonts'n'Text Library (FNT)
* Utility Library (UL)
* Pegasus Network Library (NET)
* PLIB Scripting Language (PSL)
* PLIB Windowing Library (PW)

== Recommended version ==
Even if version 1.8.5, shipped with most of the GNU/Linux distributions, does work for FlightGear and related software, it is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended] to use the latest source from its SVN repo:
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h

== Link ==
* http://plib.sourceforge.net/index.html

[[pt:PLIB]]
[[Category:Software]]

$FG ROOT

2014-08-28T16:34:24Z

Philosopher:

'''$FG_ROOT''' is refered to as the main directory of [[FlightGear]], containing the so called ''base package'' (default [[aircraft]] and [[scenery]], [[Menubar|GUI]] files etc). When running FlightGear from a [[command line]], you can set $FG_ROOT via <tt>--fg-root=path/to/root</tt>. In [[FGRun]], it is set on the paths page, previous to the aircraft selection page.

As of FlightGear 2.4, it is advised to install additional scenery and aircraft in [[$FG_SCENERY]] and [[$FG_AIRCRAFT]] directories outside $FG_ROOT. This allow for maintaining the additional stuff when installing a new version of FlightGear.

=== Common paths ===
* '''Mac OS X:''' <tt>Applications/FlightGear.app/Contents/Resources/data/</tt> (right-click on FlightGear.app and select "Show Package Contents" to see the Contents folder)
: $FG_ROOT is not installed automatically. See [[New to FlightGear#Installing on Mac OS X|New to FlightGear]] for an installation manual.
* '''Ubuntu:''' <tt>/usr/share/games/flightgear/</tt>
* '''Windows:''' <tt>Program Files\FlightGear\data\</tt> (default, '''see note!''')
: Newer Windows versions are very, very protective about the <tt>Program Files</tt> folder and installing FlightGear into this folder makes it prone to any problems relating to file read/write permissions. Hence, installing FlightGear into <tt>Program Files</tt> on Windows Vista and later is not recommended.

[[Category:Special directories|ROOT]]

[[de:$FG ROOT]]
[[fr:$FG ROOT]]
[[nl:$FG_ROOT]]
[[es:$FG_ROOT]]

Howto:Install scenery

2014-08-28T16:29:40Z

Philosopher: /* Technical */ +commandline option, formatting

{{installing}}

[[Image:High_textures_transitions3.png|thumb|High detail France scenery]]
[[Image:High_textures_transitions4_1.png|thumb|High detail France scenery]]
[[Image:High_textures_transitions6_2.png|thumb|High detail France scenery]]

FlightGear comes with a limited set of [[scenery]]. Apart from the Bay Area around San Francisco (including the default airport [[KSFO]]), additional scenery can be installed by the user. If you locate yourself at an airport and see nothing but water, you probably did not install that scenery area (correctly).

== Obtaining scenery ==
You can download the official [[World Scenery]] terrain from the [http://www.flightgear.org/Downloads/scenery FlightGear website]. Alternatively, custom scenery is available for certain specific areas. They are distributed separately due to their license, or because their level of detail is not suitable for low-end machines. See [[Suggested Airports/Scenery]] for a list of custom scenery projects.

There is also a 4 DVD set available for download via [http://www.torrentbox.com/download/59050/FlightGear_4_DVD_Disk-set.torrent BitTorrent], which can be a higher performance option for those wanting to download the entire world. And, last but not least, it can be purchased as 3 DVD set from the [http://www.flightgear.org/dvd/ official FlightGear website].

=== TerraSync ===
[[TerraSync]] is a very useful utility that automatically downloads and installs needed FlightGear scenery and keeps it up to date while the simulator is running.

=== TerraMaster ===
[[File:TerraMaster r32 - Global view.png|thumb|TerraSync scenery in TerraMaster]]
[[TerraMaster]] is a scenery manager that basically is a frontend for TerraSync but that also makes it easier to maintain and get a good overview of downloaded TerraSync scenery. It is a crossplatform graphical application written in Java.

TerraMaster allows the FlightGear user to manage scenery tiles easily, selecting which tiles to add (by download), delete, and view the downloaded/not yet downloaded tiles at a glance. TerraMaster is highly recommended not only for managing scenery tiles easily especially if you are downloading and managing scenery from a computer that does not have FlightGear installed. The downloaded tiles are put into a folder which can then be copied into the FlightGear directory later on to complete the scenery.

Learn more about the [[TerraMaster]] tool.

=== Downloading from mirrors ===
A list of mirrors can be found [http://www.flightgear.org/mirrors.html#ftp here].

On most of the mirrors, the latest scenery can be found under <tt>Scenery-2.0.0/</tt>. Downloading from mirrors is often better than the official site, because mirrors are sometimes faster and have more user capacity. Use the [http://www.flightgear.org/Downloads/scenery graphical interface] to find the appropriate chunk. Be careful about confusing N with S, and E with W!!
Here is how to find an airport's co-ordinates:

# Go to the Wikipedia page for the airport in question (for example, PHNL for Honolulu)
# Find the co-ordinates (often at the top or right and side, marked with a small globe)
#* e.g. PHNL is in 21 N 157 W. If it's in the western hemisphere, you should round it up... so you should find the block with W160N20 If the co-ords were 21 N 157 E, you would round it '''down'''.. meaning that this location would be E150N20.

=== Downloading with BitTorrent ===
There is a torrent file hosted on http://www.terasaur.org which you can [http://terasaur.org/torrent/download/ae22ec86209fb14cb143a968be5ba8d3bebd7d6f/Scenery-v2.10.torrent find here]. There is also an alternative torrent (only added a new announcement URL) with a strong seed [http://flightgear.mxchange.org:23456/file?info_hash=%AE%22%EC%86%20%9F%B1L%B1C%A9h%BE%5B%A8%D3%BE%BD%7Do available].

Please note that these downloads are currently for version 2.10 and that you should download the matching launcher, too.

== Installing scenery ==
You can optionally use a GUI installer, called [[FlightGear Admin Wizard|FGAdmin]], to (un)install scenery.

=== GNU/Linux ===
If you are under a Linux operation system and you are not using a graphical interface to extract the tar archive, you can use one of the two following set of commands in a shell terminal.

cd SceneryDirectory
tar -xvzf input_file.tgz

or

tar -xvzf 'input_file.tgz' -C SceneryDirectory

In the above two examples, it is supposed that <tt>SceneryDirectory</tt> is set to a directory, outside <tt>[[$FG_ROOT]]</tt> (see [[#Technical]] for the reasoning behind this). Additionally, <tt>input_file.tgz</tt> should be substituted with the filename of the archive to be extracted (the filename should be completed with the full pathname or any other valid method so that the shell could find the correct archive).

=== Windows ===
Simply unpack the downloaded scenery into a directory of choice, outside the <tt>[[$FG_ROOT]]</tt> directory (see [[#Technical]] for the reasoning behind this), using software like [http://www.winzip.com/ Winzip] or [http://www.7-zip.org 7-zip]. Once done, append this directory to [[$FG_SCENERY]]. When using the [[FlightGear Wizard]], you can do so on the first page (previous from aircraft selection). Do not forget to press the "Refresh" button on the airport selection page, when using the wizard.

'''Note:''' More recent Windows versions (e.g. XP, Vista, Win7) tinkering a lot with user rights on access level. Therefore it is a bad idea to install and run FlightGear (scenery) to and from <tt>C:\Program Files</tt>. Find another drive/folder where you, as logged in user, have all neccesary right to read, write and execute the files you installed. Additionally there's a space / blank in folder's name which could cause weird behaviour. Using <tt>C:\FlightGear</tt> is a nice option.

=== Macintosh ===
Unpack the tgz file either by double-clicking it and moving the resulting wXXXnXXX folder to the Scenery folder described in the next line, or on the command line:
tar -xvzf 'input_file.tgz' -C /Applications/FlightGear.app/Contents/Resources/data/Scenery

== Technical ==
Scenery for FlightGear is determined by looking at the environment variable [[$FG SCENERY]]. Should the paths in $FG_SCENERY not be valid, FlightGear falls back to <tt>[[$FG ROOT]]/Scenery</tt>.

Mixing scenery types is almost universally a bad idea, and is unsupported. In this connection you should note that the scenery packaged with the base package/windows installer may not be the latest scenery.

For this reason it's probably better to extract scenery files you've downloaded into a new folder, which we'll call, for the sake of this exercise, <tt>$FOOBAR/Scenery</tt>.
In this directory, create two subdirectories: /Objects and /Terrain. You should untar individual files into the /Terrain folder.

Then you should set up $FG_SCENERY to use the new path:
* On POSIX Clients
*: <tt>set FG_SCENERY="$FOOBAR/Scenery" + FG_SCENERY</tt>
* On Windows (FGRun)
*: Go back to the first page of fgrun, and add the <tt>$FOOBAR/Scenery</tt> folder to the list.
* Via a commandline option
*: <tt>--fg-scenery="$FOOBAR/Scenery"</tt>

=== Terrain ===
The Scenery directory will show the following (scenery is shown for completeness and for easy reference to above):

<tt>
* Scenery/
** Terrain/
*** w130n30/
** Objects/
*** w130n30/
</tt>

If you download a scenery module called w90n40.tgz from [http://flightgear.org/Downloads/scenery-1.0.1.html flightgear.org] and extract it in Scenery, the result will resemble something like the following:

<tt>
* Scenery/
** Terrain/
*** w09n40/
*** w130n30/
** Objects/
*** w09n40/
*** w130n30/
</tt>

Note that the directory structure is already present in the tar archive, starting from the Scenery directory. Note that you have to extract the tar archive in the Scenery directory, not in the FG_ROOT directory, because the Scenery directory is not present in the archive.

=== Objects ===
Objects and models can be found at the [http://scenemodels.flightgear.org/ FlightGear Scenery Objects Database].

These objects are included in each scenery release, but as the object database is more frequently updated than the terrain, one may want to occasionally update the Object subdirectory from the FlightGear Scenery Objects Database between scenery releases.
Another option is to download or update the scenery on-demand by using the terrasync program described below.

Objects are really part of the scenery and can be found in the Scenery directory under [[$FG ROOT]].

<tt>
* Scenery/
** Objects/
*** w130n30/
</tt>

Any objects should be installed under the <tt>Scenery/Objects</tt> directory.

=== Models ===
Replaces the former <tt>[[$FG_ROOT]]/Models</tt>; stores all the shared objects.

<tt>
* Scenery/
** Models/
*** Airport/
</tt>

=== Airports ===
{{Main article|About Scenery/Airports}}
As of FlightGear 2.4.0, this directory is used to extract airport data (like runway usage and parking spots) from.

The directory tree might look somewhat overwhelming, but it simply follows the <tt>Airports/[I]/[C]/[A]/</tt> code (see [[ICAO-code]]).
<tt>
* Scenery/
** Airports/
*** K/
**** S/
***** F/
</tt>

== Related content ==
* [[Scenery FAQ]]

[[de:Howto:Install_scenery]]
[[es:Instalación de escenarios]]
[[fr:Installer une scène]]
[[Nl:Scenery installeren]]
[[PL:Instalowanie scenerii]]
[[pt:Instalando Cenário]]

[[Category:Scenery]]

FGx

2014-08-07T14:22:50Z

Philosopher: Redirected page to FGX

#REDIRECT [[FGX]]

FlightGear Mac OS X Launcher

2014-08-07T14:22:11Z

Philosopher: +issue 1521; thanks for the help Johan!

{{stub}}

{{caution|This launcher is unmaintained and may not work properly. It is anticipated to no longer work at all in OS X version 10.10 "Yosemite" and beyond (see {{issue|1521}}). For an alternative, see [[FGo!]] or [[FGx]], among others.

FlightGear can also be launched via the command line (Terminal.app) from the same binary distribution, e.g.
<syntaxhighlight lang="bash">cd /Applications/FlightGear.app/Contents/Resources
./fgfs.sh
</syntaxhighlight>}}

[[File:FlightGear Mac OS X Screenshot.png|right]]

'''FlightGear Mac OS X Launcher''' is a graphical front end for [[FlightGear]], included in official Mac binaries of [[FlightGear 0.9.10]], [[FlightGear 1.0|1.0.0]], [[Flightgear 1.9.0|1.9.0]], and [[FlightGear 2.0.0|2.0.0]] through [[Flightgear 3.2.0|3.2.0]] releases. The launcher allows one to choose options more easily than with the command line.

[[Category:FlightGear front ends]]

FlightGear Mac OS X Launcher

2014-08-07T04:31:40Z

Philosopher: this page needs an update... poor launcher

{{stub}}

{{Note|This launcher is unmaintained and may not work properly. It is anticipated to no longer work at all in OS X version 10.10 "Yosemite" and beyond. For an alternative, see [[FGo!]] or [[FGx]], among others. It can also be launched via the commandline (Terminal.app) from the same binary distribution, e.g.
<syntaxhighlight lang="bash">cd /Applications/FlightGear.app/Contents/Resources
./fgfs.sh
</syntaxhighlight>}}

'''FlightGear Mac OS X Launcher''' is a graphical front end for [[FlightGear]], included in official Mac binaries of [[FlightGear 0.9.10]], [[FlightGear 1.0|1.0.0]], [[Flightgear 1.9.0|1.9.0]], and [[FlightGear 2.0.0|2.0.0]] through [[Flightgear 3.2.0|3.2.0]] releases. The launcher allows one to choose options more easily than with the command line.

[[File:FlightGear Mac OS X Screenshot.png|right]]

Talk:Failure Manager

2014-08-07T03:10:09Z

Philosopher:

== Backwards compatibilty ==

Things to consider:

- aircraft that depend on what is in the dialog today, and how it writes to serviceable properties and makes some properties read-only.

If we just remove all default failures, these aircraft, which might not be actively maintained, all of a sudden will lose all failure management, unless it is custom coded.

Maybe planes using the new system could set a property such as: <failure-system><version>2</version></failure-system>
That would give the new system, with no predefined failures, and not specifying anything will give the old, with its predefined failures. [[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 22:18, 6 February 2014 (UTC)

:: You've hit the nail on the head with this one. Can we please have the old way as default, with the new way as an option? along with correct behaviour of <nasal><FailureManager>false</FailureManager></nasal> in autosave.xml . ??? Thanks for nothing btw.
::No, I don't want to use your super duper mega fancy failure manager, and I set it to off and I expect to have the normal, old behaviour, so my simple failure manager works as expected, but no, if I set it to off everything's broken, because someone thought it might be fancy to have it that way...

:: [[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 17:10, 4 August 2014 (UTC)


:::@i4dnf: It should be possible to disable the module using standard mechanisms, and while enabled, the module should be fully backwards compatible. I wrote this part explicitly for handling backwards compatibility: [https://gitorious.org/fg/fgdata/source/509f210cd0c6a544c62be2986a10ace23f485784:Aircraft/Generic/Systems/compat_failure_modes.nas Aircraft/Generic/Systems/compat_failure_modes.nas]. I have opened a discussion in your talk page so we can work out what is missing. --[[User:Galvedro|Galvedro]] ([[User talk:Galvedro|talk]]) 12:13, 6 August 2014 (UTC)

:::: There are two big issues, besides the fundamental one of making a 'complex' piece of code mandatory for simple stuff (but that's another talk).
:::: 1: Failure to set sane defaults and provide for normal operation with the module disabled -> disabling the module leaves all 'serviceable' properties in the failed state, instead of the sane/failsafe default of true.
:::: 2: Moving properties around, changing ui items and their effect on the property tree, without proper notification/announcement (and no, i don't mean 3rd word 157th line of some obscure forum post), e.g. moving the /gear/serviceable flag to its new location. I get it that stuff is/was in disarray, but such a move should not be done overnight/pre-release and without even telling (I had to dig into the git history to see what's going on there). Given the 'age' of the original property location it is likely that aircraft might depend on it (the location of their repository is irrelevant), and such a change would break them. There are numerous examples of how this change should be handled on the devel ML.
:::: Thanks for considering these. ''Hopefully you'll also consider the possibility that not everybody wants/needs to use your code, and in many cases it's overkill.''
:::: Also keep in mind that there are many aircraft maintained outside of fgdata, and in the future it's very likely there will be no aircraft maintained in fgdata anymore (except ufo and c172p)
::::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 00:49, 7 August 2014 (UTC)

::::::: "''Also keep in mind that there are many aircraft maintained outside of fgdata, and in the future it's very likely there will be no aircraft maintained in fgdata anymore (except ufo and c172p)''"
:::::: While this might be literally true, it really isn't – I'm 100% sure there will always be a "main FG" repository of aircraft which have nowhere else to go, while certain actively-maintained aircraft could go to their respective hangars (i.e. stay there). There is a point to centrality (i.e. knowing where to find things and easy access to those) that I'm sure won't be neglected, even in the event of a potential FGData split or similar.
:::::: [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 03:10, 7 August 2014 (UTC)
:::::: P.S. How is 2 months "''overnight/pre-release''"? That's a whole third of the release cycle, plus as previously stated, it was intended to be backwards compatible – I checked the c172p and Seneca II (IIRC) myself – and it's also in the [[Changelog 3.2]], so quit your griping.

::My plan for handling backwards compatibility, as can be seen in the roadmap section, is to load the compat script explicitly from every aircraft at some point. This will provide them with the same set of failure modes that they currently have. Unmaintained planes will remain that way, and those being actively maintained will be able to replace the compat script and start tailoring failure mode support to what the aircraft can actually handle. --[[User:Galvedro|Galvedro]] ([[User talk:Galvedro|talk]]) 12:13, 6 August 2014 (UTC)

== GUI instruments ==

The GUI contains instruments, such as radio, transponder, GPS, map etc.

Should these have a failure mode, or maybe an option inside the dialog to include them as failures? (not sure if any of them currently depend on any serviceable/read-only properties. [[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 22:18, 6 February 2014 (UTC)

== Prototype dialog ==

I can make a prototype dialog, to show how I imagine the dialog to look, and then we can discuss it from there?

In my opinion there should only be 1 dialog, which includes failures, and setting random failures, instead of 3 dialogs, like today. That could be done with tabs. [[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 22:18, 6 February 2014 (UTC)

== Failing ground equipment ==

I have just skimmed through the code to have an idea of what's involved.

The problem I see right away is that there are different animals covered under the SGSubsystem umbrella. At the very least, there are a) core sim modules, like ephemeris and sound, and b) cockpit instruments and systems. The SGSubsystem interface is in my opinion, a bit overkill for the b) category in some aspects (the initialization stuff, for example), and it falls short in others (i.e. connectivity). This is something I wanted to investigate and see if it would be beneficial (and acceptable) to separate SGSubsystem into more explicit interfaces.

Regarding failure management there is another problem in the code. The current standard IO interface for built-in instruments and systems is the property tree. Those that implement failure modes, do so via a "serviceable" property. That means that they don't care about C++ interfaces, rather, they rely on conventions. Adding an interface derived from Subsystem would not improve the the situation in this case.

Additionally, navaids and such are not accessible as Subsystem objects by themselves, but as pieces of information gathered from the navaid cache (if I followed the code correctly). If we forced a FailableSubsystem interface, the interface would apply to the entire navdb, which means that the interface will not be as simple as:

FailableSubsystem::set_failure_level(int level);

It would have to be more complex, also in order to allow non trivial subsystems to implement more than one failure mode.

Given this, as a first step, what I would do in order to support navaid failure would be to expose a simplified NavDataCache interface to Nasal and either

a) implement a "failure_actuator", as I call them in the current prototype, that sets the navaid range down to zero on failure, or
b) implement a NavDataCache::fail_navaid(id) that would be exposed to Nasal, possibly together with a few other calls, now we are at it.

The easy way to do it I guess it would be to create a NavDataCache Facade class with a reduced interface suitable for Nasal, and then use cppbind to expose the class to scripting interface. Somethig like that..

[[User:Galvedro|Galvedro]] ([[User talk:Galvedro|talk]]) Thu Feb 06, 2014 8:31 pm

User talk:Hvengel

2014-07-14T13:55:03Z

Philosopher: /* Spinner animation */ Nasal

== Spinner animation ==

Hi. I've duplicated the spinner for each of the stages of the propeller animation (blades, blurred blades, disk ), as each of these spins at a different rate. It's the cheapest way to solve the issue, and it avoids having extra bits of code laying around (I generally avoid having nasal involved if there's a viable solution without it). Some will argue it's a quick job in 5 lines of nasal, well 5 lines of nasal add up, and can become quite the issue as the extra-500 bears witness (it is unflyable here and elsewhere due to the low fps, as everything is waiting on the nasal scripts).

[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 09:09, 11 July 2014 (UTC)

Like you I avoid Nasal if there is an XML way to handle things. With a JSBSim FDM you can do a lot of things in XML that require Nasal in a YASim aircraft and, at least for a JSBSim FDM, you should almost never need Nasal for animations unless they are VERY complex or are not FDM specific (IE. intended for use in any aircraft regardless of FDM). The K-14A gun sight reticle animations are an example of something complex enough to be beyond doing it with XML only but it is also intended to be FDM independent as well so using JSBSim to drive the animations was not an option.

Also in JSBSim you can setup XML functions specifically to drive animations. For example, I do this to throttle the gun animations as frame rates fall below certain thresholds. But I don't use any JSBSim stuff for the prop animation. When you use XML you are relegating things to either the FDM or to FG itself which will generally be more efficient and "safer" than rolling your own Nasal and much of this will actually happen in C++ space. Also if you do this using FDM XML you take this out of the main loop which is generally a good thing.

Yesterday evening I pulled the prop disk and a second copy of the spinner into a separate model and did some cleanup on the models (the blades and the disk were not running true so I fixed that issue). Looks OK.

Right now I only have two stages to the prop animation and I am trying (unsuccessfully) to use a transparency animation on the blades to simulate the blurred blades phase. In fact I have been unable to get the transparency animation working in a number of contexts with recent versions of FG and I am not sure what the issue really is (probably something I am doing). I can get things to have a fixed transparency by setting the material to a certain gamma and using a texture with a gamma but I have been unable to change the transparency at run time using the transparency or blend animation.

The other issue here is that in the blurred blade phase the blades should be darker/less transparent closer to the hub/spinner because they are traveling way slower than at the tips of the blades. A blurred blade phase specific model and texture would probably make this possible.

At this point I have more important stuff to tackle than the blurred blase phase stuff so it will have to wait until later as the prop animations are "good enough" for now.

[[User:Hvengel|Hvengel]] ([[User talk:Hvengel|talk]]) 16:16, 12 July 2014 (UTC)

:: "When you use XML you are relegating things to either the FDM or to FG itself which will generally be more efficient and "safer" than rolling your own Nasal and much of this will actually happen in C++ space. Also if you do this using FDM XML you take this out of the main loop which is generally a good thing."

: This is not true – FDM is still inside the main loop (anything that accesses the property tree is inside the main loop). In fact it would be less efficient (theoretically) to put animation code into the FDM because it's updated unnecessarily – animations are only evaluated each frame. (Direct output of surface position is fine, but processing it doesn't have to be in the FDM.) It's not like adding a small Nasal operation for an animation would have any performance penalty at all – even on the most outdated hardware imaginable. But then again, it'll just be a small difference normally – hardly even 1/10th of a ms.

: Emilian: while I agree that the Extra-500 is really slow for me as well, how well it performs is not relevant to this discussion. The Nasal used there is more comparable to "500+600+700+... lines of Nasal code adding up" than "5+5+5+... lines of Nasal code adding up" – because 5 lines of Nasal code takes up no time at all (unless it calls expensive functions and/or uses recursion and/or loops, which the Extra-500 certainly uses some of). The Extra-500 is really complex (as far as I understand it) and is subject to different issues, issues which don't affect small scripts (i.e. 5-liners). Some of the lack of efficiency is not even Nasal code, it's hard coded (e.g. the props.Node interface, which doesn't use cppbind and thus can create unnecessary temporary GC-able objects if used incorrectly). Some of it is the lack of efficiency in the Extra-500's code versus what being accomplished – i.e. it could be much simpler in places (and actually use MapStructure). Some of it is the positioned queries – those are not microscopic yet, but probably will be soon. Et cetera. There's different ways we could prove it's inefficient code. Nasal itself, however, is very efficient from what I've seen and simple animations are not time-wasters at all. Even 100 lines of simple Nasal animations should execute in under ~2-4ms, I would guess, on reasonably modern hardware if it doesn't use certain constructs (e.g. props.globals.getNode("").setValue/getValue, where the node isn't cached, see [http://forum.flightgear.org/viewtopic.php?f=30&t=22155#p201370], or other GC nightmares). Even GC'ing is extremely fast on my computer :-). [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 13:55, 14 July 2014 (UTC)

== Ubershader Issues ==

HI, I'm the author of the ubershader and accompanying effects. I noticed on the forums that you're having some issues with it.

Could you please paste somewhere the effect file you use?

Also could you check that the respective objects are not parented to some other object (or an empty) from where they could possibly inherit effects/materials?

The flipped normal behaviour is really weird (and would suggest you have inadvertently enabled the <normalmap-dds> flag)

Also, for the uberhsader the relevant documentation is in $FG_DATA/Docs/model-combined.eff/

(If you're gonna ask why it's not on the wiki, you have already hit the main reason, bitrot, and having to duplicate maintenance efforts. And no, I don't think the wiki should be the authoritative source for documentation)

HTH

[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 18:11, 3 July 2014 (UTC)

:Hello Hvengel

:I have/had the same problem with the EC135P2 and the Dornier 328 model slow WIP. So far I can remember one thing seems to be is the uvmapping. When two face are overlapped in the :UVmapped it seems to produce this issue. At least it is not a issue with the shader itself. More the way the model is uvmapped.
:Can you send a in-sim screenshot of the faulty part and a image of the the matching uvmapping?

:Btw: the main culprit is not the vertice numbers- but the objects numbers. So a, let's say 7.000.000 vertice aircraft divided into 1000 objects has a much bigger impact
: as a model with twice number of vertices but divided in only 50 objects. Means: combine all meshes into one object in Blender as long you don't need to animate in any way =
: One object + those objects which has to be animated (aileron, flap,...)!

:Cheers
:--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 19:38, 3 July 2014 (UTC)

::Yes, the UV coordinates direction needs to be consistent on the same mesh. You can have overlapping faces as long as they don't share an edge in the UV and/or they don't have one of the coordinates flipped. <s>(i would post some screenshots if not for the innane upload wizard :( )</s>

::In the problematic example the middle face will be causing issues (it's U coordinates being flipped, and it shares the UV edge with the left face). In the problematic2 example the B1 (right) face will be causing issues, as it's V coordinates are flipped (mirrored)
::{{Gallery
|Ubershader_blender_uv_ok.png|UV OK1
|Ubershader_blender_uv_ok.png|UV OK2
|Ubershader_blender_uv_problem.png|UV Problem1
|Ubershader_blender_uv_problem1.png|UV Problem2
}}

::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 10:44, 4 July 2014 (UTC)

I have very carefully gone over the three objects to make sure that the UV maps had no overlapping or 0 area faces in the UV map. In the case of the cowl I actually removed parts of it that were not part of the main exterior surface. These consisted of things like the cylindrical surfaces for the air intake holes, the edge and internal surfaces of the exhaust cutout, the internal air intake passages (behind the holes on the side of the cowl) and the front ring that is next to the spinner which are all now separate objects now. The cowl in now much simpler (still a fairly complex shape in the chin scoop area) with no folded over edges or inside surfaces.

So here are some screen shots:

[[File:Cowl UVMap.jpg|thumb|Cowl UVMap]]
[[File:Cowl In Sim Normals Normal.jpg|thumb|Cowl In Sim Normals Normal]]
[[File:Cowl In Sim Normals Flipped.jpg|thumb|Cowl In Sim Normals Flipped]]

These are high res screen shots (about 4.5 mega pixels each) so you should be able to see all of the necessary details. The background in the UV map screen shot is the actual texture being used. The line and hole detail in the texture was used to create the normal map.

[[User:Hvengel|Hvengel]] ([[User talk:Hvengel|talk]]) 18:08, 5 July 2014 (UTC) Hal

:''Hi, I've moved your message here to have the discussion in one place.''

:I took a look at the blender file. Sorry to say this but the mesh is a mess, and I suspect the somewhat flaky blender-2.6+ .ac export script is choking on it and spitting out garbage.
:For example on the '''cowl''' object there are 88 '''n-gons''' (faces with 5 or more vertices). This can cause issues with the winding order (which determines the respective face/normal orientation), even more so if the script tries to be smart and split those on its own. There is a blender script that's called '''MeshLint''' and can help with checking and fixing the meshes. You can find and enable it in the addons tab of the user-settings dialog. Try first manually splitting the n-gons into tris, recalculate normals and then re export the mesh from blender, see if that helps.
:I know working with booleans seems easier, but these are the ''hidden'' traps in that style of work, and you end up doing twice the work needed on the mesh to fix it up after the ''quick&dirty'' boolean operations.
:And that's a shame given the amount of work you obviously already put into it.
:HTH
:[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 19:01, 5 July 2014 (UTC) [[User:Hvengel|Hvengel]] ([[User talk:Hvengel|talk]]) 08:22, 6 July 2014 (UTC)

:Got the MeshLint add in and went through the three meshes that are having issues and removed all n-gons. Kind of time consuming but no too bad. After all I only have to do one side then mirror it to get the other side. After removing all n-gons I then had Blender recalculate the normals and exported the model. The issue is still there.

As a side note the last objects I discovered that had this issue are the exhaust covers. In these I cut the holes by hand since I couldn't get the boolean operation to work. I also cut the exhaust cutouts in the cowl by hand and at one point these were nice clean looking cutouts. But when i did the boolean operation to do the 32 1 inch holes for the filtered air intake Blender decided to mess with the exhaust cutouts. But at that point I don't think there where any n-gons. But the normals problem was still there even before I tried to clean things up. I spent some time cleaning up the air intake holes and this is where the n-gons came from.

I just had a close look at the exhaust covers and the one I looked at did have two n-gons. I fixed those then flipped back to to normal and recalculated the normals and exported it. Opening the .ac file in FG everything looked sort of OK except the inside of the mesh was bright and reflective. This object has the normals of the front pointing outward and the normals of the back areas are pointing inward and these parts of the object are textured black. But the back was acting like it's normals were flipped (IE. the back was black - showing the texture- on the outside when it should be showing this on the inside). Turns out that this is acting just like the cowl and wing fairings. So is unrelated to using a Boolean operation.

Thinking things through a little it appears that all of the objects that are showing up black in the FGRUN 3D preview when the normals are the correct direction are objects where I did cutouts of some sort either by hand or using a Boolean operation in Blender. For most of these I did NOT use a boolean operation.

The export script definitely has issues but, at least with simpler models, works in most cases. The way it behaves when something is not textured is very flawed in that it just fails with more or less hidden and very cryptic error messages. I do UI work for a living and I would never let something that poorly designed out into the wild. If it has such obvious UI issues who knows what kind of issues exist in the actually functionality.

[[User:Hvengel|Hvengel]] ([[User talk:Hvengel|talk]]) 08:22, 6 July 2014 (UTC)

===Most Likely Fix ===
:: Pfewww that was a hard one, and well hidden. The perils of transforming stuff in object mode in blender ;)
:: All these problem objects have negative scaling on at least one of the axes, and when the export script applies the transform, the normals get flipped. You'll notice it right away if you apply the transform first. Which you should do, to all objects, right away, to avoid this cropping up again. Fuselage isn't affected since it's not scaled. Examples below:
::{{Gallery
|Ubershader-isue-blender-cowl.jpg|Cowl
|Ubershader-isue-blender-exhaustcover.jpg|exhaustCoverLeft
|Ubershader-isue-blender-wingfillet.jpg|wingFilletLeft
|Ubershader-isue-blender-fuse.jpg|Fuse
}}
::Btw, a couple of issues that I noticed that '''will''' affect performance: all your meshes have '''double-sided''' faces in blender, make them '''single-sided'''; your textures have the '''alpha channel''' left in, this will affect performance with shaders disabled and will cause funny rendering bugs in Rembrandt. Remove the alpha channel for the textures that are applied to opaque objects.
::
::HTH, and cheers,
::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 16:06, 6 July 2014 (UTC)

Howto:Create custom splash screens

2014-07-10T16:55:10Z

Philosopher: /* Aircraft specific */ add information about full path to splash-texture nde

A splash screen is an image that is displayed during the loading of [[FlightGear]]. They usually exist of a [[Howto: Make nice screenshots|screenshot]] of an [[aircraft]], together with the name/type of the aircraft and the name "FlightGear".

'''Creating custom splash screens''' is another thing that is very easy to do, just by looking at the documentation or by looking at existing aircraft, for example the default [[Cessna C172|C172P]].

== Various kinds of splash screens ==
There are two kinds of splash screens:
* '''aircraft specific:''' packaged with an aircraft and only displayed when that specific aircraft is loaded.
* '''general:''' randomly picked and displayed when there is no custom splash screen for the aircraft that is loaded.

=== Aircraft specific ===
The splash screen image is configured by the <tt>aircraft-set.xml</tt>, where "aircraft" is the name of the aircraft. You can find these files in each aircraft's directory in <tt>[[$FG ROOT]]/Aircraft</tt>.

[[File:C172p-folder-structure.png]]

The set file supports a "splash-texture" tag in XML (just search for "splash-texture" using your text editor"), it should look like this and should be inside a <sim> tag and then a <startup> tag (so the path is /sim/startup/splash-texture):

<splash-texture>filename.png</splash-texture>

Please note that for the time being, aircraft cannot have multiple custom splash screens.

The filename is relative to the <tt>Aircraft/</tt> directory and will differ among different aircraft, but often it just refers to "splash.png". See for example the C172P:

<splash-texture>Aircraft/c172p/splash.png</splash-texture>

In this case, the image is located in <tt>[[$FG ROOT]]/Aircraft/c172p/splash.png</tt>.

=== General ===
Aircraft that do not have a custom splash-texture specified, will be assigned a randomly chosen screen from the global <tt>[[$FG ROOT]]/Textures</tt> directory. Editing and overwriting these screens (splash?.png) will affect all aircraft without aircraft specific screens.

== Modifying/creating splash screens ==
The easiest thing for you to get started with, would be to simply load an existing splash screen image in an image editor (i.e. GIMP or Photoshop) and start modifying it. Once you are finished, you can save the file to the directory where your aircraft is located, using a filename such as "splash.png", for an aircraft specific screen. In the aircraft-set.xml you will want to change the splash tag then, to refer to this image (case sensitive).

You could also edit the general screens, the only difference here is that you overwrite one of the screens in the <tt>[[$FG ROOT]]/Textures</tt> directory.

== Things to note ==
* '''Image dimensions must be powers of two''' (eg. 256x256 or 512x512 pixels), but as long as you really just edited existing splash screens, that should not be a problem.
* If you want to modify the splash screen of one particular aircraft, there is no reason to modify ANY splash screens outside your aircraft folder. Just add a splash screen to your aircraft folder (i.e. by copying a png or rgb file from another aircraft), add it to your aircraft-set.xml file and then modify the splash screen in your image editor.

== Related content ==
* [[Howto: Make an aircraft]], specifically at the [[Howto: Make an aircraft#.3Csplash-texture.3E.3C.2Fsplash-texture.3E|splash texture section]].

[[Category:Aircraft enhancement|Create custom splash screens]]
[[Category:Howto|Create custom splash screens]]

Initializing Nasal early

2014-07-09T22:00:36Z

Philosopher: move initial heading; don't use io.include

{{Nasal Internals}}

This is a summary of all discussions relating to:
* initializing the Nasal scripting interpreter earlier
* providing an integrated GUI front-end/launcher using [[Canvas]] and [[Nasal]]: [[Aircraft Center]]
* moving $FG_ROOT/Nasal initialization out of C++ into scripting space (aka "bootstrapping") while introducing proper dependency resolution (inter- and intra-modular)
* decoupling FlightGear initialization such that certain subsystems can be optionally disabled right at the beginning
* making the initialization process/splash screen more responsive by using Nasal/Canvas instead of hard-coded GL code [http://forum.flightgear.org/viewtopic.php?f=71&t=22021] ({{Issue|1456}})
* allowing custom startup profiles/modes to be implemented via Nasal helper scripts, for example:
** [[FGCanvas]]
** [[FlightGear Benchmark]]
** [[FlightGear Headless]]

== Objective ==
{{cquote|
The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all). This would avoid people accidentally starting on the runway in MP events, which would be a big usability win.

When no parking positions are defined, AI traffic defaults to the 'airport centre' location. Selection a taxiway parallel to the active runway is possible, but for complex airport layouts I can imagine many ways this logic could fail. Personally I think it would be more robust to stick to picking parking positions, and otherwise using the airport centre, because it would encourage people to add the parking position data :)

I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/attachment/F69E014E-F15A-4EAB-B512-36B87CA3B2C5%40mac.com/1/|title= Aircraft positioning on the runway|author=James Turner |date=2013-11-12 10:32:27}}</ref>|James Turner}}

{{FGCquote
|I would prefer to init Nasal earlier in startup, because I would like use [[Aircraft Center|Canvas-based UI for pieces such as aircraft-selection]] - but right now we have to load Nasal in postInit, which is seconds and seconds into startup. Most Nasal things that need FDM state already wait on fdm-initialized, so in ''theory'' the only fix required is to skip <nasal> evaluation in 'animation' XML files (apparently there is a long-standing assumption that such elements are skipped when loading an aircraft as the main one, i.e they are only run for AI / MP aircraft - this is a bad situation but changing it now could be a serious compatibility problem)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192734#p192734
|title=<nowiki>Re: Modular Nasal </nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sun Oct 27</nowiki>
}}
}}

{{FGCquote
| I am delighted to have this cleaned up, and a way to incrementally init bits of Nasal, but I would be much happier to see a patch of the C++ difs, the sooner the better, just in case you're doing something that is not going to work safely.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=192734#p192734
|title=<nowiki>Re: Modular Nasal </nowiki>
|author=<nowiki>zakalawe</nowiki>
|date=<nowiki>Sun Oct 27</nowiki>
}}
}}

{{FGCquote
|I really don't believe there should be an option to disable bootstrapping, it should just be an issue of matching FGData. Basically, if we have new-style scripts (i.e. using require() and deprecating "nasal-dir-initialized"), then we ''need'' a bootstrap script (because otherwise... we would have to reimplement the corresponding code in C++ space); else, we have old FGData (as I sometimes like to switch back to, to pursue other projects like the Nasal Browser) and we use the old C++ loading code.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=193231#p193231
|title=<nowiki>Re: Modular Nasal bootstrapping (again)</nowiki>
|author=<nowiki>Philosopher</nowiki>
|date=<nowiki>Mon Nov 04</nowiki>
}}
}}

{{FGCquote
| 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
|revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support).
|{{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>
}}
}}

{{FGCquote
|Given my recent "FGCanvas" experiments (making ~60% of the subsystems optional), and successes there, I'd probably consider handing off control to a hard-coded Nasal script in FGNasalSys, even though we could make the file-name property-configurable, whereas it would default to something like "default.boot". 
 
That would allow us to easily use --prop{{=}} (or a dedicated '''--mode{{=}}''') parameter to override the bootstrapping script. 
Once that is place, we could also move certain fg_init.cxx logic to Nasal space by using Zakalawe's add-subsystem/remove-subsystem fgcommands, which I already started extending to allow subsystems to be registered as SGSubsystemGroup instead of "just" SGSubsystem - which allows us to use groups as "containers" for specific subsystems, like "aircraft" (fdm, autopilot, route manager etc) or "audio" (fgcom, sound, voice). Making these entirely optional and runtime-configurable is becoming much more straightforward that way - also, because all the reset/re-init logic can be moved to each groups postinit/reinit methods. 
 
Conceptually, that's straightforward to do, and apart from supporting different startup modes, we could even support "applications", i.e. stuff like running just the REPL, or just a canvas-map, or even just the Aircraft Center eventually. 
 
So, I'd prefer to load a single property-defined Nasal script and delegate control to it in FGNasalSys:init(), so that we can handle both there, nasal bootstrapping, but also subsystems at some point.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214423#p214423
|title=<nowiki>Re: Modular Nasal bootstrapping (again)</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Jul 09</nowiki>
}}
}}

{{FGCquote
|for FGCanvas-testing, I just used a slightly-extended version of this:
<syntaxhighlight lang="diff">
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index 0389faa..26eac9c 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -1434,8 +1434,9 @@ struct OptionDesc {
int (*func)( const char * );
} fgOptionArray[] = {

+ {"mode", true, OPTION_STRING, "/sim/startup/boot-script", false, "default", 0 },
{"language", true, OPTION_IGNORE, "", false, "", 0 },
- {"console", false, OPTION_IGNORE, "", false, "", 0 },
+ {"console", false, OPTION_IGNORE, "", false, "", 0 },
{"disable-rembrandt", false, OPTION_BOOL, "/sim/rendering/rembrandt/enabled", false, "", 0 },
{"enable-rembrandt", false, OPTION_BOOL, "/sim/rendering/rembrandt/enabled", true, "", 0 },
{"renderer", true, OPTION_STRING, "/sim/rendering/rembrandt/renderer", false, "", 0 },
diff --git a/src/Scripting/NasalSys.cxx b/src/Scripting/NasalSys.cxx
index fde6319..b8c2114 100644
--- a/src/Scripting/NasalSys.cxx
+++ b/src/Scripting/NasalSys.cxx
@@ -833,6 +833,7 @@ void FGNasalSys::init()
.member("singleShot", &TimerObj::isSingleShot, &TimerObj::setSingleShot)
.member("isRunning", &TimerObj::isRunning);

+#if 0
// Now load the various source files in the Nasal directory
simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal"));
loadScriptDirectory(nasalDir);
@@ -845,6 +846,20 @@ void FGNasalSys::init()
simgear::PathList scripts = dir.children(simgear::Dir::TYPE_FILE, ".nas");
addModule(directories[i].file(), scripts);
}
+#endif
+
+ const char* boot_script = fgGetString("/sim/startup/boot-script", "default");
+ SGPath fullpath(globals->get_fg_root(), "Boot");
+ fullpath.append(boot_script);
+ fullpath.concat(".boot");
+
+
+ SG_LOG(SG_NASAL, SG_INFO, "Using boot script:" << fullpath);
+ SGPath file = fullpath.file();
+ if(!loadModule(fullpath, "boot")) {
+ SG_LOG(SG_NASAL, SG_ALERT, "Error could not load boot script:" << fullpath);
+ exit(-1);
+ }

// set signal and remove node to avoid restoring at reinit
const char *s = "nasal-dir-initialized";

</syntaxhighlight>
As you can see, the file name of the "boot script" defaults to $FG_ROOT/Boot/default.boot but can be easily overridden to add custom modes. 
Which is kinda where we could now add your bootstrap.nas logic and review the necessary C++ changes to make it work. 
For testing purposes, I used io.nas as the template for my own boot script, i.e. to load globals.nas, props.nas etc 
 
Once the hard-coded functionality is re-implemented, we can explore making things better configurable, i.e. more optional, over time.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214428#p214428
|title=<nowiki>Re: Modular Nasal bootstrapping (again)</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Jul 09</nowiki>
}}
}}
<references/>

For the sake of simplicity, we could refactor the ::init() method such that the common init code could be shared, between the initial startup Nasal interpreter, and the final runtime interpreter - so that we could load init code from a separate $FG_ROOT directory to do such things, without parsing all the stuff in $FG_ROOT/Nasal.

Referring to the GLSL segfault fix and my earlier comment about defaulting to a NON-SHADER environment by adjusting shader quality level to 0 if shaders are unsupported: For now, this is obviously easy to simply hard-code by showing an ALERT message and overriding the shader settings from there on.

However, in the long run, we'd probably want to simply delegate such stuff to Nasal space. While Nasal is currently not available that early, we could use a bare (or just temporary) Nasal instance during initialization to hand-off such stuff to scripting space. This seems to be an old idea actually (see the comments below from 2008) - and peopel were actually working on having Nasal + GUI code up really early back in 2008.

Given the state of the current init code in fg_init.cxx, the idea of factoring stuff out into Nasal space is very appealing - which means having less unmaintained C++ spaghetti code, and things like processing startup arguments can be really easily done from Nasal space, what's needed is "only" the props code - or rather just setprop/getprop, which would allow simple logic to be moved to scripting space - and it would not even be performance-critical.

In other words, it would be sensible to pick up the old idea and make a minimal Nasal interpreter available early on, and pass control to it - so that things like thís can be easily run, without hard-coding any logic:

<syntaxhighlight lang="nasal">
if (getprop("/sim/rendering/gl-shading-language-version")=="UNSUPPORTED") {
print("Warning: Shaders unavailable, defaulting to quality level 0!\n")
setprop("/sim/rendering/shaders/quality-level", 0);
}
</syntaxhighlight>

{{cquote|The only catch is, subsystems are initialised late, but I need a handful to be up before I can use the GUI dialogs; obviously the GUI subsystem itself, but also Nasal and a few others. (There are some issues with initialising nasal early, it is currently deliberately being done very late, but more on that later...)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03373.html|title=<nowiki>[Flightgear-devel]</nowiki> Subsystem run-levels|author=James Turner|date=Mon, 17 Apr 2006 13:51:07 -0700}}</ref>|James Turner}}

{{cquote|I would appreciate if Nasal were around the first subsystems to be initialized. But this would require some Nasal dependency resolution. Almost all Nasal code needs globals.nas, and most need props.nas, too (which needs globals.nas). gui.nas needs globals.nas and props.nas, and screen.nas
needs all three etc. This needs to be taken care of if Nasal is to be initialized early.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03390.html|title=<nowiki>[Flightgear-devel]</nowiki> Re: Subsystem run-levels|author=Melchior FRANZ|date=Tue, 18 Apr 2006 03:37:04 -0700}}</ref>|Melchior FRANZ}}

{{cquote|starting up the interpreter (the first part of FGNasalSys::init) can be done very early (and quickly), and the subsytem would then wait for a relatively high-valued 'init' call before running scripts (the part that needs all other properties to be defined).<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03373.html|title=<nowiki>[Flightgear-devel]</nowiki> Subsystem run-levels|author=James Turner|date=Mon, 17 Apr 2006 13:51:07 -0700}}</ref>|James Turner}}

{{cquote|I'm sure other people can propose potential groups, but I'd imagine:

early (nasal itself, GUI)
time based subsystems (ephemeris, datetime, warp, properties, interpolator)
environmental (weather fetch)
aircraft systems (FDM, electrical, cockpit?, instruments, failures, GPS)
scenery (tile manager, views, panels)
input
IO subsystems - ATC, traffic, multiplayer
sound<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03401.html|title=Re: <nowiki>[Flightgear-devel]</nowiki> Subsystem run-levels|author=James Turner|date=Tue, 18 Apr 2006 08:23:01 -0700}}</ref>|James Turner}}

{{cquote|I will start the systems I need (Nasal, GUI and input) early. This might also help make the startup progress a bit more fine-grained.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03418.html|title=<nowiki>[Flightgear-devel]</nowiki> Run-levels redux.|author=James Turner|date=Wed, 19 Apr 2006 06:43:14 -0700}}</ref>|James Turner}}

{{cquote|In the even longer run, we'd actually want to associate the Nasal scripts with run-levels (/etc/rc.d, anyone?), since the frontend GUI might want a few scripts loaded, while I assume most are only relevant when actually flying. Such a change also makes postinit() unnecessary, I think - since the effect can always be achieved by having init() watch for a higher run-level.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03373.html|title=<nowiki>[Flightgear-devel]</nowiki> Subsystem run-levels|author=James Turner|date=Mon, 17 Apr 2006 13:51:07 -0700}}</ref>|James Turner}}

<references/>
[[Category:Developer Plans]]

Howto:Animate gear scissors

2014-06-29T10:47:13Z

Philosopher:

This [[:Category:Howto|HOWTO]] describes how to create an animation for landing gear scissors using an interpolation lookup table and no [[nasal]] code.

{{Note|For FlightGear 2.11+ the [[Tracking_animation|tracking animation]] provides a more accurate and easier way of animating gear scissor.}}

== Required tools ==
* A tool to measure distances in 3D models like [[AC3D]] or [[Blender]]. The images shown in this HOWTO uses AC3D but any other application should be fine.
* The standalone version of the nasal interpreter. Get it here: [http://www.plausible.org/nasal/ http://www.plausible.org/nasal/]
* A XML editor or a plain text editor. EDLIN should do but there are probably others...
* This little peace of nasal code. Copy and paste this code into a file called '''gearscissor.nas'''.
import("math");
var acos = func(x) { math.atan2(math.sqrt(math.abs(1-x*x)), x) }
var R2D = 180.0 / math.pi;

var scissor_dist = PUT SCISSOR_DIST HERE;
var scissor = PUT SCISSOR HERE;
var oleo = PUT OLEO HERE;

var theta0 = acos(scissor_dist/2/scissor) * R2D;
print( "<?xml version = '1.0' encoding = 'UTF-8' ?>\n" );
print( "<PropertyList>\n" );

for( var i = 0; i < 1.05; i += 0.05 ) {
print( "<entry>\n" );
var l = (1.0-i) * oleo/2;
l += (scissor_dist-oleo)/2;
print( "<ind>" ~ sprintf("%4.3f", i ) ~ "</ind>\n" );
print( "<dep>" ~ sprintf("%4.3f", acos( l / scissor ) * R2D - theta0 ) ~ "</dep>\n" );
print( "</entry>\n" );
}
print( "</PropertyList>\n" );

== Let's go ==
[[File:Howto- animate gear scissors scissor dist.jpg|thumb|250px|The scissor distance]]
First open the 3D model in AC3D and look for the gear to animate. The two scissor elements need to be named as individual objects. Let's call them '''A''' and '''B''' as an example. It is not within the scope of this document to describe how to create or name objects in the 3D model.
Our first step is to create the interpolation table to be included in the animation xml file.
Open your above created file gearscissor.nas in a text editor and look for the line
var scissor_dist = PUT SCISSOR_DIST HERE;
Measure the distance between the two vertices marking the two rotation axes of the two scissor elements. Check the image on the right, the two vertices are marked as green dots. Replace the text PUT SCISSOR_DIST HERE with this value.

[[File:Howto- animate gear scissors scissor.jpg|thumb|250px|The scissor length]]
Next, measure the distance between the two rotation axes of one scissor arm. Check the image on the right as a visual reference. Put the value into the line
var scissor = PUT SCISSOR HERE
and replace the text PUT SCISSOR HERE with this value.

[[File:Howto- animate gear scissors oleo.jpg|thumb|250px|The oleo strut]]
Finally you need the length of the oleo strut, the maximum compression length of the oleo strut. Measure the distance like in the examle image and place the value into the line
var oleo = PUT OLEO HERE;
Replace PUT OLEO HERE with the value.

Save the file, and run the file through the nasal interpreter by calling
nasal gearscissor.nas

This should produce a lot of output. This is the interpolation table that checks the compression of the gear strut and derives the angular deflection of the scissor arm. It should look like this:
<?xml version = '1.0' encoding = 'UTF-8' ?>
<PropertyList>
<entry>
<ind>0.000</ind>
<dep>-0.074</dep>
</entry>
<entry>
<ind>0.050</ind>
<dep>3.816</dep>
</entry>
<entry>
<ind>0.100</ind>
<dep>7.345</dep>
...
</PropertyList>
Your numbers will look different but the structure should be the same. Save this output into a file named '''GearScissorInterpolation.xml''' and save this file in the same folder where your 3D model lives.
Note: in a console environment, you can usually save a program's output by forwarding it to a file using the > operator:

./nasal gearscissor.nas > GearScissorInterpolation.xml

== The animation XML ==
Before you continue, locate the rotation points of the two scissor arms where they are connected to the main strut. These are the vertices that were marked to measure the scissor distance.
Open the XML file that contains the animations for you model and add the following lines within the <PropertyList></PropertyList> elements:
<animation>
<type>rotate</type>
<object-name>A</object-name>
<property>gear/gear[1]/compression-norm</property>
<axis>
<x>-1</x>
</axis>
<center>
<x-m>YOUR X LOCATION OF THE ROTATION POINT HERE</x-m>
<y-m>YOUR Y LOCATION OF THE ROTATION POINT HERE</y-m>
<z-m>YOUR Z LOCATION OF THE ROTATION POINT HERE</z-m>
</center>
<interpolation include="GearScissorInterpolation.xml"/>
</animation>
Fill in your values for x-m, y-m and z-m for the location of the rotation vertices. Add another section for the second scissor arm, replace the object-name with '''B''' and set the axis to +1 instead of -1.
If you see the scissors move in the opposite direction, exchange the sign in the axis definition.

== Examples ==
Check out the [[Hamburger Flugzeugbau HFB 320 Hansa Jet|HansaJet]] and the [[Piper PA34-200T Seneca II|Seneca II]]. Both [[aircraft]] use the above technique for the animation.

[[Category:Howto|Animate gear scissors]]
[[Category:Modeling|Animate gear scissors]]

Howto:Nasal Metaprogramming

2014-06-29T02:39:02Z

Philosopher: /* bind() */ huh... I always believed bind() returned its first argument and mutated the closures, but apparently it never has... not since it was introduced in 2005: https://github.com/andyross/nasal/commit/3bb78b7bdcd01ae9ff6afee51338253a0fea99f6.

{{Template:Nasal Navigation}}
{{WIP}}

== call() ==

<syntaxhighlight lang="nasal">
var foo = func {
print( me.x );
};

call( foo, [], {x:100} );
</syntaxhighlight>

== closure() ==
Find the closure of a function, or nil if it does not exist. "Closure" is the name given to an outer namespace of a function; when considering a variable name (like "i"), that variable name is looked for in the current execution frame (the "locals" namespace) then any closures of the function. Closures are stored via two items in the internal structure of a function: a namespace (hash), which is the first to recurse to, and a link to another function (or nil if there isn't one), which stores an additional namespace and potentially another outer function. This creates a chain of namespaces stored in the functions.

The default closures for a new function (either a <tt>func {}</tt> expression or the return from compile()) are the immediate caller's namespace and function, so any local variables declared before/after the function (not inside!) become the first closure, and any closures of the current function are found by the new function. The closures, once set, become semi-permanent, and remain with the function until changed via bind(), even though they may be referenced from completely different places and namespaces. For more on closures see [[#bind()]].

;1st argument
* The function to find the closure of.
;2nd argument (optional; default<nowiki>:</nowiki> 0)
* The number of closures to look through.

== caller() ==

== compile () ==

<syntaxhighlight lang="nasal">

var x = 100;
var source_code = "print(x);";
var code = compile(source_code);
code();

</syntaxhighlight>

<syntaxhighlight lang="nasal">

var location = func {
var called_by = caller();
var file = called_by [2];
var line = called_by [3];
return "file:"~ file ~'@ line:'~ line;
}

var x = 100;
var source_code = "print(x);";
print( location() );
var code = compile(source_code, location() );
code();

</syntaxhighlight>

<syntaxhighlight lang="nasal">
var namespace = {
x:1, y:2, z:3,
print: print
};

var source_code = "print(x);";

var code = compile(source_code );
code = bind(code, namespace,nil);
code();

</syntaxhighlight>

== bind() ==
Creates a new function based on the function that is passed and sets its first closure and closure function.

;1st argument
* The function whose closures will be modified.
;2nd argument (optional)
* The first closure (i.e., outer namespace) to bind to, as a hash.
;3rd argument (optional)
* Another function, whose closure(s) are recursed into.

=== Example ===
<syntaxhighlight lang="nasal" enclose="div">
# make a function
var fn = func ;
# make a "namespace"
var namespace = {};
# re-bind the function to that namespace, which becomes the first closure of the function, erasing any/all others
var fn = bind(fn, namespace);
# assertion
if (closure(fn, 0) != namespace) die("bind() or closure() error!");
# another function: the currently executing one
var other_fn = caller(0)[1];
# re-bind the function to the namespace and all closures of *other_fn*
var fn = bind(fn, namespace, other_fn);
# same assertion holds
if (closure(fn, 0) != namespace) die("bind() or closure() error!");
# assertion for all other closures: closure(fn, i) must equal closure(other_fn, i-1)
var i = 1;
while ((var cl = closure(other_fn, i-1)) != nil) {
if (closure(fn, i) != nil) die("bind() or closure() error!");
}
# re-bind the function to the default closures, viz., namespace=caller(0)[0] and fn=caller(0)[1]
# (this is the default when we have a *func {}* expression, or equivalently, any function we get from compile())
var fn = bind(fn, caller(0)[0], caller(0)[1]);
</syntaxhighlight>

== Calling methods in Bindings ==

<syntaxhighlight lang="nasal">
var function = namespace.class.method;
var arguments = ["Hello World"];
var me = caller(0)[0];
call(function, arguments, me );
</syntaxhighlight>

Nasal Browser

2014-06-28T12:10:23Z

Philosopher: /* Features */

[[File:Nasal Namespace Browser Prototype.png|350px|thumb|Screen shot showing the new [[Nasal Browser|Nasal Namespace Browser]] that is currently being worked on by Philosopher.]]
{{Nasal Navigation}}
{{WIP}}
The '''Nasal '''('''Namespace''')''' Browser''' is a new dialog (3.3+) that allows the user to peek at the internal state of Nasal (starting from the global namespace). It displays a alphabetical list of keys mapped to values using the [[Canvas]] framework. Hashes and vectors are shown as their size and can be entered into via clicking on them; scalars' complete values are shown while ghosts and other types and represented in brackets.

{{Note|Per-update performance of the dialog (i.e. how fast it runs) is determined by how big the namespace is. On the developer's computer, it takes about 20–30ms to update the global namespace, much less for much smaller namespaces. The dialog is automatically updated about every 0.6 seconds.}}

== Features ==
Each entry is color-coded by type and scrollable via the Canvas scroll widget, sorted either by name or type and name. In a hash, each key is shown as either a string, a number, or a symbol, depending on what it really is (i.e. a scalar may be numeric but still a string; also, interned symbols are special cases of strings). Strings are shown in single quotes, symbols and numbers are shown without quotes. For strings, the brightness of the color is optionally reduced.

If the binary includes the debug.decompile extension function (i.e. is part of [[User:Philosopher/Nasal introspection|extended-nasal]]) then functions can a optionally be shown with their arguments, e.g. isa = <func(obj,class)> while _setlistener = <internal func> (in the sense of a function implemented in C/C++).

Values can be edited when they are clicked on; the edit bar then becomes activated and will capture key presses. A valid Nasal expression should be entered, which will be executed on {{key press|Enter}}.

User:Philosopher/Nasal introspection

2014-06-26T18:52:38Z

Philosopher:

{{Template:Nasal Internals}}

Used to be working on getting Nasal to profile itself in a running FlightGear session. Currently more focused on introspection through debug.decompile()/.recompile() helpers that expose code objects. See progress at the "extended-nasal" branches of [https://gitorious.org/~philosopher/fg/philosophers-simgear] [https://gitorious.org/~philosopher/fg/philosophers-flightgear] [https://gitorious.org/~philosopher/fg/philosophers-fgdata] and the gen library [https://gitorious.org/nasal-library/gen-lib].

The basic concept is to expose hooks/callbacks from the C source that get exposed to Nasal – so that Nasal does all the processing (and even collection of stats), but this requires a lot of core changes and is hard even to do from the Nasal end (I've found quite a challenge in it). The profiling script is currently fgdata:extended-nasal/Nasal/test.nas (WIP).

User:Philosopher/Nasal introspection

2014-06-26T18:49:52Z

Philosopher:

{{Template:Nasal Internals}}

Used to be working on getting Nasal to profile itself in a running FlightGear session. Currently more focused on introspection through debug.decompile()/.recompile() helpers that expose code objects. See progress at the "extended-nasal" branches of [https://gitorious.org/~philosopher/fg/philosophers-simgear] [https://gitorious.org/~philosopher/fg/philosophers-flightgear] [https://gitorious.org/~philosopher/fg/philosophers-fgdata].

The basic concept is to expose hooks/callbacks from the C source that get exposed to Nasal – so that Nasal does all the processing (and even collection of stats), but this requires a lot of core changes and is hard even to do from the Nasal end (I've found quite a challenge in it). The profiling script is currently fgdata:extended-nasal/Nasal/test.nas (WIP).

User:Philosopher

2014-06-26T18:03:59Z

Philosopher:

'''Sub-pages:''' (mostly stubs ATM)
* [[User:Philosopher/Advanced Input Programming|Advanced Input Programming]]
* [[User:Philosopher/Howto:Write Optimized Nasal Code|Howto Write Optimized Nasal Code]]
* [[User:Philosopher/Nasal introspection|Nasal introspection!]]
* [[User:Philosopher/Optimization findings|Optimization findings]] (from [[User:Philosopher/Nasal introspection|Nasal introspection]])

Sometimes working on improving Nasal internals and documenting them. Has the '''best''' joystick bindings (for a cheap joystick :P) at [http://flightgear.org/forums/viewtopic.php?t=17263 this topic]. Most recently working on various Canvas dialogs/frameworks.

Likes reading through C/C++ code for fun, and understanding, documenting, and improving it – though I'm far from an expert in either and my hat is continually off to Andy, Thomas, and James (and everyone else) for their wonderful code. Oddly enough, I find Nasal code to be harder to read, probably due to the fact that C/C++ and very structured languages and Nasal is not (it almost needs DbC at times!).

Favorite languages:
* Nasal (of course)
* Python (was my first language; I like most things about it except its duck typing – which works well until I actually need typing)
* C & C++ (different beasts; I like C++'s classes and ::iterators in particular)
* Languages yet to be discovered: I hope to find more that I like!

Things to be doing:
* [[Improving the Joystick GUI]]: porting to Canvas, tweaking things, and integration with back-end when ready.
* Nasal bootstrapping: get started again, commit in a useable state, but needs design and implementation first.
* Joystick-Philosopher (bindings for Cyborg-X): improve the control_function library.
* Nasal improvement for whatever release (LaTeX document, making patches and applying patches to SimGear), making sure it doesn't crash.
* Canvas Map: working on [[MapStructure]].nas, to replace old map.nas &c.
* Consolidating gen library, hopefully committing once bootstrapping is also committed. Make sure it doesn't crash the interpreter or reinstall Linux!
* Fixing bugs, tweaking small things :-).

Projects on the wiki:
* [[Interactive Nasal Console]]
* [[Nasal Browser]]
* [[MapStructure]]
* [[User:Philosopher/Nasal introspection|Nasal Introspection]]

Good ideas:
* Expose the catapult locations to the property tree, for JSBSim 'craft and Nasal tutorials.
* [http://flightgear.org/forums/viewtopic.php?f=18&t=19666 Changing behavior of SGPropertyNodes without tying] (something like {{issue|336}}).
* (In conjunction with Hooray) Have Nasal load itself: besides for one file (either Nasal/globals.nas or something in [[$FG_ROOT]]), ''all'' Nasal should be loaded from Nasal. (Including <tt>--prop:/nasal/module_name/script</tt> and <tt>--prop:/nasal/module_name/file</tt>.) See [http://flightgear.org/forums/viewtopic.php?f=30&t=21083] & [http://forum.flightgear.org/viewtopic.php?f=30&t=21083] {{Progressbar|50}}.

Nasal thoughts area:
* I would like to include small improvements that enhance my quality of life in SimGear: string slicing, hash iteration using foreach/forindex, save/restore aka stash? (latter to be discussed)
* Hooray and I talk about more extension functions to allow looking into internals; I need to review all of these, gather them up, add to them, etc., and hope they can be included somewhere (Hooray was saying maybe just the standalone Nasal in SimGear, not FlightGear's runtime).
** Sub-idea: if we only include the extensions in standalone and we have optimizer/post-compiler scripts ready, then make a script to be run with standalone that optimizes any or all Nasal files and outputs an optimized version (*.nas.optimized) or even just the bytecode (*.nas.opcode, textual file ofc) and have that be the preferred loading method (if the text is older than the optimized version).

Nasal Browser

2014-06-26T17:57:14Z

Philosopher: /* Features */

[[File:Nasal Namespace Browser Prototype.png|350px|thumb|Screen shot showing the new [[Nasal Browser|Nasal Namespace Browser]] that is currently being worked on by Philosopher.]]
{{Nasal Navigation}}
{{WIP}}
The '''Nasal '''('''Namespace''')''' Browser''' is a new dialog (3.3+) that allows the user to peek at the internal state of Nasal (starting from the global namespace). It displays a alphabetical list of keys mapped to values using the [[Canvas]] framework. Hashes and vectors are shown as their size and can be entered into via clicking on them; scalars' complete values are shown while ghosts and other types and represented in brackets.

{{Note|Per-update performance of the dialog (i.e. how fast it runs) is determined by how big the namespace is. On the developer's computer, it takes about 20–30ms to update the global namespace, much less for much smaller namespaces. The dialog is automatically updated about every 0.6 seconds.}}

== Features ==
Each entry is color-coded by type and scrollable via the Canvas scroll widget, sorted either by name or type and name. In a hash, each key is shown as either a string, a number, or a symbol, depending on what it really is (i.e. a scalar may be numeric but still a string; also, interned symbols are special cases of strings). Strings are shown in single quotes, symbols and numbers are shown without quotes. For strings, the brightness of the color is optionally reduced.

If the binary includes the debug.decompile extension function (i.e. is part of [[User:Philosopher/Nasal introspection|extended-nasal]]) then functions can a optionally be shown with their arguments, e.g. isa = <func(obj,class)>.

Values can be edited when they are clicked on; the edit bar becomes activated and will capture key presses. A valid Nasal expression should be entered, which will be executed on {{key press|Enter}}.

User:Philosopher

2014-06-26T17:46:24Z

Philosopher: updates now that summer is here

'''Sub-pages:''' (mostly stubs ATM)
* [[User:Philosopher/Advanced Input Programming|Advanced Input Programming]]
* [[User:Philosopher/Howto:Write Optimized Nasal Code|Howto Write Optimized Nasal Code]]
* [[User:Philosopher/Nasal introspection|Nasal introspection!]]
* [[User:Philosopher/Optimization findings|Optimization findings]] (from [[User:Philosopher/Nasal introspection|Nasal introspection]])

Currently working on improving Nasal internals and documenting them. Has the '''best''' joystick bindings (for a cheap joystick :P) at [http://flightgear.org/forums/viewtopic.php?t=17263 this topic].

Likes reading through C/C++ code for fun, and understanding, documenting, and improving it – though I'm far from an expert in either and my hat is continually off to Andy, Thomas, and James (and everyone else) for their wonderful code. Oddly enough, I find Nasal code to be harder to read, probably due to the fact that C/C++ and very structured languages and Nasal is not (it almost needs DbC at times!).

Favorite languages:
* Nasal (of course)
* Python (was my first language; I like most things about it except its duck typing – which works well until I actually need typing)
* C & C++ (different beasts; I like C++'s classes and ::iterators in particular)
* Languages yet to be discovered: I hope to find more that I like!

Things to be doing:
* [[Improving the Joystick GUI]]: porting to Canvas, tweaking things, and integration with back-end when ready.
* Nasal bootstrapping: get started again, commit in a useable state, but needs design and implementation first.
* Joystick-Philosopher (bindings for Cyborg-X): improve the control_function library.
* Nasal improvement for whatever release (LaTeX document, making patches and applying patches to SimGear), making sure it doesn't crash.
* Canvas Map: working on [[MapStructure]].nas, to replace old map.nas &c.
* Consolidating gen library, hopefully committing once bootstrapping is also committed. Make sure it doesn't crash the interpreter or reinstall Linux!
* Fixing bugs, tweaking small things :-).

Projects on the wiki:
* [[Interactive Nasal Console]]
* [[Nasal Browser]]
* [[MapStructure]]
* [[User:Philosopher/Nasal introspection|Nasal Introspection]]

Good ideas:
* Expose the catapult locations to the property tree, for JSBSim 'craft and Nasal tutorials.
* [http://flightgear.org/forums/viewtopic.php?f=18&t=19666 Changing behavior of SGPropertyNodes without tying] (something like {{issue|336}}).
* (In conjunction with Hooray) Have Nasal load itself: besides for one file (either Nasal/globals.nas or something in [[$FG_ROOT]]), ''all'' Nasal should be loaded from Nasal. (Including <tt>--prop:/nasal/module_name/script</tt> and <tt>--prop:/nasal/module_name/file</tt>.) See [http://flightgear.org/forums/viewtopic.php?f=30&t=21083] & [http://forum.flightgear.org/viewtopic.php?f=30&t=21083] {{Progressbar|50}}.

Nasal thoughts area:
* I would like to include small improvements that enhance my quality of life in SimGear: string slicing, hash iteration using foreach/forindex, save/restore aka stash? (latter to be discussed)
* Hooray and I talk about more extension functions to allow looking into internals; I need to review all of these, gather them up, add to them, etc., and hope they can be included somewhere (Hooray was saying maybe just the standalone Nasal in SimGear, not FlightGear's runtime).
** Sub-idea: if we only include the extensions in standalone and we have optimizer/post-compiler scripts ready, then make a script to be run with standalone that optimizes any or all Nasal files and outputs an optimized version (*.nas.optimized) or even just the bytecode (*.nas.opcode, textual file ofc) and have that be the preferred loading method (if the text is older than the optimized version).

File:Nasal Namespace Browser Prototype.png

2014-06-26T17:35:55Z

Philosopher: Philosopher uploaded a new version of "File:Nasal Namespace Browser Prototype.png"

=={{int:filedesc}}==
{{Information
|description={{en|1=Screen shot showing the new [[Nasal Browser|Nasal Namespace Browser]] that is currently being worked on by Philosopher.}}
|date=2014-06-26 10:31:21
|source={{own}}
|author=[[User:Hooray|Hooray]]
|permission=
|other_versions=
}}

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

[[Category:Canvas development projects]]

Template:Nasal Navigation

2014-06-26T02:13:10Z

Philosopher:

<noinclude>{{Informative template|1=
Navigation box for core [[Nasal]] articles.

== Usage ==
Put this at the top of the article:
<nowiki>{{Nasal Navigation}}</nowiki>

}}

[[Category:Navigation templates]]

</noinclude><includeonly>[[Category:Nasal]]</includeonly>{{forum|30|Nasal Scripting}}
{{sidebar
| topimage = [[File:Nasallogo3.png]]
| name = Nasal Navigation
| title = [[Nasal|Nasal scripting]]
| contentstyle= text-align: left;

| content1 =
* [[What is Nasal]]?
* [[Nasal success stories|Success stories]]
* [[Nasal FAQ]]
* [[Nasal features|Features]]
* [[Nasal Snippets]]
* [[Nasal Style Guide]]
* [[Howto:Syntax highlighting for Nasal]]

| heading2 = Tools and utilities
| content2 =
* [[Nasal Console|The Nasal Console]]
* [[Interactive Nasal Console|The Nasal REPL Console]] (3.2+)
* [[Nasal Browser|The Nasal Browser]] (3.3+)

| heading3 = Getting started
| content3 =
* [[Nasal for C++ programmers]]
* [[Creating new Nasal scripts]]
* [[Nasal Hello World]]
* [[Howto:Create a new Nasal module]]
* [[Using Nasal functions]]
* [[Nasal Variables]]
* [[Nasal Namespaces]]
* [[Howto:Understand Namespaces and Methods|Namespace and Methods]]
* [[Nasal Namespaces in-depth]]
* [[Nasal Conditionals]]
* [[Nasal Loops]]
* [[Nasal Operators]]
* [[Howto:Use vectors and foreach loops to write shorter code]]
* [[Howto:Start using vectors and hashes in Nasal]]
* [[Nasal library functions]]
* [[Nasal Flightplan]]
* [[Object oriented programming in Nasal|OOP Introduction]]
* [[Object Oriented Programming with Nasal]]
* [[Nasal Callbacks Explained]]
* [[Exception handling with Nasal]]
* [[Using listeners and signals with Nasal]]
* [[List of Nasal extension functions]]
* [[List of Nasal modules in $FG_ROOT]]
* [[Developing and debugging Nasal code]]
* [[Nasal Flightplan]]

| heading4 = Advanced Tutorials
| content4 =
* [[Caching Nasal function calls]]
* [[Nasal Unit Testing Framework]] (WIP)
* [[Nasal Meta-Programming]]
* [[A GPX flight logger in Nasal]]
* [[Multiplayer scripting in Nasal]]
* [[Howto:Making HTTP Requests from Nasal]]
* [[Howto:Transmit properties over MP]]
* [[Howto:Terrain sampling in Nasal]]
* [[Howto:Create a new system in Nasal]]
* [[Howto:Load a Nasal file at runtime]]
* [[Howto:Control the route manager in Nasal]]
* [[Howto:Get a number of elevation offsets for a number of objects]]
* [[Howto:Nasal in scenery object XML files]]
* [[Howto:Create animation XML files from Nasal]]
* [[Howto:Port I/O from Nasal]]
* [[Howto:Continuation-passing style programming in Nasal]]
* [[Howto:Start worker threads using listeners in Nasal]]
* [[Howto:Developing a DSL interpreter in Nasal]]
* [[Howto:Nasal Metaprogramming]]
* [[Nasal/JavaScript Subset]]

}}
{{Template:Nasal Internals}}

Nasal Browser

2014-06-25T22:00:36Z

Philosopher: Created page with "{{Nasal Navigation}} {{WIP}} The '''Nasal '''('''Namespace''')''' Browser''' is a new dialog (3.3+) that allows the user to peek at the internal state of Nasal (starting from..."

{{Nasal Navigation}}
{{WIP}}
The '''Nasal '''('''Namespace''')''' Browser''' is a new dialog (3.3+) that allows the user to peek at the internal state of Nasal (starting from the global namespace). It displays a alphabetical list of keys mapped to values using the [[Canvas]] framework. Hashes and vectors are shown as their size and can be entered into via clicking on them; scalars' complete values are shown while ghosts and other types and represented in brackets.

{{Note|Per-update performance of the dialog (i.e. how fast it runs) is determined by how big the namespace is. On the developer's computer, it takes about 20–30ms to update the global namespace, much less for much smaller namespaces. The dialog is automatically updated about every 0.6 seconds.}}

== Features ==
Each entry is color-coded by type and scrollable via the Canvas scroll widget. In a hash, each key is shown as either a string, a number, or a symbol, depending on what it really is (i.e. a scalar may be numeric but still a string; also, interned symbols are special cases of strings). Strings are shown in single quotes, symbols and numbers are shown without quotes. For strings, the brightness of the color is optionally reduced.

Interactive Nasal Console

2014-06-25T21:44:50Z

Philosopher: /* Updates */ 06/2014

{{Non-stable|version=3.2|progress=70}}

{{infobox subsystem
|image =Interactive-Nasal-Console-REPL.png
|name =Nasal Console REPL
|started= 03/2014 (Available since FlightGear 3.1)
|description = Fully-interactive Nasal console REPL
|status = Under active development as of 03/2014
|maintainers = Philosopher
|developers = [[User:Philosopher]] (since 03/2014),
|folders = $FG_ROOT/Nasal/console
|topic-fgdata= https://gitorious.org/fg/philosophers-fgdata/source/nasal-console:Nasal/console
|subforum= http://forum.flightgear.org/viewforum.php?f=71
}}

{{Nasal Navigation}}

Philosopher has created a very cool [[Canvas]]-based, fully-interactive, Nasal Console with a real [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL interpreter (Read-eval-print loop)]. See his gitorious clone (branch "nasal-console") for the code: [https://gitorious.org/fg/philosophers-fgdata/source/nasal-console:Nasal/console] - it's currently one file (which can even be copied into the existing [[Nasal Console]]) with a menubar entry (under "Debug") for easy access. You can also uncomment the [https://gitorious.org/fg/philosophers-fgdata/source/022bef27f05d4837d720f63c6507b47466ff2a59:Nasal/console/repl.nas#L436 last line] of the file to open it immediately. The dialog accepts user input in lines, and if it detects the user has completed a snippet, it executes the last code it's seen and prints a result of the expression on the same area. The most common way to continue input onto another line is to have an unclothed pair of braces/brackets/parentheses, but this REPL is unique in allowing unfinished expressions: blocks (e.g. just plain "if" on one line -- no condition, no body -- or "foreach (var e; list)" -- no body of the loop) and binary/prefix operators (e.g. "1 >", since that doesn't have a right side of the ">"). This however needs some work and tweaking, so it's always a WIP. The other big issue is the text styling -- the latest optimization leads to overlapping if a line of input/output is more than one line when wrapped. The output of print()/printlog()/etc. still goes to the startup OS terminal instead of the dialog. However, it still is useful for experimenting quickly -- ''quam celerrime revera''.

== Updates ==
; 04/2014
* Used scrollbar widget.
* Added compatibility with resize flag on window.
; 06/2014
* Compatible with new Canvas layout engine.
* Fixed bug on multi-line input, e.g. when pasting text with newlines or pressing shift+enter: now ''all'' lines are parsed, not just the last line.

== Gallery ==

<gallery mode=packed widths=230px heights=230px>
Interactive-Nasal-Console-REPL.png|Philosopher's interactive Nasal console REPL.
Interactive-Nasal-Console-REPL-Transparent-KSFO.png|Now at KSFO with transparency enabled (no title bar/styling).
Interactive Nasal Console REPL Random Theming.png|Don't look, it's bad color choices! This shows how colors can be changed while running.
Interactive Nasal Console REPL White Example.png|Showing a simple example of functional closures, with white styling.
</gallery>

Canvas MessageBox

2014-06-24T20:37:29Z

Philosopher: /* Examples */ canvas.MessageBox.info -> canvas.MessageBox.information, looks good!

{{Template:Non-stable|version=3.2|progress=100}}
{{Template:Canvas Navigation}}

Message boxes provide a simple way to report information and warnings or ask questions. In FlightGear 3.1+ using <code>canvas.MessageBox</code> with the Nasal scripting language, allows showing standard message boxes to the user.

== Predefined Severity Levels/Icons ==
{| class="wikitable"
|-
! Icon !! Icon Name !! Standard MessageBox !! Description
|-
| style="text-align:center;" | [[File:Dialog-question.png|link=]] || <code>"dialog-question"</code> || <syntaxhighlight lang="nasal">canvas.MessageBox.question(
<title>,
<text>,
cb = nil,
buttons = canvas.MessageBox.Yes
| canvas.MessageBox.No
);</syntaxhighlight> || Ask the user a (yes/no) question.
|-
| style="text-align:center;" | [[File:Dialog-info.png|link=]] || <code>"dialog-info"</code> || <syntaxhighlight lang="nasal">canvas.MessageBox.information(
<title>,
<text>,
cb = nil,
buttons = canvas.MessageBox.Ok
);</syntaxhighlight> || Show the user some information, with only the possiblity to close the dialog.
|-
| style="text-align:center;" | [[File:Dialog-warning.png|link=]] || <code>"dialog-warning"</code> || <syntaxhighlight lang="nasal">canvas.MessageBox.warning(
<title>,
<text>,
cb = nil,
buttons = canvas.MessageBox.Ok
);</syntaxhighlight> || Show the user a non critical warning, with only the possiblity to close the dialog.
|-
| style="text-align:center;" | [[File:Dialog-error.png|link=]] || <code>"dialog-error"</code> || <syntaxhighlight lang="nasal">canvas.MessageBox.critical(
<title>,
<text>,
cb = nil,
buttons = canvas.MessageBox.Ok
);</syntaxhighlight> || Notify the user of a critical error or failure, with only the possiblity to close the dialog.
|}

== Examples ==

{|
|- style="vertical-align:top;"
| [[File:Canvas-MessageBox-demo information.png|link=]] ||
<syntaxhighlight lang="nasal">
canvas.MessageBox.information("Success", "The operation has successfully completed.");
</syntaxhighlight>
|- style="vertical-align:top;"
| [[File:Canvas-MessageBox-demo question.png|link=]] ||
<syntaxhighlight lang="nasal">
canvas.MessageBox.question(
"Do you want it?",
"The question is: Do you want to get a real question?.",
func(sel)
{
if( sel == canvas.MessageBox.Yes )
print("I only know that the answer is 42.");
else
print("Ok, I will not give you a real question.");
}
);
</syntaxhighlight>
|- style="vertical-align:top;"
| [[File:Canvas-MessageBox-demo warning dont-show-again.png|link=]] ||
<syntaxhighlight lang="nasal">
canvas.MessageBox.warning(
"Warning...",
"Have you read this warning? If you want it will not be shown again.",
func(sel)
{
if( sel != canvas.MessageBox.Ok )
return;

print("You have been warned. Let the games begin...");
},
canvas.MessageBox.Ok
| canvas.MessageBox.Cancel
| canvas.MessageBox.DontShowAgain
);
</syntaxhighlight>
|}

Entitlement

2014-06-10T12:55:59Z

Philosopher: /* The FSX threat */

'''Entitlement''' is the errorneous perception by a subgroup of users that the Flightgear development team 'owes' them certain things for no other reason than that they are using Flightgear. This basic misunderstanding makes communication between developers and users prone to fail.

The reality is that Flightgear is developed by a team of volunteers who work for the project in their spare time and that users get the finished product for free (that 'free' includes costs for infrastructure like download bandwidth and file hosting), so it is difficult to see in what sense developers would owe users in addition to the service already rendered. If anything, it would be the other way round.

In practice, entitlement comes in various forms, often in statements like 'users should get more of a say where the project goes', requests to make binding votes and polls or unrealistic expectations in problem reporting situations.

== Votes and polls ==

With some regularity, users express their ideas on where they think the project should be going and feel that the project should be more democratic and take their vote into account and are disappointed that this leads nowhere. However, Flightgear is in essence a meritocracy in which the influence on where the project goes roughly scales with the merits a developer already has.

There are at least two basic reasons why the project does not let vote users into which direction future development should be going. First, making such decision requires insight into what the issues and alternatives are, and what they would imply. Some seemingly small changes may in fact require large changes in the basic architecture of the software. Inofficial opinion polls backed up with arguments are sometimes held on the developer's mailing list, but the aim is more to distill the arguments than the individual opinions. Basically, project decisions should be made by the people who have the skills and experience to make them. This has real-life analogies - in case of an emergency, an airliner crew does not give the passengers a vote what should be done, the cockpit crew decides that, as they have the skill and experience necessary, the passengers do not.

The second reason is tied to the volunteer nature of the project. Volunteers can not be compelled to work on something they do not like. Even if a user vote would make sense conceptually, if the people who have the ability to code a certain feature that has been voted in do not want to do it, it all stops there. It is completely unreasonable to ask people who devote their free time to coding for Flightgear to regularly do things someone else tells them to - especially if that someone else has not done any service for the project.

== The FSX threat ==

Sometimes users threaten to leave Flightgear for another simulation software if their idea is not taken into account. From a developer's perspective, this is an empty threat, as the number of people who just use the software is irrelevant for the continuation of the project. This is very different from commercial projects where the number of users largely is the number of customers who finance the project, but in the Flightgear case, things actually work the other way round in that a larger userbase creates a larger drain on the infrastructure, making it more difficult to offer it for free.

Thus, approaching Flightgear with the attitude of a paying customer who is crucial for the project leads nowhere - Flightgear users are not paying customers, and users leaving for FSX will not have any impact on the project.

What will have an impact is contributors leaving the project - but contributors have rendered services to the project already, and so they may receive some attention from other contributors in return.

== The silent majority ==

Several users have in the past questioned whether the feedback provided via the forum and other channels is really representative and argued that they represent the position of the (much larger) silent majority of users who do not provide feedback anywhere.

It is certainly true that the sample of users reporting back is skewed - but the skew goes the opposite direction, since a main driving force for users appearing in the forum is that they experience problems - in all likelihood, the silent majority is therefore silent because these users don't see problems.

However, as argued above, the (non)-existence of a large number of users having one opinion or the other who do not want to get in contact with the project is irrelevant for the way the project works. Unlike paying customers, the sheer number makes no difference anywhere. So even if the silent majority could be demonstrated to be of a certain opinion, the argument would not be stronger.

== Bug reporting ==

The Flightgear project does not have the resources to pay for a user support department, so again all bug reports are handled by volunteers. Most bug reports are answered with requests for more information. The reason is that it is almost impossible to find the cause of a bug if it can't be reproduced. Some users react rather violently to this, apparently out of a notion that they have done their part by reporting the bug, so now it's the developers' duty to fix it, not to ask more questions.

Needless to say, this is an unproductive attitude. Nobody likes to trace bugs, people volunteer nevertheless because they realize there is need. However, to expect that a volunteer will put up with rudeness and go out of his way to investigate many possible causes of a problem he can't see because a user doesn't provide enough information is unrealistic. Users are not paying customers, and the people trying to help with problems are not a paid support department.

== Support for outdated hardware ==

On occasion, users have accused to project of discriminating against them, as they can't run the recent versions of the program on their hardware. Note first that the premise is likely not true - Flightgear is known to run fine on very old hardware using a [[Howto:Debugging FlightGear Crashes|minimum startup profile]] and legacy support is strong driving force for decisions made in the devel community.

However, leaving that aside and assuming that there are systems on which a recent Flightgear version no longer runs - in what way would that be discrimination? Especially since older versions are still available? Why would the project have an obligation to support every bit of hardware in existence? With the same logic that 'free' equals 'everyone must be able to use it' - should the project provide computers for everyone who wants to use the simulator but does not own a computer at all?

Users who invest in high end graphics cards have at least just as much reason to expect that new version make use of their computers' performance. Many novel features are implemented optionally can can be switched off, the project tries hard to be backward compatible (and is probably much more so than any commercial software) but fundamentally there is no right of a user that his hardware is supported, and accusations of discrimination against users with low end hardware are just baseless.

Finally, there are features that cannot be realistically run on very outdated hardware, this includes deferred rendering schemes like Rembrandt, many shaders/effects, but also osgEarth support - more often than not, these feature actually '''require''' fairly recent hardware. And in the case of osgEarth, or many other OSG-based features, the hardware requirements (such as e.g. shader/multi-threading support and lots of RAM/VRAM) are actually beyond the control of the FlightGear project - FlightGear merely uses existing software.

File talk:Wikipedia icon 15px.png

2014-06-07T12:26:31Z

Philosopher: forgot the header!

== Linux Libertine crossed W for Wikipedia ==

Hi Johan,

Thanks for the icon, it really helps with visibility of the Wikipedia links. I'm also glad to see that I'm not the only one who uses Linux Libertine (it's the only font I like!). However, if you look at their main page, a few articles down they have a "New Wikipedia-Logo using LinuxLibertine", where they explain the W vs crossed-W. It is the latter I would suggest you use, as it's quite distinctive. I think you can find it in the private use area, last time I checked. [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 12:22, 7 June 2014 (UTC)

File talk:Wikipedia icon 15px.png

2014-06-07T12:22:52Z

Philosopher: Linux Libertine crossed W for Wikipedia

Hi Johan,

Thanks for the icon, it really helps with visibility of the Wikipedia links. I'm also glad to see that I'm not the only one who uses Linux Libertine (it's the only font I like!). However, if you look at their main page, a few articles down they have a "New Wikipedia-Logo using LinuxLibertine", where they explain the W vs crossed-W. It is the latter I would suggest you use, as it's quite distinctive. I think you can find it in the private use area, last time I checked. [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 12:22, 7 June 2014 (UTC)

FlightGear wiki:Instant-Refs

2014-05-31T22:06:07Z

Philosopher: clear selection only if user doesn't hit "cancel"

* A simple userscript extension implemented in JavaScript
* Supported by FireFox, Chrome, Chromium, probably Opera and others
* in case of doubt, just install the GreaseMonkey/[https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en TamperMonkey] extension
* install the script
* go to some sourceforge.net mail archive URL, for example: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5389094A.3080601%40gmail.com/#msg32400727
: or to any forum message
* copy/mark some relevant portion of text
* and directly get a full cquote paragraph that you can add to the wiki here
* [http://wiki.flightgear.org/User_talk:Hooray stop whining that proper cquotes are too painful] :-)

{{Note|For testing purposes, the alert showing the cleaned up fields are still enabled. You can comment it out in extractInfo().}}

<syntaxhighlight lang="javascript">
// ==UserScript==
// @name auto cquotes for sourceforge ml and forum
// @namespace http://wiki.flightgear.org/
// @version 0.5
// @description automatically create proper wikimedia cquotes for sourceforge ml and forum text selections
// @match http://sourceforge.net/p/flightgear/mailman/*
// @match http://forum.flightgear.org/*
// @copyright 2013+, FlightGear.org
// ==/UserScript==

/* for each domain, fields: author, title, date, url.
* for each field:
xpath - relative to the text body element
regex - will extract the first capture group (i.e. '(xxx)')
prepend - a string to be prepended (useful for urls)
*/
var CONFIG = {
"sourceforge.net": {
author: {
xpath: "../../../tr/td/div/small/text()",
regex: "/^From: (.*) <.*@.*>/"
},
title: {
xpath: "../../../tr/td/div/div/b/a/text()"
},
date: {
xpath: "../../../tr/td/div/small/text()",
regex: "/ - (.*-.*-.*) /"
},
url: {
xpath: "../../../tr/td/div/div/b/a/@href",
prepend: "http://sourceforge.net"
}
},
"forum.flightgear.org": {
author: {
xpath: "../p/strong/a/text()"
},
title: {
xpath: "../h3/a/text()"
},
date: {
xpath: "../p/text()[2]",
regex: "/ » (.*),/"
},
url: {
xpath: "../p/a/@href",
regex: "/\.(.*)/",
prepend: "http://forum.flightgear.org"
}
}

};

function getPathTo(element) {
if (element.id!=='')
return 'id("'+element.id+'")';
if (element===document.body)
return element.tagName;

var ix= 0;
var siblings= element.parentNode.childNodes;
for (var i= 0; i<siblings.length; i++) {
var sibling= siblings[i];
if (sibling===element)
return getPathTo(element.parentNode)+'/'+element.tagName+'['+(ix+1)+']';
if (sibling.nodeType===1 && sibling.tagName===element.tagName)
ix++;
}
}

function nowiki(text) {
return "<nowiki>" + text + "</nowiki>";
}

function extractInfo(parentPath, profile) {
var info = {};
for (field in profile) {
var fieldInfo = "";
if (profile[field].xpath) {
var fullPath = parentPath + "/" + profile[field].xpath;
fieldInfo = document.evaluate(fullPath, document, null, XPathResult.STRING_TYPE, null ).stringValue;
}

if (profile[field].regex) {
var regex = eval(profile[field].regex); // to cleanup info
fieldInfo = fieldInfo.match(regex)[1];
}

if (profile[field].prepend) {
fieldInfo = "http://" + window.location.hostname + fieldInfo;
}

alert(field+" = "+fieldInfo);
info[field] = fieldInfo;
}

return info;
}

// FIXME: remove extra \CR \LF (?)
function CreateCquote(text, parent) {
var info = {};

if(parent) {
var profile = CONFIG[window.location.hostname];
var parentPath = getPathTo(parent);

info = extractInfo(parentPath, profile);
} else {
// fallback. XXX: not tested
info.url = document.URL;
info.title = "from " + window.location.hostname;
info.author = "";
info.date = "";
}

//TODO: add template string to profile
var template = "{{cquote" + "\n" +
" |" + nowiki(text) + "\n" +
" |{{cite web |url=" + info.url + "\n" +
" |title=" + nowiki(info.title) + "\n" +
" |author=" + nowiki(info.author) + "\n" +
" |date=" + nowiki(info.date) + "\n" +
" }}" + "\n" +
"}}";
return template;
}

function GetSelectedText () {
var text = "";
var parent = null;

if (document.getSelection) {
var sel = document.getSelection ();
parent = sel.anchorNode.parentNode;// anchorNode is the textnode, parentNode is the actual parent, i.e. html element
text = sel;
} else if (document.selection) { // for IE <= v8
var textRange = document.selection.createRange ();
parent = textRange.parentElement(); // XXX: not tested!
text = textRange.text;
}

// check if we got text
if ( text != "" ) {
var cquote = CreateCquote(text, parent);
if (window.prompt ("Copy to clipboard: Ctrl+C, Enter", cquote) != null)
window.getSelection().removeAllRanges(); // deselect all text
}
}

function register() {
// check if we have a matching domain in the CONFIG hash
if (CONFIG.hasOwnProperty(window.location.hostname) ) {
// if yes, register a callback to handle mouse events
document.onmouseup = GetSelectedText;
}
}

window.addEventListener('load', register );
</syntaxhighlight>

[[Category:Wiki maintenance]]

Canvas development

2014-05-30T21:09:11Z

Philosopher: /* Placement/Element for Streaming: Computer Vision */ little bug in citation

{{Stub}}
{{Canvas Navigation}}

{{Note|This article is primarily of interest to people familiar with [[Building FlightGear]] from source, and wanting to extend the [[Canvas]] system in SimGear. Readers are assumed to be familiar with [[Programming_Resources|C++ and {{abbr|OSG|OpenSceneGraph}}
]], the [[Property Tree]] and basic FlightGear {{abbr|API|Application Programming Interface}}s like [http://docs.freeflightsim.org/simgear/classSGPropertyNode.html SGPropertyNode], [[Howto:Use Property Tree Objects|Property Objects]], [[Howto:Create new subsystems|SGSubsystem and SGPropertyChangeListener]]. The Canvas code itself makes extensive use of the {{abbr|STL|Standard Template Library}} and Boost. The latest Canvas/Doxygen docs can be found [http://docs.freeflightsim.org/simgear/classsimgear_1_1canvas_1_1Canvas.html here].

There are two main ways to extend FlightGear's Canvas system:
* new/extended elements (elements determine '''what/how''' something is to be rendered (text,image,line,circle), i.e. new rendering primitives that cannot be easily/efficiently expressed using existing means, e.g. a moving map, camera views or ESRI support)
* new/extended placements (placements determine '''where''' a canvas is to be placed, e.g. cockpit, scenery, GUI dialog or osgviewer window)

Whenever all existing elements (group, map, text, image, path) should benefit from an addition, such as for example adding effects/shader support, it makes sense to extend the underlying base class itself, i.e. [http://docs.freeflightsim.org/simgear/classsimgear_1_1canvas_1_1Element.html Canvas::Element].
In addition, the '''map''' element (a subclass of group) can be extended to support additional map projections.
People just wanting to add a new layer to an existing dialog or instrument, will probably want to refer to [[Canvas MapStructure]] instead.
}}

The canvas system is a property-driven FlightGear subsystem that allows creating, rendering and updating dynamic OpenGL textures at runtime by setting properties in the FlightGear Property Tree.

The property tree is the sole interfacing mechanism in use by the Canvas system. A so called listener-based subsystem (via SGPropertyChangeListener) will watch the canvas sub tree in the main property tree for "events" (i.e. properties being set, written to/modified), and then update each associated texture accordingly, e.g. by adding a requested vector or raster image, drawing a map, placing symbols or placing text labels with custom fonts.

Elements can be nested and added to groups which support showing/hiding and clipping of segments. Vector drawing is handled via ShivaVG.

All property updates result in native C++/{{abbr|OSG|OpenSceneGraph}} data structures being updated (typically using {{abbr|OSG|OpenSceneGraph}}
/STL/Boost containers), so that the property tree and scripting are solely used to send update events, which ensures that Canvas-based systems are typically fast enough, often delivering frame rates beyond ~40-60 {{abbr|fps|frames per second}}.

Animations are currently not directly supported, instead these can be implemented by using separate canvas groups and hiding/showing them as needed, or simply by changing the size/color/styling attributes of a canvas group using Nasal timers. Another option to update a canvas without relying on Nasal timers (i.e. due to {{abbr|GC|Nasal Garbage Collection}} considerations) is using so called "Property Rules", which are currently not yet exposed to Nasal, but which can be used for any needs where scripting overhead should be minimal.

The Canvas fully supports recursion, by allowing other canvases (and sub-regions of them via texture-mapping) to be referenced and used as raster images, so that multiple canvases can be chained together, but also through the notion of "groups", which are containers for other canvas elements, including child groups or elements referencing other canvases.

This can be particularly useful for projects requiring multi-texturing and other multi-pass texturing stages. This mechanism is also one of the main building blocks used by the [[MapStructure]] charting framework to implement caching support via texture maps, without needing any changes on the C++ side.

The canvas itself is developed with a focus on primarily being an enabling technology. In other words, the canvas is not about implementing individual features like a {{abbr|PFD|Primary Flight Display}}, {{abbr|ND|Navigational Display}}, EFIS, EICAS or other {{abbr|MFD|Multi-Function Display}} instruments like a moving map or a {{abbr|GUI|Graphical User Interface}} library. Rather, the Canvas system is all about coming up with a flexible and efficient system that allows end-users (aircraft developers and other base package contributors) to develop such features themselves in user space (i.e. the base package) via scripting - without having to be proficient C++ programmers, without having to rebuild FlightGear from source, and without having to be familiar with OpenSceneGraph, OpenGL or other technologies that typically involve a steep learning curve (i.e. STL/Boost).

This approach has several major advantages - in particular, it frees core developers from having to develop and maintain end-user features like a wxradar, groundradar or [[Navigational Display]]/{{abbr|PFD|Primary Flight Display}} by empowering content (base package) developers to handle the implementation of such features themselves.

Thus, development of content is moved to user space (i.e. the base package). Recently, we've seen a shift in trend here, because more and more core developers focusing on end user requests, instead of implementing those feature requests, they implement the building blocks and infrastructure to delegate the implementation of these features to user space.

Besides, core developers are generally overstretched, and there are not enough core developers to handle all core development related tasks:

{{cquote|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. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39921.html|title=Atmospheric Light Scattering|author=Stuart Buchanan|date=Thu, 25 Apr 2013 07:28:28 -0700}}</ref>|Stuart Buchanan}}
<references/>

The only way to deal with this is to occasionally shift the core development focus from developing complex high level end users features (such as an {{abbr|ND|Navigational Display}}, TCAS or WXRADAR) that take years to develop, to just providing lower level {{abbr|API|Application Programming Interface}}
s (like a navdb {{abbr|API|Application Programming Interface}} or a 2D drawing {{abbr|API|Application Programming Interface}} like [[Canvas]]) to enable base package developers to develop those really high level features themselves.

This is the route that seemed to work out fairly well for the local weather system, which was prototyped and implemented by a single base package developer in scripting space, who just asked for certain scripting hooks to be provided at some point.

For example, when Stuart, Torsten or Erik implemented LW-specific core extensions, these were about providing new hooks to be used by Thorsten. They didn't commit to implementing a weather system, they just enabled somebody else to continue his work. So this strategy is as much about delegation, as it is about organizing core development.

Core developers cannot possibly implement all the ideas and feature requests that end users may have, but they can at least provide a toolbox for base package developers to implement such features. Now, without doubt, implementing a WXRADAR, TCAS, AGRADAR or even a full {{abbr|ND|Navigational Display}}
/{{abbr|MFD|Multi-Function Display}} is incredibly complex and time-consuming.

Exposing a 2D drawing {{abbr|API|Application Programming Interface}} or a navdb {{abbr|API|Application Programming Interface}} to base package developers would have been much simpler and less time-consuming, at the cost of possibly not providing certain instruments/features directly - while still providing the building blocks for skilled base package contributors to implement such instruments eventually within the base package, rather than within the C++ source code where evolution and maintenance of such instruments is inherently limited by the availability of C++ developers.

Given the progress we've seen in Canvas-related contributions boosted by having a 2D {{abbr|API|Application Programming Interface}}, this is a very worthwhile route for developing {{abbr|MFD|Multi-Function Display}}-style instruments or other end-users features without being limited by our shortage of core developers.

Furthermore, the amount of specialized code in the main FlightGear code base is significantly reduced and increasingly unified: One major aspect of adopting the Canvas system was [[Unifying the 2D rendering backend via canvas]], so that more and more of the old/legacy code can be incrementally re-implemented and modernized through corresponding wrappers, which includes scripting-space frameworks for existing features like the [[Hud]] system, but also our existing PLIB/PUI-based GUI, and the old 2D panels code or the [[Map]] dialog.

Many of these features are currently using legacy code that hasn't been maintained in years, causing issues when it comes to making use of certain OSG optimizations.

In addition, widgets and instruments will no longer be hard-coded, but rather "compiled" into hardware-accelerated Canvas data structures while being initialized, which will be typically animated by using timers or listeners (via scripting or property rules). The fact that previously hard-coded widgets or instruments are now fully implemented in scripting space also means that deployment of updates no longer requires manual installations of binaries necessarily.

This is analogous to how more and more software programs, such as browsers like Firefox/Chrome, are using an increasingly scripted approach towards implementing functionality, i.e. using JavaScript/XUL to move the implementation of certain features out of native code.

Finally, an increasingly unified 2D rendering back-end also provides the opportunity to make porting/re-targeting FlightGear increasingly feasible, no matter if this is about mobile gaming platforms, mobile phones (e.g. Android) or embedded hardware like a Rasberry PI: Without a unified 2D rendering back-end, all other subsystems doing 2D rendering would need to be manually ported (hud, cockpit, instruments, GUI etc).

A unified 2D rendering back-end using the Canvas system ensures instead that all Canvas-based features will remain functional, as long as the Canvas itself is able to run on the corresponding platform/hardware, because there's really just a single subsystem that handles '''all''' 2D rendering via different user-space wrappers, and that would need porting (e.g. to support OpenGL ES).

Also, GUI dialogs and instruments can make use of other Canvas-based features, e.g. for showing a GUI dialog on an instrument, or instruments in dialogs.

The property tree centric implementation approach of the Canvas also means that all Canvas-based frameworks could technically work in a standalone [[FGCanvas]]/[[FGPanel]] mode, but also in multi-instance (master/slave) setups such as those common for FSWeekend/LinuxTag. This is yet another novelty, because most existing hard-coded instruments cannot be easily modified to work in such multi-instance setup scenarios. The Canvas system however -being based on the property tree- could retrieve property updates from external instances, e.g. via telnet/UDP or [[HLA]] without requiring major re-architecting.



[[File:PropertyTree and Canvas.png|1000px|property tree & canvas]]

== Frameworks ==

[[File:CanvasOverview02-2014.png|thumb|Overview of the Canvas system and its scripting space frameworks]]

Obviously, the Canvas {{abbr|API|Application Programming Interface}} s themselves are not intended for specific end-user features like developing a {{abbr|PFD|Primary Flight Display}}, {{abbr|ND|Navigational Display}} or EICAS - therefore, you will typically see wrappers implemented in scripting space for certain needs - i.e. Canvas frameworks intended to help with the development of certain types of instruments for example. Frameworks will usually use the Canvas scripting space API directly, while providing a more concrete, use-case specific API, on top.

{{Canvas Frameworks}}

== Elements ==


[[File:CanvasElements-Overview.png|800px|Overview of currently supported Canvas Elements]]

All new canvas elements need to implement the Canvas::Element interface (new elements can also sub-class existing elements, e.g. see the implementation of the Map and Window($FG_SRC/Canvas) elements), the canvas system currently supports the following primitives (see [[$SG_SRC]]/canvas/elements):

* '''CanvasGroup''' - main element: for grouping (a group of arbitrary canvas primitives, including other groups)
* CanvasText - for rendering texts (mapped to osgText)
* CanvasPath - for rendering vector graphics (mapped to OpenVG, currently also used to render SVGs into groups)
* '''CanvasMap''' - for rendering maps (automatic projection of geographic coordinates to screen coordinates, subclass of group)
* CanvasImage - for rendering raster images (mapped to osg::Image)
* CanvasWindow - this is part of $FG_SRC/Canvas/Window.?xx, it's a subclass of CanvasImage, used to implement windows (as of 05/2014 also to be found in simgear)



[[File:Canvas-Elements.png|thumb|Canvas vs. Canvas Elements]]

Most end-user features can be decomposed into lower-level components that need to be available in order to implement the corresponding feature in user-space.

Thus, the canvas system is based on a handful of rendering modes, each supporting different primitives - each of those modes is implemented as a so called "Canvas Element", which is a property-tree controlled subtree of a canvas texture using a certain name, that supports specific events and notifications.

According to the development philosophy outlined above, you obviously won't see new canvas elements that are highly use-case specific, such as a "night vision" or FLIR element. Instead, what is more likely to be supported are the lower level building blocks to enable end-users creating such features, i.e. by adding support for running custom effects/shaders and by rendering scenery views to canvas textures.

== Adding a new Element ==
You will want to add a new Canvas::Element whenever you want to add support for features which cannot be currently expressed easily (or efficiently) using existing means (i.e. via existing elements and scripting space frameworks). For example, this may involve projects requiring camera support, rendering scenery views to a texture, rendering 3D models to a texture or doing a complete moving map with terrain elevations/height maps (even though the latter could be implemented by sub-classing Canvas::Image to some degree).

To add a new element, these are the main steps:

* Navigate to [[$SG_SRC]]/canvas/elements
* Create a new set of files myElement.cxx myElement.hxx
* add them to [[$SG_SRC]]/canvas/elements/CMakeLists.txt (as per [[Developing using CMake]])

<syntaxhighlight lang="diff">
diff --git a/simgear/canvas/elements/CMakeLists.txt b/simgear/canvas/elements/CMakeLists.txt
index bd21c13..9fdd48d 100644
--- a/simgear/canvas/elements/CMakeLists.txt
+++ b/simgear/canvas/elements/CMakeLists.txt
@@ -1,6 +1,7 @@
include (SimGearComponent)

set(HEADERS
+ myElement.hxx
CanvasElement.hxx
CanvasGroup.hxx
CanvasImage.hxx
@@ -14,6 +15,7 @@ set(DETAIL_HEADERS
)

set(SOURCES
+ myElement.cxx
CanvasElement.cxx
CanvasGroup.cxx
CanvasImage.cxx
@@ -23,4 +25,4 @@ set(SOURCES
)
</syntaxhighlight>

Next, open the header file and add a new Element classs:

<syntaxhighlight lang="cpp">
#ifndef CANVAS_MYELEMENT_HXX_
#define CANVAS_MYELEMENT_HXX_

#include <simgear/props/propsfwd.hxx>

#include "CanvasElement.hxx"

namespace simgear
{
namespace canvas
{

class myElement : public Element
{
public:
static const std::string TYPE_NAME;
static void staticInit();

myElement( const CanvasWeakPtr& canvas,
const SGPropertyNode_ptr& node,
const Style& parent_style = Style(),
Element* parent = 0 );
virtual ~myElement();
protected:
virtual void update(double dt);
private:
myElement(const myElement&) /* = delete */;
myElement& operator=(const myElement&) /* = delete */;
};

} // namespace canvas
} // namespace simgear

#endif /* CANVAS_MYELEMENT_HXX_ */
)
</syntaxhighlight>

Next, add the source file implementing the new myElement class:

<syntaxhighlight lang="cpp">
#include "myElement.hxx"
#include <simgear/props/props.hxx>

#include <simgear/misc/sg_path.hxx>
namespace simgear
{
namespace canvas
{

const std::string myElement::TYPE_NAME = "myelement";

void myElement::staticInit()
{
if( isInit<myElement>() )
return;

}

//----------------------------------------------------------------------------
myElement::myElement( const CanvasWeakPtr& canvas,
const SGPropertyNode_ptr& node,
const Style& parent_style,
Element* parent ):
Element(canvas, node, parent_style, parent)

{
SG_LOG(SG_GENERAL, SG_ALERT, "New Canvas::myElement element added!");

}

//----------------------------------------------------------------------------
myElement::~myElement()
{
SG_LOG(SG_GENERAL, SG_ALERT, "Canvas::myElement element destroyed!");

}

void myElement::update(double dt)
{
}

} // namespace canvas
} // namespace simgear

</syntaxhighlight>

Next, edit CanvasGroup.cxx to register your new element (each canvas has a top-level '''root''' group, so that's how elements show up), navigate to Group::staticInit() and add your new element type there (don't forget to add your new header):

<syntaxhighlight lang="diff">
diff --git a/simgear/canvas/elements/CanvasGroup.cxx b/simgear/canvas/elements/CanvasGroup.cxx
index 51523f4..24e19d3 100644
--- a/simgear/canvas/elements/CanvasGroup.cxx
+++ b/simgear/canvas/elements/CanvasGroup.cxx
@@ -21,6 +21,7 @@
#include "CanvasMap.hxx"
#include "CanvasPath.hxx"
#include "CanvasText.hxx"
+#include "myElement.hxx"
#include <simgear/canvas/CanvasEventVisitor.hxx>
#include <simgear/canvas/MouseEvent.hxx>

@@ -60,6 +61,7 @@ namespace canvas
return;

add<Group>(_child_factories);
+ add<myElement>(_child_factories);
add<Image>(_child_factories);
add<Map >(_child_factories);
add<Path >(_child_factories);
</syntaxhighlight>

Next, navigate to [[$FG_ROOT]]/Nasal/canvas/api.nas and extend the module to add support for your new element:

<syntaxhighlight lang="diff">
diff --git a/Nasal/canvas/api.nas b/Nasal/canvas/api.nas
index 85f336a..81c0fa0 100644
--- a/Nasal/canvas/api.nas
+++ b/Nasal/canvas/api.nas
@@ -314,6 +314,18 @@ var Element = {
}
};

+# myElement
+# ==============================================================================
+# Class for a group element on a canvas
+#
+var myElement = {
+# public:
+ new: func(ghost)
+ {
+ return { parents: [myElement, Element.new(ghost)] };
+ },
+};
+
# Group
# ==============================================================================
# Class for a group element on a canvas
@@ -958,7 +970,8 @@ Group._element_factories = {
"map": Map.new,
"text": Text.new,
"path": Path.new,
- "image": Image.new
+ "image": Image.new,
+ "myelement": myElement.new,
};

</syntaxhighlight>

Next, rebuild SG/FG and open the [[Nasal Console]] and run a simple demo to test your new element:

<syntaxhighlight lang="nasal">
var CanvasApplication = {
##
# constructor
new: func(x=300,y=200) {
var m = { parents: [CanvasApplication] };
m.dlg = canvas.Window.new([x,y],"dialog");
m.canvas = m.dlg.createCanvas().setColorBackground(1,1,1,1);
m.root = m.canvas.createGroup();

##
# creates a new element
m.myElement = m.root.createChild("myelement");

m.init();
return m;
}, # new

init: func() {

var filename = "Textures/Splash1.png";
# create an image child for the texture
var child=me.root.createChild("image")
.setFile( filename )
.setTranslation(25,25)
.setSize(250,250);
}, #init

}; # end of CanvasApplication

var splash = CanvasApplication.new(x:300, y:300);

print("Script parsed");v
</syntaxhighlight>

you may also want to check out [[$FG_SRC]]/Scripting/NasalCanvas.?xx to learn more about exposing custom elements to scripting space via [[Nasal/CppBind]].
Next, you'll want to implement the update() methods and the various notification methods supported by CanvasElement:
* childAdded
* childRemoved
* childChanged
* valueChanged

For event handling purposes, you'll also want to check out the following virtual CanvasElement methods:
* accept()
* ascend()
* traverse()
* handleEvent()
* hitBound()

== Discussed Enhancements ==

{{Note|The features described in the following section aren't currently supported or being worked on, but they've seen lots of community discussion over the years, so that this serves as a rough overview.}}
=== An integrated Canvas based launcher ===
{{mergeto|Template:Canvas Frameworks|date=May 2014}}

Also see {{Issue|1295}}, [[Reset & re-init#Benefits]] and [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/5387B0DB.4030001%40bham.ac.uk/#msg32396634]

{{cquote|people have been working on making external launchers obsolete for most use-cases in future versions, which is likely to materialize around FG 4.2+ according to recent discussions and commits.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=37&t=22330&p=202924&hilit=fgrun+obsolete#p202924|title=<nowiki>Dev and test environment</nowiki>|author=<nowiki>Hooray</nowiki>|date=<nowiki>Thu May 15, 2014 1:33 pm</nowiki>}}</ref>|<nowiki>Hooray</nowiki>}}

{{cquote|An integrated GUI launcher is something that we'd all like to see, and which we are working towards - it will probably happen within the next 12-18 months (just a guess), not because it's such a high priority, but because, by then, we should have all the pieces for it in place - and the 3-4 main core developers (main, in terms of activity) agree that this is the way forward, so from a middleware (Nasal/XML, Canvas) standpoint, we're going to help with creating a framework to parse our existing GUI dialogs and turn them into canvas-driven GUI widgets, which will need to be developed first of all though - that's the kind of stuff that Philosopher has been doing in his REPL interpreter: custom GUI work.
The chances are pretty good that the upcoming GUI will look much less 1940s style than the existing GUI, i.e. fairly modern actually.
But the good news for you is that styling/skinnig is intended to be supported eventually. Tom has in fact added quite a bit of code to make that fast and flexible, not just Nasal, but also C++ - so he seems to consider that a priority, too.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=71&t=21617&p=209571&hilit=#p209586|title=<nowiki>Dev and test environment</nowiki>|author=<nowiki>Hooray</nowiki>|date=<nowiki>Thu May 15, 2014 1:33 pm</nowiki>}}</ref>|<nowiki>Hooray</nowiki>}}

{{cquote|The main thing here is "run-time reinitialization" - i.e. having code that doesn't need to be shut down to change settings, but that simply fetches the new settings and applies them.
Zakalawe has been working towards this as part of the reset/re-init effort - mid-term, the idea is to make GUI launchers obsolete for most people, by providing an in-sim GUI launcher where such settings can be directly changed, including changing aircraft, but also saving/loading flights.
For these reasons, most of us are not too eager to extend external GUI launchers.

Canvas-wise, there isn't much missing to provide an integrated GUI launcher - what would be useful though, is having a new element that renders arbitrary 3D models/camera views to a texture, i.e. for aircraft/scenery previews. But otherwise, this is mostly a matter of having scripting (Nasal) and Canvas available earlier, so that a GUI launcher can created using ~200-300 lines of Nasal. This is also where we could provide a pulldown menu with settings for a handful of startup/run-time profiles.

And of course there are still a handful of subsystems that cannot currently be re-intialized without shutting down the whole thing.
For non programmers, it's helpful to imagine it like exchanging your car radio, seats, brakes or even engine, while going 100 mph - not impossible to pull off, but quite a few - especially because the "car" (FG) was never designed with this requirement in mind.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=71&t=21617&p=209571&hilit=#p209571|title=<nowiki>Dev and test environment</nowiki>|author=<nowiki>Hooray</nowiki>|date=<nowiki>Thu May 15, 2014 1:33 pm</nowiki>}}</ref>|<nowiki>Hooray</nowiki>}}

{{cquote|I made some experiments with creating a GUI using Canvas, but it’s not an area I especially enjoy or feel comfortable working in, so progress was slow, and recently, non-existant. I have considered making a placeholder GUI using PUI widgets, which would only take a couple of days for something basic, but again hacking the PUI code is far from enjoyable.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/D4E91618-5AE0-4073-98B3-43711E70871A%40mac.com/#msg32375981|title=<nowiki>24 days from freeze: what happened to...</nowiki>|author=<nowiki>James Turner</nowiki>|date=<nowiki>2014-05-24 09:33:20</nowiki>}}</ref>|<nowiki>James Turner</nowiki>}}

=== Supporting Cameras ===
{{Note|People interested in working on this may want to check out the following pointers:
* [http://docs.freeflightsim.org/flightgear/classflightgear_1_1CameraGroup.html CameraGroup]
* [http://docs.freeflightsim.org/flightgear/structflightgear_1_1CameraInfo.html CameraInfo]
* Rembrandt Commits
* ...

}}

Background:
* [[Howto:Use a Camera View in an Instrument]]
* [[$FG_ROOT]]/Docs/README.multiscreen
* http://docs.freeflightsim.org/flightgear/classflightgear_1_1CameraGroup.html
* https://gitorious.org/fg/zans-flightgear/commits/09832d8076a985a329500c027c1ed4f9b72bb1a9
* http://trac.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuide/ViewerVSCompositeViewer

Also see [[The FlightGear Rendering Pipeline]]

{{cquote|I'm looking to replicate a camera with a fixed viewpoint from the aircraft. For example looking directly down.

Is there a way I can use some scripting method to call a new window displayed in the bottom right hand side of the screen showing a fixed camera view, without having to edit the preferences for my machine? I'd like it to be easily distributable. <ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=18&t=22376&p=203175#p203145|title=Sub window view|author=Avionyx|date=Wed Mar 12, 2014 7:08 am}}</ref>|Avionyx }}

{{cquote|I was wondering if it were possible to restrict the camera output to only one half of the running FG window? I'm hoping to do this so that I may have the map and route manager GUIs active in the other half, so that they aren't obscuring the camera view (and also have the entire HUD visible). So basically, half the window straight down the center - left half is just black, right half is the camera.

Although this would also be solved if there were an external FG dynamic navigational map program, that also displayed waypoints... (I don't think there is one, right?).

Additionally, I would love to hear that this question can be answered with Nasal, as I really can't afford to edit the source code and recompile (it's for a project, and I have no admin rights on the laboratory machines).<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=18&t=21897&p=200744&hilit=#p198735|title="Half" the FG window?|author=seabutler|date=Fri Jan 24, 2014 5:38 am}}</ref>|seabutler }}

{{cquote|I'm trying to debug reflection shader I'm working on. I have a camera attached to a scene graph, which pre-renders (osg::Camera::PRE_RENDER) scene into offscreen surface (osg::Camera::FRAME_BUFFER_OBJECT); For a debugging purposes I have to see the result of that render pass.
I'm not very good yet in FG internal structure, so I'd like to ask - can this camera be somehow attached to FG camera views (v), or embedded as separate window ?<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg20282.html|title=FG - camera for debugging purposes.|author=Vladimir Karmisin|date=Thu, 08 Jan 2009 05:17:07 -0800}}</ref>|Vladimir Karmisin }}

{{cquote|I want to give access to every stage of the rendering to the effect system. The geometry pass outputs to render target, but the fog, the lights, the bloom need to have access to the textures of the buffer, and there is a separate one for each camera associated to windows or sub windows. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg35553.html|title=Announcing Project Rembrandt|author=Frederic Bouvier |date=Sun, 01 Jan 2012 07:14:43 -0800}}</ref>|Frederic Bouvier }}

{{cquote|It would be nice if the Effects framework had a way to load arbitrary textures and make them available to effects.I don't know if there is a better way to create your texture offline than write C++ code in simgear. {{abbr|OSG|OpenSceneGraph}} will read a TIFF file with 32bits per component as a floating point texture... assuming you can create
such a thing.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg37873.html|title=Functions to textures?|author=Tim Moore |date=Tue, 24 Jul 2012 22:38:35 -0700}}</ref>|Tim Moore }}

{{cquote|modify the Renderer class to separate from the scenegraph, terrain and models on one hand, the skydome and stars on the other, and finally the clouds.
These three elements are passed to the CameraGroup class in order to be treated separately in the new rendering engine (and put together in the current one).<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36481.html|title=RFC: changes to views and cameras|author=Frederic Bouvier |date=Wed, 07 Mar 2012 05:08:06 -0800}}</ref>|Frederic Bouvier }}

{{cquote|I want to point out my work on my "newcameras" branch: https://gitorious.org/~zan/fg/zans-flightgear/commits/newcameras which allows user to define the rendering pipeline in preferences.xml. It does not (yet?) have everything Rembrandt's pipeline needs, but most likely is easily enhanced to support those things.

Basically this version adds support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that.

I wish this work could be extended (or maybe even I can extend it ;) to handle the Rembrandt camera system. This will not solve all problems in the merge, but some of them.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36481.html|title=Rembrandt the plan|author=Lauri Peltonen |date= Wed, 07 Mar 2012 04:58:44 -0800}}</ref>|Lauri Peltonen }}

{{cquote|I was not aware of your work. But given what you write here, this looks pretty promising. Fred mentioned your name in an offline mail. I would highly apprechiate that we do not lock out low end graphics boards by not having any fallback. May you both should combine forces?
From what I read, I think both are heading in the same global direction and both implementations have some benefits over the other?<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36481.html|title=Rembrandt the plan|author=Mathias Fröhlich |date= Wed, 07 Mar 2012 10:15:31 -0800}}</ref>|Mathias Fröhlich }}

{{cquote|I would like to extend the format to avoid duplicating the stages when you have more than one viewport. What I see is to specify a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36481.html|title=RFC: changes to views and cameras|author=Frederic Bouvier |date=Wed, 07 Mar 2012 05:08:06 -0800}}</ref>|Frederic Bouvier }}

{{cquote|Mapping cameras to different windows, which can be opened on arbitrary screens, will absolutely still be supported. I know that multi-GPU setups are
important for professional users and our demos.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg17026.html|title=RFC: changes to views and cameras|author=Tim Moore |date=30 Jun 2008 22:46:34 -0700}}</ref>|Tim Moore }}

{{cquote|I believe that we need to distinguish between different render to texture cameras. Camera nodes must be accessible from within flightgear. That ones that will end in mfd displays or hud or whatever that is pinned into models. And one that are real application windows like what you describe - additional fly by view, and so on. And I believe that we should keep that separate and not intermix the code required for application level stuff with building of 3d models that do not need anything application level code to animate the models ... I think of some kind of separation that will also be good if we would do HLA between a viewer and an application computing physical models or controlling an additional view hooking into a federate ...<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg17026.html|title=RFC: changes to views and cameras|author=Mathias Fröhlich |date=30 Jun 2008 22:46:34 -0700}}</ref>|Mathias Fröhlich }}

{{cquote|I've done some work with setting up a model of a pan/tilt camera system that can point at a specific wgs84 point or along a specific NED vector
(i.e. nadir, or exactly at my shadow, etc.) This was [unfortunately] for a paid consulting project so that code doesn't live in the FlightGear tree. However, it's really easy to configure a view that stays locked on a specific lon/lat and I hacked a small bit of nasal to copy the point you click on over into the view target variables so you can click any where in the scene and the pan/tilt camera will hold center on that exact location. FlightGear offers a lot of flexibility and comparability in this arena.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg37331.html|title=LiDAR simulation in FG and powerline scenery|author=Curtis Olson |date= Tue, 15 May 2012 14:19:34 -700}}</ref>|Curtis Olson }}

{{cquote|Would it be possible to place the new "view" into a window instead of having a dedicated view? That would allow you to have an instrument panel with a blank cut-out that could hold this newscam/FLIR window.The easiest way to visualize the idea I have is to think about the view you'd see in one of the rear-view mirrors that most fighters have along the canopy bow (and the Spitfire has mounted on top of the canopy bow, outside the cockpit). You'd see your full screen view as usual, but you'd also have these "mirrors" showing the view behind you at the same time.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg22880.html|title=view manager "look at" mode|author=Gene Buckle |date= Thu, 23 Jul 2009 10:11:05 -0700}}</ref>|Gene Buckle }}

{{cquote|One thing we have to consider with rear view mirrors is that we don't currently have the ability to flip the display for the "mirror" affect.There's got to be a very simple view transform matrix that would invert the display in the horizontal direction. Probably the identity matrix with the appropriate axis negated (-1). It might be a relatively simple thing to add to the view transform pipeline at some point.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg22880.html|title=view manager "look at" mode|author=Curtis Olson |date= Thu, 23 Jul 2009 10:11:05 -0700}}</ref>|Curtis Olson }}

{{cquote|I had a look at the this idea a while back - the problem I came across was that the camera would show the view to the rear NOT the mirror image. I
couldn't see a way around that without a great deal of processing. At hat point I gave up.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg22880.html|title=view manager "look at" mode|author=Vivian Meazza |date= Thu, 23 Jul 2009 10:11:05 -0700}}</ref>|Vivian Meazza }}

* http://sourceforge.net/p/flightgear/mailman/message/32394673/
<references/>

=== Effects / Shaders ===
{{cquote| I'm currently experimenting with a 2D Canvas and rendering everything to a texture. For this I use FGODGauge to render to texture and
FGODGauge::set_texture to replace a texture in the cockpit with the texture from the fbo. This works very well [...] I have just extended the ReplaceStaticTextureVisitor::apply(osg::Geode& node) method to also replace texture inside effects.

It works now by using the same technique as for the SGMaterialAnimation where a group is placed in between the object whose texture should be changed and its parent. This group overrides the texture:<syntaxhighlight lang="cpp">virtual void apply(osg::Geode& node)
{
simgear::EffectGeode* eg =
dynamic_cast<simgear::EffectGeode*>(&node);
if( eg )
{
osg::StateSet* ss = eg->getEffect()->getDefaultStateSet();
if( ss )
changeStateSetTexture(ss);
}
else
if( node.getStateSet() )
changeStateSetTexture(node.getStateSet());
int numDrawables = node.getNumDrawables();
for (int i = 0; i < numDrawables; i++) {
osg::Drawable* drawable = node.getDrawable(i);
osg::StateSet* ss = drawable->getStateSet();
if (ss)
changeStateSetTexture(ss);
}
traverse(node);
}
</syntaxhighlight>
<syntaxhighlight lang="cpp">
stateSet->setTextureAttribute(0, _new_texture,
osg::StateAttribute::OVERRIDE);
stateSet->setTextureMode(0, GL_TEXTURE_2D, osg::StateAttribute::ON);</syntaxhighlight><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg37225.html|title=<nowiki>Replace texture with RTT</nowiki>|author=<nowiki>Thomas Geymayer</nowiki>|date=<nowiki>Tue, 01 May 2012 15:34:41 -0700</nowiki>}}</ref>|<nowiki>Thomas Geymayer</nowiki>}}

{{cquote|If you want to pass substantial amounts of data, I’d suggest to use a texture (with filtering disabled, probably) to pass the info. Since we don’t have much chance of using the ‘correct’ solution (UBOs) in the near future.

If you need help generating a suitable texture on the CPU side, let me know.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32072598/|title=<nowiki>Passing arrays to a shader</nowiki>|author=<nowiki>James Turner</nowiki>|date=<nowiki> 2014-03-07 10:27:40</nowiki>}}</ref>|<nowiki>James Turner</nowiki>}}

<references/>

At some point, the canvas system itself could probably benefit from being also able to use the Effects/Shader framework, so that canvas textures can also be processed via effects and shaders optionally, before they get drawn. That should make all sorts of fancy effects possible, such as night vision cameras or thermal view, rendered to canvas textures/groups.

It is currently not yet clear how to address this best, the easiest option might be to specify if effects or vertex/fragment shaders shall be invoked via properties (boolean), including their file names referring to [[$FG_ROOT]]?

That would then disable the default rendering pipeline for those canvas textures and use shaders.

Basically, anything that's not directly possible via the core canvas system or via its Nasal wrappers, would then be handled via effects/shaders. So we would gain lots of flexibility, and performance benefits.

Ideally, there could be a simple interface class, so that these things can be customized via listeners, like the property-observer helper, just specific to enabling shaders for a canvas texture.
So if people really want to create really fancy textures or camera views, they could use effects/shaders then, which would keep the design truly generic, and it would ensure that there's no bloat introduced into the main canvas system.

We did have some discussions about supporting per-canvas (actually per canvas::Element) effects and shaders via properties, TheTom even mentioned that he was interested in supporting this at some point, especially given the number of projects that could be realized like that (FLIR, night vision, thermal imaging etc) - but so far, there are quite a few other things that are taking precedence obviously - so, as far as I am aware, there's nobody working on effects/shader support for canvas, even though I am sure that this would be highly appreciated.

At the time of writing this (02/2014) the Canvas does not yet include any support for applying custom effects or [[Shaders]] to canvas elements or the whole canvas itself - however, supporting this is something that's been repeatedly discussed over time, so we're probably going to look into supporting this eventually[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37210.html].

If the canvas can internally be referenced by a texture2D() call, then it should be easy - the fragment shader knows screen resolution pixel coordinates, so it's straightforward to look up the local pixel from the texture and then blur or recolor it, distort it or whatever you have in mind.

Menu lighting based on light in the scene might be cool

These shouldn't even be very complicated to do

Assuming the canvas is internally a quad with a properly uv-mapped texture, then:

* making the vertex shader just pass everything through and
* uniform sampler2D myTexture; should make that texture available to the fragment shader
* vec2 coords = gl_TexCoord[0].xy; should get the coordinates of the local pixel inside the texture

<syntaxhighlight lang="glsl">
#version 120
uniform sampler2D input_tex;

void main() {

// get the texture coords of the pixel
vec2 coords = gl_TexCoord[0].xy;

//look up the pixel color from the input texture
vec4 color = texture2D( input_tex, coords) ;

// and pass the pixel color through
gl_FragColor = color;
}

</syntaxhighlight>

There are at least 2-3 people who can help with pointers, but we don't have time to implement this ourselves - so if anybody is interested, please get in touch via the canvas subforum.

The Effects framework is implemented in SimGear: http://gitorious.org/fg/simgear/trees/next/simgear/scene/material

[[File:Canvas-glsl-support.png|thumb|airport selection dialog with a greyscale fragment shader applied to the canvas]]

[[File:Canvas-Fragment-Shader-red.png|thumb|a trivial fragment shader applied to a canvas (the original colors used in the Nasal code were not changed!)]]

<syntaxhighlight lang="glsl">
void main(void) {
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}
</syntaxhighlight>

[[File:Canvas-Fragment-Shader-circles.png|thumb|unmodified airport selection canvas with fragment shader applied]]

<syntaxhighlight lang="glsl">

// http://people.freedesktop.org/~idr/OpenGL_tutorials/03-fragment-intro.html
void main(void)
{
vec2 pos = mod(gl_FragCoord.xy, vec2(50.0)) - vec2(25.0);
float dist_squared = dot(pos, pos);

if (dist_squared < 400.0)
gl_FragColor = vec4(.90, .90, .90, 0.0);
else gl_FragColor = vec4(.20, .20, .40, 0.8);
}
</syntaxhighlight>

[[File:Canvas-Fragment-Shader-experiments.png|thumb|more canvas fragment shading experiments]]

Implementation-wise, supporting shaders per canvas seems straightforward to support - but it would probably be better to support shaders per element, where each element would render its own sub-texture if shaders/effects are specified, and apply the canvas' osg::StateSet otherwise. We could add an Interface on top of SimGear's "Effects" framework which would be implemented by the Canvas itself, but also by Canvas::Element

* Probably need to extend the Effects framework to support reloading effects/shaders from disk for testing purposes

<syntaxhighlight lang="diff">
</syntaxhighlight>

Also see:
* http://trac.openscenegraph.org/projects/osg/wiki/Support/Tutorials/ShadersIntroduction
* http://trac.openscenegraph.org/projects/osg/wiki/Support/Tutorials/ShadersUpdating
* http://en.wikipedia.org/wiki/OpenGL_Shading_Language
* http://www.cuboslocos.com/tutorials/OSG-Shader
* http://forum.flightgear.org/viewtopic.php?f=71&t=22166
* http://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+shader
* http://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+shaders
* http://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+effects

{{Appendix}}

[[Category:Nasal]]
[[Category:Property Tree]]
[[Category:Core development projects]]

=== Discussed new Elements ===

The previously mentioned primitives alone can already be used to create very sophisticated avionics and dialogs - however, depending on your needs, you may want to extend the canvas system to support additional primitives. Typically, you'll want to add new primitives in order to optimize performance or simplify the creation of more sophisticated avionics and/or dialogs (e.g. for mapping/charting purposes).
If you are interested in adding new primitives, please take a look at the sources in [[$SG_SRC]]/canvas/elements.

For example, there's been talk about possibly adding the following additional primitives at some point. However, none of these are currently a priority or being worked on by anybody:
* support for a vertical mapping mode (e.g. to create Vertical Situation Displays or flight path evaluation dialogs), would probably make sense to use [http://trac.osgeo.org/proj/ PROJ4] for additional projcetion support?
* support for [[Howto:Use a Camera View in an Instrument|rendering scenery views]] (e.g. for tail cameras or mirrors etc) [http://forum.flightgear.org/viewtopic.php?f=4&t=15722&p=192595#p158690] [http://forum.flightgear.org/viewtopic.php?f=37&t=21192] {{Issue|1250}}
* support for ESRI shapefiles (instead of using shapelib, it would make sense to use GDAL/OGR here, or directly the {{abbr|OSG|OpenSceneGraph}}/ReaderWriterOGR plugin) [http://trac.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/ogr] (FlightGear/osgEarth now depends on GDAL, so should be straightforward dependency-wise).
* support for GeoTIFF files or terrain height profiles using the tile cache
* rendering 3D objects
* support for ortographic moving map displays, e.g. using atlas [http://forum.flightgear.org/viewtopic.php?p=201955#p201955] (ideally using[[CompositeViewer Support]])

If you are interested in working on any of these, please get in touch via the canvas sub forum first.

There is already support for creating multiple osgviewer windows in FlightGear, this is commonly used in multiscreen setups - to support the creation and usage of [[Howto:Configure camera view windows|osgviewer windows]] in Canvas, we would need to look into adding a new placement type to the canvas system, so that osgviewer/OS windows can be created and controlled via the canvas system and a handful of placement-specific properties [http://forum.flightgear.org/viewtopic.php?f=37&t=2985].

== Placements ==

Obviously, users can use the canvas system for developing all sorts of features that may need to be accessible using different interfaces - for these reasons, the canvas uses the concept of so called '''placements''', so that a canvas-texture can be shown inside GUI windows, GUI dialogs, cockpits, aircraft textures (liveries) - and also as part of the scenery (e.g. for a VGDS).



[[File:Canvas-Placements.png|650px|supported canvas placements as of 03/2014]]

{{Note|The features described in the following section aren't currently supported or being worked on, but they've seen lots of community discussion over the years, so that this serves as a rough overview.}}

=== Scenery Overlays ===

Also see [http://forum.flightgear.org/viewtopic.php?f=5&t=21882&p=201862#p201862 Photoscenery via Canvas?] and [http://forum.flightgear.org/viewtopic.php?f=3&t=22784&p=206581#p206581 A project to create a source of free geo-referenced instrument charts]

{{cquote|Texture overlays - FG scenery engine does the chopping and texture co-ord generation. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg18530.html|title=Scenery engine features.|author=Paul Surgeon|Thu, 13 Nov 2003 15:37:22 -0800}}</ref>|Paul Surgeon}}

{{cquote|I am looking for a method for adding a graphical overlay channel to Flightgear. This overlay would consist of a dynamic texture that can be
modified in real time. I've used other OpenGL based systems with this feature but don't know where to start with implementing it in Flightgear.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg11324.html|title=Overlay Plane|author=Noah Brickman|Fri, 29 Jun 2007 13:27:15 -0700}}</ref>|Noah Brickman}}

{{cquote|Once the frame is converted to an opengl texture, then it would be a very simple matter of displaying it on the screen with a textured rectangle drawn in immediate mode ... possibly with some level of transparancy, or not ...

I'm involved in some UAV research where we are using FlightGear to render a synthetic view from the perspective of a live flying uav. Would be really cool to super impose the live video over the top of the FlightGear synthetic view. Or super impose an F-16 style HUD on top of the live video ... I have lots of fun ideas for someone with a fast frame grabber and a bit of time [...]

Then do whatever bit fiddling is needed to scale/convert the raster image to an opengl texture. Then draw this texture on a quad that is aligned correctly relative to the camera. It might be possible to get fancy and alpha blend the edges a bit.

Given an image and the location and orientation of the camera, it would be possible to locate world coordinates across a grid on that image. That would allow a quick/crude orthorectification where the image could be rubber sheeted onto the terrain. This would take some offline processing, but you could end up building up a near real time 3d view of the world than could then be viewed from a variety of perspectives. The offline tools could update the master images based on resolution or currency ... that's probably a phd project for someone, but many of the pieces are already in place and the results could be extremely nice and extremely useful (think managing the effort to fight a dynamic forest fire, or other emergency/disaster management, traffic monitoring, construction sites, city/county management & planning, etc.) I could even imagine some distrubuted use of this so that if you have several uav's out flying over an area, they could send their imagery back to a central location to update a master database ... then the individual operators could see near real time 3d views of places that another uav has already overflown.

If we started building up more functionality in this area, there are a lot of different directions we could take it, all of which could be extremely cool.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15459.html|title=Replace fg visualization with streaming video
Curtis Olson Fri, 25 Jan 2008 07:51:41 -0800|author=Curtis Olson |Tue, 29 Jul 2008 13:11:15 -0700}}</ref>|Curtis Olson}}

{{cquote|Could we generate the texture on the fly? Based on landclass and road data? I could see a number of advantages/disadvantages here as compared to our current, generic textures:
* much better autogen scenery possible: many textured streets/railroads without additional scenery vertices
* shared models with an individual piece of ground texture
* get rid of sharp landclass borders
* possibly improved resolution<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg39692.html|title=Generating ground textures on the fly?|author=Thomas Albrecht|Mon, 11 Mar 2013 13:37:47 -0700}}</ref>|Thomas Albrecht}}

{{cquote|A very interesting idea - so interesting I thought of it and discussed it with some people last year :) The summary answer is, it should be possible, it would
have pretty much the benefits and drawbacks you mention (especially the VRAM consumption), and it would allow nice LoD and solve some other issues.
Especially it avoid the nasty clipping issues we have with surface data in TerraGear, since you just paint into the texture, no need to clip all the
linear data.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg39692.html|title=Generating ground textures on the fly?|author=James Turner|Mon, 11 Mar 2013 13:37:47 -0700}}</ref>|James Turner}}

What we could do is identify which hooks are needed to make this work and provide those via the Canvas system: Canvas textures can already be placed in the scenery, so there should be very little needed in terms of placement-specific attributes, and the corresponding code should be available in SimGear/FlightGear already.

[http://fgphotoscenery.square7.ch/flightgear_photo_combined_2.8.patch The patch] required to modify FlightGear obviously already uses shaders and effects, and it's mostly about exposing additional parameters to the shaders.

<references/>

=== Native Windows ===
{{Note|People interested in working on this may want to check out the following files:
* {{Git link|gitorious|fg/simgear|next|src/canvas/CanvasPlacement.hxx|text=CanvasPlacement Interface in SimGear}}
* {{Git link|gitorious|fg/flightgear|next|src/Main/Viewer/WindowBuilder.cxx|text=$FG_SRC/Viewer/WindowBuilder.?xx}}
* {{Git link|gitorious|fg/flightgear|next|src/Main/Viewer/WindowSystemAdapter.cxx|text=$FG_SRC/Viewer/WindowSystemAdapter.?xx}}
* {{Git link|gitorious|fg/flightgear|next|src/Main/Canvas/window.cxx|text=Canvas Windows Implementation}}
}}
Currently, all placements are within the main FlightGear window, however there's been talk about providing support for additional Canvas placements, such as e.g. osgviewer placements to help generalize our [[Howto:Configure camera view windows|Window Management]] routines, so that a canvas can be rendered inside a dedicated OS window:

{{cquote|<nowiki>Support multiple views/windows: Currently the GUI can only be placed inside one view/window (see Docs/README.multiscreen) but it would be nice to be able to move windows between views.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37907.html|title=<nowiki>Switching from PUI to osgWidget</nowiki>|author=<nowiki>Thomas Geymayer</nowiki>|date=<nowiki>07-30-2012</nowiki>}}</ref>|<nowiki>Thomas Geymayer</nowiki>}}

{{cquote|I have just been trying out the multiple screen feature in FG. I found that the GUI camera (including the menu bar, hud and 2D panel) appears in only one of the windows. Is there any way I can make the GUI to appear in all the windows? Actually I want to be able to view the hud and 2D panel in all the windows.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27112.html|title=<nowiki>[Flightgear-devel] Help needed with multi-screen</nowiki>|author=Kavya Meyyappan|date=Fri, 19 Mar 2010 03:31:50 -0700}}</ref>|Kavya Meyyappan}}

{{cquote|there's a limitation in Plib that forces the GUI to be drawn on one window.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html|title=<nowiki>Re: [Flightgear-devel] Help needed with multi-screen</nowiki>|author=Tim Moore|date=Sat, 20 Mar 2010 01:42:31 -0700}}</ref>|Tim Moore}}

{{cquote|I think you have just summarized all the limitations of the FlightGear multi-camera/view/display system. I know that in the case of menus, hud, 2d instrument panels, there would need to be some significant code restructuring to allow these to be displayed on other windows.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27114.html|title=<nowiki>Re: [Flightgear-devel] Help needed with multi-screen</nowiki>|author=Curtis Olson|date=Fri, 19 Mar 2010 08:36:22 -0700}}</ref>|Curtis Olson}}

{{cquote|Good thing to have!!! Just still support graphics context on different screens/displays too ...<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17016.html|title=<nowiki>Re: [Flightgear-devel] RFC: changes to views and cameras</nowiki>|author=Mathias Fröhlich|date=Sat, 28 Jun 2008 00:05:19 -0700}}</ref>|Mathias Fröhlich}}

{{cquote|it can be solved by using multiple osg windows to contain whatever GUI solution we go with - canvas, osgWidget or PUI-port.

Or to put it another way - the actual hard part is running the widgets in the main OpenGL window - which *is* a requirement for full-screen apps and
multi-monitor setups. (Some people have claimed otherwise, but I believe we need the option of 'in-window' UI for many cases).

So, this is a desirable feature, but doesn't dictate the choice of GUI technology. And can be done as a separate step from replacing PLIB.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37875.html|title=<nowiki>Switching from PUI to osgWidget</nowiki>|author=James Turner|date= Wed, 25 Jul 2012 02:28:42 -0700}}</ref>|James Turner}}

<references/>

=== Placement/Element for Streaming: Computer Vision ===

{{Note|There seem to be two main use-cases discussed by contributors: 1) The UAV guys want to view/use external live video inside FlightGear as an instrument/texture (which would require a new Canvas::Element to render an external video stream to a canvas) and 2) the computer vision (OpenCV) guys want to stream FlightGear live video itself to another application for image processing purposes - the latter would require streaming FlightGear's main window view to an external program (i.e. by using FlightGear's CameraGroup code), possibly by using a corresponding "virtual Placement" that opens a socket to provide a live stream of the FlightGear main window via background thread.}}

People interested in doing UAV work that involves computer vision (e.g. using OpenCV, see {{Issue|924}}, [http://forum.flightgear.org/viewtopic.php?f=36&t=16015&hilit=opencv], [http://forum.flightgear.org/viewtopic.php?f=37&t=21192&p=192915&hilit=#p192817]) will probably also want to look into using a dedicated Canvas placement for this, in combination with adding a dedicated Canvas::Element to render scenery views to a texture using [[CompositeViewer Support]] - these two features would provide a straightforward mechanism to export a live video stream of FlightGear via a dedicated port.

{{Note|There were several early attempts at bringing streaming capabilities to FlightGear in the pre-{{abbr|OSG|OpenSceneGraph}} days that are meanwhile unmaintained, e.g.:
* [http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg11213.html Experimental screen streamer patch]
* [http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg12262.html New screen streamer and mpcam]
}}

{{cquote|I'm new to FlightGear, and am trying to use it as an image generator for a simulator I'm developing...I've got it configured to take inputs
from a UDP port to fly, but I want to disable a lot of features so that all FlightGear does is draw scenery. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg30338.html|title=Disabling functionality|author=Drew |date=Tue, 25 Jan 2005 09:24:30 -0800}}</ref>|Drew}}

{{cquote|I would like to use FlightGear to generate the scene observed by a UAV's onboard camera.

Basically, this would translate to feeding FlightGear the FDM data and visualizing the image generated by FlightGear in another computer, across a network, using for example streaming video.

I suppose this is a bit of a far-fetched idea, but is there any sort of support for this (or something similar) already implemented? <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg10528.html|title=Flightgear visualization as streaming video|author=Antonio Almeida |date=Tue, 22 May 2007 10:14:46 -0700}}</ref>|Antonio Almeida}}

{{cquote|I am interested in using it as a visualization tool for UAV's. I would like to replace the fg scenery with images captured from a camera onboard an aircraft. I was wondering if there is any way to import images into flightgear on the fly. The basic goal would be to show live video where available and fall over to flight gear visuals when the feed is lost(using a custom view from the camera perspective) .<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15463.html|title=Replace fg visualization with streaming video|author=STEPHEN THISTLE |date=Fri, 25 Jan 2008 06:32:03 -0800}}</ref>|STEPHEN THISTLE}}

{{cquote|I'm hooking up a lumenera Camera for a live video feed from a UAV, so that the video gets handed to Flightgear, which then draws its HUD over the video stream. In order to do this, I need to be able to communicate with the window controls. My camera can display the video in a new window, but I want it to draw to the video screen that Flightgear is already using.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17203.html|title=Window controls|author=cullam Bruce-Lockhart |date=Tue,29 Jul 2008 09:23:54 -0700}}</ref>|Bruce-Lockhart }}

{{cquote|I don't think there's any current way to do this. However, I think what is needed is to link in some video capture library to do frame grabs from your video camera as quickly as possible. Then do whatever bit fiddling is needed to scale/convert the raster image to an opengl texture. Then draw this texture on a quad that is aligned correctly relative to the camera. It might be possible to get fancy and alpha blend the edges a bit.

Given an image and the location and orientation of the camera, it would be possible to locate world coordinates across a grid on that image. That would allow a quick/crude orthorectification where the image could be rubber sheeted onto the terrain. This would take some offline processing, but you could end up building up a near real time 3d view of the world than could then be viewed from a variety of perspectives. The offline tools could update the master images based on resolution or currency ... that's probably a phd project for someone, but many of the pieces are already in place and the results could be extremely nice and extremely useful (think managing the effort to fight a dynamic forest fire, or other emergency/disaster management, traffic monitoring, construction sites, city/county management & planning, etc.) I could even imagine some distrubuted use of this so that if you have several uav's out flying over an area, they could send their imagery back to a central location to update a master database ... then the individual operators could see near real time 3d views of places that another uav has already overflown.

If we started building up more functionality in this area, there are a lot of different directions we could take it, all of which could be extremely cool.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15459.html|title=Replace fg visualization with streaming video
Curtis Olson Fri, 25 Jan 2008 07:51:41 -0800|author=Curtis Olson |Tue, 29 Jul 2008 13:11:15 -0700}}</ref>|Curtis Olson}}

{{cquote|Getting live video onto a texture is pretty standard stuff in the OpenSceneGraph community<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15464.html|title=<nowiki>Replace fg visualization with streaming video</nowiki>|author=Tim Moore|date=Fri, 25 Jan 2008 08:31:40 -0800}}</ref>|Tim Moore}}

{{cquote|I imagined embedding some minimal routine that talks to the camera and grabs an image frame. Then usually you can directly map this into an opengl texture if you figure out the pixel format of your frame grab and pass the right flags to the opengl texture create call. Then you should be able to draw this texture on top of any surface just like any other texture ... you could map it to a rectangular area of the screen, you could map it to a rotating cube, map it to the earth surface, etc. That's about as far as far as I've gone with thinking through the problem.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17206.html|title=Window controls|author=Curtis Olson |Tue, 29 Jul 2008 13:11:15 -0700}}</ref>|Curtis Olson}}

{{cquote|I want draw something in the front face of the FlightGear view, but I don't wan to recompile / modify any codes, so, if the FlightGear could give me a interface to draw something myself through DLL, that's perfect.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=6&t=22995|title=<nowiki>One suggestion: FlightGear wolud support plugins like this!</nowiki>|author=CHIV|date=Thu May 08, 2014 3:03 am}}</ref>|CHIV}}

<references/>

=== Adding new Placements ===

== Projections ==
Also see {{Issue|550}} and http://docs.freeflightsim.org/simgear/classsimgear_1_1canvas_1_1Projection.html

=== Adding new Projections ===
{{Note|Discuss base class that needs to be implemented}}

== Event Handling ==
{{Note|Discuss CanvasEventManager, CanvasEvent, CanvasEventVisitor}}

== Canvas Integration ==
{{Note|Discuss FGCanvasSystemAdapter}}

==Suggested reading ==
* [[Howto:Create_new_subsystems|Using Property Listeners]]
* [http://docs.freeflightsim.org/simgear/classSGPropertyChangeListener.html SGPropertyChangeListener]
* [[PropertyBasedElement]]
* [[Howto:Use Property Tree Objects]]
* [[Programming_resources#OSG.2FOpenSceneGraph_related|OSG Programming]]

New to FlightGear

2014-05-27T20:13:03Z

Philosopher: /* Getting FlightGear */ Mac too! plus a few typos

== Getting started ==
=== Hardware requirements ===
For FlightGear to run smoothly, it requires a video card with OpenGL drivers. OpenGL 2.0 or higher is required for FlightGear 2.0 and later. Most modern PCs support OpenGL, but if you are having trouble with slow frame-rates, see [[Fr/Hardware Recommendations|Hardware Recommendations]] for more information.

Many laptops with insufficient 3D hardware acceleration capabilities are known to have issues with running FlightGear. Since laptops are smaller, the graphics card(s) on them are usually lower-end. See [[notebooks known to run FlightGear]] for reviews of several laptop systems.

=== Getting FlightGear ===
You may download the latest files from [http://www.flightgear.org/download/ FlightGear Downloads] page. Choose the source or binary files appropriate for your particular system. Most Linux users will find that most distributions have a packaged version of FlightGear (the package name could be fgfs or flightgear.)

Depending on your technical expertise you may choose the [[Git]] development version of FlightGear, which typically has more features and can be required by some of the latest developmental aircraft, but can be unstable and is more complicated to acquire and install. In general, the development version is not advised to the average user, but if you're willing to do some testing there's a nightly build for Windows or Mac available for download at the [[FlightGear Build Server]].

You may also order FlightGear on a set of DVDs, available at [http://www.flightgear.org/dvd/].

=== Installing on Windows ===
After installing FlightGear on Windows a dialog box appears to define file locations. This is [[FlightGear Launch Control]], also known as FGRun.

Apply the following settings:
* '''Executable''': the full path to the FlightGear program (<tt>fgfs.exe</tt>, usually <tt>C:/Program Files/FlightGear/bin/win32/fgfs.exe</tt> ). One can choose it directly using the file selection dialog that pops up when the folder button is hit.
* '''[[$FG ROOT|FG_ROOT]]''': the full path to the FlightGear base package (<tt>data/</tt> directory, usually <tt>C:/Program Files/FlightGear/data</tt>). If this path is wrong, no [[aircraft]] would be displayed and FlightGear won't run.

Once you have defined these default settings, you can press <tt>Next</tt> to select an airport, aircraft and edit additional settings.

=== Installing on Mac OS X ===
Installing [[FlightGear Mac OS X|FlightGear on Mac OS X]] is very simple. Just drag and drop the FlightGear icon to the <tt>/Applications</tt> folder. That's it.

The first time you launch FlightGear, its icon on the Dock bounces for several seconds while loading aircraft and airport info. When the GUI launcher appears, select an aircraft and and airport by clicking the "Gear" buttons at the right of the names. Pressing "Start flight" will launch the simulator. You can configure more options using the GUI launcher. see the [http://macflightgear.sourceforge.net/home/documents/users-guide/ Users Guide] for more details.

If you'd like to launch FlightGear using command-line, launch <tt>/Applications/Utilities/Terminal.app</tt> and type the following.

cd /Applications/FlightGear.app/Contents/Resources
./fgfs --options.....

The [[$FG ROOT]] and [[$FG SCENERY]] are not set on Mac OS X. If you want to specify these variables yourself for command-line use, run the followings on Terminal.app:

FG_ROOT=/Applications/FlightGear.app/Contents/Resources/data
FG_SCENERY=[[$FG_ROOT]]/Scenery

After launching the GUI launcher, you will have the alias to [[$FG ROOT]] at <tt>$HOME/Documents/Flightgear/<version></tt> so you can browse the data folder using Finder.

Note: Once you have installed FlightGear, mac users can locate their [[$FG_ROOT]] folder by opening their applications folder in Finder, right clicking on FlightGear, and clicking "Show Package Contents". This will take you inside the FlightGear folder. You are now able to access all files including Data/Aircraft for [[Howto: Install aircraft#Macintosh OS X|installing new aircraft]].

=== Configuring OpenGL ===
FlightGear runs best with current [[OpenGL]] video drivers. If you are having trouble running FlightGear smoothly, see [[Graphics drivers configuration]] for more information.

=== Getting scenery ===
A limited set of [[scenery]] comes installed with FlightGear, which consists of the area surrounding [[San Francisco International Airport]] (KSFO).

In FlightGear, scenery is generally stored in you [[$FG_ROOT]] directory, and is divided into three kinds of data:
* '''Airports''' holds airport data, like runway usage and parking spots.
* '''Objects''' are the buildings, bridges and radio towers, etc. that represent three-dimensional structures.
* '''Terrain''' represents the contours, elevations and type of ground you fly/taxi over.

The current way of "installing" new scenery is using [[TerraSync]], which will automatically download and update any place you visit - even on the fly! However, some might have problems with that, so you can also manually download and install new scenery parts, either official, the [[World Scenery]], or custom.

The official scenery is available at [http://www.flightgear.org/download/scenery/ the scenery download section] of the FlightGear website, and can be installed following [[Howto: Install scenery]]. You may obtain additional and more up to date scenery objects as they become available through the [http://scenemodels.flightgear.org/ FlightGear Scenery Database].

=== Getting aircraft ===
{{Main article|Howto: Install aircraft}}
To download additional [[aircraft]] for FlightGear individually, go to the FlightGear website and navigate to the [http://www.flightgear.org/download/ download page], then choose the aircraft download link that fits your FlightGear version.

Once the aircraft package has downloaded, decompress and extract the archived files onto your computer. You may extract to a temporary directory and move them, or extract directly into the Aircraft/ directory in FlightGear. This is typically <tt>[[$FG ROOT]]/Aircraft</tt>.

=== Starting FlightGear ===
Many users choose to start FlightGear from the command line ("console" or "shell" as it is known to Unix users). Alternatively some use graphical interfaces such as [[FlightGear Launch Control|Fgrun]] (FlightGear Launch Control).

To start FlightGear type on the command line:

fgfs

and hit enter. This will start FlightGear.

If FlightGear fails to start, it is likely the compiled FlightGear binary software is not in your path. If you know Unix, you may add the location of the binary to your path and try starting again. Otherwise, you may find the location of the 'fgfs' binary and enter an absolute path to it like

/usr/games/fgfs

The location depends on your particular system and choices you made during compile and installation.

It is important to understand when not using a graphical interface to start FlightGear, your interaction will be entirely from the command line. To see available aircraft, you specify an option on the command line. To specify an aircraft, an airport, multiplayer server, etc. you add an option to the command line when starting FlightGear. Please consult the list of [[Command Line Parameters]]. The parameters are also useful to those starting FlightGear from [[FlightGear Launch Control]] graphical interface, as it allows you to specify parameters.

=== Displaying available aircraft ===
From the command line:

fgfs --show-aircraft

displays a list of available (installed) aircraft.

=== Choosing an aircraft ===
From the command line:

fgfs --aircraft=foo

where foo is the name of the aircraft's <tt>*-set.xml</tt> file (eg. for the c172p this is <tt>c172p-set.xml</tt>, so the command is <tt>--aircraft=c172p</tt>). See also [[Command Line Parameters]]. The following commands gives a list of available aircraft:

fgfs --show-aircraft

=== Online multiplayer flying ===
{{Main article|Howto: Multiplayer}}

=== Using the keyboard and/or mouse ===
Users with limited access to a [[joystick]] or other controllers sometimes use the keyboard or mouse to control their aircraft. Using the keyboard to fly can be difficult and the mouse is recommended over the keyboard for flying. Adjustments (like throttle, instruments etc.) may be made with the keyboard.

To get help with keyboard commands, with FlightGear running, go to the Help [[menu]], look under Basic Keys (for simulator related commands) and Common Aircraft Keys (for commands universal to all aircraft) and Aircraft Help for key commands specific to your aircraft. A list displaying what each key does will display.

Coming from an other simulator? Check [[key commands compared to other simulators]] for an overview of the difference between the key commands of that sim and FlightGear.

To use the mouse to fly the aircraft, right click (the cursor should change to a cross) and move the mouse to direct the aircraft. Right click again to look around (cursor should show a two sided arrow), click again to return to normal mode.

=== First time in the cockpit ===
Finding your way around the cockpit can be daunting the first time.

Where is the 'virtual cockpit?' Not all FlightGear aircraft come with an interior, including a virtual cockpit. (Due to FlightGear being used by various research projects, some aircraft may not even come with an exterior model. Remember, FlightGear is very flexible.) A 2D panel may display over the 3d cockpit if one exists. You may turn this off using the View menu. Otherwise, you should be sitting in the virtual cockpit when FlightGear starts, as long as the Cockpit View is selected.

You may find it difficult to read some of the displays, dials and gauges on the instrument panel. Use the Zoom keys to zoom in on an instrument. The 'x' and Shift-X keys control eyepoint zoom in the Cockpit View. Use the joystick hat (or other controller assigned to this function) to pan the eyepoint to the instrument you wish to read. Then zoom in.

Alternate Method: Click the right mouse button until you get a cursor with two arrows (like this <=>). You can now move your view around the cockpit. Press 'x' and Shift-X to zoom in and out.

'''Note:''' Some functions, such as starter or magneto, may be difficult to use or lack "hotspots" to control with your mouse. Especially when flying an aircraft model that is still undergoing development. In this case, look for equivalent controls on a 2D panel or resort to the keyboard. The keyboard controls always work according to the assignments listed on the Help Menu (unless reassigned by an aircraft or configuration). Go to the main window menu, click Help, then click Basic Keys or Common Aircraft Keys.

One of the first steps I take on entering an unfamiliar cockpit is to press Ctrl-C to highlight all the "hotspots" on the 3d cockpit instrument panel. This enables you to easily see where to place the mouse to operate an instrument's controls, buttons, knobs, etc.

Many aircraft offer a help menu specific to that aircraft on the Aircraft Help menu (go to Help, then Aircraft Help.

== Making your first flight ==
One of the most frequent questions novice pilots ask about any flight sim, but more so to FlightGear, is "why is my aircraft turning left all the time?" Although it could be due to wind gusts crossing the runway, it is more likely due to the increased realism FlightGear provides. In a certain other flight simulator, some settings are turned down to make the aircraft easier to fly. This reduces effects such as propeller torque and p-factor, which may be the cause of the tendency to turn to the left (to figure out which effect, you may read more in [[Understanding Propeller Torque and P-Factor]]).

Despite marketing slogans to the contrary, some flight simulators are aimed at a casual game player market, and ship with their "realism" turned down. The realism is always turned up in FlightGear.

FlightGear offers a great deal of realism, which may be confusing to first time pilots.

* "Left Turning Syndrome" for the previously mentioned reasons.
* Compass Turning Error: A compass, when subjected to the forces of flight, tends to turn in the opposite direction for a brief period before settling on the correct heading. This is not a malfunction.
* The Vertical Speed Indicator is also subject to error.
* The Horizontal Situation Indicator is driven by a gyroscope (that is why it's sometimes called a Directional Gyroscope), which is subject to a phenomenon called gyro drift. For a number of reasons, the gyro will drift from its current heading and must be periodically (about every 15 minutes) calibrated to agree with the magnetic compass heading.

Many forces act on an aircraft in flight as well as on the instruments and systems used for control and navigation, and may be counter-intuitive. Pilots must learn to recognize these phenomena and compensate for their effects. FlightGear models instrument errors that exist in the real world.

=== Flying using navigational aids and the autopilot ===
To make this very clear for new users: Some aircraft require you to use the [[autopilot]] available from the Autopilot menu, which is the original FlightGear autopilot. This is a '''generic''' autopilot and as such, many aircraft come with their own '''specific''' autopilot, frequently a model of the real life one. '''For aircraft that provide their own autopilot in the cockpit, you must use the autopilot controls available in the virtual cockpit'''. This means clicking on the instrument panel in the virtual cockpit. The Autopilot menu will be grayed out and unavailable when the aircraft supplies its own autopilot (generally).

FlightGear, as of version 0.9.9, comes with a "built-in" autopilot. The Autopilot dialog accessible from the FlightGear toolbar in the main FlightGear window does not work with all aircraft. It only works with aircraft that either
* do not specify an autopilot
* use the default autopilot. When an aircraft does not specify an autopilot, the default is used.

For aircraft that supply their own autopilot, you must use the autopilot controls in the 2D or virtual cockpit. The Cessna comes with a KAP140 autopilot in its virtual cockpit. You cannot use the Autopilot dialog with this aircraft. It has no effect. You must use the autopilot device in the panel.

For help with navigation see [[Understanding Navigation]].

=== Airports and navigation aids ===
When you first start FlightGear, whether from the command line or the graphical interface, you may wonder how to determine what airports are available. FGRun displays a list of airports, but you will not see details such as tower or [[ILS]] frequencies. You will not find a map showing [[VOR]]s and their frequencies. Short of finding an actual sectional map for the area you wish to fly, what can you do?

[http://maps.google.com Google Maps] and the [[MPMap|FlightGear Online Map for multiplayers]] are both good resources as well as the FlightGear [http://fgfs.i-net.hu/modules/fgplanner/ Community Flight Planner].

== Getting help ==
Besides this wiki, there are more places that can be visited to obtain information or request help:
* Documents bundled with the release package.
* [http://forum.flightgear.org FlightGear Forum]
* [[FlightGear IRC channel]], the quickest way to get help.
* [[Malinglists|FlightGear users mailing list]], biggest chance to get in contact with developers.

== Getting more detailed information ==
This page is designed to give the user the essential things they need to know about using FG for the first time.

You now know enough to get started with FlightGear. To learn more, you may wish to start at the main page of this wiki and read the more detailed Getting Started section, or Using FlightGear section or study the Flying Resources to learn more about flight instruments and how to navigate and fly your aircraft.

Also, note that those using the Git version of FlightGear may choose to update their aircraft files through the Git system.

The following are some issues raised by new users of FlightGear. More detailed troubleshooting and answers can be found in [[Troubleshooting Problems]] and the [[FAQ]].

=== I do not want to compile FlightGear, what can I do? ===
[http://www.flightgear.org/Downloads/ Our website] offers precompiled binaries for download and install on a variety of systems. Current platforms are Windows, Linux, Solaris, SGI, Mac OSX and FreeBSD. These are offered as a convienence and availablility may vary at times.

Note: FlightGear is highly configurable through editable [[XML]] files. You are free, and encouraged to, make changes to aircraft flight models and any other feature you wish to change for your personal satisfaction or to share with other FlightGear users. The flight model is not defined in a binary file. It is easy to modify (given enough knowledge). Although the install is binary, most of FlightGear's system is open to configuration through XML files and [[NASAL scripting]].

=== Does FlightGear come with a printed manual? ===
You are invited to read the [[FlightGear Manual]] online as HTML or download it as PDF for viewing with Acrobar Reader or printing. It's not always up to date with bleeding-edge developments but provides a good start for beginners and it's a ''must read'' if you have no or little idea of how to fly.

== How you can help ==
{{Main article|Volunteer}}

=== Testing ===
* [[Building Flightgear|Build]] the latest Git code or download snapshots (link)
* [http://flightgear-bugs.googlecode.com File bug reports]

=== Debugging & Profiling ===
* Running FlightGear via valgrind to track down memory leaks

=== Support ===
* Help new users with downloading, compiling, installing and running FlightGear (http://forum.flightgear.org or on IRC)
* Provide Ideas & Suggestions, see: [[Feature Requests / Proposals / Ideas]]
* Help clean up this wiki
* Help provide new contents for missing wiki pages

=== Development ===
* Writing documentation! Everyone is welcome to contribute to "The Manual"; having at least a little experience with LaTeX makes the task easier. Please contact the authors of The Manual if you would like to add corrections or whole chapters, you may also simply use this wiki to contribute fixes, modifications and new contents.
* C/C++ Coding:
** provide source code cleanups (i.e. help in the process of migrating over to a primarily smart pointer-based memory management approach using SGSharedPtr)
** provide bug fixes [[Bugs]]
** provide enhanced features [[Feature Requests / Proposals / Ideas]]
** provide new features
** get involved in any of the other FlightGear-affiliated projects
* Aircraft development (3D modelling, textures, FDMs, scripting)
* Scenery development

[[Category:FlightGear]]

[[de:Neu bei FlightGear]]
[[Nl:Nieuw bij FlightGear]]
[[es:Nuevo para FlightGear]]
[[fr:Nouveau sur flightgear]]
[[Pt:Novo no FlightGear]]
[[zh:FlightGear新手]]
[[ja:FlightGear入門]]

Nasal Operators

2014-05-27T20:09:55Z

Philosopher: mm.. have to escape everything

{{Nasal Navigation}}

Nasal has support for various operators, both mathematical (add, subtract, multiply, and divide) and programming-specific (assignment, concatenation, control-flow, etc.). Most operators are in [http://en.wikipedia.org/wiki/Infix_notation infix notation] – that is, the operator is in the middle of its operands as in "{{code|3 + 5}}". As mentioned, Nasal supports the four basic math operators as {{code|+}}, {{code|-}}, {{code|*}}, and {{code|/}} (power is ''not'' available as {{code|**}} (Python) or {{code|^}} (Visual basic), but rather is done in the '''math''' namespace as: {{code|math.pow(}}''base'', ''exponent''{{code|)}}). For other math ones, assignment is just a single equals sign ({{code|{{=}}}}, as in {{code|var pi {{=}} 3.14}}) and equality comparison is double-equals ({{code|{{=}}{{=}}}}, as in {{code|3 {{=}}{{=}} 3}}). Relative comparisons such as less-than ({{code|<}}), greater-than ({{code|>}}), less-than-or-equal-to ({{code|<{{=}}}}), and greater-than-or-equal-to ({{code|>{{=}}}}) also can be used (see [[Howto:Add a new binary operator to Nasal]] for an example of adding another comparison operator: the Perl "spaceship" operator, {{code|<{{=}}>}}). When operating on two variables using these operators (excepting assignment), Nasal uses a notion of "scalars" if applicable. Instead of the mathematical notion of scalars as non-vectors, a scalar in programming is defined as a number ''or'' numeric string – essentially duplicity of datatypes available to represent a number. This allows a string to also represent a number, which makes, e.g., parsing a number out of a file or string very easy, since the programmer doesn't have to think about the conversion. According to Andy (the creator of Nasal):

{{cquote| Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks. <ref>{{cite web |url=http://plausible.org/nasal/doc.html |title= Nasal – Not another scripting language.|author=Andy Ross|date=2007}}</ref>|Andy Ross}}
<references/>

This presents a problem when you need to concatenate two or more numeric strings (which is often done with the same operator as addition). If the {{code|+}} operator sees two numeric strings, it will add them as numbers, thus {{code|"67" + "75" {{=}}{{=}} 142}} (resulting in a number), when one might want the string "35". Andy had to introduce a new operator to do concatenation, like the {{code|.}} operator in PHP, and that was the tilde ({{code|~}}). Here's some examples showing the difference:
<syntaxhighlight lang="nasal">
"88" + "88" == 176; # number
88 + "88" == "88" + 88; # same
"88" ~ "88" == "8888"; # string
88 ~ 88 == "8888"; # string as well
"88" ~ 88 == 88 ~ "88"; # same
</syntaxhighlight>

== Conditionals ==

Readers familiar with C/C++ will be familiar with the "ternary" operator for control-flow within an expression:
<syntaxhighlight lang="nasal">
# (condition) ? condition_true_expr1 : condition_false_expr2
x = reverse ? -x : x; # if (reverse) x = -x else x = x
</syntaxhighlight>
This is an expression that evaluates the first expression if the condition is true, or if it is false it evaluates the second expression. In most languages, this is an alternative to the if statement, which cannot be used as a value since it is a statement (in Nasal an if/else block is actually an expression, with the else value defaulting to nil if there is no else, so it is possible but rather ugly). The Python equivalent of the ternary-operator is: {{code|expr1 if (condition) else expr2}}.

Nasal also includes the boolean [http://en.wikipedia.org/wiki/Short-circuit_evaluation short-circuit operators] "{{code|or}}" and "{{code|and}}" as keywords not symbols (not {{code|{{!}}{{!}}}} and {{code|&&}}), like in Python. Unary negation is still {{code|!}} like C/C++ (Python, however, does it as "{{code|not}}"). One of the uses for these is as a reduction of if statements:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1); # if (condition) setprop("/sim/gui/loaded", 1)
condition or setprop("/sim/gui/exited", 1); # if (!condition) setprop("/sim/gui/exited", 1) -- negated case of above
</syntaxhighlight>

Beware! if{}else{} does ''not'' (quite) work in this way:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
"{{code|or}}" is of higher precedence than "{{code|and}}", so that is equivalent to:
<syntaxhighlight lang="nasal">
(condition and setprop("/sim/gui/loaded", 1)) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
Doesn't it seem silly to be including the return of {{code|setprop()}} in the value of the left expression, which then can influence the execution of the second piece of code? In particular:
<syntaxhighlight lang="nasal">
var hash = {};
!contains(hash, "loopid") and hash.loopid = 0 or hash.loopid += 1;
</syntaxhighlight>
Which evaluates like this:
# hash is empty, so contains(hash, "loopid") is false, and !contains(...) is thus true, so
# the right-hand side of {{code|and}} is tried, which is assignment to 0, and since the value of assignment is the right-hand side, it produces 0 aka false.
# since the result of false and false is false (which is the left side of the {{code|or}}), the right side of the {{code|or}} is tried (!) as per short-circuit rules.
# that means hash.loopid += 1 is evaluated – wait, didn't we want to ''not'' evaluate this?

This counter-example proves that using "{{code|... and ... or ...}}" isn't quite the same thing as using "{{code|if (...) ... else ...}}" expression (which is better done using the ternary operator, "{{code|... ? ... : ...}}), which can be a dangerous bug, so the rule is: '''don't use this'''.

== Slicing and indexing ==
{{Note|As of 27 May 2014, the syntax {{code|expr[]}} is no longer valid and considered an error. It is neither a slice nor an index expression, although it utilized postfix brackets.}}
In Nasal, vectors can be sliced (i.e. a new vector is constructed from indexes of an existing vector) and strings, hashes, and vectors can be indexed/subscripted. For an overview of slicing see [[Nasal Variables#Vector slicing|vector slicing]].

Indexing works in different ways for the different types. For strings indexing returns a value equal to the value of the character at the position. For hashes it looks up the key in the hash directly, ignoring the parents vector, and returns nil if it is not found; this treats numbers and strings as different types of keys. For vectors, the value at the index of the array is retrieved, if it is valid. Some examples:
<syntaxhighlight lang="nasal" enclose="div">
var vec = [0,1,2,3];
vec[0] == 0; vec[1] == 1;
vec[-1] == 3; # last element
vec[-2] == 2; # next-from-last element

var hash = {
-1: 0,
"-1": 1,
hello: "hi",
parents: [{ find_me_here: 42 }]
};
hash[-1] == 0; # look up the number -1 in the hash
hash["-1"] == 1; # look up the string (!) "-1" in the hash
hash[-1~""] == 1; # same thing -- makes a string
hash.hello == "hi"; # find the member hello in the hash
hash["hello"] == "hi"; # approximately the same, but using an index expression
hash.find_me_here == 42; # find the member find_me_here in the hash, or actually its parent
hash["find_me_here"] == nil; # but it cannot be found with an index expression, because its parent isn't searched
hash.parents[0]["find_me_here"] == 42; # but we can always look for the specific parent's member
</syntaxhighlight>

== Semantics ==

Some insights on the workings of various common operations.

=== Equality ===

Here are the rules for checking equality:
* If both are scalars:
** If both are numeric: check if they are numerically equal (converting to numbers first).
** Else: check if they are equal as strings.
* Else compare id's (items only equal themselves, e.g. {{code|nil {{=}}{{=}} nil}} while {{code|[] !{{=}} []}} because they are different vectors with different id's).

=== Boolean evaluation ===

Rules for checking if a value is "true" or "false":
* If nil: return false
* If numeric:
** If 0: return false
** Else: return true
* Else: error "non-scalar in boolean context" (applies to hashes, functions, vectors, and ghosts)

== Table ==
Here's a summary of operators, in no particular order:
{| class="wikitable"
|-
! Symbol !! Operates on... !! Evaluates to...
|-
| {{code|+}} and {{code|-}} and {{code|/}} and {{code|*}} || Numeric scalars || A number
|-
| {{code|~}} || Scalars || A string
|-
| {{code|?:}} || Three "simple" expressions: condition, expr1, and expr2 || expr1 if the condition is true, else expr2
|-
| {{code|or}} || Two "simple" expressions || The first expression, if it evaluates to '''true''', else the second
|-
| {{code|and}} || Two "simple" expressions || The first expression, if it evaluates to '''false''', else the second
|}

Template:Code

2014-05-27T20:03:12Z

Philosopher: example

<tt>{{{1}}}</tt><noinclude>{{Informative template|1=
__NOTOC__
== Goal ==
Provide a unified way to embed code inline into a paragraph and investigate possible styling.

== Usage ==
<nowiki>{{</nowiki>'''code'''<nowiki>|</nowiki>SHORT CODE EXPR<nowiki>}}</nowiki>

== Example ==
* <tt><nowiki>{{code|"a" + "b"}}</nowiki></tt> {{code|"a" + "b"}}



[[Category:Formatting templates]]
}}
</noinclude>

Nasal Operators

2014-05-27T20:01:33Z

Philosopher: try and use Template:code

{{Nasal Navigation}}

Nasal has support for various operators, both mathematical (add, subtract, multiply, and divide) and programming-specific (assignment, concatenation, control-flow, etc.). Most operators are in [http://en.wikipedia.org/wiki/Infix_notation infix notation] – that is, the operator is in the middle of its operands as in "{{code|3 + 5}}". As mentioned, Nasal supports the four basic math operators as {{code|+}}, {{code|-}}, {{code|*}}, and {{code|/}} (power is ''not'' available as {{code|**}} (Python) or {{code|^}} (Visual basic), but rather is done in the '''math''' namespace as: {{code|math.pow(}}''base'', ''exponent''{{code|)}}). For other math ones, assignment is just a single equals sign ({{code|=}}, as in {{code|var pi = 3.14}}) and equality comparison is double-equals ({{code|==}}, as in {{code|3 == 3}}). Relative comparisons such as less-than ({{code|<}}), greater-than ({{code|>}}), less-than-or-equal-to ({{code|<=}}), and greater-than-or-equal-to ({{code|>=}}) also can be used (see [[Howto:Add a new binary operator to Nasal]] for an example of adding another comparison operator: the Perl "spaceship" operator, {{code|<=>}}). When operating on two variables using these operators (excepting assignment), Nasal uses a notion of "scalars" if applicable. Instead of the mathematical notion of scalars as non-vectors, a scalar in programming is defined as a number ''or'' numeric string – essentially duplicity of datatypes available to represent a number. This allows a string to also represent a number, which makes, e.g., parsing a number out of a file or string very easy, since the programmer doesn't have to think about the conversion. According to Andy (the creator of Nasal):

{{cquote| Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks. <ref>{{cite web |url=http://plausible.org/nasal/doc.html |title= Nasal – Not another scripting language.|author=Andy Ross|date=2007}}</ref>|Andy Ross}}
<references/>

This presents a problem when you need to concatenate two or more numeric strings (which is often done with the same operator as addition). If the {{code|+}} operator sees two numeric strings, it will add them as numbers, thus {{code|"67" + "75" == 142}} (resulting in a number), when one might want the string "35". Andy had to introduce a new operator to do concatenation, like the {{code|.}} operator in PHP, and that was the tilde ({{code|~}}). Here's some examples showing the difference:
<syntaxhighlight lang="nasal">
"88" + "88" == 176; # number
88 + "88" == "88" + 88; # same
"88" ~ "88" == "8888"; # string
88 ~ 88 == "8888"; # string as well
"88" ~ 88 == 88 ~ "88"; # same
</syntaxhighlight>

== Conditionals ==

Readers familiar with C/C++ will be familiar with the "ternary" operator for control-flow within an expression:
<syntaxhighlight lang="nasal">
# (condition) ? condition_true_expr1 : condition_false_expr2
x = reverse ? -x : x; # if (reverse) x = -x else x = x
</syntaxhighlight>
This is an expression that evaluates the first expression if the condition is true, or if it is false it evaluates the second expression. In most languages, this is an alternative to the if statement, which cannot be used as a value since it is a statement (in Nasal an if/else block is actually an expression, with the else value defaulting to nil if there is no else, so it is possible but rather ugly). The Python equivalent of the ternary-operator is: {{code|expr1 if (condition) else expr2}}.

Nasal also includes the boolean [http://en.wikipedia.org/wiki/Short-circuit_evaluation short-circuit operators] "{{code|or}}" and "{{code|and}}" as keywords not symbols (not {{code|||}} and {{code|&&}}), like in Python. Unary negation is still {{code|!}} like C/C++ (Python, however, does it as "{{code|not}}"). One of the uses for these is as a reduction of if statements:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1); # if (condition) setprop("/sim/gui/loaded", 1)
condition or setprop("/sim/gui/exited", 1); # if (!condition) setprop("/sim/gui/exited", 1) -- negated case of above
</syntaxhighlight>

Beware! if{}else{} does ''not'' (quite) work in this way:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
"{{code|or}}" is of higher precedence than "{{code|and}}", so that is equivalent to:
<syntaxhighlight lang="nasal">
(condition and setprop("/sim/gui/loaded", 1)) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
Doesn't it seem silly to be including the return of {{code|setprop()}} in the value of the left expression, which then can influence the execution of the second piece of code? In particular:
<syntaxhighlight lang="nasal">
var hash = {};
!contains(hash, "loopid") and hash.loopid = 0 or hash.loopid += 1;
</syntaxhighlight>
Which evaluates like this:
# hash is empty, so contains(hash, "loopid") is false, and !contains(...) is thus true, so
# the right-hand side of {{code|and}} is tried, which is assignment to 0, and since the value of assignment is the right-hand side, it produces 0 aka false.
# since the result of false and false is false (which is the left side of the {{code|or}}), the right side of the {{code|or}} is tried (!) as per short-circuit rules.
# that means hash.loopid += 1 is evaluated – wait, didn't we want to ''not'' evaluate this?

This counter-example proves that using "{{code|... and ... or ...}}" isn't quite the same thing as using "{{code|if (...) ... else ...}}" expression (which is better done using the ternary operator, "{{code|... ? ... : ...}}), which can be a dangerous bug, so the rule is: '''don't use this'''.

== Slicing and indexing ==
{{Note|As of 27 May 2014, the syntax {{code|expr[]}} is no longer valid and considered an error. It is neither a slice nor an index expression, although it utilized postfix brackets.}}
In Nasal, vectors can be sliced (i.e. a new vector is constructed from indexes of an existing vector) and strings, hashes, and vectors can be indexed/subscripted. For an overview of slicing see [[Nasal Variables#Vector slicing|vector slicing]].

Indexing works in different ways for the different types. For strings indexing returns a value equal to the value of the character at the position. For hashes it looks up the key in the hash directly, ignoring the parents vector, and returns nil if it is not found; this treats numbers and strings as different types of keys. For vectors, the value at the index of the array is retrieved, if it is valid. Some examples:
<syntaxhighlight lang="nasal" enclose="div">
var vec = [0,1,2,3];
vec[0] == 0; vec[1] == 1;
vec[-1] == 3; # last element
vec[-2] == 2; # next-from-last element

var hash = {
-1: 0,
"-1": 1,
hello: "hi",
parents: [{ find_me_here: 42 }]
};
hash[-1] == 0; # look up the number -1 in the hash
hash["-1"] == 1; # look up the string (!) "-1" in the hash
hash[-1~""] == 1; # same thing -- makes a string
hash.hello == "hi"; # find the member hello in the hash
hash["hello"] == "hi"; # approximately the same, but using an index expression
hash.find_me_here == 42; # find the member find_me_here in the hash, or actually its parent
hash["find_me_here"] == nil; # but it cannot be found with an index expression, because its parent isn't searched
hash.parents[0]["find_me_here"] == 42; # but we can always look for the specific parent's member
</syntaxhighlight>

== Semantics ==

Some insights on the workings of various common operations.

=== Equality ===

Here are the rules for checking equality:
* If both are scalars:
** If both are numeric: check if they are numerically equal (converting to numbers first).
** Else: check if they are equal as strings.
* Else compare id's (items only equal themselves, e.g. {{code|nil == nil}} while {{code|[] != []}} because they are different vectors with different id's).

=== Boolean evaluation ===

Rules for checking if a value is "true" or "false":
* If nil: return false
* If numeric:
** If 0: return false
** Else: return true
* Else: error "non-scalar in boolean context" (applies to hashes, functions, vectors, and ghosts)

== Table ==
Here's a summary of operators, in no particular order:
{| class="wikitable"
|-
! Symbol !! Operates on... !! Evaluates to...
|-
| {{code|+}} and {{code|-}} and {{code|/}} and {{code|*}} || Numeric scalars || A number
|-
| {{code|~}} || Scalars || A string
|-
| {{code|?:}} || Three "simple" expressions: condition, expr1, and expr2 || expr1 if the condition is true, else expr2
|-
| {{code|or}} || Two "simple" expressions || The first expression, if it evaluates to '''true''', else the second
|-
| {{code|and}} || Two "simple" expressions || The first expression, if it evaluates to '''false''', else the second
|}

Template:Code

2014-05-27T19:59:26Z

Philosopher: Created page with "<tt>{{{1|No code provided!}}}</tt><noinclude>{{Informative template|1= __NOTOC__ == Goal == Provide a unified way to embed code inline into a paragraph and investigate possibl..."

<tt>{{{1|No code provided!}}}</tt><noinclude>{{Informative template|1=
__NOTOC__
== Goal ==
Provide a unified way to embed code inline into a paragraph and investigate possible styling.

== Usage ==
<nowiki>{{</nowiki>'''code'''<nowiki>|</nowiki>SHORT CODE EXPR<nowiki>}}</nowiki>



[[Category:Formatting templates]]
}}
</noinclude>

Nasal Operators

2014-05-27T19:35:23Z

Philosopher: /* Slicing and indexing */ one more example

{{Nasal Navigation}}

Nasal has support for various operators, both mathematical (add, subtract, multiply, and divide) and programming-specific (assignment, concatenation, control-flow, etc.). Most operators are in [http://en.wikipedia.org/wiki/Infix_notation infix notation] – that is, the operator is in the middle of its operands as in "<tt>3 + 5</tt>". As mentioned, Nasal supports the four basic math operators as <tt>+</tt>, <tt>-</tt>, <tt>*</tt>, and <tt>/</tt> (power is ''not'' available as <tt>**</tt> (Python) or <tt>^</tt> (Visual basic), but rather is done in the '''math''' namespace as: <tt>math.pow(</tt>''base'', ''exponent''<tt>)</tt>). For other math ones, assignment is just a single equals sign (<tt>=</tt>, as in <tt>var pi = 3.14</tt>) and equality comparison is double-equals (<tt>==</tt>, as in <tt>3 == 3</tt>). Relative comparisons such as less-than (<tt><</tt>), greater-than (<tt>></tt>), less-than-or-equal-to (<tt><=</tt>), and greater-than-or-equal-to (<tt>>=</tt>) also can be used (see [[Howto:Add a new binary operator to Nasal]] for an example of adding another comparison operator: the Perl "spaceship" operator, <tt><=></tt>). When operating on two variables using these operators (excepting assignment), Nasal uses a notion of "scalars" if applicable. Instead of the mathematical notion of scalars as non-vectors, a scalar in programming is defined as a number ''or'' numeric string – essentially duplicity of datatypes available to represent a number. This allows a string to also represent a number, which makes, e.g., parsing a number out of a file or string very easy, since the programmer doesn't have to think about the conversion. According to Andy (the creator of Nasal):

{{cquote| Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks. <ref>{{cite web |url=http://plausible.org/nasal/doc.html |title= Nasal – Not another scripting language.|author=Andy Ross|date=2007}}</ref>|Andy Ross}}
<references/>

This presents a problem when you need to concatenate two or more numeric strings (which is often done with the same operator as addition). If the <tt>+</tt> operator sees two numeric strings, it will add them as numbers, thus <tt>"67" + "75" == 142</tt> (resulting in a number), when one might want the string "35". Andy had to introduce a new operator to do concatenation, like the <tt>.</tt> operator in PHP, and that was the tilde (<tt>~</tt>). Here's some examples showing the difference:
<syntaxhighlight lang="nasal">
"88" + "88" == 176; # number
88 + "88" == "88" + 88; # same
"88" ~ "88" == "8888"; # string
88 ~ 88 == "8888"; # string as well
"88" ~ 88 == 88 ~ "88"; # same
</syntaxhighlight>

== Conditionals ==

Readers familiar with C/C++ will be familiar with the "ternary" operator for control-flow within an expression:
<syntaxhighlight lang="nasal">
# (condition) ? condition_true_expr1 : condition_false_expr2
x = reverse ? -x : x; # if (reverse) x = -x else x = x
</syntaxhighlight>
This is an expression that evaluates the first expression if the condition is true, or if it is false it evaluates the second expression. In most languages, this is an alternative to the if statement, which cannot be used as a value since it is a statement (in Nasal an if/else block is actually an expression, with the else value defaulting to nil if there is no else, so it is possible but rather ugly). The Python equivalent of the ternary-operator is: <tt>expr1 if (condition) else expr2</tt>.

Nasal also includes the boolean [http://en.wikipedia.org/wiki/Short-circuit_evaluation short-circuit operators] "<tt>or</tt>" and "<tt>and</tt>" as keywords not symbols (not <tt>||</tt> and <tt>&&</tt>), like in Python. Unary negation is still <tt>!</tt> like C/C++ (Python, however, does it as "<tt>not</tt>"). One of the uses for these is as a reduction of if statements:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1); # if (condition) setprop("/sim/gui/loaded", 1)
condition or setprop("/sim/gui/exited", 1); # if (!condition) setprop("/sim/gui/exited", 1) -- negated case of above
</syntaxhighlight>

Beware! if{}else{} does ''not'' (quite) work in this way:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
"<tt>or</tt>" is of higher precedence than "<tt>and</tt>", so that is equivalent to:
<syntaxhighlight lang="nasal">
(condition and setprop("/sim/gui/loaded", 1)) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
Doesn't it seem silly to be including the return of <tt>setprop()</tt> in the value of the left expression, which then can influence the execution of the second piece of code? In particular:
<syntaxhighlight lang="nasal">
var hash = {};
!contains(hash, "loopid") and hash.loopid = 0 or hash.loopid += 1;
</syntaxhighlight>
Which evaluates like this:
# hash is empty, so contains(hash, "loopid") is false, and !contains(...) is thus true, so
# the right-hand side of <tt>and</tt> is tried, which is assignment to 0, and since the value of assignment is the right-hand side, it produces 0 aka false.
# since the result of false and false is false (which is the left side of the <tt>or</tt>), the right side of the <tt>or</tt> is tried (!) as per short-circuit rules.
# that means hash.loopid += 1 is evaluated – wait, didn't we want to ''not'' evaluate this?

This counter-example proves that using "<tt>... and ... or ...</tt>" isn't quite the same thing as using "<tt>if (...) ... else ...</tt>" expression (which is better done using the ternary operator, "<tt>... ? ... : ...</tt>), which can be a dangerous bug, so the rule is: '''don't use this'''.

== Slicing and indexing ==
{{Note|As of 27 May 2014, the syntax <tt>expr[]</tt> is no longer valid and considered an error. It is neither a slice nor an index expression, although it utilized postfix brackets.}}
In Nasal, vectors can be sliced (i.e. a new vector is constructed from indexes of an existing vector) and strings, hashes, and vectors can be indexed/subscripted. For an overview of slicing see [[Nasal Variables#Vector slicing|vector slicing]].

Indexing works in different ways for the different types. For strings indexing returns a value equal to the value of the character at the position. For hashes it looks up the key in the hash directly, ignoring the parents vector, and returns nil if it is not found; this treats numbers and strings as different types of keys. For vectors, the value at the index of the array is retrieved, if it is valid. Some examples:
<syntaxhighlight lang="nasal" enclose="div">
var vec = [0,1,2,3];
vec[0] == 0; vec[1] == 1;
vec[-1] == 3; # last element
vec[-2] == 2; # next-from-last element

var hash = {
-1: 0,
"-1": 1,
hello: "hi",
parents: [{ find_me_here: 42 }]
};
hash[-1] == 0; # look up the number -1 in the hash
hash["-1"] == 1; # look up the string (!) "-1" in the hash
hash[-1~""] == 1; # same thing -- makes a string
hash.hello == "hi"; # find the member hello in the hash
hash["hello"] == "hi"; # approximately the same, but using an index expression
hash.find_me_here == 42; # find the member find_me_here in the hash, or actually its parent
hash["find_me_here"] == nil; # but it cannot be found with an index expression, because its parent isn't searched
hash.parents[0]["find_me_here"] == 42; # but we can always look for the specific parent's member
</syntaxhighlight>

== Semantics ==

Some insights on the workings of various common operations.

=== Equality ===

Here are the rules for checking equality:
* If both are scalars:
** If both are numeric: check if they are numerically equal (converting to numbers first).
** Else: check if they are equal as strings.
* Else compare id's (items only equal themselves, e.g. <tt>nil == nil</tt> while <tt>[] != []</tt> because they are different vectors with different id's).

=== Boolean evaluation ===

Rules for checking if a value is "true" or "false":
* If nil: return false
* If numeric:
** If 0: return false
** Else: return true
* Else: error "non-scalar in boolean context" (applies to hashes, functions, vectors, and ghosts)

== Table ==
Here's a summary of operators, in no particular order:
{| class="wikitable"
|-
! Symbol !! Operates on... !! Evaluates to...
|-
| <tt>+</tt> and <tt>-</tt> and <tt>/</tt> and <tt>*</tt> || Numeric scalars || A number
|-
| <tt>~</tt> || Scalars || A string
|-
| <tt>?:</tt> || Three "simple" expressions: condition, expr1, and expr2 || expr1 if the condition is true, else expr2
|-
| <tt>or</tt> || Two "simple" expressions || The first expression, if it evaluates to '''true''', else the second
|-
| <tt>and</tt> || Two "simple" expressions || The first expression, if it evaluates to '''false''', else the second
|}

Nasal Operators

2014-05-27T19:34:29Z

Philosopher:

{{Nasal Navigation}}

Nasal has support for various operators, both mathematical (add, subtract, multiply, and divide) and programming-specific (assignment, concatenation, control-flow, etc.). Most operators are in [http://en.wikipedia.org/wiki/Infix_notation infix notation] – that is, the operator is in the middle of its operands as in "<tt>3 + 5</tt>". As mentioned, Nasal supports the four basic math operators as <tt>+</tt>, <tt>-</tt>, <tt>*</tt>, and <tt>/</tt> (power is ''not'' available as <tt>**</tt> (Python) or <tt>^</tt> (Visual basic), but rather is done in the '''math''' namespace as: <tt>math.pow(</tt>''base'', ''exponent''<tt>)</tt>). For other math ones, assignment is just a single equals sign (<tt>=</tt>, as in <tt>var pi = 3.14</tt>) and equality comparison is double-equals (<tt>==</tt>, as in <tt>3 == 3</tt>). Relative comparisons such as less-than (<tt><</tt>), greater-than (<tt>></tt>), less-than-or-equal-to (<tt><=</tt>), and greater-than-or-equal-to (<tt>>=</tt>) also can be used (see [[Howto:Add a new binary operator to Nasal]] for an example of adding another comparison operator: the Perl "spaceship" operator, <tt><=></tt>). When operating on two variables using these operators (excepting assignment), Nasal uses a notion of "scalars" if applicable. Instead of the mathematical notion of scalars as non-vectors, a scalar in programming is defined as a number ''or'' numeric string – essentially duplicity of datatypes available to represent a number. This allows a string to also represent a number, which makes, e.g., parsing a number out of a file or string very easy, since the programmer doesn't have to think about the conversion. According to Andy (the creator of Nasal):

{{cquote| Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks. <ref>{{cite web |url=http://plausible.org/nasal/doc.html |title= Nasal – Not another scripting language.|author=Andy Ross|date=2007}}</ref>|Andy Ross}}
<references/>

This presents a problem when you need to concatenate two or more numeric strings (which is often done with the same operator as addition). If the <tt>+</tt> operator sees two numeric strings, it will add them as numbers, thus <tt>"67" + "75" == 142</tt> (resulting in a number), when one might want the string "35". Andy had to introduce a new operator to do concatenation, like the <tt>.</tt> operator in PHP, and that was the tilde (<tt>~</tt>). Here's some examples showing the difference:
<syntaxhighlight lang="nasal">
"88" + "88" == 176; # number
88 + "88" == "88" + 88; # same
"88" ~ "88" == "8888"; # string
88 ~ 88 == "8888"; # string as well
"88" ~ 88 == 88 ~ "88"; # same
</syntaxhighlight>

== Conditionals ==

Readers familiar with C/C++ will be familiar with the "ternary" operator for control-flow within an expression:
<syntaxhighlight lang="nasal">
# (condition) ? condition_true_expr1 : condition_false_expr2
x = reverse ? -x : x; # if (reverse) x = -x else x = x
</syntaxhighlight>
This is an expression that evaluates the first expression if the condition is true, or if it is false it evaluates the second expression. In most languages, this is an alternative to the if statement, which cannot be used as a value since it is a statement (in Nasal an if/else block is actually an expression, with the else value defaulting to nil if there is no else, so it is possible but rather ugly). The Python equivalent of the ternary-operator is: <tt>expr1 if (condition) else expr2</tt>.

Nasal also includes the boolean [http://en.wikipedia.org/wiki/Short-circuit_evaluation short-circuit operators] "<tt>or</tt>" and "<tt>and</tt>" as keywords not symbols (not <tt>||</tt> and <tt>&&</tt>), like in Python. Unary negation is still <tt>!</tt> like C/C++ (Python, however, does it as "<tt>not</tt>"). One of the uses for these is as a reduction of if statements:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1); # if (condition) setprop("/sim/gui/loaded", 1)
condition or setprop("/sim/gui/exited", 1); # if (!condition) setprop("/sim/gui/exited", 1) -- negated case of above
</syntaxhighlight>

Beware! if{}else{} does ''not'' (quite) work in this way:
<syntaxhighlight lang="nasal">
condition and setprop("/sim/gui/loaded", 1) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
"<tt>or</tt>" is of higher precedence than "<tt>and</tt>", so that is equivalent to:
<syntaxhighlight lang="nasal">
(condition and setprop("/sim/gui/loaded", 1)) or setprop("/sim/gui/exited", 1);
</syntaxhighlight>
Doesn't it seem silly to be including the return of <tt>setprop()</tt> in the value of the left expression, which then can influence the execution of the second piece of code? In particular:
<syntaxhighlight lang="nasal">
var hash = {};
!contains(hash, "loopid") and hash.loopid = 0 or hash.loopid += 1;
</syntaxhighlight>
Which evaluates like this:
# hash is empty, so contains(hash, "loopid") is false, and !contains(...) is thus true, so
# the right-hand side of <tt>and</tt> is tried, which is assignment to 0, and since the value of assignment is the right-hand side, it produces 0 aka false.
# since the result of false and false is false (which is the left side of the <tt>or</tt>), the right side of the <tt>or</tt> is tried (!) as per short-circuit rules.
# that means hash.loopid += 1 is evaluated – wait, didn't we want to ''not'' evaluate this?

This counter-example proves that using "<tt>... and ... or ...</tt>" isn't quite the same thing as using "<tt>if (...) ... else ...</tt>" expression (which is better done using the ternary operator, "<tt>... ? ... : ...</tt>), which can be a dangerous bug, so the rule is: '''don't use this'''.

== Slicing and indexing ==
{{Note|As of 27 May 2014, the syntax <tt>expr[]</tt> is no longer valid and considered an error. It is neither a slice nor an index expression, although it utilized postfix brackets.}}
In Nasal, vectors can be sliced (i.e. a new vector is constructed from indexes of an existing vector) and strings, hashes, and vectors can be indexed/subscripted. For an overview of slicing see [[Nasal Variables#Vector slicing|vector slicing]].

Indexing works in different ways for the different types. For strings indexing returns a value equal to the value of the character at the position. For hashes it looks up the key in the hash directly, ignoring the parents vector, and returns nil if it is not found; this treats numbers and strings as different types of keys. For vectors, the value at the index of the array is retrieved, if it is valid. Some examples:
<syntaxhighlight lang="nasal" enclose="div">
var vec = [0,1,2,3];
vec[0] == 0; vec[1] == 1;
vec[-1] == 3; # last element
vec[-2] == 2; # next-from-last element

var hash = {
-1: 0,
"-1": 1,
hello: "hi",
parents: [{ find_me_here: 42 }]
};
hash[-1] == 0; # look up the number -1 in the hash
hash["-1"] == 1; # look up the string (!) "-1" in the hash
hash[-1~""] == 1; # same thing -- makes a string
hash.hello == "hi"; # find the member hello in the hash
hash["hello"] == "hi"; # approximately the same, but using an index expression
hash.find_me_here == 42; # find the member find_me_here in the hash, or actually its parent
hash["find_me_here"] == nil; # but it cannot be found with an index expression, because its parent isn't searched
</syntaxhighlight>

== Semantics ==

Some insights on the workings of various common operations.

=== Equality ===

Here are the rules for checking equality:
* If both are scalars:
** If both are numeric: check if they are numerically equal (converting to numbers first).
** Else: check if they are equal as strings.
* Else compare id's (items only equal themselves, e.g. <tt>nil == nil</tt> while <tt>[] != []</tt> because they are different vectors with different id's).

=== Boolean evaluation ===

Rules for checking if a value is "true" or "false":
* If nil: return false
* If numeric:
** If 0: return false
** Else: return true
* Else: error "non-scalar in boolean context" (applies to hashes, functions, vectors, and ghosts)

== Table ==
Here's a summary of operators, in no particular order:
{| class="wikitable"
|-
! Symbol !! Operates on... !! Evaluates to...
|-
| <tt>+</tt> and <tt>-</tt> and <tt>/</tt> and <tt>*</tt> || Numeric scalars || A number
|-
| <tt>~</tt> || Scalars || A string
|-
| <tt>?:</tt> || Three "simple" expressions: condition, expr1, and expr2 || expr1 if the condition is true, else expr2
|-
| <tt>or</tt> || Two "simple" expressions || The first expression, if it evaluates to '''true''', else the second
|-
| <tt>and</tt> || Two "simple" expressions || The first expression, if it evaluates to '''false''', else the second
|}

Howto talk:Mix scenery versions

2014-05-25T05:40:56Z

Philosopher:

== Scenery v2.12? Or is it the scenery for FG 2.12 (that is, v1)? ==

I was reviewing this, are we sure that the info at [[Howto:Mix scenery versions#Use the FlightGear world map]] is correct? I thought that it still contained the old scenery (v. 1)
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 23:33, 24 May 2014 (UTC)

: Yeah, old scenery (v1) -- that's the only thing I've heard. [[User:Philosopher|—Philosopher]] ([[User talk:Philosopher|talk]]) 05:40, 25 May 2014 (UTC)

User:Philosopher/Optimization findings

2014-05-23T21:05:19Z

Philosopher: /* GC Hints */ more realistic examples, with actual GC-able objects...

{{Template:Nasal Internals}}

Here's some findings WRT optimizations. Note that these were from a test run with the B-1B, which is particularly heavy Nasal wise, see the second heading. Also note that these were profiled with a meta-Nasal script – Nasal profiling itself might have influenced some of the findings (the sim usually slows down, say, a factor of 4-6), but it should be relatively correct. To profile these yourself, clone & compile the "extended-nasal" branches of [https://gitorious.org/~philosopher/fg/philosophers-simgear] [https://gitorious.org/~philosopher/fg/philosophers-flightgear] [https://gitorious.org/~philosopher/fg/philosophers-fgdata].

== props.Node.getNode() ==

props.Node.getNode is evil. Well, as evil as it can be, here's some raw stats:
<syntaxhighlight lang="php">
props.wrapNode():
Global name: props.wrapNode()
Declared in /Users/philosopher/Documents/FlightGear/fgdata/Nasal/props.nas
Times called: 12797
Call time stats:
min: 0.000036/3.600121e-05
max: 0.062680/6.268001e-02
average: 0.000074/7.401553e-05
Used local variables: None
Unused local variables: None
Most called from: /Users/philosopher/Documents/FlightGear/fgdata/Nasal/props.nas

props.Node.getNode():
Global name: props.Node.getNode()
Declared in /Users/philosopher/Documents/FlightGear/fgdata/Nasal/props.nas
Times called: 10272
Call time stats:
min: 0.000182/1.819134e-04
max: 0.070453/7.045293e-02
average: 0.001123/1.122783e-03
Used local variables: None
Unused local variables: None
Most called from: /Users/philosopher/Documents/FlightGear/fgdata/Aircraft/Generic/aar.nas
</syntaxhighlight>
That's a lot of calls to props.wrapNode (it was the most called function in this particular run) and it creates a new Nasal object each and every time – that's 12797 Nasal objects from a short test run! (At least, I believe it was short...) And each time one does getNode, that creates a new object. So using "immediate" .setValue/.getValue (those with the relative path) is going to be better in some circumstances. The best solution, I believe, is to use C++Bind for these (which of course is where we're eventually headed anyways...). The good news for now is that these functions are usually closer to the minimum value versus the maximum value (in particular, wrapNode averages out to about twice it's minimum time taken and getNode is a little less than an order of ten times it's minimum).

== Aircraft/Generic/aar.nas ==

'''The worst module ever'''. To quote from my analyzer script: "Longest function called (if called more than three times): fuel.update_loop (max time taken: 0.6208341, called 51 times)".
<syntaxhighlight lang="php">
Global name: fuel.update_loop()
Declared in /Users/philosopher/Documents/FlightGear/fgdata/Aircraft/Generic/aar.nas at line 216
Times called: 51
Call time stats:
min: 0.106532/1.065321e-01
max: 0.620834/6.208341e-01
average: 0.312339/3.123395e-01
Used local variables: {'lbs', 'ppg', 'selected_tanks', 'consumed', 'cap', 'ac', 'out_of_fuel', 'gals', 'mp', 'fuel_per_tank', 'fuel', 'e', 'refueling', 't'}
Unused local variables: {'tankers'}
Most called from: /Users/philosopher/Documents/FlightGear/fgdata/Aircraft/Generic/aar.nas
</syntaxhighlight>
That's just awful, taking up a half-second max and barely managing a tenth of a second ?? This needs to be improved. (It looks like it recreates variables each time unnecessarily.)

== Garbage Collector ==
Actually, I think it's pretty efficient if it has to sort through ''that'':
<syntaxhighlight lang="php">
**** Nasal garbage collection statistics: objects: 43883, references: 105527
</syntaxhighlight>
(wink)

: to determine the potential benefits of the generational approach to GC, just add a counter to the naRef struct to count the number of GC survivals per object and increment it upon mark()ing - which should give you the percentage of "old" objects vs. "new" objects (nursery/young generation). The general assumption is that the majority of objects are in the nursery generation (gen0) and will be discarded quickly, while older objects (those having survived multiple GC passes) are assumed to stay around longer, in a larger generation (usually called "eden").

== GC Pressure ==
Objective: Come up with heuristics to define GC pressure as a useful metric, e.g.:
* function triggers GC (normally, ANY function can trigger the GC for unrelated objects, just because the GC runs out of free memory, so we need to do tracking)
* function allocates new objects
* function causes memory pools to be resized
* objects allocated by the function (temporaries) are GC'ed during or after the invocation of the func
* percentage of mark()ed and reap()ed objects per function
* repeatedly called functions (via timers or listeners) can be sampled by comparing runtime profiles of different runs
* new objects vs. additional references
* shadowed symbols

== GC Hints ==
Nasal being a dynamic language, we could reduce the amount of necessary GC work by giving hints to the GC, either through dedicated APIs (extension functions) or by using a custom syntax for variables that have a certain lifetime (which would also help with generational GC), e.g.:

<syntaxhighlight lang="php">
var canvas = {};
GC.promote_to_generation(GC.eden, canvas);
</syntaxhighlight>

A syntax/keyword-based approach would seem more intuitive, but would only take place at runtime, e.g.:

<syntaxhighlight lang="php">
var:permanent nodes = []; # a permanent variable
var:temp i = []; # a temporary variable
</syntaxhighlight>

We could use lookup tables to register callbacks for different '''var:''' storage specifiers. Python and Lua provide explicit hooks into the GC, to affect and customize GC behavior.

== Random observations ==
Resizing the window seems to be particularly Nasal-heavy (i.e. takes a long time with introspection).
: I assume that's because of a bunch of Nasal scripts having listeners registered to the x/y coordinates of the window ? Or is it something else ?

User:Philosopher/Howto:Write Optimized Nasal Code

2014-05-23T20:07:05Z

Philosopher: ... how was I using PHP highlighting here?? ;-

{{WIP}}

Paying attention to the code your writing can help speed it up and make it higher quality. This tutorial will teach programming good-practices and how to write more efficient code.

There are two main types of efficiency to think about: algorithmic and GC (garbage collector) efficiency. Like all programming languages, one can write more and less efficient algorithms to fix the same problem, and in particular Nasal does '''not''' have an optimizer, so the coder (you) have to fix these yourself. Since Nasal is a scripting language, it has automatic garbage collecting through a mark/sweep collector which has been shown to be an expensive part of running Nasal in a runtime environment. There are things that can be done about this, in particular writing code that better heeds this limitation. I will start with this issue.

== Garbage Collector-conscious optimizations ==
Except for numbers, every data type in Nasal has to be stored in an allocated C structure (struct naCode, naFunc, naCCode, naHash, naVec, and naStr) which is pointed to when a reference is needed. Each "variable" that one interacts with when writing a program is essentially a reference to one of these if the variable is not a number. To find the ones that are not valid, the mark/sweep garbage collector has to trace all references that are deemed valid and trace those children too; the starting point for the snowballing is essentially anything that is accessible from a function on the call stack or from the global namespace (though of course listeners and such also have to protect their storage). Excepting scalars, every object references other objects within their internal structure; when the object is declared as "reachable" during the mark phase, the GC also has to declare any references in the object as "reachable" as well (since they are obviously crucial to the working of their parent object and need to exist with their parent). For hashes this means all of the key/value pairs; for vectors all of the values; and for function wrappers (naFunc) the code (naCode) and its namespace (naHash) and other closures (naFunc) or the Nasal wrapper for a C function pointer (naCCode) (besides any other member references in any of those latter datatypes, like the filename for a naCode).

There are a couple ways that a new object is created, which potentially requires calling the GC before the object is allocated. These are:
# String/vector concatenation with the <tt>~</tt> operator.
# Any [...] or {...} expression to create a vector or hash.
# Any func {...} expression, since a new wrapper (naFunc) needs to be generated for the underlying code (naCode).
# A call to a function written in Nasal will need to create a namespace for the function call (unless it is specified as part of call()). This creates a new object that will need to be GC'ed later
# Most extension functions, which often will create & return new objects (those using any naNew*() API), like substr, subvec, and caller, but usually not append (if sufficiently sized, i.e. not needing to resize() - since it modifies an existing object) or systime (because it returns a number).

These constructs that create new objects are definitely fine to have in your code, but the question to ask with each one is "if this garbage-creating expression is evaluated often, can I move this to an outer scope?". In other words: can you make the object once and still have the same functionality instead of making multiple copies? An example:

<syntaxhighlight lang="nasal">
# BAD: creates multiple object in each iteration of the loop
for (var i=0; i<10; i+=1)
foreach (var j; [1,2,3,4,5]) # creates new object at the start of this foreach loop
print(j); # uses it as read-only and thus doesn't require a new object each time
# GOOD: creates one object that is used for every iteration of the loop
# without being part of the loop body, i.e. the list variable in the outer scope
# doesn't need to be GC'ed here
var list=[1,2,3,4,5];
for (var i=0; i<10; i+=1)
foreach (var j; list) # references the same object each time
print(j); # uses it as read-only
</syntaxhighlight>

Now if we were to mutate the vector, by assigning to one of its elements or by changing its size, we would want a different object each time (otherwise the mutations would keep building on top of each other). Note that in cases where we can do this, it not only serves as a GC optimization but also as a algorithmic optimization if we do this with hashes, since we avoid several hash sets to initialize the new hash by substituting a single hash get to find the variable.

* Use append(vec, a) instead of vec ~= [a].

In general, move object creation out of loops/functions, to a higher level scope, so that they don't add unnecessary garbage to the program - this applies in particular to those that are frequently used in callbacks invoked through timers and/or listeners. Also, instead of using anonymous objects in repeatedly called code, (vectors, hashes, functions) - lift their scope to a higher level, give them a symbolic name and reference them, so instead of this:

<syntaxhighlight lang="nasal">
var l = settimer( func {
var x = [1,2,3];
}, 0);
</syntaxhighlight>

Use:

<syntaxhighlight lang="nasal">
var x = [1,2,3];

var foo = func {
x;
};
var l = settimer( foo, 0);
</syntaxhighlight>

It is a good idea to set up your own environment (hash/namespace) for invocation-specific state, so that you can reuse/cache objects, rather than allocating/freeing them every time your callback is invoked.

== Algorithmic optimizations ==
Here's a list of general things to keep in mind (in no particular order):
* Use foreach/forindex where possible.
* '''Don't''' create temporary variables.
* Avoid multiple calls to a function if they will return the same thing.
* If you set a variable and make use of it only once, then directly embed the right-hand side of the assignment.
* In general, move the assignment of variables to the first place you use them, and if that is the only place you use that variable, then remove assignment of the variable entirely.

If you think some of these rules lead to complete illegibility, then you can either ignore it (at the expense of optimization) or write two versions of the same code, one optimized and one legible.

User:TheTom

2014-05-21T18:16:18Z

Philosopher: /* General */ add issue link

[[Category:FlightGear Core developers]]
[[Category:Developer Plans]]

{{User
|name = Thomas (TheTom)
|location = Austria}}

== Development plan ==

=== GUI / render ===

* Canvas based GUI {{Pending}}
** Create dialogs {{Done}} and widgets {{Pending}} from Nasal
** Handle keyboard input {{Not done}}
** Parse current gui and menu xml files {{Not done}}
* Canvas based HUD {{Pending}}
** Nasal API/framwork {{Pending}}
** Parse HUD xml files {{Not done}}
** Use Canvas GUI for 2D HUD {{Not done}}
** object placements for 3D HUD? {{Pending}}
*** Take care of projection/moving head {{Pending}}
* Canvas (API/General)
** Rotate map children according to map heading {{Pending}}

=== Animation ===

* Improved/advanced animations
** [[Tracking animation]] {{Done}}
* Blender animation/basic fdm exporter {{Pending}}

=== Simulation / systems ===

* Generic sytem building blocks {{Pending}}
** Allow to use conditions/expressions/property-rules/etc. to simulate any type of system (eg. electric, hydraulic,...) and especially take care to be able to build reusable building blocks.
** Unify/cleanup expression parser {{Not done}}
** Generic APU {{Pending}}
** Generic electrical system {{Pending}}
* Generic VDGS {{Pending}}
* MCDU/FMS/AMU framework {{Pending}}
* Blender system exporter {{Not done}}

=== Aircraft / Scenery ===

* [[Lockheed Martin C-130J Super Hercules]] {{Pending}}
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=18475 Flughafen Graz-Thalerhof (LOWG)] {{Pending}}

=== General ===

* Respect XDG directories (and environment variables) {{issue|1468}} {{Not done}}

Changelog 3.2

2014-05-19T03:28:38Z

Philosopher: /* Major enhancements in this release */ just a few commits I saw - need to add Gitorious links/more details

{{draft|changelog|This changelog is currently being written for the FlightGear 3.2 release. To see what is being worked on, check out [[Changelog 3.2]].
Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog. It's a good idea to check [[:Category:Changes_after_3.00|the newsletters since the last release]], and the git commit history.
To view the changelog for the most recent release, please see [[Changelog 3.0]].
We also encourage people to help by translating the changelog and appreciate all contributions, however please keep in mind that this changelog is not yet final!

}}

==Upcoming FlightGear Changelog==



=== Major enhancements in this release ===

'''Surface Light Effects & OpenSceneGraph 3.2'''

Stuart committed a change that brings surface lights, including VASI/PAPI/taxi/runway etc. into the xml-defined Effects framework. Kudos to Tim Moore for his original Effects work - it made it very straightforward to enhance with support for point sprites and a custom texture generator required.

The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.

Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your
build fails, please check you've got a recent OSG build installed.

'''Core'''
* [[Reset & re-init]] is merged and now enabled
* A segfault related to scripted Nasal fgcommands (like used in joystick and other bindings) has been fixed {{Issue|1397}}
* yasim versioning support for maintenance fixes (TorstenD)
* FLITE TTS support
* Windows dependencies have been updated

'''Aircraft Modeling'''
* galvedro's work: [[A Failure Management Framework for FlightGear]]
* extra 500
* Tu-154B2 version 3.1
* additional aircraft have started adopting Gijs' [[NavDisplay]]

'''JSBSim'''
* ground effects (see newsletter 02/2014)

'''Environment Rendering'''
* EarthView: Orbital Rendering (Thorsten) [http://sourceforge.net/p/flightgear/mailman/message/32262904/]

'''Performance'''
* F-JJTH and Stuart have started working on using osg::Simplifier [https://gitorious.org/fg/simgear/commit/3429e0072103a8c90d8e456f1f6b711099851225]: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAP3ntysifK34TxANKUj1s4Of_dJRg7dvJ74Gbko4zXVFHdV-YQ%40mail.gmail.com/#msg32016452

'''Misc/Uncategorized'''
* AIModels use PagedLOD
* Optimise NavCache airport query
* osg::Switch for masking scenery rendering
* Torsten's metar work, newradio, mongoose httpd
* HTTP: improve handling of connection errors
* [[FGCamera]] (external addon, not yet reviewed/committed as of 03/2014)
* Windows installer has been reworked
* Windows installer creates 3 news directories pre-configured in FGRun:
** {user}\Documents\FlightGear\Aircraft
** {user}\Documents\FlightGear\TerraSync
** {user}\Documents\FlightGear\Custom Scenery

''' Usability '''
* Windows users are now able to use scrollwheel in dialog

''' Internationalization '''

''' Scenery '''

'''Canvas System'''

FlightGear's fully scriptable 2D rendering system now includes improved APIs for creating maps and navigation displays amongst many other improvements. People no longer need to have programming experience to add a working ND to their aircraft, it can now be all done by copying and pasting 30 lines of text and customizing a few properties. The so called MapStructure back-end handles efficient updating of all ND layers transparently.

* Tom has pushed an update to git (simgear) which removes a lot of unneeded OpenGL state changes for Canvas paths. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].
* Hooray is working on adding shader support to Canvas {{Progressbar|30}}
* Gijs is currently working on additional projections as part of {{Issue|550}}
* The [[MapStructure]] back-end used by the [[NavDisplay]] now supports symbol instancing, so that performance is improved
* MapStructure-based layers can now be customized and styled
* Tom added support for button/modifiers (mouse handling) [http://wiki.flightgear.org/index.php?title=Canvas_Event_Handling&curid=10777&diff=68569&oldid=68422]
* CanvasImage now supports the ''http://'' protocol for dynamically retrieving raster images. See the renamed [[Canvas_Image#src|src attribute]] (''file'' is now deprecated).
* As part of the ongoing effort on [[Unifying the 2D rendering backend via canvas]], we have started re-implementing the integrated [[Map]] dialog using Nasal & Canvas instead of C++ {{Progressbar|80}}
* Custom event handlers can now be registered.

'''Nasal Scripting'''

* getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index", "texture", 1, "name");
</syntaxhighlight>
: is now the same as:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request 54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])
* A new fully-interactive Nasal GUI console based on [[Canvas]] has been added: [[Interactive Nasal Console]]
* the hard-coded '''flight path history''' subsystem which samples aircraft position, which was previously only accessible to C++ code, has now been exposed to scripting space by Tom so that people can easily access the system and reuse the data for their own purpoes (e.g. for creating an instructor console). The first use-case will involve the new [[Canvas]] based [[Map]] dialog which will be 100% scripted by then.
: Usage:
<syntaxhighlight lang="nasal">
var hist = aircraft.history(); debug.dump(hist.pathForHistory(50));
</syntaxhighlight>
* cppbind: Nasal ghosts can now support arbitrary setters/getters for when members are not mapped to a C++ member/method.

'''Documentation'''

'''Highlighted new and improved aircraft'''

Tuned autopilot and improved instrument stack for the Cessna337G Skymaster.

'''Other'''

'''Bug fixes'''

* See [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=Milestone%3D3.2 our bugtracker] for an extensive, yet incomplete, list of the bugs fixed in this release.

[[Category:FlightGear changelogs]]

User:Philosopher

2014-05-16T20:16:50Z

Philosopher: better document this issue report while I have it...

'''Sub-pages:''' (mostly stubs ATM)
* [[User:Philosopher/Advanced Input Programming|Advanced Input Programming]]
* [[User:Philosopher/Howto:Write Optimized Nasal Code|Howto Write Optimized Nasal Code]]
* [[User:Philosopher/Nasal introspection|Nasal introspection!]]
* [[User:Philosopher/Optimization findings|Optimization findings]] (from [[User:Philosopher/Nasal introspection|Nasal introspection]])

Currently working on improving Nasal internals and documenting them. Has the '''best''' joystick bindings (for a cheap joystick :P) at [http://flightgear.org/forums/viewtopic.php?t=17263 this topic].

Likes reading through C/C++ code for fun, and understanding, documenting, and improving it – though I'm far from an expert in either and my hat is continually off to Andy, Thomas, and James (and everyone else) for their wonderful code. Oddly enough, I find Nasal code to be harder to read, probably due to the fact that C/C++ and very structured languages and Nasal is not (it almost needs DbC at times!).

Favorite languages:
* Nasal (of course)
* Python (was my first language; I like most things about it except its duck typing – which works well until I actually need typing)
* C & C++ (different beasts; I like C++'s classes and ::iterators in particular)
* Languages yet to be discovered: I hope to find more that I like!

Things to be doing:
* [[Improving the Joystick GUI]]: porting to Canvas, tweaking things, and integration with back-end when ready.
* Joystick-Philosopher (bindings for Cyborg-X): improve the control_function library.
* Nasal improvement for 3.0 (LaTeX document, making patches and applying patches to SimGear).
* Nasal browser: need a mechanism to add/delete/edit entries, need better scrolling code.
* Canvas Map: working on [[MapStructure]].nas, to replace old map.nas &c.

Projects on the wiki:
* [[Interactive Nasal Console]]
* [[MapStructure]]
* [[User:Philosopher/Nasal introspection|Nasal Introspection]]

Good ideas:
* Expose the catapult locations to the property tree, for JSBSim 'craft and Nasal tutorials.
* [http://flightgear.org/forums/viewtopic.php?f=18&t=19666 Changing behavior of SGPropertyNodes without tying] (something like {{issue|336}}).
* (In conjunction with Hooray) Have Nasal load itself: besides for one file (either Nasal/globals.nas or something in [[$FG_ROOT]]), ''all'' Nasal should be loaded from Nasal. (Including <tt>--prop:/nasal/module_name/script</tt> and <tt>--prop:/nasal/module_name/file</tt>.) See [http://flightgear.org/forums/viewtopic.php?f=30&t=21083] & [http://forum.flightgear.org/viewtopic.php?f=30&t=21083] {{Progressbar|50}}.

Nasal thoughts area:
* I would like to include small improvements that enhance my quality of life in SimGear: string slicing, hash iteration using foreach/forindex, save/restore aka stash? (latter to be discussed)
* Hooray and I talk about more extension functions to allow looking into internals; I need to review all of these, gather them up, add to them, etc., and hope they can be included somewhere (Hooray was saying maybe just the standalone Nasal in SimGear, not FlightGear's runtime).
** Sub-idea: if we only include the extensions in standalone and we have optimizer/post-compiler scripts ready, then make a script to be run with standalone that optimizes any or all Nasal files and outputs an optimized version (*.nas.optimized) or even just the bytecode (*.nas.opcode, textual file ofc) and have that be the preferred loading method (if the text is older than the optimized version).

Implementing new features for FlightGear

2014-05-16T18:08:57Z

Philosopher: some formatting tweaks

{{WIP}}

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".

Currently, this article is entirely based on a write-up that Thorsten contributed based on having worked on a variety of novel, and unprecedented, FlightGear features over the years which initially also didn't receive much support at all, and which also caused lengthy discussions (or even flame wars) on the forum and the devel list, including features like [[Advanced weather]], [[Atmospheric light scattering]], [[Procedural Texturing]] and most recently the [[FlightGear Newsletter April 2014|EarthView]] orbital rendering engine.
These are just a few examples to put some context around the advice given here. Also note that the people who contributed to this particular write-up are not core developers per se, we are also primarily middleware/base package contributors. And when we started out a few years ago (and several thousand postings back), we were also highly critical about [[How the FlightGear project works|the way the project works]], and all its shortcomings. And now, we're often the ones being "yelled" at on the forums when dealing with newcomers, even though that's exactly how we started out.
Yet, fast forward 5+ years later, we are still trying to contribute in meaningful ways to the project, despite some (or even many) of these problems still persisting even today. So this is an attempt to provide a '''lessons learnt''' intro based on newcomers trying to become contributors, and trying to turn their ideas into features that actually end up in FlightGear, without having to be expert programmers necessarily, or even programmers at all.

== What is this about? ==

Like many FG users, you probably reach a point when you think 'Wouldn't it be nice if we had feature XY?' From this point, there are various options available:

* You mention it in the forum: A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there.
* You make a formal feature request on the issue tracker: The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen.
* You make it your own project to get feature XY implemented: This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on.

== Some (unpleasant) truths up front ==
First, to avoid disappointments, it is important to understand how FG as an OpenSource all-volunteer project works - if you start with your project without understanding these essentials, it is bound to fail.

# Flightgear relies on having a contributor base, but not on a user base: Unlike a commercial project which needs customers to survive, FG does not. As a result, FG development is not focused on the end user. Developers tend to work on features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting.
# Developers are free to do what they want: This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily.
# Flightgear development tends to be inclusive: There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers).

== Test the waters ==

If you want your idea to be part of Flightgear in the end and not a fork or an addon, test the waters early on. Working for a year on some project which won't be committed in the end is frustrating for both sides. Use the forum or the mailing list to talk to people, get a feeling for how the response is, just don't leave it there.

Some events that have occurred in the past, and what to learn from them:

* Beautiful airport scenery (and certain aircraft/cockpits) could not be committed, because it was textured using material from a source that has free textures with a no commercial use clause. This however is incompatible with FGs GPL license which permits also commercial use. Lesson: If you use any material other than your own work, check the license early!

* A large collection of Swiss airport scenery could not be committed because it was structured in the wrong way - scenery data has to be submitted in a certain format to the scenery database, other data to the FGData repository. Lesson: Study the structure of FG - don't expect that the whole structure of the project will change for you, it is what it is for good reasons, even if you don't know them, others do.

* The bombable addon providing support for air combat could not be committed because the devel community feels strongly that FG should remain a civilian aviation simulator. Lesson: Test the waters, see what the response to an idea from developers who can commit are. They will decide, regardless of what users say.

== Gather information ==

Regardless if you want to proceed on your own, or if you want to find people to help you - you need information. If you want to see a new visual effect implemented, at minimum you need to find out who inside the FG project can help you, even better is to have an idea what options FG provides, how the effect framework works, how effects are configured etc. The Wiki is your friend, but usually if you show some interest, people in the forum will post helpful links. If you want to be taken seriously later, work through the information and make sure you know what you're talking about.

== Make a proposal ==

Now it's time to approach the people who can help you. Remember - they're volunteers. So you need to get them interested.

Do...

* ... point out how your idea will make FG a better simulation.
* ... make a point out of what you would be willing to do if only XY were available.
* ... be as concrete as possible, point out what precisely you would like to see changed.
* ... demonstrate that you have looked at the relevant information and know what you're talking about

Don't...

* ... demand anything from anyone.
* ... be rude or angry if people are critical - it's part of the process.
* ... point out how bad FG is going to be or how it will fail if your idea is not implemented.
* ... say you can't do anything, because you don't understand C++ - the human mind can learn

Compare 'Wouldn't it be cool if we had better-looking cities like X-Plane?' with 'Would it be possible to make the random building shader configurable such that it loads a pre-defined set of 3d models and assembles them in naturally looking groups by a placement mask of this and that format? I would then take care of the buildings and textures, but I'd need some help with the code. Here's a picture of how FG could look like.' - which of the two proposals would you support?

Even good proposals have a fair chance of failing to get any support. The reason is that experience has shown that the majority of people who say that they would do X if only feature XY is implemented do in fact not do X afterwards. Which is to say, before starting to join a project, developers want to be reasonably sure that their work will not be in vain because you lose interest and walk away. The magic words here are 'track record' and 'proof of concept', you can help improve you signal/noise ratio significantly by ensuring that you follow up on your commitments and do the necessary behind-the-scenes networking to implement a new feature or project. It is this combination of having a track record, "credit" and a good signal/noise ratio that will ultimately give you certain ''leverage'' when interacting with other contributors.
Overall, time spent contributing to the project really '''is''' our "currency-it shows dedication and discipline and it demonstrates to potential collaboratos that you are serious about your commitments, and that teaming up with you is not a waste of their time. If properly done, such networking can be a great multiplier/lever.

If you already have a history of bringing projects to a conclusion, people are far, far more likely to support you. If you have not, because you're just starting out, the best thing you can do is a proof of concept. Perhaps something should really be in C++ for performance reasons - but you can make a simple proof of concept in Nasal scripting space. Once people see that you're actually investing time and work rather than talk, and once they can see what you want to do, you're again more likely to get support.

== Be persistent ==
If you fail to get help you need, think about why. There may be fair reasons for it - your priority may not be everyone else's priority, or some criticism may not be mean but actually valid, or your contribution isn't apparent enough - go back and try to revise the proposal. If you can't get help in some area, perhaps there's a workaround which is less perfect? Nasal often is a viable alternative to C++, and subsystems can always be converted later. Trying to get things perfect up-front is likely to get you nowhere, because making things perfect is very hard - starting with something 'good enough' and improving it is more likely to succeed. If your project is truly good, it will get support on the way. Investigate your idea critically, but if you truly believe in your idea, stay with it and make it work in some form.

As an example, in the beginning the idea of using Nasal to implement a full weather system was not taken seriously by anyone in the development community. Once written in a very inefficient but working way, the system however did get lots of help from developers on the C++ side and is now known as Advanced Weather, one of the most sophisticated weather systems which exist in a flight simulation.

== Honor your commitments ==

This should go without saying but: Keep your end of the bargain. Seriously. If you got someone to do a month of work for you because you proposed it would enable you to do XY and you in fact don't do XY later, that's pretty much it - no one will ever lift a finger for you from that point.

== Release early, document your efforts ==

Use the forum and/or the wiki as a platform to show people what you are doing and how you are progressing. People need to be aware of things before they can help you, and you may get useful pointers just at the expense of posting your current vexing problem in the forum. It is also always a good idea to do a forum/devel list search to check the archives for related discussions that took place in the past, this should give you a good idea on discussed approaches, but also people involved in these discussions (and if they're still around or not).

While the forum and the devel mailing list are great places for discussions, there are sometimes topics that have been discussed at great lengths, this includes topics like multiplayer improvements or even combat support for example.

For such popular discussions, there are often 5-10 threads per year on the list/forum with typically dozens of responses. Another popular debate is better multi-threading support, but also scenery improvements.

Accordingly, given the popularity of these topics, there are typically hundreds (or even thousands!) of postings and statements that have been made over the years.

Often, with little -if anything- materializing from such debates directly, no matter how good the discussed ideas were. Postings may contain good suggestions, useful feedback, but also lots of controversial arguments.
And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved.

Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time.

'''Time''' really being the keyword here - some topics are not about a single isolated feature that can simply be implemented by some random developer, those are often large-scale architectural changes, or even proposals to change the project's philosophy ([[Release Plan]]) or some of its infrastructure (e.g. the [[FlightGear Build Server]]). Thus, these topics are often not about people disagreeing that something needs to be done, but the suggestion really is a long-term item, that needs to be tackled over time - typically many months, often several years.

Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time. We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA effort is another example for this. Typically, complex ideas may very well have a shelf life of several months - often, 12-18 months. The [[Canvas]] system only took shape 18 months after it had been discussion on the FlightGear wiki for example.

Thus, sometimes good ideas may take time to materialize - and whenever timing doesn't seem to work, it's a good idea to let time work for you, by creating a corresponding wiki article to document something, and maintaining it over time.

Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release.

If you made it to this point, you may perhaps appreciate much better why the devel community is how it is!

Implementing new features for FlightGear

2014-05-16T17:59:58Z

Philosopher: remove Template:Note because it doesn't quite fit

{{WIP}}

We've been seeing an increasing number of discussions on the forum started by people who are obviously eager to become potential contributors. 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".

Currently, this article is entirely based on a write-up that Thorsten contributed based on having worked on a variety of novel, and unprecedented, FlightGear features over the years which initially also didn't receive much support at all, and which also caused lengthy discussions (or even flame wars) on the forum and the devel list, including features like [[Advanced weather]], [[Atmospheric light scattering]], [[Procedural Texturing]] and most recently the [[FlightGear Newsletter April 2014|EarthView]] orbital rendering engine.
These are just a few examples to put some context around the advice given here. Also note that the people who contributed to this particular write-up are not core developers per se, we are also primarily middleware/base package contributors. And when we started out a few years ago (and several thousand postings back), we were also highly critical about [[How the FlightGear project works|the way the project works]], and all its shortcomings. And now, we're often the ones being "yelled" at on the forums when dealing with newcomers, even though that's exactly how we started out.
Yet, fast forward 5+ years later, we are still trying to contribute in meaningful ways to the project, despite some (or even many) of these problems still persisting even today. So this is an attempt to provide a '''lessons learnt''' intro based on newcomers trying to become contributors, and trying to turn their ideas into features that actually end up in FlightGear, without having to be expert programmers necessarily, or even programmers at all.

== What is this about? ==

Like many FG users, you probably reach a point when you think 'Wouldn't it be nice if we had feature XY?' From this point, there are various options available:

* You mention it in the forum:

A vast body of observation suggests that the likely outcome of this is that several users will answer and tell you that it is a good idea, a few long-term contributers will chime in and point out possible difficulties, and it will end there.

* You make a formal feature request on the issue tracker:

The most likely outcome are a few comments and then the request will be assigned a low priority and not much else will happen.

* You make it your own project to get feature XY implemented:

This doesn't necessarily mean that you have to do everything yourself, but it means that you must actively manage what is happening rather than be content to put an idea out in writing and relax. If you're willing to do this, this guide is for you, please read on.

== Some (unpleasant) truths up front ==
First, to avoid disappointments, it is important to understand how FG as an OpenSource all-volunteer project works - if you start with your project without understanding these essentials, it is bound to fail.

# Flightgear relies on having a contributor base, but not on a user base

Unlike a commercial project which needs customers to survive, FG does not. As a result, FG development is not focused on the end user. Developers tend to work on features they would like to see, scenery contributors work on areas of the world they are interested in - the project works on the basis of people devoting their spare time to creating the simulator they want to have. This means that arguments along 'If feature XY will be implemented, many more users will join the community.' or 'If feature XY is not implemented, many users will use FSX instead.' will leave developers unimpressed, but arguments like 'If feature XY is implemented, it allows new contributors to improve the simulator in that way.' will be regarded as more interesting.

# Developers are free to do what they want

This should be pretty obvious given the nature as an all-volunteer project, but in reality it is not, so it's worth pointing out: FG developers work for the project in their free time, they have work and family obligations just like other people, and they have every right to not work on FG or to not code a feature even if a majority of users or developers thinks it is very important. The implication is that if you like anyone to help you, you need to convince him to do it voluntarily.

# Flightgear development tends to be inclusive

There is strong concern throughout the development community about making FG impossible to use for some hardware setups or dropping existing features, and all such changes tend to be discussed in length (over months or even years). Usually new features are therefore implemented in an optional way. If the feature you have in mind will mean abandoning support for an existing feature, you will have a hard time getting support even if it has clear benefits (the devel community did for instance not support the use of compressed dds textures despite their obvious benefits in terms of loading time and GPU memory consumption for the reason that they can't be run by Linux-users with non-proprietary graphics drivers).

== Test the waters ==

If you want your idea to be part of Flightgear in the end and not a fork or an addon, test the waters early on. Working for a year on some project which won't be committed in the end is frustrating for both sides. Use the forum or the mailing list to talk to people, get a feeling for how the response is, just don't leave it there.

Some events that have occurred in the past, and what to learn from them:

* Beautiful airport scenery (and certain aircraft/cockpits) could not be committed, because it was textured using material from a source that has free textures with a no commercial use clause. This however is incompatible with FGs GPL license which permits also commercial use. Lesson: If you use any material other than your own work, check the license early!

* A large collection of Swiss airport scenery could not be committed because it was structured in the wrong way - scenery data has to be submitted in a certain format to the scenery database, other data to the FGData repository. Lesson: Study the structure of FG - don't expect that the whole structure of the project will change for you, it is what it is for good reasons, even if you don't know them, others do.

* The bombable addon providing support for air combat could not be committed because the devel community feels strongly that FG should remain a civilian aviation simulator. Lesson: Test the waters, see what the response to an idea from developers who can commit are. They will decide, regardless of what users say.

== Gather information ==

Regardless if you want to proceed on your own, or if you want to find people to help you - you need information. If you want to see a new visual effect implemented, at minimum you need to find out who inside the FG project can help you, even better is to have an idea what options FG provides, how the effect framework works, how effects are configured etc. The Wiki is your friend, but usually if you show some interest, people in the forum will post helpful links. If you want to be taken seriously later, work through the information and make sure you know what you're talking about.

== Make a proposal ==

Now it's time to approach the people who can help you. Remember - they're volunteers. So you need to get them interested.

Do...

... point out how your idea will make FG a better simulation.
... make a point out of what you would be willing to do if only XY were available.
... be as concrete as possible, point out what precisely you would like to see changed.
... demonstrate that you have looked at the relevant information and know what you're talking about

Don't...

... demand anything from anyone.
... be rude or angry if people are critical - it's part of the process.
... point out how bad FG is going to be or how it will fail if your idea is not implemented.
... say you can't do anything, because you don't understand C++ - the human mind can learn
Compare 'Wouldn't it be cool if we had better-looking cities like X-Plane?' with 'Would it be possible to make the random building shader configurable such that it loads a pre-defined set of 3d models and assembles them in naturally looking groups by a placement mask of this and that format? I would then take care of the buildings and textures, but I'd need some help with the code. Here's a picture of how FG could look like.' - which of the two proposals would you support?

Even good proposals have a fair chance of failing to get any support. The reason is that experience has shown that the majority of people who say that they would do X if only feature XY is implemented do in fact not do X afterwards. Which is to say, before starting to join a project, developers want to be reasonably sure that their work will not be in vain because you lose interest and walk away. The magic words here are 'track record' and 'proof of concept'.

If you already have a history of bringing projects to a conclusion, people are far, far more likely to support you. If you have not, because you're just starting out, the best thing you can do is a proof of concept. Perhaps something should really be in C++ for performance reasons - but you can make a simple proof of concept in Nasal scripting space. Once people see that you're actually investing time and work rather than talk, and once they can see what you want to do, you're again more likely to get support.

== Be persistent ==
If you fail to get help you need, think about why. There may be fair reasons for it - your priority may not be everyone else's priority, or some criticism may not be mean but actually valid, or your contribution isn't apparent enough - go back and try to revise the proposal. If you can't get help in some area, perhaps there's a workaround which is less perfect? Nasal often is a viable alternative to C++, and subsystems can always be converted later. Trying to get things perfect up-front is likely to get you nowhere, because making things perfect is very hard - starting with something 'good enough' and improving it is more likely to succeed. If your project is truly good, it will get support on the way. Investigate your idea critically, but if you truly believe in your idea, stay with it and make it work in some form.

As an example, in the beginning the idea of using Nasal to implement a full weather system was not taken seriously by anyone in the development community. Once written in a very inefficient but working way, the system however did get lots of help from developers on the C++ side and is now known as Advanced Weather, one of the most sophisticated weather systems which exist in a flight simulation.

== Honor your commitments ==

This should go without saying but: Keep your end of the bargain. Seriously. If you got someone to do a month of work for you because you proposed it would enable you to do XY and you in fact don't do XY later, that's pretty much it - no one will ever lift a finger for you from that point.

== Release early, document your efforts ==

Use the forum and/or the wiki as a platform to show people what you are doing and how you are progressing. People need to be aware of things before they can help you, and you may get useful pointers just at the expense of posting your current vexing problem in the forum. It is also always a good idea to do a forum/devel list search to check the archives for related discussions that took place in the past, this should give you a good idea on discussed approaches, but also people involved in these discussions (and if they're still around or not).

While the forum and the devel mailing list are great places for discussions, there are sometimes topics that have been discussed at great lengths, this includes topics like multiplayer improvements or even combat support for example.

For such popular discussions, there are often 5-10 threads per year on the list/forum with typically dozens of responses. Another popular debate is better multi-threading support, but also scenery improvements.

Accordingly, given the popularity of these topics, there are typically hundreds (or even thousands!) of postings and statements that have been made over the years.

Often, with little -if anything- materializing from such debates directly, no matter how good the discussed ideas were. Postings may contain good suggestions, useful feedback, but also lots of controversial arguments.
And more often than not, the general truth is that people -especially newcomers- are unlikely to do a forum/devel list search in order to dig out some discussion that took place many years ago, just to learn about a project, its status, the ideas and the people that were involved.

Thus, it is up to you to see how much momentum there really is, or if a certain topic tends to be a "time-waster", i.e. taking up lots of time to deal with, with very little materializing in terms of features - sometimes, those are long-standing features, such as being able to reset/re-init the simulator, or even save/load flights and switch aircraft at run-time. These are popular feature requests and there are dozens of discussions related to these, so it is usually not a good idea to start yet another debate - this is where a less-conversational platform (like the wiki) can be a great tool, so that ideas, proposals, community support and project status can be documented over time.

'''Time''' really being the keyword here - some topics are not about a single isolated feature that can simply be implemented by some random developer, those are often large-scale architectural changes, or even proposals to change the project's philosophy ([[Release Plan]]) or some of its infrastructure (e.g. the [[FlightGear Build Server]]). Thus, these topics are often not about people disagreeing that something needs to be done, but the suggestion really is a long-term item, that needs to be tackled over time - typically many months, often several years.

Here, using the wiki to present your ideas, and document related discussions, proposals and supporters, can be a great tool to aid building up momentum over time. We've had a number of efforts that got discussed for years before they finally got implemented. This included for example the PLIB/OSG migration, and the HLA effort is another example for this. Typically, complex ideas may very well have a shelf life of several months - often, 12-18 months. The [[Canvas]] system only took shape 18 months after it had been discussion on the FlightGear wiki for example.

Thus, sometimes good ideas may take time to materialize - and whenever timing doesn't seem to work, it's a good idea to let time work for you, by creating a corresponding wiki article to document something, and maintaining it over time.

Make your efforts available for testing early - let people play with it and get ideas from it. Only a well-working project should go directly to the FG repositories, but there's plenty of ways to distribute your efforts before that. When it's ready and tested, make a merge request on GIT, talk to a person who has commit rights and is able to test your work, and enjoy your feature being part of the next release.

If you made it to this point, you may perhaps appreciate much better why the devel community is how it is!

Template:Note

2014-05-16T17:55:40Z

Philosopher: remove float:center...

<div class="noprint" style="margin:1em 5% 1em 5%; border: 1px solid #AAAAAA; border-left: 10px solid #1E90FF; width: 50%; background-color: #F5F5F5; padding: 2px;">
{| cellspacing="0"
| style="padding-left:5px;"| '''Note:''' {{{1}}}
|}</div>
<noinclude>{{Informative template |1=
== Goal ==
Provide an uniform note style.

== Usage ==
<code><nowiki>{{note|The actual text comes here.}}</nowiki></code>
}}

[[Category:Messagebox templates]]
</noinclude>

Template:Note

2014-05-16T17:52:35Z

Philosopher: restore margin setting?

<div class="noprint" style="margin:1em 5% 1em 5%; float:center; border: 1px solid #AAAAAA; border-left: 10px solid #1E90FF; width: 50%; background-color: #F5F5F5; padding: 2px;">
{| cellspacing="0"
| style="padding-left:5px;"| '''Note:''' {{{1}}}
|}</div>
<noinclude>{{Informative template |1=
== Goal ==
Provide an uniform note style.

== Usage ==
<code><nowiki>{{note|The actual text comes here.}}</nowiki></code>
}}

[[Category:Messagebox templates]]
</noinclude>

Template:Note

2014-05-16T17:49:37Z

Philosopher: wasn't fond of the style here... so copied the div from Template:notice and added small caps to NOTE - does it look good?

<div class="noprint" style="margin-left: auto; margin-right:auto; float:center; border: 1px solid #AAAAAA; border-left: 10px solid #1E90FF; width: 50%; background-color: #F5F5F5; padding: 2px;">
{| cellspacing="0"
| style="padding-left:5px;"| '''Note:''' {{{1}}}
|}</div>
<noinclude>{{Informative template |1=
== Goal ==
Provide an uniform note style.

== Usage ==
<code><nowiki>{{note|The actual text comes here.}}</nowiki></code>
}}

[[Category:Messagebox templates]]
</noinclude>