https://wiki.flightgear.org/w/api.php?action=feedcontributions&user=T3r&feedformat=atomFlightGear wiki - User contributions [en]2024-03-28T14:41:26ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=Howto:Set_up_a_multiplayer_server&diff=117817Howto:Set up a multiplayer server2019-04-13T09:57:17Z<p>T3r: </p>
<hr />
<div>This page is dedicated to providing a short overview of installing the [[FlightGear Multiplayer Server]] ('fgms'). The reader is assumed to be reasonably familiar with working in a Unix/Linux shell environment.<br />
<br />
== Pre-Requisites ==<br />
* A computer running a variant of *nix to compile and host the server. Speed of the machine isn't of great consequence as the protocol is a multiplexer which doesn't require much processing grunt.<br />
** For specific documentation for setting up on FreeBSD see [[Howto:Set up a multiplayer server on FreeBSD]].<br />
* direct/physical or remote access to the server (i.e. SSH/telnet, a conventional web hosting package will usually '''not''' be sufficient!)-suitable hosting packages are: dedicated root servers, virtual private servers, shell servers - for a collection of '''free''' shell account providers that may be suitable for fgms, see [[Free Shell Providers]] (you may want to check this out if you are interested in running fgms but don't have hosting yet)<br />
* if the server is meant to be a public internet server: an internet connection, featuring sufficient upstream/downstream capabilities (see below for details concerning bandwidth requirements). <br />
* firewall policies will need to be set up to allow for incoming and outgoing UDP traffic for the corresponding ports, the same applies to the administration port (TCP)<br />
* permission to run unattended background processes (this may only be an issue with certain limited hosting packages)<br />
* a working GNU toolchain including gcc/g++ (compiler), make & cmake<br />
* fgms source code, currently version 0.10.23<br />
* about 5-10 MB of hard disk space (mainly required for building the binary)<br />
<br />
== Traffic & Bandwidth Considerations ==<br />
<br />
Note: Currently (May 2008), the server code basically boils down to a packet multiplexer (i.e. most data is -unconditionally- transmitted to all 'active' clients), which may thus create considerable amounts of traffic; this ought to be taken into consideration due to bandwidth limitations in most hosting packages (i.e. '''fgms may create considerable amounts of traffic!'''). For basic calculations: inbound traffic is 25 Kilobit per second while outbound is 25 Kbits per second for each plane/client that can 'see' another. <br />
<br />
By default, assuming a 10hz update interval, each active fgfs client will currently cause I/O traffic of approximately 5 kbytes/sec (one update consuming ~500 bytes) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16016.html].<br />
<br />
As client updates have to be propagated to all other active clients by the server, this number has to be multiplied by the number of active clients -1 (i.e. clients within a configurable range, minus the originating client). <br />
In addition, the fgms system allows for traffic updates to be sort of 'mirrored' on (relayed to) other configurable multiplayer/relay servers. <br />
<br />
This feature makes it possible for users/clients to use an arbitrary server (with acceptable latency), but still see clients/vehicles connected to different servers. Thus, such relay servers may additionally increase inbound/outbound traffic considerably as all traffic is mirrored/propagated to such relays.<br />
<br />
Having more servers should actually decrease the load on each server in high load situations, i.e. when most of the clients are within range of each other. See this<br />
[http://www.gidenstam.org/FlightGear/fgms/fgms_bandwidth_estimates.txt brief note on the theoretical bandwidth behaviour of fgms.]<br />
<br />
=== Facts ===<br />
In March 2008, the main fgms multiplayer server (pigeond.net) was reported to consume approximately 15 gb of bandwidth per '''day''', with an average throughput of 200 kB/sec and peak loads of up to ~ 650 kB/sec [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16016.html].<br />
<br />
During the same month (the much less used but interconnected) mpserver06.flightgear.org had on average 742 MB incoming and 688 MB outgoing traffic per day (i.e. 72 kbit/sec respective 66 kbit/sec on average).<br />
<br />
In September 2009, mpserver 05 had a massive peak bandwidth of 1.0 MB/sec. Average bandwidth consumed was about 9 GB of bandwidth per day. The average bandwidth usage per day is climbing due to more users moving from 02 to 05.<br />
<br />
In July 2013, mpserver01 load was reported averaging at 10 MBit/sec<br />
<br />
=== Reducing bandwidth requirements ===<br />
Total network traffic is mainly determined by the number of active clients that 'see eachother' and configured mirrors. <br />
If traffic considerations are relevant, the following options exist to reduce overall server/network load:<br />
<br />
* configure a relatively low "server.out_of_reach" value, so that clients outside a certain range are not provided with updates (usually about 100 nm on the main server network)<br />
* for virtual gatherings (i.e. fly-ins), have clients use airports and places that do not have lots of other traffic (i.e. in other words, avoid places like standard airports such as KSFO)<br />
* avoid the use of unnecessary relay servers<br />
* if you are not interested in your server being publicly available, only share its address with your friends privately<br />
* for local testing/development purposes, you may want to run only a private fgms session, that may be specific to your LAN or even computer.<br />
<br />
== Getting & Building fgms ==<br />
* You will need the build tools cmake and make, and also g++ to compile the fgms application. These can usually be found in the package manager for most the common Linux distributions. You will also need the git client to fetch the source code from the repository, if you plan to download it from the command line interface (see below).<br />
* Once the build tools are installed on your machine, create a directory to hold the source code. This could be named anything, such as fgms. Create it in your user home directory. Note that this WILL NOT be the directory where the program will be compiled.<br />
* Now 'cd' into the directory you just made, where you will run the command to fetch the source code from the git repository (see below). <br />
* To download the latest stable version via HTTP, you can use direct your browse to the URL https://sourceforge.net/projects/fgms/. Download and unzip the source code, and place it in the directory you created above.<br />
* To download a file directly to your server from an ssh session, you can use git tools with the following command:<br />
:<syntaxhighlight lang="bash">git clone https://git.code.sf.net/p/fgms/src</syntaxhighlight><br />
<br />
== Compiling FGMS ==<br />
<br />
For FreeBSD-specific instructions, please see [[Howto:Set up a multiplayer server on FreeBSD]]<br />
<br />
NOTE: In general, on any current machine this process should not take longer than about 60 seconds.<br />
<br />
* Once you have the source code, 'cd' into the ~/fgms/ directory and note the presence of the CMakeLists.txt file and the README.cmake file. Open the README.cmake file and take a minute to read it over. Also, note the path to the CMakeLists.txt file, as you will need this in the following steps.<br />
<br />
* Now create a build-fgms directory in your home directory, and 'cd' into it. From inside the ~/build-fgms/ directory, run the cmake command using the path to the CMakeLists.txt as an argument. For example: cmake /home/<user_name>/fgms/<br />
<br />
* Once the build finishes, you can either run the "cmake --build ..." command as shown in the README.cmake file, or you can simply use "make" to build the program.<br />
<br />
* Once the compilation process finishes, you need to install the program using "make install" (as user), or you can also install as root.<br />
<br />
* Once the program has been installed, you need to copy the example *.conf files from the /fgms/contrib/etc directory, into the build-fgms directory. To do this from inside the /fgms/contrib/etc directory, you can use e.g. this command: cp ./fgms_local.skel.conf ~/build-fgms/<br />
<br />
* Now 'cd' into the build-fgms directory, and rename the file you just copied as "fgms.conf" so that fgms can find the proper configuration.<br />
<br />
== Running in docker ==<br />
** WARNING - this is currently under development, consider this experimental **<br />
If you have docker installed or are willing to do so, there are pre-built docker images available at [https://cloud.docker.com/u/flightgear/repository/docker/flightgear/fgms/ The docker hub]. There are images for amd64/linux systems as well as for raspberry pis running arm/linux. Sorry, no windows based binaries are currently available.<br />
<br />
Installing docker on any linux or the pi is as easy as<br />
:<syntaxhighlight lang="bash">curl -sSL https://get.docker.com | sh</syntaxhighlight><br />
and adding your user to the docker group.<br />
<br />
If you have docker running, you are all set to start your multiplayer-server for localhost usage:<br />
:<syntaxhighlight lang="bash">docker run -p5000:5000/udp -p5001:5001 flightgear/fgms:0.13.4</syntaxhighlight><br />
<br />
This starts fgms in local-lan mode, redirects the log to the console and exposes ports 5000 and 5001 to your local loopback network.<br />
To use your own fgms.conf, simply link it into the container like<br />
:<syntaxhighlight lang="bash">docker run -p5000:5000/udp -p5001:5001 -v /path/to/my/fgms.conf:/usr/local/etc/fgms.conf:ro flightgear/fgms:0.13.4</syntaxhighlight><br />
where /path/to/my/fgms.conf is the absolute path name of your fgms.conf. You MUST use absolute paths names.<br />
<br />
The docker image wraps the fgms binary so you can add any command line option that fgms accepts:<br />
<br />
:<syntaxhighlight lang="bash"><br />
$ docker run flightgear/fgms:0.13.4 -h<br />
fgms: version 0.13.4, compiled on Apr 13 2019, at 09:11:11<br />
<br />
options are:<br />
-h print this help screen<br />
-a PORT listen to PORT for telnet<br />
-c config read 'config' as configuration file<br />
-p PORT listen to PORT<br />
-t TTL Time a client is active while not sending packets<br />
-o OOR nautical miles two players must be apart to be out of reach<br />
-l LOGFILE Log to LOGFILE<br />
-v LEVEL verbosity (loglevel) in range 0 (few) and 4 (much). 5 to disable. (def=2)<br />
-d do _not_ run as a daemon (stay in foreground)<br />
-D do run as a daemon<br />
<br />
the default is to run as a daemon, which can be overridden in the<br />
config file.<br />
<br />
syntax: /usr/local/sbin/fgms options<br />
</syntaxhighlight><br />
<br />
<br />
== Setting up the config file ==<br />
<br />
At this point you should have a working 'fgms' binary in the build-fgms directory. If the server will be offline or for private use (i.e. LAN-only, please comment out the relay servers section. This will save bandwidth from the server being consumed.<br />
<br />
* Edit the fgms.conf file according to the instructions found elsewhere on this page, then save and close the file.<br />
<br />
{{cquote|As long as you are not absolutly sure what you are doing you should:<br />
- disable tracking<br />
- disable HUB setting<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}<br />
<br />
<br />
{{cquote|fgms will ignore traffic comming from unknown relays and since the multiplayer network is a star topology you should list only mpserver01<br />
as your only relay. Currently mpserver01 is the only HUB, Although multiple HUBs should work I have not tested a multi HUB environment yet.<br />
And for those interrested: Current traffic load on mpserver01 is around 10 MBit/s<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}<br />
<br />
{{cquote|your fgms.conf should look like:<br />
<pre><br />
# basic setting<br />
server.name = mpserver02<br />
server.port = 5000<br />
<br />
# you can telnet to this port with this username/password<br />
# and see statistics (nice cisco like CLI)<br />
server.admin_port = 6002<br />
server.admin_user = fred<br />
server.admin_pass = fred<br />
<br />
server.admin_enable = fred<br />
<br />
# mpserver01 does this<br />
server.tracked = false<br />
<br />
# mpserver01 is hub<br />
server.is_hub = false</pre><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}<br />
<br />
{{cquote|<pre># don't set this too high<br />
server.out_of_reach = 100<br />
<br />
# your only relay should be mpserver01<br />
relay.host = mpserver01.flightgear.org<br />
relay.port = 5000<br />
<br />
# you don't need a crossfeed, it's only interresting for fgms-developers<br />
# crossfeed.host = foo.example.com<br />
# crossfeed.port = 5002<br />
<br />
# you can add static entries of IPs which get blocked,<br />
# but it's generally not needed and you can add them via<br />
# the admin CLI<br />
# blacklist = 123.123.123.123</pre><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}<br />
<br />
== Running FGMS for the first time ==<br />
<br />
In addition to its configuration file, FGMS supports a number of configuration parameters that can be passed at startup (and that will by default override any configuration file settings), to get a summary of supported parameters, you may want to run:<br />
$ ./fgms --help<br />
<br />
Which should present you with the following output:<br />
<br />
<pre><br />
options are:<br />
-h print this help screen<br />
-a PORT listen to PORT for telnet<br />
-c config read 'config' as configuration file<br />
-p PORT listen to PORT<br />
-t TTL Time a client is active while not sending packets<br />
-o OOR nautical miles two players must be apart to be out of reach<br />
-l LOGFILE Log to LOGFILE<br />
-v LEVEL verbosity (loglevel) in range 1 (few) and 5 (much)<br />
-d do _not_ run as a daemon (stay in foreground)<br />
-D do run as a daemon<br />
<br />
the default is to run as a daemon, which can be overridden in the<br />
config file.<br />
commandline parameters always override config file options<br />
</pre><br />
<br />
After having finished the fgms configuration, you can try running fgms and start up fgfs to use the new server.<br />
=== Public Server ===<br />
If you'd like to make it a public server, you can simply use your external (public) IP address to set up the multiplayer in fgfs.<br />
<br />
For others to know about your public server you should notify the developers of the existence of your server by posting a message to the [[Mailing list|developers mailing list]].<br />
<br />
Add your server to this list: http://wiki.flightgear.org/Howto:Multiplayer#Servers<br />
<br />
== Related content ==<br />
* [http://fgms.freeflightsim.org/ Website: fgms.freeflightsim.org]<br />
* [[Howto: Multiplayer|Multiplayer howto]]<br />
* [[MPmap]]<br />
<br />
<references/><br />
<br />
[[Category:Howto]]<br />
[[Category:Multiplayer]]<br />
<br />
[[fr:Installer un serveur multijoueur]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=User:T3r&diff=108652User:T3r2017-06-28T20:42:49Z<p>T3r: some self praise</p>
<hr />
<div>{{User<br />
|name = T3r <br />
|location = near Hamburg, Germany, Europe<br />
|callsign = Torsten, D-GEJL, D-GOOF<br />
|favourite=[[Piper PA34-200T Seneca II]], [[Cessna C172]]<br />
|website =[http://www.t3r.de/ www.t3r.de]<br />
|age = constantly changing<br />
}}<br />
[[Image:T3r.jpg|Hey - that's me!]]<br />
<br />
Contact: '''Torsten''' (at) '''flightgear''' _dot_ '''org'''<br />
<br />
* '''Aircraft'''<br />
** [[Ogel]]<br />
** [[Piper PA34-200T Seneca II]]<br />
** [[Zivko Edge 540]]<br />
** [[Moyes Dragonfly]]<br />
** [[Hamburger Flugzeugbau HFB 320 Hansa Jet]]<br />
** [[Der Kleine Uhu]]<br />
* '''Scenery'''<br />
** Some buildings in my home town Hamburg <br />
** Buildings of my home base Lubeck (EDHL)<br />
** Some buildings of Lelystad (EHLE)<br />
** [https://scenery.flightgear.org/author.php?id=20 My scenemodels contribs]<br />
* '''Program'''<br />
** overhauled environment system<br />
** overhauled xml-autopilot system<br />
** overhauled the input system<br />
** added support for generic input devices (linux)<br />
** added the ridge lift from Patrice Poly<br />
** removed dozens of gcc warnings<br />
** overhauled the internal httpd to use mongoose httpd<br />
** added flite+hts_engine text-to-speech<br />
** overhauled the ATIS creation code<br />
** created the comm radio subsystem<br />
** created Phi<br />
** Check [http://www.ohloh.net/accounts/80410?ref=Detailed Ohloh] for commit timeline. <br />
* '''Hardware'''<br />
** Made some USB/HID input devices based on ATMega microcontroller<br />
** Built a FlightGear based [[Howto:_Build_your_own_procedure_trainer|Procedure Trainer]]<br />
* '''Wiki work'''<br />
**[http://wiki.flightgear.org/index.php/Special:Contributions/T3r T3r's wiki contributions]<br />
* '''Infrastructure'''<br />
** managing the [http://sf.net/p/flightgear SourceForge project page]<br />
** managing and hosts the [https://scenery.flightgear.org/ FG Scenery database and website]<br />
** managing the flightgear.org DNS domain for multiplayer server and TerraSync<br />
** managing the [http://build.flightgear.org:8080 build server]<br />
** somehow managing to get releases out every three month<br />
*'''What the hack means T3r?'''<br />
**That's the acronyme for my name, only decipherable if you speak the german language.<br />
<br />
----<br />
<br />
'''The genuine FlightGear flight simulator is at [http://www.flightgear.org/ www.flightgear.org]. Fly free.'''<br />
<br />
--[[User:T3r|T3r]] 10:33, 12 October 2010 (UTC)<br />
<br />
[[Category: FlightGear Core developers]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Talk:DNS&diff=105977Talk:DNS2016-11-18T08:02:30Z<p>T3r: Answer to Hooray</p>
<hr />
<div>== Page name ==<br />
What is the rationale to copy the content of my original page "Dns" to the uppercase variant of "DNS"?<br />
<br />
{{unsigned|13:01, November 14, 2016|T3r}}<br />
<br />
Sorry for leaving my comment unintentionally unsigned. My wiki skills are a little rusted.<br />
<br />
[[User:T3r|T3r]] ([[User talk:T3r|talk]]) 10:23, 14 November 2016 (EST)<br />
<br />
: Obviously, it was far from unmaintained- in fact, it received more edits than the version you started (and also contained more information). The motivation (as stated in the edit logs) was to fork your article (to prevent edit warring), because we obviously disagreed regarding the contents to be added, i.e. so that we can maintain a copy until your article actually contains a similar degree of information, I've restored the copy elsewhere. Otherwise, there simply is a significant disparity between the degree of information available in the archives and what we make available in the wiki. Actually, it was a rather bold move to simply delete my work and hijack its title without properly discussing this with fellow wiki admins first. If others had done this to articles documenting your work, there would be hardly any useful information left here - as a matter of fact, I don't think the [[Phi]] article contains even a single edit made by you, despite containing tons of content you posted via the devel list. Thus, I would politely suggest to tread more carefully here. We don't need to make this a virtual peeing contest. Thank you. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:04, 17 November 2016 (EST)<br />
<br />
The number of edits is not a measure for the quality of content. Against my clearly stated intention on the ML (which should be known by you as you quoted many posts from that thread) you bloated this article with useless quotes, some of them belonging more to multiplayer than to DNS. This leaves the question who was hijacking the article.<br />
With all due respect, my I kindly ask to stay out of my way and not touch articles I actively working on?<br />
Thank you.<br />
[[User:T3r|T3r]] ([[User talk:T3r|talk]]) 03:01, 18 November 2016 (EST)</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Dns&diff=105960Dns2016-11-17T15:06:37Z<p>T3r: T3r moved page Dns to DNS: Uppercase for acronyms</p>
<hr />
<div>#REDIRECT [[DNS]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=DNS&diff=105959DNS2016-11-17T15:06:37Z<p>T3r: T3r moved page Dns to DNS: Uppercase for acronyms</p>
<hr />
<div>== Usage of DNS within FlightGear ==<br />
<br />
The {{wikipedia|Domain Name System}} (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.<br />
This page documents the used services in detail.<br />
<br />
== FlightGear systems using DNS ==<br />
Currently, (as of version 2016.4.0) these systems use DNS for service discovery:<br />
* The TerraSync client to find a TerraSync server<br />
* The [[Multiplayer|multiplayer]] client to list [[Howto:Set up a multiplayer server|multiplayer servers]] and retrieve information about each server<br />
<br />
=== TerraSync ===<br />
The TerraSync client queries {{Wikipedia|NAPTR record|NAPTR records}} for the DNS name <code>terrasync.flightgear.org</code>. As of version 2016.4, the configured entries are:<br />
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://mpserver16.flightgear.org/scenery!" .<br />
<br />
At system start, FlightGear sends a query for the DNS name <code>terrasync.flightgear.org</code>. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with <code>!^.*$!</code> and must end with <code>!</code>, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken.<br />
The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".<br />
<br />
==== Algorithm to pick a Server ====<br />
* At startup, if TerraSync is enabled and if the property /sim/terrasync/http-server is set to "automatic" (the default), a DNS query for terrasync.flightgear.org is sent and the response filtered for entries with the flag field set to "U". <br />
* All entries that have a "order" value higher than the lowest order are discarded. (currently the sourceforge entry)<br />
* The remaining entries are filtered for those with the lowest preference. (both other entries survive this filter)<br />
* a random entry from the remaining list is picked for the entire session of FlightGear.<br />
This is implemented in <code>SGTerraSync::WorkerThread::run()</code> {{simgear source|simgear/scene/tsync/terrasync.cxx|l=441|t=here}}.<br />
<br />
The property /sim/terrasync/http-server can be set to user defined URL pointing to the location of a custom TerraSync server e.g. <code>http://myterrasync.org/custom-scenery</code>.<br />
This will disable the above algorithm.<br />
<br />
=== Multiplayer ===<br />
Expanding the use of DNS to multiplayer resulted from a discussion at fsweekend 2016 followed by a discussion on the mailing list. <ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35475777/ <br />
|title = <nowiki>[Flightgear-devel] Proposal for storing the mp server information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 7th, 2016 <br />
|added = Nov 7th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
Multiplayer discovery via DNS is an experimental feature found in FlightGear branch [https://sourceforge.net/p/flightgear/flightgear/ci/next/~/tree/ next]. It will be released with version 2017.1.1<br />
<br />
The multiplayer client queries {{Wikipedia|SRV record|SRV records}} for a list of multiplayer servers and {{Wikipedia|TXT record|TXT records}} on each server for detailed information about the server.<br />
<br />
The SRV record for a multiplayer server looks like this:<br />
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code><br />
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance (usually 5001). The port number is 0 (zero) for inactive servers.<br />
<br />
The TXT record for each referenced multiplayer server looks like this:<br />
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="<br />
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.<br />
For the given example, the base64 string of <br />
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= <br />
decodes to<br />
{"name":"mpserver01","location":"Frankfurt,Germany"}<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Core development projects]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=DNS&diff=105958DNS2016-11-17T15:04:16Z<p>T3r: /* Multiplayer */</p>
<hr />
<div>== Usage of DNS within FlightGear ==<br />
<br />
The {{wikipedia|Domain Name System}} (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.<br />
This page documents the used services in detail.<br />
<br />
== FlightGear systems using DNS ==<br />
Currently, (as of version 2016.4.0) these systems use DNS for service discovery:<br />
* The TerraSync client to find a TerraSync server<br />
* The [[Multiplayer|multiplayer]] client to list [[Howto:Set up a multiplayer server|multiplayer servers]] and retrieve information about each server<br />
<br />
=== TerraSync ===<br />
The TerraSync client queries {{Wikipedia|NAPTR record|NAPTR records}} for the DNS name <code>terrasync.flightgear.org</code>. As of version 2016.4, the configured entries are:<br />
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://mpserver16.flightgear.org/scenery!" .<br />
<br />
At system start, FlightGear sends a query for the DNS name <code>terrasync.flightgear.org</code>. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with <code>!^.*$!</code> and must end with <code>!</code>, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken.<br />
The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".<br />
<br />
==== Algorithm to pick a Server ====<br />
* At startup, if TerraSync is enabled and if the property /sim/terrasync/http-server is set to "automatic" (the default), a DNS query for terrasync.flightgear.org is sent and the response filtered for entries with the flag field set to "U". <br />
* All entries that have a "order" value higher than the lowest order are discarded. (currently the sourceforge entry)<br />
* The remaining entries are filtered for those with the lowest preference. (both other entries survive this filter)<br />
* a random entry from the remaining list is picked for the entire session of FlightGear.<br />
This is implemented in <code>SGTerraSync::WorkerThread::run()</code> {{simgear source|simgear/scene/tsync/terrasync.cxx|l=441|t=here}}.<br />
<br />
The property /sim/terrasync/http-server can be set to user defined URL pointing to the location of a custom TerraSync server e.g. <code>http://myterrasync.org/custom-scenery</code>.<br />
This will disable the above algorithm.<br />
<br />
=== Multiplayer ===<br />
Expanding the use of DNS to multiplayer resulted from a discussion at fsweekend 2016 followed by a discussion on the mailing list. <ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35475777/ <br />
|title = <nowiki>[Flightgear-devel] Proposal for storing the mp server information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 7th, 2016 <br />
|added = Nov 7th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
Multiplayer discovery via DNS is an experimental feature found in FlightGear branch [https://sourceforge.net/p/flightgear/flightgear/ci/next/~/tree/ next]. It will be released with version 2017.1.1<br />
<br />
The multiplayer client queries {{Wikipedia|SRV record|SRV records}} for a list of multiplayer servers and {{Wikipedia|TXT record|TXT records}} on each server for detailed information about the server.<br />
<br />
The SRV record for a multiplayer server looks like this:<br />
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code><br />
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance (usually 5001). The port number is 0 (zero) for inactive servers.<br />
<br />
The TXT record for each referenced multiplayer server looks like this:<br />
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="<br />
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.<br />
For the given example, the base64 string of <br />
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= <br />
decodes to<br />
{"name":"mpserver01","location":"Frankfurt,Germany"}<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Core development projects]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Talk:DNS&diff=105877Talk:DNS2016-11-14T15:24:09Z<p>T3r: </p>
<hr />
<div>== Page name ==<br />
What is the rationale to copy the content of my original page "Dns" to the uppercase variant of "DNS"?<br />
<br />
{{unsigned|13:01, November 14, 2016|T3r}}<br />
<br />
Sorry for leaving my comment unintentionally unsigned. My wiki skills are a little rusted.<br />
<br />
[[User:T3r|T3r]] ([[User talk:T3r|talk]]) 10:23, 14 November 2016 (EST)</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Talk:DNS&diff=105873Talk:DNS2016-11-14T13:01:56Z<p>T3r: Created page with "What is the rationale to copy the content of my original page "Dns" to the uppercase variant of "DNS"?"</p>
<hr />
<div>What is the rationale to copy the content of my original page "Dns" to the uppercase variant of "DNS"?</div>T3rhttps://wiki.flightgear.org/w/index.php?title=DNS&diff=105872DNS2016-11-14T12:57:00Z<p>T3r: TS: refer to the ml discussion, link in the branch and commit.</p>
<hr />
<div>== Usage of DNS within FlightGear ==<br />
<br />
The {{wikipedia|Domain Name System}} (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.<br />
This page documents the used services in detail.<br />
<br />
== FlightGear systems using DNS ==<br />
Currently, (as of version 2016.4.0) these systems use DNS for service discovery:<br />
* The TerraSync client to find a TerraSync server<br />
* The [[Multiplayer|multiplayer]] client to list [[Howto:Set up a multiplayer server|multiplayer servers]] and retrieve information about each server<br />
<br />
=== TerraSync ===<br />
The TerraSync client queries {{Wikipedia|NAPTR record|NAPTR records}} for the DNS name <code>terrasync.flightgear.org</code>. As of version 2016.4, the configured entries are:<br />
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://mpserver16.flightgear.org/scenery!" .<br />
<br />
At system start, FlightGear sends a query for the DNS name <code>terrasync.flightgear.org</code>. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with <code>!^.*$!</code> and must end with <code>!</code>, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken.<br />
The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".<br />
<br />
==== Algorithm to pick a Server ====<br />
* At startup, if TerraSync is enabled and if the property /sim/terrasync/http-server is set to "automatic" (the default), a DNS query for terrasync.flightgear.org is sent and the response filtered for entries with the flag field set to "U". <br />
* All entries that have a "order" value higher than the lowest order are discarded. (currently the sourceforge entry)<br />
* The remaining entries are filtered for those with the lowest preference. (both other entries survive this filter)<br />
* a random entry from the remaining list is picked for the entire session of FlightGear.<br />
This is implemented in <code>SGTerraSync::WorkerThread::run()</code> {{simgear source|simgear/scene/tsync/terrasync.cxx|l=441|t=here}}.<br />
<br />
The property /sim/terrasync/http-server can be set to user defined URL pointing to the location of a custom TerraSync server e.g. <code>http://myterrasync.org/custom-scenery</code>.<br />
This will disable the above algorithm.<br />
<br />
=== Multiplayer ===<br />
Expanding the use of DNS to multiplayer resulted from a discussion at fsweekend 2016 followed by a discussion on the mailing list. <ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35475777/ <br />
|title = <nowiki>[Flightgear-devel] Proposal for storing the mp server information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 7th, 2016 <br />
|added = Nov 7th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
Multiplayer discovery via DNS is an experimental feature found in FlightGear branch [https://sourceforge.net/p/flightgear/flightgear/ci/topics/mpdiscovery-via-dns/~/tree/ topics/mp-discovery-via-dns], the relevant commit is [https://sourceforge.net/p/flightgear/flightgear/ci/979010de4d3ef0116c49a1e8acb15d1b22bdf479/ 979010].<br />
<br />
The multiplayer client queries {{Wikipedia|SRV record|SRV records}} for a list of multiplayer servers and {{Wikipedia|TXT record|TXT records}} on each server for detailed information about the server.<br />
<br />
The SRV record for a multiplayer server looks like this:<br />
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code><br />
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance (usually 5001). The port number is 0 (zero) for inactive servers.<br />
<br />
The TXT record for each referenced multiplayer server looks like this:<br />
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="<br />
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.<br />
For the given example, the base64 string of <br />
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= <br />
decodes to<br />
{"name":"mpserver01","location":"Frankfurt,Germany"}<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Core development projects]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=DNS&diff=105864DNS2016-11-13T20:40:21Z<p>T3r: Remove mailing list quotes without information content for this page.</p>
<hr />
<div>== Usage of DNS within FlightGear ==<br />
<br />
The {{wikipedia|Domain Name System}} (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.<br />
This page documents the used services in detail<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35483751/ <br />
|title = <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server<br />
information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 10th, 2016 <br />
|added = Nov 10th, 2016 <br />
|script_version = 0.40 <br />
}}</ref>.<br />
<br />
== FlightGear systems using DNS ==<br />
Currently, (as of version 2016.4.0) these systems use DNS for service discovery:<br />
* The TerraSync client to find a TerraSync server<br />
* The [[Multiplayer|multiplayer]] client to list [[Howto:Set up a multiplayer server|multiplayer servers]] and retrieve information about each server<br />
<br />
=== TerraSync ===<br />
The TerraSync client queries {{Wikipedia|NAPTR record|NAPTR records}} for the DNS name <code>terrasync.flightgear.org</code>. As of version 2016.4, the configured entries are:<br />
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://mpserver16.flightgear.org/scenery!" .<br />
<br />
At system start, FlightGear sends a query for the DNS name <code>terrasync.flightgear.org</code>. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with <code>!^.*$!</code> and must end with <code>!</code>, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken.<br />
The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".<br />
<br />
==== Algorithm to pick a Server ====<br />
* At startup, if TerraSync is enabled and if the property /sim/terrasync/http-server is set to "automatic" (the default), a DNS query for terrasync.flightgear.org is sent and the response filtered for entries with the flag field set to "U". <br />
* All entries that have a "order" value higher than the lowest order are discarded. (currently the sourceforge entry)<br />
* The remaining entries are filtered for those with the lowest preference. (both other entries survive this filter)<br />
* a random entry from the remaining list is picked for the entire session of FlightGear.<br />
This is implemented in <code>SGTerraSync::WorkerThread::run()</code> {{simgear source|simgear/scene/tsync/terrasync.cxx|l=441|t=here}}.<br />
<br />
The property /sim/terrasync/http-server can be set to user defined URL pointing to the location of a custom TerraSync server e.g. <code>http://myterrasync.org/custom-scenery</code>.<br />
This will disable the above algorithm.<br />
<br />
=== Multiplayer ===<br />
The multiplayer client queries {{Wikipedia|SRV record|SRV records}} for a list of multiplayer servers and {{Wikipedia|TXT record|TXT records}} on each server for detailed information about the server.<br />
<br />
The SRV record for a multiplayer server looks like this:<br />
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code><br />
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance. The port number is zero for inactive servers.<br />
<br />
The TXT record for each referenced multiplayer server looks like this:<br />
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="<br />
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.<br />
For the given example, the base64 string of <br />
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= <br />
decodes to<br />
{"name":"mpserver01","location":"Frankfurt,Germany"}<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Core development projects]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=DNS&diff=105767DNS2016-11-10T19:44:22Z<p>T3r: /* TerraSync algorithm */</p>
<hr />
<div>== Status ==<br />
Torsten created a branch [https://sourceforge.net/p/flightgear/flightgear/ci/topics/mpdiscovery-via-dns/~/tree/ topics/mpdiscovery-via-dns] with a first implementation - just in case somebody might want to have a look. It does contain full lookup of a server list by checking the SRV records and each server's properties via TXT records with name=value text and value being a b64 encoded JSON string. It does not /yet/ contain a "is-online" check.<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35482909/ <br />
|title = <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server<br />
information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 10th, 2016 <br />
|added = Nov 10th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
The latter being considered to be implemented using UDP ‘ping’, i.e. because we can include some interesting info in it.<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35483816/ <br />
|title = <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server<br />
information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> James Turner </nowiki> <br />
|date = Nov 10th, 2016 <br />
|added = Nov 10th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
== Usage of DNS within FlightGear ==<br />
<br />
[https://en.wikipedia.org/wiki/Domain_Name_System The Domain Name System] (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.<br />
This page documents the used services in detail<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35483751/ <br />
|title = <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server<br />
information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 10th, 2016 <br />
|added = Nov 10th, 2016 <br />
|script_version = 0.40 <br />
}}</ref>.<br />
<br />
Its creation was inspired by a discussion that took place on the FlightGear devel mailing list in 11/2016 to stop using a dedicated web service for retrieving a list of active multiplayer servers and instead use DNS <ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35482909/ <br />
|title = <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server<br />
information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 10th, 2016 <br />
|added = Nov 10th, 2016 <br />
|script_version = 0.40 <br />
}}</ref>.<br />
<br />
== FlightGear systems using DNS ==<br />
Currently, (as of version 2016.4.0) these systems use DNS for service discovery:<br />
* The TerraSync client to find a TerraSync server<br />
* The [[Multiplayer|multiplayer]] client to list [[Howto:Set up a multiplayer server|multiplayer servers]] and retrieve information about each server<br />
<br />
=== TerraSync ===<br />
The TerraSync client queries {{Wikipedia|NAPTR record}}s for the DNS name <code>terrasync.flightgear.org</code>. As of version 2016.4, the configured entries are:<br />
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://mpserver16.flightgear.org/scenery!" .<br />
<br />
At system start, FlightGear sends a query for the DNS name <code>terrasync.flightgear.org</code>. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with <code>!^.*$!</code> and must end with <code>!</code>, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken.<br />
The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".<br />
<br />
==== Algorithm to pick a Server ====<br />
* At startup, if TerraSync is enabled and if the property /sim/terrasync/http-server is set to "automatic" (the default), a DNS query for terrasync.flightgear.org is sent and the response filtered for entries with the flag field set to "U". <br />
* All entries that have a "order" value higher than the lowest order are discarded. (currently the sourceforge entry)<br />
* The remaining entries are filtered for those with the lowest preference. (both other entries survive this filter)<br />
* a random entry from the remaining list is picked for the entire session of FlightGear.<br />
This is implemented in <code>SGTerraSync::WorkerThread::run()</code> [https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/scene/tsync/terrasync.cxx#l441 here].<br />
<br />
The property /sim/terrasync/http-server can be set to user defined URL pointing to the location of a custom TerraSync server e.g. <code>http://myterrasync.org/custom-scenery</code>.<br />
This will disable the above algorithm.<br />
<br />
=== Multiplayer ===<br />
The multiplayer client queries {{Wikipedia|SRV record}}s for a list of multiplayer servers and {{Wikipedia|TXT record}}s on each server for detailed information about the server.<br />
<br />
The SRV record for a multiplayer server looks like this:<br />
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code><br />
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance. The port number is zero for inactive servers.<br />
<br />
The TXT record for each referenced multiplayer server looks like this:<br />
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="<br />
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.<br />
For the given example, the base64 string of <br />
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= <br />
decodes to<br />
{"name":"mpserver01","location":"Frankfurt,Germany"}<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Core development projects]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=DNS&diff=105762DNS2016-11-10T19:26:08Z<p>T3r: terrasync dns name is not settable</p>
<hr />
<div>== Usage of DNS within FlightGear ==<br />
<br />
[https://en.wikipedia.org/wiki/Domain_Name_System The Domain Name System] (DNS) is being used within FlightGear to look up resources providing several services. Its use started with release [[Changelog 2016.2|2016.2.1]] as an experimental feature to resolve the location of the [[TerraSync]] servers.<br />
This page documents the used services in detail<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35483751/ <br />
|title = <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server<br />
information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 10th, 2016 <br />
|added = Nov 10th, 2016 <br />
|script_version = 0.40 <br />
}}</ref>.<br />
<br />
Its creation was inspired by a discussion that took place on the FlightGear devel mailing list in 11/2016 to stop using a dedicated web service for retrieving a list of active multiplayer servers and instead use DNS <ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35482909/ <br />
|title = <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server<br />
information in DNS instead of a web service </nowiki> <br />
|author = <nowiki> Torsten Dreyer </nowiki> <br />
|date = Nov 10th, 2016 <br />
|added = Nov 10th, 2016 <br />
|script_version = 0.40 <br />
}}</ref>.<br />
<br />
== FlightGear systems using DNS ==<br />
Currently, (as of version 2016.4.0) these systems use DNS for service discovery:<br />
* The TerraSync client to find a TerraSync server<br />
* The [[Multiplayer|multiplayer]] client to list [[Howto:Set up a multiplayer server|multiplayer servers]] and retrieve information about each server<br />
<br />
=== TerraSync ===<br />
The TerraSync client queries {{Wikipedia|NAPTR record}}s for the DNS name <code>terrasync.flightgear.org</code>. As of version 2016.4, the configured entries are:<br />
* terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .<br />
* terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://mpserver16.flightgear.org/scenery!" .<br />
<br />
At system start, FlightGear sends a query for the DNS name <code>terrasync.flightgear.org</code>. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with <code>!^.*$!</code> and must end with <code>!</code>, the regex itself is not interpreted by the TerraSync client, only the fixed string is taken.<br />
The DNS to query is currently not configurable at system start by setting a property. The version number can be changed by setting property /sim/terrasync/scenery-version to a value other than the default "ws20".<br />
<br />
<br />
=== Multiplayer ===<br />
The multiplayer client queries {{Wikipedia|SRV record}}s for a list of multiplayer servers and {{Wikipedia|TXT record}}s on each server for detailed information about the server.<br />
<br />
The SRV record for a multiplayer server looks like this:<br />
<code>_fgms._udp IN SRV 10 20 5001 mpserver01</code><br />
All entries currently use the same values for priority and weight. The port numbers for active servers are set to the port number of the running fgms instance. The port number is zero for inactive servers.<br />
<br />
The TXT record for each referenced multiplayer server looks like this:<br />
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="<br />
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.<br />
For the given example, the base64 string of <br />
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= <br />
decodes to<br />
{"name":"mpserver01","location":"Frankfurt,Germany"}<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Core development projects]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=DNS&diff=105754DNS2016-11-10T16:52:36Z<p>T3r: Documentation of DNS usage</p>
<hr />
<div>== Usage of DNS within FlightGear ==<br />
<br />
[https://en.wikipedia.org/wiki/Domain_Name_System The Domain Name System] (DNS) is being used within FlightGear to lookup resources providing several services. It's use started with release 2016.2.1 as an experimental feature to resolve the location of the terrasync servers.<br />
This page documents the used services in detail.<br />
<br />
== FlightGear systems using DNS ==<br />
Currently (as of version 2016.4.0) these systems use DNS for service discovery:<br />
* The terrasync client to find a terrasync server<br />
* The multiplayer client to list multiplayer servers and retrieve information about each server<br />
<br />
=== Terrasync ===<br />
The terrasync client queries [https://en.wikipedia.org/wiki/NAPTR_record NAPTR] records for the dns name terrasync.flightgear.org. As of version 2016.4 the configured entries are<br />
terrasync.flightgear.org. IN NAPTR 100 100 "U" "ws20" "!^.*$!http://flightgear.sourceforge.net/scenery!" .<br />
terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://fgfs.goneabitbursar.com/terrascenery!" .<br />
terrasync.flightgear.org. IN NAPTR 100 50 "U" "ws20" "!^.*$!http://mpserver16.flightgear.org/scenery!" .<br />
<br />
At system start, FlightGear sends a query for the dns name terrasync.flightgear.org. The URL for scenery download is encoded in the regex field between the last two exclamation marks. This string MUST start with !^.*$! and end with !, the regex itself is not interpreted by the terrasync client, only the fixed string is taken.<br />
The hostname to query is configurable at system start by setting a property, so is the scenery version number. The default scenery version is "ws20".<br />
<br />
<br />
=== Multiplayer ===<br />
The multiplayer client queries [https://en.wikipedia.org/wiki/SRV_record SRV] records for a list of multiplayer servers and [https://en.wikipedia.org/wiki/TXT_record TXT] records on each server for detailed information about the server.<br />
<br />
The SRV record for a multiplayer server looks like this:<br />
_fgms._udp IN SRV 10 20 5001 mpserver01<br />
All entries currently use the same values for priority and weight. The port number for active servers are set to the port number of the running fgms instance. The port number is zero for inactive servers.<br />
<br />
The TXT record for each referenced multiplayer server looks like this:<br />
mpserver01 IN TXT "flightgear-mpserver=eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo="<br />
with the text data used as in [https://tools.ietf.org/html/rfc1464 RFC 1464 - Using the Domain Name System To Store Arbitrary String Attributes]. The attribute name flightgear-mpserver marks this entry as "ours" while it's attribute value is a base64 encoded json string containing additional attributes for the server not available within the SRV record.<br />
For the given example, the base64 string of <br />
eyJuYW1lIjoibXBzZXJ2ZXIwMSIsImxvY2F0aW9uIjoiRnJhbmtmdXJ0LEdlcm1hbnkifQo= <br />
decodes to<br />
{"name":"mpserver01","location":"Frankfurt,Germany"}</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Tutorials&diff=96176Tutorials2016-03-23T10:23:43Z<p>T3r: New location for marker.xml</p>
<hr />
<div><br />
{{infobox subsystem<br />
<!--<br />
|image =Missionb.png<br />
--><br />
|name =Tutorials<br />
|started= 01/2011 <br />
|description = Interactive Tutorials<br />
|status = Under active development as of 04/2014<br />
|developers = Stuart, Marius_A (since 04/2014), DFaber (04/2014) [http://forum.flightgear.org/viewtopic.php?f=6&t=22698&p=206575#p206551]<br />
|topic-fgdata= soon<br />
}}<br />
<br />
{{Tutorials Navigation}}<br />
{{Checklists}}<br />
<br />
[[FlightGear]] offers a flexible '''tutorial''' system, entirely written in the [[Nasal]] scripting language.<br />
Aircraft that provide support for these scripted tutorials can be found in [[:Category:Interactive Tutorial Support]].<br />
<br />
== News ==<br />
[[FlightGear Missions and Adventures]]<br />
<br />
{{#ev:youtube|yWEyRVGJks0}}<br />
<br />
Continue reading at [http://forum.flightgear.org/viewtopic.php?f=6&t=22598 "Mission" for helicopters]...<br />
<br />
== Interfacing Tutorials to web sites ==<br />
To learn more about interfacing FlightGear to web sites (without having to go through the multiplayer protocol) by making HTTP requests via Nasal, please see this tutorial: <br />
[[Howto:Making HTTP Requests from Nasal]].<br />
<br />
== Supporting Checklists ==<br />
As of V2.9.0, FlightGear can display aircraft checklists in a standardized way, under Help->Aircraft Checklists.<br />
<br />
Checklists are situated under /sim/checklists. <br />
Please see [[Aircraft Checklists]].<br />
<br />
Also see: http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170386#p170386<br />
<br />
== Some Background Info ==<br />
<br />
The tutorial system itself was largely developed by Stuart.<br />
<br />
In recent FGDATA, the Nasal "tutorial" module has become a so called "Nasal sub module", which means that the "tutorial.nas" module now resides in its own sub folder inside {{fg root file|Nasal}}: {{fgdata url|Nasal/tutorial}}.<br />
<br />
Support for Nasal sub modules was added by ThorstenB. Modules loaded as Nasal sub modules do automatically support reloading, because they are loaded via a listener.<br />
<br />
Please see the Nasal documentation on sub modules for details: [[Nasal#Nasal sub modules]].<br />
<br />
Regarding suggested coding practices, you should check out: [[Nasal scripting language#Memory management]] and [[Nasal#Managing timers and listeners]].<br />
<br />
To learn more about translating tutorials, please see: http://forum.flightgear.org/viewtopic.php?f=42&t=16876&p=164407&hilit=tutorials#p164407<br />
<br />
== Missions & Adventures ==<br />
<br />
{{WIP}}<br />
<br />
* http://forum.flightgear.org/viewtopic.php?f=19&t=22618<br />
* http://forum.flightgear.org/viewtopic.php?f=6&t=20747&p=189541<br />
* http://forum.flightgear.org/viewtopic.php?f=5&t=8927&p=88248&hilit=missions+tutorials#p88248<br />
* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170386&hilit=missions+tutorials#p170386<br />
* http://forum.flightgear.org/viewtopic.php?f=3&t=18240&p=170125&hilit=missions+tutorials#p170125<br />
* http://forum.flightgear.org/viewtopic.php?f=6&t=16192&p=156393&hilit=missions+tutorials#p156393<br />
* http://flightgear.org/forums/search.php?st=0&sk=t&sd=d&sr=posts&keywords=missions+adventures<br />
* http://flightgear.org/forums/search.php?st=0&sk=t&sd=d&sr=posts&keywords=missions+tutorials<br />
* http://flightgear.org/forums/search.php?st=0&sk=t&sd=d&sr=posts&keywords=adventures+tutorials<br />
<br />
== Reloading XML tutorials at runtime ==<br />
<br />
tutorial.nas module is loaded via a listener ("/nasal/tutorial/loaded").<br />
See line 28-37 of tutorial.nas in [[$FG_ROOT]]/Nasal/tutorial to see how this is done.<br />
<br />
Before you can actually reload a tutorial, you must first of all STOP it.<br />
Please see line 112-122 of tutorial.nas in [[$FG_ROOT]]/Nasal/tutorial.<br />
<br />
Once you have stopped all running tutorials, you can reload the corresponding tutorial.<br />
Please see line 477-480 of tutorial.nas in [[$FG_ROOT]]/Nasal/tutorial to see how this is done.<br />
<br />
Basically, you should be able to come up with your own "reload" function by combining the stop() and the load() functions and adding a new "reload" function to tutorial.nas:<br />
<syntaxhighlight lang="nasal"><br />
var reload = func(filename,slot) stopTutorial() and load(filename,slot);<br />
</syntaxhighlight><br />
<br />
Also, see line 450-463 of tutorial.nas in [[$FG_ROOT]]/Nasal/tutorial to see how the namespace is initialized.<br />
For additional information on namespace, I suggest to have a look at: [[Namespaces and Methods]]<br />
<br />
== Using tutorials ==<br />
<br />
Tutorials can be started and stopped from the "Help" [[menubar|menu]]. They are defined in XML files. Each of them has to be loaded into <tt>/sim/tutorials/</tt> under a separate <tt>tutorial[n]/</tt> branch:<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<tutorials><br />
<tutorial include="Tutorials/take-off.xml"/><br />
<tutorial include="Tutorials/landing.xml"/><br />
<tutorial include="/Missions/oilrig-landing.xml"/><br />
</tutorial><br />
</sim><br />
</syntaxhighlight><br />
<br />
Alternatively, all tutorials can be defined in a single file, with <tt><tutorial></tt> tags around each tutorial. This is then included like so:<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<tutorials include="foo-tutorials.xml"/><br />
</sim><br />
</syntaxhighlight><br />
<br />
== Structure ==<br />
A tutorial has this structure, where some of the elements are described in detail below:<br />
<br />
<syntaxhighlight lang="xml"><br />
<tutorial><br />
<name>...</name> mandatory; short identifier, also shown in the<br />
tutorial selection dialog<br />
<description>...</description> mandatory; longer description for the dialog<br />
<audio-dir>...</audio-dir> optional; defines where to load sound samples<br />
<interval>5</interval> optional; defines default loop interval in sec<br />
<step-time>...</step-time> optional; time between tutorial steps in sec<br />
<exit-time>...</exit-time> optional; time between fulfillment of steps in sec<br />
<timeofday>noon</timeofday> optional; defines daytime; any of "dawn",<br />
"morning", "noon", "afternoon",<br />
"evening", "dusk", "midnight", "real"<br />
<nasal><br />
... optional; initial Nasal code; see below<br />
</nasal><br />
<br />
<models><br />
... optional; scenery objects; see below<br />
</models><br />
<br />
<targets><br />
... optional; targets; see below<br />
</targets><br />
<br />
<presets><br />
... optional; initial simulator state; see below<br />
</presets><br />
<br />
<br />
<init> optional; initial settings; see below<br />
<set><br />
... optional; property settings; allowed multiple<br />
</set> times<br />
<view><br />
... optional; view settings<br />
</view><br />
<marker><br />
... optional; marker coordinates<br />
</marker><br />
<nasal><br />
... optional; Nasal code<br />
</nasal><br />
<interval>10</inteval> optional; run loop next in this many seconds<br />
</init> (default: 5); doesn't change global<br />
interval<br />
<br />
<br />
<step> mandatory; well, not really, but if there's not<br />
at least one <step>, then the whole tutorial<br />
won't do anything; see below for details<br />
<br />
<message>...</message> optional; message to be displayed/spoken when<br />
<step> is entered; allowed multiple times, in<br />
which case one is chosen at random<br />
<br />
<audio>...</audio> optional; file name of *.wav sample to be played;<br />
may be used multiple times (random)<br />
<set><br />
... optional; allowed several times<br />
</set><br />
<view><br />
... optional<br />
</view><br />
<marker><br />
... optional<br />
</marker><br />
<nasal><br />
... optional; Nasal code that is executed when the<br />
</nasal> step is entered<br />
<br />
<interval>10</inteval> optional; run loop next in this many seconds<br />
<br />
<error> optional; allowed several times<br />
<message>..</message> optional; text displayed/spoken<br />
<audio>...</audio> optional; name of *.wav sample to be played<br />
<br />
<condition><br />
... optional, but one should be there to make sense<br />
</condition> see [[$FG_ROOT]]/Docs/README.conditions<br />
<br />
<nasal><br />
... optional; Nasal code that is executed when the<br />
</nasal> error condition was fulfilled<br />
<br />
<interval>10</inteval> optional; run loop next in this many seconds<br />
</error><br />
<br />
<exit> optional; defines when to leave this <step><br />
<condition> see [[$FG_ROOT]]/Docs/README.conditions<br />
...<br />
</condition><br />
<br />
<nasal><br />
... optional; Nasal code that is executed when the<br />
</nasal> exit condition was met<br />
</exit><br />
</step><br />
<br />
<br />
<end> optional; final settings & actions; see below<br />
<message>...</message> optional; multiple times (random)<br />
<audio>...</audio> optional; multiple times (random)<br />
<set><br />
... optional<br />
</set><br />
<view><br />
... optional<br />
</view><br />
<nasal><br />
... optional<br />
</nasal><br />
</end><br />
</tutorial><br />
</syntaxhighlight><br />
<br />
After the tutorial has finished its initialization, it goes through all <steps>. For each, it outputs the <message> or <audio>, optionally sets a <marker> and/or a <view>, then it checks all <error>s and, if an <error><condition> is fulfilled, outputs the respective <error><message>. If none of the <error>s occurred, then it checks if the <exit><condition> is true, and if so, it jumps to the next <step>. Otherwise the current <step> is endlessly repeated. Finally, after all <step>s were processed, the <end> group is executed.<br />
<br />
== Elements ==<br />
=== Nasal ===<br />
Embedded Nasal code is supported on the top level, in <init> in each <step>, in a <step>'s <error> and <exit>, and in <end>. All Nasal runs in a separate namespace __tutorial, so it's possible to define a function in the <init>'s Nasal block, and to use this function in other blocks without prefix. The namespace is preloaded with some functions:<br />
<br />
<br />
next([n=1]) ... to switch n <step>s forward<br />
previous([n=1]) ... to switch n <step>s backwards<br />
<br />
say(what [, who="copilot [, delay=0]])<br />
... says 'what' with voice 'copilot' after 'delay' seconds<br />
<br />
<br />
A Nasal group looks like this:<br />
<br />
<syntaxhighlight lang="xml"><br />
<nasal><br />
<script><br />
say("Hi, I'm the pilot!", "pilot");<br />
</script><br />
<module>__tutorial</module> optional; preset with __tutorial<br />
</nasal><br />
</syntaxhighlight><br />
<br />
=== Models ===<br />
This loads models into the scenery. It can be used to place, for example, a helicopter landing pad at an airport where normally none is, so that the tutorial can train landing. The layout is the following, with <path> being relative to [[$FG_ROOT]]:<br />
<br />
<syntaxhighlight lang="xml"><br />
<models><br />
<model><br />
<path>Models/Airport/supacat_winch.ac</path> mandatory<br />
<longitude-deg>-122.4950109</longitude-deg> mandatory<br />
<latitude-deg>37.51403798</latitude-deg> mandatory<br />
<elevation-ft>51</elevation-ft> mandatory<br />
<heading-deg>2.488888979</heading-deg> optional (default: 0)<br />
<pitch-deg>0</pitch-deg> optional (default: 0)<br />
<roll-deg>0</roll-deg> optional (default: 0)<br />
</model><br />
<br />
<model><br />
... another model<br />
</model><br />
</models><br />
</syntaxhighlight><br />
<br />
The models are only removed before a new tutorial is loaded. Otherwise they remain in the scenery for the whole FlightGear session. They aren't permanently added.<br />
<br />
=== Targets ===<br />
These are simple pairs of longitude/latitude under an arbitrary name (here "hospital" and "helipad"):<br />
<br />
<syntaxhighlight lang="xml"><br />
<targets><br />
<hospital><br />
<longitude-deg>-122.4950109</longitude-deg> mandatory<br />
<latitude-deg>37.51403798</latitude-deg> mandatory<br />
</hospital><br />
<br />
<helipad><br />
...<br />
</helipad><br />
</targets><br />
</syntaxhighlight><br />
<br />
The tutorial system will for each calculate how the user's aircraft is positioned relative to the respective target, and offer the information in this structure:<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<tutorials><br />
<targets><br />
<hospital><br />
<direction-deg>12.345</direction-deg><br />
<heading-deg>33.333</heading-deg><br />
<distance-m>12404.932</distance-m><br />
<eta-min>39.2358</eta-min><br />
</hospital><br />
<br />
<helipad><br />
...<br />
</helipad><br />
</targets><br />
</tutorials><br />
</sim><br />
</syntaxhighlight><br />
<br />
Where:<br />
<syntaxhighlight lang="xml"><br />
<direction-deg> is an angle between the aircraft's velocity vector and the<br />
azimuth to the target. 0 means that the aircraft is moving<br />
right towards the target. 10 means that the target is slightly<br />
to the right, -90 means that it's exactly left, and -180 or<br />
179.9999 that it's right behind.<br />
<br />
<heading-deg> is the absolute heading that the aircraft would currently<br />
have to fly with in a straight line to reach the target<br />
<br />
<distance-m> is the distance in meters<br />
<br />
<eta-min> is the "Estimated Time of Arrival" given the aircraft's<br />
current speed towards the target. Positive times mean that<br />
the aircraft is getting nearer to the target and can arrive<br />
there in this time given the current speed. It will, of course,<br />
only arrive there, if <direction-deg> is zero. A negative<br />
number means that the aircraft moves away, or in other words:<br />
that in this number of minutes it will be away twice as far.<br />
</syntaxhighlight><br />
<br />
=== Preset ===<br />
These set the initial simulator state. All properties are optional. The last three entries are to define the position relative to the airport/runway or the longitude/latitude.<br />
<br />
<syntaxhighlight lang="xml"><br />
<presets><br />
<airport-id>KHAF</airport-id><br />
<on-ground>1</on-ground><br />
<runway>12</runway><br />
<!--<br />
<altitude-ft>122.333</altitude-ft><br />
<latitude-deg>37.555</latitude-deg><br />
<longitude-deg>1000</longitude-deg><br />
--><br />
<heading-deg>0</heading-deg><br />
<airspeed-kt>0</airspeed-kt><br />
<glideslope-deg>0</glideslope-deg><br />
<offset-azimuth>0</offset-azimuth><br />
<offset-distance>0</offset-distance><br />
</presets><br />
</syntaxhighlight><br />
<br />
=== Set ===<br />
<set> groups can be used in <init>, <step>, and <end>. They set a <property> to a given <value> or to the value that a second <property> points to. They can also reset values that were only temporarily changed for the duration of the tutorial. This is desirable for properties that are saved to the aircraft config file or to ~/.fgfs/autosave.xml.<br />
<br />
<syntaxhighlight lang="xml"><br />
<set><br />
<property>/foo/bar</property> set /foo/bar to 123<br />
<value>123</value><br />
</set><br />
<br />
<set><br />
<property>/foo/bar</property> set /foo/bar to value of /test<br />
<property>/test</property><br />
</set><br />
</syntaxhighlight><br />
<br />
=== View ===<br />
These groups can be used in <init>, <step>, and <end>. They smoothly move the view to a new view position/direction. All parameters are optional. If, for example, only <field-of-view> is set, then the view will only zoom in -- the direction and position will remain the same. This feature is meant for cockpit tutorials, where the pilot's view is directed to some switch or instrument.<br />
<br />
<syntaxhighlight lang="xml"><br />
<view><br />
<heading-offset-deg>20</heading-offset-deg> positive is left<br />
<pitch-offset-deg>-4</pitch-offset-deg> positive is up<br />
<roll-offset-deg>0</roll-offset-deg> positive is roll right<br />
<x-offset-m>0.2</x-offset-m> positive is move right<br />
<y-offset-m>0.2</y-offset-m> positive is move up<br />
<z-offset-m>0.2</z-offset-m> positive is move back<br />
<field-of-view>55</field-of-view> default: 55; smaller zooms in<br />
</view> <br />
</syntaxhighlight><br />
<br />
=== Marker ===<br />
These are supported in <init>, <step>, and <end>. They show a magenta colored circle at given position (relative to aircraft origin) in given size. See the last section for how to conveniently find the proper coordinates.<br />
<br />
<syntaxhighlight lang="xml"><br />
<marker><br />
<x-m>1.3</x-m> positive is back<br />
<y-m>0.3</y-m> positive is to the right<br />
<z-m>0.1</z-m> positive is up<br />
<scale>1.3</scale> optional; default: 1<br />
</marker><br />
</syntaxhighlight><br />
<br />
For this to work, the aircraft model needs to include the tutorial marker model in its animation xml file:<br />
<br />
<syntaxhighlight lang="xml"><br />
<PropertyList><br />
<path>lightning-f1a.ac</path><br />
<br />
<model><br />
<path>Aircraft/Generic/marker.xml</path><br />
</model><br />
<br />
...<br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
==== Finding marker coordinates ====<br />
If an aircraft tutorial wants to use the marker, then the aircraft animation file needs to include the marker model (see above). If this is done, then one can use the "marker-adjust" dialog to find the respective <marker> coordinates. Just type this into the "Help->Nasal Console" dialog:<br />
<br />
<syntaxhighlight lang="nasal"><br />
tutorial.dialog()<br />
</syntaxhighlight><br />
<br />
<br />
Or temporarily add a key binding to the *-set.xml file:<br />
<br />
<syntaxhighlight lang="xml"><br />
<key n="96"><br />
<name>Backtick</name><br />
<desc>Open marker adjust dialog</desc><br />
<binding><br />
<command>dialog-show</command><br />
<dialog-name>marker-adjust</dialog-name><br />
</binding><br />
</key><br />
</syntaxhighlight><br />
<br />
The dialog allows to move a red cross around, which has the blinking marker circle in the middle. Note that ctrl- and shift-modifiers modulate the slider movements. Ctrl makes positioning coarser, and shift finer. The [Reset] button moves the marker back to aircraft origin, the [Center] button centers the sliders, and the [Dump] button dumps the marker coordinates to the terminal, for example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<marker><br />
<x-m>1.1425</x-m><br />
<y-m>0.1994</y-m><br />
<z-m>-0.0844</z-m><br />
<scale>2.0489</scale><br />
</marker><br />
</syntaxhighlight><br />
<br />
This just needs to be copied to the tutorial XML file.<br />
<br />
=== Message/audio ===<br />
Groups <step> and <end> can have one or more <message> entries, and one or more <audio> entries. If more are used of a kind, then the tutorial chooses one at random. If <audio> are available, then the contents are interpreted as file name of a *.wav sample, which is appended to the <audio-dir> path defined at the <tutorial> top level (default: "") and played by the tutorial system. Otherwise the <message> is handed over to the voice system, and synthesized to speech by the Festival speech synthesizer (if installed). In either case the chosen <message> is displayed on top of the screen. Neither <message> nor <audio> are mandatory.<br />
<br />
Because one and the same <message> string can be displayed *and* be synthesized, which can be problematic in some cases, there is a way to specify parts for either display *or* voice synthesizer: "{<display part>|<voice part}". Example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<message>Press the {No1|number one} button!</message><br />
</syntaxhighlight><br />
<br />
Here, "No1" would be displayed on the screen, but "number one" would be sent to the speech synthesis system. This can also be used to add invisible but audible exclamation marks: "Press the button{|!}"<br />
<br />
=== Condition ===<br />
These are explained in detail in [[$FG_ROOT]]/Docs/README.conditions. Here's just one example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<condition><br />
<less-than><br />
<property>/foo/bar</property><br />
<value>12</value><br />
</less-than><br />
</condition><br />
</syntaxhighlight><br />
<br />
This condition is true when the value of /foo/bar is less than 12, and false otherwise.<br />
<br />
[[Category:Aircraft enhancement]]<br />
[[Category:Nasal]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Autopilot_configuration_reference&diff=83707Autopilot configuration reference2015-04-21T11:52:51Z<p>T3r: State Machine: fix definition of transition/source</p>
<hr />
<div>[[File:FgPlot.jpg|400px|thumb|[[FGPlot]] can be used to plot the value properties while tuning an autopilot.]]<br />
<br />
{{forum|46|Autopilot & Route Manager}}<br />
{{Autoflight Navigation}}<br />
<br />
: ''For a guide on how to model an autopilot using these elements, see [[Howto:Design an autopilot]].''<br />
<br />
The '''property rules''' used for '''autopilot configuration''' can also be used for other kinds of systems modeling. The controllers and filters allow for both simple and complex systems to be modeled. By using the output from one as the input to another one, very complex systems such as fly-by-wire systems with different control laws can be modeled.<br />
<br />
This page serves as a reference for the elements of [[FlightGear]] xml [[autopilot]] and property rule configuration files. It describes all elements available within the autopilot configuration file supported in the bleeding edge [[Git]] sources. Some of the elements may not be available in the current release version of FlightGear.<br />
<br />
For built-in runtime plotting of FlightGear properties (including FDM/Autopilot properties), check out [[FGPlot]] (available in FlightGear 2.11+).<br />
<br />
{{Systems_Modeling_Disclaimer}}<br />
<br />
== Autopilot vs. property-rule configurations ==<br />
The main difference between XML based autopilot and property-rule systems is the update rate:<br />
<br />
* Autopilot configurations run at [[FDM]] rate<br />
* Property-rule configurations run at frame rate<br />
<br />
=== Performance considerations ===<br />
Using property-rule elements for things that does not have to run a FDM rate can improve the frame rate, in particular for complex systems and on weaker computers. Depending on FlightGear settings and the hardware, the FDM rate is about 2–10 times higher than the frame rate.<br />
<br />
It is possible to implement a system using both autopilot and property-rule based elements. They can communicate with each other using [[Property tree|properties]]. The only disadvantage is that they will be split between an autopilot and a property-rule configuration file.<br />
<br />
For example would a fly-by-wire flight control system element augmenting an instable aircraft need to run at FDM rate, while an element depending on the flap extension would work just as well at frame rate.<br />
<br />
== Adding a configuration to an aircraft ==<br />
A configuration is added to an aircraft by adding the path to an XML configuration file to the <code>&lt;Aircraft&gt;-set.xml</code> file.<br />
<br />
=== Adding an autopilot configuration ===<br />
Autopilot configuration files are added to the aircraft by adding<br />
<br />
<syntaxhighlight lang="xml"><br />
<autopilot><br />
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path><br />
</autopilot><br />
</syntaxhighlight><br />
<br />
to the<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<systems><br />
<!-- many other elements live here --><br />
<autopilot><br />
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path><br />
</autopilot><br />
</systems><br />
</sim><br />
</syntaxhighlight><br />
<br />
node of your aircraft-set.xml file. Note, that more than one <autopilot> node may be present, each will create a new instance of the autopilot subsystem when running FlightGear. They run in the order of appearance under <systems>. For example, lateral and vertical autopilot modes could live in separate files, as could a yaw-damper system.<br />
<br />
=== Adding a property-rule configuration ===<br />
Property-rules can also be used in which case they will run at frame rate. You can use these to process properties so their values can be used by other systems outside of the autopilot scope (for example to create smooth animations for switches that normally have discrete values)<br />
<br />
To achieve this load your filters configuration by adding:<br />
<br />
<syntaxhighlight lang="xml"><br />
<property-rule n="100"> <!-- "n" needs to be >= 100 to avoid overwriting other predefined global rules (in particular the environment ones) --><br />
<name>My property rule</name> <!-- Optional name tag useful for debugging and other maintenance --><br />
<path>Systems/my-propertyrules.xml</path> <!-- path can be relative to the current aircraft-set.xml location --><br />
</property-rule><br />
</syntaxhighlight><br />
<br />
to the :<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<systems><br />
<!-- many other elements live here --><br />
<property-rule n="100"> <!-- "n" needs to be >= 100 to avoid overwriting other predefined global rules (in particular the environment ones) --><br />
<name>My property rule</name> <!-- Optional name tag useful for debugging and other maintenance --><br />
<path>Systems/my-propertyrules.xml</path> <!-- path can be relative to the current aircraft-set.xml location --><br />
</property-rule><br />
</systems><br />
</sim><br />
</syntaxhighlight><br />
node of your aircraft-set.xml file. Note that you can add multiple <property-rule> elements, similar to the <autopilot> as described above.<br />
<br />
== Structure of a configuration file ==<br />
Autopilot configurations live in a separate file, formatted using the well known XML syntax like so many other FlightGear files with a <code>&lt;PropertyList&gt;</code> node as a root element. A basic skeleton file looks like this:<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<PropertyList><br />
<params include="MyParams.xml"> <!-- Params can be included like this --><br />
<controls><br />
<aileron>controls/flight/aileron</aileron><br />
<rudder>controls/flight/rudder</rudder><br />
<elevator>controls/flight/elevator</elevator><br />
</controls><br />
</params><br />
<br />
<!-- Place your components here --><br />
<!--<br />
<filter><br />
<name>Myfilter</name><br />
<input>/foo</input><br />
<output>/bar</output><br />
</filter><br />
<filter><br />
<name>Myfilter</name><br />
<input alias="/params/control/aileron"/> Aliasing a property name<br />
<output>/bar</output><br />
</filter><br />
--><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
The location and the name of the configuration file is up to the developer. A descriptive name like <code>autopilot.xml</code> might be a good choice. Most developers put these files into the <code>Systems</code> folder of the aircraft.<br />
<br />
{{tip|Using [[PropertyList XML files#Aliased properties|aliased property names]] is good style and makes the configuration file more readable. The params section may be included from an external file to avoid duplication of code.<br />
<br />
For complex systems, spread over multiple autopilot and/or property-rule configuration files, this can greatly aid debugging and maintenance.}}<br />
{{tip|Commenting the configuration file to document the purpose elements and groups of elements and what they are intended to do can also aid debugging and maintenance.}}<br />
<br />
== Available elements ==<br />
All elements may contain the attributes "include" and "alias". <br />
The "include" property takes a file name as a parameter. This can be used to read the document tree of an external XML file into the node containing the "include" attribute. The included file must have a PropertyList node as the root node. All nodes under this PropertyList node will be added to the node containing the "include" attribute.<br />
The "alias" attribute refers to an element defined elsewhere in this XMl document. Alias references are in a path-style syntax, either as a relative or absolute path. Absolute paths start with a slash, like <foo alias="/params/bar/baz"/>. Use the colon to move through the document tree, similar to file system paths like <foo alias="../../bar/baz"/>.<br />
<br />
Any top-level element can appear in an autopilot XML file, but only the following elements will be recognised and used:<br />
* <pid-controller><br />
* <pi-simple-controller><br />
* <filter><br />
* <predict-simple><br />
* <logic><br />
* <flipflop><br />
* <state-machine><br />
<br />
== Common elements used by all elements ==<br />
<br />
=== Name of filter and controller &lt;name&gt; ===<br />
The <name> element is optional, but should be added to give the controller a distinct name. It is only used in debug output.<br />
<br />
<syntaxhighlight lang="xml"><br />
<name>NAV hold</name><br />
</syntaxhighlight><br />
<br />
=== Feedback &lt;feedback-if-disabled&gt; ===<br />
The <feedback-if-disabled> element advises the controller to feed back the output property value to the active input property if the<br />
condition defined in the <enable> tag evaluates to false. This is usually required for controllers like servo drivers behind a PID-controller to give that PID-controller a valid starting value when it becomes enabled. The absence of this element or anything but the word ''true'' within this element results in feedback disabled.<br />
<br />
<syntaxhighlight lang="xml"><br />
<feedback-if-disabled>true</feedback-if-disabled><br />
</syntaxhighlight><br />
<br />
=== Printing debug output &lt;debug&gt; ===<br />
If the <debug> element is present and if it contains the word ''true'', the containing controller prints out some diagnostic information on the console for each processing loop.<br />
<br />
<syntaxhighlight lang="xml"><br />
<debug>true</debug><br />
</syntaxhighlight><br />
<br />
=== Input and reference properties or values &lt;input&gt; and &lt;reference&gt; ===<br />
Each controller has two input "lines", denoted by the tags <input> and <reference>. The arithmetic difference of these two values is used by the respective controller to compute it's output. Unfortunately due to historical reasons, the sign of input and reference is not consistent for all controllers. While the pid-controller and the pi-simple-controller compute "reference-input", the filter controller computes "input-reference". Each element is optional with a default value of zero. These elements are made of so called ''input values'' described further down in this document.<br />
<br />
Example for a simple differential amplifier, computing output = (input-reference)*2<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input>/some/input</input><br />
<reference>/some/output</reference><br />
<output>/some/output</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Output property &lt;output&gt; ===<br />
The <output> element names the properties, the computed value should be written to. More than one <output> may be present, each named property will be assigned the computed value.<br />
<br />
<syntaxhighlight lang="xml"><br />
<output>controls/flight/elevator</output><br />
</syntaxhighlight><br />
<br />
=== Enabling and disabling a filter &lt;enable&gt; ===<br />
Controllers can be enabled or disabled using property values. This element <enable> may contain a <prop> and a <value> element. The controller is enabled, if the value of the named property equals the given value. This feature is considered deprecated and might go away in future releases. The preferred way of defining the enable-condition is by adding a <condition> element to the <enable> element. This <condition> follows the same syntactical rules as the one used in model animations and can model complex expression trees.<br />
To enable a wing leveler only if the current bank angle does not exceed 30° of bank, use this condition<br />
<br />
<syntaxhighlight lang="xml"><br />
<enable><br />
<condition><br />
<less-than><br />
<property>orientation/bank-angle-deg</property><br />
<value>30.0</value><br />
</less-than><br />
<greater-than><br />
<property>orientation/bank-angle-deg</property><br />
<value>-30.0</value><br />
</greater-than><br />
</condition><br />
</enable><br />
</syntaxhighlight><br />
<br />
=== Input values ===<br />
Input values for controllers may be specified in several notations. Values may be supplied as constants, from properties or by means of simple linear transformations. Conditions allow the selection of one of multiple input sources. The following text will use the <tt>reference</tt> element as an example but it may be substituted by any other input element like <tt>Kp</tt>, <tt>gain</tt> etc. Input values will be interpreted as double values.<br />
<br />
==== A constant value &lt;value&gt; or &lt;reference&gt; ====<br />
A constant value is defined by just adding the value as text to the input element: <br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<value>3.5</value><br />
</reference><br />
</syntaxhighlight><br />
<br />
The shortcut syntax is also valid:<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference>3.5</reference><br />
</syntaxhighlight><br />
<br />
If the text can be parsed by <tt>strtod()</tt> to a double value, it will be used as a constant value, otherwise it will be interpreted as a property value (see next paragraph)<br />
<br />
==== A property value ====<br />
To evaluate the value of a property, place the name of the property into the text element:<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/my/property</property><br />
</reference><br />
</syntaxhighlight><br />
<br />
The shortcut syntax is also valid:<br />
<syntaxhighlight lang="xml"><br />
<reference>/my/property</reference><br />
</syntaxhighlight><br />
<br />
{{note|The shortcut syntax is only valid, if neither <property> nor <value> element exists.<br />
If both <property> '''and''' <value> element exist, the property will be initialized with the given value with scale and offset applied correctly.<br />
Properties don't have to exist, the will be created as needed.}}<br />
{{note|For backward compatibility, the notation <prop> instead of <property> is also valid but considered deprecated and might go away in future releases.}}<br />
<br />
==== Linear transformation of the input value &lt;offset&gt; ====<br />
Input values may be scaled and shifted before they are processed by the controller using the formula <tt>y = value * scale + offset</tt><br />
To use a Celsius temperature property in a controller which expects the temperature in Fahrenheit you might use<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/environment/temperature-degc</property><br />
<scale>1.8</scale><br />
<offset>32</offset><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Periodical transformation of the input value &lt;period&gt; ====<br />
Periodical (like angular) input values can be transformed to appear in the correct phase before they are processed by the controller by adding or subtracting multiples of the period to the input value until the values is in the requested periods interval.<br />
The following example converts the heading which comes in the range of [0..360] into the range of [-180..+180]. This will cause a heading of 270 to be processed as a value of -90.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/orientation/heading-deg</property><br />
<period><br />
<min>-180.0</min><br />
<max>180.0</max><br />
</period><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Input clamping &lt;min&gt; and &lt;max&gt; ====<br />
To clamp the input to a minimum value, maximum value or both, the tags <tt><min></tt> and <tt><max></tt> can be used. Clamping will occur after the linear transformation has been applied. Note the difference of input clamping to output clamping. While input clamping is applied '''before''' the signal reaches the controller, output clamping will be applied to the output signal '''after''' it has been processed.<br />
<br />
The following code will keep the input to the controller in the range of 60 to 80 degrees Fahrenheit:<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/environment/temperature-degc</property><br />
<scale>1.8</scale><br />
<offset>32</offset><br />
<min>60</min><br />
<max>80</max><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Absolute values &lt;abs&gt; ====<br />
To use the absolute (unsigned) value of the input, add <tt><abs type="bool">true</abs></tt>.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/autopilot/internal/course-error-deg</property><br />
<abs type="bool">true</abs><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Recursive definition ====<br />
The elements <tt><scale></tt>, <tt><offset></tt>, <tt><min></tt> and <tt><max></tt> itself can be defined as input values. This code uses as reference the value of course-error-deg, scaled by two and an offset applied which is calculated as the product of the bank-angle-de and the property some/property which itself is limited within the range of -1.5 .. +1.5.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/autopilot/internal/course-error-deg</property><br />
<scale>2.0</scale><br />
<offset><br />
<property>orientation/bank-angle-deg</property><br />
<scale><br />
<property>some/property<br />
<min>-1.5</min><br />
<max>1.5</max><br />
</scale><br />
</offset><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Conditional input values &lt;condition&gt; ====<br />
The direct inputs of controller and filter elements support so called input value lists. This is useful, if the input should be connected to one of many separate inputs like autopilots connected to NAV1, NAV2 or the GPS. A standard <tt><condition></tt> element is allowed within an input value element. The input value list will be traversed until the first input value with a successful condition is found. The behavior is much like the switch statement in programming languages.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<condition><br />
<property>/autopilot/coupled-to-gps</property><br />
</condition><br />
<property>instrumentation/gps/desired-track-deg</property><br />
</reference><br />
<reference><br />
<condition><br />
<property>/autopilot/coupled-to-nav2</property><br />
</condition><br />
<property>instrumentation/nav[1]/radials/selected-deg</property><br />
</reference><br />
<reference>instrumentation/nav[0]/radials/selected-deg</reference><br />
</syntaxhighlight><br />
<br />
Note the unconditional last <tt><reference<></tt> element which acts as an "if all others fail, use NAV1" anchor. If no input value return with a successful condition, the input value is undefined.<br /><br />
The <tt><scale></tt>, <tt><offset></tt>, <tt><min></tt> and <tt><max></tt> elements of input values itself currently don't support input value lists.<br />
<br />
==== Expressions &lt;expression&gt; ====<br />
Complex math or lookup tables may be represented using the [[expression]] syntax. The expression has to be enclosed in <expression> tag.<br />
<br />
=== Output values ===<br />
After processing of a component, the resulting value passes a transformation stage where it can be clipped or normalized into a given period. Periodic values such as angular properties may be normalized into a given period by adding a <period> element, defining the lower and upper bounds of the period. Additionally, a maximun and a minimum value may be given which will guarantee that the output value will ever exceed a defined value. <br />
<br />
{{note|Both periodical normalization and clipping may be defined. If both are given, the value will be normalized first and the clipping will be applied to the normalized value.}}<br />
<br />
The following example shifts the computed value into the interval of [-180..180] thereafter being limited into the interval of [-30..30]. The following table contains some computed values and the resulting written value:<br />
<br />
{| class="prettytable"<br />
! computed !! written<br />
|-<br />
| -350 || 10<br />
|-<br />
| -270 || 30<br />
|-<br />
| -90 || -30<br />
|-<br />
| -29 || -29<br />
|-<br />
| 29 || 29<br />
|-<br />
| 90 || 30<br />
|-<br />
| 350 || -10<br />
|}<br />
<br />
<syntaxhighlight lang="xml"><br />
<output>/some/property</output><br />
<period><br />
<min>-180</min><br />
<max>180</max><br />
</period><br />
<min>-30</min><br />
<max>30</max><br />
</syntaxhighlight><br />
<br />
== Logic controller &lt;logic&gt; ==<br />
The logic controller provides a simple way of creating property values from the result of the condition expression in the <input> element. The condition expression is evaluated once per iteration and the result is written as a boolean value to the named output property or properties. An optional <inverted> element inverts the logic. The default is "not inverted".<br />
<br />
Example: output = not( ( a is true ) or ( ( b greater than c ) and ( d is true ) )<br />
<br />
<syntaxhighlight lang="xml"><br />
<logic><br />
<inverted>true</inverted><br />
<input><br />
<property>a</property><br />
<or><br />
<greater-than><br />
<property>b</property><br />
<property>c</property><br />
<greater-than><br />
<property>d</property><br />
</or><br />
</input><br />
<output>output</output><br />
</logic><br />
</syntaxhighlight><br />
<br />
== Flip flop logic &lt;flipflop&gt; ==<br />
A flip flop is a controller that has two stable states so it can be used as a one bit memory. Four types of flip flops are implemented: '''RS''', '''JK''', '''D''' and '''T'''. All use positive logic and operate on the raising edge of the clock signal if a clock is used.<br />
All input lines, including the clock line, are encoded as condition constructs.<br />
If negative logic for the input line is required, wrap the condition into a <not> tag to invert the logic.<br />
<br />
{{note|The type, for example '''RS''', is case sensitive.}}<br />
{{note|Using <code><nowiki><condition></nowiki></code> tags will break the logic.}}<br />
<br />
=== RS flip flop &lt;RS&gt; ===<br />
This flip flop sets its output according to the set (S) or reset (R) input lines. If the set line is set, the output gets set. If the reset line is set, the output gets reset. If no line is set, the output stays unchanged. For the special case where set and reset lines are both set, two types of RS flip flops exist: for the RS flip flop (<type>RS</type>), the reset line is dominant and the output is reset. Alternatively, a SR flip flop (<type>SR</type>) has a dominant set line and the output gets set if set and reset line are set.<br />
<br />
Example: simple RS flip flop<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>RS</type> <!-- or SR --><br />
<S><br />
<property>/myflipflop/set</property><br />
</S><br />
<R><br />
<property>/myflipflop/reset</property><br />
</R><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== JK flip flop &lt;JK&gt; ===<br />
The JK flip flop is an extension of the RS flip flop. In addition to the set and reset lines of the RS flip flop it uses J, K and a clock input.<br />
The J line serves as a clock dependent set input while the K line does the reset job. Optionally, a clock input may be provided. State changes do not occour immediately, but on the next raising edge of the clock signal. The state of J=K=true causes the output to toggle it's current state on the next raising edge of the clock signal.<br />
If no clock signal is provided, the frame rate serves as the clock input.<br />
<br />
Example: simple JK flip flop with negative edge clock<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>JK</type><br />
<J><br />
<property>/myflipflop/set</property><br />
</J><br />
<K><br />
<property>/myflipflop/reset</property><br />
</K><br />
<clock><br />
<not><br />
<property>/myflipflop/clock</property><br />
</not><br />
</clock><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== D flip flop &lt;D&gt; ===<br />
The D flip flop transfers the state of the input signal '''D''' to the output line at the next raising edge of the clock signal, which is mandatory for this flip flop.<br />
<br />
Example: simple D flip flop with inverted output<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>D</type><br />
<D><br />
<property>/myflipflop/data</property><br />
</D><br />
<clock><br />
<property>/myflipflop/clock</property><br />
</clock><br />
<output>/myflipflop/output</output><br />
<inverted type="bool">true</inverted><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== T flip flop &lt;T&gt; ===<br />
The T flip flop toggles the state of the output signal at the next raising edge of the clock signal, which is mandatory for this flip flop.<br />
<br />
Example: simple T flip flop<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>T</type><br />
<clock><br />
<property>/myflipflop/clock</property><br />
</clock><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== Monostable flip flop &lt;monostable&gt; ===<br />
A monostable flip flop has only one stable state which will be reentered after a well defined time. The stable state in current implementation is the output set 'false' or 0. The Monostable is an extension of the JK flip flop. Additionally to the input values defined there, an InputValue for the definition of the pulse time is mandatory. <br />
<br />
The moment the time for the astable state starts counting depends on the input used to set the output. If the output is set from the SET input of the RS flipflop, the output is kept true for the defined time ''after'' the SET input enters it's false state. The total time the output is true equals the time, the SET input is true plus the time defined in the <time> element.<br />
If the output is set from the J and clock inputs of the JK flipflop, the timer starts on the raising edge of the clock input. The output signal will be true for exactly the time defined in the <time> element. <br />
<br />
{{note|The optional <R> and <K> inputs may be used to reset the output before the internal timer expired. This will also reset the timer to zero, so no additional event will be triggered after the defined timer interval.}}<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<name>Test mf</name><br />
<type>monostable</type><br />
<time><br />
<property>/myflipflop/pulsetime-sec</property><br />
<value>10</value><br />
</time><br />
<S><property>/myflipflop/s</property></S><br />
<J><property>/myflipflop/j</property></J><br />
<clock><property>/myflipflop/clock</property></clock><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
The following example shows how a monostable can be used to enable a certain property (/myflipflop/output) if another property (/myflipflop/s) is true for at least the specified amount of time:<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<name>Test mf</name><br />
<type>monostable</type><br />
<inverted type="bool">true</inverted><br />
<S><br />
<not><br />
<property>/myflipflop/s</property><br />
</not><br />
</S><br />
<time><br />
<value>10.0</value><br />
</time><br />
<output><br />
<property>/myflipflop/output</property><br />
</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
In this example the monostable is inverted, which means the stable state is true instead of false. The key idea here is to keep the monostable in its unstable state (false) by keeping the set line true, which is the case when /myflipflop/s is false. Then, when /myflipflop/s becomes true the set line becomes false, which causes the timer to start. When the timer expires (in this case 10 seconds) the monostable will enter its stable state (true). At any time when the set line becomes true (when /myflipflop/s becomes false) the monostable will immediately enter its unstable state (false) again, resulting in /myflipflop/output to become false immediately.<br />
<br />
== Filters &lt;filter&gt; ==<br />
<br />
=== Pure gain filter &lt;gain&gt; ===<br />
A gain filter multiplies the <input> value by a given factor or gain <gain> and returns the output to <output>. More than one <gain> element formatted as in [[Autopilot Configuration Reference#Input Values|Input Values]] may be present. Within a <condition> evaluating as true the first <gain> will define the used gain.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>gain</type><br />
<gain>6.28</gain><br />
<input>radius</input><br />
<output>circumfence</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== First order low pass filter &lt;exponential&gt; ===<br />
The exponential filter is a typical [http://en.wikipedia.org/wiki/Low-pass_filter low pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, lower frequencies can pass this filter while higher frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <filter-time> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency).<br />
<br />
Example: a 1Hz first order low pass filter <br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>exponential</type><br />
<filter-time>0.16</filter-time><br />
<input>/some/input</input><br />
<output>/some/output/</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
<br />
<br />
=== First order high pass filter &lt;high-pass&gt; ===<br />
The high pass filter is a typical [http://en.wikipedia.org/wiki/High-pass_filter high pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, higher frequencies can pass this filter while lower frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <filter-time> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency). It is commonly known as a wash-out filter or a 1st order lead filter<br />
<br />
Example: a 1Hz first order high pass filter <br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>high-pass</type><br />
<filter-time>0.16</filter-time><br />
<input>/some/input</input><br />
<output>/some/output/</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Second order low pass filter &lt;double-exponential&gt; ===<br />
The double exponential filter is a low pass filter like the exponential filter with a steeper slope of the filter diagram. It acts basically like two chained exponential filters and it is some times called second order filter. <br />
<br />
The configuration is the same for exponential and double-exponential filters, just the type entry differs.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>double-exponential</type><br />
<filter-time>0.16</filter-time><br />
<input>/some/input</input><br />
<output>/some/output/<output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Moving average filter &lt;moving-average&gt; ===<br />
Calculates average of specified number of values.<br />
<br />
Currently the average length can only be given as number of samples and not time.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>moving-average</type><br />
<samples>120</samples><br />
<input>/some/input</input><br />
<output>/some/output</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Rate limit filter &lt;noise-spike&gt; ===<br />
A better name for a noise spike filter would probably have been "rate limit filter". This is exactly what it does: limit the rate of change of the output value. The relevant configuration element is <max-rate-of-change> setting the maximum rate of change of the output property per second.<br />
<br />
Example: A transition from 0 to 4 at the input property results in a linear increase of the output property over 8 seconds from 0 to 4 at a rate of 0.5/sec.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>noise-spike</type><br />
<max-rate-of-change>0.5</max-rate-of-change><br />
<input>/some/input</input><br />
<output>/some/output</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Reciprocal filter &lt;reciprocal&gt; ===<br />
Compute the reciprocal (1/x) value of the input property. If x is zero, no computation is performed. The optional <gain> element may be used to scale the value. Output computes as gain divided by input.<br />
<br />
Example: compute the flight time per pound of burned fuel from the fuel flow<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>reciprocal</type><br />
<gain>1.0</gain><br />
<input>/engines/engine[0]/fuel-flow-pph</input><br />
<output>/engines/engine[0]/fuel-flow-hpp</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Derivative filter &lt;derivative&gt; ===<br />
Compute first time derivative of the input property, that is change per unit of time. Time is measured in seconds. A <filter-time> acts as gain and must be given because it has default 0.<br />
<br />
Example: compute derivative of static port pressure<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>derivative</type><br />
<input>systems/static[0]/pressure-inhg</input><br />
<output>autopilot/internal/pressure-rate</output><br />
<filter-time>1.0</filter-time><br />
</filter><br />
</syntaxhighlight><br />
<br />
== PID controller &lt;pid-controller&gt; ==<br />
The [http://en.wikipedia.org/wiki/PID_controller PID controller] is the swiss army knife of automation and this implementation is suitable for most situations. It has a builtin anti-windup logic, and usage of <max> and <min> elements for clamping the output is mandatory. The most important thing to know is that this controller 'does not' compute absolute output values but an offset from the current value of the output property. This can lead to unexpected behavior if the current value of the output property is unknown when the controller is enabled. This behavior is different to that of the pi-simple-controller.<br />
The xml element creating a pid controller is <tt><pid-controller></tt>.<br />
<br />
Legal elements are:<br />
<br />
{| class="prettytable"<br />
!Kp<br />
|the overall gain for the proportional, integral and derivative part<br />
|-<br />
!Ti<br />
|integrator time<br />
|-<br />
!Td<br />
|derivator time<br />
|-<br />
!Ts<br />
|sampling interval (default: sample at frame rate)<br />
|-<br />
!alpha<br />
|scaling factor for Td (defaults to 0.1)<br />
|-<br />
!beta<br />
|reference weighing factor for the proportional component (defaults to 1.0)<br />
|-<br />
!gamma<br />
|reference weighing factor for the derivate component (defaults to 0.0)<br />
|}<br />
<br />
== PI controller &lt;pi-simple-controller&gt; ==<br />
This controller implements a PI controller. Other than the PID controller, it computes absolute output values, regardless of the value of the output property. It can by configured as an I-only, P-only or PI-controller. It has anti windup logic if <min> and <max> elements are present.<br />
The xml element creating a PI controller is <tt><pi-simple-controller></tt><br />
Legal elements are:<br />
<br />
{| class="prettytable"<br />
!Kp<br />
|gain of the proportional component<br />
|-<br />
!Ki<br />
|gain of the integrator component<br />
|}<br />
<br />
== Predictor &lt;predict-simple&gt; ==<br />
Estimates the future value for a given property based on its current (or averaged) rate of change.<br />
<br />
Legal elements are:<br />
<br />
{| class="prettytable"<br />
!seconds<br />
|the time to be estimated ahead<br />
|-<br />
!filter-gain<br />
|Smoothing factor (0.0-1.0, 1.0=no smoothing)<br />
|}<br />
<br />
Example: compute estimated speed 5 seconds ahead<br />
<br />
<syntaxhighlight lang="xml"><br />
<predict-simple><br />
<name>predicted air speed 5 seconds ahead</name><br />
<debug>false</debug><br />
<input>velocities/airspeed-kt</input><br />
<output>autopilot/internal/airspeed-5-sec-ahead</output><br />
<seconds>5.0</seconds><br />
<filter-gain>0.1</filter-gain><br />
</predict-simple><br />
</syntaxhighlight><br />
<br />
== State Machine &lt;state-machine&gt; ==<br />
For a discription of what a state machine can do, look here: [http://en.wikipedia.org/wiki/Finite-state_machine].<br />
<br />
<state-machine><br />
<branch>/my-statemachine</branch><br />
<state><br />
<name>init</name><br />
<enter><br />
<binding></binding><br />
<binding></binding><br />
</enter><br />
<exit><br />
<binding></binding><br />
</exit><br />
<update><br />
<binding></binding><br />
</update><br />
</state><br />
<state><br />
<name>finished</name><br />
<enter>Zero to many bindings, fired upon state enter</enter><br />
<exit>Zero to many bindings, fired upon state exit</exit><br />
<update>Zero to many bindings, fired upon every state change</update><br />
</state><br />
<transition><br />
<name>ready</name><br />
&lt;source&gt;init</source><br />
<target>finished</target><br />
<exclude-target type="bool">true</exclude-target><br />
<condition><br />
<greater-than><br />
<property>/sim/time/elapsed-sec</property><br />
<value>30</value><br />
</greater-than><br />
</condition><br />
<binding>Zero to many bindings, fired upon state change</binding><br />
</transition><br />
</state-machine><br />
<br />
Legal elements for the state machine are:<br />
<br />
{| class="prettytable"<br />
!branch<br />
|A path to a property node where the internal states of the machine gets written to. Can be empty.<br />
|-<br />
!state<br />
|Two ore more state elements are required for a minimal state machine<br />
|-<br />
!transition<br />
|Any number of transition elements. Describes how to change from one state to another.<br />
|}<br />
<br />
<br />
Legal elements for the state element are:<br />
<br />
{| class="prettytable"<br />
!name<br />
|required, gives the state a name for reference<br />
|-<br />
!enter<br />
|optional, zero to many enter elements containing a SGBinding to fire upon state enter<br />
|-<br />
!exit<br />
|optional, zero to many exit elements containing a SGBinding to fire upon state exit<br />
|-<br />
!update<br />
|optional, zero to many update elements containing a SGBinding to fire upon state change<br />
|}<br />
<br />
Legal elements for the transition element are:<br />
<br />
{| class="prettytable"<br />
!name<br />
|required, gives the transition a name for reference<br />
|-<br />
!source<br />
|optional, zero to many source elements containing the name of a source state. If no source state is definied, this transition applies to all states.<br />
|-<br />
!target<br />
|required, exactly one target element defining the target state<br />
|-<br />
!condition<br />
|required, contains a SGCondition when this state change occours<br />
|-<br />
!exclude-target<br />
|optional, boolean flag defaults to true. Indicates if this transition should be evaluated even if current state equals target<br />
|-<br />
!binding<br />
|optional, zero to many binding elements containing a SGBinding to fire when this transition triggers<br />
|}<br />
<br />
== Proposed extensions ==<br />
This sections contains new features for the autopilot to be implemented. Nobody knows if and when this will happen. Consider this as a collection of ideas as a base for discussion on the mailing list, the forum or IRC.<br />
<br />
== Related content ==<br />
=== Readme file ===<br />
: ''This file can also be found in [[$FG_ROOT]]/Docs.''<br />
<br />
* {{Git link|gitorious|fg/fgdata|master|Docs/README.digitalfilters|text=README.digitalfilters}}<br />
<br />
=== Source code ===<br />
* {{Git link|gitorious|fg/flightgear|next|src/Autopilot/digitalfilter.hxx}}<br />
* {{Git link|gitorious|fg/flightgear|next|src/Autopilot/autopilot.cxx}}<br />
<br />
[[Category:Aircraft enhancement]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Autopilot_configuration_reference&diff=83703Autopilot configuration reference2015-04-21T08:00:25Z<p>T3r: Added state-machine documentation</p>
<hr />
<div>[[File:FgPlot.jpg|400px|thumb|[[FGPlot]] can be used to plot the value properties while tuning an autopilot.]]<br />
<br />
{{forum|46|Autopilot & Route Manager}}<br />
{{Autoflight Navigation}}<br />
<br />
: ''For a guide on how to model an autopilot using these elements, see [[Howto:Design an autopilot]].''<br />
<br />
The '''property rules''' used for '''autopilot configuration''' can also be used for other kinds of systems modeling. The controllers and filters allow for both simple and complex systems to be modeled. By using the output from one as the input to another one, very complex systems such as fly-by-wire systems with different control laws can be modeled.<br />
<br />
This page serves as a reference for the elements of [[FlightGear]] xml [[autopilot]] and property rule configuration files. It describes all elements available within the autopilot configuration file supported in the bleeding edge [[Git]] sources. Some of the elements may not be available in the current release version of FlightGear.<br />
<br />
For built-in runtime plotting of FlightGear properties (including FDM/Autopilot properties), check out [[FGPlot]] (available in FlightGear 2.11+).<br />
<br />
{{Systems_Modeling_Disclaimer}}<br />
<br />
== Autopilot vs. property-rule configurations ==<br />
The main difference between XML based autopilot and property-rule systems is the update rate:<br />
<br />
* Autopilot configurations run at [[FDM]] rate<br />
* Property-rule configurations run at frame rate<br />
<br />
=== Performance considerations ===<br />
Using property-rule elements for things that does not have to run a FDM rate can improve the frame rate, in particular for complex systems and on weaker computers. Depending on FlightGear settings and the hardware, the FDM rate is about 2–10 times higher than the frame rate.<br />
<br />
It is possible to implement a system using both autopilot and property-rule based elements. They can communicate with each other using [[Property tree|properties]]. The only disadvantage is that they will be split between an autopilot and a property-rule configuration file.<br />
<br />
For example would a fly-by-wire flight control system element augmenting an instable aircraft need to run at FDM rate, while an element depending on the flap extension would work just as well at frame rate.<br />
<br />
== Adding a configuration to an aircraft ==<br />
A configuration is added to an aircraft by adding the path to an XML configuration file to the <code>&lt;Aircraft&gt;-set.xml</code> file.<br />
<br />
=== Adding an autopilot configuration ===<br />
Autopilot configuration files are added to the aircraft by adding<br />
<br />
<syntaxhighlight lang="xml"><br />
<autopilot><br />
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path><br />
</autopilot><br />
</syntaxhighlight><br />
<br />
to the<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<systems><br />
<!-- many other elements live here --><br />
<autopilot><br />
<path>Aircraft/MyAircraft/Systems/my-autopilot.xml</path><br />
</autopilot><br />
</systems><br />
</sim><br />
</syntaxhighlight><br />
<br />
node of your aircraft-set.xml file. Note, that more than one <autopilot> node may be present, each will create a new instance of the autopilot subsystem when running FlightGear. They run in the order of appearance under <systems>. For example, lateral and vertical autopilot modes could live in separate files, as could a yaw-damper system.<br />
<br />
=== Adding a property-rule configuration ===<br />
Property-rules can also be used in which case they will run at frame rate. You can use these to process properties so their values can be used by other systems outside of the autopilot scope (for example to create smooth animations for switches that normally have discrete values)<br />
<br />
To achieve this load your filters configuration by adding:<br />
<br />
<syntaxhighlight lang="xml"><br />
<property-rule n="100"> <!-- "n" needs to be >= 100 to avoid overwriting other predefined global rules (in particular the environment ones) --><br />
<name>My property rule</name> <!-- Optional name tag useful for debugging and other maintenance --><br />
<path>Systems/my-propertyrules.xml</path> <!-- path can be relative to the current aircraft-set.xml location --><br />
</property-rule><br />
</syntaxhighlight><br />
<br />
to the :<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
<systems><br />
<!-- many other elements live here --><br />
<property-rule n="100"> <!-- "n" needs to be >= 100 to avoid overwriting other predefined global rules (in particular the environment ones) --><br />
<name>My property rule</name> <!-- Optional name tag useful for debugging and other maintenance --><br />
<path>Systems/my-propertyrules.xml</path> <!-- path can be relative to the current aircraft-set.xml location --><br />
</property-rule><br />
</systems><br />
</sim><br />
</syntaxhighlight><br />
node of your aircraft-set.xml file. Note that you can add multiple <property-rule> elements, similar to the <autopilot> as described above.<br />
<br />
== Structure of a configuration file ==<br />
Autopilot configurations live in a separate file, formatted using the well known XML syntax like so many other FlightGear files with a <code>&lt;PropertyList&gt;</code> node as a root element. A basic skeleton file looks like this:<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<PropertyList><br />
<params include="MyParams.xml"> <!-- Params can be included like this --><br />
<controls><br />
<aileron>controls/flight/aileron</aileron><br />
<rudder>controls/flight/rudder</rudder><br />
<elevator>controls/flight/elevator</elevator><br />
</controls><br />
</params><br />
<br />
<!-- Place your components here --><br />
<!--<br />
<filter><br />
<name>Myfilter</name><br />
<input>/foo</input><br />
<output>/bar</output><br />
</filter><br />
<filter><br />
<name>Myfilter</name><br />
<input alias="/params/control/aileron"/> Aliasing a property name<br />
<output>/bar</output><br />
</filter><br />
--><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
The location and the name of the configuration file is up to the developer. A descriptive name like <code>autopilot.xml</code> might be a good choice. Most developers put these files into the <code>Systems</code> folder of the aircraft.<br />
<br />
{{tip|Using [[PropertyList XML files#Aliased properties|aliased property names]] is good style and makes the configuration file more readable. The params section may be included from an external file to avoid duplication of code.<br />
<br />
For complex systems, spread over multiple autopilot and/or property-rule configuration files, this can greatly aid debugging and maintenance.}}<br />
{{tip|Commenting the configuration file to document the purpose elements and groups of elements and what they are intended to do can also aid debugging and maintenance.}}<br />
<br />
== Available elements ==<br />
All elements may contain the attributes "include" and "alias". <br />
The "include" property takes a file name as a parameter. This can be used to read the document tree of an external XML file into the node containing the "include" attribute. The included file must have a PropertyList node as the root node. All nodes under this PropertyList node will be added to the node containing the "include" attribute.<br />
The "alias" attribute refers to an element defined elsewhere in this XMl document. Alias references are in a path-style syntax, either as a relative or absolute path. Absolute paths start with a slash, like <foo alias="/params/bar/baz"/>. Use the colon to move through the document tree, similar to file system paths like <foo alias="../../bar/baz"/>.<br />
<br />
Any top-level element can appear in an autopilot XML file, but only the following elements will be recognised and used:<br />
* <pid-controller><br />
* <pi-simple-controller><br />
* <filter><br />
* <predict-simple><br />
* <logic><br />
* <flipflop><br />
* <state-machine><br />
<br />
== Common elements used by all elements ==<br />
<br />
=== Name of filter and controller &lt;name&gt; ===<br />
The <name> element is optional, but should be added to give the controller a distinct name. It is only used in debug output.<br />
<br />
<syntaxhighlight lang="xml"><br />
<name>NAV hold</name><br />
</syntaxhighlight><br />
<br />
=== Feedback &lt;feedback-if-disabled&gt; ===<br />
The <feedback-if-disabled> element advises the controller to feed back the output property value to the active input property if the<br />
condition defined in the <enable> tag evaluates to false. This is usually required for controllers like servo drivers behind a PID-controller to give that PID-controller a valid starting value when it becomes enabled. The absence of this element or anything but the word ''true'' within this element results in feedback disabled.<br />
<br />
<syntaxhighlight lang="xml"><br />
<feedback-if-disabled>true</feedback-if-disabled><br />
</syntaxhighlight><br />
<br />
=== Printing debug output &lt;debug&gt; ===<br />
If the <debug> element is present and if it contains the word ''true'', the containing controller prints out some diagnostic information on the console for each processing loop.<br />
<br />
<syntaxhighlight lang="xml"><br />
<debug>true</debug><br />
</syntaxhighlight><br />
<br />
=== Input and reference properties or values &lt;input&gt; and &lt;reference&gt; ===<br />
Each controller has two input "lines", denoted by the tags <input> and <reference>. The arithmetic difference of these two values is used by the respective controller to compute it's output. Unfortunately due to historical reasons, the sign of input and reference is not consistent for all controllers. While the pid-controller and the pi-simple-controller compute "reference-input", the filter controller computes "input-reference". Each element is optional with a default value of zero. These elements are made of so called ''input values'' described further down in this document.<br />
<br />
Example for a simple differential amplifier, computing output = (input-reference)*2<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>gain</type><br />
<gain>1.0</gain><br />
<input>/some/input</input><br />
<reference>/some/output</reference><br />
<output>/some/output</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Output property &lt;output&gt; ===<br />
The <output> element names the properties, the computed value should be written to. More than one <output> may be present, each named property will be assigned the computed value.<br />
<br />
<syntaxhighlight lang="xml"><br />
<output>controls/flight/elevator</output><br />
</syntaxhighlight><br />
<br />
=== Enabling and disabling a filter &lt;enable&gt; ===<br />
Controllers can be enabled or disabled using property values. This element <enable> may contain a <prop> and a <value> element. The controller is enabled, if the value of the named property equals the given value. This feature is considered deprecated and might go away in future releases. The preferred way of defining the enable-condition is by adding a <condition> element to the <enable> element. This <condition> follows the same syntactical rules as the one used in model animations and can model complex expression trees.<br />
To enable a wing leveler only if the current bank angle does not exceed 30° of bank, use this condition<br />
<br />
<syntaxhighlight lang="xml"><br />
<enable><br />
<condition><br />
<less-than><br />
<property>orientation/bank-angle-deg</property><br />
<value>30.0</value><br />
</less-than><br />
<greater-than><br />
<property>orientation/bank-angle-deg</property><br />
<value>-30.0</value><br />
</greater-than><br />
</condition><br />
</enable><br />
</syntaxhighlight><br />
<br />
=== Input values ===<br />
Input values for controllers may be specified in several notations. Values may be supplied as constants, from properties or by means of simple linear transformations. Conditions allow the selection of one of multiple input sources. The following text will use the <tt>reference</tt> element as an example but it may be substituted by any other input element like <tt>Kp</tt>, <tt>gain</tt> etc. Input values will be interpreted as double values.<br />
<br />
==== A constant value &lt;value&gt; or &lt;reference&gt; ====<br />
A constant value is defined by just adding the value as text to the input element: <br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<value>3.5</value><br />
</reference><br />
</syntaxhighlight><br />
<br />
The shortcut syntax is also valid:<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference>3.5</reference><br />
</syntaxhighlight><br />
<br />
If the text can be parsed by <tt>strtod()</tt> to a double value, it will be used as a constant value, otherwise it will be interpreted as a property value (see next paragraph)<br />
<br />
==== A property value ====<br />
To evaluate the value of a property, place the name of the property into the text element:<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/my/property</property><br />
</reference><br />
</syntaxhighlight><br />
<br />
The shortcut syntax is also valid:<br />
<syntaxhighlight lang="xml"><br />
<reference>/my/property</reference><br />
</syntaxhighlight><br />
<br />
{{note|The shortcut syntax is only valid, if neither <property> nor <value> element exists.<br />
If both <property> '''and''' <value> element exist, the property will be initialized with the given value with scale and offset applied correctly.<br />
Properties don't have to exist, the will be created as needed.}}<br />
{{note|For backward compatibility, the notation <prop> instead of <property> is also valid but considered deprecated and might go away in future releases.}}<br />
<br />
==== Linear transformation of the input value &lt;offset&gt; ====<br />
Input values may be scaled and shifted before they are processed by the controller using the formula <tt>y = value * scale + offset</tt><br />
To use a Celsius temperature property in a controller which expects the temperature in Fahrenheit you might use<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/environment/temperature-degc</property><br />
<scale>1.8</scale><br />
<offset>32</offset><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Periodical transformation of the input value &lt;period&gt; ====<br />
Periodical (like angular) input values can be transformed to appear in the correct phase before they are processed by the controller by adding or subtracting multiples of the period to the input value until the values is in the requested periods interval.<br />
The following example converts the heading which comes in the range of [0..360] into the range of [-180..+180]. This will cause a heading of 270 to be processed as a value of -90.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/orientation/heading-deg</property><br />
<period><br />
<min>-180.0</min><br />
<max>180.0</max><br />
</period><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Input clamping &lt;min&gt; and &lt;max&gt; ====<br />
To clamp the input to a minimum value, maximum value or both, the tags <tt><min></tt> and <tt><max></tt> can be used. Clamping will occur after the linear transformation has been applied. Note the difference of input clamping to output clamping. While input clamping is applied '''before''' the signal reaches the controller, output clamping will be applied to the output signal '''after''' it has been processed.<br />
<br />
The following code will keep the input to the controller in the range of 60 to 80 degrees Fahrenheit:<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/environment/temperature-degc</property><br />
<scale>1.8</scale><br />
<offset>32</offset><br />
<min>60</min><br />
<max>80</max><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Absolute values &lt;abs&gt; ====<br />
To use the absolute (unsigned) value of the input, add <tt><abs type="bool">true</abs></tt>.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/autopilot/internal/course-error-deg</property><br />
<abs type="bool">true</abs><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Recursive definition ====<br />
The elements <tt><scale></tt>, <tt><offset></tt>, <tt><min></tt> and <tt><max></tt> itself can be defined as input values. This code uses as reference the value of course-error-deg, scaled by two and an offset applied which is calculated as the product of the bank-angle-de and the property some/property which itself is limited within the range of -1.5 .. +1.5.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<property>/autopilot/internal/course-error-deg</property><br />
<scale>2.0</scale><br />
<offset><br />
<property>orientation/bank-angle-deg</property><br />
<scale><br />
<property>some/property<br />
<min>-1.5</min><br />
<max>1.5</max><br />
</scale><br />
</offset><br />
</reference><br />
</syntaxhighlight><br />
<br />
==== Conditional input values &lt;condition&gt; ====<br />
The direct inputs of controller and filter elements support so called input value lists. This is useful, if the input should be connected to one of many separate inputs like autopilots connected to NAV1, NAV2 or the GPS. A standard <tt><condition></tt> element is allowed within an input value element. The input value list will be traversed until the first input value with a successful condition is found. The behavior is much like the switch statement in programming languages.<br />
<br />
<syntaxhighlight lang="xml"><br />
<reference><br />
<condition><br />
<property>/autopilot/coupled-to-gps</property><br />
</condition><br />
<property>instrumentation/gps/desired-track-deg</property><br />
</reference><br />
<reference><br />
<condition><br />
<property>/autopilot/coupled-to-nav2</property><br />
</condition><br />
<property>instrumentation/nav[1]/radials/selected-deg</property><br />
</reference><br />
<reference>instrumentation/nav[0]/radials/selected-deg</reference><br />
</syntaxhighlight><br />
<br />
Note the unconditional last <tt><reference<></tt> element which acts as an "if all others fail, use NAV1" anchor. If no input value return with a successful condition, the input value is undefined.<br /><br />
The <tt><scale></tt>, <tt><offset></tt>, <tt><min></tt> and <tt><max></tt> elements of input values itself currently don't support input value lists.<br />
<br />
==== Expressions &lt;expression&gt; ====<br />
Complex math or lookup tables may be represented using the [[expression]] syntax. The expression has to be enclosed in <expression> tag.<br />
<br />
=== Output values ===<br />
After processing of a component, the resulting value passes a transformation stage where it can be clipped or normalized into a given period. Periodic values such as angular properties may be normalized into a given period by adding a <period> element, defining the lower and upper bounds of the period. Additionally, a maximun and a minimum value may be given which will guarantee that the output value will ever exceed a defined value. <br />
<br />
{{note|Both periodical normalization and clipping may be defined. If both are given, the value will be normalized first and the clipping will be applied to the normalized value.}}<br />
<br />
The following example shifts the computed value into the interval of [-180..180] thereafter being limited into the interval of [-30..30]. The following table contains some computed values and the resulting written value:<br />
<br />
{| class="prettytable"<br />
! computed !! written<br />
|-<br />
| -350 || 10<br />
|-<br />
| -270 || 30<br />
|-<br />
| -90 || -30<br />
|-<br />
| -29 || -29<br />
|-<br />
| 29 || 29<br />
|-<br />
| 90 || 30<br />
|-<br />
| 350 || -10<br />
|}<br />
<br />
<syntaxhighlight lang="xml"><br />
<output>/some/property</output><br />
<period><br />
<min>-180</min><br />
<max>180</max><br />
</period><br />
<min>-30</min><br />
<max>30</max><br />
</syntaxhighlight><br />
<br />
== Logic controller &lt;logic&gt; ==<br />
The logic controller provides a simple way of creating property values from the result of the condition expression in the <input> element. The condition expression is evaluated once per iteration and the result is written as a boolean value to the named output property or properties. An optional <inverted> element inverts the logic. The default is "not inverted".<br />
<br />
Example: output = not( ( a is true ) or ( ( b greater than c ) and ( d is true ) )<br />
<br />
<syntaxhighlight lang="xml"><br />
<logic><br />
<inverted>true</inverted><br />
<input><br />
<property>a</property><br />
<or><br />
<greater-than><br />
<property>b</property><br />
<property>c</property><br />
<greater-than><br />
<property>d</property><br />
</or><br />
</input><br />
<output>output</output><br />
</logic><br />
</syntaxhighlight><br />
<br />
== Flip flop logic &lt;flipflop&gt; ==<br />
A flip flop is a controller that has two stable states so it can be used as a one bit memory. Four types of flip flops are implemented: '''RS''', '''JK''', '''D''' and '''T'''. All use positive logic and operate on the raising edge of the clock signal if a clock is used.<br />
All input lines, including the clock line, are encoded as condition constructs.<br />
If negative logic for the input line is required, wrap the condition into a <not> tag to invert the logic.<br />
<br />
{{note|The type, for example '''RS''', is case sensitive.}}<br />
{{note|Using <code><nowiki><condition></nowiki></code> tags will break the logic.}}<br />
<br />
=== RS flip flop &lt;RS&gt; ===<br />
This flip flop sets its output according to the set (S) or reset (R) input lines. If the set line is set, the output gets set. If the reset line is set, the output gets reset. If no line is set, the output stays unchanged. For the special case where set and reset lines are both set, two types of RS flip flops exist: for the RS flip flop (<type>RS</type>), the reset line is dominant and the output is reset. Alternatively, a SR flip flop (<type>SR</type>) has a dominant set line and the output gets set if set and reset line are set.<br />
<br />
Example: simple RS flip flop<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>RS</type> <!-- or SR --><br />
<S><br />
<property>/myflipflop/set</property><br />
</S><br />
<R><br />
<property>/myflipflop/reset</property><br />
</R><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== JK flip flop &lt;JK&gt; ===<br />
The JK flip flop is an extension of the RS flip flop. In addition to the set and reset lines of the RS flip flop it uses J, K and a clock input.<br />
The J line serves as a clock dependent set input while the K line does the reset job. Optionally, a clock input may be provided. State changes do not occour immediately, but on the next raising edge of the clock signal. The state of J=K=true causes the output to toggle it's current state on the next raising edge of the clock signal.<br />
If no clock signal is provided, the frame rate serves as the clock input.<br />
<br />
Example: simple JK flip flop with negative edge clock<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>JK</type><br />
<J><br />
<property>/myflipflop/set</property><br />
</J><br />
<K><br />
<property>/myflipflop/reset</property><br />
</K><br />
<clock><br />
<not><br />
<property>/myflipflop/clock</property><br />
</not><br />
</clock><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== D flip flop &lt;D&gt; ===<br />
The D flip flop transfers the state of the input signal '''D''' to the output line at the next raising edge of the clock signal, which is mandatory for this flip flop.<br />
<br />
Example: simple D flip flop with inverted output<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>D</type><br />
<D><br />
<property>/myflipflop/data</property><br />
</D><br />
<clock><br />
<property>/myflipflop/clock</property><br />
</clock><br />
<output>/myflipflop/output</output><br />
<inverted type="bool">true</inverted><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== T flip flop &lt;T&gt; ===<br />
The T flip flop toggles the state of the output signal at the next raising edge of the clock signal, which is mandatory for this flip flop.<br />
<br />
Example: simple T flip flop<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<type>T</type><br />
<clock><br />
<property>/myflipflop/clock</property><br />
</clock><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
=== Monostable flip flop &lt;monostable&gt; ===<br />
A monostable flip flop has only one stable state which will be reentered after a well defined time. The stable state in current implementation is the output set 'false' or 0. The Monostable is an extension of the JK flip flop. Additionally to the input values defined there, an InputValue for the definition of the pulse time is mandatory. <br />
<br />
The moment the time for the astable state starts counting depends on the input used to set the output. If the output is set from the SET input of the RS flipflop, the output is kept true for the defined time ''after'' the SET input enters it's false state. The total time the output is true equals the time, the SET input is true plus the time defined in the <time> element.<br />
If the output is set from the J and clock inputs of the JK flipflop, the timer starts on the raising edge of the clock input. The output signal will be true for exactly the time defined in the <time> element. <br />
<br />
{{note|The optional <R> and <K> inputs may be used to reset the output before the internal timer expired. This will also reset the timer to zero, so no additional event will be triggered after the defined timer interval.}}<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<name>Test mf</name><br />
<type>monostable</type><br />
<time><br />
<property>/myflipflop/pulsetime-sec</property><br />
<value>10</value><br />
</time><br />
<S><property>/myflipflop/s</property></S><br />
<J><property>/myflipflop/j</property></J><br />
<clock><property>/myflipflop/clock</property></clock><br />
<output>/myflipflop/output</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
The following example shows how a monostable can be used to enable a certain property (/myflipflop/output) if another property (/myflipflop/s) is true for at least the specified amount of time:<br />
<br />
<syntaxhighlight lang="xml"><br />
<flipflop><br />
<name>Test mf</name><br />
<type>monostable</type><br />
<inverted type="bool">true</inverted><br />
<S><br />
<not><br />
<property>/myflipflop/s</property><br />
</not><br />
</S><br />
<time><br />
<value>10.0</value><br />
</time><br />
<output><br />
<property>/myflipflop/output</property><br />
</output><br />
</flipflop><br />
</syntaxhighlight><br />
<br />
In this example the monostable is inverted, which means the stable state is true instead of false. The key idea here is to keep the monostable in its unstable state (false) by keeping the set line true, which is the case when /myflipflop/s is false. Then, when /myflipflop/s becomes true the set line becomes false, which causes the timer to start. When the timer expires (in this case 10 seconds) the monostable will enter its stable state (true). At any time when the set line becomes true (when /myflipflop/s becomes false) the monostable will immediately enter its unstable state (false) again, resulting in /myflipflop/output to become false immediately.<br />
<br />
== Filters &lt;filter&gt; ==<br />
<br />
=== Pure gain filter &lt;gain&gt; ===<br />
A gain filter multiplies the <input> value by a given factor or gain <gain> and returns the output to <output>. More than one <gain> element formatted as in [[Autopilot Configuration Reference#Input Values|Input Values]] may be present. Within a <condition> evaluating as true the first <gain> will define the used gain.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>gain</type><br />
<gain>6.28</gain><br />
<input>radius</input><br />
<output>circumfence</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== First order low pass filter &lt;exponential&gt; ===<br />
The exponential filter is a typical [http://en.wikipedia.org/wiki/Low-pass_filter low pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, lower frequencies can pass this filter while higher frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <filter-time> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency).<br />
<br />
Example: a 1Hz first order low pass filter <br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>exponential</type><br />
<filter-time>0.16</filter-time><br />
<input>/some/input</input><br />
<output>/some/output/</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
<br />
<br />
=== First order high pass filter &lt;high-pass&gt; ===<br />
The high pass filter is a typical [http://en.wikipedia.org/wiki/High-pass_filter high pass filter]. The magic euler number and the associated mathematical funtion exp() plays a major role here. As the name implies, higher frequencies can pass this filter while lower frequencies are cut. The frequency where only half of the input signal reaches the output is called cutoff frequency. This cutoff frequency is defined by the parameter <filter-time> and resolves as cutoff-frequency = 1/(2*pi*cutoff-frequency). It is commonly known as a wash-out filter or a 1st order lead filter<br />
<br />
Example: a 1Hz first order high pass filter <br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>high-pass</type><br />
<filter-time>0.16</filter-time><br />
<input>/some/input</input><br />
<output>/some/output/</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Second order low pass filter &lt;double-exponential&gt; ===<br />
The double exponential filter is a low pass filter like the exponential filter with a steeper slope of the filter diagram. It acts basically like two chained exponential filters and it is some times called second order filter. <br />
<br />
The configuration is the same for exponential and double-exponential filters, just the type entry differs.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>double-exponential</type><br />
<filter-time>0.16</filter-time><br />
<input>/some/input</input><br />
<output>/some/output/<output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Moving average filter &lt;moving-average&gt; ===<br />
Calculates average of specified number of values.<br />
<br />
Currently the average length can only be given as number of samples and not time.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>moving-average</type><br />
<samples>120</samples><br />
<input>/some/input</input><br />
<output>/some/output</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Rate limit filter &lt;noise-spike&gt; ===<br />
A better name for a noise spike filter would probably have been "rate limit filter". This is exactly what it does: limit the rate of change of the output value. The relevant configuration element is <max-rate-of-change> setting the maximum rate of change of the output property per second.<br />
<br />
Example: A transition from 0 to 4 at the input property results in a linear increase of the output property over 8 seconds from 0 to 4 at a rate of 0.5/sec.<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>noise-spike</type><br />
<max-rate-of-change>0.5</max-rate-of-change><br />
<input>/some/input</input><br />
<output>/some/output</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Reciprocal filter &lt;reciprocal&gt; ===<br />
Compute the reciprocal (1/x) value of the input property. If x is zero, no computation is performed. The optional <gain> element may be used to scale the value. Output computes as gain divided by input.<br />
<br />
Example: compute the flight time per pound of burned fuel from the fuel flow<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>reciprocal</type><br />
<gain>1.0</gain><br />
<input>/engines/engine[0]/fuel-flow-pph</input><br />
<output>/engines/engine[0]/fuel-flow-hpp</output><br />
</filter><br />
</syntaxhighlight><br />
<br />
=== Derivative filter &lt;derivative&gt; ===<br />
Compute first time derivative of the input property, that is change per unit of time. Time is measured in seconds. A <filter-time> acts as gain and must be given because it has default 0.<br />
<br />
Example: compute derivative of static port pressure<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<type>derivative</type><br />
<input>systems/static[0]/pressure-inhg</input><br />
<output>autopilot/internal/pressure-rate</output><br />
<filter-time>1.0</filter-time><br />
</filter><br />
</syntaxhighlight><br />
<br />
== PID controller &lt;pid-controller&gt; ==<br />
The [http://en.wikipedia.org/wiki/PID_controller PID controller] is the swiss army knife of automation and this implementation is suitable for most situations. It has a builtin anti-windup logic, and usage of <max> and <min> elements for clamping the output is mandatory. The most important thing to know is that this controller 'does not' compute absolute output values but an offset from the current value of the output property. This can lead to unexpected behavior if the current value of the output property is unknown when the controller is enabled. This behavior is different to that of the pi-simple-controller.<br />
The xml element creating a pid controller is <tt><pid-controller></tt>.<br />
<br />
Legal elements are:<br />
<br />
{| class="prettytable"<br />
!Kp<br />
|the overall gain for the proportional, integral and derivative part<br />
|-<br />
!Ti<br />
|integrator time<br />
|-<br />
!Td<br />
|derivator time<br />
|-<br />
!Ts<br />
|sampling interval (default: sample at frame rate)<br />
|-<br />
!alpha<br />
|scaling factor for Td (defaults to 0.1)<br />
|-<br />
!beta<br />
|reference weighing factor for the proportional component (defaults to 1.0)<br />
|-<br />
!gamma<br />
|reference weighing factor for the derivate component (defaults to 0.0)<br />
|}<br />
<br />
== PI controller &lt;pi-simple-controller&gt; ==<br />
This controller implements a PI controller. Other than the PID controller, it computes absolute output values, regardless of the value of the output property. It can by configured as an I-only, P-only or PI-controller. It has anti windup logic if <min> and <max> elements are present.<br />
The xml element creating a PI controller is <tt><pi-simple-controller></tt><br />
Legal elements are:<br />
<br />
{| class="prettytable"<br />
!Kp<br />
|gain of the proportional component<br />
|-<br />
!Ki<br />
|gain of the integrator component<br />
|}<br />
<br />
== Predictor &lt;predict-simple&gt; ==<br />
Estimates the future value for a given property based on its current (or averaged) rate of change.<br />
<br />
Legal elements are:<br />
<br />
{| class="prettytable"<br />
!seconds<br />
|the time to be estimated ahead<br />
|-<br />
!filter-gain<br />
|Smoothing factor (0.0-1.0, 1.0=no smoothing)<br />
|}<br />
<br />
Example: compute estimated speed 5 seconds ahead<br />
<br />
<syntaxhighlight lang="xml"><br />
<predict-simple><br />
<name>predicted air speed 5 seconds ahead</name><br />
<debug>false</debug><br />
<input>velocities/airspeed-kt</input><br />
<output>autopilot/internal/airspeed-5-sec-ahead</output><br />
<seconds>5.0</seconds><br />
<filter-gain>0.1</filter-gain><br />
</predict-simple><br />
</syntaxhighlight><br />
<br />
== State Machine &lt;state-machine&gt; ==<br />
For a discription of what a state machine can do, look here: [http://en.wikipedia.org/wiki/Finite-state_machine].<br />
<br />
<state-machine><br />
<branch>/my-statemachine</branch><br />
<state><br />
<name>init</name><br />
<enter><br />
<binding></binding><br />
<binding></binding><br />
</enter><br />
<exit><br />
<binding></binding><br />
</exit><br />
<update><br />
<binding></binding><br />
</update><br />
</state><br />
<state><br />
<name>finished</name><br />
<enter>Zero to many bindings, fired upon state enter</enter><br />
<exit>Zero to many bindings, fired upon state exit</exit><br />
<update>Zero to many bindings, fired upon every state change</update><br />
</state><br />
<transition><br />
<name>ready</name><br />
&lt;source&gt;init</source><br />
<target>finished</target><br />
<exclude-target type="bool">true</exclude-target><br />
<condition><br />
<greater-than><br />
<property>/sim/time/elapsed-sec</property><br />
<value>30</value><br />
</greater-than><br />
</condition><br />
<binding>Zero to many bindings, fired upon state change</binding><br />
</transition><br />
</state-machine><br />
<br />
Legal elements for the state machine are:<br />
<br />
{| class="prettytable"<br />
!branch<br />
|A path to a property node where the internal states of the machine gets written to. Can be empty.<br />
|-<br />
!state<br />
|Two ore more state elements are required for a minimal state machine<br />
|-<br />
!transition<br />
|Any number of transition elements. Describes how to change from one state to another.<br />
|}<br />
<br />
<br />
Legal elements for the state element are:<br />
<br />
{| class="prettytable"<br />
!name<br />
|required, gives the state a name for reference<br />
|-<br />
!enter<br />
|optional, zero to many enter elements containing a SGBinding to fire upon state enter<br />
|-<br />
!exit<br />
|optional, zero to many exit elements containing a SGBinding to fire upon state exit<br />
|-<br />
!update<br />
|optional, zero to many update elements containing a SGBinding to fire upon state change<br />
|}<br />
<br />
Legal elements for the transition element are:<br />
<br />
{| class="prettytable"<br />
!name<br />
|required, gives the transition a name for reference<br />
|-<br />
!source<br />
|required, one to many source elements containing the name of a source state<br />
|-<br />
!target<br />
|required, exactly one target element defining the target state<br />
|-<br />
!condition<br />
|required, contains a SGCondition when this state change occours<br />
|-<br />
!exclude-target<br />
|optional, boolean flag defaults to true. Indicates if this transition should be evaluated even if current state equals target<br />
|-<br />
!binding<br />
|optional, zero to many binding elements containing a SGBinding to fire when this transition triggers<br />
|}<br />
== Proposed extensions ==<br />
This sections contains new features for the autopilot to be implemented. Nobody knows if and when this will happen. Consider this as a collection of ideas as a base for discussion on the mailing list, the forum or IRC.<br />
<br />
== Related content ==<br />
=== Readme file ===<br />
: ''This file can also be found in [[$FG_ROOT]]/Docs.''<br />
<br />
* {{Git link|gitorious|fg/fgdata|master|Docs/README.digitalfilters|text=README.digitalfilters}}<br />
<br />
=== Source code ===<br />
* {{Git link|gitorious|fg/flightgear|next|src/Autopilot/digitalfilter.hxx}}<br />
* {{Git link|gitorious|fg/flightgear|next|src/Autopilot/autopilot.cxx}}<br />
<br />
[[Category:Aircraft enhancement]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Changelog_3.2&diff=77101Changelog 3.22014-10-12T21:02:42Z<p>T3r: /* Major enhancements in this release */</p>
<hr />
<div>{{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]].<br />
Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.<br/>It's a good idea to check [[:Category:Changes_after_3.00|the newsletters since the last release]], and the git commit history.<br />
To view the changelog for the most recent release, please see [[Changelog 3.0]]. <br />
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!<br />
<br />
}}<br />
<br />
==Upcoming FlightGear Changelog==<br />
The FlightGear development team is delighted to announce the v3.2 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include ... <br />
<br />
Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create <br />
the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world <br />
by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.<br />
<br />
FlightGear features more than 400 aircraft, a worldwide scenery database, a multi-player environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute. <br />
<br />
Download FlightGear v3.2 for free from [http://www.flightgear.org FlightGear.org].<br />
<br />
FlightGear - Fly Free!<br />
<br />
=== Breaking Changes ===<br />
<br />
<br />
=== Major enhancements in this release ===<br />
<br />
'''Surface Light Effects & OpenSceneGraph 3.2'''<br />
<br />
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.<br />
<br />
The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.<br />
<br />
Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your<br />
build fails, please check you've got a recent OSG build installed.<br />
<br />
'''Core'''<br />
* [[Reset & re-init]] is merged and now enabled<br />
* A segfault related to scripted Nasal fgcommands (like used in joystick and other bindings) has been fixed {{Issue|1397}}<br />
* YASim now has versioning support. The YASim FDM now checks a version tag in it's configuration file to eventually provide backward compatibility.<br />
* A text-to-speech system based on flite+hts_engine has been implemented. <br />
* ATIS messages, previously hard coded in C++, are now generated based on customizable XML configuration files. Their audio now gets generated by the new text-to-speech system.<br />
* Windows dependencies have been updated<br />
* The integrated [[Map]] dialog now uses an azimuthal equidistant projection, for better representation in polar regions and across the International Date Line.<br />
* A new internal web server (aka httpd) based on mongoose httpd has been added. It supports various AJAX requests, a screenshot server, a property tree browser and much more.<br />
* A web browser based moving map has been added using the new AJAX capabilities of FlightGear<br />
<br />
'''Aircraft Modeling'''<br />
* [[A Failure Management Framework for FlightGear]] has been added<br />
* Additional aircraft have started adopting the [[NavDisplay|Canvas navigation display]] that was introduced with FlightGear 3.0.<br />
<br />
'''JSBSim'''<br />
* The JSBSim flight dynamics model now has support for ground effects like bumpiness, solid-ground detection and adjusting of friction factors. Additionally, bogey type contact points sink in non-solid surfaces, making it no longer possible to ride on water.<br />
<br />
'''Atmospheric Light Scattering'''<br />
<br />
Atmospheric Light Scattering (ALS) is one of FlightGear's three rendering frameworks, with the aim of providing an integrated simulation of the interaction between weather, light and the environment.<br />
<br />
Additions to ALS in version 3.2 include:<br />
<br />
* an experimental framework to render cloud shadows on the ground (requires Advanced Weather)<br />
* a substantial extension of cloud layer visibility using impostor techniques to 150 km<br />
* a new agriculture effect allowing to render fields without tiling artifacts<br />
* a new forest effect to simulate managed forest, varying tree size by patch<br />
* sparkle and fog effect on runway lights<br />
* much improved visual appearance of rock faces<br />
<br />
<br />
'''Environment Rendering'''<br />
<br />
* EarthView, a simple orbital rendering engine based on projecting a textured sphere into the scene. By default, EarthView uses low resolution textures, however using hires textures e.g. from the NASA [http://visibleearth.nasa.gov/ Visible Earth] project very realistic results from altitudes above 100 km can be achieved.<br />
* New deciduous and needle tree textures with much improved visuals<br />
* New regional texture definitions for Ireland, Alaska/Northwest territories and US Southwest <br />
<br />
'''Performance'''<br />
As a side effect of a fixed bug, a huge performance boost with respect to frame rate can be seen on some machines. The implementation of a Uniform-Cache for shader-effects has reduced the CPU workload significantly.<br />
<br />
<br />
'''Misc/Uncategorized'''<br />
* AIModels use PagedLOD<br />
* Optimise NavCache airport query<br />
* osg::Switch for masking scenery rendering<br />
* Torsten's metar work, newradio, mongoose httpd<br />
* HTTP: improve handling of connection errors<br />
* Windows installer has been reworked<br />
* Windows installer creates 3 news directories pre-configured in FGRun:<br />
** {user}\Documents\FlightGear\Aircraft<br />
** {user}\Documents\FlightGear\TerraSync<br />
** {user}\Documents\FlightGear\Custom Scenery<br />
<br />
''' Usability '''<br />
* Windows users are now able to use the scroll wheel in dialog lists<br />
<br />
''' Scenery '''<br />
<br />
<br />
'''Canvas System'''<br />
<br />
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. Also, maps can now be mostly customized, including custom styling (colors, fonts, symbols etc).<br />
<br />
* 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].<br />
<!-- code freeze ...<br />
* Hooray is working on adding shader support to Canvas {{Progressbar|30}}<br />
--><br />
* The [[MapStructure]] back-end used by the [[NavDisplay]] now supports symbol instancing, so that performance is improved<br />
* MapStructure-based layers can now be customized and styled<br />
* Tom added support for button/modifiers (mouse handling) [http://wiki.flightgear.org/index.php?title=Canvas_Event_Handling&curid=10777&diff=68569&oldid=68422]<br />
* CanvasImage now supports the ''http://'' protocol for dynamically retrieving raster images. See the renamed [[Canvas_Image#src|src attribute]] (''file'' is now deprecated).<br />
* 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}}<br />
* Custom event handlers can now be registered.<br />
* Canvas Layout Engine<br />
* Canvas-based dialog for downloading aircraft [[Aircraft Center]]<br />
<br />
'''Nasal Scripting'''<br />
<br />
* getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:<br />
<syntaxhighlight lang="nasal"><br />
getprop("canvas/by-index", "texture", 1, "name");<br />
</syntaxhighlight><br />
: is now the same as:<br />
<syntaxhighlight lang="nasal"><br />
getprop("canvas/by-index/texture[1]/name");<br />
</syntaxhighlight><br />
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request 54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])<br />
* A new fully-interactive Nasal GUI console based on [[Canvas]] has been added: [[Interactive Nasal Console]]<br />
* 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. <br />
: Usage:<br />
<syntaxhighlight lang="nasal"><br />
var hist = aircraft.history(); debug.dump(hist.pathForHistory(50));<br />
</syntaxhighlight><br />
* cppbind: Nasal ghosts can now support arbitrary setters/getters for when members are not mapped to a C++ member/method.<br />
* Language enhancements<br />
** Bitwise operators (|, &, ^, ~, |=, &=, ^=)<br />
** Support for octal, decimal and hexadecimal numbers in literals as well as in strings<br />
<br />
'''Documentation'''<br />
<br />
'''Highlighted new and improved aircraft'''<br />
* [[Boeing 757-200]]: Improved autopilot and additional systems, like hydraulics and pneumatic. The aircraft comes with two engine options.<br />
* [[Cessna 337G Skymaster]]: Tuned autopilot and improved instrument stack.<br />
* [[Mainair Flash 2 Alpha]]: Simulated weightshift-control and new wing model.<br />
* [[North American P-51 Mustang|North American P-51D]]: All new highly accurate external model based on factory blueprints.<br />
* [[Tupolev Tu-154B|Tupolev Tu-154B2]]: version 3.1<br />
<br />
'''Other'''<br />
<br />
'''Bug fixes'''<br />
A serious bug has prevented FlightGear version 3.2 being released on time. Identified by the clumsy name "crash in SGPropertyNode::fireValueChanged", this bug clearly was a release blocker and it took a lot of effort to identify the cause for the crash. Finding a solution was even harder but was finally accomplished and presented the nice side-effect of a noticeable performance boost.<br />
* 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.<br />
<br />
[[Category:FlightGear changelogs]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Switching_default_texture_format_to_DDS&diff=76842Switching default texture format to DDS2014-09-30T06:40:09Z<p>T3r: /* NVIDIA open source driver (Nouveau) */</p>
<hr />
<div>The FG development team is considering to '''switch the default format for textures from png to DDS'''. This would offer a number of significant advantages:<br />
<br />
* DDS is a more compact format than png, hence the download size of the FG base package may be decreased<br />
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption<br />
* DDS stores all texture resolution levels, in essence no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory<br />
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost<br />
<br />
Practically all commercial simulations use DDS for these reasons. <br />
<br />
== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==<br />
However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.<br />
<br />
{{FGCquote<br />
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Torsten Dreyer</nowiki><br />
|date=<nowiki>2014-09-03</nowiki><br />
}}<br />
}}<br />
<br />
If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.<br />
In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!<br />
<br />
=== What we need you to do? ===<br />
FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:<br />
<br />
# Open the dialog under View -> Rendering<br />
# Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)' <br />
# Press 'Okay' - FG will reload the terrain<br />
# Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.<br />
# Change back to the texture scheme you like best<br />
# Enter your experiences in the list below<br />
<br />
Thanks for your help!<br />
<br />
== Tested hardware and graphics drivers ==<br />
=== NVIDIA proprietary driver ===<br />
{| class="wikitable sortable"<br />
!Card<br />
!Driver<br />
!DDS ok<br />
!Reported by<br />
|-<br />
|GeForce GTX 670M<br />
|310.19<br />
|{{yes}}<br />
|ThorstenR<br />
|-<br />
|N13M-NS Optimus <br />
|340.32<br />
|{{yes}}<br />
|Tom_ch<br />
|-<br />
|GeForce GT 640 <br />
|343.13<br />
|{{yes}}<br />
|lumni1968<br />
|-<br />
|GeForce GTX 780 Ti<br />
|340.52<br />
|{{yes}}<br />
|Avionyx<br />
|-<br />
|GeForce GT 750M<br />
|331.38<br />
|{{yes}}<br />
|Dutchguy<br />
|-<br />
|GeForce GT 620 OEM<br />
|331.38<br />
|{{yes}}<br />
|C-GGKV<br />
|-<br />
|GeForce GTX 650<br />
|331.20<br />
|{{yes}}<br />
|dany93<br />
|-<br />
|GeForce 210<br />
|304.117<br />
|{{yes}}<br />
|Jean-Philippe<br />
|-<br />
|GeForce GT 520<br />
|332.21<br />
|{{yes}}<br />
|cossack90<br />
|-<br />
|GeForce GTX 260<br />
|304.117<br />
|{{yes}}<br />
|Lann<br />
|-<br />
|GeForce GTS 250<br />
|331.38<br />
|{{yes}}<br />
|Madbyte<br />
|-<br />
|GeForce GTS 450<br />
|340.32<br />
|{{yes}}<br />
|chris_blues<br />
|-<br />
|GeForce 8600 GT<br />
|340.32<br />
|{{yes}}<br />
|szpajder<br />
|-<br />
|GeForce GTX 460 SE<br />
|331.38<br />
|{{yes}}<br />
|f-jjth<br />
|-<br />
|GeForce GTX 560 Ti<br />
|319.32<br />
|{{yes}}<br />
|PATTEN<br />
|-<br />
|GeForce 8600 GT<br />
|331.38<br />
|{{yes}}<br />
|attila<br />
|-<br />
|GeForce GTX 750 ti<br />
|340.32<br />
|{{yes}}<br />
|f-toro<br />
|-<br />
|GeForce GT 650M <br />
|Apple OS 10.9.4<br />
|{{No}}<br />
|dersh<br />
|-<br />
|GeForce 9800GTX<br />
|304.117<br />
|{{yes}}<br />
|ctec356<br />
|-<br />
|GeForce GT 220<br />
|331.38<br />
|{{yes}}<br />
|D-ABEK<br />
|-<br />
|GeForce GTX 760M<br />
|331.38<br />
|{{yes}}<br />
|f-ojac<br />
|-<br />
|GeForce GTX 560<br />
|319.32<br />
|{{yes}}<br />
|[http://fr.flightgear.org/forums/viewtopic.php?pid=28721#p28721 Clm76]<br />
|}<br />
<br />
=== NVIDIA open source driver (Nouveau)===<br />
{| class="wikitable sortable"<br />
!Card<br />
!Driver<br />
!DDS ok<br />
!Reported by<br />
|-<br />
|GeForce GT 630<br />
|<br />
|{{no}}<br />
|[https://plus.google.com/111978238381658236898/posts/VYSusMLRiH2 Jakub Klawiter]<br />
|-<br />
|GeForce GT 220<br />
|<br />
|{{no}}<br />
|D-ABEK<br />
|-<br />
|GeForce GTX460<br />
|<br />
|{{no}}<br />
|[[User:T3r]]<br />
|-<br />
|}<br />
<br />
=== Intel proprietary driver ===<br />
<br />
=== Intel open source driver ===<br />
{| class="wikitable sortable"<br />
!Card<br />
!Driver<br />
!libtxc_dxtn installed?<br />
!DDS ok<br />
!Reported by<br />
|-<br />
|HD Graphics 3000 (i7-2600K)<br />
|10.2.6<br />
|{{n/a}}<br />
|{{yes}}<br />
|cdesai<br />
|-<br />
|HD Graphics 3000 (i3-2330M)<br />
|10.2.2<br />
|{{n/a}}<br />
|{{yes}}<br />
|Flyhigh/saiarcot895<br />
|-<br />
|HD Graphics Sandy Bridge (Pentium B980)<br />
|10.1.0<br />
|{{no}}<br />
|{{yes}}<br />
|f-jjth<br />
|-<br />
|HD Graphics 4000 Ivy Bridge<br />
|10.3.0<br />
|{{no}}<br />
|{{yes}}<br />
|onox<br />
|}<br />
<br />
=== ATI/AMD proprietary driver ===<br />
{| class="wikitable sortable"<br />
!Card<br />
!Driver<br />
!DDS ok<br />
!Reported by<br />
|-<br />
|ATI Radeon HD 6310<br />
|14.6-1<br />
|{{yes}}<br />
|ZLSA<br />
|-<br />
|AMD Radeon R9 200 Series<br />
|14.4<br />
|{{yes}}<br />
|Richi<br />
|-<br />
|Radeon HD 4850/4870<br />
|legacy 8.97.100.7-4<br />
|{{yes}}<br />
|Jano<br />
|}<br />
<br />
=== ATI/AMD open source driver ===<br />
{| class="wikitable sortable"<br />
!Card<br />
!Driver<br />
!libtxc_dxtn installed?<br />
!DDS ok<br />
!Reported by<br />
|-<br />
|AMD Radeon HD 6570<br />
|10.1.3<br />
|{{yes}}<br />
|{{yes}}<br />
|fgjosh<br />
|-<br />
|-<br />
|AMD Radeon HD 6770<br />
|10.2.5<br />
|{{no}}<br />
|{{no}}<br />
|Mongrol<br />
|-<br />
|AMD Radeon HD 7950<br />
|10.2.1<br />
|{{yes}}<br />
|{{yes}}<br />
|Saga<br />
|-<br />
|AMD Radeon R9 270X<br />
|10.3~git20140805<br />
|{{no}}<br />
|{{no}}<br />
|nine<br />
|-<br />
|AMD Radeon R9 270X<br />
|10.3~git20140805<br />
|{{yes}}<br />
|{{yes}}<br />
|nine<br />
|}<br />
<br />
== Sample test ==<br />
=== DDS Test at the airport of Orio (Bergamo - Italy) ===<br />
[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this.<BR>These are the parameters used by the startup script "run_fgrun.sh":<br />
{{Note|To reproduce this test, you can use the following [[Fgfsrc]] file - you should set up [[$FG_ROOT]] and [[$FG_SCENERY]] specifically for your own system though.}}<br />
<code><br />
--airport=LIME<br />
--aircraft=757-200-PW2040<br />
--disable-random-objects<br />
--enable-horizon-effect<br />
--enable-enhanced-lighting<br />
--enable-distance-attenuation<br />
--enable-ai-models<br />
--disable-ai-traffic<br />
--disable-real-weather-fetch<br />
--enable-clouds3d<br />
--bpp=32<br />
--texture-filtering=16<br />
--prop:/sim/rendering/multi-sample-buffers=1<br />
--prop:/sim/rendering/multi-samples=4<br />
--timeofday=noon<br />
--enable-terrasync<br />
--httpd=5500<br />
--props=5501<br />
--jpg-httpd=5502<br />
--multiplay=out,10,,0<br />
--multiplay=in,10,,0<br />
--disable-fgcom<br />
</code><br />
<br />
== Excerpts from the ongoing discussion ==<br />
{{FGCquote<br />
|Here is my suggestion how to proceed:<br />
<br />
* Let's do your 1) and 2) on as many information channels we have.<br />
* Collect the responses on a public place, I'd suggest a wiki page<br />
* Do this for a well defined time frame. Is three month too much/too short?<br />
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback<br />
* Keep this for one release.<br />
* Depending on the feedback we get, keep it that way or move entirely to DDS.<br />
<br />
Does that sound reasonable for everybody?<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Torsten Dreyer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
== Misc ==<br />
{{FGCquote<br />
|I'd propose [...] this process:<br />
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.<br />
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.<br />
<br />
I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
== DDS Debate in 2012 ==<br />
=== Legalities ===<br />
{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}<br />
<br />
{{FGCquote<br />
|These kind of precompressed images limits their usage to a specific set of <br/><br />
drivers. And no, due to the patent issues no open source code including ours <br/><br />
is allowed to implement compression/decompression code for these image <br/><br />
formats. Even if this is easy implementation wise.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-29</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|t is technically incorrect to provide these s3 patent <br/><br />
precompressed textures to a driver that does not announce the apropriate <br/><br />
extension and since we are not allowed to code something that deompresses <br/><br />
this, I think we should avoid using this compression for all the provided <br/><br />
models/textures.<br/><br />
<br/><br />
I think of a warning that is issued from the image loader in flightgear that <br/><br />
detects when these precompressed textures are seen. So even people using <br/><br />
drivers that just offer this extension have a chance to see that the provided <br/><br />
textures will not work for others.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612879/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-01</nowiki><br />
}}<br />
}}<br />
<br />
=== Portability Concerns ===<br />
{{FGCquote<br />
|These kind of precompressed images limits their usage to a specific set of <br/><br />
drivers. And no, due to the patent issues no open source code including ours <br/><br />
is allowed to implement compression/decompression code for these image <br/><br />
formats. Even if this is easy implementation wise.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-29</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|And this is what I try to do now:<br/><br />
Object against using these patented compression algorithms.<br/><br />
I do not care for the on disk format of any image file we have. But the problem <br/><br />
is that some kind of precompression that can be stored in these dds files <br/><br />
cannot be used with other drivers than the closed ati and nvidia ones.<br/><br />
As long as these patented compression techiques are not used, every OpenGL <br/><br />
driver can use this and displays this fine.<br/><br />
<br/><br />
Think: Intel has the hugest marketshare in graphics today. If I remember <br/><br />
right, they sell more than ati and nvidia together (*). This kind of change in <br/><br />
effect rules out the majority of users as intel cannot work with these files.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-29</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably <br/><br />
have the same effect. So I think simply ommitting DDS is ok?<br/><br />
<br/><br />
Also, much more important, the comment is not about 'your video driver'. It is <br/><br />
in your (Vivian) case even wrong. Your driver will display this fine.<br/><br />
So, in the end I do not care if it is 'your particular video driver' that does <br/><br />
not like this. You will just see this in the best case as the models look <br/><br />
wrong, and in the worst case fgfs just crashes the driver if these textures <br/><br />
are used.<br/><br />
What I really care about is that these files are expected not to work on a huge <br/><br />
amount of graphics boards out there. The point is to tell people doing <br/><br />
textures that they should omit compression so that this message disapears.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|I would like to have a flightgear that is by default just running on every <br/><br />
average system. Having this run faster on a special configured system with some <br/><br />
better configuration options and hand tuned hardware and drivers is very fine.<br/><br />
But without tuning it must at least work in an acceptable way.<br/><br />
<br/><br />
I have checked in a change to flightgear to make the use of the compressed <br/><br />
internal formats a starttime configuration option.<br/><br />
I am still interrested if we have that hangs also with texture compression <br/><br />
disabled and without providing precompressed dds textures?<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28602775/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-29</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|this is the reason for the message. If your machine would refuse to display this you, <br/><br />
developing that, would probably just say 'nice try, but it does not work' <br/><br />
before you check in something. In the case it displays fine, you probably say <br/><br />
'it works here, so I assume it works also for others, lets do'.<br/><br />
And the message tells you, 'despite of just seeing this working on this <br/><br />
current machine, it does not work for others'.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Seriously, I think plenty people not being on this list today and probably <br/><br />
never will be in touch with anybody here, will run into this issue.<br/><br />
People here are those few guys from the power users that want to develop this <br/><br />
stuff.<br/><br />
<br/><br />
I am not going to discuss the patent stuff. Please search the mesa-dev archives <br/><br />
for the discussion and see there why they think that the nvidia tools and <br/><br />
other stuff out there cannot be used. Really - it is not that the code for that <br/><br />
is too dificult or unavailable. I am not a lawyer and I cannot change this <br/><br />
world - even if I would like to in this regard.<br/><br />
<br/><br />
I agree that techically for drivers/gpus supporting these compression formats <br/><br />
it would be best to use these precompressed files.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Seriously, I think plenty people not being on this list today and probably <br/><br />
never will be in touch with anybody here, will run into this issue.<br/><br />
People here are those few guys from the power users that want to develop this <br/><br />
stuff.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Your driver will display this fine.<br/><br />
So, in the end I do not care if it is 'your particular video driver' that does <br/><br />
not like this. You will just see this in the best case as the models look <br/><br />
wrong, and in the worst case fgfs just crashes the driver if these textures <br/><br />
are used.<br/><br />
What I really care about is that these files are expected not to work on a huge <br/><br />
amount of graphics boards out there. The point is to tell people doing <br/><br />
textures that they should omit compression so that this message disapears.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
=== Approaches ===<br />
{{FGCquote<br />
|Well, the default f16 does not work anymore for example.<br/><br />
I have also never tried the new textures, but I assume that these also contain <br/><br />
precompressed data? Also you claimed that the old texture files start to bitrot <br/><br />
comared to the new ones which makes me think that the new standard should be <br/><br />
the dds files. This together makes me think that the dds files should replace <br/><br />
the traditional image files.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-29</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Hmm, regarding dds.<br/><br />
I have to say, that not all OpenGL drivers support texture compression, and <br/><br />
the models with dds files, are those that I cannot display, because of that.<br/><br />
And in fact this will not happen to the open source drivers before something <br/><br />
about 2020 because of patent issues.<br/><br />
<br/><br />
Sorry to step in this so late - probably way too late - but is there a reason <br/><br />
that the on disk format must be compressed?<br/><br />
The previous strategy to have on disk an format that everybody can read and to <br/><br />
make the driver compress them as needed/possible is better I think?<br/><br />
<br/><br />
So, for me the f16 lost its livery lately - where I can live with this for the <br/><br />
f16, I hope that this does not happen to flightgear as a whole ...<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28594472/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-27</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Well, I hope that we can get rid of the compression.<br/><br />
Can somebody with the apropriate tools convert the compressed textures to non <br/><br />
compressed ones? That could still be dds, but dds without these compressions <br/><br />
that produce the warning. So no problem with cubemaps in dds as long as the <br/><br />
compression is not there.<br/><br />
Then *everybody* is again able to use this stuff.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678109/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|I can see several approaches:<br/><br />
<br/><br />
* Just do not use the patented compression stuff. The precomputed mipmaps could <br/><br />
probably do the job of avoiding the hangs (hopefully? to be checked?). May be <br/><br />
we could lower disk space usage by providing a dds.gz or similar wrapper?<br/><br />
<br/><br />
* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu <br/><br />
in the database loader thread. This would help all textures not only the ones <br/><br />
that could be converted. May be this is the most generic solution.<br/><br />
<br/><br />
* Implement some kind of image lookup order that knows if the compressed files <br/><br />
could be handled or not. On loading an image in case of available compression <br/><br />
first try to find a dds file with the same name of the original one. That <br/><br />
involves some 'magic' which often leads to problems but that could at least <br/><br />
work.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/<br />
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &<br />
buildings)</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-30</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Next step is to make sure that compression is not required to avoid the hangs.<br/><br />
My favorite bet would be that then the new configure option regarding texture <br/><br />
compression needs to be set to none.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/<br />
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &<br />
buildings)</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-30</nowiki><br />
}}<br />
}}<br />
<br />
=== Precomputed mipmaps ===<br />
{{FGCquote<br />
|Could we do dds files without compression but with precomputed mipmaps?<br/><br />
<br/><br />
So at next, can you try out which combination of compression/provided <br/><br />
mipmaps/forced simgear compression still work fine?<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28603114/<br />
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2011-12-29</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|The 4. Method that I can imagine is to precompute the mipmaps in the loader.<br/><br />
IIRC tests with some of the guys suffering from this problem, providing <br/><br />
premipmapped but uncompressed dds files had helped to get a fluent viewer.<br/><br />
The argument against providing these dds files in general was that these files <br/><br />
are really huge because of not including any compression and having all the <br/><br />
mipmaps.<br/><br />
But that means we could at the point where the warning happens compute the <br/><br />
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be <br/><br />
used to do this I think (or something similar not requireing a context). This <br/><br />
one is an imported version of the original glu function that is included in <br/><br />
osg for running on an EGL stack which no longer provides GLU.<br/><br />
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and <br/><br />
scale this to the 2. mipmap and so forth.<br/><br />
<br/><br />
This would have the advantage that the png's do not deviate from the dds files <br/><br />
over time.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571679/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-07-21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|I think then, computing mipmaps for any texture file on the CPU in the loader <br/><br />
thread should globally improove the situation.<br/><br />
Also avoiding the compression already in the files should help every use case. <br/><br />
Except that the on disk memory consumption is higher.<br/><br />
Well and except that the database loader has more work to do on the CPU.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612897/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-01</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Doing that differently will provide some overhead that could be kept at a <br/><br />
minimum I think:<br/><br />
For the disk usage, I think gzip compressing these will work sufficiently fine.<br/><br />
Ram usage of the images should not hurt too much. Sure the images are bigger <br/><br />
in memory. But fgfs is not just about images - far from that.<br/><br />
On the GPU, you can still use compression for the textures as the internal <br/><br />
format. This is what flightgear tries to do if the extension is supported <br/><br />
(checked by osg).<br/><br />
<br/><br />
The major point is that there are several ways that use slightly more <br/><br />
resources to get around this problem.<br/><br />
But once the patented compression is on disk, there is *no* way back for <br/><br />
people not having this feature.<br/><br />
<br/><br />
If you have better ideas that do not rule out intel and the oss drivers, you <br/><br />
are welcome!<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this <br/><br />
also the case for the default win32 case? Is there a osgdb_gz.dll or something <br/><br />
along the lines in the directory containing the plugins?<br/><br />
<br/><br />
If yes, we can already tackle the size problem of the uncompressed dds files on <br/><br />
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and <br/><br />
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. <br/><br />
And I assume that this works fine for all unix like operating systems including <br/><br />
mac?!<br/><br />
James?<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-01-15</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|What about solution 6 with (uncompressed premipmapped dds).gz?<br/><br />
On linux this should work as long as you have zlib installed which could be <br/><br />
regarded as a system library there.<br/><br />
Can we rely on zlib being compield into our osg distributions on win32? We do <br/><br />
need zlib in any case, it's mostly about teaching osg that it finds our zlib on <br/><br />
configure and build the gz plugin.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571819/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki><br />
|author=<nowiki>Mathias Fröhlich</nowiki><br />
|date=<nowiki>2012-07-21</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|I implemented a mipmap control and generation tool in effects when I last updated<br/><br />
the urban shader. For the moment, it relies on hardware when the average operator <br/><br />
is used for all texture channels but it could easily be modified to compute <br/><br />
all mipmap on the CPU. look the <mipmap-control> effect option and <br/><br />
mipmap.[ch]xx in SG material lib<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606692/<br />
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees<br />
& buildings)</nowiki><br />
|author=<nowiki>Frederic Bouvier</nowiki><br />
|date=<nowiki>2011-12-30</nowiki><br />
}}<br />
}}<br />
<br />
== Implementation ==<br />
{{FGCquote<br />
|As has been previously pointed out, the current DDS texture set is not<br/><br />
simply the global png texture set converted.<br/><br />
<br/><br />
For our own sanity and those of the users, we need to ensure that there's<br/><br />
an apples-to-apples comparison being made when we change the default. I<br/><br />
therefore think we need to create a DDS version of the current default<br/><br />
texture set.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Stuart Buchanan</nowiki><br />
|date=<nowiki>2014-09-04</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|2) If we go down this path, we probably want to separate the underlying<br/><br />
texture format from the materials.xml definition entirely. For example, we<br/><br />
could simply remove the extention from the materials definition, and have<br/><br />
the C++ code append the appropriate extension based on a separate property.<br/><br />
This has a couple of advantages:<br/><br />
a) Makes testing easier and materials definitions less error-prone.<br/><br />
Assuming we have some batch job in place to generate dds textures, those<br/><br />
working on materials definitions could continue to work with png textures,<br/><br />
and only convert to dds as a final step (or indeed as part of the "make<br/><br />
release" jobs).<br/><br />
a) Avoids duplication of materials definitions. Having just spent quite a<br/><br />
bit of time making the materials definitions more efficient, I'd like to<br/><br />
avoid making it worse again!<br/><br />
<br/><br />
I'm quite happy to do the C++ coding required for this in the materials<br/><br />
loader - it's probably pretty straightforward.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Stuart Buchanan</nowiki><br />
|date=<nowiki>2014-09-04</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|That does leave the issue of what happens to the existing dds texture<br/><br />
definitions where there are special mipmap layers. I'd suggest that we<br/><br />
have some Clever Script (tm) that is able to work out whether the DDS or<br/><br />
PNG version of a texture is the master, and then generate the other version<br/><br />
from it. I admit that the PNG conversion of the DDS will lose some<br/><br />
information in this process, but it would allow those without DDS support<br/><br />
to at least use the textures.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Stuart Buchanan</nowiki><br />
|date=<nowiki>2014-09-04</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|3) We need a sensible process for dealing with aircraft, which has been<br/><br />
identified as a significant issue. Again, I think more aircraft developers<br/><br />
find .png easier to deal with, and there are a lot of aircraft out there<br/><br />
that would need conversion. It feels like we need some build scripts to<br/><br />
"compile" aircraft to use DDS textures.<br/><br />
<br/><br />
A more far-fetched idea might be to have a cache of dds textures that are<br/><br />
generated on-the-fly, or when aircraft are loaded by the aircraft center.<br/><br />
Clearly that impacts initial load time the first time a new aircraft is<br/><br />
loaded, and would increase the size of .fgfs/ directories massively, but it<br/><br />
would remove the need for any work by aircraft/scenery developers and could<br/><br />
be made optional.<br/><br />
<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Stuart Buchanan</nowiki><br />
|date=<nowiki>2014-09-04</nowiki><br />
}}<br />
}}<br />
<br />
== Challenges ==<br />
{{FGCquote<br />
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib."<br/><br />
<br/><br />
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons?<br/><br />
<br/><br />
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Another potential option would be to convert regions to .dds but keep <br/><br />
both global-png and global-dds, but making that user-friendly would <br/><br />
require a way to automatically detect lack of .dds support.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/<br />
|title=<nowiki>Re: [Flightgear-devel] Download size,<br />
and hardware support (was .dds textures)</nowiki><br />
|author=<nowiki>Rebecca Palmer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|On my system (Intel Ivybridge), DDS works with or without libtxc, but <br/><br />
this may not be true of all Intel hardware.<br/><br />
<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/<br />
|title=<nowiki>Re: [Flightgear-devel] Download size,<br />
and hardware support (was .dds textures)</nowiki><br />
|author=<nowiki>Rebecca Palmer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|You can specify the dependency on libtxc_dxtn, but then distributions like <br/><br />
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture <br/><br />
compression which is patented in many parts of the world. Linux distributions <br/><br />
therefore cannot ship it. You can easily find it in add-on repositories, but <br/><br />
as I said, distributions would not be able to include FlightGear creating a <br/><br />
huge hurdle to installation for users.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/<br />
|title=<nowiki>Re: [Flightgear-devel] Download size,<br />
and hardware support (was .dds textures)</nowiki><br />
|author=<nowiki>Stefan Seifert</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the <br/><br />
patent at a small cost in visual quality: <br/><br />
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn<br/><br />
That site also states that modern hardware doesn't need this software <br/><br />
fallback anyway (and hence won't hit either this quality loss or the <br/><br />
slowness of any software decoder), but doesn't define "modern hardware".<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/<br />
|title=<nowiki>Re: [Flightgear-devel] Download size,<br />
and hardware support (was .dds textures)</nowiki><br />
|author=<nowiki>Rebecca Palmer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|The dds textures seem to have some advantages over our png textures and <br/><br />
using them is tempting.<br/><br />
But the points from Thorsten R. are good points and if there is any <br/><br />
chance to have a step-wise transition to the new format, I'd prefer that <br/><br />
path.<br/><br />
<br/><br />
Don't we have an alternate dds texture set already in fgdata that is <br/><br />
enabled with an option? What about making this the default, keeping the <br/><br />
png texture set as an alternate. That would get us reports from users <br/><br />
unable to run dds textures and provide an easy fallback method.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Torsten Dreyer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|We currently have regions-png, global-png and global-dds; as I noted <br/><br />
earlier, switching to regions-dds, global-png and global-dds has the <br/><br />
issue that while changing the texture set is easy (dropdown in View > <br/><br />
Rendering Options), knowing that one needs to do so may not be.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Rebecca Palmer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled <br/><br />
by default and switching to xxx-png has to be done in rendering options?<br/><br />
<br/><br />
Torsten<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Torsten Dreyer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Changing the default (which is in preferences.xml) is easy: the problem <br/><br />
is how do users with non-.dds-supporting hardware (if this exists) know <br/><br />
they need to change back.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Rebecca Palmer</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
== Conversion ==<br />
Also see [[DDS texture conversion]].<br />
<br />
{{FGCquote<br />
|the script take the .dds and not convert the png again if both exist(I remember having manually used "compare" to check if both the dds and the png looks the same, and if not i changed some names)<br/><br />
<br/><br />
notice that the normal maps are a particular case as you need to tell the effect the texture is dds with a line like:<br/><br />
<br/><br />
1<br/><br />
<br/><br />
<br/><br />
just be sure to include this in the normal map effects with png and it will be easier:<br/><br />
<br/><br />
0<br/><br />
<br/><br />
<br/><br />
about FG doing the dds conversion , nvcompress is told to be gpl compatible, but i'm not an expert here:<br/><br />
<br/><br />
http://nvidia-texture-tools.googlecode.com/svn/trunk/NVIDIA_Texture_Tools_README.txt<br/><br />
<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799214/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>jean pellotier</nowiki><br />
|date=<nowiki>2014-09-05</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|I think this is an inheritance from some other game engine using a different convention, and therefore from the authoring tools that were developed for such an engine (photoshop exporter plugins and the like). If indeed the FGFS DDS textures are only meant to be used in FGFS then this should be fixed at the conversion time. Otherwise, if we want other applications to easily reuse the FGFS textures then it would be better to stick to the most common convention. But I think we all agree that the source for any DDS texture should be kept, which pretty much precludes importing ready made DDS textures from 3rd party sources. Incidentally I think importing DDS artwork from other sources should be discouraged, since it will most likely run afoul of the licensing terms of the original copyright owner.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799324/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>TDO Brandano</nowiki><br />
|date=<nowiki>2014-09-05</nowiki><br />
}}<br />
}}<br />
<br />
Nothing as exotic. Just a different "origin" between OpenGL and Direct3D image conventions. OpenGL image origin is located in the lower-left corner, while Direct3D (hence DDS too) considers the top-left as the origin, resulting in a DDS image to appear vertically flipped when read in an OpenGL context. This has repercussions in the way normal-map decoded normals appear (hence the flag in the effects, which signals to the shader to flip the decoded normals). The rest is simply a matter of workflow: either use flipped coordinates and skewed/reversed conventions throughout your whole workflow, or just flip the image and (eventually) set a flag for the shader at "publish" time (said flag could be automatically set by the code on DDS texture load). ''(the latter seems more pragmatic/appealing)''<br />
<br />
{{FGCquote<br />
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/<br />
|title=<nowiki>Re: [Flightgear-devel] Download size,<br />
and hardware support (was .dds textures)</nowiki><br />
|author=<nowiki>Clement de l'Hamaide</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|A few world about the conversion: once a png/rgb/jpg found, the script <br/><br />
try to guess the suitable dds format: with or without alpha channel, <br/><br />
bumpmap, if a .dds is allready found we just erase the png one, if not <br/><br />
we use nvcompress to get the dds. After we change the textures name <br/><br />
called in the differents files and that's it. There's a way to tell the <br/><br />
script what to do for each file, if the automatic mode is a failure.<br/><br />
<br/><br />
I guess speaking theorically is not the best to make an opinion, so if <br/><br />
some of you are interested to make a test, I will make a 3.2 minimal dds <br/><br />
fgdata this we, once on my FG pc.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>jean</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
== Pros ==<br />
{{FGCquote<br />
|I always got a loading problem with png textures, large textures take <br/><br />
seconds to load and convert, and that ruin my close flight where you <br/><br />
can't afford to take pause in the air.<br/><br />
that's why i did a batch script to convert to dds ALL the textures in <br/><br />
the data, not only the matérial set, but everything. Now i only flight a <br/><br />
dds version of flightgear, and am quite happy with it, that's why i <br/><br />
propose to provide a dds fgdata for test, and maybe to make it an <br/><br />
alternate download possibility.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>jean</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
== Cons ==<br />
{{FGCquote<br />
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/<br />
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures)</nowiki><br />
|author=<nowiki>Renk Thorsten</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/<br />
|title=<nowiki>Re: [Flightgear-devel] Download size,<br />
and hardware support (was .dds textures)</nowiki><br />
|author=<nowiki>Saikrishna Arcot</nowiki><br />
|date=<nowiki>2014-09-02</nowiki><br />
}}<br />
}}<br />
<br />
[[Category:Core development projects]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_September_2014&diff=76289FlightGear Newsletter September 20142014-09-15T08:50:46Z<p>T3r: The hidden map</p>
<hr />
<div>{{Newsletter-header|September 2014}}<br />
<div style="border-bottom:3px double #BBB;"><br />
{| width="100%" |<br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}}<br/><br />
{{Newsletter-cover-item|DDS feedback needed}}<br/><br />
{{Newsletter-cover-item|Aircraft moved to SVN}}<br/><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-item|Performance issues}}<br/><br />
{{Newsletter-cover-item|The hidden Map}}<br/><br />
<br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-item|Interview with a contributor}}<br />
|}<br />
</div><br />
<br />
== DDS feedback needed ==<br />
<br />
We are looking for feedback about possibly adopting DDS textures in FlightGear. There are several advantages in doing so:<br />
<br />
* DDS is a more compact format than png, hence the download size of the FG base package may be decreased<br />
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption<br />
* DDS stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory<br />
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost<br />
<br />
Practically all commercial simulations use DDS for these reasons. <br />
<br />
However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by most Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.<br />
<br />
If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.<br />
<br />
Continue reading at [[Switching default texture format to DDS]]...<br />
<br />
== Aircraft moved to SVN ==<br />
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.<br />
The <code>fgdata</code> repo would be a mirror of the base package.<br />
<br />
We finally moved all our aircraft to '''the new SVN repo''': http://sourceforge.net/p/flightgear/fgaddon/<br />
<br />
This repository is named "FGAddon" because its content is not required to run FlightGear but provides a new feature (aircraft in this case); this is usually called an "addon".<br />
<br />
=== Advantages ===<br />
On the user side, the most important feature is to be able to checkout only desired aircraft, as you no longer need to download the 400+ aircraft at once.<br />
<br />
On the developer side, the most important interest is to have a base package (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.<br />
<br />
=== A mini HowTo ===<br />
* For Windows: Install TortoiseSVN (http://tortoisesvn.net/) <br />
* For Linux/Mac: Install SVN<br />
<br />
Then to fetch an aircraft (in this example we pick up the [[DR400 Dauphin]]):<br />
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin<br />
<br />
Then you can regularly fetch the latest updates with<br />
svn up<br />
<br />
If you are used to use Git, <code>svn co</code> and <code>svn up</code> are similar to <code>git clone</code> or <code>git pull</code>.<br />
<br />
The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.<br />
<br />
=== Background ===<br />
For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971<br />
<br />
== Performance Issues ==<br />
Several FlightGear users have pointed out inexplicable "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily. <br />
<br />
So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker. <br />
<br />
As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its knees in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong.<br />
<br />
As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question.<br />
<br />
Also, Hooray recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - it seems that a few contributors are still trying to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work. <br />
<br />
But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:<br />
<br />
* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)<br />
<br />
* [[Testing|Testing Performance]]<br />
<br />
Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.<br />
<br />
People wanting to change that, need to roll up their sleeves and get involved, and PLEAE provide feedback.<br />
<br />
'''All''' testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: [[Howto:Optimizing FlightGear for mobile devices]].<br />
<br />
<br />
And here some initial observations based on running FlightGear on an underpowered Netbook with integrated Intel GMA graphics:<br />
<br />
* our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit<br />
* once the dialog is closed, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!)<br />
* hiding the PUI menubar further helps increase frame rate and improve frame spacing<br />
* hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s<br />
* the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !)<br />
* it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!)<br />
* in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100%<br />
* Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage)<br />
* there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on<br />
<br />
Hooray is hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs.<br />
<br />
If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine.<br />
So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM.<br />
<br />
The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance.<br />
<br />
Unofortunately, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs.<br />
<br />
It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization.<br />
<br />
But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ...<br />
<br />
We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself.<br />
<br />
People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing things in a slow fashion, code that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have: [[FlightGear_Benchmark]].<br />
<br />
If you're interested in getting involved with testing FlightGear and improving compatibility for older/slow systems, please get in touch with Hooray on the forum.<br />
<br />
<gallery mode=packed widths=230px heights=230px><br />
Fgfs 3.2 on a dual-core netbook.png|FlightGear 3.2/Canvas working on a dual-core Netbook with Intel GMA graphics showing the [[Interactive Nasal Console]] dialog<br />
Comparing Native Canvas GUI Performance over PUI.png|A native [[Canvas]] window showing the new [[Aircraft Center]] dialog (good performance)<br />
System-monitor-on-netbook.png|Screen shot showing a number of performance issues in a handful of FG subsystems, especially the PUI GUI<br />
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator<br />
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance)<br />
</gallery><br />
<br />
== The hidden Map ==<br />
[[File:FlightGear-Map-on-Android.png|right|400px]]<br />
Did you know that FlightGear has an internal web server? And did you ever ask yourself the question, what does a flight simulator needs a web server for? A nice and impressive use case is a map application that has just been brought to the main menu. Click on "Equipment" and select "Map (opens in browser)". Your web browser will pop up and show a map based on current web standards. It can display OpenStreetMap maps as a base layer as well as satelite image or roads from MapQuest. Overlays for current (real) weather like precipitation and isobares exist. The map can display FlightGear internal navigation data like airports, navaids etc. And it can display AI traffic and multiplayer aircraft, too.<br />
Of course, it runs on any descent browser, but not only the one on your FlightGear computer. It is web-app-capable so you can install it to your mobile device (IOS and Android) to have a full screen map App on your tablet or phone displaying your current FlightGear status. All this at almost zero cost for the FlightGear main loop. All the rendering computations are done within your browser. The FlightGear webserver only provides the HTML and JavaScript files and transmits the internal properties over a websocket.<br />
To enable the internal browser based map, you need to enable the internal web server by adding <code>--httpd=8080</code> to your command line.<br />
Consult your mobile devices operation manual about how to add a web page as a full screen App.<br />
<br />
<br />
== Interview with a contributor ==<br />
<br />
This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.<br />
<br />
Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.<br />
<br />
'''What is your forum nickname, ZLSA?''' ZLSA.<br />
<br />
'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?<br />
<br />
'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?<br />
<br />
'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.<br />
<br />
'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.<br />
<br />
'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.<br />
<br />
'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.<br />
<br />
'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.<br />
<br />
'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.<br />
<br />
'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.<br />
<br />
'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.<br />
<br />
'''Have you previously used other flight simulators or simulation software in general?''' No.<br />
<br />
'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.<br />
<br />
'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?<br />
<br />
'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.<br />
<br />
'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.<br />
<br />
'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.<br />
<br />
'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.<br />
<br />
'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.<br />
<br />
'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.<br />
<br />
'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)<br />
<br />
'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.<br />
<br />
'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.<br />
<br />
'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...<br />
<br />
'''Is there anything else you'd like to share with us?''' No.<br />
<br />
'''Good day then, and thanks for agreeing to this interview.''' No problem.</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_September_2014&diff=76288FlightGear Newsletter September 20142014-09-15T08:48:10Z<p>T3r: The hidden map</p>
<hr />
<div>{{Newsletter-header|September 2014}}<br />
<div style="border-bottom:3px double #BBB;"><br />
{| width="100%" |<br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}}<br/><br />
{{Newsletter-cover-item|DDS feedback needed}}<br/><br />
{{Newsletter-cover-item|Aircraft moved to SVN}}<br/><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-item|Performance issues}}<br/><br />
| valign="top" width="33%" |<br />
{{Newsletter-cover-item|Interview with a contributor}}<br />
|}<br />
</div><br />
<br />
== DDS feedback needed ==<br />
<br />
We are looking for feedback about possibly adopting DDS textures in FlightGear. There are several advantages in doing so:<br />
<br />
* DDS is a more compact format than png, hence the download size of the FG base package may be decreased<br />
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption<br />
* DDS stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory<br />
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost<br />
<br />
Practically all commercial simulations use DDS for these reasons. <br />
<br />
However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by most Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.<br />
<br />
If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.<br />
<br />
Continue reading at [[Switching default texture format to DDS]]...<br />
<br />
== Aircraft moved to SVN ==<br />
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.<br />
The <code>fgdata</code> repo would be a mirror of the base package.<br />
<br />
We finally moved all our aircraft to '''the new SVN repo''': http://sourceforge.net/p/flightgear/fgaddon/<br />
<br />
This repository is named "FGAddon" because its content is not required to run FlightGear but provides a new feature (aircraft in this case); this is usually called an "addon".<br />
<br />
=== Advantages ===<br />
On the user side, the most important feature is to be able to checkout only desired aircraft, as you no longer need to download the 400+ aircraft at once.<br />
<br />
On the developer side, the most important interest is to have a base package (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.<br />
<br />
=== A mini HowTo ===<br />
* For Windows: Install TortoiseSVN (http://tortoisesvn.net/) <br />
* For Linux/Mac: Install SVN<br />
<br />
Then to fetch an aircraft (in this example we pick up the [[DR400 Dauphin]]):<br />
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin<br />
<br />
Then you can regularly fetch the latest updates with<br />
svn up<br />
<br />
If you are used to use Git, <code>svn co</code> and <code>svn up</code> are similar to <code>git clone</code> or <code>git pull</code>.<br />
<br />
The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.<br />
<br />
=== Background ===<br />
For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971<br />
<br />
== Performance Issues ==<br />
Several FlightGear users have pointed out inexplicable "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily. <br />
<br />
So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker. <br />
<br />
As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its knees in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong.<br />
<br />
As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question.<br />
<br />
Also, Hooray recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - it seems that a few contributors are still trying to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work. <br />
<br />
But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:<br />
<br />
* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)<br />
<br />
* [[Testing|Testing Performance]]<br />
<br />
Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.<br />
<br />
People wanting to change that, need to roll up their sleeves and get involved, and PLEAE provide feedback.<br />
<br />
'''All''' testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: [[Howto:Optimizing FlightGear for mobile devices]].<br />
<br />
<br />
And here some initial observations based on running FlightGear on an underpowered Netbook with integrated Intel GMA graphics:<br />
<br />
* our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit<br />
* once the dialog is closed, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!)<br />
* hiding the PUI menubar further helps increase frame rate and improve frame spacing<br />
* hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s<br />
* the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !)<br />
* it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!)<br />
* in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100%<br />
* Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage)<br />
* there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on<br />
<br />
Hooray is hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs.<br />
<br />
If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine.<br />
So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM.<br />
<br />
The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance.<br />
<br />
Unofortunately, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs.<br />
<br />
It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization.<br />
<br />
But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ...<br />
<br />
We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself.<br />
<br />
People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing things in a slow fashion, code that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have: [[FlightGear_Benchmark]].<br />
<br />
If you're interested in getting involved with testing FlightGear and improving compatibility for older/slow systems, please get in touch with Hooray on the forum.<br />
<br />
<gallery mode=packed widths=230px heights=230px><br />
Fgfs 3.2 on a dual-core netbook.png|FlightGear 3.2/Canvas working on a dual-core Netbook with Intel GMA graphics showing the [[Interactive Nasal Console]] dialog<br />
Comparing Native Canvas GUI Performance over PUI.png|A native [[Canvas]] window showing the new [[Aircraft Center]] dialog (good performance)<br />
System-monitor-on-netbook.png|Screen shot showing a number of performance issues in a handful of FG subsystems, especially the PUI GUI<br />
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator<br />
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance)<br />
</gallery><br />
<br />
== The hidden Map ==<br />
[[File:FlightGear-Map-on-Android.png|right|400px]]<br />
Did you know that FlightGear has an internal web server? And did you ever ask yourself the question, what does a flight simulator needs a web server for? A nice and impressive use case is a map application that has just been brought to the main menu. Click on "Equipment" and select "Map (opens in browser)". Your web browser will pop up and show a map based on current web standards. It can display OpenStreetMap maps as a base layer as well as satelite image or roads from MapQuest. Overlays for current (real) weather like precipitation and isobares exist. The map can display FlightGear internal navigation data like airports, navaids etc. And it can display AI traffic and multiplayer aircraft, too.<br />
Of course, it runs on any descent browser, but not only the one on your FlightGear computer. It is web-app-capable so you can install it to your mobile device (IOS and Android) to have a full screen map App on your tablet or phone displaying your current FlightGear status. All this at almost zero cost for the FlightGear main loop. All the rendering computations are done within your browser. The FlightGear webserver only provides the HTML and JavaScript files and transmits the internal properties over a websocket.<br />
To enable the internal browser based map, you need to enable the internal web server by adding <code>--httpd=8080</code> to your command line.<br />
Consult your mobile devices operation manual about how to add a web page as a full screen App.<br />
<br />
<br />
== Interview with a contributor ==<br />
<br />
This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.<br />
<br />
Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.<br />
<br />
'''What is your forum nickname, ZLSA?''' ZLSA.<br />
<br />
'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?<br />
<br />
'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?<br />
<br />
'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.<br />
<br />
'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.<br />
<br />
'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.<br />
<br />
'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.<br />
<br />
'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.<br />
<br />
'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.<br />
<br />
'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.<br />
<br />
'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.<br />
<br />
'''Have you previously used other flight simulators or simulation software in general?''' No.<br />
<br />
'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.<br />
<br />
'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?<br />
<br />
'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.<br />
<br />
'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.<br />
<br />
'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.<br />
<br />
'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.<br />
<br />
'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.<br />
<br />
'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.<br />
<br />
'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)<br />
<br />
'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.<br />
<br />
'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.<br />
<br />
'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...<br />
<br />
'''Is there anything else you'd like to share with us?''' No.<br />
<br />
'''Good day then, and thanks for agreeing to this interview.''' No problem.</div>T3rhttps://wiki.flightgear.org/w/index.php?title=File:FlightGear-Map-on-Android.png&diff=76287File:FlightGear-Map-on-Android.png2014-09-15T08:47:11Z<p>T3r: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=A Screenshot of FlightGear's browser based map rendered on a Nexud 4 running Android.}}<br />
|date=2014-09-15 10:56:02<br />
|source={{own}}<br />
|author=[[User:T3r|T3r]]<br />
|permission=<br />
|other_versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-3.0}}<br />
<br />
<br />
[[Category:Screenshots]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=User:T3r&diff=71692User:T3r2014-05-20T21:22:59Z<p>T3r: some self-adulation</p>
<hr />
<div>{{User<br />
|name = T3r <br />
|location = near Hamburg, Germany, Europe<br />
|callsign = Torsten, D-GEJL, D-GOOF<br />
|favourite=[[Piper PA34-200T Seneca II]], [[Cessna C172]]<br />
|website =[http://www.t3r.de/ www.t3r.de]<br />
|age = constantly changing<br />
}}<br />
[[Image:T3r.jpg|Hey - that's me!]]<br />
<br />
Contact: '''Torsten''' (at) '''flightgear''' _dot_ '''org'''<br />
<br />
* '''Aircraft'''<br />
** [[Ogel]]<br />
** [[Piper PA34-200T Seneca II]]<br />
** [[Zivko Edge 540]]<br />
** [[Moyes Dragonfly]]<br />
** [[Hamburger Flugzeugbau HFB 320 Hansa Jet]]<br />
** [[Der Kleine Uhu]]<br />
* '''Scenery'''<br />
** Some buildings in my home town Hamburg <br />
** Buildings of my home base Lubeck (EDHL)<br />
** Some buildings of Lelystad (EHLE)<br />
** [http://scenemodels.flightgear.org/author.php?id=20 My scenemodels contribs]<br />
* '''Program'''<br />
** overhauled environment system<br />
** overhauled xml-autopilot system<br />
** overhauled the input system<br />
** added support for generic input devices (linux)<br />
** added the ridge lift from Patrice Poly<br />
** removed dozens of gcc warnings<br />
** overhauled the internal httpd to use mongoose httpd<br />
** added flite+hts_engine text-to-speech<br />
** overhauled the ATIS creation code<br />
** created the comm radio subsystem<br />
** Check [http://www.ohloh.net/accounts/80410?ref=Detailed Ohloh] for commit timeline. <br />
* '''Hardware'''<br />
** Made some USB/HID input devices based on ATMega microcontroller<br />
** Built a FlightGear based [[Howto:_Build_your_own_procedure_trainer|Procedure Trainer]]<br />
* '''Wiki work'''<br />
**[http://wiki.flightgear.org/index.php/Special:Contributions/T3r T3r's wiki contributions]<br />
*'''What the hack means T3r?'''<br />
**That's the acronyme for my name, only decipherable if you speak the german language.<br />
<br />
----<br />
<br />
'''The genuine FlightGear flight simulator is at [http://www.flightgear.org/ www.flightgear.org]. Fly free.'''<br />
<br />
--[[User:T3r|T3r]] 10:33, 12 October 2010 (UTC)<br />
<br />
[[Category: FlightGear Core developers]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_April_2014&diff=69530FlightGear Newsletter April 20142014-04-06T19:28:20Z<p>T3r: /* Scenery corner */</p>
<hr />
<div>{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
{{Newsletter being written}}<br />
== Development news ==<br />
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].<br />
<br />
=== Proof-of-Concept: A TerraGear Web Service (by F-JJTH) ===<br />
{{WIP}} <br />
<br />
As part of prototyping a [[TerraGear scenery build server]], F-JJTH has started working on a proof-of-concept for a web-based TerraGear GUI/build service. This can use the precompiled-TerraGear packages created and provided by saiarcot895. We are currently looking for people interested in picking up this prototype to continue developing it over time. All the difficult bits are now in place (namely the TerraGear setup), as well as a compelling web-based interface. People interested in helping with this, should ideally have some web programming experience, for TerraGear specifics you can probably just get in touch with psadro_gm and papillon81 (or refer to the docs for starters). Also, we're hoping to also create Linux packages for the web interface, so that installation/updates can be just as easily handled using the deb/apt/ppa package manager. <br />
<br />
Primarily, we are now looking for hosting, not just for the TerraGear setup itself (which should be fairly powerful), but also for those deb/apt packages. If you'd like to help with this, please get in touch via the forum.<br />
<br />
<gallery mode=packed widths=230px heights=230px><br />
TerraGear_build_server_concept_map.png|Schematic of a possible setup for TG GUI or a web interface to access TerraGear services provided by a build server<br />
TerraGear-BuildServer-Prototype.png|TerraGear BuildServer Experiments<br />
TerraGear-hgtchop-VM.png|TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages<br />
F-jjth-tggui-prototype.jpg|Web-based TerraGear GUI prototype developed by F-JJTH in 03/2014<br />
</gallery><br />
<br />
<br />
<br />
Continue reading at [[TerraGear scenery build server]]...<br />
<br />
=== Helicopter Missions ===<br />
{{WIP}}<br />
<br />
{{#ev:youtube|yWEyRVGJks0}}<br />
<br />
Continue reading at [http://forum.flightgear.org/viewtopic.php?f=6&t=22598 "Mission" for helicopters]...<br />
=== YASim Bug Fixes ===<br />
As of April 4th, several bug fixes by Colin Howell have been merged into the "next" branch of FlightGear's source. As per issues {{issue|1400|}}, {{issue|1423|}}, and {{issue|1427|}}, these are only small fixes in portions of code, but they still may have noticeable affects on YASim aircraft, including making the solver fail with some aircraft and making other aircraft perform better. Currently these fixes are loaded unconditionally, so there's no opt-in or opt-out system in place, meaning that we need ''you'' to help test as many YASim aircraft as possible. (Please note that these patches are only available with a latest binary, i.e. a nightly from Jenkins or a compilation from source, and a corresponding FGData clone.) Detlef posts, "I have tested the slat patch and the twist patch and found very little problems, in fact most cases I've seen saw an improvment. Of the 15 Aircraft I've tested the twist patch on, only two wouldn't start up at all" [http://forum.flightgear.org/viewtopic.php?f=49&t=22522#p204370]. Having a large number of non-working aircraft in the next release would be undesirable, and would suggest that we need an opt-in system for such fixes, but if most aircraft work well it will be simpler to let the patches load unconditionally.<br />
<br />
Please report aircraft that fail to work with latest FG (but that still work in 3.0, i.e. without the fixes) on the devel list or on the forums.<br />
<br />
Links to ongoing discussion at the development list:<br />
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]<br />
<br />
=== Canvas GUI Progress ===<br />
<br />
=== Random Buildings ===<br />
<br />
=== Project Rembrandt ===<br />
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].<br />
<br />
=== Canvas System ===<br />
<br />
Tom has updated FlightGear 3.1 to remove a lot of unneeded OpenGL state changes. 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].<br />
<br />
=== High Level Architecture ===<br />
<br />
=== Usability Improvements ===<br />
<br />
=== Creating your own keybindings ===<br />
A common request is how to change keys to do different commands. FlightGear makes this as easy as editing an XML file, and possibly adding a parameter to point FG to the new XML file.<br />
<br />
In general, the list of keyboard commands is stored in the property tree and is loaded at startup or when the menu option "Debug -> Reload input" is selected. The main list of commands is available in {{Git link|gitorious|fg/fgdata|master|keyboard.xml|pre=$FG_ROOT/}}, but each aircraft can add/change its own bindings through its -set.xml file, and additional [[config file]]s can do the same.<br />
<br />
<br />
Continue reading [[Howto:Reassign keyboard keys]]...<br />
<br />
=== Getting involved as a programmer ===<br />
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.<br />
<br />
If you are interested in contributing as a core developer, please see [[Howto:Start core development]].<br />
<br />
If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder. <br />
<br />
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.<br />
<br />
== Release ChangeLog ==<br />
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
=== New aircraft ===<br />
<br />
=== Updated aircraft ===<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== The Making of a new World Scenery ===<br />
A frequently asked question about scenery is: "Why isn't the terrain updated more often?". Most of us are probably unaware about what is required to build a new World Scenery and what is required to ship a complete set of data for rendering the world in FlightGear. As there is actually a new build in progress, we are able to present some naked numbers to give a rough impression about the resources involved.<br />
First, there is the raw data. Roughly half a dozen databases containing more than 100GB of elevation, coast lines, water ways, roads, land cover, navigation data and all the things that make up the details of our planets surface. [[File:terrain-generation-memory-consumption.png|right|thumb|Memory consumption during scenery creation]]<br />
All these information have to be converted into files understandable by FlightGear. The earth's surface in FlightGear is cut into tiles, each tile containing a 3d model for that area. While generating a single tile is a not too complicated task, generating the entire world is. Roads, coastlines, run- and taxiways do sometimes cross tile boundaries so the 3d surface has to be sliced at the tile boundary. The vertices on both edges have to be at the exact same position. To guarantee, you can't fall into the abyss while taxiing across an unclosed tile boundary, all tiles have to be created in a single run with the current toolchain.<br />
The machine performing that task has to crunch all the 100GB of raw data, keep the results more or less in memory and write the results to disk. This is an extremly time and resource hungry job. The current vectorization job has been started on Feb. 28th and is still running (Apr. 6th). Probably most impressive is the memory consumption which has grown to nearly 130GB. This is RAM, not Harddisk. As the machine is unfortunately ''only'' equipped with 100GB of RAM has started to use nearly 30GB of swap space.<br />
All this only works because of just a few people working hard and usually undiscovered in the background.<br />
<br />
=== Airports ===<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
=== Translators required ===<br />
{|<br />
|[[File:en.gif]]<br />
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].<br />
|-<br />
|[[File:de.gif]]<br />
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
|[[File:nl.gif]]<br />
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
|[[File:es.gif]]<br />
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|}<br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
==== The Northern-Italy ATC Controlled Area (NIATCA) ====<br />
NIATCA was born between December 2013 and January 2014 to offer Air Traffic Control in Northern Italy and in the neighboring area.<br />
Initially it was an ATC project only for LIPA, LIPX, LSZS and LIMC; but then more airports have been added to the project to become what NIATCA is today.<br />
<br />
Presently, its members' efforts allow you to enjoy professional services at the following airports:<br />
* Verona Villafranca (LIPX)<br />
* Milano Malpensa (LIMC)<br />
* Aviano Air Base (LIPA)<br />
* Samedan (LSZS)<br />
* Trieste-Ronchi dei Legionari (LIPQ)<br />
* Venezia Tessera (LIPZ)<br />
<br />
ATC sessions take place throughout the week and are planned on [http://flightgear-atc.alwaysdata.net/ Lenny's website]. Airport briefings and links to charts are available [http://forum.flightgear.org/viewtopic.php?f=10&t=21959 on the forum].<br />
<br />
For more informations, you can visit [https://plus.google.com/113151232487920064268 the project's Google+ page] or [https://www.youtube.com/user/NIATCAproject its YouTube channel]. The project is also searching for new members to extend coverage; current open positions are Torino Caselle (LIMF), Genova Sestri (LIMJ), Milano Linate (LIML), Bergamo (LIME), Treviso "San Angelo" (LIPH), Innsbruck-Kranebitten (LOWI), Bologna (LIPE), Bolzano-Dolomiti (LIPB), Base aerea di Rivolto (LIPI). If you want to contribute, just [https://docs.google.com/forms/d/1Yh5QqEHGZ-64tvUHUBoEa43SLMF8jwOm2Sis9otyPpo/viewform apply to become a member].<br />
<br />
Candidates are required to:<br />
* know ATC phraseology;<br />
* know the English language (knowledge of Italian is a plus);<br />
* be able to read charts and to let pilots follow real SIDs/STARs;<br />
* be able to man their position(s) at least one/two hours a week.<br />
<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
<br />
{{Volunteer Intro|mode=showlogo}}<br />
<br />
<!--<br />
TODO: this needs to be added to Template:Volunteer Intro<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].<br />
--><br />
<br />
=== YASim looking for a new maintainer ===<br />
<br />
<br />
{{cquote|There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.<br />
<br />
Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)<br />
<br />
So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, <br />
if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. <br />
Suggestions for that means in practice, are most welcome!<br />
<br />
Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html <br />
|title=YASim and documentation<br />
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}<br />
<br />
{{cquote|I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my<br />
latencies here are measured in weeks. <br />
Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html <br />
|title=YASim and documentation<br />
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}<br />
<br />
<references/><br />
<br />
<br />
=== Call for volunteers ===<br />
* The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].<br />
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support<br />
<br />
=== Did you know ===<br />
<br />
[[Category:FlightGear Newsletter]]<br />
<!-- this needs to be changed after each release, so that newsletters show up in the proper category --><br />
<br />
[[Category:Changes after 3.00]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=File:Terrain-generation-memory-consumption.png&diff=69528File:Terrain-generation-memory-consumption.png2014-04-06T19:19:04Z<p>T3r: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=Memory consumption of the scenery creation server}}<br />
|date=2014-04-06 21:15:46<br />
|source=http://webextra.osgeo.osuosl.org/munin/telascience.org/sphere.telascience.org/memory.html<br />
|author=http://munin-monitoring.org/<br />
|permission=<br />
|other_versions=<br />
|other_fields=<br />
}}<br />
{{Location dec|0|0}}<br />
<br />
=={{int:license-header}}==<br />
{{subst:uwl}}<br />
<br />
<br />
[[Category:Scenery]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Json_Properties&diff=69310Json Properties2014-03-27T22:04:01Z<p>T3r: Description of the JSON properties format</p>
<hr />
<div>== Abstract ==<br />
Beginning with the developer version 3.1 and the indroduction of the advanced internal web server, the access to internal properties via web services have been introduced. The properties are represented as [http://www.json.org/ JSON]. This Article contains the format description of JSON properties.<br />
<br />
=== Example ===<br />
This is an example of the /sim/time subtree:<br />
<pre><br />
{<br />
"path": "/sim/time",<br />
"name": "time",<br />
"type": "-",<br />
"index": 0,<br />
"nChildren": 12,<br />
"children": [{<br />
"path": "/sim/time/cur-time-override",<br />
"name": "cur-time-override",<br />
"value": "0",<br />
"type": "long",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/delta-sec",<br />
"name": "delta-sec",<br />
"value": "0.01666666667",<br />
"type": "double",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/warp",<br />
"name": "warp",<br />
"value": "-28320",<br />
"type": "int",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/warp-delta",<br />
"name": "warp-delta",<br />
"value": "0",<br />
"type": "int",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/delta-realtime-sec",<br />
"name": "delta-realtime-sec",<br />
"value": "0.01666666667",<br />
"type": "double",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/local-offset",<br />
"name": "local-offset",<br />
"value": "3600",<br />
"type": "int",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/utc",<br />
"name": "utc",<br />
"type": "-",<br />
"index": 0,<br />
"nChildren": 8<br />
}, {<br />
"path": "/sim/time/real",<br />
"name": "real",<br />
"type": "-",<br />
"index": 0,<br />
"nChildren": 7<br />
}, {<br />
"path": "/sim/time/elapsed-sec",<br />
"name": "elapsed-sec",<br />
"value": "7072.525",<br />
"type": "double",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/gmt",<br />
"name": "gmt",<br />
"value": "2014-03-27T13:25:10",<br />
"type": "string",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/gmt-string",<br />
"name": "gmt-string",<br />
"value": "13:25:10",<br />
"type": "string",<br />
"index": 0,<br />
"nChildren": 0<br />
}, {<br />
"path": "/sim/time/sun-angle-rad",<br />
"name": "sun-angle-rad",<br />
"value": "0.9883239645",<br />
"type": "double",<br />
"index": 0,<br />
"nChildren": 0<br />
}]<br />
}<br />
</pre><br />
<br />
== Definitions ==<br />
* JavaScript Object Notation (JSON), and the terms object, name, value, array, and number, are defined in [http://www.ietf.org/rfc/rfc4627.txt IETF RTC 4627].<br />
* The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [http://www.ietf.org/rfc/rfc2119.txt IETF RFC 2119].<br />
<br />
== Property Objects ==<br />
A Property Object always consist of a single object. This object represents a single property node or a complete (sub) tree of nodes.<br />
<br />
* Each object must have a member with the name ''path''. The members value is a string naming the absolute path of the node in the property tree. Example: '''/engines/engine[1]'''<br />
* Each object must have a member with the name ''name''. The members value is a string that determines the name of the node. Example: '''engine'''<br />
* Each object may have a member with the name ''value''. The members value contains the property nodes value. The current server implementation returns property node values by using the getStringValue() function.<br />
* Each object must have a member with the name ''type''. The members value must be on of "-" (for no type), "alias", "bool", "int", "long", "float", "double", "string", "unspecified", "extended", "vec3d" or "vec4d".<br />
* Each object may have a member with the name ''index''. The members value determines the index of the node in the parents node. Example: For a node /engines/engine[1] this would be 1. A missing ''index'' attribute results in an index of 0 (zero).<br />
* Each object may have a member with the name ''ts''. The members value represents the time when the server read node from the property tree. This is the time of /sim/time/elapsed-sec.<br />
* Each object may have a member with the name ''nChildren''. The members value determines the number of children under this node. It is optional to actually display the children itself within the JSON object. <br />
* Each object may have a member with the name ''children''. The members value is an array of JSON Property Objects.<br />
<br />
== Accessing the Property Tree ==<br />
=== The web service ===<br />
A simple web service provides read-only access to the property tree. This web service can be reached at the URL http://localhost:port/json<br />
where port is the portnumber provided to the -httpd= startup option. Path elements following that URL are interpreted as a property path, so http://localhost:port/json/sim/time returnes the JSON representation of the property node /sim/time and its immediate children (see example above). <br />
The service understands the following request parameters:<br />
* i - if the request parameter i is set to 'y', the output will be indented to make it more readable by humans. If the parameter is missing or assigned any other value, the output will be compressed.<br />
* t - if the request parameter t is set to 'y', the returned properties will be time stamped with the value of simulation time <br />
* d - the recursion depth of the resulting tree. The default and minimum depth is implemented as 1 resulting in the node itself and - if existing - the immediate children of the node. A value of 2 would return the node itself, it's children and their children. A very high value combined with a request for the root node returns a complete dump of the property tree (use this with caution!)<br />
<br />
=== The /PropertyListener websocket ===<br />
The property change listener websocket also sends property objects as change events for the subscribed nodes.<br />
<br />
<br />
<br />
== Pitfalls ==<br />
* calling http://localhost:port/json results in a 404 (Not found) error. Use http://localhost:port/json/ to access the root node.<br />
* asking for a nonexistant node returns an empty object ''{}''</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_March_2014&diff=69049FlightGear Newsletter March 20142014-03-24T22:20:51Z<p>T3r: Missing line break :-/</p>
<hr />
<div><br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
{{Newsletter being written}}<br />
== Development news ==<br />
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].<br />
<br />
=== TerraGear developers looking for your help ===<br />
The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]]. In addition, as part of working on an experimental [[TerraGear scenery build server]], we're currently looking for people able to offer hosting for testing purposes.<br />
<br />
=== FGPlot goes OOP ===<br />
<br />
<br />
[[File:FGplot2NG.jpg|thumb|http://forum.flightgear.org/viewtopic.php?f=71&t=22422]]<br />
<br />
kuifje09 has finished porting his original [[FGPlot]] work (originally using PUI/XML dialogs) to use just [[Canvas]] now. In addition, the FGPlot code base has now been heavily refactored and modularized, introducing additional classes and separate files for each modules. In addition, FGPlot has now been sufficiently generaliued to be also usable from other Nasal scripts. We are currently in the process of reviewing everything to hopefully ensure that this can be committed in time for the upcoming 3.2 release. <br />
<br />
To learn more, continue reading at: http://forum.flightgear.org/viewtopic.php?f=71&t=22422<br />
<br />
=== Installing TerraGear in 10 seconds on Linux ===<br />
<br />
[[File:TerraGear-hgtchop-VM.png|thumb|TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages]]<br />
<br />
As part of working on a long-standing feature request, namely having a central shared [[TerraGear scenery build server]], saiarcot895 has created Linux packages for Debian/Ubuntu (deb/ppa) to install precompiled TerraGear binaries. This now greatly simplifies installing TerraGear, because people no longer need to manually set up a complete Linux build environment and all SimGear/TerraGear dependencies. Everything is now done in an automated fashion.<br />
<br />
Next, we're hoping to use this to install TerraGear on a public server for which people can ask for remote shell access (SSH). People interested in exploring this, should be getting in touch via the forum or the wiki. <br />
<br />
Obviously, users will still need to be familiar with TerraGear, but they may benefit from reduced bandwidth restrictions and/or more horsepower in comparison to running TerraGear locally (e.g. one user offered to contribute hosting on a 32gb RAM and 8-core server). So this could be a great opportunity for people to run scripted/unattended jobs, without having to go through the hassle of downloading/building/installing and configuring TerraGear. <br />
But so far, being familiar with TerraGear and Linux is going to be a prerequisite still.<br />
<br />
Once that is working, we'll investigate making the setup reproducible by using TurnKeyLinux. Once we have a working TKL distro, we can install a full TG setup in just a few minutes by downloading an ISO file and installing it in a VM (VMWare/VirtualBox). This would basically allow people to easily download/install TerraGear locally, either installed next to their OS, or as a virtual machine.<br />
<br />
The long term idea is to hook up [[TerraGear GUI]] to it, so that the GUI front-end talks to TerraGear across SSH. <br />
<br />
This is currently still a use-case for which TG wasn't designed for, and the TG developers mentioned already on the forums that there may be some roadblocks ahead, so everything here is still highly experimental. But ultimately we hope to provide a front-end to a Linux-based TerraGear VM, either by reusing [[TerraGear GUI]] or by coming up with a custom web-based front-end (please get in touch if you can help with this!). <br />
<br />
If you're interested in helping or learning more, please get in touch via the forum or via [[TerraGear scenery build server]].<br />
<br />
===Modified JSBSim search paths ===<br />
AndersG has changed the search paths for JSBSim engines, propellers and systems in FlightGear to make it possible to have engines, propeller and system files shared by several aircraft stored in one place instead of keeping copies below each aircraft directory.<br />
<br />
The change adds $FG_ROOT/Aircraft/Generic/JSBSim/{Engines,Systems} to the JSBSim engine, propeller and system search paths.<br />
<br />
JSBSim searches <aircraft_dir>/Engines and <aircraft_dir>/Systems for the requested files before looking in the shared directories. This is <br />
consistent with how JSBSim works as a standalone program and should not cause any existing aircraft to load a different file than before.<br />
<br />
=== Reset & Reinit ===<br />
Over the next few days James is going to start switching over the reset system to use the new code. The following changes will happen, in order:<br />
<br />
* places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally. <br />
<br />
* the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let me know)<br />
* the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used<br />
* Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)<br />
<br />
James is not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file. <br />
<br />
Continue reading at [[Reset & re-init]]...<br />
<br />
=== built-in httpd updated ===<br />
While working on the new radio/atis implementation, Torsten rediscovered the internal httpd (aka webserver) to browse the property tree.<br />
It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal <br />
property browser and navigate to the locations after each sim restart. <br />
<br />
After a while, Torsten got disappointed by the functionality and the look&feel of the http property-browser, so he had a look at the code to see if it <br />
could be improved, he quickly realized, that the implementation was simple but not scalable, so he looked for something allready available on <br />
the GPL market.<br />
<br />
And he found Mongoose as a well maintained, feature rich and yet simple implementation of a web server and started to embedd that into FlightGear.<br />
<br />
What is ready so far and pushed to next is:<br />
* A single threaded httpd running in the main loop (should probably get its own thread soon)<br />
* Running as a replacement for the old httpd<br />
* Serving FGDATA/Docs as the document root<br />
* Serving the uri /props/ as a replacement for the old property browser (improved functionality, improved l&f, styling via css)<br />
* Serving the uri /run.cgi as a replacement for the old interface to run fg_commands<br />
* Serving the uri /json/ to return selected properties as JSON (read-only so far)<br />
<br />
All this has a lot of potential. With the JSON interface extended to being able to write properties, the CGI interface of <br />
Mongoose turned on, the webserver running stable in it's own thread, It should be possible to run e.g. PHP with jQuery or dojo.<br />
<br />
If you want to test the new functions, go to:<br />
* http://localhost:<httpd-port>/ for FGDATA/Docs<br />
* http://localhost:<httpd-port>/props/ for the internal property browser<br />
* http://localhost:<httpd-port>/json/some/property/name/or/path for the internal property browser<br />
* http://localhost:<httpd-port>/run.cgi?value=pause to pause/unpause the simulation<br />
<br />
Please mind the trailing slash for /props/ and /json/ (no, it's not bug-free yet.)<br />
<br />
Torsten has just pushed a litte quick-and-dirty example to fgdata. If you have a recent build from git/next, start fgfs with --httpd=8080 and <br />
point your browser at http://localhost:8080/gui/radio.html<br />
You need to be online to see the goodies as the jQuery js is loaded from code.jquery.com and not (yet) pushed to fgdata.<br />
The updates every five seconds and does not write back to fg yet.<br />
<br />
If you can't run the latest codebase, here is a screenshot:<br />
https://www.dropbox.com/s/98ejva4n4m38po1/HTMLRadioSettings.jpg.<br />
<br />
=== New built-in moving map ===<br />
[[File:Browsermap-2.jpg|300px|right|Central Europe with Navdata and Weather Layers]]<br />
When starting FlightGear with the internal web server enabled (--httpd=8080), a new moving map application is accessible for those with a working internet connection and state-of-the-art web browser. http://localhost:8080/gui/map opens an interactive map covering the entire world, enriched with FlightGear navigation data and life weather information. An aircraft symbol is showing the current position of the simulated FlightGear aircraft, also indicating it's heading and altitude. The position information is sent through a websocket in realtime without the need for polling the FlightGear web server. The update rate of the map is currently throttled to 1Hz but refresh frequencies up to 20Hz have been successfully tested. The map can follow the aircraft's position or may be panned free around the world, still tracking the planes position on the map.<br />
[[File:Browsermap-3.jpg|300px|right|Around Hamburg (EDDH) with LOC courses]]Three base layers currently exist: openstreetmap, Mapquest road and Mapquest satelite. Overlays for the FlightGear navdata, precipitation and sea level pressure isobares from openweather.org may be added in any combination. The level of detail for the navigation data varies with the zoom level. To keep the load on the FlightGear instance low, Navigation data will only be displayed up to a radius of 250NM around the maps center. In detailed zoom levels, all airports (including runways), navigation aids, localizer courses of the displayed area will show up after a short delay. A click on a marker brings up a popup with detailed information about the item like name, frequency, runway length etc.<br />
[[File:Browsermap-4.jpg|300px|right|At GA Parking EDDH with popup for ALSTER DME]]Several modern web techniques power all this: There is [http://http://leafletjs.com/ Leaflet], "Open-Source JavaScript Library for Mobile-Friendly Interactive Maps". There is [http://jquery.com/ jQuery], "a fast, small, and feature-rich JavaScript library". On the server side lives [http://cesanta.com/mongoose.shtml mongoose], "The easiest to use web server on the planet". Data flows as [http://www.json.org/fatfree.html JSON], "The Fat-Free Alternative to XML". A lot of HTML5 and CSS3 is also involved.<br />
The map has been tested on Safari on OSX and iOS. Chrome on Android, OSX and Linux. Firefox on OSX and Linux. It runs on workstations with huge screens, laptop computers with small screens, tablets, smartphones and even an old iPod with iOS 6.<br />
<br />
=== Cloud Shadows (by Thorsten) ===<br />
<br />
Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows:<br />
<br />
In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.<br />
<br />
<br />
For those interested, here's some details to the technique and why it's implemented the way it is:<br />
<br />
I've read up a bit on shadow generation techniques in the literature, and clouds appear to be tricky. Shadow volume techniques are out because they don't work for semi-transparent texture stacks, so it's got to be shadow maps. <br />
<br />
Generating a shadow map on the fly requires a shadow camera pass over clouds. I know from prior experience optimizing cloud rendering performance by means of a z-buffer filling first pass that any second pass over clouds is prohibitively expensive - any attempt to pass over clouds a second time drove me below 10 fps for even moderately clouded scenes. If I were to speculate, I'd say that this is the reason clouds in Rembrandt don't cast any shadows in spite of Rembrandt being easily able to include clouds in the shadow camera pass. There are other disadvantages to this approach, for instance a cloud texture could be fairly opaque (i.e. zero alpha) but we still might not want to render a shadow since the cloud is too high and diffraction would erase it, or because the cloud is translucent white and does in fact not cast a shadow, we may want to draw different depth of shadow etc.<br />
<br />
So I believe a cloud shadow map needs to be generated procedurally from meta-information supplied by the weather system rather than in the rendering pipeline, since only the weather system knows what a cloud is and whether we want to draw a shadow or not.<br />
<br />
There are still two different ways this could be done:<br />
<br />
* the CPU gets the meta-info and assembles a shadow map as texture and passes that texture to the rendering pipeline<br />
* the GPU gets the meta-info and assembles the shadow map inside the rendering pipeline<br />
<br />
In the event, I've chosen the second approach, since evaluating 'simple' functions on the GPU is in my experience (a lot) faster than looking up a large texture (my rule of thumb is that a texture lookup is worth about 10 exp() functions or ~100 simple functions such as smoothstep()). Moreover, texture units are limited to 8, and the model ubershader already uses all available texture units, so there's some merit to not passing a texture.<br />
<br />
The current code then passes 40 uniform position data points of clouds with shadow strength and depth encoded in the position information, allowing to draw 20 distinct cloud shadows. The weather system registers a shadow candidate every time a cloud which would cast a shadow is generated (currently that's Cu and Congestus type clouds) and a subroutine of the weather system selects which of these candidates should be drawn by the shader based on the current view position (and fov if the flag is on). The shadows are projected in a rudimentary way, but not exactly, i.e. the projection does not account for season and for terrain elevation - that's the price of framerate-friendliness, but one really has to go look hard to see the projection errors.<br />
<br />
So, I believe this technique has pros and cons over an on the fly generation by a camera pass, but framerate friendliness certainly is a big pro here. As indicated above, I will gradually deal with proper shadows in all special-purpose shadows and also register different types of clouds for shadow candidates in the weather system.<br />
<br />
I'm not sure whether this can easily be generalized to the way Basic Weather handles clouds, and one point of discussion may be down to which quality level this feature should be supported, so there's plenty to be discussed.<br />
<br />
[[File:Cloud shadow01.jpg|400px|Clouds cast shadow on the terrain]]<br />
[[File:Cloud shadow02.jpg|400px|Clouds cast shadow on the terrain and aircraft]]<br />
<br />
=== Random Buildings ===<br />
<br />
=== Project Rembrandt ===<br />
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].<br />
<br />
=== Canvas System ===<br />
<br />
=== High Level Architecture ===<br />
<br />
=== Usability Improvements ===<br />
<br />
=== Getting involved as a programmer ===<br />
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.<br />
<br />
If you are interested in contributing as a core developer, please see [[Howto:Start core development]].<br />
<br />
If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder. <br />
<br />
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.<br />
<br />
== Release ChangeLog ==<br />
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
=== Bash Completion ===<br />
A new [[Bash completion]] script is now available for the fgfs-command. You just have to install the completion script as explained [[Bash completion#Installation|here]].<br />
<br />
New feature??? Yes, you are right! Bash completion has existed for Flightgear since 2005 (a time where this feature has been really rare!), but not been updated since 2008.<br />
<br />
The new release now supports auto-completion for all options from "fgfs --help --verbose", as well as airport codes, aircraft names, parking positions, runways, carrier names, scenarios, navaids, and some more.<br />
<br />
If you have questions or comments regarding that script, please post them to this [http://forum.flightgear.org/viewtopic.php?f=6&t=22349 forum thread].<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
=== New aircraft ===<br />
<br />
== Vespa Scooter for FlightGear ==<br />
<br />
::Really not a new aircraft per se, but it's flight model borrows from YAsim prop drive aircraft. Some years back I had made a scooter model for Flying Model Simulator, the RC model training simulator. This is the 3D model with some improvements of the basic 3D and additional animations. In use it operates much like a modern 'Twist and Go' CVT transmissioned scooter. You apply throttle and it accelerates, apply brakes, ( both wheels are braked.) using the joystick button 0 or trigger button..) or the period key, (.) for rear and comma (,) for front brakes. Using the rear brake is handy because it applies less braking force and can be used as a 'trailing brake' through corners. My future plans include re-editing the FDM and adding some nasal so this bike has a 4 speed gearbox.<br />
<br />
:::I'm presenting this model for a Multiplayer Event of a Scooter tour of the Isle of Man's famous motorcycle Time Trial Race Course. I'm preparing some 3D scenery files to add to the existing scenery used in the new 2.0 FG scenery for the UK/Europe areas, with it's improved roads.<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=10&t=22114]<br />
<br />
:::There will be a couple other bikes made for the FG, although I don't think they will be done in time for the MP event. <br />
<br />
:::I've been approached by Detlef Faber, who offer to adapt his walker figure to use with this scooter. So the user/pilot will have the ability do first person excursions from the bike after parking it. It will also have improved rider animations. I'm also providing the aero-winch tow functions from the FG YAsim glider FDM's on this bike, because it tends to get stuck fast in rough terrain, much like the conifer forest terrain tiles. This is a 'feature' of the YAsim wheel modeling that I like, because it models rough ground and you can make trips off the pavement on some kinds of terrain without having it get stuck.<br />
<br />
[[File:Start finish of the Isle of Man TT course.jpg|thumb|Start finish of the Isle of Man TT course from the MPMap view]]<br />
<br />
[[File:Small displacement TT road racer.jpg|thumb|Small displacement TT road racer in development]]<br />
<br />
<br />
{{#ev:youtube|fwdnYUCNmGw}}<br />
<br />
=== Updated aircraft ===<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Airports ===<br />
Flyingfisch has been working on several of the airports in northeast Ohio.<br />
<br />
[[File:KCAK Terminal 1.png|300px|Akron canton terminal]]<br />
[[File:KCAK Terminal 2.png|300px|AirTran 717 at Akron canton terminal]]<br />
[[File:Airdock thumbnail.jpg|Goodyear airdock at KAKR]]<br />
<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=5&t=14671&p=203927#p203927 Forum Post]<br />
<br />
=== New tree textures ===<br />
<br />
<br />
With the new world scenery and procedural terrain texturing techniques, FG visuals have progressed to a point that trees were the least realistic element in the scene. This of course can be fixed. Thanks to work by forum user Zbyszek (deciduous trees) and ThorstenR (coniferous trees), we now have new hires tree textures for the regional texturing scheme (for legacy support, global texturing still uses the old trees), making the visual quality of the trees now on par with the rest of the scene: <br />
<br />
[[File:Trees04.jpg|300px|Hires deciduous trees]] [[File:Trees06.jpg|300px|Hires coniferous trees]] [[File:Trees05.jpg|300px|Hires coniferous trees wit snow]]<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
Flying by Denali, Alaska, in tricky weather<br />
<br />
[[File:Denali2.jpg|600px|Near Denali, Alaska]]<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
=== Piper PA-22 ===<br />
{{review}}<br />
[[File:pa22-3.jpg|thumb|270px|Flying over northeast Ohio]]<br />
[[File:Pa22-2.png|thumb|270px|A look out the left side]]<br />
[[File:Pa22cockpit-2.png|thumb|270px|The cockpit]]<br />
<br />
The PA-22 is a classic post-World War II aircraft. Produced from 1950-1964, it competed with other light GA aircraft of the day, including the Cessna 150. Its popular appeal lay in its ruggedness, spacious cabin, and, for the time, impressive speed.<br />
<br />
Let's see how the flightgear version compares.<br />
<br />
The flightgear version of the plane includes an autostart option as well as a tutorial to step you through the process. The takeoff is smooth and steady, only minimal rudder is needed to keep the aircraft lined up with the runway. We rotate at about 55 MPH, accelerate to about 85 MPH, and climb. The climb rate is decent, and pretty soon we reach our cruising altitude of 1000 feet. <br />
<br />
After leaning out the mixture a bit, pulling the throttle back to three quarters, I decide to turn on autopilot. There is a tutorial to step you through the use of the autopilot, which is quite simple. Since the autopilot only takes care of roll, we reach up to the ceiling to adjust the vertical trim. Clicking it will cause it to rotate in one direction, middle clicking will rotate it in the other direction.<br />
<br />
Now that the plane is flying in a hands-off configuration, we can look around. Since the day I took off on was pretty warm, I decided to open the window for a little breeze. This is easily done by clicking on it. The vents on all four windows also open and close when clicked. If it's dark out you can click the dome light behind you to light up the cockpit. Red-tinted instrument lights are also available.<br />
<br />
A little experimentation will show you that it is pretty hard to stall this aircraft. What happens instead is the aircraft mushes with full elevator, and the plane just falls from the sky. You still have control and dipping the nose down a bit and increasing power should get you flying normally again.<br />
<br />
We head back to the airport at about 110 MPH to test out the landing charactersitics. As we approach the airport, we slow down to about 90 MPH and lower the flaps fully. Our over-the-fence speed is about 85 MPH, and raising the nose slightly and cutting power over the runway sets us gently on the ground. <br />
<br />
The flight isn't over yet though. A little judicial movement on the rudder pedals makes sure we don't turn off the runway. In this regard, a stitch in time saves nine, and small movements as soon as you see a little lateral movement saves having to make large embarrassing ones a second later. Be careful with the brakes, as this plane has a tendancy to dip a wing if applied too roughly.<br />
<br />
The flight dynamics seem pretty realistic, the model is excellent (it even has four liveries and a paintkit), and the 3D cockpit is superb. One thing I would suggest is having it remember your preference whether to show or hide the wheel pants, but apart from that I don't see anything lacking.<br />
<br />
-- [[User:Flyingfisch|Flyingfisch]] ([[User talk:Flyingfisch|talk]]) 20:54, 13 March 2014 (UTC)<br />
<br />
== Wiki updates ==<br />
=== Translators required ===<br />
{|<br />
|[[File:en.gif]]<br />
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].<br />
|-<br />
|[[File:de.gif]]<br />
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
|[[File:nl.gif]]<br />
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
|[[File:es.gif]]<br />
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|}<br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
==== Hang gliding simulator ====<br />
<br />
[[File:Hang gliding simulator using FlightGear.jpg|thumb|Hang gliding simulator using FlightGear]] FlightGear is being used to power a hang gliding simulator to be presented on March 8th/9th in Bremen at the [http://www.rad-outdoor.de/ro/Home Rad+Outdoor / Passion 2014 convention], hall 4B, booth 60.<br />
<br />
The pilot sees the simulation through an Oculus Rift head mounted display ([http://www.oculusvr.com/]). Input is controlled by a joystick that is [http://cognium.de/misc/hgsim2.jpg mounted upside down] to catch user input. The whole simulator runs out of the box with proper command line/config options in FlightGear.<br />
<br />
See the [http://forum.flightgear.org/viewtopic.php?f=25&t=19772&start=15 Forum thread] for some details.<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].<br />
<br />
=== YASim looking for a new maintainer ===<br />
<br />
<br />
{{cquote|There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.<br />
<br />
Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)<br />
<br />
So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, <br />
if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. <br />
Suggestions for that means in practice, are most welcome!<br />
<br />
Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html <br />
|title=YASim and documentation<br />
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}<br />
<br />
{{cquote|I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my<br />
latencies here are measured in weeks. <br />
Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html <br />
|title=YASim and documentation<br />
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}<br />
<br />
<references/><br />
<br />
<br />
=== Call for volunteers ===<br />
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support<br />
<br />
=== Did you know ===<br />
<br />
[[Category:FlightGear Newsletter]]<br />
<!-- this needs to be changed after each release, so that newsletters show up in the proper category --><br />
<br />
[[Category:Changes after 3.00]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_March_2014&diff=69048FlightGear Newsletter March 20142014-03-24T22:19:11Z<p>T3r: /*new moving map */</p>
<hr />
<div><br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
{{Newsletter being written}}<br />
== Development news ==<br />
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].<br />
<br />
=== TerraGear developers looking for your help ===<br />
The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]]. In addition, as part of working on an experimental [[TerraGear scenery build server]], we're currently looking for people able to offer hosting for testing purposes.<br />
<br />
=== FGPlot goes OOP ===<br />
<br />
<br />
[[File:FGplot2NG.jpg|thumb|http://forum.flightgear.org/viewtopic.php?f=71&t=22422]]<br />
<br />
kuifje09 has finished porting his original [[FGPlot]] work (originally using PUI/XML dialogs) to use just [[Canvas]] now. In addition, the FGPlot code base has now been heavily refactored and modularized, introducing additional classes and separate files for each modules. In addition, FGPlot has now been sufficiently generaliued to be also usable from other Nasal scripts. We are currently in the process of reviewing everything to hopefully ensure that this can be committed in time for the upcoming 3.2 release. <br />
<br />
To learn more, continue reading at: http://forum.flightgear.org/viewtopic.php?f=71&t=22422<br />
<br />
=== Installing TerraGear in 10 seconds on Linux ===<br />
<br />
[[File:TerraGear-hgtchop-VM.png|thumb|TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages]]<br />
<br />
As part of working on a long-standing feature request, namely having a central shared [[TerraGear scenery build server]], saiarcot895 has created Linux packages for Debian/Ubuntu (deb/ppa) to install precompiled TerraGear binaries. This now greatly simplifies installing TerraGear, because people no longer need to manually set up a complete Linux build environment and all SimGear/TerraGear dependencies. Everything is now done in an automated fashion.<br />
<br />
Next, we're hoping to use this to install TerraGear on a public server for which people can ask for remote shell access (SSH). People interested in exploring this, should be getting in touch via the forum or the wiki. <br />
<br />
Obviously, users will still need to be familiar with TerraGear, but they may benefit from reduced bandwidth restrictions and/or more horsepower in comparison to running TerraGear locally (e.g. one user offered to contribute hosting on a 32gb RAM and 8-core server). So this could be a great opportunity for people to run scripted/unattended jobs, without having to go through the hassle of downloading/building/installing and configuring TerraGear. <br />
But so far, being familiar with TerraGear and Linux is going to be a prerequisite still.<br />
<br />
Once that is working, we'll investigate making the setup reproducible by using TurnKeyLinux. Once we have a working TKL distro, we can install a full TG setup in just a few minutes by downloading an ISO file and installing it in a VM (VMWare/VirtualBox). This would basically allow people to easily download/install TerraGear locally, either installed next to their OS, or as a virtual machine.<br />
<br />
The long term idea is to hook up [[TerraGear GUI]] to it, so that the GUI front-end talks to TerraGear across SSH. <br />
<br />
This is currently still a use-case for which TG wasn't designed for, and the TG developers mentioned already on the forums that there may be some roadblocks ahead, so everything here is still highly experimental. But ultimately we hope to provide a front-end to a Linux-based TerraGear VM, either by reusing [[TerraGear GUI]] or by coming up with a custom web-based front-end (please get in touch if you can help with this!). <br />
<br />
If you're interested in helping or learning more, please get in touch via the forum or via [[TerraGear scenery build server]].<br />
<br />
===Modified JSBSim search paths ===<br />
AndersG has changed the search paths for JSBSim engines, propellers and systems in FlightGear to make it possible to have engines, propeller and system files shared by several aircraft stored in one place instead of keeping copies below each aircraft directory.<br />
<br />
The change adds $FG_ROOT/Aircraft/Generic/JSBSim/{Engines,Systems} to the JSBSim engine, propeller and system search paths.<br />
<br />
JSBSim searches <aircraft_dir>/Engines and <aircraft_dir>/Systems for the requested files before looking in the shared directories. This is <br />
consistent with how JSBSim works as a standalone program and should not cause any existing aircraft to load a different file than before.<br />
<br />
=== Reset & Reinit ===<br />
Over the next few days James is going to start switching over the reset system to use the new code. The following changes will happen, in order:<br />
<br />
* places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally. <br />
<br />
* the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let me know)<br />
* the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used<br />
* Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)<br />
<br />
James is not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file. <br />
<br />
Continue reading at [[Reset & re-init]]...<br />
<br />
=== built-in httpd updated ===<br />
While working on the new radio/atis implementation, Torsten rediscovered the internal httpd (aka webserver) to browse the property tree.<br />
It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal <br />
property browser and navigate to the locations after each sim restart. <br />
<br />
After a while, Torsten got disappointed by the functionality and the look&feel of the http property-browser, so he had a look at the code to see if it <br />
could be improved, he quickly realized, that the implementation was simple but not scalable, so he looked for something allready available on <br />
the GPL market.<br />
<br />
And he found Mongoose as a well maintained, feature rich and yet simple implementation of a web server and started to embedd that into FlightGear.<br />
<br />
What is ready so far and pushed to next is:<br />
* A single threaded httpd running in the main loop (should probably get its own thread soon)<br />
* Running as a replacement for the old httpd<br />
* Serving FGDATA/Docs as the document root<br />
* Serving the uri /props/ as a replacement for the old property browser (improved functionality, improved l&f, styling via css)<br />
* Serving the uri /run.cgi as a replacement for the old interface to run fg_commands<br />
* Serving the uri /json/ to return selected properties as JSON (read-only so far)<br />
<br />
All this has a lot of potential. With the JSON interface extended to being able to write properties, the CGI interface of <br />
Mongoose turned on, the webserver running stable in it's own thread, It should be possible to run e.g. PHP with jQuery or dojo.<br />
<br />
If you want to test the new functions, go to:<br />
* http://localhost:<httpd-port>/ for FGDATA/Docs<br />
* http://localhost:<httpd-port>/props/ for the internal property browser<br />
* http://localhost:<httpd-port>/json/some/property/name/or/path for the internal property browser<br />
* http://localhost:<httpd-port>/run.cgi?value=pause to pause/unpause the simulation<br />
<br />
Please mind the trailing slash for /props/ and /json/ (no, it's not bug-free yet.)<br />
<br />
Torsten has just pushed a litte quick-and-dirty example to fgdata. If you have a recent build from git/next, start fgfs with --httpd=8080 and <br />
point your browser at http://localhost:8080/gui/radio.html<br />
You need to be online to see the goodies as the jQuery js is loaded from code.jquery.com and not (yet) pushed to fgdata.<br />
The updates every five seconds and does not write back to fg yet.<br />
<br />
If you can't run the latest codebase, here is a screenshot:<br />
https://www.dropbox.com/s/98ejva4n4m38po1/HTMLRadioSettings.jpg.<br />
<br />
=== New built-in moving map ===[[File:Browsermap-2.jpg|300px|right|Central Europe with Navdata and Weather Layers]]<br />
When starting FlightGear with the internal web server enabled (--httpd=8080), a new moving map application is accessible for those with a working internet connection and state-of-the-art web browser. http://localhost:8080/gui/map opens an interactive map covering the entire world, enriched with FlightGear navigation data and life weather information. An aircraft symbol is showing the current position of the simulated FlightGear aircraft, also indicating it's heading and altitude. The position information is sent through a websocket in realtime without the need for polling the FlightGear web server. The update rate of the map is currently throttled to 1Hz but refresh frequencies up to 20Hz have been successfully tested. The map can follow the aircraft's position or may be panned free around the world, still tracking the planes position on the map.<br />
[[File:Browsermap-3.jpg|300px|right|Around Hamburg (EDDH) with LOC courses]]Three base layers currently exist: openstreetmap, Mapquest road and Mapquest satelite. Overlays for the FlightGear navdata, precipitation and sea level pressure isobares from openweather.org may be added in any combination. The level of detail for the navigation data varies with the zoom level. To keep the load on the FlightGear instance low, Navigation data will only be displayed up to a radius of 250NM around the maps center. In detailed zoom levels, all airports (including runways), navigation aids, localizer courses of the displayed area will show up after a short delay. A click on a marker brings up a popup with detailed information about the item like name, frequency, runway length etc.<br />
[[File:Browsermap-4.jpg|300px|right|At GA Parking EDDH with popup for ALSTER DME]]Several modern web techniques power all this: There is [http://http://leafletjs.com/ Leaflet], "Open-Source JavaScript Library for Mobile-Friendly Interactive Maps". There is [http://jquery.com/ jQuery], "a fast, small, and feature-rich JavaScript library". On the server side lives [http://cesanta.com/mongoose.shtml mongoose], "The easiest to use web server on the planet". Data flows as [http://www.json.org/fatfree.html JSON], "The Fat-Free Alternative to XML". A lot of HTML5 and CSS3 is also involved.<br />
The map has been tested on Safari on OSX and iOS. Chrome on Android, OSX and Linux. Firefox on OSX and Linux. It runs on workstations with huge screens, laptop computers with small screens, tablets, smartphones and even an old iPod with iOS 6.<br />
<br />
=== Cloud Shadows (by Thorsten) ===<br />
<br />
Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows:<br />
<br />
In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.<br />
<br />
<br />
For those interested, here's some details to the technique and why it's implemented the way it is:<br />
<br />
I've read up a bit on shadow generation techniques in the literature, and clouds appear to be tricky. Shadow volume techniques are out because they don't work for semi-transparent texture stacks, so it's got to be shadow maps. <br />
<br />
Generating a shadow map on the fly requires a shadow camera pass over clouds. I know from prior experience optimizing cloud rendering performance by means of a z-buffer filling first pass that any second pass over clouds is prohibitively expensive - any attempt to pass over clouds a second time drove me below 10 fps for even moderately clouded scenes. If I were to speculate, I'd say that this is the reason clouds in Rembrandt don't cast any shadows in spite of Rembrandt being easily able to include clouds in the shadow camera pass. There are other disadvantages to this approach, for instance a cloud texture could be fairly opaque (i.e. zero alpha) but we still might not want to render a shadow since the cloud is too high and diffraction would erase it, or because the cloud is translucent white and does in fact not cast a shadow, we may want to draw different depth of shadow etc.<br />
<br />
So I believe a cloud shadow map needs to be generated procedurally from meta-information supplied by the weather system rather than in the rendering pipeline, since only the weather system knows what a cloud is and whether we want to draw a shadow or not.<br />
<br />
There are still two different ways this could be done:<br />
<br />
* the CPU gets the meta-info and assembles a shadow map as texture and passes that texture to the rendering pipeline<br />
* the GPU gets the meta-info and assembles the shadow map inside the rendering pipeline<br />
<br />
In the event, I've chosen the second approach, since evaluating 'simple' functions on the GPU is in my experience (a lot) faster than looking up a large texture (my rule of thumb is that a texture lookup is worth about 10 exp() functions or ~100 simple functions such as smoothstep()). Moreover, texture units are limited to 8, and the model ubershader already uses all available texture units, so there's some merit to not passing a texture.<br />
<br />
The current code then passes 40 uniform position data points of clouds with shadow strength and depth encoded in the position information, allowing to draw 20 distinct cloud shadows. The weather system registers a shadow candidate every time a cloud which would cast a shadow is generated (currently that's Cu and Congestus type clouds) and a subroutine of the weather system selects which of these candidates should be drawn by the shader based on the current view position (and fov if the flag is on). The shadows are projected in a rudimentary way, but not exactly, i.e. the projection does not account for season and for terrain elevation - that's the price of framerate-friendliness, but one really has to go look hard to see the projection errors.<br />
<br />
So, I believe this technique has pros and cons over an on the fly generation by a camera pass, but framerate friendliness certainly is a big pro here. As indicated above, I will gradually deal with proper shadows in all special-purpose shadows and also register different types of clouds for shadow candidates in the weather system.<br />
<br />
I'm not sure whether this can easily be generalized to the way Basic Weather handles clouds, and one point of discussion may be down to which quality level this feature should be supported, so there's plenty to be discussed.<br />
<br />
[[File:Cloud shadow01.jpg|400px|Clouds cast shadow on the terrain]]<br />
[[File:Cloud shadow02.jpg|400px|Clouds cast shadow on the terrain and aircraft]]<br />
<br />
=== Random Buildings ===<br />
<br />
=== Project Rembrandt ===<br />
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].<br />
<br />
=== Canvas System ===<br />
<br />
=== High Level Architecture ===<br />
<br />
=== Usability Improvements ===<br />
<br />
=== Getting involved as a programmer ===<br />
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.<br />
<br />
If you are interested in contributing as a core developer, please see [[Howto:Start core development]].<br />
<br />
If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder. <br />
<br />
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.<br />
<br />
== Release ChangeLog ==<br />
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
=== Bash Completion ===<br />
A new [[Bash completion]] script is now available for the fgfs-command. You just have to install the completion script as explained [[Bash completion#Installation|here]].<br />
<br />
New feature??? Yes, you are right! Bash completion has existed for Flightgear since 2005 (a time where this feature has been really rare!), but not been updated since 2008.<br />
<br />
The new release now supports auto-completion for all options from "fgfs --help --verbose", as well as airport codes, aircraft names, parking positions, runways, carrier names, scenarios, navaids, and some more.<br />
<br />
If you have questions or comments regarding that script, please post them to this [http://forum.flightgear.org/viewtopic.php?f=6&t=22349 forum thread].<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
=== New aircraft ===<br />
<br />
== Vespa Scooter for FlightGear ==<br />
<br />
::Really not a new aircraft per se, but it's flight model borrows from YAsim prop drive aircraft. Some years back I had made a scooter model for Flying Model Simulator, the RC model training simulator. This is the 3D model with some improvements of the basic 3D and additional animations. In use it operates much like a modern 'Twist and Go' CVT transmissioned scooter. You apply throttle and it accelerates, apply brakes, ( both wheels are braked.) using the joystick button 0 or trigger button..) or the period key, (.) for rear and comma (,) for front brakes. Using the rear brake is handy because it applies less braking force and can be used as a 'trailing brake' through corners. My future plans include re-editing the FDM and adding some nasal so this bike has a 4 speed gearbox.<br />
<br />
:::I'm presenting this model for a Multiplayer Event of a Scooter tour of the Isle of Man's famous motorcycle Time Trial Race Course. I'm preparing some 3D scenery files to add to the existing scenery used in the new 2.0 FG scenery for the UK/Europe areas, with it's improved roads.<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=10&t=22114]<br />
<br />
:::There will be a couple other bikes made for the FG, although I don't think they will be done in time for the MP event. <br />
<br />
:::I've been approached by Detlef Faber, who offer to adapt his walker figure to use with this scooter. So the user/pilot will have the ability do first person excursions from the bike after parking it. It will also have improved rider animations. I'm also providing the aero-winch tow functions from the FG YAsim glider FDM's on this bike, because it tends to get stuck fast in rough terrain, much like the conifer forest terrain tiles. This is a 'feature' of the YAsim wheel modeling that I like, because it models rough ground and you can make trips off the pavement on some kinds of terrain without having it get stuck.<br />
<br />
[[File:Start finish of the Isle of Man TT course.jpg|thumb|Start finish of the Isle of Man TT course from the MPMap view]]<br />
<br />
[[File:Small displacement TT road racer.jpg|thumb|Small displacement TT road racer in development]]<br />
<br />
<br />
{{#ev:youtube|fwdnYUCNmGw}}<br />
<br />
=== Updated aircraft ===<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Airports ===<br />
Flyingfisch has been working on several of the airports in northeast Ohio.<br />
<br />
[[File:KCAK Terminal 1.png|300px|Akron canton terminal]]<br />
[[File:KCAK Terminal 2.png|300px|AirTran 717 at Akron canton terminal]]<br />
[[File:Airdock thumbnail.jpg|Goodyear airdock at KAKR]]<br />
<br />
<br />
[http://forum.flightgear.org/viewtopic.php?f=5&t=14671&p=203927#p203927 Forum Post]<br />
<br />
=== New tree textures ===<br />
<br />
<br />
With the new world scenery and procedural terrain texturing techniques, FG visuals have progressed to a point that trees were the least realistic element in the scene. This of course can be fixed. Thanks to work by forum user Zbyszek (deciduous trees) and ThorstenR (coniferous trees), we now have new hires tree textures for the regional texturing scheme (for legacy support, global texturing still uses the old trees), making the visual quality of the trees now on par with the rest of the scene: <br />
<br />
[[File:Trees04.jpg|300px|Hires deciduous trees]] [[File:Trees06.jpg|300px|Hires coniferous trees]] [[File:Trees05.jpg|300px|Hires coniferous trees wit snow]]<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
Flying by Denali, Alaska, in tricky weather<br />
<br />
[[File:Denali2.jpg|600px|Near Denali, Alaska]]<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
=== Piper PA-22 ===<br />
{{review}}<br />
[[File:pa22-3.jpg|thumb|270px|Flying over northeast Ohio]]<br />
[[File:Pa22-2.png|thumb|270px|A look out the left side]]<br />
[[File:Pa22cockpit-2.png|thumb|270px|The cockpit]]<br />
<br />
The PA-22 is a classic post-World War II aircraft. Produced from 1950-1964, it competed with other light GA aircraft of the day, including the Cessna 150. Its popular appeal lay in its ruggedness, spacious cabin, and, for the time, impressive speed.<br />
<br />
Let's see how the flightgear version compares.<br />
<br />
The flightgear version of the plane includes an autostart option as well as a tutorial to step you through the process. The takeoff is smooth and steady, only minimal rudder is needed to keep the aircraft lined up with the runway. We rotate at about 55 MPH, accelerate to about 85 MPH, and climb. The climb rate is decent, and pretty soon we reach our cruising altitude of 1000 feet. <br />
<br />
After leaning out the mixture a bit, pulling the throttle back to three quarters, I decide to turn on autopilot. There is a tutorial to step you through the use of the autopilot, which is quite simple. Since the autopilot only takes care of roll, we reach up to the ceiling to adjust the vertical trim. Clicking it will cause it to rotate in one direction, middle clicking will rotate it in the other direction.<br />
<br />
Now that the plane is flying in a hands-off configuration, we can look around. Since the day I took off on was pretty warm, I decided to open the window for a little breeze. This is easily done by clicking on it. The vents on all four windows also open and close when clicked. If it's dark out you can click the dome light behind you to light up the cockpit. Red-tinted instrument lights are also available.<br />
<br />
A little experimentation will show you that it is pretty hard to stall this aircraft. What happens instead is the aircraft mushes with full elevator, and the plane just falls from the sky. You still have control and dipping the nose down a bit and increasing power should get you flying normally again.<br />
<br />
We head back to the airport at about 110 MPH to test out the landing charactersitics. As we approach the airport, we slow down to about 90 MPH and lower the flaps fully. Our over-the-fence speed is about 85 MPH, and raising the nose slightly and cutting power over the runway sets us gently on the ground. <br />
<br />
The flight isn't over yet though. A little judicial movement on the rudder pedals makes sure we don't turn off the runway. In this regard, a stitch in time saves nine, and small movements as soon as you see a little lateral movement saves having to make large embarrassing ones a second later. Be careful with the brakes, as this plane has a tendancy to dip a wing if applied too roughly.<br />
<br />
The flight dynamics seem pretty realistic, the model is excellent (it even has four liveries and a paintkit), and the 3D cockpit is superb. One thing I would suggest is having it remember your preference whether to show or hide the wheel pants, but apart from that I don't see anything lacking.<br />
<br />
-- [[User:Flyingfisch|Flyingfisch]] ([[User talk:Flyingfisch|talk]]) 20:54, 13 March 2014 (UTC)<br />
<br />
== Wiki updates ==<br />
=== Translators required ===<br />
{|<br />
|[[File:en.gif]]<br />
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at [[Help:Translate]].<br />
|-<br />
|[[File:de.gif]]<br />
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
|[[File:nl.gif]]<br />
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
|[[File:es.gif]]<br />
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|}<br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
==== Hang gliding simulator ====<br />
<br />
[[File:Hang gliding simulator using FlightGear.jpg|thumb|Hang gliding simulator using FlightGear]] FlightGear is being used to power a hang gliding simulator to be presented on March 8th/9th in Bremen at the [http://www.rad-outdoor.de/ro/Home Rad+Outdoor / Passion 2014 convention], hall 4B, booth 60.<br />
<br />
The pilot sees the simulation through an Oculus Rift head mounted display ([http://www.oculusvr.com/]). Input is controlled by a joystick that is [http://cognium.de/misc/hgsim2.jpg mounted upside down] to catch user input. The whole simulator runs out of the box with proper command line/config options in FlightGear.<br />
<br />
See the [http://forum.flightgear.org/viewtopic.php?f=25&t=19772&start=15 Forum thread] for some details.<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
To learn more about how the project works, please see [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].<br />
<br />
=== YASim looking for a new maintainer ===<br />
<br />
<br />
{{cquote|There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.<br />
<br />
Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)<br />
<br />
So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, <br />
if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. <br />
Suggestions for that means in practice, are most welcome!<br />
<br />
Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html <br />
|title=YASim and documentation<br />
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}<br />
<br />
{{cquote|I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my<br />
latencies here are measured in weeks. <br />
Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html <br />
|title=YASim and documentation<br />
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}<br />
<br />
<references/><br />
<br />
<br />
=== Call for volunteers ===<br />
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support<br />
<br />
=== Did you know ===<br />
<br />
[[Category:FlightGear Newsletter]]<br />
<!-- this needs to be changed after each release, so that newsletters show up in the proper category --><br />
<br />
[[Category:Changes after 3.00]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=File:Browsermap-3.jpg&diff=69047File:Browsermap-3.jpg2014-03-24T22:18:26Z<p>T3r: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=Browser Map - Around Hamburg (EDDH) with LOC courses}}<br />
|date=2014-03-24 23:13:58<br />
|source={{own}}<br />
|author=[[User:T3r|T3r]]<br />
|permission=<br />
|other_versions=<br />
|other_fields=<br />
}}<br />
{{Location dec|0|0}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-3.0}}<br />
<br />
<br />
[[Category:Screenshots]]<br />
[[Category:Maps]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=File:Browsermap-4.jpg&diff=69046File:Browsermap-4.jpg2014-03-24T22:18:15Z<p>T3r: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=At GA Parking EDDH with popup for ALSTER DME}}<br />
|date=2014-03-24 23:14:07<br />
|source={{own}}<br />
|author=[[User:T3r|T3r]]<br />
|permission=<br />
|other_versions=<br />
|other_fields=<br />
}}<br />
{{Location dec|0|0}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-3.0}}<br />
<br />
<br />
[[Category:Screenshotss]]<br />
[[Category:Maps]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=File:Browsermap-2.jpg&diff=69045File:Browsermap-2.jpg2014-03-24T22:18:04Z<p>T3r: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=Central Europe with Navdata and Weather Layers}}<br />
|date=2014-03-24 23:13:46<br />
|source={{own}}<br />
|author=[[User:T3r|T3r]]<br />
|permission=<br />
|other_versions=<br />
|other_fields=<br />
}}<br />
{{Location dec|0|0}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-3.0}}<br />
<br />
<br />
[[Category:Screenshots]]<br />
[[Category:Maps]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Release_plan&diff=57939Release plan2013-02-15T14:53:14Z<p>T3r: Detailed time schedule and checklist: add a call for screenshots</p>
<hr />
<div>{{GitStatus}}<br />
<br />
This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release. <br />
<br />
[[File:ReleasePlan.jpg|thumb|250px|The original plan]]<br />
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.<br />
<br />
If you think you have something to contribute to the release process, feel free to <span class=plainlinks>[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]</span>. In particular, improvements should be based on [[Release plan#Lessons learned]] from past releases. Please discuss this concept at the mailing-list.<br />
<br />
=== General release concept ===<br />
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA. <br />
<br />
After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.<br />
<br />
The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.<br />
<br />
=== Version numbers ===<br />
FlightGear version numbers exist of three digits, seperated by dots:<br />
* '''Major''' (<u>2</u>.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).<br />
* '''Minor''' (2.<u>4</u>.1): has two applications:<br />
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.<br />
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release is 2.8.0, the current development stream is 2.9.0.<br />
* '''Revision''' (2.4.<u>1</u>): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.<br />
<br />
=== Detailed time schedule and checklist ===<br />
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"<br />
##Send a mail to the flightgear-devel mailing-list to announce the state, add a call for screenshots<br />
##Create a "release preperations" topic at the forum and make it a "Global Announcement", add a call for screenshots<br />
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code><br />
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.9.0 -> 3.0.0)<br />
##Compile and test drive FlightGear with the new version-number<br />
##Commit the new version number to next (flightgear+simgear) and master(fgdata)<br />
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/3.0.0</tt><br />
##:''git tag -a version/3.0.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' the tags upstream<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.0.0''<br />
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams<br />
<!-- We don't really need this step...<br />
##Declare the streams "closed" or "red"<br />
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything<br />
##:Post an update to the forum topic<br />
##:Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code><br />
--><br />
##Pull current Git, create the release branches (for sg/fg/fgdata):<br />
##:''git pull<br />
##:''git branch release/3.0.0<br />
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (3.0.0 -> 3.1.0)<br />
##Compile and test drive FlightGear with the new development version number<br />
##Commit the changes of version-number to next/master<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"<br />
##:''git tag -a version/2.9.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream<br />
##:for flightgear, simgear and fgdata: ''git push origin release/3.0.0''<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.1.0''<br />
##Declare dev-streams "open" or "green"<br />
##: Ask a [http://wiki.flightgear.org/index.php?title=Special:ListUsers&group=sysop wiki admin] to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code><br />
##:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build<br />
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement<br />
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.<br />
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.<br />
##Tag the release/3.00 branches of simgear, flightgear and fgdata and push the tags.<br />
##:for flighgear, simgear and fgdata: ''git tag version/3.0.0-final''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/3.0.0-final''<br />
##Merge the branch release/3.0.0 into '''master''' (<u>'''NOT'''</u> next) for flightgear and simgear and push the branch<br />
##:We don't have a next branch for fgdata, no merging of the release branch here.<br />
##:for flighgear and simgear: <br />
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch<br />
##:''git merge version/3.0.0-final<br />
##:''git push origin master''<br />
##[[:Category:FlightGear Core developers|Core developers]] and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.<br />
<br />
=== To bump up the version number ===<br />
* fgdata<br />
** edit the ''version'' file<br />
* SimGear<br />
** edit the ''version'' file<br />
* FlightGear<br />
** edit the ''version'' file<br />
<br />
=== Definition of repository states ===<br />
{| class="wikitable"<br />
!<br />
! State<br />
! Description<br />
|-<br />
! [[File:Traffic light green.png|20px]]<br />
! Open/Green<br />
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.<br />
|-<br />
! [[File:Traffic light yellow.png|20px]]<br />
! Frozen/Yellow<br />
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.<br />
<br />
It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.<br />
|-<br />
! [[File:Traffic light red.png|20px]]<br />
! Closed/Red<br />
| Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.<br />
|}<br />
<br />
=== Bug fix committing policy ===<br />
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.<br />
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next. <br />
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.<br />
<br />
'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.<br />
<br />
=== Bug tracking ===<br />
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.<br />
<br />
Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].<br />
<br />
=== Tasks and owners ===<br />
<br />
The following table should be updated and augmented after each release, according to the [[Release plan#Lessons learned|Lessons learned]] section below.<br />
<br />
{|class="wikitable"<br />
!<br />
! width="500px" | Task<br />
! Owner(s)<br />
! Status for [[Changelog 2.10.0|2.10.0]]<br />
|-<br />
! rowspan="7" | <br />
| Announce the state-change of the dev-streams<br />
| TorstenD<br />
| {{Done}}<br />
|-<br />
| Create/maintain the git branches<br />
| TorstenD<br />
| {{Done}}<br />
|-<br />
| Track the bugs on the tracker, trigger developers, adjust bug-priorities<br />
| ThorstenB, Gijs, James, ...<br />
|-<br />
| Sync the language files so they can be translated<br />
| ThorstenB, James<br />
| {{Done}}<br />
|-<br />
| Beta testing <br />
| '''EVERYBODY'''<br />
|-<br />
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki<br />
| Stuart, Gijs and anyone else<br />
| {{Done}}<br />
|-<br />
| Pack RC and final version of FGDATA<br />
|<br />
|-<br />
! rowspan="5" | Create the RC and final version<br />
| Source-tarball<br />
| Curt<br />
|-<br />
| Linux<br />
| ThorstenB (for openSUSE)<br />
|-<br />
| Windows<br />
| Curt<br />
| {{Done}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39219.html]<br />
|-<br />
| MacOS<br />
| Tat/James<br />
| {{Done}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39221.html]<br />
|-<br />
| Distribute files to download servers<br />
| Curt<br />
| {{progressbar|30}}<br />
|-<br />
! rowspan="2" | Make adjustments on the web-site<br />
| Collect/make screenshots for the gallery <br />
| Curt<br />
|-<br />
| Generate aircraft page<br />
| Curt, Gijs<br />
|-<br />
! rowspan="2" | Announce the new version to the public<br />
| Write a changelog: [[Changelog 3.0.0]]<br />
| All developers<br />
|-<br />
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.<br />
| '''EVERYBODY'''<br />
|}<br />
<br />
=== Open items, questions ===<br />
* Automate and/or document the creation of RC's: "We need to get this automated some day. Or at least documented...(another one from "famous last words": if you have to do it more than once, automate it. If you can't automate it, document it." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html]<br />
* Automate the creation of Windows and Mac installers<br />
* Automate the creation of FGDATA distribution<br />
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html]<br />
<br />
=== Lessons learned ===<br />
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.<br />
<br />
==== 2.10 ====<br />
* '''FlightGear Core related ''':<br />
** perform a sync with JSBSim sources before the feature freeze.<br />
** decide early on if/when navdata can be updated [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39280.html]<br />
** there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894] [http://flightgear.org/forums/viewtopic.php?f=68&p=175690#p175690]<br />
** a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - some of this boiled down to coding style related issues, highlighting the fact that different core developers have different "coding styles" and requirements when reviewing merge requests, because we still lack an official "FlightGear coding style guide" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html]<br />
** merge requests that didn't make it into the previous release should probably be handled early during the upcoming release cycle<br />
<br />
<br />
* '''Changelog / Release Announcement''':<br />
** {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]<br />
** Probably it would be even better to directly process all "lessons learned" items and improve the release plan after each release accordingly<br />
** To get to the 3.0 goal sometime in the near future, it's probably a good idea to [[FlightGear 3.0 backlog|create a backlog of open items in the wiki and link the release plan document to that]]. As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html] (also see [[:Category:Developer Plans]])<br />
** {{Thumbs up}} Posting the link to the changelog for the upcoming release helped writing the changelog early, this should also be done for the [[Hardware Recommendations]] and [[Notebooks known to run FlightGear]] pages probably?<br />
** {{Thumbs up}} The changelog can be easily written by using "git log", searching the issue tracker and by going through the last 6 newsletters published since the previous release. It might make sense to explicitly add a "ChangeLog" message to important commits, so that the Changelog can be compiled more easily ?<br />
** Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?<br />
** for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features<br />
** it may make sense to also allow artwork contributors to contribute new splash screen images for use in the upcoming release. The screen shot contest should provide plenty of options [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795].<br />
** The RC announcement should also contain links to 1) the issue tracker and 2) the RC subforum [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39222.html]<br />
** Using wiki tagging, we could ensure that we can also tag our wiki documentation after each release, so that we can provide older versions of our docs for old FG versions [http://flightgear.org/forums/viewtopic.php?f=3&t=18240&p=170735&hilit=wiki+tagging#p170735]<br />
<br />
* '''Shaders''':<br />
** {{Thumbs up}} lowering the default shader level to 1 improved compatibility for older/underpowered systems [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39189.html]<br />
** GLSL shaders and effects should be treated like core code, and should be tested on different platforms before being enabled by default (i.e. signed-off by people using NVIDIA, ATI/AMD, Intel) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]<br />
** modified shaders should be tested with other shader-related features to prevent breakage [http://flightgear.org/forums/viewtopic.php?f=68&t=18924#p175583] (there might be a way to automate this a litle by catching GLSL compiler errors?)<br />
** to address all the intel GPU related issues, we may want to show an info dialog on computers where /sim/rendering/gl-vendor contains "intel" as a substring and provide an option to disable all shaders [http://flightgear.org/forums/viewtopic.php?f=37&t=18050&p=175774#p175774]<br />
** we probably need a separate article detailing GLSL coding requirements to ensure that portable constructs are used [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39278.html] so that problematic shaders are not just identified at the end of the release cycle<br />
<br />
* '''Installer''':<br />
** The installer should be updated to show a warning regarding TerraSync update time [http://flightgear.org/forums/viewtopic.php?f=68&t=18942&p=175779#p175779]<br />
** When Flightgear releases a new version, can the staff create a way for the average computer users to install a new version without doing anything to the old version but still use the terrain files from the older version? [http://flightgear.org/forums/viewtopic.php?f=22&t=18706&p=175762#p175762]<br />
** I believe Fred intentionally chose to use the same registry key from one version to the next. Thus if you install a new version over the top of an existing version it will end up in the same path under C:\<PF> [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39246.html]<br />
<br />
<br />
* '''FGData related (Base Package)''':<br />
** Language files should be synced between English and other languages, so translators can work on them before the release ;-)<br />
** the [https://gitorious.org/fg/flightgear/blobs/next/scripts/python/nasal_api_doc.py nasal_api_doc.py] script in $FG_SRC/scripts/python should be run as part of the release process, to create an updated doc file for $FG_ROOT/Docs and ship it with each release [http://flightgear.org/forums/viewtopic.php?f=30&t=15133]<br />
** New/updated Nasal scripts contributed to the base package should be checked to properly support important features like simulator reset, this also applies to Nasal scripts used by aircraft, Nasal scripts that fail these criteria, end up breaking existing features! [https://code.google.com/p/flightgear-bugs/issues/detail?id=956] (also see [[Release:Aircraft Selection Criteria]])<br />
** {{Thumbs up}} regarding aircraft included in the release: "I must stress usefulness of the Autostart feature, present in most aircraft not running at startup. It keeps frustration away from those who just want to enjoy the flight . (Please note that I actually agree with aircraft being shut down at startup, as long as autostart is present, or the starting procedure is trivially doable by just trying what you see in the cockpit.) " [http://flightgear.org/forums/viewtopic.php?f=3&t=18240&p=175117#p175117] (also see [[Release:Aircraft Selection Criteria]])<br />
** {{Thumbs up}} also, it would apparently make sense to provide tutorials for the default aircraft: "At first startup, I noticed the "Need help? use help->tutorials" message, and because I had no idea how to start up the plane (it would be just plain try and fail, than try something else), I did just that and started some basic tutorials. I wouldn't say going through the tutorials was frustrating, but they were quite boring and I was eager to get in the air as soon as possible." [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (also see [[Release:Aircraft Selection Criteria]])<br />
** "I discovered however, that there can be some problems on Linux about the planes (eg. some versions of the L39 Albatros undergoing several improvements lately). The problems can be caused by Linux being case sensitive about file paths (Windows is not), and I suspect, more models could suffer from some developers not knowing that. It's easy to fix if you know about the problem, but it would better be done on the developer side, as you never know if the smoke is just not implemented or missing due to this. Not to mention how lengthy it would be to go through more aircraft..." [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795]<br />
<br />
* '''Usability''':<br />
** {{Thumbs down}} A little downside is how the FGcom is done as a standalone program just cooperating with FG itself. It took me some fiddling with the settings for about two hours to get it working, but again installation was simply done from repos (FGcom and than FGcomGui as well). [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (this is planned [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38057.html])<br />
** {{Thumbs down}} Most likely because of the Intel graphics, I suffered for a long time from a problem with aircraft models (and some ground textures too) being black or missing some parts (see my post in an older thread complaining about similar problem). I solved it by adding a command line option turning off texture compression. [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (also see [[Release:Aircraft Selection Criteria]])<br />
<!--<br />
** I also vote for hosting a non-GPL hangar on the FG site, and tighter coordination with the aircraft developers (I think they should be asked to actively propose their models to the hangar once it is created, of course there could be link to their site/hangar). It would help nice models to be more easily found, an more people could enjoy them. And that's why people spend time creating them, right? [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795]<br />
--><br />
** We should probably add a new menu to the menubar for our online resources (wiki, forum, issue tracker, FAQ) so that people more easily find important resources just by selecting them from a menu.<br />
<!--<br />
** Our GUI dialogs are currently not designed with a fixed resolution in mind, also they cannot be easily resized/changed, so that some dialogs may not be usable under certain circumstances [http://flightgear.org/forums/viewtopic.php?f=71&t=17625&p=170292&hilit=canvas+screen#p170232][http://flightgear.org/forums/viewtopic.php?f=68&t=18942&p=175738&hilit=768#p175738] We should ensure that all dialogs can be used with the recommended minimal screen size, or even better, provide a way to dynamically make dialogs resizable/tabbed to support smaller screen devices (like netbooks). This should be easier with the upcoming [[Canvas GUI]] system.<br />
--><br />
<br />
* '''Release Candidates''':<br />
** a number of users reported crashes, for better debugging support, consider linking in Google BreakPad (cross platform stack traces) [http://flightgear.org/forums/viewtopic.php?f=68&t=18942&p=176669#p176669]<br />
** Release Candidates should probably have a higher default logging level while writing everything to a log file that can be easily shared via the issue tracker/forums, so that end users can provide better bug reports.<br />
** some users reported "OpenGL out of memory" and "out of space" errors when testing the RCs, we may want to link in a leak detector library or simply add BoehmGC - which is used by Mozilla to track leaking subsystems (a runtime log is created and dumped at process termination), that way non-developers could provide better leak reports.<br />
** How about having a test run a week or two in advance, just to make sure we can indeed produce release installers for Win+Mac - and then release the first RC on December 17th/18th or 19th [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]<br />
** We've already got a fairly extensive lead-in time for the release. More testers on more platforms would seem to be the answer. Perhaps we should advertize for testers of those platforms that aren't adequately covered by developers running git? Making a complete package available, not just the binaries would help, as testers wouldn't need to be git-aware. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38764.html]<br />
** The main area to improve is to distribute release candidates for all platforms earlier - preferably starting immediately after the freeze. That would already give us more time for testing - without extending the actual freeze period.[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]<br />
** aircraft packages should be prepared prior to the official release date: "For the 2.8 release I didn't start making aircraft download packages (or uploading them to the ftp servers) until after the official release date which was a mistake" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39227.html]<br />
** RC's should probably be built with [[Built-in Profiler]] support enabled [http://flightgear.org/forums/viewtopic.php?f=68&t=18839&p=175689#p175689].<br />
** When releasing RC's do not limit them to Win/Mac binaries, but also create source snapshots so that distros can already work on the next package versions.<br />
** For RC's it might make sense to distribute binaries with debugging symbols included and [[Built-in Profiler|profiling support enabled]], so that people can more easily provide useful bug reports, or even backtraces.<br />
** Also, many end users still prefer using the forum for making bug reports and don't use the issue tracker - it might help to add a link (button) to the issue tracker to the about dialog or maybe even directly to the help menu ("Report an issue") (same for wiki/troubleshooting/faq ?)<br />
** it might make sense to give wider exposure to our RCs, i.e. via the newsletter - possibly by adjusting the release schedule<br />
** actually, it would even seem better to use our [[Release promotion]] checklist to send out an "Upcoming Release" announcement 4-6 weeks prior to the actual release, so that all the flightsim websites can notify their users to participate in RC beta testing.<br />
** a number of forum users reported that the RC/release mirrors were a real bottleneck, and that downloading the 800MB RC installer would often take 2-3 hours (using torrents instead was suggested)<br />
** it also seemed that a number of users had issues related to their browser corrupting the huge image download [http://flightgear.org/forums/viewtopic.php?f=68&t=18979&p=176137#p176087] (website should suggest to use a download manager instead!)<br />
** so reducing the size of the installer (i.e. base package) would seem like another good idea to give our RCs wider exposure, for example by focusing only on 2-3 aircraft<br />
** certain reported issues were really tricky to reproduce, we may want to provide an option to export crucial runtime settings to an XML file that can be easily shared with other testers/developers, or even extend the new flight recorder/replay tape system accordingly [http://flightgear.org/forums/viewtopic.php?f=68&t=18924&start=15#p176023]<br />
** it might be good if the forum release-candidates announcement mentions that tests and bug-reports should be done with a clean install of the release-candidate, with no third-party data used in tests.<br />
<br />
* '''Build related''':<br />
* A normal Linux user has practically no chance to get last stable on his box running if it isn't in his distro - a normal Windows user gets everything nice and streamlined. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38817.html]<br />
* According to the issue tracker there were 3-5 different contributors who provided C++ patches that didn't end up reviewed/merged, which caused some irritation.<br />
<br />
==== 2.8 ====<br />
* {{Thumbs down}} Lack of stress-testing: A number of users reported severe memory growth issues (with fgfs consuming as much as 14gb of RAM), many directly related to new features, such as random buildings: [http://flightgear.org/forums/viewtopic.php?f=17&t=16758&p=160765&hilit=vegetation#p160747] [http://flightgear.org/forums/viewtopic.php?f=17&t=17249] [http://flightgear.org/forums/viewtopic.php?f=68&t=17114&start=15#p163829] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38007.html] These could have probably been identified earlier by running FG for extended periods of time, and testing the shipped aircraft with the default KSFO scenery, and new features such as random buildings enabled.<br />
* {{Thumbs down}} Lack of graceful feature scaling: Several users with old graphics cards reported not being able to run FG 2.8 without crashing during startup, because the FG defaults didn't scale for old hardware [http://flightgear.org/forums/viewtopic.php?f=17&t=17308]<br />
* {{Thumbs down}} According to noaa.gov it seems that the NOAA metar source got phased out in 04/2012 and moved to a new URL[http://weather.noaa.gov/weather/coded.html], some users reported issues related to this[http://flightgear.org/forums/viewtopic.php?f=17&t=17457&p=165784&hilit=metar#p165784]. However, the metar URL is currently hard-coded in the fgfs/metar source code - in addition, the default format is no longer a plain text dump [http://www.aviationweather.gov/adds/metars/]. It would make sense to make the URL a string property that can be put into preferences.xml and then use a Nasal listener to parse the resulting XML/HTML and set a plain text property instead, that can be processed by the existing metar code.<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38113.html Broken OSX downloads]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=21&p=165841#p165841 the OSX 10.8 release and code signing caused some irritation]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=47&t=14883&start=330#p166062 After the 2.8 release a number of users on the forums reported seeing GLSL related errors, because some of the 2.8 shaders used GLSL features only supported by more recent GLSL compilers/drivers - it would probably make sense to test all shader settings on all 3 platforms and check if they cause any errors (and "backport" shaders as necessary). Apple/Mac OSX seems to be more problematic]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38121.html Microsoft Redistributables were apparently not shipped with the Windows installer ?]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38089.html The changelog should be written as early as possible]<br />
* The code freeze could probably be lifted for patches that are not normally enabled/used by any default code paths (or shipped aircraft) in a FlightGear release. This probably involves Nasal extension functions, fgcommands, telnet commands, but also custom hard coded instruments or instrumentation-related APIs (think Canvas). Basically, whenever there's no chance to break a release by committing a certain patch, because the code path will not be executed by default without explicitly enabling it. For 2.8, this also meant that the Nasal [[Canvas]] API could not be included due to the code freeze, which however wasn't used by any systems or aircraft - so that there would have been zero chance for breakage [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37622.html] [http://flightgear.org/forums/viewtopic.php?f=71&t=17397#p165413].<br />
* The wiki contains a number of resources to help new users with hardware decisions, such as [[Hardware Recommendations]] [[Notebooks known to run FlightGear]] and [[Supported Video Cards]] - these should probably be updated for each release several weeks in advance.<br />
<br />
==== 2.6 ====<br />
* {{Thumbs up}} feature freeze in general<br />
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.<br />
* {{Thumbs down}} feature freeze for aircraft<br />
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.<br />
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.<br />
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.<br />
* {{Thumbs down}} manual creation of release candidates and the release binaries<br />
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.<br />
* {{Thumbs down}} release date/time frame<br />
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:<br />
*:* no big difference between releases for the various OS.<br />
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.<br />
<br />
[[Category:Core developer documentation]]<br />
[[Category:FlightGear]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Release_plan&diff=57784Release plan2013-02-08T09:52:47Z<p>T3r: removel obsolete edit of options.cxx</p>
<hr />
<div>{{GitStatus}}<br />
<br />
This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release. <br />
<br />
[[File:ReleasePlan.jpg|thumb|250px|The original plan]]<br />
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.<br />
<br />
If you think you have something to contribute to the release process, feel free to <span class=plainlinks>[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]</span>. In particular, improvements should be based on [[Release plan#Lessons learned]] from past releases. Please discuss this concept at the mailing-list.<br />
<br />
=== General release concept ===<br />
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA. <br />
<br />
After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.<br />
<br />
The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.<br />
<br />
=== Version numbers ===<br />
FlightGear version numbers exist of three digits, seperated by dots:<br />
* '''Major''' (<u>2</u>.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).<br />
* '''Minor''' (2.<u>4</u>.1): has two applications:<br />
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.<br />
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release is 2.8.0, the current development stream is 2.9.0.<br />
* '''Revision''' (2.4.<u>1</u>): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.<br />
<br />
=== Detailed time schedule and checklist ===<br />
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"<br />
##Send a mail to the flightgear-devel mailing-list to announce the state<br />
##Create a "release preperations" topic at the forum and make it a "Global Announcement"<br />
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code><br />
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.9.0 -> 3.0.0)<br />
##Compile and test drive FlightGear with the new version-number<br />
##Commit the new version number to next (flightgear+simgear) and master(fgdata)<br />
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/3.0.0</tt><br />
##:''git tag -a version/3.0.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' the tags upstream<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.0.0''<br />
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams<br />
<!-- We don't really need this step...<br />
##Declare the streams "closed" or "red"<br />
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything<br />
##:Post an update to the forum topic<br />
##:Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code><br />
--><br />
##Pull current Git, create the release branches (for sg/fg/fgdata):<br />
##:''git pull<br />
##:''git branch release/3.0.0<br />
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (3.0.0 -> 3.1.0)<br />
##Compile and test drive FlightGear with the new development version number<br />
##Commit the changes of version-number to next/master<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"<br />
##:''git tag -a version/2.9.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream<br />
##:for flightgear, simgear and fgdata: ''git push origin release/3.0.0''<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.1.0''<br />
##Declare dev-streams "open" or "green"<br />
##: Ask a [http://wiki.flightgear.org/index.php?title=Special:ListUsers&group=sysop wiki admin] to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code><br />
##:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build<br />
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement<br />
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.<br />
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.<br />
##Tag the release/3.00 branches of simgear, flightgear and fgdata and push the tags.<br />
##:for flighgear, simgear and fgdata: ''git tag version/3.0.0-final''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/3.0.0-final''<br />
##Merge the branch release/3.0.0 into '''master''' (<u>'''NOT'''</u> next) for flightgear and simgear and push the branch<br />
##:We don't have a next branch for fgdata, no merging of the release branch here.<br />
##:for flighgear and simgear: <br />
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch<br />
##:''git merge version/3.0.0-final<br />
##:''git push origin master''<br />
##[[:Category:FlightGear Core developers|Core developers]] and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.<br />
<br />
=== To bump up the version number ===<br />
* fgdata<br />
** edit the ''version'' file<br />
* SimGear<br />
** edit the ''version'' file<br />
* FlightGear<br />
** edit the ''version'' file<br />
<br />
=== Definition of repository states ===<br />
{| class="wikitable"<br />
!<br />
! State<br />
! Description<br />
|-<br />
! [[File:Traffic light green.png|20px]]<br />
! Open/Green<br />
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.<br />
|-<br />
! [[File:Traffic light yellow.png|20px]]<br />
! Frozen/Yellow<br />
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.<br />
<br />
It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.<br />
|-<br />
! [[File:Traffic light red.png|20px]]<br />
! Closed/Red<br />
| Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.<br />
|}<br />
<br />
=== Bug fix committing policy ===<br />
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.<br />
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next. <br />
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.<br />
<br />
'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.<br />
<br />
=== Bug tracking ===<br />
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.<br />
<br />
Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].<br />
<br />
=== Tasks and owners ===<br />
<br />
The following table should be updated and augmented after each release, according to the [[Release plan#Lessons learned|Lessons learned]] section below.<br />
<br />
{|class="wikitable"<br />
!<br />
! width="500px" | Task<br />
! Owner(s)<br />
! Status for [[Changelog 2.10.0|2.10.0]]<br />
|-<br />
! rowspan="7" | <br />
| Announce the state-change of the dev-streams<br />
| TorstenD<br />
| {{Done}}<br />
|-<br />
| Create/maintain the git branches<br />
| TorstenD<br />
| {{Done}}<br />
|-<br />
| Track the bugs on the tracker, trigger developers, adjust bug-priorities<br />
| ThorstenB, Gijs, James, ...<br />
|-<br />
| Sync the language files so they can be translated<br />
| ThorstenB, James<br />
| {{Done}}<br />
|-<br />
| Beta testing <br />
| '''EVERYBODY'''<br />
|-<br />
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki<br />
| Stuart, Gijs and anyone else<br />
| {{Done}}<br />
|-<br />
| Pack RC and final version of FGDATA<br />
|<br />
|-<br />
! rowspan="5" | Create the RC and final version<br />
| Source-tarball<br />
| Curt<br />
|-<br />
| Linux<br />
| ThorstenB (for openSUSE)<br />
|-<br />
| Windows<br />
| Curt<br />
| {{Done}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39219.html]<br />
|-<br />
| MacOS<br />
| Tat/James<br />
| {{Done}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39221.html]<br />
|-<br />
| Distribute files to download servers<br />
| Curt<br />
| {{progressbar|30}}<br />
|-<br />
! rowspan="2" | Make adjustments on the web-site<br />
| Collect/make screenshots for the gallery <br />
| Curt<br />
|-<br />
| Generate aircraft page<br />
| Curt, Gijs<br />
|-<br />
! rowspan="2" | Announce the new version to the public<br />
| Write a changelog: [[Changelog 3.0.0]]<br />
| All developers<br />
|-<br />
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.<br />
| '''EVERYBODY'''<br />
|}<br />
<br />
=== Open items, questions ===<br />
* Automate and/or document the creation of RC's: "We need to get this automated some day. Or at least documented...(another one from "famous last words": if you have to do it more than once, automate it. If you can't automate it, document it." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html]<br />
* Automate the creation of Windows and Mac installers<br />
* Automate the creation of FGDATA distribution<br />
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html]<br />
<br />
=== Lessons learned ===<br />
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.<br />
<br />
==== 2.10 ====<br />
* '''FlightGear Core related ''':<br />
** perform a sync with JSBSim sources before the feature freeze.<br />
** decide early on if/when navdata can be updated [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39280.html]<br />
** there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894] [http://flightgear.org/forums/viewtopic.php?f=68&p=175690#p175690]<br />
** a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - some of this boiled down to coding style related issues, highlighting the fact that different core developers have different "coding styles" and requirements when reviewing merge requests, because we still lack an official "FlightGear coding style guide" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html]<br />
** merge requests that didn't make it into the previous release should probably be handled early during the upcoming release cycle<br />
<br />
<br />
* '''Changelog / Release Announcement''':<br />
** {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]<br />
** Probably it would be even better to directly process all "lessons learned" items and improve the release plan after each release accordingly<br />
** To get to the 3.0 goal sometime in the near future, it's probably a good idea to [[FlightGear 3.0 backlog|create a backlog of open items in the wiki and link the release plan document to that]]. As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html] (also see [[:Category:Developer Plans]])<br />
** {{Thumbs up}} Posting the link to the changelog for the upcoming release helped writing the changelog early, this should also be done for the [[Hardware Recommendations]] and [[Notebooks known to run FlightGear]] pages probably?<br />
** {{Thumbs up}} The changelog can be easily written by using "git log", searching the issue tracker and by going through the last 6 newsletters published since the previous release. It might make sense to explicitly add a "ChangeLog" message to important commits, so that the Changelog can be compiled more easily ?<br />
** Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?<br />
** for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features<br />
** it may make sense to also allow artwork contributors to contribute new splash screen images for use in the upcoming release. The screen shot contest should provide plenty of options [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795].<br />
** The RC announcement should also contain links to 1) the issue tracker and 2) the RC subforum [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39222.html]<br />
** Using wiki tagging, we could ensure that we can also tag our wiki documentation after each release, so that we can provide older versions of our docs for old FG versions [http://flightgear.org/forums/viewtopic.php?f=3&t=18240&p=170735&hilit=wiki+tagging#p170735]<br />
<br />
* '''Shaders''':<br />
** {{Thumbs up}} lowering the default shader level to 1 improved compatibility for older/underpowered systems [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39189.html]<br />
** GLSL shaders and effects should be treated like core code, and should be tested on different platforms before being enabled by default (i.e. signed-off by people using NVIDIA, ATI/AMD, Intel) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]<br />
** modified shaders should be tested with other shader-related features to prevent breakage [http://flightgear.org/forums/viewtopic.php?f=68&t=18924#p175583] (there might be a way to automate this a litle by catching GLSL compiler errors?)<br />
** to address all the intel GPU related issues, we may want to show an info dialog on computers where /sim/rendering/gl-vendor contains "intel" as a substring and provide an option to disable all shaders [http://flightgear.org/forums/viewtopic.php?f=37&t=18050&p=175774#p175774]<br />
** we probably need a separate article detailing GLSL coding requirements to ensure that portable constructs are used [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39278.html] so that problematic shaders are not just identified at the end of the release cycle<br />
<br />
* '''Installer''':<br />
** The installer should be updated to show a warning regarding TerraSync update time [http://flightgear.org/forums/viewtopic.php?f=68&t=18942&p=175779#p175779]<br />
** When Flightgear releases a new version, can the staff create a way for the average computer users to install a new version without doing anything to the old version but still use the terrain files from the older version? [http://flightgear.org/forums/viewtopic.php?f=22&t=18706&p=175762#p175762]<br />
** I believe Fred intentionally chose to use the same registry key from one version to the next. Thus if you install a new version over the top of an existing version it will end up in the same path under C:\<PF> [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39246.html]<br />
<br />
<br />
* '''FGData related (Base Package)''':<br />
** Language files should be synced between English and other languages, so translators can work on them before the release ;-)<br />
** the [https://gitorious.org/fg/flightgear/blobs/next/scripts/python/nasal_api_doc.py nasal_api_doc.py] script in $FG_SRC/scripts/python should be run as part of the release process, to create an updated doc file for $FG_ROOT/Docs and ship it with each release [http://flightgear.org/forums/viewtopic.php?f=30&t=15133]<br />
** New/updated Nasal scripts contributed to the base package should be checked to properly support important features like simulator reset, this also applies to Nasal scripts used by aircraft, Nasal scripts that fail these criteria, end up breaking existing features! [https://code.google.com/p/flightgear-bugs/issues/detail?id=956] (also see [[Release:Aircraft Selection Criteria]])<br />
** {{Thumbs up}} regarding aircraft included in the release: "I must stress usefulness of the Autostart feature, present in most aircraft not running at startup. It keeps frustration away from those who just want to enjoy the flight . (Please note that I actually agree with aircraft being shut down at startup, as long as autostart is present, or the starting procedure is trivially doable by just trying what you see in the cockpit.) " [http://flightgear.org/forums/viewtopic.php?f=3&t=18240&p=175117#p175117] (also see [[Release:Aircraft Selection Criteria]])<br />
** {{Thumbs up}} also, it would apparently make sense to provide tutorials for the default aircraft: "At first startup, I noticed the "Need help? use help->tutorials" message, and because I had no idea how to start up the plane (it would be just plain try and fail, than try something else), I did just that and started some basic tutorials. I wouldn't say going through the tutorials was frustrating, but they were quite boring and I was eager to get in the air as soon as possible." [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (also see [[Release:Aircraft Selection Criteria]])<br />
** "I discovered however, that there can be some problems on Linux about the planes (eg. some versions of the L39 Albatros undergoing several improvements lately). The problems can be caused by Linux being case sensitive about file paths (Windows is not), and I suspect, more models could suffer from some developers not knowing that. It's easy to fix if you know about the problem, but it would better be done on the developer side, as you never know if the smoke is just not implemented or missing due to this. Not to mention how lengthy it would be to go through more aircraft..." [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795]<br />
<br />
* '''Usability''':<br />
** {{Thumbs down}} A little downside is how the FGcom is done as a standalone program just cooperating with FG itself. It took me some fiddling with the settings for about two hours to get it working, but again installation was simply done from repos (FGcom and than FGcomGui as well). [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (this is planned [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38057.html])<br />
** {{Thumbs down}} Most likely because of the Intel graphics, I suffered for a long time from a problem with aircraft models (and some ground textures too) being black or missing some parts (see my post in an older thread complaining about similar problem). I solved it by adding a command line option turning off texture compression. [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795] (also see [[Release:Aircraft Selection Criteria]])<br />
<!--<br />
** I also vote for hosting a non-GPL hangar on the FG site, and tighter coordination with the aircraft developers (I think they should be asked to actively propose their models to the hangar once it is created, of course there could be link to their site/hangar). It would help nice models to be more easily found, an more people could enjoy them. And that's why people spend time creating them, right? [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795]<br />
--><br />
** We should probably add a new menu to the menubar for our online resources (wiki, forum, issue tracker, FAQ) so that people more easily find important resources just by selecting them from a menu.<br />
<!--<br />
** Our GUI dialogs are currently not designed with a fixed resolution in mind, also they cannot be easily resized/changed, so that some dialogs may not be usable under certain circumstances [http://flightgear.org/forums/viewtopic.php?f=71&t=17625&p=170292&hilit=canvas+screen#p170232][http://flightgear.org/forums/viewtopic.php?f=68&t=18942&p=175738&hilit=768#p175738] We should ensure that all dialogs can be used with the recommended minimal screen size, or even better, provide a way to dynamically make dialogs resizable/tabbed to support smaller screen devices (like netbooks). This should be easier with the upcoming [[Canvas GUI]] system.<br />
--><br />
<br />
* '''Release Candidates''':<br />
** a number of users reported crashes, for better debugging support, consider linking in Google BreakPad (cross platform stack traces) [http://flightgear.org/forums/viewtopic.php?f=68&t=18942&p=176669#p176669]<br />
** Release Candidates should probably have a higher default logging level while writing everything to a log file that can be easily shared via the issue tracker/forums, so that end users can provide better bug reports.<br />
** some users reported "OpenGL out of memory" and "out of space" errors when testing the RCs, we may want to link in a leak detector library or simply add BoehmGC - which is used by Mozilla to track leaking subsystems (a runtime log is created and dumped at process termination), that way non-developers could provide better leak reports.<br />
** How about having a test run a week or two in advance, just to make sure we can indeed produce release installers for Win+Mac - and then release the first RC on December 17th/18th or 19th [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]<br />
** We've already got a fairly extensive lead-in time for the release. More testers on more platforms would seem to be the answer. Perhaps we should advertize for testers of those platforms that aren't adequately covered by developers running git? Making a complete package available, not just the binaries would help, as testers wouldn't need to be git-aware. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38764.html]<br />
** The main area to improve is to distribute release candidates for all platforms earlier - preferably starting immediately after the freeze. That would already give us more time for testing - without extending the actual freeze period.[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]<br />
** aircraft packages should be prepared prior to the official release date: "For the 2.8 release I didn't start making aircraft download packages (or uploading them to the ftp servers) until after the official release date which was a mistake" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39227.html]<br />
** RC's should probably be built with [[Built-in Profiler]] support enabled [http://flightgear.org/forums/viewtopic.php?f=68&t=18839&p=175689#p175689].<br />
** When releasing RC's do not limit them to Win/Mac binaries, but also create source snapshots so that distros can already work on the next package versions.<br />
** For RC's it might make sense to distribute binaries with debugging symbols included and [[Built-in Profiler|profiling support enabled]], so that people can more easily provide useful bug reports, or even backtraces.<br />
** Also, many end users still prefer using the forum for making bug reports and don't use the issue tracker - it might help to add a link (button) to the issue tracker to the about dialog or maybe even directly to the help menu ("Report an issue") (same for wiki/troubleshooting/faq ?)<br />
** it might make sense to give wider exposure to our RCs, i.e. via the newsletter - possibly by adjusting the release schedule<br />
** actually, it would even seem better to use our [[Release promotion]] checklist to send out an "Upcoming Release" announcement 4-6 weeks prior to the actual release, so that all the flightsim websites can notify their users to participate in RC beta testing.<br />
** a number of forum users reported that the RC/release mirrors were a real bottleneck, and that downloading the 800MB RC installer would often take 2-3 hours (using torrents instead was suggested)<br />
** it also seemed that a number of users had issues related to their browser corrupting the huge image download [http://flightgear.org/forums/viewtopic.php?f=68&t=18979&p=176137#p176087] (website should suggest to use a download manager instead!)<br />
** so reducing the size of the installer (i.e. base package) would seem like another good idea to give our RCs wider exposure, for example by focusing only on 2-3 aircraft<br />
** certain reported issues were really tricky to reproduce, we may want to provide an option to export crucial runtime settings to an XML file that can be easily shared with other testers/developers, or even extend the new flight recorder/replay tape system accordingly [http://flightgear.org/forums/viewtopic.php?f=68&t=18924&start=15#p176023]<br />
<br />
* '''Build related''':<br />
* A normal Linux user has practically no chance to get last stable on his box running if it isn't in his distro - a normal Windows user gets everything nice and streamlined. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38817.html]<br />
* According to the issue tracker there were 3-5 different contributors who provided C++ patches that didn't end up reviewed/merged, which caused some irritation.<br />
<br />
==== 2.8 ====<br />
* {{Thumbs down}} Lack of stress-testing: A number of users reported severe memory growth issues (with fgfs consuming as much as 14gb of RAM), many directly related to new features, such as random buildings: [http://flightgear.org/forums/viewtopic.php?f=17&t=16758&p=160765&hilit=vegetation#p160747] [http://flightgear.org/forums/viewtopic.php?f=17&t=17249] [http://flightgear.org/forums/viewtopic.php?f=68&t=17114&start=15#p163829] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38007.html] These could have probably been identified earlier by running FG for extended periods of time, and testing the shipped aircraft with the default KSFO scenery, and new features such as random buildings enabled.<br />
* {{Thumbs down}} Lack of graceful feature scaling: Several users with old graphics cards reported not being able to run FG 2.8 without crashing during startup, because the FG defaults didn't scale for old hardware [http://flightgear.org/forums/viewtopic.php?f=17&t=17308]<br />
* {{Thumbs down}} According to noaa.gov it seems that the NOAA metar source got phased out in 04/2012 and moved to a new URL[http://weather.noaa.gov/weather/coded.html], some users reported issues related to this[http://flightgear.org/forums/viewtopic.php?f=17&t=17457&p=165784&hilit=metar#p165784]. However, the metar URL is currently hard-coded in the fgfs/metar source code - in addition, the default format is no longer a plain text dump [http://www.aviationweather.gov/adds/metars/]. It would make sense to make the URL a string property that can be put into preferences.xml and then use a Nasal listener to parse the resulting XML/HTML and set a plain text property instead, that can be processed by the existing metar code.<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38113.html Broken OSX downloads]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=21&p=165841#p165841 the OSX 10.8 release and code signing caused some irritation]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=47&t=14883&start=330#p166062 After the 2.8 release a number of users on the forums reported seeing GLSL related errors, because some of the 2.8 shaders used GLSL features only supported by more recent GLSL compilers/drivers - it would probably make sense to test all shader settings on all 3 platforms and check if they cause any errors (and "backport" shaders as necessary). Apple/Mac OSX seems to be more problematic]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38121.html Microsoft Redistributables were apparently not shipped with the Windows installer ?]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38089.html The changelog should be written as early as possible]<br />
* The code freeze could probably be lifted for patches that are not normally enabled/used by any default code paths (or shipped aircraft) in a FlightGear release. This probably involves Nasal extension functions, fgcommands, telnet commands, but also custom hard coded instruments or instrumentation-related APIs (think Canvas). Basically, whenever there's no chance to break a release by committing a certain patch, because the code path will not be executed by default without explicitly enabling it. For 2.8, this also meant that the Nasal [[Canvas]] API could not be included due to the code freeze, which however wasn't used by any systems or aircraft - so that there would have been zero chance for breakage [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37622.html] [http://flightgear.org/forums/viewtopic.php?f=71&t=17397#p165413].<br />
* The wiki contains a number of resources to help new users with hardware decisions, such as [[Hardware Recommendations]] [[Notebooks known to run FlightGear]] and [[Supported Video Cards]] - these should probably be updated for each release several weeks in advance.<br />
<br />
==== 2.6 ====<br />
* {{Thumbs up}} feature freeze in general<br />
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.<br />
* {{Thumbs down}} feature freeze for aircraft<br />
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.<br />
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.<br />
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.<br />
* {{Thumbs down}} manual creation of release candidates and the release binaries<br />
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.<br />
* {{Thumbs down}} release date/time frame<br />
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:<br />
*:* no big difference between releases for the various OS.<br />
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.<br />
<br />
[[Category:Core developer documentation]]<br />
[[Category:FlightGear]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Release_plan&diff=57281Release plan2013-01-23T08:55:17Z<p>T3r: Lessons learned: remove placeholder</p>
<hr />
<div>{{GitStatus}}<br />
<br />
This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release. <br />
<br />
[[File:ReleasePlan.jpg|thumb|250px|The original plan]]<br />
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.<br />
<br />
If you think you have something to contribute to the release process, feel free to <span class=plainlinks>[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]</span>. In particular, improvements should be based on [[Release plan#Lessons learned]] from past releases. Please discuss this concept at the mailing-list.<br />
<br />
=== General release concept ===<br />
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA. <br />
<br />
After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.<br />
<br />
The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.<br />
<br />
=== Version numbers ===<br />
FlightGear version numbers exist of three digits, seperated by dots:<br />
* '''Major''' (<u>2</u>.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).<br />
* '''Minor''' (2.<u>4</u>.1): has two applications:<br />
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.<br />
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release is 2.8.0, the current development stream is 2.9.0.<br />
* '''Revision''' (2.4.<u>1</u>): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.<br />
<br />
=== Detailed time schedule and checklist ===<br />
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"<br />
##Send a mail to the flightgear-devel mailing-list to announce the state<br />
##Create a "release preperations" topic at the forum and make it a "Global Announcement"<br />
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code><br />
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.9.0 -> 3.0.0)<br />
##modify options.cxx to bump the hard-coded base package version number in [http://gitorious.org/fg/flightgear/commit/bffb5589215182cb21ab2b2697ae7bf000db1412/diffs/ddc2a745c67d138b34e3d95948d341341c85965d]<br />
##Compile and test drive FlightGear with the new version-number<br />
##Commit the new version number to next (flightgear+simgear) and master(fgdata)<br />
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/3.0.0</tt><br />
##:''git tag -a version/3.0.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' the tags upstream<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.0.0''<br />
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams<br />
<!-- We don't really need this step...<br />
##Declare the streams "closed" or "red"<br />
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything<br />
##:Post an update to the forum topic<br />
##:Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code><br />
--><br />
##Pull current Git, create the release branches (for sg/fg/fgdata):<br />
##:''git pull<br />
##:''git branch release/3.0.0<br />
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (3.0.0 -> 3.1.0)<br />
##Compile and test drive FlightGear with the new development version number<br />
##Commit the changes of version-number to next/master<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"<br />
##:''git tag -a version/2.9.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream<br />
##:for flightgear, simgear and fgdata: ''git push origin release/3.0.0''<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.1.0''<br />
##Declare dev-streams "open" or "green"<br />
##: Ask a wiki admin to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code><br />
##:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build<br />
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement<br />
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.<br />
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.<br />
##Tag the release/3.00 branches of simgear, flightgear and fgdata and push the tags.<br />
##:for flighgear, simgear and fgdata: ''git tag version/3.0.0-final''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/3.0.0-final''<br />
##Merge the branch release/3.0.0 into '''master''' (<u>'''NOT'''</u> next) for flightgear and simgear and push the branch<br />
##:We don't have a next branch for fgdata, no merging of the release branch here.<br />
##:for flighgear and simgear: <br />
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch<br />
##:''git merge version/3.0.0-final<br />
##:''git push origin master''<br />
##Core developers and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.<br />
<br />
=== To bump up the version number ===<br />
* fgdata<br />
** edit the ''version'' file<br />
* SimGear<br />
** edit the ''version'' file<br />
* FlightGear<br />
** edit the ''version'' file<br />
<br />
=== Definition of repository states ===<br />
{| class="wikitable"<br />
!<br />
! State<br />
! Description<br />
|-<br />
! [[File:Traffic light green.png|20px]]<br />
! Open/Green<br />
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.<br />
|-<br />
! [[File:Traffic light yellow.png|20px]]<br />
! Frozen/Yellow<br />
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.<br />
<br />
It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.<br />
|-<br />
! [[File:Traffic light red.png|20px]]<br />
! Closed/Red<br />
| Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.<br />
|}<br />
<br />
=== Bug fix committing policy ===<br />
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.<br />
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next. <br />
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.<br />
<br />
'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.<br />
<br />
=== Bug tracking ===<br />
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.<br />
<br />
Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].<br />
<br />
=== Tasks and owners ===<br />
<br />
The following table should be updated and augmented after each release, according to the [[Release plan#Lessons learned|Lessons learned]] section below.<br />
<br />
{|class="wikitable"<br />
!<br />
! width="500px" | Task<br />
! Owner(s)<br />
! Status for [[Changelog 2.10.0|2.10.0]]<br />
|-<br />
! rowspan="6" | <br />
| Announce the state-change of the dev-streams<br />
| TorstenD<br />
| {{Done}}<br />
|-<br />
| Create/maintain the git branches<br />
| TorstenD<br />
| {{Done}}<br />
|-<br />
| Track the bugs on the tracker, trigger developers, adjust bug-priorities<br />
| ThorstenB, Gijs, James, ...<br />
|-<br />
| Beta testing <br />
| '''EVERYBODY'''<br />
|-<br />
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki<br />
| Stuart, Gijs and anyone else<br />
|-<br />
| Pack RC and final version of FGDATA<br />
|<br />
|-<br />
! rowspan="5" | Create the RC and final version<br />
| Source-tarball<br />
| Curt<br />
|-<br />
| Linux<br />
| ThorstenB (for openSUSE)<br />
|-<br />
| Windows<br />
| Curt<br />
|-<br />
| MacOS<br />
| Tat<br />
|-<br />
| Distribute files to download servers<br />
| Curt<br />
|-<br />
! rowspan="2" | Make adjustments on the web-site<br />
| Collect/make screenshots for the gallery <br />
| Curt<br />
|-<br />
| Generate aircraft page<br />
| Curt, Gijs<br />
|-<br />
! rowspan="2" | Announce the new version to the public<br />
| Write a changelog: [[Changelog 3.0.0]]<br />
| All developers<br />
|-<br />
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.<br />
| '''EVERYBODY'''<br />
|}<br />
<br />
=== Open items, questions ===<br />
* Automate the creation of Windows and Mac installers<br />
* Automate the creation of FGDATA distribution<br />
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html]<br />
<br />
=== Lessons learned ===<br />
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.<br />
<br />
==== 2.10 ====<br />
* {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]<br />
* {{Thumbs up}} Posting the link to the changelog for the upcoming release helped writing the changelog early, this should also be done for the [[Hardware Recommendations]] and [[Notebooks known to run FlightGear]] pages probably?<br />
* perform a sync with JSBSim sources before the feature freeze.<br />
* {{Thumbs up}} The changelog can be easily written by using "git log", searching the issue tracker and by going through the last 6 newsletters published since the previous release.<br />
* GLSL shaders and effects should be treated like core code, and should be tested on different platforms before being enabled by default (NVIDIA, ATI/AMD, Intel) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]<br />
* New/updated Nasal scripts contributed to the base package should be checked to properly support important features like simulator reset, this also applies to Nasal scripts used by aircraft, Nasal scripts that fail these criteria, end up breaking existing features! [https://code.google.com/p/flightgear-bugs/issues/detail?id=956]<br />
* there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894]<br />
* a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - some of this boiled down to coding style related issues, highlighting the fact that different core developers have different "coding styles" and requirements when reviewing merge requests, because we still lack an official "FlightGear coding style guide" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html]<br />
* the [https://gitorious.org/fg/flightgear/blobs/next/scripts/python/nasal_api_doc.py nasal_api_doc.py] script in $FG_SRC/scripts/python should be run as part of the release process, to create an updated doc file for $FG_ROOT/Docs and ship it with each release [http://flightgear.org/forums/viewtopic.php?f=30&t=15133]<br />
* We've already got a fairly extensive lead-in time for the release. More testers on more platforms would seem to be the answer. Perhaps we should advertize for testers of those platforms that aren't adequately covered by developers running git? Making a complete package available, not just the binaries would help, as testers wouldn't need to be git-aware. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38764.html]<br />
* The main area to improve is to distribute release candidates for all platforms earlier - preferably starting immediately after the freeze. That would already give us more time for testing - without extending the actual freeze period.[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]<br />
* How about having a test run a week or two in advance, just to make sure we can indeed produce release installers for Win+Mac - and then release the first RC on December 17th/18th or 19th [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html]<br />
* To get to the 3.0 goal sometime in the near future, it's probably a good idea to create a backlog of open items in the wiki and link the release plan document to that. As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html] (also see [[:Category:Developer Plans]])<br />
* A normal Linux user has practically no change to get last stable on his box running if it isn't in his distro - a normal Windows user gets everything nice and streamlined. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38817.html]<br />
* According to the issue tracker there were 3-5 different contributors who provided C++ patches that didn't end up reviewed/merged, which caused some irritation.<br />
* it may make sense to also allow art work contributors to contribute new splash screen images for use in the upcoming release. The screen shot contest should provide plenty of options [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795].<br />
<br />
==== 2.8 ====<br />
* {{Thumbs down}} Lack of stress-testing: A number of users reported severe memory growth issues (with fgfs consuming as much as 14gb of RAM), many directly related to new features, such as random buildings: [http://flightgear.org/forums/viewtopic.php?f=17&t=16758&p=160765&hilit=vegetation#p160747] [http://flightgear.org/forums/viewtopic.php?f=17&t=17249] [http://flightgear.org/forums/viewtopic.php?f=68&t=17114&start=15#p163829] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38007.html] These could have probably been identified earlier by running FG for extended periods of time, and testing the shipped aircraft with the default KSFO scenery, and new features such as random buildings enabled.<br />
* {{Thumbs down}} Lack of graceful feature scaling: Several users with old graphics cards reported not being able to run FG 2.8 without crashing during startup, because the FG defaults didn't scale for old hardware [http://flightgear.org/forums/viewtopic.php?f=17&t=17308]<br />
* {{Thumbs down}} According to noaa.gov it seems that the NOAA metar source got phased out in 04/2012 and moved to a new URL[http://weather.noaa.gov/weather/coded.html], some users reported issues related to this[http://flightgear.org/forums/viewtopic.php?f=17&t=17457&p=165784&hilit=metar#p165784]. However, the metar URL is currently hard-coded in the fgfs/metar source code - in addition, the default format is no longer a plain text dump [http://www.aviationweather.gov/adds/metars/]. It would make sense to make the URL a string property that can be put into preferences.xml and then use a Nasal listener to parse the resulting XML/HTML and set a plain text property instead, that can be processed by the existing metar code.<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38113.html Broken OSX downloads]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=21&p=165841#p165841 the OSX 10.8 release and code signing caused some irritation]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=47&t=14883&start=330#p166062 After the 2.8 release a number of users on the forums reported seeing GLSL related errors, because some of the 2.8 shaders used GLSL features only supported by more recent GLSL compilers/drivers - it would probably make sense to test all shader settings on all 3 platforms and check if they cause any errors (and "backport" shaders as necessary). Apple/Mac OSX seems to be more problematic]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38121.html Microsoft Redistributables were apparently not shipped with the Windows installer ?]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38089.html The changelog should be written as early as possible]<br />
* The code freeze could probably be lifted for patches that are not normally enabled/used by any default code paths (or shipped aircraft) in a FlightGear release. This probably involves Nasal extension functions, fgcommands, telnet commands, but also custom hard coded instruments or instrumentation-related APIs (think Canvas). Basically, whenever there's no chance to break a release by committing a certain patch, because the code path will not be executed by default without explicitly enabling it. For 2.8, this also meant that the Nasal [[Canvas]] API could not be included due to the code freeze, which however wasn't used by any systems or aircraft - so that there would have been zero chance for breakage [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37622.html] [http://flightgear.org/forums/viewtopic.php?f=71&t=17397#p165413].<br />
* The wiki contains a number of resources to help new users with hardware decisions, such as [[Hardware Recommendations]] [[Notebooks known to run FlightGear]] and [[Supported Video Cards]] - these should probably be updated for each release several weeks in advance.<br />
<br />
==== 2.6 ====<br />
* {{Thumbs up}} feature freeze in general<br />
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.<br />
* {{Thumbs down}} feature freeze for aircraft<br />
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.<br />
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.<br />
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.<br />
* {{Thumbs down}} manual creation of release candidates and the release binaries<br />
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.<br />
* {{Thumbs down}} release date/time frame<br />
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:<br />
*:* no big difference between releases for the various OS.<br />
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.<br />
<br />
[[Category:Core developer documentation]]<br />
[[Category:FlightGear]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Release_plan&diff=57162Release plan2013-01-13T21:37:24Z<p>T3r: Lessons learned: JSBSim sync</p>
<hr />
<div>{{GitStatus}}<br />
<br />
This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release. <br />
<br />
[[File:ReleasePlan.jpg|thumb|250px|The original plan]]<br />
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.<br />
<br />
If you think you have something to contribute to the release process, feel free to <span class=plainlinks>[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]</span>. In particular, improvements should be based on [[Release plan#Lessons learned]] from past releases. Please discuss this concept at the mailing-list.<br />
<br />
=== General release concept ===<br />
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA. <br />
<br />
After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.<br />
<br />
The development stream of SimGear, FlightGear and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.<br />
<br />
=== Version numbers ===<br />
FlightGear version numbers exist of three digits, seperated by dots:<br />
* '''Major''' (<u>2</u>.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).<br />
* '''Minor''' (2.<u>4</u>.1): has two applications:<br />
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.<br />
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release is 2.8.0, the current development stream is 2.9.0.<br />
* '''Revision''' (2.4.<u>1</u>): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.<br />
<br />
=== Detailed time schedule and checklist ===<br />
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"<br />
##Send a mail to the flightgear-devel mailing-list to announce the state<br />
##Create a "release preperations" topic at the forum and make it a "Global Announcement"<br />
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code><br />
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.9.0 -> 3.0.0)<br />
##modify options.cxx to bump the hard-coded base package version number in [http://gitorious.org/fg/flightgear/commit/bffb5589215182cb21ab2b2697ae7bf000db1412/diffs/ddc2a745c67d138b34e3d95948d341341c85965d]<br />
##Compile and test drive FlightGear with the new version-number<br />
##Commit the new version number to next (flightgear+simgear) and master(fgdata)<br />
##Tag (annotated) flightgear, simgear and fgdata with <tt>version/3.0.0</tt><br />
##:''git tag -a version/3.0.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' the tags upstream<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.0.0''<br />
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams<br />
<!-- We don't really need this step...<br />
##Declare the streams "closed" or "red"<br />
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything<br />
##:Post an update to the forum topic<br />
##:Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code><br />
--><br />
##Pull current Git, create the release branches (for sg/fg/fgdata):<br />
##:''git pull<br />
##:''git branch release/3.0.0<br />
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (3.0.0 -> 3.1.0)<br />
##Compile and test drive FlightGear with the new development version number<br />
##Commit the changes of version-number to next/master<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.9.0"<br />
##:''git tag -a version/2.9.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream<br />
##:for flightgear, simgear and fgdata: ''git push origin release/3.0.0''<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##:for the tags (all repos): ''git push origin version/3.1.0''<br />
##Declare dev-streams "open" or "green"<br />
##: Ask a wiki admin to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code><br />
##:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build<br />
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement<br />
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.<br />
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.<br />
##Tag the release/3.00 branches of simgear, flightgear and fgdata and push the tags.<br />
##:for flighgear, simgear and fgdata: ''git tag version/3.0.0-final''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/3.0.0-final''<br />
##Merge the branch release/3.0.0 into '''master''' (<u>'''NOT'''</u> next) for flightgear and simgear and push the branch<br />
##:We don't have a next branch for fgdata, no merging of the release branch here.<br />
##:for flighgear and simgear: <br />
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch<br />
##:''git merge version/3.0.0-final<br />
##:''git push origin master''<br />
<br />
=== To bump up the version number ===<br />
* fgdata<br />
** edit the ''version'' file<br />
* SimGear<br />
** edit the ''version'' file<br />
* FlightGear<br />
** edit the ''version'' file<br />
<br />
=== Definition of repository states ===<br />
{| class="wikitable"<br />
!<br />
! State<br />
! Description<br />
|-<br />
! [[File:Traffic light green.png|20px]]<br />
! Open/Green<br />
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.<br />
|-<br />
! [[File:Traffic light yellow.png|20px]]<br />
! Frozen/Yellow<br />
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.<br />
<br />
It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.<br />
|-<br />
! [[File:Traffic light red.png|20px]]<br />
! Closed/Red<br />
| Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.<br />
|}<br />
<br />
=== Bug fix committing policy ===<br />
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.<br />
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next. <br />
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.<br />
<br />
'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.<br />
<br />
=== Bug tracking ===<br />
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.<br />
<br />
Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.8.0 the list of fixed bugs].<br />
<br />
=== Tasks and owners ===<br />
{|class="wikitable"<br />
!<br />
! width="500px" | Task<br />
! Owner(s)<br />
|-<br />
! rowspan="6" | <br />
| Announce the state-change of the dev-streams<br />
| TorstenD<br />
|-<br />
| Create/maintain the git branches<br />
| TorstenD<br />
|-<br />
| Track the bugs on the tracker, trigger developers, adjust bug-priorities<br />
| ThorstenB, Gijs, James, ...<br />
|-<br />
| Beta testing <br />
| '''EVERYBODY'''<br />
|-<br />
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki<br />
| Stuart, Gijs and anyone else<br />
|-<br />
| Pack RC and final version of FGDATA<br />
|<br />
|-<br />
! rowspan="5" | Create the RC and final version<br />
| Source-tarball<br />
| Curt<br />
|-<br />
| Linux<br />
| ThorstenB (for openSUSE)<br />
|-<br />
| Windows<br />
| Curt<br />
|-<br />
| MacOS<br />
| Tat<br />
|-<br />
| Distribute files to download servers<br />
| Curt<br />
|-<br />
! rowspan="2" | Make adjustments on the web-site<br />
| Collect/make screenshots for the gallery <br />
| Curt<br />
|-<br />
| Generate aircraft page<br />
| Curt, Gijs<br />
|-<br />
! rowspan="2" | Announce the new version to the public<br />
| Write a changelog: [[Changelog 3.0.0]]<br />
| All developers<br />
|-<br />
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.<br />
| '''EVERYBODY'''<br />
|}<br />
<br />
=== Open items, questions ===<br />
* Automate the creation of Windows and Mac installers<br />
* Automate the creation of FGDATA distribution<br />
<br />
=== Lessons learned ===<br />
This is a list of lessons learned from the previous releases, things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases.<br />
<br />
==== 3.2 ====<br />
(not yet released)<br />
<br />
==== 3.0 ====<br />
(not yet released)<br />
<br />
==== 2.10 ====<br />
* perform a sync with JSBSim sources before the feature freeze.<br />
<br />
==== 2.8 ====<br />
* {{Thumbs down}} Lack of stress-testing: A number of users reported severe memory growth issues (with fgfs consuming as much as 14gb of RAM), many directly related to new features, such as random buildings: [http://flightgear.org/forums/viewtopic.php?f=17&t=16758&p=160765&hilit=vegetation#p160747] [http://flightgear.org/forums/viewtopic.php?f=17&t=17249] [http://flightgear.org/forums/viewtopic.php?f=68&t=17114&start=15#p163829] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38007.html] These could have probably been identified earlier by running FG for extended periods of time, and testing the shipped aircraft with the default KSFO scenery, and new features such as random buildings enabled.<br />
* {{Thumbs down}} Lack of graceful feature scaling: Several users with old graphics cards reported not being able to run FG 2.8 without crashing during startup, because the FG defaults didn't scale for old hardware [http://flightgear.org/forums/viewtopic.php?f=17&t=17308]<br />
* {{Thumbs down}} According to noaa.gov it seems that the NOAA metar source got phased out in 04/2012 and moved to a new URL[http://weather.noaa.gov/weather/coded.html], some users reported issues related to this[http://flightgear.org/forums/viewtopic.php?f=17&t=17457&p=165784&hilit=metar#p165784]. However, the metar URL is currently hard-coded in the fgfs/metar source code - in addition, the default format is no longer a plain text dump [http://www.aviationweather.gov/adds/metars/]. It would make sense to make the URL a string property that can be put into preferences.xml and then use a Nasal listener to parse the resulting XML/HTML and set a plain text property instead, that can be processed by the existing metar code.<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38113.html Broken OSX downloads]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=21&p=165841#p165841 the OSX 10.8 release and code signing caused some irritation]<br />
* {{Thumbs down}} [http://flightgear.org/forums/viewtopic.php?f=47&t=14883&start=330#p166062 After the 2.8 release a number of users on the forums reported seeing GLSL related errors, because some of the 2.8 shaders used GLSL features only supported by more recent GLSL compilers/drivers - it would probably make sense to test all shader settings on all 3 platforms and check if they cause any errors (and "backport" shaders as necessary). Apple/Mac OSX seems to be more problematic]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38121.html Microsoft Redistributables were apparently not shipped with the Windows installer ?]<br />
* {{Thumbs down}} [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38089.html The changelog should be written as early as possible]<br />
* The code freeze could probably be lifted for patches that are not normally enabled/used by any default code paths (or shipped aircraft) in a FlightGear release. This probably involves Nasal extension functions, fgcommands, telnet commands, but also custom hard coded instruments or instrumentation-related APIs (think Canvas). Basically, whenever there's no chance to break a release by committing a certain patch, because the code path will not be executed by default without explicitly enabling it. For 2.8, this also meant that the Nasal [[Canvas]] API could not be included due to the code freeze, which however wasn't used by any systems or aircraft - so that there would have been zero chance for breakage [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37622.html] [http://flightgear.org/forums/viewtopic.php?f=71&t=17397#p165413].<br />
* The wiki contains a number of resources to help new users with hardware decisions, such as [[Hardware Recommendations]] [[Notebooks known to run FlightGear]] and [[Supported Video Cards]] - these should probably be updated for each release several weeks in advance.<br />
<br />
==== 2.6 ====<br />
* {{Thumbs up}} feature freeze in general<br />
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.<br />
* {{Thumbs down}} feature freeze for aircraft<br />
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.<br />
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.<br />
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.<br />
* {{Thumbs down}} manual creation of release candidates and the release binaries<br />
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.<br />
* {{Thumbs down}} release date/time frame<br />
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:<br />
*:* no big difference between releases for the various OS.<br />
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.<br />
<br />
[[Category:Core developer documentation]]<br />
[[Category:FlightGear]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FGPanel&diff=54750FGPanel2012-10-09T07:46:14Z<p>T3r: Not affected by canvas</p>
<hr />
<div>[[File:FGPanel_SenecaII.png|thumb|300px|The 2D panel of a [[SenecaII]].]]<br />
'''FGPanel''' is designed as a standalone lightweight panel rendering engine to draw 2D panels on a low-cost computer/graphic card without 3D acceleration at reasonable frame rates.<br />
<br />
FGPanel was not part of the FlightGear 2.4.0 release for Windows. Windows users can get the executable from [http://flightgear.simpits.org:8080/job/FlightGear-Win-Cmake/lastSuccessfulBuild/artifact/install/msvc100/FlightGear/bin/fgpanel.exe Jenkins].<br />
<br />
== FGPanel Live System ==<br />
[[File:C172MiniCockpit1.jpg|thumb|200px|right|A complete display setup for the [[Cessna C172P]] using FGPanel.]]<br />
FGPanel is now available as a ''Live System'', a complete, stand-alone software setup, including FGPanel, (partial) FGData, Linux operating system and necessary start-up scripts. The ISO image (350MB download) needs to be programmed on a CD/DVD, USB flash or hard disk drive. Just insert the CD/DVD or connect the USB/HDD drive to your (old) PC, add an (old) graphics card, and an (old) TFT or monitor - and you've made the first step to your own cockpit home setup! The PC boots the image, immediately starts FGPanel and displays C172p cockpit instruments. Run the FlightGear Simulator on your main PC and enable the C172 FGPanel Protocol to transmit data to your cockpit panel PC.<br />
<br />
The live CD is a freely available SUSE Studio project. It can also be cloned/modified/adapted to personal needs via SUSE Studio (web interface). Operating system is based on OpenSuSE Linux 12.1. FlightGear binaries (fgpanel) are directly pulled from the OpenSuSE build service (OBS).<br />
<br />
More information available at the [http://susestudio.com/a/sBTdmU/flightgear-fgpanel SUSEStudio FGPanel] project.<br />
<br />
== Related content ==<br />
* [[ Howto: Build your own procedure trainer]], describes how you can create a "cheap" procedure trainer, making use of FGPanel to draw the instruments.<br />
<br />
== External link ==<br />
* [https://gitorious.org/fg/flightgear/trees/next/utils/fgpanel Source], part of fg/flightgear.<br />
* [https://gitorious.org/fg/flightgear/blobs/next/utils/fgpanel/README README]<br />
<br />
[[Category: Software]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Release_plan&diff=50750Release plan2012-06-02T19:39:38Z<p>T3r: /* Tasks and owners */</p>
<hr />
<div>This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release. <br />
<br />
[[File:ReleasePlan.jpg|thumb|250px|The original plan]]<br />
This release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.<br />
<br />
If you think you have something to contribute to the release process, feel free to <span class=plainlinks>[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]</span>. Please discuss this concept at the mailing-list.<br />
<br />
=== General release concept ===<br />
New FlightGear releases will be scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch will be created for SimGear, FlightGear and FGDATA. <br />
<br />
After branching, we will allow one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA will take place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August. <br />
<br />
The development stream of SimGear, FlightGear and FGDATA will be set into a frozen state one month before the branch-day (17th) to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.<br />
<br />
=== Version numbers ===<br />
* '''Major releases''' always have '''even numbers''' as the second version element, i.e. 2.4.0, 2.6.0, 2.8.0.<br />
* '''Bugfix releases''' increase the least significant digit: 2.6.1, 2.6.2, 2.6.3.<br />
* The '''development stream''' (''latest Git version'') uses an '''odd number''', increasing the second element of the latest stable release's version by 1: (latest release is 2.6.0 =&gt; current development stream is 2.7.0, next official release is 2.8.0).<br />
* The major version number is increased after significant changes to the functionality of the software (i.e. FG 1.x => 2.0 due to switch to OSG).<br />
<br />
=== Detailed time schedule and checklist ===<br />
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"<br />
#:Send a mail to the flightgear-devel mailing-list to announce the state<br />
#:Create a "release preperations" topic at the forum and make it a "Global Announcement"<br />
#:Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:frozen}}</nowiki></tt><br />
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams<br />
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"<br />
##Post an update to the forum topic<br />
##Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:closed}}</nowiki></tt><br />
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.5.0 -> 2.6.0)<br />
##Compile and test drive FlightGear with the new version-number<br />
##Commit the new version number to next (flightgear+simgear) and master(fgdata)<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.6.0"<br />
##:''git tag -a version/2.6.0'' (Enter a wise comment)<br />
##Create the release branches on simgear, flightgear and fgdata named release/2.6.0<br />
##:''git branch release/2.6.0''<br />
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.6.0 -> 2.7.0)<br />
##Compile and test drive FlightGear with the new development version number<br />
##Commit the changes of version-number to next/master<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.7.0"<br />
##:''git tag -a version/2.7.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' release/2.6.0 '''and''' the tags upstream<br />
##:for flightgear, simgear and fgdata: ''git push origin release/2.6.0''<br />
##:for flightgear, simgear and fgdata: ''git push origin version/2.6.0''<br />
##:for flightgear, simgear and fgdata: ''git push origin version/2.7.0''<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##: Declare dev-streams "open" or "green"<br />
##: Change the content of wiki template at [[Template:GitStatus]] to <tt><nowiki>{{GitStatus:open}}</nowiki></tt><br />
##:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build<br />
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement<br />
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.<br />
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.<br />
##Tag the release/2.6.0 branches of simgear, flightgear and fgdata and push the tags.<br />
##:for flighgear, simgear and fgdata: ''git tag version/2.6.0-final''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0-final''<br />
##Merge the branch release/2.6.0 into '''master''' (<u>'''NOT'''</u> next) for flightgear and simgear and push the branch<br />
##:We don't have a next branch for fgdata, no merging of the release branch here.<br />
##:for flighgear and simgear: <br />
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch<br />
##:''git merge version/2.6.0-final<br />
##:''git push origin master''<br />
<br />
=== To bump up the version number ===<br />
* fgdata<br />
** edit the ''version'' file<br />
* SimGear<br />
** edit the ''version'' file<br />
* FlightGear<br />
** edit the ''version'' file<br />
** <s>edit ''CMakeLists.txt''</s><br />
**: <s>change the line '''find_package(SimGear 2.5.0 REQUIRED)'''</s><br />
** <s>edit ''src/Main/options.cxx''</s><br />
**: <s>change the line '''static char required_version[] = "2.5.0";'''</s><br />
** <s>edit configure.ac</s> (Obsolete, automake is gone)<br />
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s><br />
<br />
=== Definition of repository states ===<br />
* Open/Green<br />
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.<br />
* Frozen/Yellow<br />
*:No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.<br />
*:It's a good idea for aircraft developers to adhere to this rule. However, aircraft in FGDATA may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.<br />
* Closed/Red<br />
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.<br />
<br />
=== Bug fix committing policy ===<br />
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.6.0.<br />
A fix goes into release/2.6.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next. <br />
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.6.0 branch.<br />
<br />
'''DO NOT''' merge next into release/2.6.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.<br />
<br />
=== Bug tracking ===<br />
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.<br />
<br />
Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.6.0 the list of fixed bugs].<br />
<br />
=== Legacy ===<br />
The branch for version 2.2.0 will be left untouched. No release has ever been created from this branch.<br />
<br />
The last official release was made from branch ''release/2.4.0'', tag ''version/2.4.0-final''.<br />
<br />
If everything goes well, version 2.6.0 will be available around Feb, 18th 2012.<br />
<br />
=== Tasks and owners ===<br />
* Announce the state-change of the dev-streams - TorstenD<br />
* Create/maintain the git branches - TorstenD<br />
* Track the bugs on the tracker, trigger developers, adjust bug-priorities - ThorstenB, Gijs, James, ...<br />
* Beta testing - '''EVERYBODY'''<br />
* Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki - ???<br />
* Pack RC and final version of FGDATA<br />
* Create the RC and final version (source-tarball) - Curt<br />
* Create the RC and final version for Linux - ThorstenB (for openSUSE)<br />
* Create the RC and final version for Windows - Curt<br />
* Create the RC and final version for MacOS - Tat<br />
* Distribute files to download servers - Curt<br />
* Make adjustments on the web-site<br />
** Collect/make screenshots for the gallery - Curt<br />
* Announce the new version to the public<br />
** Write a changelog: [[Changelog 2.6.0]] - all developers<br />
** Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins. - '''EVERYBODY'''<br />
<br />
=== Open items, questions ===<br />
* Automate the creation of Windows and Mac installers<br />
* Automate the creation of FGDATA distribution<br />
<br />
=== Lessons learned ===<br />
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.<br />
* {{Thumbs up}} feature freeze in general<br />
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.<br />
* {{Thumbs down}} feature freeze for aircraft<br />
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.<br />
* {{Thumbs down}} switching to a new version of supporting libraries like OSG.<br />
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.<br />
* {{Thumbs down}} manual creation of release candidates and the release binaries<br />
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.<br />
* {{Thumbs down}} release date/time frame<br />
*: It took several days to release all the subparts. Might be better to upload all files and pages to hidden folders and publish them all at once (or at least within a couple of hours). That'll have several advantages:<br />
*:* no big difference between releases for the various OS.<br />
*:* the website will switch to the new release state quickly. With 2.6.0, the aircraft page was published before the setup. The release announcement was published even later.<br />
<br />
[[Category:FlightGear]]<br />
[[Category:Core developer documentation]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_April_2012&diff=47890FlightGear Newsletter April 20122012-04-17T16:48:29Z<p>T3r: Just the spelling of my name ;-)</p>
<hr />
<div>{{draft|newsletter}}<br />
<br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
== Development news ==<br />
<br />
=== Mailing list digest ===<br />
<br />
(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list or the git logs)<br />
<br />
=== Forum digest ===<br />
<br />
=== Git digest ===<br />
<br />
== Interview with a contributor (Sam Clancy) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]!''<br />
<br />
'''[http://www.flightgear.org/contributors/ Read this and previous interviews at our website's archive].'''<br />
<br />
* '''How long have you been involved in FlightGear?'''<br />
Actively I've been involved with the FlightGear project since early January 2011. Simply because my old computer (which my family had had for about 5 or 6 years prior) couldn't run FlightGear. But after we upgraded... (insert evil laugh here)<br />
* '''What is your forum nickname?'''<br />
connect is my name.<br />
* '''What are your major interests in FlightGear?'''<br />
Flying, first of all. My life dream is to become a commercial airline pilot, hopefully somewhere in Europe. I've taken my very first steps towards this in real life, with my "TIF" or Training Introductory Flight, but I also believe my prior experience FlightGear, and of course my continued use of FlightGear gives me a much cheaper alternative, for the time being, to gain experience.<br />
* '''Why is it that you are interested in flight simulation or aviation in general?'''<br />
The fact that it took mankind literally thousands of years to figure out how to fly, in just a century we've gone from the Wright Flyer all the way to the Antonov An-225, the Airbus A380, the Boeing 747, the list is endless. I think the fact we got to the moon is pretty good to.<br />
* '''What project are you working on right now?'''<br />
I think you mean projects, in my case. I've actually got three on the go; all of which I am collaborating on (something I love with FlightGears community spirit). They are; the Airbus A350-900XWB in co-operation with Malik Guest (tehwarlock). The Jabiru J-170 (the aircraft I completed my "TIF" or Training Introductory Flight in) with Narendran Muraleedharan (Omega Pilot/Omega95) and Project Brisbane, perhaps the most ambitious, with Lachlan Bruce (spitfirebruce21), Drew Gibson (VH-TIT/FlightGearNZ) and Malik Guest (tehwarlock).<br />
* '''What do you plan on doing in the future?'''<br />
I actually don't know. I just hope I can develop my skills enough to contribute something really good to the FlightGear Project.'''<br />
* '''Are you happy with the way the FlightGear project is going?<br />
Overall; yes. Having come in the days of v2.0.0 and at one stage, using 0.9.0, it's blatantly obvious the progress that has been made in the year or so I've been actively involved in the community.<br />
* '''On average, how much time do you spend working with/contributing to FlightGear?'''<br />
A day? Hours. Note the plural form of the word. I don't have a number, as I'm frankly not pedantic enough to record, but I assume it'd scare me.<br />
* '''Which of the more recent FlightGear developments do you consider most interesting/appealing?'''<br />
Thorsten's Local/Advanced Weather; I use it everytime I fly. It's alot nicer visually then the "Global/Simple Weather" and I think it competes with FSX and REX.<br />
* '''What do you enjoy most about developing for FlightGear?'''<br />
The satisfaction you get when something works! Maybe that's because I'm not the most technically minded, hehe.<br />
<br />
'''[http://www.flightgear.org/contributors/ Read this and previous interviews at our website's archive].'''<br />
<br />
== Snapshot releases ==<br />
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].<br />
<br />
The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].<br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.<br />
<br />
=== New aircraft ===<br />
New Embraer - 195, developed by the group FGBr.<br />
version FG 2.4 / 2.6<br />
Soon this site: www.grupofgbr.com.br<br />
[[File:Embraer - 195 em desenvolvimento (2)..jpg]]<br />
[[File:Embraer - 195 em desenvolvimento..jpg]]<br />
[[File:Embraer - 195 em desenvolvimento (4)..jpg]]<br />
[[File:Embraer - 195 em desenvolvimento (3)..jpg]]<br />
Soon this site: www.grupofgbr.com.br<br />
<br />
=== Updated aircraft ===<br />
The Zivko Edge by Torsten Dreyer was already a great airplane, Jentron worked the FDM over and now its quite capable of tumbling and spinning with rough handling.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Birds in FG ===<br />
Every so often I get fed up modelling buildings, so I think of other (often silly) things I can model for FlightGear. I have already made several low-poly models which can be used with AI scenarios. This time I have created an animated Seagull. [[File:Sea_Gulls_2.png|thumb|]]<br />
<br />
By attaching him, and variations of him, as sub-models to an invisible rotating base, You can have several seagulls circling above any model which has an .xml file. <br />
<br />
There are 2 standard sub-model entries which can be added individually or together to an existing model’s .xml file. Each will add 4 Seagulls:<br />
<model><br />
<path>Models/Fauna/SeaGull_Origin.xml</path><br />
<offsets><br />
<x-m> 0.0</x-m><br />
<y-m> 0.0</y-m><br />
<z-m>15.0</z-m><br />
</offsets><br />
</model><br />
The above option is already available and the one below has been sent for inclusion in the model database, and should be available very soon.<br />
<model><br />
<path>Models/Fauna/SeaGull_Origin_2.xml</path><br />
<offsets><br />
<x-m> 0.0</x-m><br />
<y-m> 0.0</y-m><br />
<z-m>20.0</z-m><br />
</offsets><br />
</model><br />
<br />
These entries can be altered to your own preference, or if you so wish you can alter the individual Seagull variations, which can be found in <tt>[[$FG_ROOT]]/Models/Fauna</tt>.<br />
<br />
Who says we have to be serious all the time. Have fun. Enjoy.<br />
<br />
VicMar<br />
<br />
=== TerraGear ===<br />
As you might be aware there is constant genapts850 development going on, to bring the apt.dat 850 format features (and beyond) to FlightGear. This work has now been merged into the official Terragear git repository for general consumption. Work is still ongoing to bring missing features like some special light variants, runway shoulders and different textures in. Some bad bugs have been fixed recently and there are even Windows binaries available from our build server.<br />
<br />
== Aircraft of the month ==<br />
<br />
== Airport of the month ==<br />
"Airport International Of Guarulhos (SBGR Sao Paulo)"<br />
<br />
[[File:International_Airport_Of_Guarulhos.jpg]]<br />
[[File:International Airport Of Guarulhos (1).jpg]]<br />
[[File:International Airport Of Guarulhos (2).jpg]]<br />
<br />
International Airport Of Guarulhos In Sao Paulo City Brasil<br />
In the site: www.grupofgbr.com.br<br />
<br />
== Screenshot of the month ==<br />
FlightGear is going to simulate the effect of air pollution - with some air pollution, sunrise colors become a lot more spectacular, as demonstrated here by a DR-400 experiencing a sunrise flying close to Nice (France).<br />
<br />
[[File:Dr400-nice.jpg|800px]]<br />
<br />
== Suggested flights ==<br />
<br />
=== Central Karakoram range ===<br />
Let's explore one of the highest regions of the planet - the central Karakoram with the densest concentration of mountains of 8000 m and above. We're going to need a good climbing performance for the trip - even the frozen plateau of Baltoro glacier above which K2 and Gasherbrum V and VI loom is more than 13.000 ft high.<br />
<br />
[[File:Karakoram1.jpg|300px|thumb|left|Circling Gasherbrum I]]<br />
<br />
Take off from Skardu airport in Pakistan (OPSD). Skardu has a reasonably long (11,944 ft) runway at just 7,316 ft elevation, so you can take a jet, but for instance the Twin Otter is more stylish. <br />
<br />
South of Skardu lies Deosai park, a famous high plateau, but we turn initially east. There's a chain of lakes which is the Indus river. After about five miles, the Shigar river merges with the Indus. Turn slightly left and follow the Shigar, then follow it into a long and broad lake-filled valley stretching into north-western direction. <br />
<br />
Towards the end of the lake, a small tributary river, the Braldu, turns eastward out of the main valley. Follow the Braldu and start climbing (if you haven't done so yet). About 15 miles after turning into the Braldu river valley, two glacier-filled valleys stretch to the north - admire the view!<br />
<br />
[[File:Karakoram2.jpg|300px|thumb|right|Heading back into Skardu, Nanga Parbat on the horizon]]<br />
<br />
Passing a few lakes, you reach finally Baltoro glacier continuing the river valley stretching eastward. Ever climbing, follow the glacier till you reach some kind of T-junction. The glacier arm reaching north leads to K2 (which sadly isn't really there in Flightgear), but just ahead of you are the still rather impressive peaks of Gasherbrum V, VI and I - circle the range and make some pictures!<br />
<br />
<br />
<br />
A good way back to Skardu is to go about 10 miles sourth from the Gasherbrum peaks, then head due west. To your west, you can see the long valleys fall away from the high ranges, to your right is the still glacier-covered high Karakoram. On a clear day (really good visibility selected) you can see the distinctive peak of Nanga Parbat appearing straight ahead on the horizon. The valley of Skardu is quite a distinctive feature and finding back VFR should not be a problem.<br />
<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
Throughout April, various aspects of the wiki have been changed or updated. The wiki software is now running the latest stable release, providing better security and usability. A side effect of this update is a bunch of new features.<br />
<br />
Besides the update, several new extensions were installed. <br />
<br />
Some of the most noticeable changes include:<br />
* The '''upload wizard''' guides you through the process of uploading files. It provides an user interface to fill in the information template that we discussed in the previous newsletter edition. And should therefore help us archiving files in a way that they can be easily found back and used among the wiki and other places.<br />
* Vector is the '''new default style''' of the wiki. It comes with a more advanced search box (moved to the top right of the page), showing suggestions of articles that you might be looking for.<br />
<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
* The [[OpenRadar]] project is looking for a new maintainer.<br />
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Did you know ===<br />
<br />
[[Category:FlightGear Newsletter|2012 04]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Zivko_Edge_540&diff=44880Zivko Edge 5402012-03-19T19:21:46Z<p>T3r: Authors</p>
<hr />
<div>{{infobox Aircraft<br />
|image =Zivko_Edge_540.jpg<br />
|name =Zivko Edge 540<br />
|type = Aerobatic aircraft<br />
|status-fdm = 4<br />
|status-systems = 2<br />
|status-cockpit = 5<br />
|status-model = 4<br />
|fdm =JSBSim<br />
|status =Alpha<br />
|authors =Torsten Dreyer (3D, FDM) Ron Jensen (FDM)<br />
|fgname =ZivkoEdge540<br />
}}The '''Zivko Edge 540''' manufactured by Zivko Aeronautics is a highly [[:Category:Aerobatic|aerobatic]] [[aircraft]].<br />
<br />
The Zivko Edge 540X is the most common aircraft used in the [[Red Bull Air Race]] World Series, in fact all champions of the World Series have flown this aircraft.<br />
<br />
== Aircraft help ==<br />
{| class="prettytable"<br />
|O<br />
|Toggle smoke on/off<br />
|}<br />
<br />
== Related content ==<br />
* [[Red Bull Air Race]]<br />
<br />
[[Category:Aerobatic]]<br />
[[Category:Aircraft]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Zivko_Edge_540&diff=44879Zivko Edge 5402012-03-19T19:21:19Z<p>T3r: Rating</p>
<hr />
<div>{{infobox Aircraft<br />
|image =Zivko_Edge_540.jpg<br />
|name =Zivko Edge 540<br />
|type = Aerobatic aircraft<br />
|status-fdm = 4<br />
|status-systems = 2<br />
|status-cockpit = 5<br />
|status-model = 4<br />
|fdm =JSBSim<br />
|status =Alpha<br />
|authors =Torsten Dreyer<br />
|fgname =ZivkoEdge540<br />
}}The '''Zivko Edge 540''' manufactured by Zivko Aeronautics is a highly [[:Category:Aerobatic|aerobatic]] [[aircraft]].<br />
<br />
The Zivko Edge 540X is the most common aircraft used in the [[Red Bull Air Race]] World Series, in fact all champions of the World Series have flown this aircraft.<br />
<br />
== Aircraft help ==<br />
{| class="prettytable"<br />
|O<br />
|Toggle smoke on/off<br />
|}<br />
<br />
== Related content ==<br />
* [[Red Bull Air Race]]<br />
<br />
[[Category:Aerobatic]]<br />
[[Category:Aircraft]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2012&diff=42124FlightGear Newsletter February 20122012-02-19T20:24:02Z<p>T3r: FlightGear 2.6.0 released!</p>
<hr />
<div>{{draft|newsletter|Feel free to contribute! Or [[FlightGear Newsletter January 2012|read the latest edition]].}}<br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
== FlightGear 2.6.0 Released ==<br />
Following our [[Release_plan]], version 2.6.0 of our simulator has been released. Please check the [[Changelog_2.6.0]] for what has changed since our last release 6 month ago.<br />
<br />
== Development news ==<br />
<br />
=== Heads up: Project Rembrandt ===<br />
As many of you may have heard already, Fred is currently making huge progress on adding shadows to FlightGear in [[Project Rembrandt]]. Now, F-JJTH ported the P92 to use the new system and posted a youtube video demonstrating [[Project Rembrandt]] at work. To provide feedback, please check out the the [http://flightgear.org/forums/viewtopic.php?f=47&t=14883 forum thread].<br />
<br />
{{#ev:youtube|v02phoOqWHE|400|Project Rembrandt at work}} [[File:Project-rembrandt-cockpit-lighting.png|400px|Cockpit lighting in Project Rembrandt at work (by F-JJTH)]]<br />
<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Snapshot releases ==<br />
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].<br />
<br />
The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].<br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.<br />
<br />
=== A new instrument: Vertical Situation Display ===<br />
[[File:Omega95-vsd-instrument.jpeg|250px|thumb|Omega95's VSD instrument]]<br />
Omega95 has created an entirely new instrument type for FlightGear, a so called Vertical Situation Display (VSD).<br />
<br />
This was done entirely in scripting space using Nasal and XML animations. He's basically proven everbody wrong who ever claimed that complex instruments couldn't yet be created in scripting space. Apparently, he managed to create this instrument in less than 24 hrs. His first question related to this was about accessing trigonometric functions from Nasal, shortly thereafter he posted screen shots depicting his VSD. <br />
<br />
To read up on the whole discussion, please see [http://flightgear.org/forums/viewtopic.php?f=30&t=15200 the forum topic]. There's work ongoing to turn his project into a new tutorial for the wiki on creating complex instruments in scripting space: [[Howto: Implement a Vertical Situation Display in Nasal]].<br />
<br />
<br />
=== Glider winch launching ropes ===<br />
[[File:DG-101G_winch_launch_with_rope.png|thumb|250px|A DG-101G during a winch launch.]]<br />
FlightGear never showed ropes during winch launching. [[User:Gijs|Gijs]] started working on an animated 3D rope, attached to the glider and winch. The cable exist of the following parts:<br />
<br />
* '''Strop''' (3 m) attached to the glider with a ring.<br />
* '''Weak link assembly''' designed to break apart before the cable or any other equipment fails.<br />
* '''Trace''' (17 m)<br />
* '''Parachute''' so the cable doesn't drop too quickly after releasing.<br />
* '''Launch cable''' the longest part; all the way to the winch.<br />
<br />
=== New aircraft ===<br />
==== Hawker Siddeley Harrier GR.1 ====<br />
[[File:Harrier-GR1 Splash.png|thumb|250px|Harrier GR.1 splash screen]]<br />
[[Hawker Siddeley Harrier GR1]] is a private project by pjedvaj, it was not intended to replace or update the existing [[British Aerospace Harrier]].<br />
<br />
It has a detailed 3D model, animations and RAF livery. Instruments and HUD are fairly authentic. The aircraft has working ADEN guns and basic fuel and weight control. FDM is adapted from the original BAe Harrier, internal and external fuel tank capacities are modified to match the GR.1 version.<br />
<br />
=== Updated aircraft ===<br />
==== Boeing 787-8 Dreamliner ====<br />
[[File:boeing-787-8-splash.png|thumb|250px|The Boeing 787-8 Splash Screen]]<br />
The Boeing 787-8 Dreamliner has already been there in FlightGear for a very long time but then it didn't have many of the 787's features like a realistic glass cockpit and many of the instruments.<br />
<br />
The new/updated Boeing 787-8 is a community project that features new JSBSim flight dynamics, Vertical Navigation, realistic 787 glass cockpit, new CDU, Electronic Flight Bag, TCAS, advanced Nav Displays, [[Howto:_Implement_a_Vertical_Situation_Display_in_Nasal|Vertical Situation Display]], [[Howto:_Implement_a_Fly-By-Wire_System_for_Airliners|Fly-by-wire]] and a lot of other neat features. It has not exactly been completed and the project is still running.<br />
<br />
You can find out more about the Boeing 787-8 Project HERE or wait for a while till a wiki page is created for it. One of the really good points of this project is how most of our findings and resources have been converted into Wiki HowTos for other aircraft developers to use for their projects.<br />
<br />
==== Cessna 337G Skymaster ====<br />
[[File:Cessna337-cockpit.png|thumb|250px|General view of the new Cessna 337G Skymaster cockpit]]<br />
The [[Cessna 337G Skymaster]] from the Spain-Latinamerica "Vive FlightGear" factory have received a major update. <br />
<br />
The new cockpit is now totally modelled, almost buttons and knobs are functional, animated, and properly labeled for easy identification.<br />
<br />
New custom sounds, lights, controls, a Bendix/King avionics pack capable of full IFR and night navigation, 2 new HQ liveries and the first FlightGear's working [[ELT]] (Emergency Locator Transmitter) are part of this great improvement on a FlightGear aircraft.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Shanghai Skylines: FG's New (not-so-)Hidden Gem ===<br />
[[File:SH fgfs-screen-001.png|250px|thumb|A view of the Shanghai skyline]][[File:Shanghai003.png|250px|thumb]][[File:Shanghai007.png|250px|thumb]]<br />
Shanghai is one of the biggest city in China and is among the cities with the most number of skyscrapers -this is now also true for FlightGear.<br />
21 models were created over the past few months by JVC, who also modeled the Akashi-Kaikyo Bridge in Japan and the United Nations building in New York.<br />
<br />
=== Airports ===<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
===Copacabana to San Rafael over Lake Titicaca===<br />
Bolivia to Peru. This trip will lead you over one of the highest and deepest lakes in the world towards the highest airfield in the world. It a demonstration of a [[IFR]] flight towards a fix and a demonstration how accurate FlightGear simulates air density and the effects it has on aircraft.<br />
[[File:Slcc-sprf.jpg|thumb|200px|left|Flight and fix SLCC to SPRF]]<br />
Place your aircraft on the airfield [http://en.wikipedia.org/wiki/Copacabana,_Bolivia SLCC, Copacabana], with an [[elevation]] of 12,592 feet. FlightGear will show snow all around you but that is not very realistic so let's clean up. View=> Rendering Options=> Snow line=> Set to max. (5,000M). <br />
<br />
We will fly towards and land at SPRF. If you would enter SLCC and SPRF in [[Kelpie]] planner you probably would not be able to find SPRF. To find SPRF I am adding an additional VOR-DME station and for a good fix give you another VOR-DME. Try Kelpie planner to plan this route and compare with this suggestion.<br />
<br />
Equipment preparation. Set [[NAV1]] to [http://en.wikipedia.org/wiki/Juliaca Juliaca] VOR-DME on 155.55 with a radial of 311° (magnetic). Set [[NAV2]] to Arequipa VOR-DME on 113.7 with a radial of 212°. During our flight we will fly with [[true altitude]] as set with [[QNH]], keep QNH updated. Arm the autopilot with the [[heading bug]] at 311° and an initial altitude of 13,500 feet.<br />
<br />
Take off and if you took the wrong RW pull up hard. Take a small tour over [http://en.wikipedia.org/wiki/Titicaca lake Titicaca], see the floating islands and try to find the lost golden treasure. Intercept the nearest radial on NAV1 towards Juliaca (about 311°). <br />
<br />
Just before Juliaca is a hill so while on lake Titicaca increase altitude to 14,200 feet, the [[VFR]] part of this trip is over. After passing Juliaca set the radial of NAV1 to 352° and set the altitude to 17,422 feet. We will fly from NAV1 and slowly increase altitude.<br />
<br />
At a distance of about 60 NM set the heading bug on the current course. Monitor the distance to NAV1, the radial of NAV2 and the distance to NAV2. At a distance of 74.5 NM to NAV1, a distance of 140.7 NM and at the '''radial''' intercept of NAV2 should be the runway. So, from 60 NM onwards, look outside the window, then at NAV1 and then NAV2 etc.<br />
<br />
If you are at 80NM to NAV1 you have missed the airfield but you still won't hit any hills (unless you bank left). Bank right and set the heading bug to 172°. Fly back towards NAV1 and intercept the radial 352° at about 50NM again to repeat the search.<br />
<br />
The runway SPRF, San Rafael, has a elevation of 14,422 feet and a heading of 297°/ 117°. Our initial altitude has been set 3,000NM above the RW elevation. That should give sufficient room for navigation.<br />
<br />
After you have seen the airfield set the radial of NAV1 to 297°, the heading of the runway (not the course to the runway) as a visual aid. Land on RW 30 (and not on RW 12 unless you are a show-off). Oh, there is a small hill in front of RW 30, just so you know.<br />
<br />
Decreasing speed at this altitude can be a bit tricky. The air is thin and does not give much resistance. Next to that, the difference between [[indicated airspeed]] and [[ground speed]] is very noticeable. The ground speed is much higher as the indicated airspeed.<br />
<br />
After a successful landing, try to discover the [[Suggested_Flights#Origin_of_the_Amazon_River | origin of the Amazon river]] since we are now at the starting point of that trip.<br />
<br />
*More places you can visit can be found at [[Suggested Flights]].<br />
<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
[[User:Johan G|Johan G]] did a great job categorising all images. All sub-categories are listed under [[:Category:Images]]. Please note when uploading images that it's important to give the file a descriptive name. That'll make it easier for others to find your file and use it in articles.<br />
<br />
A good example comes from Michat who has designed new small logos for [[Dual Control]] and [[Bombable]] aircrafts allowing you to see at a glance if aircraft has some of those interesting features.<br />
<br />
[[File:Dualcontrolready2.png|Dual_control]] [[File:BombableReady.png|Bombable]].<br />
<br />
<br />
<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
* [http://youtu.be/hBEaOMzBq6E KSFO Thermal Demo] by MD-BFC Going on their way for Bocian certification<br />
* [http://youtu.be/-yI5PzC5RE8 Sukhoi 37 'The russian dream'] by Águilas de FlightGear performing "Balalaika amok" master tune by Aleksei Arkhipovsky.<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
* The [[OpenRadar]] project is looking for a new maintainer.<br />
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Did you know ===<br />
...that you can use expressions to create complex animations of objects in your 3d models or even drive them from multiple properties?<br />
Usually, an animation looks like this<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<property>foo/bar</property><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
You can add a scaling factor or an offset to it, but that's basically all you can do that way. <br />
If you want to animate your object following a complex function, most people create complex Nasal scripts to compute the driving properties, probably not knowing that there is another way to achieve the goal: Expressions. <br />
Here is an example for a translate animation depending on two properties and the cosine function<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
A rich set of predefined functions is available, including almost all those you have on your scientific pocket calculator.<br />
<br />
[[Category:FlightGear Newsletter|2012 02]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Changelog_2.6.0&diff=41743Changelog 2.6.02012-02-15T20:12:09Z<p>T3r: /* Some of the major changes include: */</p>
<hr />
<div>{{Draft|changelog|''It should not (yet) be seen as an official document.''.}}<br />
FlightGear 2.6.0 ChangeLog<br />
<br />
The [[FlightGear]] development team is happy to announce the v2.6.0 release of FlightGear, the free, open-source flight simulator. <br />
This new version contains many exciting new features, enhancements and bugfixes. Major improvements from v2.4.0 include <br />
reduced AI aircraft load times, easier graphics tuning, more sophisticated AI aircraft and improved usability.<br />
<br />
Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create <br />
the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world <br />
by desktop flight simulator enthusiasts, for research in Universities and for interactive exhibits in museums.<br />
<br />
FlightGear features more than 400 aircraft, a worldwide scenery database, a worldwide multi-player environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute. <br />
<br />
Download FlightGear V2.6.0 for free from [http://www.flightgear.org FlightGear.org]<br />
<br />
FlightGear - Fly Free!<br />
<br />
=== Some of the major changes include: ===<br />
<br />
'''Aircraft operations:'''<br />
* At selected airports, FlightGear can automatically start at an appropriate parking spot based on the size and type of your aircraft. <br />
<br />
'''AI system'''<br />
* To reduce stuttering during model loading and take further advantage of multi-core CPUs, MP and AI aircraft models are now loaded in a background thread.<br />
* To reduce load times still further, only the parts of the aircraft currently visible are loaded from disk. <br />
* AI and multiplayer aircraft are no longer silent objects, they can produce sounds just like the main aircraft.<br />
<br />
'''AI Traffic'''<br />
* Many new and updated AI aircraft and liveries. Over 80 airlines now populate the virtual skies.<br />
* The range at which AI aircraft are displayed is now configurable, allowing you to tune FlightGear for best performance.<br />
* AI controlled pilots have received extensive landing training wit, and now make a more realistic approach, and vacate the runway when able.<br />
* The simulator now assigns an available parking position on startup.<br />
<br />
'''Flight dynamics'''<br />
* The JSBSim flight dynamics model received a major overhaul.<br />
<br />
'''Environment'''<br />
* The Local Weather package has been further integrated with the FlightGear core, and has been renamed "Advanced Weather". New rendering techniques allow more detailed clouds with no performance impact. High altitude clouds are rendered more realistically, and clouds move with the wind without impacting performance.<br />
<br />
'''Interface'''<br />
* New replay system. Video-player like controls, including slow motion and fast forward. Pilots can now take over the aircraft at any time during a replay. Great for training particular flight phases such as approach over and over again.<br />
* [[Formalizing Aircraft Status|Aircraft status ratings]] are displayed in the FlightGear launcher for a selected number of aircraft, allowing you to see at a glance the FDM, model, systems and cockpit quality.<br />
* Multiplayer settings can be accessed in-sim. You can now choose your callsign, select an MP server and connect within the simulator.<br />
* Automatic scenery download is now even easier to use. Simply select the scenery directory to download to, and switch it on.<br />
* Individual graphics effects can now be configured from within the Rendering Settings dialog, allowing you to fine-tune the performance of FlightGear within the sim.<br />
* The simulation of radio signal propagation has started and will make the reception of ATC messages and navigation aids more realistic in the future.<br />
* A new set of options makes it easier to create seamless and zoomable multi screen setups.<br />
* A new performance monitor shows the time spent in each subsystem.<br />
<br />
<br />
'''Highlighted new and improved aircraft'''<br />
* [[A-26 Invader]]: cockpit improvements.<br />
* [[Boeing 777-200ER]]: many additional and updated features, including autopilot, instrument displays and animations.<br />
* [[Douglas DC-3-C47|Douglas DC-3/C-47]]<br />
* [[Polikarpov I16]]: cockpit improvements.<br />
<br />
'''Navigation'''<br />
* <br />
<br />
'''Project infrastructure'''<br />
* CMake is now the only build system on Linux, Mac and Windows<br />
<br />
'''Scenery improvements'''<br />
* Detailed scenery is available for various areas in Europe, based on the CORINE data set.<br />
<br />
'''Visual effects'''<br />
* The sea now looks more realistic. Waves align with the wind, and foam appears at high wind speed.<br />
* Steep slopes now appear rocky.<br />
* Runways now appear wet during rain showers.<br />
* To help aircraft developers, a single shader combining bump-map, specular, reflection and light mapping components has been created. <br />
* The sky is now more realistic due to an improved skydome shader.<br />
<br />
'''Other'''<br />
* Additonal joysticks and rudder pedals are supported out-of-the-box, including the Logitech WingMan Interceptor, Saitek Pro Combat Rudder Pedals and Thrustmaster HOTAS Warthog.<br />
* [[FGPanel]], lightweight software to render 2D instrument panels, is now included in the setup.<br />
<br />
'''Bug fixes'''<br />
* See [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=Milestone%3D2.6.0 our bugtracker] for an extensive list of the bugs fixed in this release.</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Changelog_2.6.0&diff=41731Changelog 2.6.02012-02-15T18:51:39Z<p>T3r: /* Some of the major changes include: */</p>
<hr />
<div>{{Draft|changelog|''It should not (yet) be seen as an official document.''.}}<br />
FlightGear 2.6.0 ChangeLog<br />
<br />
The [[FlightGear]] development team is happy to announce the v2.6.0 release of FlightGear, the free, open-source flight simulator. <br />
This new version contains many exciting new features, enhancements and bugfixes. Major improvements from v2.4.0 include <br />
reduced AI aircraft load times, easier graphics tuning, more sophisticated AI aircraft and improved usability.<br />
<br />
Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create <br />
the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world <br />
by desktop flight simulator enthusiasts, for research in Universities and for interactive exhibits in museums.<br />
<br />
FlightGear features more than 400 aircraft, a worldwide scenery database, a worldwide multi-player environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute. <br />
<br />
Download FlightGear V2.6.0 for free from [http://www.flightgear.org FlightGear.org]<br />
<br />
FlightGear - Fly Free!<br />
<br />
=== Some of the major changes include: ===<br />
<br />
'''Aircraft operations:'''<br />
* At selected airports, FlightGear can automatically start at an appropriate parking spot based on the size and type of your aircraft. <br />
<br />
'''AI system'''<br />
* To reduce stuttering during model loading and take further advantage of multi-core CPUs, MP and AI aircraft models are now loaded in a background thread.<br />
* To reduce load times still further, only the parts of the aircraft currently visible are loaded from disk. <br />
<br />
'''AI Traffic'''<br />
* Many new and updated AI aircraft and liveries. Over 80 airlines now populate the virtual skies.<br />
* The range at which AI aircraft are displayed is now configurable, allowing you to tune FlightGear for best performance.<br />
* AI controlled pilots have received extensive landing training wit, and now make a more realistic approach, and vacate the runway when able.<br />
* The simulator now assigns an available parking position on startup.<br />
<br />
'''Flight dynamics'''<br />
* The JSBSim flight dynamics model received a major overhaul.<br />
<br />
'''Environment'''<br />
* The Local Weather package has been further integrated with the FlightGear core, and has been renamed "Advanced Weather". New rendering techniques allow more detailed clouds with no performance impact. High altitude clouds are rendered more realistically, and clouds move with the wind without impacting performance.<br />
<br />
'''Interface'''<br />
* New replay system. Video-player like controls, including slow motion and fast forward. Pilots can now take over the aircraft at any time during a replay. Great for training particular flight phases such as approach over and over again.<br />
* [[Formalizing Aircraft Status|Aircraft status ratings]] are displayed in the FlightGear launcher for a selected number of aircraft, allowing you to see at a glance the FDM, model, systems and cockpit quality.<br />
* Multiplayer settings can be accessed in-sim. You can now choose your callsign, select an MP server and connect within the simulator.<br />
* Automatic scenery download is now even easier to use. Simply select the scenery directory to download to, and switch it on.<br />
* Individual graphics effects can now be configured from within the Rendering Settings dialog, allowing you to fine-tune the performance of FlightGear within the sim.<br />
* The simulation of radio signal propagation has started and will make the reception of ATC messages and navigation aids more realistic in the future.<br />
<br />
<br />
'''Highlighted new and improved aircraft'''<br />
* [[A-26 Invader]]: cockpit improvements.<br />
* [[Boeing 777-200ER]]: many additional and updated features, including autopilot, instrument displays and animations.<br />
* [[Douglas DC-3-C47|Douglas DC-3/C-47]]<br />
* [[Polikarpov I16]]: cockpit improvements.<br />
<br />
'''Navigation'''<br />
* <br />
<br />
'''Project infrastructure'''<br />
* <br />
<br />
'''Scenery improvements'''<br />
* Detailed scenery is available for various areas in Europe, based on the CORINE data set.<br />
<br />
'''Visual effects'''<br />
* The sea now looks more realistic. Waves align with the wind, and foam appears at high wind speed.<br />
* Steep slopes now appear rocky.<br />
* Runways now appear wet during rain showers.<br />
* To help aircraft developers, a single shader combining bump-map, specular, reflection and light mapping components has been created. <br />
* The sky is now more realistic due to an improved skydome shader.<br />
<br />
'''Other'''<br />
* Additonal joysticks and rudder pedals are supported out-of-the-box, including the Logitech WingMan Interceptor, Saitek Pro Combat Rudder Pedals and Thrustmaster HOTAS Warthog.<br />
* [[FGPanel]], lightweight software to render 2D instrument panels, is now included in the setup.<br />
<br />
'''Bug fixes'''<br />
* See [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=Milestone%3D2.6.0 our bugtracker] for an extensive list of the bugs fixed in this release.</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2012&diff=40388FlightGear Newsletter February 20122012-02-09T06:26:34Z<p>T3r: /* Did you know */</p>
<hr />
<div>{{draft|newsletter|Feel free to contribute! Or [[FlightGear Newsletter January 2012|read the latest edition]].}}<br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
== Development news ==<br />
<br />
<br />
<br />
Omega95 has created an entirely new instrument type for FlightGear, a so called "VSD" (Vertical Situation Display). This was done entirely in scripting space using Nasal and XML animations. He's basically proven everbody wrong who ever claimed that complex instruments couldn't yet be created in scripting space. Apparently, he managed to create this instrument in less than 24 hrs, his first question related to this was about accessing trigonometric functions from Nasal, shortly thereafter he posted screen shots depicting his VSD. To read up on the whole discussion, please see [http://flightgear.org/forums/viewtopic.php?f=30&t=15200]. There's work ongoing to turn his project into a new tutorial for the wiki on creating complex instruments in scripting space: [[Howto: Implement a Vertical Situation Display in Nasal]].<br />
<br />
[[File:Omega95-vsd-instrument.jpeg|200px|thumb|Omega95's VSD instrument]]<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Snapshot releases ==<br />
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].<br />
<br />
The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].<br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.<br />
<br />
=== New aircraft ===<br />
<br />
=== Updated aircraft ===<br />
<br />
==== Cessna 337G Skymaster ====<br />
[[File:Cessna337-cockpit.png|thumb|250px|General view of the new Cessna 337G Skymaster cockpit]]<br />
The [[Cessna 337G Skymaster]] from the Spain-Latinamerica "Vive FlightGear" factory have received a major update. The new cockpit is now totally modelled, almost buttons and knobs are functional, animated, and properly labeled for easy identification. New custom sounds, lights, controls, a Bendix/King avionics pack capable of full IFR and night navigation, 2 new HQ liveries and the first FlightGear's working [[ELT]] (Emergency Locator Transmitter) are part of this great improvement on a FlightGear aircraft.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Airports ===<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
* [http://youtu.be/hBEaOMzBq6E KSFO Thermal Demo] by MD-BFC Going on their way for Bocian certification<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
* The [[OpenRadar]] project is looking for a new maintainer.<br />
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Did you know ===<br />
...that you can use expressions to create complex animations of objects in your 3d models or even drive them from multiple properties?<br />
Usually, an animation looks like this<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<property>foo/bar</property><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
You can add a scaling factor or an offset to it, but that's basically all you can do that way. <br />
If you want to animate your object following a complex function, most people create complex Nasal scripts to compute the driving properties, probably not knowing that there is another way to achieve the goal: Expressions. <br />
Here is an example for a translate animation depending on two properties and the cosine function<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
A rich set of predefined functions is available, including almost all those you have on your scientific pocket calculator.<br />
<br />
<s>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35900.html</s><br />
No,that's another "did you know" story and unrelated to expressions.<br />
--[[User:T3r|T3r]] 01:26, 9 February 2012 (EST)<br />
<br />
[[Category:FlightGear Newsletter|2012 02]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2012&diff=40380FlightGear Newsletter February 20122012-02-08T20:39:02Z<p>T3r: /* Did you know */</p>
<hr />
<div>{{draft|newsletter|Feel free to contribute! Or [[FlightGear Newsletter January 2012|read the latest edition]].}}<br />
{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
== Development news ==<br />
<br />
<br />
<br />
Omega95 has created an entirely new instrument type for FlightGear, a so called "VSD" (Vertical Situation Display). This was done entirely in scripting space using Nasal and XML animations. He's basically proven everbody wrong who ever claimed that complex instruments couldn't yet be created in scripting space. Apparently, he managed to create this instrument in less than 24 hrs, his first question related to this was about accessing trigonometric functions from Nasal, shortly thereafter he posted screen shots depicting his VSD. To read up on the whole discussion, please see [http://flightgear.org/forums/viewtopic.php?f=30&t=15200]. There's work ongoing to turn his project into a new tutorial for the wiki on creating complex instruments in scripting space: [[Howto: Implement a Vertical Situation Display in Nasal]].<br />
<br />
[[File:Omega95-vsd-instrument.jpeg|200px|thumb|Omega95's VSD instrument]]<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Snapshot releases ==<br />
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].<br />
<br />
The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].<br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.<br />
<br />
=== New aircraft ===<br />
<br />
=== Updated aircraft ===<br />
<br />
==== Cessna 337G Skymaster ====<br />
[[File:Cessna337-cockpit.png|thumb|250px|General view of the new Cessna 337G Skymaster cockpit]]<br />
The [[Cessna 337G Skymaster]] from the Spain-Latinamerica "Vive FlightGear" factory have received a major update. The new cockpit is now totally modelled, almost buttons and knobs are functional, animated, and properly labeled for easy identification. New custom sounds, lights, controls, a Bendix/King avionics pack capable of full IFR and night navigation, 2 new HQ liveries and the first FlightGear's working [[ELT]] (Emergency Locator Transmitter) are part of this great improvement on a FlightGear aircraft.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Airports ===<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
* [http://youtu.be/hBEaOMzBq6E KSFO Thermal Demo] by MD-BFC Going on their way for Bocian certification<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
* The [[OpenRadar]] project is looking for a new maintainer.<br />
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Did you know ===<br />
...that you can use expressions to create complex animations of objects in your 3d models or even drive them from multiple properties?<br />
Usually, an animation looks like this<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<property>foo/bar</property><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
You can add a scaling factor or an offset to it, but that's basically all you can do that way. <br />
If you want to animate your object following a complex function, most people create complex Nasal scripts to compute the driving properties, probably not knowing that there is another way to achieve the goal: Expressions. <br />
Here is an example for a translate animation depending on two properties and the cosine function<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
A rich set of predefined functions is available, including almost all those you have on your scientific pocket calculator.<br />
<br />
<br />
[[Category:FlightGear Newsletter|2012 02]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Hamburger_Flugzeugbau_HFB_320_Hansa_Jet&diff=39590Hamburger Flugzeugbau HFB 320 Hansa Jet2012-01-23T22:21:17Z<p>T3r: Autopilot, rating</p>
<hr />
<div>{{infobox Aircraft<br />
|image =Hansajet.jpg<br />
|caption =Deutsche Luftwaffe Hansajet<br />
|name =HFB 320 Hansa Jet<br />
|type =2 engine multirole<br />
|fdm =JSBSim<br />
|authors =Torsten Dreyer<br />
|fgname = Hansajet<br />
|status-fdm = 2<br />
|status-systems = 3<br />
|status-cockpit = 3<br />
|status-model = 2<br />
<br />
}}<br />
[[File:Hansajet-Schiphol.jpg|thumb|270px|HFB 320 Hansa Jet at [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) with drag chute deployed]]<br />
The '''Hamburger Flugzeugbau HFB 320 Hansa Jet''' was a West German passenger and multi-purpose [[aircraft]] developed in the 1960s, powered by two turbojets.<sup>[http://www.luftfahrtmuseum.com/htmi/itf/hf320.htm]</sup><br />
<br />
It did not have [[Howto: Add thrust reversal|thrust reversers]] but a drag chute installed to land on short fields.<br />
<br />
== Aircraft help ==<br />
=== Startup ===<br />
A tutorial exists for starting up the engines. This tutorial describes and performes all necessary items to get the engines running.<br />
# Pull the throttle levers to CUTOFF (fully back)<br />
# LH and RH WING-PUMP MAIN both ON, located at the overhead panel<br />
# check FUEL PRESSURE LOW lights OFF in the warning panel<br />
# Click START LH and START RH, engines spool up<br />
# Advance throttles to IDLE (a little more than 10%), check IGNITION lights in overhead panel ON<br />
# engines fire and after a few seconds check IGNITION lights are OFF in overhead panel<br />
# check engine rpm approx 50%<br />
# switch on GEN1 and GEN2, warning lights in the warning panel go off<br />
<br />
=== Using the Autopilot ===<br />
'''Don't use FlightGear's built in autopilot dialog. It does not work for the Hansajet.'''<br />
<br />
During takeoff, after passing 500ft GND, engage the autopilot by pressing CTRL-A or flipping the AFCS-ENG switch. This will enable HDG HOLD and PITCH HOLD and causing the Hansa to maintain the current magnetic heading and pitch attitude. It is recommended to also activate the yaw-damper.<br />
Note: the autopilot only engages if the current bank angle is less than 6 degrees.<br />
<br />
Using the PITCH Switch, adjust the pitch attitude of the aircraft. Flipping the switch forward decreases pitch (nose-down), flipping the switch back increases pitch (nose-up). The pitch change is proportional to the duration of the activation of the switch and changes at the rate of one degree per second.<br />
<br />
Pressing the ALT mode selector button activates altitude hold. The aircraft will maintain the altitude it was at the moment ALT was pressed. ALT mode is canceled by operating the PITCH switch or disengaging the autopilot.<br />
<br />
The TURN rotary knob is for performing turns. Turn the knob clockwise for right turns and counterclockwise for left turns. The rotation of the knob is proportional to the target bank angle of the jet with a maximum bank angle limited to 30 degrees.<br />
<br />
Pressing the HDG SEL mode selector switch activates the heading bug. In this mode, the pilot commands the target heading by setting the heading bug in the HSI.<br />
<br />
Note: <br />
Radio navigation is not yet implemented and the Three-Axis-Trim-Indicators are not yet functional.<br />
<br />
<br />
== Development status/Issues/Todo ==<br />
* The autopilot is stable but (still) incomplete<br />
* High altitude performance is unrealistic<br />
* Electrical system is incomplete<br />
* Hydraulic system is incomplete<br />
* Weather radar is missing<br />
* Many more<br />
<br />
== External links ==<br />
* http://www.luftfahrtmuseum.com/htmi/itf/hf320.htm<br />
* http://www.hansajet.de/indexeng.htm<br />
<br />
* [http://www.airliners.net/photo/Germany---Air/Hamburger-Flugzeugbau-HFB-320/1388669/M/ Photo (airliners.net)]<br />
* [http://commons.wikimedia.org/wiki/Category:HFB-320_Hansa_Jet?uselang=en Gallery of Luftwaffe HFB 320 (wikimedia.org)] at the [[Luftwaffe Museum Berlin-Gatow]].<br />
<br />
[[Category:Aircraft]]<br />
[[Category:Civilian aircraft]]</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Template:GitStatus&diff=39358Template:GitStatus2012-01-17T07:51:31Z<p>T3r: Open again</p>
<hr />
<div>{{GitStatus:open}}</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Template:GitStatus&diff=39357Template:GitStatus2012-01-17T06:41:36Z<p>T3r: Closed!</p>
<hr />
<div>{{GitStatus:closed}}</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Release_plan&diff=39301Release plan2012-01-15T09:41:53Z<p>T3r: /* Detailed Time Schedule and Checklist */</p>
<hr />
<div>This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release. <br />
<br />
[[File:ReleasePlan.jpg|thumb|250px|The original plan]]<br />
This release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.<br />
<br />
If you think you have something to contribute to the release process, feel free to <span class=plainlinks>[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]</span>. Please discuss this concept at the mailing-list.<br />
<br />
=== General Release Concept ===<br />
New FlightGear releases will be scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch will be created for SimGear, FlightGear and FGDATA. <br />
<br />
After branching, we will allow one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA will take place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August. <br />
<br />
The development stream of SimGear, FlightGear and FGDATA will be set into a frozen state one month before the branch-day (17th) to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.<br />
<br />
=== Version Numbers ===<br />
Releases will have even version numbers (2.2.0, 2.4.0, 2.6.0), bugfix releases will increase their least significant digit (2.2.0, 2.2.1, 2.2.2, 2.2.3).<br />
The Development stream uses odd version numbers and is usually one number higher than the current release (Released is 2.4.0, development stream is 2.5.0, next release will be 2.6.0).<br />
<br />
The Major version number will be increased after significant changes to the functionality of the software.<br />
<br />
=== Detailed Time Schedule and Checklist ===<br />
# Dec/Jun 17th: Development stream is declared "frozen" or "yellow".<br />
#:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
#:change the content of wiki template at [[Template:GitStatus]] to <pre>{{GitStatus:frozen}}</pre><br />
# Jan/Jul 17th: Create new release branch, assign new version number to dev-stream, re-open streams<br />
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"<br />
##change the content of wiki template at [[Template:GitStatus]] to <pre>{{GitStatus:closed}}</pre><br />
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.5.0 -> 2.6.0)<br />
##Compile and test drive FlightGear with the new version-number<br />
##Commit the new version number to next (flightgear+simgear) and master(fgdata)<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.6.0"<br />
##:''git tag -a version/2.6.0'' (Enter a wise comment)<br />
##Create the release branches on simgear, flightgear and fgdata named release/2.6.0<br />
##:''git branch release/2.6.0''<br />
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.6.0 -> 2.7.0)<br />
##Compile and test drive FlightGear with the new development version number<br />
##Commit the changes of version-number to next/master<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.7.0"<br />
##:''git tag -a version/2.7.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' release/2.6.0 '''and''' the tags upstream<br />
##:for flighgear, simgear and fgdata: ''git push origin release/2.6.0''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/2.7.0''<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
##: declare dev-streams "open" or "green"<br />
##: change the content of wiki template at [[Template:GitStatus]] to <pre>{{GitStatus:open}}</pre><br />
##:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
## Trigger James for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build<br />
# Feb/Aug 1st: Start preparing the release notes and a press announcement<br />
# Feb/Aug 17th: Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch<br />
##Tag the release/2.6.0 branches of simgear, flightgear and fgdata and push the tags.<br />
##:for flighgear, simgear and fgdata: ''git tag version/2.6.0-final''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0-final''<br />
##Merge the branch release/2.6.0 into '''master''' (<u>'''NOT'''</u> next) for flightgear and simgear and push the branch<br />
##:We don't have a next branch for fgdata, no merging of the release branch here.<br />
##:for flighgear and simgear: <br />
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch<br />
##:''git merge version/2.6.0-final<br />
##:''git push origin master''<br />
<br />
=== To bump up the version number ===<br />
* fgdata<br />
** edit the ''version'' file<br />
* SimGear<br />
** edit the ''version'' file<br />
* FlightGear<br />
** edit the ''version'' file<br />
** edit ''CMakeLists.txt''<br />
**: change the line '''find_package(SimGear 2.5.0 REQUIRED)'''<br />
** edit ''src/Main/options.cxx''<br />
**: change the line '''static char required_version[] = "2.5.0";'''<br />
** <s>edit configure.ac</s> (Obsolete, automake is gone)<br />
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s><br />
<br />
=== Definition of Repository States ===<br />
* Open/Green<br />
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.<br />
* Frozen/Yellow<br />
*:No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.<br />
*:It's a good idea for aircraft developers to adhere to this rule. However, aircraft in FGDATA may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.<br />
* Closed/Red<br />
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.<br />
<br />
=== Bug fix committing policy ===<br />
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.6.0.<br />
A fix goes into release/2.6.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next. <br />
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.6.0 branch.<br />
<br />
'''DO NOT''' merge next into release/2.6.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.<br />
<br />
=== Bug Tracking ===<br />
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.<br />
<br />
Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.6.0 the list of fixed bugs].<br />
<br />
=== Legacy ===<br />
The branch for version 2.2.0 will be left untouched. No release has ever been created from this branch.<br />
The last official release was made from branch ''release/2.4.0'', tag ''version/2.4.0-final''.<br />
If everything goes well, version 2.6.0 will be available around Jan, 18th 2012.<br />
<br />
=== Tasks and Owners ===<br />
(taskowners not yet assigned)<br />
* Announce the state-change of the dev-streams<br />
* Create/maintain the git branches<br />
* Track the bugs on the tracker, trigger developers, adjust bug-priorities<br />
* Beta testing<br />
* Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki<br />
* Pack RC and final version of FGDATA<br />
* Create the RC and final version (source-tarball)<br />
* Create the RC and final version for Linux<br />
* Create the RC and final version for Windows<br />
* Create the RC and final version for MacOS<br />
* Distribute files to download servers<br />
* Make adjustments on the web-site<br />
** Collect/make screenshots for the gallery<br />
* Announce the new version to the public<br />
** Write a changelog: [[Changelog 2.6.0]]<br />
** Contact flightsim websites and send them/link them to a "press release"<br />
<br />
=== Open Items, Questions ===<br />
* Automate the creation of Windows and Mac installers<br />
* Automate the creation of FGDATA distribution<br />
<br />
=== Lessons Learned ===<br />
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.<br />
* Good: feature freeze in general<br />
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.<br />
* Not so good: feature freeze for aircraft<br />
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.<br />
* Not so good: switching to a new version of supporting libraries like OSG.<br />
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.<br />
* Not so good: manual creation of release candidates and the release binaries<br />
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Release_plan&diff=39299Release plan2012-01-15T08:23:53Z<p>T3r: /* Detailed Time Schedule and Checklist */</p>
<hr />
<div>This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release. <br />
<br />
[[File:ReleasePlan.jpg|thumb|250px|The original plan]]<br />
This release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.<br />
<br />
If you think you have something to contribute to the release process, feel free to <span class=plainlinks>[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]</span>. Please discuss this concept at the mailing-list.<br />
<br />
=== General Release Concept ===<br />
New FlightGear releases will be scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch will be created for SimGear, FlightGear and FGDATA. <br />
<br />
After branching, we will allow one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA will take place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August. <br />
<br />
The development stream of SimGear, FlightGear and FGDATA will be set into a frozen state one month before the branch-day (17th) to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers are requested not to add any new features, subsystems or alike. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.<br />
<br />
=== Version Numbers ===<br />
Releases will have even version numbers (2.2.0, 2.4.0, 2.6.0), bugfix releases will increase their least significant digit (2.2.0, 2.2.1, 2.2.2, 2.2.3).<br />
The Development stream uses odd version numbers and is usually one number higher than the current release (Released is 2.4.0, development stream is 2.5.0, next release will be 2.6.0).<br />
<br />
The Major version number will be increased after significant changes to the functionality of the software.<br />
<br />
=== Detailed Time Schedule and Checklist ===<br />
# Dec/Jun 17th: Development stream is declared "frozen" or "yellow".<br />
#: Send a mail to the flightgear-devel mailing-list to announce the state.<br />
#: change the wiki template at [[Template:GitStatus]]<br />
# Jan/Jul 17th: Create new release branch, assign new version number to dev-stream, re-open streams<br />
##Send a mail to the flightgear-devel mail-list, asking not to commit/push anything, declare the streams "closed" or "red"<br />
## change the wiki template at [[Template:GitStatus]]<br />
##Bump up the version-number of simgear/next, flightgear/next and fgdata/master to an even number (2.5.0 -> 2.6.0)<br />
##Compile and test drive FlightGear with the new version-number<br />
##Commit the new version number to next (flightgear+simgear) and master(fgdata)<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.6.0"<br />
##:''git tag -a version/2.6.0'' (Enter a wise comment)<br />
##Create the release branches on simgear, flightgear and fgdata named release/2.6.0<br />
##:''git branch release/2.6.0''<br />
##On the next/master branches, bump up the version-number of simgear, flightgear and fgdata to an odd number (2.6.0 -> 2.7.0)<br />
##Compile and test drive FlightGear with the new development version number<br />
##Commit the changes of version-number to next/master<br />
##Tag (annotated) flightgear, simgear and fgdata with "version/2.7.0"<br />
##:''git tag -a version/2.7.0'' (Enter a wise comment)<br />
##Push the branches next/master '''and''' release/2.6.0 '''and''' the tags upstream<br />
##:for flighgear, simgear and fgdata: ''git push origin release/2.6.0''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/2.7.0''<br />
##:for flightgear and simgear: ''git push origin next''<br />
##:for fgdata: ''git push origin master''<br />
## declare dev-streams "open" or "green"<br />
##:change the wiki template at [[Template:GitStatus]]<br />
<br />
##:Send a mail to the flightgear-devel mailing-list to announce the state.<br />
## Trigger James for the Jenkins-builds and Curt for a snapshot release<br />
# Feb/Aug 1st: Start preparing the release notes and a press announcement<br />
# Feb/Aug 17th: Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch<br />
##Tag the release/2.6.0 branches of simgear, flightgear and fgdata and push the tags.<br />
##:for flighgear, simgear and fgdata: ''git tag version/2.6.0-final''<br />
##:for flighgear, simgear and fgdata: ''git push origin version/2.6.0-final''<br />
##Merge the branch release/2.6.0 into '''master''' (<u>'''NOT'''</u> next) for flightgear and simgear and push the branch<br />
##:We don't have a next branch for fgdata, no merging of the release branch here.<br />
##:for flighgear and simgear: <br />
##:''git checkout -b master origin/master'' or ''git checkout master'' if you already have the local branch<br />
##:''git merge version/2.6.0-final<br />
##:''git push origin master''<br />
<br />
=== To bump up the version number ===<br />
* fgdata<br />
** edit the ''version'' file<br />
* SimGear<br />
** edit the ''version'' file<br />
* FlightGear<br />
** edit the ''version'' file<br />
** edit ''CMakeLists.txt''<br />
**: change the line '''find_package(SimGear 2.5.0 REQUIRED)'''<br />
** edit ''src/Main/options.cxx''<br />
**: change the line '''static char required_version[] = "2.5.0";'''<br />
** <s>edit configure.ac</s> (Obsolete, automake is gone)<br />
**: <s>change the line '''AC_MSG_CHECKING([for SimGear 2.5.0 or newer])'''</s><br />
<br />
=== Definition of Repository States ===<br />
* Open/Green<br />
: Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five month after the release branches were created.<br />
* Frozen/Yellow<br />
*:No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.<br />
*:It's a good idea for aircraft developers to adhere to this rule. However, aircraft in FGDATA may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.<br />
* Closed/Red<br />
*:Nothing shall be pushed to the development streams (simgear, flightgear and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.<br />
<br />
=== Bug fix committing policy ===<br />
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.6.0.<br />
A fix goes into release/2.6.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next. <br />
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.6.0 branch.<br />
<br />
'''DO NOT''' merge next into release/2.6.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.<br />
<br />
=== Bug Tracking ===<br />
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.<br />
<br />
Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.6.0 the list of fixed bugs].<br />
<br />
=== Legacy ===<br />
The branch for version 2.2.0 will be left untouched. No release has ever been created from this branch.<br />
The last official release was made from branch ''release/2.4.0'', tag ''version/2.4.0-final''.<br />
If everything goes well, version 2.6.0 will be available around Jan, 18th 2012.<br />
<br />
=== Tasks and Owners ===<br />
(taskowners not yet assigned)<br />
* Announce the state-change of the dev-streams<br />
* Create/maintain the git branches<br />
* Track the bugs on the tracker, trigger developers, adjust bug-priorities<br />
* Beta testing<br />
* Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki<br />
* Pack RC and final version of FGDATA<br />
* Create the RC and final version (source-tarball)<br />
* Create the RC and final version for Linux<br />
* Create the RC and final version for Windows<br />
* Create the RC and final version for MacOS<br />
* Distribute files to download servers<br />
* Make adjustments on the web-site<br />
** Collect/make screenshots for the gallery<br />
* Announce the new version to the public<br />
** Write a changelog: [[Changelog 2.6.0]]<br />
** Contact flightsim websites and send them/link them to a "press release"<br />
<br />
=== Open Items, Questions ===<br />
* Automate the creation of Windows and Mac installers<br />
* Automate the creation of FGDATA distribution<br />
<br />
=== Lessons Learned ===<br />
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases.<br />
* Good: feature freeze in general<br />
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release.<br />
* Not so good: feature freeze for aircraft<br />
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release.<br />
* Not so good: switching to a new version of supporting libraries like OSG.<br />
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle.<br />
* Not so good: manual creation of release candidates and the release binaries<br />
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate.</div>T3rhttps://wiki.flightgear.org/w/index.php?title=Template:POTW/2012-3&diff=39268Template:POTW/2012-32012-01-14T14:00:53Z<p>T3r: typo</p>
<hr />
<div>{| class="prettytable" style="background-color:#efefef; width: 100%;" <br />
| align="center" |[[Image:Release-2.6.0.jpg|300px]]<br />
|-<br />
| align="left" | The release branches for FlightGear version 2.6.0 have been created in gitorious on Jan. 17th. <div style="text-align:right;">'''[[Release_plan|Read more...]] | [[:Category:Picture of the week 2012|Archive]]'''</div><br />
|}<br />
<br />
<noinclude>[[Category:Picture of the week 2012]]</noinclude></div>T3r