FlightGear wiki - User contributions [en]

Aircraft rating system

2010-10-03T12:36:23Z

MILSTD: /* Related Community Discussions */

== Formalizing Aircraft Status ==

=== Intro ===
Based on various mailing list discussions since 11/2007, it is getting clear that the current method of classifying aircraft development status is not satisfactory to adequately and fully describe an aircraft's development progress. Which can be pretty frustrating for developers, contributors and users, because of different expectations about an aircraft's "status".

This can be even witnessed in more recent discussions (03/2009), where users explicitly inquire about recommendations for feature-complete aircraft [http://www.flightgear.org/forums/viewtopic.php?f=2&t=3171], or users pointing out weaknesses in FDM configurations [http://flightgear.org/forums/viewtopic.php?f=4&t=3281].

This is mainly because of the fact that different people may have different requirements when it comes to aircraft status and are thus viewing the status from different angles, possibly neglecting progress in other areas.

In addition, users are frequently facing issues when it comes to determining compatibility requirements between aircraft tarballs and fgfs binary releases (see for example [http://flightgear.org/forums/viewtopic.php?f=6&t=2814]). This very issue is further complicated by the fact, that FlightGear in general doesn't expose any detailed version information that could be queried by arbitrary FlightGear resources (such as aircraft). Furthermore, it is questionable whether simply starting to expose version information in the property tree would be sufficient, i.e. for scenarios where individual features may be removed/added or modified in CVS/HEAD, which however wouldn't necessarily result in a modified version number, so that such modifications wouldn't be easily communicated to FlightGear resources that depend on such features and information (for a more in depth discussion of this particular issue, please see [http://wiki.flightgear.org/index.php/Simplifying_Aircraft_Deployment#Version_tracking.2FCompatibility_checking]).

=== Scope ===
This page is dedicated to providing a place to start collecting suggestions about how to describe aircraft development status more formally and reliably, to point out the strengths and weaknesses of individual aircraft implementations more comprehensively.

Given that people seem to be expecting different things when they read about an aircraft's development status being "alpha", "beta" or "production", it should be possible to address this issue, by starting to classify each aircraft's individual components (i.e. fdm, cockpit panel, 3d model etc) directly, rather than the overall aircraft itself which would result in less-developed parts of an aircraft (which can usually be assumed to be most of it) affecting an aircraft's development status negatively, even if it should feature some very well-developed parts.

=== Suggestions ===
This classification process should preferably take place by following certain conventions, so that it is likely that the majority of aircraft types, as well as their various features, are covered thoroughly.

This could for example be achieved by starting to evaluate aircraft based on abstract factors such as the following:

* status/realism of FDM configs (performance characteristics)
* status/realism of exterior 3D models
* status/realism of cockpit panels (2D/3D)
* status/realism of autopilot implementation
* status/realism of aircraft-specific instruments
* status/realism of procedure modeling (i.e. startup)
* status/realism of systems modeling
* status/realism of failure modeling
* status/realism of integrated checklists/procedures
* status/realism of integrated help (i.e. in the form of help dialogs)
* status/realism of integrated scripted tutorials
* status/realism of available documentation
* status/realism of overall usability

Furthermore, it might also be worthwhile to consider evaluating aircraft based on additional criteria such as:

* available support for multiplayer
* available support for AI traffic (i.e. 3D models featuring LOD support may be reused by the AIT system)
* available support for runtime customization (i.e. liveries)
* available support for eye candy/effects
* available support for saving/loading and continuing flights
* available support for saving/loading aircraft configurations

In addition, it is important to keep in mind that there are different requirements for aircraft to appear "realistic" - depending on whether they are mainly used in VFR settings or IFR settings, where the former application scenario puts an increased demand on visual effects, the latter requires IFR-specific features to be in place, for example proper IFR instrumentation, as well as correct navigation lights.

Therefore, it might be a good idea to not only evaluate individual components of an aircraft, but also its readiness for certain usage scenarios, such as for example VFR/IFR flight.

=== Desired Results ===

It can be expected that following this or similarly factually objective approaches to classifying aircraft development status, should not only help people understand more easily and more completely an individual aircraft's development status, but also highlight the strengths and weaknesses of an aircraft, so that aircraft authors are motivated because of the work they have actually done, rather than being discouraged because of the work they could not (yet) do (or might possibly never be able to do because of it being outside their usual scope of contributions).

Additionally, this would also help aircraft becoming more self-documented, so that new contributors could more easily see where and how their help could be used.

== Implementation ==

Implementing support for more thorough status-tracking should be fairly straight forward, as the current approach of keeping aircraft status information by using a property tree node in an aircraft's *-set.xml file, could be easily extended to provide additional meta information, of the aforementioned nature - using the previously suggested type of information, this could end up looking like the following:

<PropertyList>
<aircraft-status>
<fdm>beta</fdm>
<exterior>early-production</exterior>
<cockpit>alpha</cockpit>
<instrumentation>alpha</instrumentation>
<procedures>alpha</procedures>
<system-modeling>beta</system-modeling>
<failure-modeling>alpha<failure-modeling>
<checklist-support>alpha</checklist-support>
<tutorial-support>alpha</tutorial-support>
<documentation>alpha</documentation>
<usability>beta</usability>
<eye-candy>alpha</eye-candy>
</aircraft-status>
</PropertyList>

On the other hand, some of this information should probably not directly go into the toplevel *-set.xml file, but rather into files of the various components (i.e. the cockpit/panel status would be a good candidate to have its status being tracked directly in the panel file).

=== Extending status information ===
Given that not all conceivable status for the above mentioned criteria can be properly represented using the existing notion of "status" information being restricted to "alpha, beta, early-production...", it should be considered to support additional states, such as for example "none/unavailable", "draft" or "design".

While it would of course be much easier to simply provide a full-length description space of the status information for each individual entry, where each contributor could leave some information, this would make it more complicated to later on provide web-based frontends to facilitate searching/picking aircraft based on certain attributes.

On the other hand, it is not unlikely that even this level of more finely-grained status information should turn out insufficient in some cases, to describe the status properly, thus combining the two previously mentioned approaches of 1) providing formal status information and 2) providing an optional textual description of the progress would probably be the most powerful long-term solution.

This could for example be accomplished by allowing contributors to optionally specify a corresponding attribute to point to a plaintext (or possibly even HTML) file (residing in the aircraft's folder) that may contain further details, such an XML attribute, named "info-file" is shown in the following example:

<PropertyList>
<aircraft-status>
<fdm '''info-file="fdm-status.txt"'''>beta</fdm>
<exterior '''info-file="ext-status.txt"'''>early-production</exterior>
<cockpit '''info-file="cockpit-status.txt"'''>alpha</cockpit>
[...]
<eye-candy '''info-file="effects-status.txt"'''>alpha</eye-candy>
</aircraft-status>
</PropertyList>

These attributes could not only be easily parsed by an XML parser to provide web-based search facilities, they could even be used within FlightGear at runtime, to provide enriched status information by reading in the corresponding files and showing their contents in a dialog.

In the long run, it might even be an interesting option to provide optional support for three different attributes specifying filenames for these status-tags:

* bugs-filename=""
* fixme-filename=""
* todo-filename=""

That way, it would be possible for contributors to easily provide very detailed information about the development status of individual components or features, simply by dropping a corresponding file into the aircraft tarball, possibly using a standard-location/folder such as "meta-info" within the aircraft's folder.

Likewise, users noticing new issues could easily augment said files and send them to the maintainer to have them committed to HEAD, so that future users can first check out this information before possibly reporting a duplicate issue/feature request.

While it may seem unnecessary to provide this sort of information-collecting infrastructure to aircraft authors and their contributors, it would probably help aircraft development status become more self-documenting and aircraft-development itself become more self-contained, given that key information would be collected in one central place (the repository) and aircraft-specific issues/ideas could be easily reported and checked for by new contributors.
In the long run

=== A Flexible Approach ===
It is obvious that regardless of how many sensible rating-categories are now identified and used in FlightGear, people will sooner or later want to use modified or even completey new categories to rate the strengths and weaknesses of their aircraft.

Because of this, but also because hardcoding such tag names (i.e. property paths) would be unnecessarily tedious, given that FlightGear itself does not yet actively use this sort of information at the moment to provide aircraft picker/sorting facilities, one could simply by convention have ALL tags below one specific node (i.e. PropertyList/sim/aircraft-status/) -regardless- of their name be honored by potential search frontends.

===Future Extendability ===

Because of the easy and flexibility of directly using XML/PropertyList files together with the FlightGear Property Tree, this approach to supporting more finely-grained status information tracking is extremely powerful and is promising enough to even support highly detailed status information for complex aircraft that may feature a number of distinct components, for example to appropriately describe various high performance aircraft or airliners, child nodes could be used:

<systems-modeling>
<electrical></electrical>
<hydraulic></hydraulic>
<pneumatic></pneumatic>
...
</systems-modeling>

===Fully searchable Aircraft - by Type ===

Furthermore, many users have frequently requested a possibility to search and pick aircraft based on certain aircraft-specific characteristics, such as for example the type of aircraft (i.e. single engine vs. multi engine, piston vs. jet etc.)

This could also be easily accomplished by having aircraft authors and contributors provide such meta information in the same way, for example:

<PropertyList>

<type-of-aircraft include ="aircraft-type.xml"/>
</PropertyList>

NOTE: for the sake of illustration purposes, false values have
also been specified, even though they would be obsolete if all
all values are by default assumed to be false, which would
significantly reduce unnecessary overhead.

aircraft-type.xml:
<PropertyList>

<is-fixed-wing type="bool">true</is-fixed-wing>
<is-helicopter type="bool">false</is-helicopter>
<is-sailplane type="bool">false</is-sailplane>
<is-amphibian type="bool">false</is-amphibian>

<is-military type="bool">false</is-military>
<is-civilian type="bool">true</is-civilian>

<is-airliner type="bool">true</is-airliner>
<is-multi-cew type="bool">true</is-multi-cew>

<is-single-engine type="bool">false<is-single-engine>
<is-multi-engine type="bool">true<is-multi-engine>

<has-piston-propulsion type="bool">false</has-piston-propulsion>
<has-jet-propulsion type="bool">true</has-jet-propulsion>
...
</PropertyList>

From a programming point of view, this doesn't require any work as it only requires contributors to provide said information-however from a usability point of view, it adds the possibility for GUI/WEB frontends to easily offer a way to search aircraft using this information. By restricting this information to be of Boolean type, it is very straightforward to either directly search the base package or to simply create a small database for very powerful queries-by just having users check/uncheck a corresponding checkbox, no matter whether this is on a webpage or directly in a FlightGear GUI launchr such as fgrun.

=== Challenges ===
For some components (like FDM configs, 2D panels, 3D cockpits, exterior models or liveries) it may be possible to specify multiple separately referenced files in one single *-set.xml file, in these cases it would seem more appropriate to also track their development status separately in these files, rather than in the top-level aircraft file, this would make sure that the development status is really tracked on a per-component basis. So, that sharing aircraft resources still works properly while retaining component status information.

== Ease of Deployment ==

In order to simplify the introduction of the aforementioned concept to store aircraft status information, it might make sense to consider requesting aircraft authors/maintainers by convention to specify said status information externally, in a separate PropertyList-encoded XML file, that is then only referenced in a corresponding include attribute (i.e. <aircraft-status include="ac-status.xml"/>.

While this doesn't make any conceptual difference, it helps to to keep this structured information in a separate place.

Enforcing this convention could simplify the required parsing process in certain situations and would thus not only help creating web-based search/sort frontends using such status information attributes, but would also enable the wealth of existing standalone FlightGear launchers (most of which do not link to SimGear, and may thus not easily process PropertyList-XML files) to be able to easily deal with this information without having to parse the whole *-set.xml file, rather it would become possible to just concentrate on parsing said "aircraft-status.xml" file for certain purposes.

== Overall Rating/Status ==

If an overall aircraft rating is desired, it should be possible to easily determine it, as a product of factors, based on the status information of its individual components, taking into account that the weight of said information varies, depending on the type of aircraft, and its requirements.

== Related Community Discussions ==
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14021.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14090.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14098.html
* http://mail.flightgear.org/pipermail/flightgear-devel/2004-November/032295.html
* http://www.flightgear.org/forums/viewtopic.php?f=6&t=1531
* http://flightgear.org/forums/viewtopic.php?f=6&t=2214
* [http://www.flightgear.org/forums/viewtopic.php?f=17&t=7698 Aircraft frustration] (04/2010)
* [http://flightgear.org/forums/viewtopic.php?f=4&t=8441 Aircraft Metadata] (06/2010)
* [http://flightgear.org/forums/viewtopic.php?f=6&t=9034 fewer aircraft] (08/2010)
* [http://flightgear.org/forums/viewtopic.php?f=4&t=9057 Naming conventions] (08/2010)
* [http://flightgear.org/forums/viewtopic.php?f=4&t=9680 Discussing aircraft status] (10/2010)

[[Category:Base Package:Aircraft]]
[[Category:Aircraft TODO|*]]
[[Category: RFC]]

Aircraft rating system

2010-10-03T12:17:26Z

MILSTD: /* Related Community Discussions */ added recent forum discussion: Discussing aircraft status's ( http://flightgear.org/forums/viewtopic.php?f=4&t=9680 )

== Formalizing Aircraft Status ==

=== Intro ===
Based on various mailing list discussions since 11/2007, it is getting clear that the current method of classifying aircraft development status is not satisfactory to adequately and fully describe an aircraft's development progress. Which can be pretty frustrating for developers, contributors and users, because of different expectations about an aircraft's "status".

This can be even witnessed in more recent discussions (03/2009), where users explicitly inquire about recommendations for feature-complete aircraft [http://www.flightgear.org/forums/viewtopic.php?f=2&t=3171], or users pointing out weaknesses in FDM configurations [http://flightgear.org/forums/viewtopic.php?f=4&t=3281].

This is mainly because of the fact that different people may have different requirements when it comes to aircraft status and are thus viewing the status from different angles, possibly neglecting progress in other areas.

In addition, users are frequently facing issues when it comes to determining compatibility requirements between aircraft tarballs and fgfs binary releases (see for example [http://flightgear.org/forums/viewtopic.php?f=6&t=2814]). This very issue is further complicated by the fact, that FlightGear in general doesn't expose any detailed version information that could be queried by arbitrary FlightGear resources (such as aircraft). Furthermore, it is questionable whether simply starting to expose version information in the property tree would be sufficient, i.e. for scenarios where individual features may be removed/added or modified in CVS/HEAD, which however wouldn't necessarily result in a modified version number, so that such modifications wouldn't be easily communicated to FlightGear resources that depend on such features and information (for a more in depth discussion of this particular issue, please see [http://wiki.flightgear.org/index.php/Simplifying_Aircraft_Deployment#Version_tracking.2FCompatibility_checking]).

=== Scope ===
This page is dedicated to providing a place to start collecting suggestions about how to describe aircraft development status more formally and reliably, to point out the strengths and weaknesses of individual aircraft implementations more comprehensively.

Given that people seem to be expecting different things when they read about an aircraft's development status being "alpha", "beta" or "production", it should be possible to address this issue, by starting to classify each aircraft's individual components (i.e. fdm, cockpit panel, 3d model etc) directly, rather than the overall aircraft itself which would result in less-developed parts of an aircraft (which can usually be assumed to be most of it) affecting an aircraft's development status negatively, even if it should feature some very well-developed parts.

=== Suggestions ===
This classification process should preferably take place by following certain conventions, so that it is likely that the majority of aircraft types, as well as their various features, are covered thoroughly.

This could for example be achieved by starting to evaluate aircraft based on abstract factors such as the following:

* status/realism of FDM configs (performance characteristics)
* status/realism of exterior 3D models
* status/realism of cockpit panels (2D/3D)
* status/realism of autopilot implementation
* status/realism of aircraft-specific instruments
* status/realism of procedure modeling (i.e. startup)
* status/realism of systems modeling
* status/realism of failure modeling
* status/realism of integrated checklists/procedures
* status/realism of integrated help (i.e. in the form of help dialogs)
* status/realism of integrated scripted tutorials
* status/realism of available documentation
* status/realism of overall usability

Furthermore, it might also be worthwhile to consider evaluating aircraft based on additional criteria such as:

* available support for multiplayer
* available support for AI traffic (i.e. 3D models featuring LOD support may be reused by the AIT system)
* available support for runtime customization (i.e. liveries)
* available support for eye candy/effects
* available support for saving/loading and continuing flights
* available support for saving/loading aircraft configurations

In addition, it is important to keep in mind that there are different requirements for aircraft to appear "realistic" - depending on whether they are mainly used in VFR settings or IFR settings, where the former application scenario puts an increased demand on visual effects, the latter requires IFR-specific features to be in place, for example proper IFR instrumentation, as well as correct navigation lights.

Therefore, it might be a good idea to not only evaluate individual components of an aircraft, but also its readiness for certain usage scenarios, such as for example VFR/IFR flight.

=== Desired Results ===

It can be expected that following this or similarly factually objective approaches to classifying aircraft development status, should not only help people understand more easily and more completely an individual aircraft's development status, but also highlight the strengths and weaknesses of an aircraft, so that aircraft authors are motivated because of the work they have actually done, rather than being discouraged because of the work they could not (yet) do (or might possibly never be able to do because of it being outside their usual scope of contributions).

Additionally, this would also help aircraft becoming more self-documented, so that new contributors could more easily see where and how their help could be used.

== Implementation ==

Implementing support for more thorough status-tracking should be fairly straight forward, as the current approach of keeping aircraft status information by using a property tree node in an aircraft's *-set.xml file, could be easily extended to provide additional meta information, of the aforementioned nature - using the previously suggested type of information, this could end up looking like the following:

<PropertyList>
<aircraft-status>
<fdm>beta</fdm>
<exterior>early-production</exterior>
<cockpit>alpha</cockpit>
<instrumentation>alpha</instrumentation>
<procedures>alpha</procedures>
<system-modeling>beta</system-modeling>
<failure-modeling>alpha<failure-modeling>
<checklist-support>alpha</checklist-support>
<tutorial-support>alpha</tutorial-support>
<documentation>alpha</documentation>
<usability>beta</usability>
<eye-candy>alpha</eye-candy>
</aircraft-status>
</PropertyList>

On the other hand, some of this information should probably not directly go into the toplevel *-set.xml file, but rather into files of the various components (i.e. the cockpit/panel status would be a good candidate to have its status being tracked directly in the panel file).

=== Extending status information ===
Given that not all conceivable status for the above mentioned criteria can be properly represented using the existing notion of "status" information being restricted to "alpha, beta, early-production...", it should be considered to support additional states, such as for example "none/unavailable", "draft" or "design".

While it would of course be much easier to simply provide a full-length description space of the status information for each individual entry, where each contributor could leave some information, this would make it more complicated to later on provide web-based frontends to facilitate searching/picking aircraft based on certain attributes.

On the other hand, it is not unlikely that even this level of more finely-grained status information should turn out insufficient in some cases, to describe the status properly, thus combining the two previously mentioned approaches of 1) providing formal status information and 2) providing an optional textual description of the progress would probably be the most powerful long-term solution.

This could for example be accomplished by allowing contributors to optionally specify a corresponding attribute to point to a plaintext (or possibly even HTML) file (residing in the aircraft's folder) that may contain further details, such an XML attribute, named "info-file" is shown in the following example:

<PropertyList>
<aircraft-status>
<fdm '''info-file="fdm-status.txt"'''>beta</fdm>
<exterior '''info-file="ext-status.txt"'''>early-production</exterior>
<cockpit '''info-file="cockpit-status.txt"'''>alpha</cockpit>
[...]
<eye-candy '''info-file="effects-status.txt"'''>alpha</eye-candy>
</aircraft-status>
</PropertyList>

These attributes could not only be easily parsed by an XML parser to provide web-based search facilities, they could even be used within FlightGear at runtime, to provide enriched status information by reading in the corresponding files and showing their contents in a dialog.

In the long run, it might even be an interesting option to provide optional support for three different attributes specifying filenames for these status-tags:

* bugs-filename=""
* fixme-filename=""
* todo-filename=""

That way, it would be possible for contributors to easily provide very detailed information about the development status of individual components or features, simply by dropping a corresponding file into the aircraft tarball, possibly using a standard-location/folder such as "meta-info" within the aircraft's folder.

Likewise, users noticing new issues could easily augment said files and send them to the maintainer to have them committed to HEAD, so that future users can first check out this information before possibly reporting a duplicate issue/feature request.

While it may seem unnecessary to provide this sort of information-collecting infrastructure to aircraft authors and their contributors, it would probably help aircraft development status become more self-documenting and aircraft-development itself become more self-contained, given that key information would be collected in one central place (the repository) and aircraft-specific issues/ideas could be easily reported and checked for by new contributors.
In the long run

=== A Flexible Approach ===
It is obvious that regardless of how many sensible rating-categories are now identified and used in FlightGear, people will sooner or later want to use modified or even completey new categories to rate the strengths and weaknesses of their aircraft.

Because of this, but also because hardcoding such tag names (i.e. property paths) would be unnecessarily tedious, given that FlightGear itself does not yet actively use this sort of information at the moment to provide aircraft picker/sorting facilities, one could simply by convention have ALL tags below one specific node (i.e. PropertyList/sim/aircraft-status/) -regardless- of their name be honored by potential search frontends.

===Future Extendability ===

Because of the easy and flexibility of directly using XML/PropertyList files together with the FlightGear Property Tree, this approach to supporting more finely-grained status information tracking is extremely powerful and is promising enough to even support highly detailed status information for complex aircraft that may feature a number of distinct components, for example to appropriately describe various high performance aircraft or airliners, child nodes could be used:

<systems-modeling>
<electrical></electrical>
<hydraulic></hydraulic>
<pneumatic></pneumatic>
...
</systems-modeling>

===Fully searchable Aircraft - by Type ===

Furthermore, many users have frequently requested a possibility to search and pick aircraft based on certain aircraft-specific characteristics, such as for example the type of aircraft (i.e. single engine vs. multi engine, piston vs. jet etc.)

This could also be easily accomplished by having aircraft authors and contributors provide such meta information in the same way, for example:

<PropertyList>

<type-of-aircraft include ="aircraft-type.xml"/>
</PropertyList>

NOTE: for the sake of illustration purposes, false values have
also been specified, even though they would be obsolete if all
all values are by default assumed to be false, which would
significantly reduce unnecessary overhead.

aircraft-type.xml:
<PropertyList>

<is-fixed-wing type="bool">true</is-fixed-wing>
<is-helicopter type="bool">false</is-helicopter>
<is-sailplane type="bool">false</is-sailplane>
<is-amphibian type="bool">false</is-amphibian>

<is-military type="bool">false</is-military>
<is-civilian type="bool">true</is-civilian>

<is-airliner type="bool">true</is-airliner>
<is-multi-cew type="bool">true</is-multi-cew>

<is-single-engine type="bool">false<is-single-engine>
<is-multi-engine type="bool">true<is-multi-engine>

<has-piston-propulsion type="bool">false</has-piston-propulsion>
<has-jet-propulsion type="bool">true</has-jet-propulsion>
...
</PropertyList>

From a programming point of view, this doesn't require any work as it only requires contributors to provide said information-however from a usability point of view, it adds the possibility for GUI/WEB frontends to easily offer a way to search aircraft using this information. By restricting this information to be of Boolean type, it is very straightforward to either directly search the base package or to simply create a small database for very powerful queries-by just having users check/uncheck a corresponding checkbox, no matter whether this is on a webpage or directly in a FlightGear GUI launchr such as fgrun.

=== Challenges ===
For some components (like FDM configs, 2D panels, 3D cockpits, exterior models or liveries) it may be possible to specify multiple separately referenced files in one single *-set.xml file, in these cases it would seem more appropriate to also track their development status separately in these files, rather than in the top-level aircraft file, this would make sure that the development status is really tracked on a per-component basis. So, that sharing aircraft resources still works properly while retaining component status information.

== Ease of Deployment ==

In order to simplify the introduction of the aforementioned concept to store aircraft status information, it might make sense to consider requesting aircraft authors/maintainers by convention to specify said status information externally, in a separate PropertyList-encoded XML file, that is then only referenced in a corresponding include attribute (i.e. <aircraft-status include="ac-status.xml"/>.

While this doesn't make any conceptual difference, it helps to to keep this structured information in a separate place.

Enforcing this convention could simplify the required parsing process in certain situations and would thus not only help creating web-based search/sort frontends using such status information attributes, but would also enable the wealth of existing standalone FlightGear launchers (most of which do not link to SimGear, and may thus not easily process PropertyList-XML files) to be able to easily deal with this information without having to parse the whole *-set.xml file, rather it would become possible to just concentrate on parsing said "aircraft-status.xml" file for certain purposes.

== Overall Rating/Status ==

If an overall aircraft rating is desired, it should be possible to easily determine it, as a product of factors, based on the status information of its individual components, taking into account that the weight of said information varies, depending on the type of aircraft, and its requirements.

== Related Community Discussions ==
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14021.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14090.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14098.html
* http://mail.flightgear.org/pipermail/flightgear-devel/2004-November/032295.html
* http://www.flightgear.org/forums/viewtopic.php?f=6&t=1531
* [http://flightgear.org/forums/viewtopic.php?f=4&t=9680 Discussing aircraft status] (10/2010)

[[Category:Base Package:Aircraft]]
[[Category:Aircraft TODO|*]]
[[Category: RFC]]

FlightGear Headless

2010-07-02T12:35:21Z

MILSTD: /* Milestones */ --disable-sound is available for running FG without sound support

{{Stub}}

= FlightGear Headless =

== Regression Testing in FlightGear ==
While introducing unit tests and regression tests into the FlightGear project has been repeatedly brought up by several long-term contributors [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg12321.html] and core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11825.html], it isn't yet in wide or regular use in FlightGear, even though it is generally understood to be a worthwhile addition to FlightGear in order to do automated testing of individual features, for example when preparing releases [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11832.html].

And while there are indeed some minor build tests provided by both, the SimGear and FlightGear projects, such test cases aren't really commonly provided our updated by developers when introducing modified or new code.
Also, these are just low level tests for specific APIs - and do not lend themselves to be used for testing high level features.

Increasingly, FlightGear users are facing issues that are highly specific to their usage of FlightGear so that it isn't directly or easily possible to reproduce certain issues without exactly reproducing possibly an entire flight including identical startup and runtime settings, a fact that is also frequently acknowledged by FlightGear core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22171.html].

This is however not only a tedious and long-winded process, but also a process that may require certain usage patterns and background information or a specific set of skills (such as for example landing a specific aircraft on an aircraft carrier).

In fact, the corresponding bug reports are often fairly long winded and complicated in that they try to provide all information necessary in order to allow developers to redo a certain flight segment that resulted in an error (see for example [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19994.html] or [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html], [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html]).

These obstacles in debugging such highly specific issues are also highlighted by core developers to severely limit the troubleshooting process
[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21664.html].

== Background ==
FlightGear in its current form is an application that was primarily designed as an ''interactive'' graphical simulator, in other words, it is meant to be used by a user sitting in front of one or multiple screens, controlled by means such as a keyboard, mouse and other optional hardware such as joysticks/yokes and possibly also rudder/yaw pedals.

While confining FlightGear's design and use cases to this standard use scenario was of course very valid and feasible (as this is definitely the primary use) this restriction isn't necessarily ideal or even appropriate for the project to eventually be able to leverage itself for increasingly important purposes such as '''automated unit testing''' or '''automated benchmarking''' of individual FlightGear components in order to do '''regression testing'''.

This is an approach that is already used by the jsbsim project to some extent [http://sourceforge.net/mailarchive/forum.php?thread_name=003c01c9de85%2421a04ce0%2464e0e6a0%24%40net&forum_name=jsbsim-devel].

This RFC is meant to discuss the possible merits and approaches of allowing FlightGear to be used non-interactively, i.e. in an automated fashion such as for example by invoking it via shell scripts, so that FlightGear doesn't necessarily have to rely on user input or even a graphical output window in order to do a certain, ''well-defined and limited'' job, such as for example running certain subsystems for benchmarking purposes or by running scripted flights to fly standard patterns in order to generally help test aircraft that are considered for inclusion in upcoming FlightGear releases.

While there are certainly various thinkable scenarios for employing such facilities in other interesting contexts, this RFC will merely '''focus on the benefits for FlightGear itself'''.

== Introducing Regression Tests to FlightGear ==

The task of introducing regression tests isn't that easily achieved in FlightGear's case:

FlightGear has largely become an independent system and platform, so while it would be fairly straightforward (but still very tedious) to introduce individual unit tests in order to validate the correct behavior of low level C++ components, such as the SimGear APIs, it wouldn't really be that easy to properly test the various abstract, high level features that are provided by FlightGear as a functionality provider and simulation framework/platform with all its various subsystems providing support for abstract features.

In fact, conventional regression tests would inevitably fail when it comes to supporting base package resources, simply because FlightGear is the sole target platform for these resources.

While base package resources do generally make use of well-understood and established technologies or standards (i.e. textures, XML, scripts, 3D models, text files etc), it is only the specific combination of these resources inside FlightGear, that define a real purpose and use.

So, doing proper regression testing for such high level features would be very difficult without writing lots of redundant test code, which would probably end up being a maintenance burden in the long term - probably resulting in a situation similar to the current one, where tests simply end up being neglected and ignored at some point.

'''Thus, this discussion of bringing regression testing to FlightGear favors an approach where FlightGear itself is used as the regression testing framework.'''

So this isn't about doing low-level unit testing for individual FlightGear C++ code, but much more abstractly do regression testing by making use of the FlightGear platform to test abstract FlightGear features by making use of FlightGear's native support for technologies such as XML, scripting and networking.

== Goals ==

Leverage FlightGear as its own regression testing framework, for purposes such as for example:

* debugging (running FlightGear non-interactively, without requiring user input)
* unit tests (e.g. to facilitate refactoring efforts)
* automated release preparations (e.g. to test individual subsystems but also complete aircraft)
* benchmarking the whole system or individual subsystems

== Approach ==
Due to FlightGear's extensive support for flexible software interfaces (such as e.g. networking, scripting and XML), FlightGear can in many scenarios theoretically already be used for serving as its own test platform.

In fact, the major obstacle really limiting FlightGear to be used by automated/scripted tests is its reliance on having a graphical output window available and opened.

If FlightGear provided an option to be run in non-interactive/headless mode, so that it wouldn't necessarily create a visible output window but could just run silently in a shell environment, it could already be easily used by shell scripts to do simple things such as for example profiling the fgfs process while running a specific Nasal script non-interactively and automatically terminating afterwards.

It's worth pointing out that this is indeed already possible: Nasal scripts can terminate the simulator by invoking an fgcommand, so this really isn't that much off the table and would facilitate scenarios where Nasal scripts may run certain test suites and automatically report status back to the caller (shell script). So, this would be just one scenario for running fgfs non-interactively in order to profile the Nasal interpreter.
Another possible use might be scripted flights to have aircraft fly standard patterns or instrument approaches, while using a network interface such as the telnet facility to monitor the state of the flight during all phases of the flight.

Also, FlightGear's reliance on user input via means such as the mouse/keyboard and other hardware peripherals doesn't really pose a real problem, because all of these inputs are already internally handled by a combination of XML and scripting, so that emulating arbitrary user input by making use of scripts or by automatically writing to the property tree via network sockets is fairly straightforward and could also be accomplished by running shell scripts, that may for example invoke "netcat" specifically for this purpose.

The recent additions to the [[Autopilot]] and [[Route Manager]] systems in FlightGear also make it increasingly feasible to create completely scripted test flights for automatically doing certain portions of a flight without relying on user input.

== Milestones ==
* allow FlightGear to be run without creating a visible GUI window, i.e. in "headless" mode, using a --headless parameter
* allow FlightGear to be optionally compiled and run without any sound support/dependencies (OpenAL), as of 07/2010 there is a --disable-sound option available, which however still requires OpenAL for compilation.
* allow replay buffers to be saved to a file in order to be replayed for automated test/demo flights, so that users can share saved replay buffers when reporting a bug
* allow arbitrary user inputs to be simulated via property tree modifications (pretty much possible already)
* allow individual subsystems to be enabled/disabled dynamically (via properties), so that profiling and debugging can be restricted to specific usage scenarios and components
* [[Howto:Extending Nasal|extend the Nasal API]] in order to facilitate "remote controlling" the simulator largely using scripts

[[Category: RFC]]

Talk:FlightGear Sessions

2010-06-29T11:38:53Z

MILSTD: /* FG Initialization */

= Related discussions =
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20398.html The [Re-]Initialization Process in FlightGear: A Specification Proposal
* http://www.flightgear.org/forums/viewtopic.php?f=11&t=5322
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg37358.html
* http://www.opensubscriber.com/message/flightgear-users@lists.sourceforge.net/9589296.html

= Thinking in terms of FG startup modes =
"FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18446.html]

* without FDM
* without 2D/3D panel
* remove the implicit assumption that FG always simulates an aircraft (FDM + instrumentation + panel) (think non-aircraft or non-FDM modes, i.e. ATC)
* start up without aircraft
* reload vehicles, ATC
* remove assumption: always FDM running, always panel present (i.e. replay mode)
* generic protocol playback
* without scenery

= FG Initialization =
* should be decoupled from the entry loop, so that it can also be invoked by setting a listener (i.e. aircraft-name) - so that switching aircraft would boil down to setting a property to a valid filename, which in turn would invoke all the relevant init routines.
* just adding such a listener right away, would also make it much more straightforward to run everything in a debugger and see how things need to be changed to make it work
* all the explicit legacy init code would preferably be re-implemented by using listeners instead
* things would probably be simplified quite a bit by modifying FlightGear so that it can be started without specifying and running any aircraft at all, that in itself would remove the assumption that FlightGear is always simulating a particular aircraft, so that the init code could be properly modified to provide support for changing aircraft.
* to really tackle this, one will probably need to modify FG to support a "bare bones" mode, that does not yet use any of its optional subsystems - subsystems should be dynamically enabled/disabled, on to demand
* the "null FDM" is already an option, so it needs support for "null aircraft", "null panel", "null scenery"

= Global State Management =
In its current form, FlightGear fails badly whenever it has to deal with managing global state - that applies to many situations and components:
* simulator resets (partial) [http://sourceforge.net/tracker/index.php?func=detail&aid=1905728&group_id=583&atid=350583] [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18881.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg08035.html]
* saving/loading, resuming flights (partial) [http://www.flightgear.org/forums/viewtopic.php?f=6&t=1791] [http://flightgear.org/forums/viewtopic.php?f=2&t=6427]
* simulator replays (along with an option to continue flights)
* saving/loading startup "situations" (partial) - similar to loading saved flights
* internal subsystem state [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03373.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03418.html]
* property "classes" (velocities, orientation, position, cockpit animations, exterior animations, instrumentation) - select classes and reset/save/load accordingly
* provide corresponding signal handlers: reinit/reset, save-state, load-state etc
* have aircraft authors provide scripts to register listeners for the corresponding signals and implement corresponding aircraft specific handlers to handle cleanup/reinit work

Talk:FlightGear Sessions

2010-06-29T11:37:06Z

MILSTD: /* FG Initialization */

= Related discussions =
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20398.html The [Re-]Initialization Process in FlightGear: A Specification Proposal
* http://www.flightgear.org/forums/viewtopic.php?f=11&t=5322
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg37358.html
* http://www.opensubscriber.com/message/flightgear-users@lists.sourceforge.net/9589296.html

= Thinking in terms of FG startup modes =
"FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18446.html]

* without FDM
* without 2D/3D panel
* remove the implicit assumption that FG always simulates an aircraft (FDM + instrumentation + panel) (think non-aircraft or non-FDM modes, i.e. ATC)
* start up without aircraft
* reload vehicles, ATC
* remove assumption: always FDM running, always panel present (i.e. replay mode)
* generic protocol playback
* without scenery

= FG Initialization =
* should be decoupled from the entry loop, so that it can also be invoked by setting a listener (i.e. aircraft-name) - so that switching aircraft would boil down to setting a property to a valid filename, which in turn would invoke all the relevant init routines.
* just adding such a listener right away, would also make it much more straightforward to run everything in a debugger and see how things need to be changed to make it work
* things would probably be simplified quite a bit by modifying FlightGear so that it can be started without specifying and running any aircraft at all, that in itself would remove the assumption that FlightGear is always simulating a particular aircraft, so that the init code could be properly modified to provide support for changing aircraft.
* to really tackle this, one will probably need to modify FG to support a "bare bones" mode, that does not yet use any of its optional subsystems - subsystems should be dynamically enabled/disabled, on to demand
* the "null FDM" is already an option, so it needs support for "null aircraft", "null panel", "null scenery"

= Global State Management =
In its current form, FlightGear fails badly whenever it has to deal with managing global state - that applies to many situations and components:
* simulator resets (partial) [http://sourceforge.net/tracker/index.php?func=detail&aid=1905728&group_id=583&atid=350583] [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18881.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg08035.html]
* saving/loading, resuming flights (partial) [http://www.flightgear.org/forums/viewtopic.php?f=6&t=1791] [http://flightgear.org/forums/viewtopic.php?f=2&t=6427]
* simulator replays (along with an option to continue flights)
* saving/loading startup "situations" (partial) - similar to loading saved flights
* internal subsystem state [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03373.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03418.html]
* property "classes" (velocities, orientation, position, cockpit animations, exterior animations, instrumentation) - select classes and reset/save/load accordingly
* provide corresponding signal handlers: reinit/reset, save-state, load-state etc
* have aircraft authors provide scripts to register listeners for the corresponding signals and implement corresponding aircraft specific handlers to handle cleanup/reinit work

Talk:FlightGear Sessions

2010-06-29T11:33:22Z

MILSTD: /* Thinking in terms of FG startup modes */

= Related discussions =
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20398.html The [Re-]Initialization Process in FlightGear: A Specification Proposal
* http://www.flightgear.org/forums/viewtopic.php?f=11&t=5322
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg37358.html
* http://www.opensubscriber.com/message/flightgear-users@lists.sourceforge.net/9589296.html

= Thinking in terms of FG startup modes =
"FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18446.html]

* without FDM
* without 2D/3D panel
* remove the implicit assumption that FG always simulates an aircraft (FDM + instrumentation + panel) (think non-aircraft or non-FDM modes, i.e. ATC)
* start up without aircraft
* reload vehicles, ATC
* remove assumption: always FDM running, always panel present (i.e. replay mode)
* generic protocol playback
* without scenery

= FG Initialization =
* should be decoupled from the entry loop, so that it can also be invoked by setting a listener (i.e. aircraft-name) - so that switching aircraft would boil down to setting a property to a valid filename, which in turn would invoke all the relevant init routines.
* just adding such a listener right away, would also make it much more straightforward to run everything in a debugger and see how things need to be changed to make it work
* things would probably be simplified quite a bit by modifying FlightGear so that it can be started without specifying and running any aircraft at all, that in itself would remove the assumption that FlightGear is always simulating a particular aircraft, so that the init code could be properly modified to provide support for changing aircraft.

= Global State Management =
In its current form, FlightGear fails badly whenever it has to deal with managing global state - that applies to many situations and components:
* simulator resets (partial) [http://sourceforge.net/tracker/index.php?func=detail&aid=1905728&group_id=583&atid=350583] [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18881.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg08035.html]
* saving/loading, resuming flights (partial) [http://www.flightgear.org/forums/viewtopic.php?f=6&t=1791] [http://flightgear.org/forums/viewtopic.php?f=2&t=6427]
* simulator replays (along with an option to continue flights)
* saving/loading startup "situations" (partial) - similar to loading saved flights
* internal subsystem state [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03373.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg03418.html]
* property "classes" (velocities, orientation, position, cockpit animations, exterior animations, instrumentation) - select classes and reset/save/load accordingly
* provide corresponding signal handlers: reinit/reset, save-state, load-state etc
* have aircraft authors provide scripts to register listeners for the corresponding signals and implement corresponding aircraft specific handlers to handle cleanup/reinit work

FlightGear Headless

2010-06-29T11:29:45Z

MILSTD: /* Milestones */

{{Stub}}

= FlightGear Headless =

== Regression Testing in FlightGear ==
While introducing unit tests and regression tests into the FlightGear project has been repeatedly brought up by several long-term contributors [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg12321.html] and core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11825.html], it isn't yet in wide or regular use in FlightGear, even though it is generally understood to be a worthwhile addition to FlightGear in order to do automated testing of individual features, for example when preparing releases [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11832.html].

And while there are indeed some minor build tests provided by both, the SimGear and FlightGear projects, such test cases aren't really commonly provided our updated by developers when introducing modified or new code.
Also, these are just low level tests for specific APIs - and do not lend themselves to be used for testing high level features.

Increasingly, FlightGear users are facing issues that are highly specific to their usage of FlightGear so that it isn't directly or easily possible to reproduce certain issues without exactly reproducing possibly an entire flight including identical startup and runtime settings, a fact that is also frequently acknowledged by FlightGear core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22171.html].

This is however not only a tedious and long-winded process, but also a process that may require certain usage patterns and background information or a specific set of skills (such as for example landing a specific aircraft on an aircraft carrier).

In fact, the corresponding bug reports are often fairly long winded and complicated in that they try to provide all information necessary in order to allow developers to redo a certain flight segment that resulted in an error (see for example [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19994.html] or [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html], [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html]).

These obstacles in debugging such highly specific issues are also highlighted by core developers to severely limit the troubleshooting process
[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21664.html].

== Background ==
FlightGear in its current form is an application that was primarily designed as an ''interactive'' graphical simulator, in other words, it is meant to be used by a user sitting in front of one or multiple screens, controlled by means such as a keyboard, mouse and other optional hardware such as joysticks/yokes and possibly also rudder/yaw pedals.

While confining FlightGear's design and use cases to this standard use scenario was of course very valid and feasible (as this is definitely the primary use) this restriction isn't necessarily ideal or even appropriate for the project to eventually be able to leverage itself for increasingly important purposes such as '''automated unit testing''' or '''automated benchmarking''' of individual FlightGear components in order to do '''regression testing'''.

This is an approach that is already used by the jsbsim project to some extent [http://sourceforge.net/mailarchive/forum.php?thread_name=003c01c9de85%2421a04ce0%2464e0e6a0%24%40net&forum_name=jsbsim-devel].

This RFC is meant to discuss the possible merits and approaches of allowing FlightGear to be used non-interactively, i.e. in an automated fashion such as for example by invoking it via shell scripts, so that FlightGear doesn't necessarily have to rely on user input or even a graphical output window in order to do a certain, ''well-defined and limited'' job, such as for example running certain subsystems for benchmarking purposes or by running scripted flights to fly standard patterns in order to generally help test aircraft that are considered for inclusion in upcoming FlightGear releases.

While there are certainly various thinkable scenarios for employing such facilities in other interesting contexts, this RFC will merely '''focus on the benefits for FlightGear itself'''.

== Introducing Regression Tests to FlightGear ==

The task of introducing regression tests isn't that easily achieved in FlightGear's case:

FlightGear has largely become an independent system and platform, so while it would be fairly straightforward (but still very tedious) to introduce individual unit tests in order to validate the correct behavior of low level C++ components, such as the SimGear APIs, it wouldn't really be that easy to properly test the various abstract, high level features that are provided by FlightGear as a functionality provider and simulation framework/platform with all its various subsystems providing support for abstract features.

In fact, conventional regression tests would inevitably fail when it comes to supporting base package resources, simply because FlightGear is the sole target platform for these resources.

While base package resources do generally make use of well-understood and established technologies or standards (i.e. textures, XML, scripts, 3D models, text files etc), it is only the specific combination of these resources inside FlightGear, that define a real purpose and use.

So, doing proper regression testing for such high level features would be very difficult without writing lots of redundant test code, which would probably end up being a maintenance burden in the long term - probably resulting in a situation similar to the current one, where tests simply end up being neglected and ignored at some point.

'''Thus, this discussion of bringing regression testing to FlightGear favors an approach where FlightGear itself is used as the regression testing framework.'''

So this isn't about doing low-level unit testing for individual FlightGear C++ code, but much more abstractly do regression testing by making use of the FlightGear platform to test abstract FlightGear features by making use of FlightGear's native support for technologies such as XML, scripting and networking.

== Goals ==

Leverage FlightGear as its own regression testing framework, for purposes such as for example:

* debugging (running FlightGear non-interactively, without requiring user input)
* unit tests (e.g. to facilitate refactoring efforts)
* automated release preparations (e.g. to test individual subsystems but also complete aircraft)
* benchmarking the whole system or individual subsystems

== Approach ==
Due to FlightGear's extensive support for flexible software interfaces (such as e.g. networking, scripting and XML), FlightGear can in many scenarios theoretically already be used for serving as its own test platform.

In fact, the major obstacle really limiting FlightGear to be used by automated/scripted tests is its reliance on having a graphical output window available and opened.

If FlightGear provided an option to be run in non-interactive/headless mode, so that it wouldn't necessarily create a visible output window but could just run silently in a shell environment, it could already be easily used by shell scripts to do simple things such as for example profiling the fgfs process while running a specific Nasal script non-interactively and automatically terminating afterwards.

It's worth pointing out that this is indeed already possible: Nasal scripts can terminate the simulator by invoking an fgcommand, so this really isn't that much off the table and would facilitate scenarios where Nasal scripts may run certain test suites and automatically report status back to the caller (shell script). So, this would be just one scenario for running fgfs non-interactively in order to profile the Nasal interpreter.
Another possible use might be scripted flights to have aircraft fly standard patterns or instrument approaches, while using a network interface such as the telnet facility to monitor the state of the flight during all phases of the flight.

Also, FlightGear's reliance on user input via means such as the mouse/keyboard and other hardware peripherals doesn't really pose a real problem, because all of these inputs are already internally handled by a combination of XML and scripting, so that emulating arbitrary user input by making use of scripts or by automatically writing to the property tree via network sockets is fairly straightforward and could also be accomplished by running shell scripts, that may for example invoke "netcat" specifically for this purpose.

The recent additions to the [[Autopilot]] and [[Route Manager]] systems in FlightGear also make it increasingly feasible to create completely scripted test flights for automatically doing certain portions of a flight without relying on user input.

== Milestones ==
* allow FlightGear to be run without creating a visible GUI window, i.e. in "headless" mode, using a --headless parameter
* allow FlightGear to be optionally compiled and run without any sound support/dependencies (OpenAL)
* allow replay buffers to be saved to a file in order to be replayed for automated test/demo flights, so that users can share saved replay buffers when reporting a bug
* allow arbitrary user inputs to be simulated via property tree modifications (pretty much possible already)
* allow individual subsystems to be enabled/disabled dynamically (via properties), so that profiling and debugging can be restricted to specific usage scenarios and components
* [[Howto:Extending Nasal|extend the Nasal API]] in order to facilitate "remote controlling" the simulator largely using scripts

[[Category: RFC]]

Talk:FlightGear Headless

2010-06-29T11:28:49Z

MILSTD: /* Related Discussions */

= Hudson based CI for FG =
* http://wiki.flightgear.org/index.php/FlightGear_Newsletter_June_2010#Server_wanted:_Continuous_Integration_for_FlightGear
* pursuing this, would allow for a number of regression tests and standard Linux tools to be similarly automated:
** gprof
** valgrind
* Doing this would mostly require standard situations or scenarios to have a repeatable runtime scenario for benchmarking/profiling, instrument and debugging FG
= Related Discussions =
* 06/2010: there are now a number of projects related to scripting AI objects - see FG forums
* "although right now our test suite is pretty much zero - I did some work on that once, but it got lost in disk shuffles last year " [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27924.html]
* http://sourceforge.net/forum/forum.php?thread_id=1647216&forum_id=128876
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21928.html
* http://sourceforge.net/mailarchive/forum.php?thread_name=003c01c9de85%2421a04ce0%2464e0e6a0%24%40net&forum_name=jsbsim-devel
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18434.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10274.html
* http://flightgear.org/forums/viewtopic.php?f=6&t=7806
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18295.html headless traffic injector]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27033.html

= Possible infrastructure =

Have a look at Phoronix Test Suite (www.phoronix-test-suite.com) for a possible infrastructure when paired with phoromatic. (www.phoromatic.com).

FlightGear Headless

2010-06-29T11:27:52Z

MILSTD: /* Approach */

{{Stub}}

= FlightGear Headless =

== Regression Testing in FlightGear ==
While introducing unit tests and regression tests into the FlightGear project has been repeatedly brought up by several long-term contributors [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg12321.html] and core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11825.html], it isn't yet in wide or regular use in FlightGear, even though it is generally understood to be a worthwhile addition to FlightGear in order to do automated testing of individual features, for example when preparing releases [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11832.html].

And while there are indeed some minor build tests provided by both, the SimGear and FlightGear projects, such test cases aren't really commonly provided our updated by developers when introducing modified or new code.
Also, these are just low level tests for specific APIs - and do not lend themselves to be used for testing high level features.

Increasingly, FlightGear users are facing issues that are highly specific to their usage of FlightGear so that it isn't directly or easily possible to reproduce certain issues without exactly reproducing possibly an entire flight including identical startup and runtime settings, a fact that is also frequently acknowledged by FlightGear core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22171.html].

This is however not only a tedious and long-winded process, but also a process that may require certain usage patterns and background information or a specific set of skills (such as for example landing a specific aircraft on an aircraft carrier).

In fact, the corresponding bug reports are often fairly long winded and complicated in that they try to provide all information necessary in order to allow developers to redo a certain flight segment that resulted in an error (see for example [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19994.html] or [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html], [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html]).

These obstacles in debugging such highly specific issues are also highlighted by core developers to severely limit the troubleshooting process
[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21664.html].

== Background ==
FlightGear in its current form is an application that was primarily designed as an ''interactive'' graphical simulator, in other words, it is meant to be used by a user sitting in front of one or multiple screens, controlled by means such as a keyboard, mouse and other optional hardware such as joysticks/yokes and possibly also rudder/yaw pedals.

While confining FlightGear's design and use cases to this standard use scenario was of course very valid and feasible (as this is definitely the primary use) this restriction isn't necessarily ideal or even appropriate for the project to eventually be able to leverage itself for increasingly important purposes such as '''automated unit testing''' or '''automated benchmarking''' of individual FlightGear components in order to do '''regression testing'''.

This is an approach that is already used by the jsbsim project to some extent [http://sourceforge.net/mailarchive/forum.php?thread_name=003c01c9de85%2421a04ce0%2464e0e6a0%24%40net&forum_name=jsbsim-devel].

This RFC is meant to discuss the possible merits and approaches of allowing FlightGear to be used non-interactively, i.e. in an automated fashion such as for example by invoking it via shell scripts, so that FlightGear doesn't necessarily have to rely on user input or even a graphical output window in order to do a certain, ''well-defined and limited'' job, such as for example running certain subsystems for benchmarking purposes or by running scripted flights to fly standard patterns in order to generally help test aircraft that are considered for inclusion in upcoming FlightGear releases.

While there are certainly various thinkable scenarios for employing such facilities in other interesting contexts, this RFC will merely '''focus on the benefits for FlightGear itself'''.

== Introducing Regression Tests to FlightGear ==

The task of introducing regression tests isn't that easily achieved in FlightGear's case:

FlightGear has largely become an independent system and platform, so while it would be fairly straightforward (but still very tedious) to introduce individual unit tests in order to validate the correct behavior of low level C++ components, such as the SimGear APIs, it wouldn't really be that easy to properly test the various abstract, high level features that are provided by FlightGear as a functionality provider and simulation framework/platform with all its various subsystems providing support for abstract features.

In fact, conventional regression tests would inevitably fail when it comes to supporting base package resources, simply because FlightGear is the sole target platform for these resources.

While base package resources do generally make use of well-understood and established technologies or standards (i.e. textures, XML, scripts, 3D models, text files etc), it is only the specific combination of these resources inside FlightGear, that define a real purpose and use.

So, doing proper regression testing for such high level features would be very difficult without writing lots of redundant test code, which would probably end up being a maintenance burden in the long term - probably resulting in a situation similar to the current one, where tests simply end up being neglected and ignored at some point.

'''Thus, this discussion of bringing regression testing to FlightGear favors an approach where FlightGear itself is used as the regression testing framework.'''

So this isn't about doing low-level unit testing for individual FlightGear C++ code, but much more abstractly do regression testing by making use of the FlightGear platform to test abstract FlightGear features by making use of FlightGear's native support for technologies such as XML, scripting and networking.

== Goals ==

Leverage FlightGear as its own regression testing framework, for purposes such as for example:

* debugging (running FlightGear non-interactively, without requiring user input)
* unit tests (e.g. to facilitate refactoring efforts)
* automated release preparations (e.g. to test individual subsystems but also complete aircraft)
* benchmarking the whole system or individual subsystems

== Approach ==
Due to FlightGear's extensive support for flexible software interfaces (such as e.g. networking, scripting and XML), FlightGear can in many scenarios theoretically already be used for serving as its own test platform.

In fact, the major obstacle really limiting FlightGear to be used by automated/scripted tests is its reliance on having a graphical output window available and opened.

If FlightGear provided an option to be run in non-interactive/headless mode, so that it wouldn't necessarily create a visible output window but could just run silently in a shell environment, it could already be easily used by shell scripts to do simple things such as for example profiling the fgfs process while running a specific Nasal script non-interactively and automatically terminating afterwards.

It's worth pointing out that this is indeed already possible: Nasal scripts can terminate the simulator by invoking an fgcommand, so this really isn't that much off the table and would facilitate scenarios where Nasal scripts may run certain test suites and automatically report status back to the caller (shell script). So, this would be just one scenario for running fgfs non-interactively in order to profile the Nasal interpreter.
Another possible use might be scripted flights to have aircraft fly standard patterns or instrument approaches, while using a network interface such as the telnet facility to monitor the state of the flight during all phases of the flight.

Also, FlightGear's reliance on user input via means such as the mouse/keyboard and other hardware peripherals doesn't really pose a real problem, because all of these inputs are already internally handled by a combination of XML and scripting, so that emulating arbitrary user input by making use of scripts or by automatically writing to the property tree via network sockets is fairly straightforward and could also be accomplished by running shell scripts, that may for example invoke "netcat" specifically for this purpose.

The recent additions to the [[Autopilot]] and [[Route Manager]] systems in FlightGear also make it increasingly feasible to create completely scripted test flights for automatically doing certain portions of a flight without relying on user input.

== Milestones ==
* allow FlightGear to be run without creating a GUI window, i.e. in "headless" mode, using a --headless parameter
* allow FlightGear to be optionally compiled and run without any sound support/dependencies (OpenAL)
* allow replay buffers to be saved to a file in order to be replayed for automated test/demo flights, so that users can share saved replay buffers when reporting a bug
* allow arbitrary user inputs to be simulated via property tree modifications (pretty much possible already)
* allow individual subsystems to be enabled/disabled dynamically (via properties), so that profiling and debugging can be restricted to specific usage scenarios and components
* [[Howto:Extending Nasal|extend the Nasal API]] in order to facilitate "remote controlling" the simulator largely using scripts

[[Category: RFC]]

FlightGear Headless

2010-06-29T11:27:13Z

MILSTD: /* Approach */

{{Stub}}

= FlightGear Headless =

== Regression Testing in FlightGear ==
While introducing unit tests and regression tests into the FlightGear project has been repeatedly brought up by several long-term contributors [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg12321.html] and core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11825.html], it isn't yet in wide or regular use in FlightGear, even though it is generally understood to be a worthwhile addition to FlightGear in order to do automated testing of individual features, for example when preparing releases [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11832.html].

And while there are indeed some minor build tests provided by both, the SimGear and FlightGear projects, such test cases aren't really commonly provided our updated by developers when introducing modified or new code.
Also, these are just low level tests for specific APIs - and do not lend themselves to be used for testing high level features.

Increasingly, FlightGear users are facing issues that are highly specific to their usage of FlightGear so that it isn't directly or easily possible to reproduce certain issues without exactly reproducing possibly an entire flight including identical startup and runtime settings, a fact that is also frequently acknowledged by FlightGear core developers [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22171.html].

This is however not only a tedious and long-winded process, but also a process that may require certain usage patterns and background information or a specific set of skills (such as for example landing a specific aircraft on an aircraft carrier).

In fact, the corresponding bug reports are often fairly long winded and complicated in that they try to provide all information necessary in order to allow developers to redo a certain flight segment that resulted in an error (see for example [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19994.html] or [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html], [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23521.html]).

These obstacles in debugging such highly specific issues are also highlighted by core developers to severely limit the troubleshooting process
[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21664.html].

== Background ==
FlightGear in its current form is an application that was primarily designed as an ''interactive'' graphical simulator, in other words, it is meant to be used by a user sitting in front of one or multiple screens, controlled by means such as a keyboard, mouse and other optional hardware such as joysticks/yokes and possibly also rudder/yaw pedals.

While confining FlightGear's design and use cases to this standard use scenario was of course very valid and feasible (as this is definitely the primary use) this restriction isn't necessarily ideal or even appropriate for the project to eventually be able to leverage itself for increasingly important purposes such as '''automated unit testing''' or '''automated benchmarking''' of individual FlightGear components in order to do '''regression testing'''.

This is an approach that is already used by the jsbsim project to some extent [http://sourceforge.net/mailarchive/forum.php?thread_name=003c01c9de85%2421a04ce0%2464e0e6a0%24%40net&forum_name=jsbsim-devel].

This RFC is meant to discuss the possible merits and approaches of allowing FlightGear to be used non-interactively, i.e. in an automated fashion such as for example by invoking it via shell scripts, so that FlightGear doesn't necessarily have to rely on user input or even a graphical output window in order to do a certain, ''well-defined and limited'' job, such as for example running certain subsystems for benchmarking purposes or by running scripted flights to fly standard patterns in order to generally help test aircraft that are considered for inclusion in upcoming FlightGear releases.

While there are certainly various thinkable scenarios for employing such facilities in other interesting contexts, this RFC will merely '''focus on the benefits for FlightGear itself'''.

== Introducing Regression Tests to FlightGear ==

The task of introducing regression tests isn't that easily achieved in FlightGear's case:

FlightGear has largely become an independent system and platform, so while it would be fairly straightforward (but still very tedious) to introduce individual unit tests in order to validate the correct behavior of low level C++ components, such as the SimGear APIs, it wouldn't really be that easy to properly test the various abstract, high level features that are provided by FlightGear as a functionality provider and simulation framework/platform with all its various subsystems providing support for abstract features.

In fact, conventional regression tests would inevitably fail when it comes to supporting base package resources, simply because FlightGear is the sole target platform for these resources.

While base package resources do generally make use of well-understood and established technologies or standards (i.e. textures, XML, scripts, 3D models, text files etc), it is only the specific combination of these resources inside FlightGear, that define a real purpose and use.

So, doing proper regression testing for such high level features would be very difficult without writing lots of redundant test code, which would probably end up being a maintenance burden in the long term - probably resulting in a situation similar to the current one, where tests simply end up being neglected and ignored at some point.

'''Thus, this discussion of bringing regression testing to FlightGear favors an approach where FlightGear itself is used as the regression testing framework.'''

So this isn't about doing low-level unit testing for individual FlightGear C++ code, but much more abstractly do regression testing by making use of the FlightGear platform to test abstract FlightGear features by making use of FlightGear's native support for technologies such as XML, scripting and networking.

== Goals ==

Leverage FlightGear as its own regression testing framework, for purposes such as for example:

* debugging (running FlightGear non-interactively, without requiring user input)
* unit tests (e.g. to facilitate refactoring efforts)
* automated release preparations (e.g. to test individual subsystems but also complete aircraft)
* benchmarking the whole system or individual subsystems

== Approach ==
Due to FlightGear's extensive support for flexible software interfaces (such as e.g. networking, scripting and XML), FlightGear can in many scenarios theoretically already be used for serving as its own test platform.

In fact, the major obstacle really limiting FlightGear to be used by automated/scripted tests is its reliance on having a graphical output window available and opened.

If FlightGear provided an option to be run in non-interactive/headless mode, so that it wouldn't necessarily create a visible output window but could just run silently in a shell environment, it could already be easily used by shell scripts to do simple things such as for example profiling the fgfs process while running a specific Nasal script non-interactively and automatically terminating afterwards.

It's worth pointing out that this is indeed already possible: Nasal scripts can terminate the simulator by invoking an fgcommand, so this really isn't that much off the table and would facilitate scenarios where Nasal scripts may run certain test suites and automatically report status back to the caller (shell script). So, this would be just one scenario for running fgfs non-interactively in order to profile the Nasal interpreter.
Another possible use might be scripted flights to have aircraft fly standard patterns or instrument approaches, while using a network interface such as the telnet facility to monitor the state of the flight during all phases of the flight.

Also, FlightGear's reliance on user input via means such as the mouse/keyboard and other hardware peripherals doesn't really pose a real problem, because all of these inputs are already internally handled by a combination of XML and scripting, so that emulating arbitrary user input by making use of scripts or by automatically writing to the property tree via network sockets is fairly straightforward and could also be accomplished by running shell scripts, that may for example invoke "netcat" specifically for this purpose.

The recent additions to the [[Autopilot]] and [[Route Manager]] systems in FlightGear also make it increasingly feasible to created completely scripted test flights for automatically doing certain portions of a flight without relying on user input.

== Milestones ==
* allow FlightGear to be run without creating a GUI window, i.e. in "headless" mode, using a --headless parameter
* allow FlightGear to be optionally compiled and run without any sound support/dependencies (OpenAL)
* allow replay buffers to be saved to a file in order to be replayed for automated test/demo flights, so that users can share saved replay buffers when reporting a bug
* allow arbitrary user inputs to be simulated via property tree modifications (pretty much possible already)
* allow individual subsystems to be enabled/disabled dynamically (via properties), so that profiling and debugging can be restricted to specific usage scenarios and components
* [[Howto:Extending Nasal|extend the Nasal API]] in order to facilitate "remote controlling" the simulator largely using scripts

[[Category: RFC]]

Talk:FlightGear Headless

2010-06-29T11:21:32Z

MILSTD: /* Related Discussions */

= Hudson based CI for FG =
* http://wiki.flightgear.org/index.php/FlightGear_Newsletter_June_2010#Server_wanted:_Continuous_Integration_for_FlightGear
* pursuing this, would allow for a number of regression tests and standard Linux tools to be similarly automated:
** gprof
** valgrind
* Doing this would mostly require standard situations or scenarios to have a repeatable runtime scenario for benchmarking/profiling, instrument and debugging FG
= Related Discussions =
* "although right now our test suite is pretty much zero - I did some work on that once, but it got lost in disk shuffles last year " [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27924.html]
* http://sourceforge.net/forum/forum.php?thread_id=1647216&forum_id=128876
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21928.html
* http://sourceforge.net/mailarchive/forum.php?thread_name=003c01c9de85%2421a04ce0%2464e0e6a0%24%40net&forum_name=jsbsim-devel
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18434.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10274.html
* http://flightgear.org/forums/viewtopic.php?f=6&t=7806
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18295.html headless traffic injector]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27033.html

= Possible infrastructure =

Have a look at Phoronix Test Suite (www.phoronix-test-suite.com) for a possible infrastructure when paired with phoromatic. (www.phoromatic.com).

Talk:FlightGear Headless

2010-06-29T11:18:55Z

MILSTD: Hudson based CI server is now available, which would directly benefit from a HEADLESS mode for regression testing purposes

= Hudson based CI for FG =
* http://wiki.flightgear.org/index.php/FlightGear_Newsletter_June_2010#Server_wanted:_Continuous_Integration_for_FlightGear
* pursuing this, would allow for a number of regression tests and standard Linux tools to be similarly automated:
** gprof
** valgrind
* Doing this would mostly require standard situations or scenarios to have a repeatable runtime scenario for benchmarking/profiling, instrument and debugging FG
= Related Discussions =
* http://sourceforge.net/forum/forum.php?thread_id=1647216&forum_id=128876
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21928.html
* http://sourceforge.net/mailarchive/forum.php?thread_name=003c01c9de85%2421a04ce0%2464e0e6a0%24%40net&forum_name=jsbsim-devel
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18434.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10274.html
* http://flightgear.org/forums/viewtopic.php?f=6&t=7806
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18295.html headless traffic injector]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27033.html

= Possible infrastructure =

Have a look at Phoronix Test Suite (www.phoronix-test-suite.com) for a possible infrastructure when paired with phoromatic. (www.phoromatic.com).

FlightGear Newsletter June 2010

2010-06-29T11:12:39Z

MILSTD: /* Server wanted: Continuous Integration for FlightGear */

{{newsletter}}
{{TOC_right}}

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

==Development news==
===Server wanted: Continuous Integration for FlightGear ===
The FlightGear project has started using a build server for [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] purposes and [http://en.wikipedia.org/wiki/Build_automation automating software builds], the [http://hudson-ci.org/ Hudson] based build server is currently running on a home box as a prototype: http://zakalawe.ath.cx:8080/

A build server like Hudson makes it very easy to automatically build FlightGear from source code, e.g. to check the integrity of the source tree or to help prepare prebuilt binaries, pre-releases or even releases.
The server will need a proper home if it moves beyond the prototype stage. If anyone wishes to volunteer or help sponsor a proper server (with a reasonably symmetric connection) to run Hudson, please get in touch using the [http://flightgear.org/mail.html mailing list] or the [http://flightgear.org/forums/ forums] - any Unix will do, for Ubuntu/Debian there's an easy apt.get source available.
All the setup can be done remotely, given SSH access. The disk, memory, CPU and bandwidth requirements are pretty moderate, due to our low commit rate. For additional details, please see [[FlightGear Build Server]].

===SquawkGear: Bringing VATSIM to FlightGear!===
{{Main article|SquawkGear}}
SquawkGear is the much-awaited client that allows FlightGear users to connect to the largest and most realistic sim server in the world: [http://vatsim.net/ VATSIM]. VATSIM is simply a network that can, in theory, take any sim, although the current ones are X-Plane and Microsoft Flight Simulator. Using addons like SquawkBox for MSFS, pilots must adhere to strict rules about realism. A valid [[flight plan]] must always be submitted before takeoff, for instance. And pilots must contact [[Air Traffic Control]] before any actions.

SquawkGear brings this wonderful server to FlightGear. While installation is not as simple as that of VATSIM clients for MSFS, pilots are now able to connect to the VATSIM network and use chat and voice to communicate with other players and ATC. Since [[scenery]] is very different between sims, aircraft do not always appear where they are supposed to be; a MSFS user might see you hovering a few feet above the ground, for instance.

With its first release, SquawkGear is an excellent addon for pilots wishing to get on VATSIM without having to buy the payware sims. It is strongly recommended that you '''read all manuals''' before connecting to VATSIM; not only because installation is tricky, but also because there are certain rules to be followed on VATSIM. You will find that your [[KSFO]] on VATSIM is a thousand times more under control than your KSFO on one of the [[Howto: Multiplayer|mpservers]]!

''Special thanks to Ivan (Reed) for all of his work!''

===Bombable air combat add-on updated===
The [http://www.flightgear.org/forums/viewtopic.php?f=2&t=5742 Bombable air combat add-on to FlightGear] received a major update in June. Bombable now has these features:

* Dogfight against other FlightGear pilots over multiplayer with [[Sopwith Camel]], SPAC VII, [[Fokker Dr.I|Fokker DR 1 Triplane]], or [[A6M2 Zero]]
* Explode/burn when you crash
* Exceeding [[Howto:Define limits|aircraft limitations]] (excess g-forces, overspeed) adds damage to your aircraft and finally leads to shutdown/crash
* Shootable/bombable moving AI tanks, jeeps, ships, and aircraft that [[Wildfire|catch fire]], burn, explode, sink, crash, etc.
* [[AI|AI scenarios]] that allow you to use FlightGear aircraft for air-to-ground, air-to-sea, and air-to-air combat missions against these targets

==In the hangar==
===Boeing 787===
''nickyivyca'' is currently working on the [[Boeing 787]]. He corrected the [[FDM]] and changed some details in the model. More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8203 the forum].

===C-130 Hercules===
The [[C-130]] Hercules [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8629 is receiving some updates] from ''glazmax'' and ''helijah''. These updates include FDM and instruments fixes and improvements.

===Cessna T-37===
''richter'' and ''snipey'' are working together in improving the [[Cessna T-37]]. Here is a list of items that have been improved/created:

'''Model:'''
* Completely remodeled canopy;
* Main gear wheel wells and covers.
'''Sound:'''
* Interior-exterior sound level difference.
'''Instruments:'''
* Basic flight instruments.

More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8354 the forum].

===CH-47 Chinook===
''MOJO'' is tuning the [[CH-47 Chinook Helicopter|CH-47 ''Chinook'']]. He spent some time adding external cosmetics which main purpose is to add more detail to the Chinook. He added antenna and aerials, domed windows, pitot tubes, winch, engine hub details and started with the internal cargo bay. He intends to be adding an animated refuel probe and will be including several liveries. His ultimate aim for the CH-47 Chinook is to attempt to get the model more defined and realistic.

===Cirrus Vision SF50===
''Zexe'' created a SF50 model. It is still at a very early stage. More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8352 the forum].

===CRJ-200===
''nickyivyca'' has also been working in the [[CRJ-200]]:

''"The CRJ-200 and 787 were made with very similar systems and such. Neither had a 2.0 compatible [[autopilot]]. So, I found out what was wrong with the one for the 787 first, and made those changes to the CRJ here. Both worked. I also did some FDM improvements, like moving the engines to where they really are and adding gear smoke and contrails."'' - says he in [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8329 the forum thread].

===Curtiss P-40 Warhawk===
''jackmermod'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8621 is developing a P-40 model]. It is already complete, and to be done are the animations and textures. Development of the P-40 Warhawk is coming along very quick, although a full release date is unknown.

===Il-96-400/T===
The Il-96-400/T [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 has been updated] to version 3, with more accurate model and a better panel, among other little fixes.

===MiG-15bis===
''vitos'' improved the [[MiG-15|MiG-15bis]] model, and released it. More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7486 the forum].

===MB-339 PAN===
The MB-339 PAN aircraft [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8604 was updated by ''Albert''] to work with [[FlightGear]] version 2.0.0.

===X-29A===
''Intel-Qube'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8485 is currently revamping] the experimental X-29A aircraft. Here is a list of items that have been improved/created:

* A new, more realistic [[FDM]] is on the way;
* Landing gear has been redone and is now much more aesthetically pleasing;
* New exhaust will now dilate based on throttle as it should;
* The cockpit panel has been entirely rebuilt, is far more detailed, and will likely have interactive switches in the final release;
* The model is more ''"anatomically correct"''.

===San Antonio LPD17 and Hermann Marwede SAR-ship===
Browsing through the files, ''HHS'' [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8351 found a rotorcraft carrier model] and made a scenario to run it, which will be available in July on [[Git]] together with the [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8482#p83700 "Hermann Marwede"], another scenario especially for helipilots.

==Scenery corner==
===Nighttime London Gatwick===
London Gatwick (EGKK) is being further improved and is in the second phase of development - night textures. All the buildings and features are currently being modified by ''karla'' to give suitable lighting and make London Gatwick even more attractive to FlightGear commercial fliers. Landing or taking off from Gatwick at night should add much to your enjoyment of the game - and most likely extend the hours you enter in your pilot's log.
Further improvements and many minor changes are also being made to the existing models and daytime textures.
The link shows an image of the part completed airport at night http://www.donlavelle.net/flightgear/flightgear19.html.

The new scenery is available through [[TerraSync]] and/or the [[Objects Database]].

===Dubai airport gets busy===
With the terrain updates that were discussed in the [[FlightGear Newsletter March 2010#Dubai is coming up|March edition]] still in our minds, we now have another feature for the area; taking it yet another step closer to a bussy and realistic representation of the real emirate!

After looking jealously at the greatly enhanced airport [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) and the latest highlight Gatwick (EGKK) Mike ([[User:D-SKY1|D-SKY1]]) decided to create [[interactive traffic]] for [[Dubai International Airport]] (OMDB). Based on the existing airport layout in FlightGear the traffic pattern for taxiing between gates and runways has been created in [[TaxiDraw]] next to a timetable for runway usage.

Although no model work is done (yet) a big bunch of scheduled flights is now added to this important hub in the middle east. As Dubai is home port for Emirates Airlines (UAE) only Emirates flights are included. Within the next weeks more scheduled flights for AI traffic at Dubai will be added. During the process of creating AI traffic he tried to stay as close as possible to the real life timetable for Dubai International Airport querying several sources for double checking.

As Emirates Airlines (UAE) is one of the most important customers for the [[Airbus A380]] (UAE just ordered another 30 units of A380) the Emirates Airlines livery has been added to AI aircraft A380. Additionally some minor errors in several traffic files concerning changed [[ICAO]] codes for some airports have been removed.

All changes are available via [[Git]]. Enjoy the enhancements; and always follow [[SID]]s and [[STAR]]s to prevent collisions.

===Meadows Field and FGSignMaker===
''skyop'' released his improvements to the Meadows Field (KBFL) scenery. Read [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8466 this topic] for more information.

He is also writing [[FGSignMaker]], a tool to generate taxiway sign codes written in JavaScript. More information on taxiway signs can be found [[Signs|here]].

===Landcover additions===
Connecticut, Oshkosh (Wisconsin, USA) and the Toronto Harbor have been added to the [http://mapserver.flightgear.org FlightGear mapserver]. They will be released to the public with the next scenery build, or alternatively the shapefiles can be downloaded and compiled by the user.

This is in addition to the other numerous improvements to the land cover which are pending with the next scenery release, which includes (but is not limited to) France; Madrid, Spain; London, England; Bonn, Germany; Western Washington, USA; Northwest Oregon, USA; Phoenix, Arizona, USA; Washington, DC, and Baltimore, Maryland, USA; Rhode Island; Hawaii; and Long Island, New York, USA.

Landcover development is ongoing.

===LFLJ and EDDF===
After one year of having released these sceneries (LFLJ/EDDF), ''papillon81'' returned to make changes (some of them big) at them.
More information at the forum: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=5238&st=0&sk=t&sd=a#p84745 EDDF], [http://www.flightgear.org/forums/viewtopic.php?f=5&t=1436&st=0&sk=t&sd=a&start=30#p84800 LFLJ].

==Multiplayer News==
===Atlas Virtual Airlines' leaders recognized!===
[[Atlas Virtual Airlines]], FlightGear's most populated airline, has been a hit success in its inaugural months since opening in mid-April. The airline, however, couldn't have made it without the guidance of its two current leaders: ''MaverickAlex'' (Alex Park) and ''SkyWlf77'' (Jason Sheperd). Besides sinking their own cash into the airline for site domain and software, these two founding members have sorted out many mis-judgements of Atlas and helped to form a strong and community-bonding airline. Jason, the vice-chairman and moderator, helped revamp AVA's standing on the forums and turned many former anti-Atlas-ers into supporting members, which has been very beneficial for the FlightGear multiplayer community. Thanks to him, members can now feel confident to join an airline that was, just months ago, in the midst of intense controversy. Sheperd has taken a strong stand against arguments and flame wars on the Forums, intent on preventing the locked-topics and arguing members that degraded the VA Community during the VA "Dark Ages". But now, Atlas has flourished into a friendship-filled and happy organization that members find enjoyment and fun in.

Meanwhile, Alex, the current chairman and administrator, independently designed an awesome and top-of-the-line VA website for Atlas pilots. He has also worked with nightmares of coding to get drawing-board ideas implemented. And on top of it all, Alex is finishing up his Bombardier Dash-8 400Q, designed especially for Atlas Express flights. This very nicely modeled aircraft will also be available to the public, underlining how Atlas Virtual Airlines is really benefiting all of FlightGear. Alex is the brains behind it all that makes Atlas so sophisticated. His partner, Jason, has the ideas and people-person skills that gives Atlas the openness and fun that attracts its 50-plus members. So, from all of Atlas and those who follow it, thank you, Jason and Alex!

BRIEFS: Atlas celebrated its 50th member this month, a landmark achievement for a VA that is still newborn!

==Aircraft Review==
'''This month: B-25 Mitchell'''

[[Image:B-25.jpg|thumb|270px|A B-25 in the air near KATL]]
The [[B-25]] served in almost every theater in World War II. From Europe to the Pacific, the Mitchell was there. One of the most famous missions accomplished by B-25s was the Doolittle Raid on Tokyo, when a group of 16 B-25s attacked the Japanese mainland, raising morale in the United States, and changing the priorities of the Imperial Japanese Navy, and possibly changing the direction of the war.

The flightgear model looks good on the outside. The author has done a lot of work on the textures, and this is improved even more by some excellent liveries made by Gooneybird that have been added to the B-25 base package by the author. The landing gear, engines and canopies are all carefully modeled, too.

The Cockpit is a little bit threadbare, with no chairs, two pilot figures, and the standard six instruments, which is more than enough to fly with. The only other issue I could come up with was the lack of weapons, but that is only an aesthetic problem. The B-25 handles nicely both on the ground and in the air. I can't talk about accuracy, however, as I have never flown in a B-25, so I don't know how it 'feels' in the air.

The Mitchell sounds great, too!

''Review by Armchair Ace''

==From the community==
===LinuxTAG===
Once again, a team of FlightGear enthusiasts operated a booth during the four days of this year's [http://www.linuxtag.org/ LinuxTAG], the most important place for Linux and open source software in Europe. Besides to it's main purpose of presenting FlightGear to a public audience, LinuxTag becomes more and more '''the''' place for a meeting of core FlightGear developers and users. A technical discussion between James, Alex and Matthias has the potential to become a ''FlightGear legend'' and will probably lead to a multithreaded processing within the simulator's core. Alex also held a public presentation about the integration of [http://www.linuxtag.org/2010/en/program/free-conference/all-events/details.html?talkid=329 "Android for pilots"] with fgfs. [http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Alex%20Perry%20-%20Android%20for%20Pilots%20-%20Integration%20with%20the%20FlightGear%20Flight%20Simulator.pdf]

An exciting first contact was initiated between FlightGear team members and a hardware vendor resulting in an idea to operate a shared presentation of powerful hardware running a powerful flight simulator at the next year's LinuxTAG - to proof the claim "where .com meets .org".

===FlightGear on YouTube===
* ''edubletooth'' captured a [http://www.youtube.com/watch?v=EeQUfnHLs_Q bunch of landings] at the airports with the world's most famous approach: [[Princess Juliana International Airport|Princess Juliana]] in the Netherlands Antilles. Make sure to bend when a 777-200 or maybe even a mighty [[Boeing 747|747]] is passing just meters over your head!
* [http://www.youtube.com/watch?v=nzCcqtkTUT8 This excellent video] proves that ''Howto'' Oscar (we already mentioned him last month) does more than creating howtos. Together with Don's extremely detailed simulation of Gatwick Airport (EGKK), Oscar's video angles make this an interesting and pleasant video to watch.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

==And finally...==
===Your own Copilot===
How about having your own Copilot to help you fly your heavy metal? Imagine: You're at 3000 ft making a hand controlled descent to EGKK 26L in your [[Boeing 777-200|777-200ER]]: "flaps down"; check airspeed and altitude; you're now five miles out; "undercarriage down"; reduce speed a little more; "flaps down"; you seem to be slightly overspeed; "spoilers"; touch down "brakes" then "reverse thrust"; "flaps retract"; now take a look at the detailed scenery while taxiing to your stand; "view" and "zoom out".

Those using Windows can employ '''Shoot''' - a free user-editable voice command utility. This may be used concurrently with FlightGear to recognize spoken words or phrases and carry out keyboard actions - including sequential or Shift/Alt/Ctrl... keying. Unfortunately Linux users do not have access to such a powerful utility.

[http://clans.gameclubcentral.com/shoot Download Shoot 1.6.4] and install it on your PC. You also need the Microsoft Speech API (SAPI) which is also free; the link is given on the Shoot website. The free Microsoft .NET should also be installed using the Shoot link.

Shoot may be edited to obey verbal commands such as "start engines", "maximum thrust", "undercarriage up", "flaps retract", "trim nose down", "deploy spoilers", "reverse thrust", "view exterior" - or whatever you choose. Try it and add more immersion to your flying.

===Did you know?===
* ...that FlightGear is made of roughly 3,000,000 lines of code and would cost more than $42,000,000 if created from scratch? <ref>Metrics from [http://www.ohloh.net/p/flightgear/analyses/latest ohloh.net]</ref>
* ...that in version 2.0, fellow pilots' chat messages could be ignored on [[multiplayer]] by checking the ignore box in the pilot list? For upcoming releases, pilots' aircraft will also be able to be ignored. This is part of a strong offensive against "trolling" that disrupts MP flying.
* ...that the USS Nimitz [[Howto: Carrier|aircraft carrier]] has deck elevators that can be lowered/raised to go below deck? Toggle them up/down in your ATC Options menu under Carrier; Check-Apply raises them, unchecked-apply lowers them.

==References==
<references/>

[[Category:FlightGear Newsletter|2010 06]]

Talk:Decoupling the AI traffic system

2010-06-28T13:47:49Z

MILSTD: /* Also see */

= Further Notes =
* even in an "offline scenario", FlightGear could internally use a local/loopback multiplayer server (fgms) and run the AI traffic component in a separate thread or process to feed in traffic - this would be reliable and keep things very straightforward, because FlightGear could make the assumption that a running fgms instance is always available. Similarly, other global state could also be managed and propagated using such an internal fgms instance. This would simplify the design quite a bit.

* basically, this is already possible without making any modifications to the FG MP protocol: simply by using a dedicated UDP connection for each AI traffic client, instead of directly writing to the FG property tree in order to spawn new AI traffic instances.

* at some point, private (local) fgms instances could by default allow arbitrary AI traffic to be published, while standalone (public) fgms instances should probably be configurable to enable/disable AI traffic propagation from possibly untrusted clients.

= Also see =
* http://wiki.flightgear.org/index.php/Talk:Distributed_Interactive_Simulation#Turning_the_AI_traffic_system_into_an_MP_client
* http://wiki.flightgear.org/index.php/Distributed_Interactive_Simulation
* [[Proposals:AI Traffic related]]
* http://flightgear.org/forums/viewtopic.php?f=5&t=6807&p=60580
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18295.html headless traffic injector]

Talk:Distributed Interactive Simulation

2010-06-28T13:46:12Z

MILSTD: /* Related Discussions */

== Details ==
* "To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34063.html] (XML configurable multiplayer properties specific to individual aircraft)
* "It would be highly desirable to get at least the gear and flap animation, and the weather/clouds sorted"[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34072.html]
* "Cloud movement is based on wind direction and speed so it should be the same at all time if the initial situation is the same. To construct the initial situation I think it's enought to send the cloud layer information and the delta time during the connection to the server."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34065.html]
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34045.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34061.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34253.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34358.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34099.html

== Related Discussions ==
* http://flightgear.org/forums/viewtopic.php?f=10&t=8432 Fixing the MP environment 06/2010
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg11168.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg35695.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34169.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23964.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23969.html
* http://www.flightgear.org/forums/viewtopic.php?f=6&t=292
* http://flightgear.org/forums/viewtopic.php?f=2&t=5532
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17067.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16807.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22673.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18143.html
* About remotely managed properties: "I think the current MP protocol could be enhanced to provide this function fairly easily. The first step would be to (re-add) function to export arbitary properties. Then define the FDM properties to be exported from the master computer (running the FDM), and define control inputs to be passed the other way from the slave (running null FDM)." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10340.html]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25944.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25961.html

== Still to be evaluated ==
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26356.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg07779.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15810.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg12391.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg10793.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg07193.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg14615.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15809.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34627.html

== Turning the AI traffic system into an MP client ==
(This should probably be put somewhere else, as it affects mostly the AI traffic system and is only relevant here because of additional requirements to the MP protocol)
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13245.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13211.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08701.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08708.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18423.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18682.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34145.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18517.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13210.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18295.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34143.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15027.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26038.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26040.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26053.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26054.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26055.html
* http://flightgear.org/forums/viewtopic.php?f=5&t=6807

== Multiplayer Server RFC: ==
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18128.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18317.html

== MP Server ==
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg11931.html
* multiplayer separating environments (worlds) by using different instances [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18281.html]
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18143.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10210.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34139.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg11242.html

== Bandwidth savings ==
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17067.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23994.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23970.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24005.html

== IVAO/VATSIM Discussions ==
Also search mailing lists and forums for IVAO/VATSIM

* http://flightgear.org/forums/viewtopic.php?f=6&t=533

== Regarding Multiplayer-aware ATC Support ==
(also see fgms/atlas sourceforge trackers, and search archives for "ATC", "VATSIM", "IVAO")
* http://sourceforge.net/tracker/index.php?func=detail&aid=1827096&group_id=161928&atid=821811
* http://sourceforge.net/tracker/?func=detail&aid=1905973&group_id=9456&atid=359456
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25729.html

== Initial Data (PUSH/SUBSCRIBE) ==
Depending on the aircraft, each client will need to be provided with a bunch of properties to obtain initial state. These properties are likely to differ between aircraft (custom state such as animations, effects etc), and would ideally be defined by aircraft developers.
So that clients connecting with an aircraft, will automatically provide this initial state, while other multiplayer clients would automatically subscribe to it. This would ideally be specified in each aircraft-set.xml file by aircraft developers. Also see [http://wiki.flightgear.org/index.php/Talk:Recommended_Property_Tree_Enhancements#Remote_Properties]

Portal:Developer

2010-06-28T13:44:55Z

MILSTD: adding WIP RFCs

{{PortalMenu}}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:100%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="1" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">The Developer Portal</h2>
|-
|style="color:#000;"|
This portal is for developers contributing to FlightGear. If you want to help with FlightGears development, it's a good idea to subscribe yourself to the [http://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear devel] mailing list. The [http://sourceforge.net/mailarchive/forum.php?forum_name=flightgear-devel list archive] is also available and should be searched before posting the same question.<br><br>
'''Please choose a sub-portal:'''
* [[Portal:Developer/3D Modelers|3D Modelers]]
* [[Portal:Developer/Aircraft|Aircraft]]
* [[Portal:Developer/Scenery|Scenery]]<br><br>
'''The FlightGear project is looking for organizations/individuals who would be willing to help sponsor a fulltime project coordinator/manager to help oversee the overall development process If you are interested in helping or have anything else to contribute to this issue, please subscribe to the the [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11813.html FlightGear Devel mailing list] to discuss details.''' (Note that the FlightGear project can apply for free funding/sponsoring with [http://www.nlnet.nl nlnet]-applications are to be sent [http://www.nlnet.nl/foundation/request/index.html here]-you can help prepare a template for applying: [[Funding Application]])
|}
|}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Current Events, Efforts/Branches & Work in Progress</h2>
|-
|style="color:#000;"|
*[[FlightGear Package Manager]] (New! Alpha release of [[Java]]/[[XML]] package manager!)
*[[Walk View‎]] (New! walk view code!)
*[[FlightGear Contest]]
'''[[Work in progress|More...]]'''

|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Latest Organizational Issues</h2>
|-
|style="color:#000;"|
* [[ FlightGear Build Server ]]
* [[ Project Infrastructure Enhancements ]]
* [[ Source Code Management Issues ]]
* [[Google Summer of Code Candidate Projects]] - application template to allow community members to prepare a possible application to decrease the effort required to actually apply
* [[Programming Resources]]
* [[ Tools of the Trade ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">FlightGear Issues</h2>
|-
|style="color:#000;"|
* [[Pending Patches]] (2 listed for the moment)
* [[Segfaults]] - Reproducible Critical Bugs in FlightGear
* [[Showstoppers]] - Annoying Issues in FlightGear
* [[FlightGear Glitches]] (graphical/scenery related glitches)
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Improvement Initiatives</h2>
|-
|style="color:#000;"|
* [[Improving Helicopter Realism]]
* [[Improving Glider Realism]]
* [[Usability Improvements]] (list of related feature requests)
* [[Proposals:Eye_Candy_related|Eye Candy & Effects]] (list of related feature requests)
'''[[:Category:Code_Cleanup|More...]]'''

|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Compiling</h2>
|-
|style="color:#000;"|
* [[ Building FlightGear - Linux]]
* [http://macflightgear.sourceforge.net/home/documents/how-to-build-flightgear-cvs-on-mac-os-x/ Building FlightGear - Mac OS X]
* [[ Building FlightGear - Windows]]
* [[ Building FlightGear Launch Control ]]
* [[ Building Terragear ]]
* [[ Building_terragear-cs_in_Ubuntu_64|Building Terragear in Ubuntu]]
* [[ Updating FlightGear on Windows]]
* [[ OpenSceneGraph ]]
* [[ Using TortoiseCVS with FlightGear ]]
* [[ FlightGear and Git ]]
* [[ FlightGear Package Manager ]]

|-
|}

|class="MainPageBG" style="width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Contributing</h2>
|-
|style="color:#000;"|
* [[Howto:Extending Nasal]]
* [[Howto:Creating new Subsystems]]
* [[Howto:Working with the Property Tree API]]
* [[ Code Cleanup ]]
* [[ Contributor Repositories ]] mirrors, branches and forks privately maintained by contributors
* [[ Submitting Patches ]]
* [[ Technical Reports ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Code Internals</h2>
|-
|style="color:#000;"|
* [[Command Parameters]]
* [[ File Formats ]]
* [[ Initialization Sequence ]]
* [[ Nasal scripting language ]]
* [[ Property Tree ]]
* [[ UML Diagrams ]]
* [[ YASim ]]
* [[ FlightGear 1.0 aircraft names for command line‎|1.0.0 a/c names for command line]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Todo</h2>
|-
|style="color:#000;"|
* [[ Bugs ]]
* [[ Feature Requests / Proposals / Ideas ]]
* [[ FGFS Todo ]]
* [[ FlightGear Expo Checklist ]]
* [[ Long Term Goals ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Done</h2>
|-
|style="color:#000;"|
* [[ Changes since 0.9.10 ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">HowTos</h2>
|-
|style="color:#000;"|

* [[Howto: Set up a multiplayer server|Set up a multiplayer server]]
'''[[:Category:Howto|More...]]'''
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Nasal scripting</h2>
|-
|style="color:#000;"|
* [[ Nasal FAQ ]]
* [[ Nasal scripting language ]]
* [[ Nasal Snippets ]]
* [[ Nasal Modules ]]
* [[ Nasal Style Guide ]]
* [[ Writing simple scripts in %22nasal%22 ]]
* [[ Walk View‎]]
* [[Howto: Nasal in scenery object XML files]]
* [[Howto:Extending Nasal]]
|}
|}

__NOTOC__
__NOEDITSECTION__

== Developer Documentation ==
=== RFC Topics ===
'''Clarification:''' In its current form, the RFC section is exclusively based on and covered by previous mailing list and forum discussions (as well as various wiki entries), as such it is not supposed to reflect work in progress (RFC="Request For Comments" and not WIP), but is rather to be seen as an attempt to provide comprehensive analyses and summaries of key issues identified in various FlightGear related discussions and feature requests (which are to be linked to in the corresponding resource sections, if that didn't yet take place, it's because of most of these RFCs being indeed WIP).

Thus, RFC entries are not meant to imply anyone "working" on any of these issues, in fact only because an RFC entry is listed here doesn't necessarily mean that work on that particular issue is prioritized or generally endorsed by the FlightGear community.
These RFC documents are however intended to hopefully help increase and maintain awareness of long-standing issues and challenges affecting FlightGear's evolution and overall development progress in order to solicit community feedback about possible approaches to address these in an efficient and structured fashion.
Anybody is welcome to comment on, help refine and develop new strategies to tackle the challenges presented in these and future RFCs.

* [[A local weather system]] - improving the FlightGear weather system to make it more configurable and feature rich
* [[An Integrated AI Traffic System]] - improving the integration of the AI traffic system with the rest of FlightGear
* [[Autopilot Enhancements]] - enhancing the autopilot infrastructure.
* [[Backwards Compatibility Initiative]] - discussing possible ways to improve FlightGear's backwards compatibility.
* [[Canvas Properties]] - discussing ways to add a 2D drawing API to FlightGear that is property driven
* [[CDI instrument]] - collection of information relating to creating a formal CDI instrument in FG
* [[Decoupling the AI Traffic System]] - discussing possible ways to decouple the AI traffic system from FlightGear in order to improve overall performance and synchronize AI state across multiplayer clients
* [[Distributed Interactive Simulation|Multiplayer Enhancements]] - discussing possible steps to enhance FlightGear's Multiplayer support.
* [[Modularizing, parallelizing and distributing FlightGear]] - splitting fgfs into distinct components that are to be run as separate processes using the property tree for IPC purposes in order to leverage SMP platforms and distribution/remoting to help FlightGear become more scalable.
* [[FDM engine feature standardization]] - discussing possible steps to standardize feature support of mainstream FlightGear FDM engines.
* [[FlightGear Glass Cockpits]] - discussing required infrastructure changes to enable non-developers to easily access FlightGear-internals in order to enable them to model complex glass cockpit-type aircraft instrumentation systems.
* [[FlightGear Headless]] - discussing required steps to enable FlightGear to be used as its own regression testing framework
* [[FlightGear Sessions]] - discussing possible steps to finally allow aircraft to be reliably switched at runtime.
* [[OpenGL GUI RESOURCES|Potential alternatives to Plib's PUI library]] - collection of cross-platform GUI libraries that work with OpenGL
* [[Formalizing Aircraft Status]] - discussing suggestions about how to more properly describe aircraft development status.
* [[Keyboard function priority list]] - reorganizing FlightGear keybindings.
* [[Next Generation Scenery ]] - revamping the FG scenery engine.
* [[Property Tree Reorganization]] - reorganizing the property tree (i.e. implementing and enforcing existing property/node naming conventions).
* [[Recommended Property Tree Enhancements]] - discussing possible property tree enhancements to help ensure integrity of crucial runtime state.
* [[Recommended Project Policies]] - discussing recommended policies for future contributions to the project.
* [[Redesigning the Replay System]] - addressing the restrictions in the current implementation of the replay system
* [[Remote Properties]] - introduces a small but powerful extension to the property tree in order to allow properties to be maintained in a different (remote) instance of a property tree, that is transparently accessed using a network socket.
* [[Simplifying Aircraft Deployment]] - identifying potential steps to simplify deployment of FlightGear aircraft.

[[es:Portal:Desarrollo]]

FlightGear Newsletter June 2010

2010-06-28T13:39:14Z

MILSTD: /* Server wanted: Continuous Integration for FlightGear */ adding URL: http://zakalawe.ath.cx:8080/

{{newsletter}}
{{TOC_right}}

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

==Development news==
===Server wanted: Continuous Integration for FlightGear ===
The FlightGear project has started using a build server for [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] purposes and [http://en.wikipedia.org/wiki/Build_automation automating software builds], the [http://hudson-ci.org/ Hudson] based build server is currently running on a home box as a prototype: http://zakalawe.ath.cx:8080/

A build server like Hudson makes it very easy to automatically build FlightGear from source code, e.g. to check the integrity of the source tree or to help prepare prebuilt binaries, pre-releases or even releases.
The server will need a proper home if it moves beyond the prototype stage. If anyone wishes to volunteer or help sponsor a proper server (with a reasonably symmetric connection) to run Hudson, please get in touch - any Unix will do, for Ubuntu/Debian there's an easy apt.get source available. All the setup can be done remotely, given SSH access. The disk, memory, CPU and bandwidth requirements are pretty moderate, due to our low commit rate. For additional details, please see [[FlightGear Build Server]].

===SquawkGear: Bringing VATSIM to FlightGear!===
{{Main article|SquawkGear}}
SquawkGear is the much-awaited client that allows FlightGear users to connect to the largest and most realistic sim server in the world: [http://vatsim.net/ VATSIM]. VATSIM is simply a network that can, in theory, take any sim, although the current ones are X-Plane and Microsoft Flight Simulator. Using addons like SquawkBox for MSFS, pilots must adhere to strict rules about realism. A valid [[flight plan]] must always be submitted before takeoff, for instance. And pilots must contact [[Air Traffic Control]] before any actions.

SquawkGear brings this wonderful server to FlightGear. While installation is not as simple as that of VATSIM clients for MSFS, pilots are now able to connect to the VATSIM network and use chat and voice to communicate with other players and ATC. Since [[scenery]] is very different between sims, aircraft do not always appear where they are supposed to be; a MSFS user might see you hovering a few feet above the ground, for instance.

With its first release, SquawkGear is an excellent addon for pilots wishing to get on VATSIM without having to buy the payware sims. It is strongly recommended that you '''read all manuals''' before connecting to VATSIM; not only because installation is tricky, but also because there are certain rules to be followed on VATSIM. You will find that your [[KSFO]] on VATSIM is a thousand times more under control than your KSFO on one of the [[Howto: Multiplayer|mpservers]]!

''Special thanks to Ivan (Reed) for all of his work!''

===Bombable air combat add-on updated===
The [http://www.flightgear.org/forums/viewtopic.php?f=2&t=5742 Bombable air combat add-on to FlightGear] received a major update in June. Bombable now has these features:

* Dogfight against other FlightGear pilots over multiplayer with Sopwith Camel, SPAC VII, Fokker DR 1 Triplane, or A6M2 Zero
* Explode/burn when you crash
* Exceeding aircraft limitations (excess g-forces, overspeed) adds damage to your aircraft and finally leads to shutdown/crash
* Shootable/bombable moving AI tanks, jeeps, ships, and aircraft that catch fire, burn, explode, sink, crash, etc.
* AI scenarios that allow you to use FlightGear aircraft for air-to-ground, air-to-sea, and air-to-air combat missions against these targets

==In the hangar==
===Boeing 787 and CRJ-200===
''nickyivyca'' is currently working on the [[Boeing 787]]. He corrected the [[FDM]] and changed some details in the model.
More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8203 in the forums].

He has also been working in the [[CRJ-200]]:

''"The CRJ-200 and 787 were made with very similar systems and such. Neither had a 2.0 compatible AP. So, I found out what was wrong with the one for the 787 first, and made those changes to the CRJ here. Both worked. I also did some FDM improvements, like moving the engines to where they really are and adding gear smoke and contrails."'' - says he [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8329 in the forum thread].

===Cessna T-37===
''richter'' and ''snipey'' are working together in improving the Cessna T-37. Here is a list of items that have been improved/created:

'''Model:'''
* Completely remodeled canopy;
* Main gear wheel wells and covers.
'''Sound:'''
* Interior-exterior sound level difference.
'''Instruments:'''
* Basic flight instruments.

More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8354 at the forum].

===CH-47 Chinook===
''MOJO'' is tuning the CH-47. He spent some time adding external cosmetics which main purpose is to add more detail to the Chinook. He added antenna and aerials, domed windows, pitot tubes, winch, engine hub details and started with the internal cargo bay. He intends to be adding an animated refuel probe and will be including several liveries. His ultimate aim for the CH-47 Chinook is to attempt to get the model more defined and realistic.

===Cirrus Vision SF50===
''Zexe'' created a SF50 model. It is still at a very early stage. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8352 here].

===MiG-15bis===
''vitos'' improved the MiG-15bis model, and released it. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7486 here].

===MB-339 PAN===
The MB-339 PAN aircraft [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8604 was updated by ''Albert''] to work with [[FlightGear]] version 2.0.0.

===Curtiss P-40 Warhawk===
''jackmermod'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8621 is developing a P-40 model]. It is already complete, and to be done are the animations and textures. Development of the P-40 Warhawk is coming along very quick, although a full release date is unknown.

===X-29A===
''Intel-Qube'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8485 is currently revamping] the experimental X-29A aircraft. Here is a list of items that have been improved/created:

* A new, more realistic [[FDM]] is on the way;
* Landing gear has been redone and is now much more aesthetically pleasing;
* New exhaust will now dilate based on throttle as it should;
* The cockpit panel has been entirely rebuilt, is far more detailed, and will likely have interactive switches in the final release;
* The model is more ''"anatomically correct"''.

===Il-96-400/T===
The Il-96-400/T [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 has been updated] to version 3, with more accurate model and a better panel, among other little fixes.

===C-130 Hercules===
The [[C-130]] Hercules [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8629 is receiving some updates] from ''glazmax'' and ''helijah''. These updates include FDM and instruments fixes and improvements.

===San Antonio LPD17===
Browsing through the files, ''HHS'' [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8351 found a rotorcraft carrier model] and made a scenario to run it, which is available on [[Git]].

==Scenery corner==
===Nighttime London Gatwick===
London Gatwick (EGKK) is being further improved and is in the second phase of development - night textures. All the buildings and features are currently being modified by ''karla'' to give suitable lighting and make London Gatwick even more attractive to FlightGear commercial fliers. Landing or taking off from Gatwick at night should add much to your enjoyment of the game - and most likely extend the hours you enter in your pilot's log.
Further improvements and many minor changes are also being made to the existing models and daytime textures.
The link shows an image of the part completed airport at night http://www.donlavelle.net/flightgear/flightgear19.html.

The new scenery will be released early in July.

===Dubai airport gets busy===
With the terrain updates that were discussed in the [[FlightGear Newsletter March 2010#Dubai is coming up|March edition]] still in our minds, we now have another feature for the area; taking it yet another step closer to a bussy and realistic representation of the real emirate!

After looking jealously at the greatly enhanced airport [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) and the latest highlight Gatwick (EGKK) Mike ([[User:D-SKY1|D-SKY1]]) decided to create [[Interactive_Traffic|interactive traffic]] for [[Dubai International Airport]] (OMDB). Based on the existing airport layout in FlightGear the traffic pattern for taxiing between gates and runways has been created in [[TaxiDraw]] next to a timetable for runway usage.

Although no model work is done (yet) a big bunch of scheduled flights is now added to this important hub in the middle east. As Dubai is home port for Emirates Airlines (UAE) only Emirates flights are included. Within the next weeks more scheduled flights for AI traffic at Dubai will be added. During the process of creating AI traffic he tried to stay as close as possible to the real life timetable for Dubai International Airport querying several sources for double checking.

As Emirates Airlines (UAE) is one of the most important customers for the [[Airbus A380]] (UAE just ordered another 30 units of A380) the Emirates Airlines livery has been added to AI aircraft A380. Additionally some minor errors in several traffic files concerning changed [[ICAO]] codes for some airports have been removed.

All changes are available via [[Git]]. Enjoy the enhancements; and always follow [[SID]]s and [[STAR]]s to prevent collisions.

===Meadows Field and FGSignMaker===
''skyop'' released his improvements to the Meadows Field (KBFL) scenery. Read [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8466 this topic] for more information.

He is also writing [[FGSignMaker]], a tool to generate taxiway sign codes written in JavaScript. More information on taxiway signs can be found [[Signs|here]].

===Landcover additions===
Connecticut, Oshkosh (Wisconsin, USA) and the Toronto Harbor have been added to the [[FlightGear]] mapserver. They will be released to the public with the next scenery build, or alternatively the shapefiles can be downloaded and compiled by the user.

This is in addition to the other numerous improvements to the land cover which are pending with the next scenery release, which includes (but is not limited to) France; Madrid, Spain; London, England; Bonn, Germany; Western Washington, USA; Northwest Oregon, USA; Phoenix, Arizona, USA; Washington, DC, and Baltimore, Maryland, USA; Rhode Island; Hawaii; and Long Island, New York, USA.

Landcover development is ongoing.

===LFLJ and EDDF===
After one year of having released these sceneries (LFLJ/EDDF), ''papillon81'' returned to make changes (some of them big) at them.
More information: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=5238&st=0&sk=t&sd=a#p84745 EDDF], [http://www.flightgear.org/forums/viewtopic.php?f=5&t=1436&st=0&sk=t&sd=a&start=30#p84800 LFLJ].

==Multiplayer News==
===Atlas Virtual Airlines' leaders recognized!===
[[Atlas Virtual Airlines]], FlightGear's most populated airline, has been a hit success in its inaugural months since opening in mid-April. The airline, however, couldn't have made it without the guidance of its two current leaders: ''MaverickAlex'' (Alex Park) and ''SkyWlf77'' (Jason Sheperd). Besides sinking their own cash into the airline for site domain and software, these two founding members have sorted out many mis-judgements of Atlas and helped to form a strong and community-bonding airline. Jason, the vice-chairman and moderator, helped revamp AVA's standing on the forums and turned many former anti-Atlas-ers into supporting members, which has been very beneficial for the FlightGear multiplayer community. Thanks to him, members can now feel confident to join an airline that was, just months ago, in the midst of intense controversy. Sheperd has taken a strong stand against arguments and flame wars on the Forums, intent on preventing the locked-topics and arguing members that degraded the VA Community during the VA "Dark Ages". But now, Atlas has flourished into a friendship-filled and happy organization that members find enjoyment and fun in.

Meanwhile, Alex, the current chairman and administrator, independently designed an awesome and top-of-the-line VA website for Atlas pilots. He has also worked with nightmares of coding to get drawing-board ideas implemented. And on top of it all, Alex is finishing up his Bombardier Dash-8 400Q, designed especially for Atlas Express flights. This very nicely modeled aircraft will also be available to the public, underlining how Atlas Virtual Airlines is really benefiting all of FlightGear. Alex is the brains behind it all that makes Atlas so sophisticated. His partner, Jason, has the ideas and people-person skills that gives Atlas the openness and fun that attracts its 50-plus members. So, from all of Atlas and those who follow it, thank you, Jason and Alex!

BRIEFS: Atlas celebrated its 50th member this month, a landmark achievement for a VA that is still newborn!

==Aircraft Review==
'''This month: B-25 Mitchell'''

[[Image:B-25.jpg|thumb|270px|A B-25 in the air near KATL]]
The [[B-25]] served in almost every theater in World War II. From Europe to the Pacific, the Mitchell was there. One of the most famous missions accomplished by B-25s was the Doolittle Raid on Tokyo, when a group of 16 B-25s attacked the Japanese mainland, raising morale in the United States, and changing the priorities of the Imperial Japanese Navy, and possibly changing the direction of the war.

The flightgear model looks good on the outside. The author has done a lot of work on the textures, and this is improved even more by some excellent liveries made by Gooneybird that have been added to the B-25 base package by the author. The landing gear, engines and canopies are all carefully modeled, too.

The Cockpit is a little bit threadbare, with no chairs, two pilot figures, and the standard six instruments, which is more than enough to fly with. The only other issue I could come up with was the lack of weapons, but that is only an aesthetic problem. The B-25 handles nicely both on the ground and in the air. I can't talk about accuracy, however, as I have never flown in a B-25, so I don't know how it 'feels' in the air.

The Mitchell sounds great, too!

''Review by Armchair Ace''

==From the community==
===LinuxTAG===
Once again, a team of FlightGear enthusiasts operated a booth during the four days of this year's [http://www.linuxtag.org/ LinuxTAG], the most important place for Linux and open source software in Europe. Besides to it's main purpose of presenting FlightGear to a public audience, LinuxTag becomes more and more '''the''' place for a meeting of core FlightGear developers and users. A technical discussion between James, Alex and Matthias has the potential to become a ''FlightGear legend'' and will probably lead to a multithreaded processing within the simulator's core. Alex also held a public presentation about the integration of [http://www.linuxtag.org/2010/en/program/free-conference/all-events/details.html?talkid=329 "Android for pilots"] with fgfs. [http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Alex%20Perry%20-%20Android%20for%20Pilots%20-%20Integration%20with%20the%20FlightGear%20Flight%20Simulator.pdf]

An exciting first contact was initiated between FlightGear team members and a hardware vendor resulting in an idea to operate a shared presentation of powerful hardware running a powerful flight simulator at the next year's LinuxTAG - to proof the claim "where .com meets .org".

===FlightGear on YouTube===
* ''edubletooth'' captured a [http://www.youtube.com/watch?v=EeQUfnHLs_Q bunch of landings] at the airports with the world's most famous approach: [[Princess Juliana International Airport|Princess Juliana]] in the Netherlands Antilles. Make sure to bend when a 777-200 or maybe even a mighty [[Boeing 747|747]] is passing just meters over your head!
* [http://www.youtube.com/watch?v=nzCcqtkTUT8 This excellent video] proves that ''Howto'' Oscar (we already mentioned him last month) does more than creating howtos. Together with Don's extremely detailed simulation of Gatwick Airport (EGKK), Oscar's video angles make this an interesting and pleasant video to watch.

==And finally...==
===Your own Copilot===
How about having your own Copilot to help you fly your heavy metal? Imagine: You're at 3000 ft making a hand controlled descent to EGKK 26L in your [[Boeing 777-200|777-200ER]]: "flaps down"; check airspeed and altitude; you're now five miles out; "undercarriage down"; reduce speed a little more; "flaps down"; you seem to be slightly overspeed; "spoilers"; touch down "brakes" then "reverse thrust"; "flaps retract"; now take a look at the detailed scenery while taxiing to your stand; "view" and "zoom out".

Those using Windows can employ '''Shoot''' - a free user-editable voice command utility. This may be used concurrently with FlightGear to recognize spoken words or phrases and carry out keyboard actions - including sequential or Shift/Alt/Ctrl... keying. Unfortunately Linux users do not have access to such a powerful utility.

[http://clans.gameclubcentral.com/shoot Download Shoot 1.6.4] and install it on your PC. You also need the Microsoft Speech API (SAPI) which is also free; the link is given on the Shoot website. The free Microsoft .NET should also be installed using the Shoot link.

Shoot may be edited to obey verbal commands such as "start engines", "maximum thrust", "undercarriage up", "flaps retract", "trim nose down", "deploy spoilers", "reverse thrust", "view exterior" - or whatever you choose. Try it and add more immersion to your flying.

===Did you know?===

* ...that FlightGear is made of roughly 3,000,000 lines of code and would cost more than $42,000,000 if created from scratch? <small>(Metrics from [http://www.ohloh.net/p/flightgear/analyses/latest ohloh.net])</small>

* ...that in version 2.0, fellow pilots' chat messages could be ignored on [[multiplayer]] by checking the ignore box in the pilot list?
For upcoming releases, pilots' aircraft will also be able to be ignored. This is part of a strong offensive against "trolling" that disrupts MP flying.<br>

* ...that the USS Nimitz [[Howto: Carrier|aircraft carrier]] has deck elevators that can be lowered/raised to go below deck?
Toggle them up/down in your ATC Options menu under Carrier; Check-Apply raises them, unchecked-apply lowers them.

[[Category:FlightGear Newsletter|2010 06]]

FlightGear Newsletter June 2010

2010-06-28T13:38:21Z

MILSTD: /* Server wanted: Continuous Integration for FlightGear */ more background info

{{newsletter}}
{{TOC_right}}

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

==Development news==
===Server wanted: Continuous Integration for FlightGear ===
The FlightGear project has started using a build server for [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] purposes and [http://en.wikipedia.org/wiki/Build_automation automating software builds], the [http://hudson-ci.org/ Hudson] based build server is currently running on a home box as a prototype.
A build server like Hudson makes it very easy to automatically build FlightGear from source code, e.g. to check the integrity of the source tree or to help prepare prebuilt binaries, pre-releases or even releases.
The server will need a proper home if it moves beyond the prototype stage. If anyone wishes to volunteer or help sponsor a proper server (with a reasonably symmetric connection) to run Hudson, please get in touch - any Unix will do, for Ubuntu/Debian there's an easy apt.get source available. All the setup can be done remotely, given SSH access. The disk, memory, CPU and bandwidth requirements are pretty moderate, due to our low commit rate. For additional details, please see [[FlightGear Build Server]].

===SquawkGear: Bringing VATSIM to FlightGear!===
{{Main article|SquawkGear}}
SquawkGear is the much-awaited client that allows FlightGear users to connect to the largest and most realistic sim server in the world: [http://vatsim.net/ VATSIM]. VATSIM is simply a network that can, in theory, take any sim, although the current ones are X-Plane and Microsoft Flight Simulator. Using addons like SquawkBox for MSFS, pilots must adhere to strict rules about realism. A valid [[flight plan]] must always be submitted before takeoff, for instance. And pilots must contact [[Air Traffic Control]] before any actions.

SquawkGear brings this wonderful server to FlightGear. While installation is not as simple as that of VATSIM clients for MSFS, pilots are now able to connect to the VATSIM network and use chat and voice to communicate with other players and ATC. Since [[scenery]] is very different between sims, aircraft do not always appear where they are supposed to be; a MSFS user might see you hovering a few feet above the ground, for instance.

With its first release, SquawkGear is an excellent addon for pilots wishing to get on VATSIM without having to buy the payware sims. It is strongly recommended that you '''read all manuals''' before connecting to VATSIM; not only because installation is tricky, but also because there are certain rules to be followed on VATSIM. You will find that your [[KSFO]] on VATSIM is a thousand times more under control than your KSFO on one of the [[Howto: Multiplayer|mpservers]]!

''Special thanks to Ivan (Reed) for all of his work!''

===Bombable air combat add-on updated===
The [http://www.flightgear.org/forums/viewtopic.php?f=2&t=5742 Bombable air combat add-on to FlightGear] received a major update in June. Bombable now has these features:

* Dogfight against other FlightGear pilots over multiplayer with Sopwith Camel, SPAC VII, Fokker DR 1 Triplane, or A6M2 Zero
* Explode/burn when you crash
* Exceeding aircraft limitations (excess g-forces, overspeed) adds damage to your aircraft and finally leads to shutdown/crash
* Shootable/bombable moving AI tanks, jeeps, ships, and aircraft that catch fire, burn, explode, sink, crash, etc.
* AI scenarios that allow you to use FlightGear aircraft for air-to-ground, air-to-sea, and air-to-air combat missions against these targets

==In the hangar==
===Boeing 787 and CRJ-200===
''nickyivyca'' is currently working on the [[Boeing 787]]. He corrected the [[FDM]] and changed some details in the model.
More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8203 in the forums].

He has also been working in the [[CRJ-200]]:

''"The CRJ-200 and 787 were made with very similar systems and such. Neither had a 2.0 compatible AP. So, I found out what was wrong with the one for the 787 first, and made those changes to the CRJ here. Both worked. I also did some FDM improvements, like moving the engines to where they really are and adding gear smoke and contrails."'' - says he [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8329 in the forum thread].

===Cessna T-37===
''richter'' and ''snipey'' are working together in improving the Cessna T-37. Here is a list of items that have been improved/created:

'''Model:'''
* Completely remodeled canopy;
* Main gear wheel wells and covers.
'''Sound:'''
* Interior-exterior sound level difference.
'''Instruments:'''
* Basic flight instruments.

More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8354 at the forum].

===CH-47 Chinook===
''MOJO'' is tuning the CH-47. He spent some time adding external cosmetics which main purpose is to add more detail to the Chinook. He added antenna and aerials, domed windows, pitot tubes, winch, engine hub details and started with the internal cargo bay. He intends to be adding an animated refuel probe and will be including several liveries. His ultimate aim for the CH-47 Chinook is to attempt to get the model more defined and realistic.

===Cirrus Vision SF50===
''Zexe'' created a SF50 model. It is still at a very early stage. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8352 here].

===MiG-15bis===
''vitos'' improved the MiG-15bis model, and released it. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7486 here].

===MB-339 PAN===
The MB-339 PAN aircraft [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8604 was updated by ''Albert''] to work with [[FlightGear]] version 2.0.0.

===Curtiss P-40 Warhawk===
''jackmermod'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8621 is developing a P-40 model]. It is already complete, and to be done are the animations and textures. Development of the P-40 Warhawk is coming along very quick, although a full release date is unknown.

===X-29A===
''Intel-Qube'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8485 is currently revamping] the experimental X-29A aircraft. Here is a list of items that have been improved/created:

* A new, more realistic [[FDM]] is on the way;
* Landing gear has been redone and is now much more aesthetically pleasing;
* New exhaust will now dilate based on throttle as it should;
* The cockpit panel has been entirely rebuilt, is far more detailed, and will likely have interactive switches in the final release;
* The model is more ''"anatomically correct"''.

===Il-96-400/T===
The Il-96-400/T [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 has been updated] to version 3, with more accurate model and a better panel, among other little fixes.

===C-130 Hercules===
The [[C-130]] Hercules [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8629 is receiving some updates] from ''glazmax'' and ''helijah''. These updates include FDM and instruments fixes and improvements.

===San Antonio LPD17===
Browsing through the files, ''HHS'' [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8351 found a rotorcraft carrier model] and made a scenario to run it, which is available on [[Git]].

==Scenery corner==
===Nighttime London Gatwick===
London Gatwick (EGKK) is being further improved and is in the second phase of development - night textures. All the buildings and features are currently being modified by ''karla'' to give suitable lighting and make London Gatwick even more attractive to FlightGear commercial fliers. Landing or taking off from Gatwick at night should add much to your enjoyment of the game - and most likely extend the hours you enter in your pilot's log.
Further improvements and many minor changes are also being made to the existing models and daytime textures.
The link shows an image of the part completed airport at night http://www.donlavelle.net/flightgear/flightgear19.html.

The new scenery will be released early in July.

===Dubai airport gets busy===
With the terrain updates that were discussed in the [[FlightGear Newsletter March 2010#Dubai is coming up|March edition]] still in our minds, we now have another feature for the area; taking it yet another step closer to a bussy and realistic representation of the real emirate!

After looking jealously at the greatly enhanced airport [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) and the latest highlight Gatwick (EGKK) Mike ([[User:D-SKY1|D-SKY1]]) decided to create [[Interactive_Traffic|interactive traffic]] for [[Dubai International Airport]] (OMDB). Based on the existing airport layout in FlightGear the traffic pattern for taxiing between gates and runways has been created in [[TaxiDraw]] next to a timetable for runway usage.

Although no model work is done (yet) a big bunch of scheduled flights is now added to this important hub in the middle east. As Dubai is home port for Emirates Airlines (UAE) only Emirates flights are included. Within the next weeks more scheduled flights for AI traffic at Dubai will be added. During the process of creating AI traffic he tried to stay as close as possible to the real life timetable for Dubai International Airport querying several sources for double checking.

As Emirates Airlines (UAE) is one of the most important customers for the [[Airbus A380]] (UAE just ordered another 30 units of A380) the Emirates Airlines livery has been added to AI aircraft A380. Additionally some minor errors in several traffic files concerning changed [[ICAO]] codes for some airports have been removed.

All changes are available via [[Git]]. Enjoy the enhancements; and always follow [[SID]]s and [[STAR]]s to prevent collisions.

===Meadows Field and FGSignMaker===
''skyop'' released his improvements to the Meadows Field (KBFL) scenery. Read [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8466 this topic] for more information.

He is also writing [[FGSignMaker]], a tool to generate taxiway sign codes written in JavaScript. More information on taxiway signs can be found [[Signs|here]].

===Landcover additions===
Connecticut, Oshkosh (Wisconsin, USA) and the Toronto Harbor have been added to the [[FlightGear]] mapserver. They will be released to the public with the next scenery build, or alternatively the shapefiles can be downloaded and compiled by the user.

This is in addition to the other numerous improvements to the land cover which are pending with the next scenery release, which includes (but is not limited to) France; Madrid, Spain; London, England; Bonn, Germany; Western Washington, USA; Northwest Oregon, USA; Phoenix, Arizona, USA; Washington, DC, and Baltimore, Maryland, USA; Rhode Island; Hawaii; and Long Island, New York, USA.

Landcover development is ongoing.

===LFLJ and EDDF===
After one year of having released these sceneries (LFLJ/EDDF), ''papillon81'' returned to make changes (some of them big) at them.
More information: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=5238&st=0&sk=t&sd=a#p84745 EDDF], [http://www.flightgear.org/forums/viewtopic.php?f=5&t=1436&st=0&sk=t&sd=a&start=30#p84800 LFLJ].

==Multiplayer News==
===Atlas Virtual Airlines' leaders recognized!===
[[Atlas Virtual Airlines]], FlightGear's most populated airline, has been a hit success in its inaugural months since opening in mid-April. The airline, however, couldn't have made it without the guidance of its two current leaders: ''MaverickAlex'' (Alex Park) and ''SkyWlf77'' (Jason Sheperd). Besides sinking their own cash into the airline for site domain and software, these two founding members have sorted out many mis-judgements of Atlas and helped to form a strong and community-bonding airline. Jason, the vice-chairman and moderator, helped revamp AVA's standing on the forums and turned many former anti-Atlas-ers into supporting members, which has been very beneficial for the FlightGear multiplayer community. Thanks to him, members can now feel confident to join an airline that was, just months ago, in the midst of intense controversy. Sheperd has taken a strong stand against arguments and flame wars on the Forums, intent on preventing the locked-topics and arguing members that degraded the VA Community during the VA "Dark Ages". But now, Atlas has flourished into a friendship-filled and happy organization that members find enjoyment and fun in.

Meanwhile, Alex, the current chairman and administrator, independently designed an awesome and top-of-the-line VA website for Atlas pilots. He has also worked with nightmares of coding to get drawing-board ideas implemented. And on top of it all, Alex is finishing up his Bombardier Dash-8 400Q, designed especially for Atlas Express flights. This very nicely modeled aircraft will also be available to the public, underlining how Atlas Virtual Airlines is really benefiting all of FlightGear. Alex is the brains behind it all that makes Atlas so sophisticated. His partner, Jason, has the ideas and people-person skills that gives Atlas the openness and fun that attracts its 50-plus members. So, from all of Atlas and those who follow it, thank you, Jason and Alex!

BRIEFS: Atlas celebrated its 50th member this month, a landmark achievement for a VA that is still newborn!

==Aircraft Review==
'''This month: B-25 Mitchell'''

[[Image:B-25.jpg|thumb|270px|A B-25 in the air near KATL]]
The [[B-25]] served in almost every theater in World War II. From Europe to the Pacific, the Mitchell was there. One of the most famous missions accomplished by B-25s was the Doolittle Raid on Tokyo, when a group of 16 B-25s attacked the Japanese mainland, raising morale in the United States, and changing the priorities of the Imperial Japanese Navy, and possibly changing the direction of the war.

The flightgear model looks good on the outside. The author has done a lot of work on the textures, and this is improved even more by some excellent liveries made by Gooneybird that have been added to the B-25 base package by the author. The landing gear, engines and canopies are all carefully modeled, too.

The Cockpit is a little bit threadbare, with no chairs, two pilot figures, and the standard six instruments, which is more than enough to fly with. The only other issue I could come up with was the lack of weapons, but that is only an aesthetic problem. The B-25 handles nicely both on the ground and in the air. I can't talk about accuracy, however, as I have never flown in a B-25, so I don't know how it 'feels' in the air.

The Mitchell sounds great, too!

''Review by Armchair Ace''

==From the community==
===LinuxTAG===
Once again, a team of FlightGear enthusiasts operated a booth during the four days of this year's [http://www.linuxtag.org/ LinuxTAG], the most important place for Linux and open source software in Europe. Besides to it's main purpose of presenting FlightGear to a public audience, LinuxTag becomes more and more '''the''' place for a meeting of core FlightGear developers and users. A technical discussion between James, Alex and Matthias has the potential to become a ''FlightGear legend'' and will probably lead to a multithreaded processing within the simulator's core. Alex also held a public presentation about the integration of [http://www.linuxtag.org/2010/en/program/free-conference/all-events/details.html?talkid=329 "Android for pilots"] with fgfs. [http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Alex%20Perry%20-%20Android%20for%20Pilots%20-%20Integration%20with%20the%20FlightGear%20Flight%20Simulator.pdf]

An exciting first contact was initiated between FlightGear team members and a hardware vendor resulting in an idea to operate a shared presentation of powerful hardware running a powerful flight simulator at the next year's LinuxTAG - to proof the claim "where .com meets .org".

===FlightGear on YouTube===
* ''edubletooth'' captured a [http://www.youtube.com/watch?v=EeQUfnHLs_Q bunch of landings] at the airports with the world's most famous approach: [[Princess Juliana International Airport|Princess Juliana]] in the Netherlands Antilles. Make sure to bend when a 777-200 or maybe even a mighty [[Boeing 747|747]] is passing just meters over your head!
* [http://www.youtube.com/watch?v=nzCcqtkTUT8 This excellent video] proves that ''Howto'' Oscar (we already mentioned him last month) does more than creating howtos. Together with Don's extremely detailed simulation of Gatwick Airport (EGKK), Oscar's video angles make this an interesting and pleasant video to watch.

==And finally...==
===Your own Copilot===
How about having your own Copilot to help you fly your heavy metal? Imagine: You're at 3000 ft making a hand controlled descent to EGKK 26L in your [[Boeing 777-200|777-200ER]]: "flaps down"; check airspeed and altitude; you're now five miles out; "undercarriage down"; reduce speed a little more; "flaps down"; you seem to be slightly overspeed; "spoilers"; touch down "brakes" then "reverse thrust"; "flaps retract"; now take a look at the detailed scenery while taxiing to your stand; "view" and "zoom out".

Those using Windows can employ '''Shoot''' - a free user-editable voice command utility. This may be used concurrently with FlightGear to recognize spoken words or phrases and carry out keyboard actions - including sequential or Shift/Alt/Ctrl... keying. Unfortunately Linux users do not have access to such a powerful utility.

[http://clans.gameclubcentral.com/shoot Download Shoot 1.6.4] and install it on your PC. You also need the Microsoft Speech API (SAPI) which is also free; the link is given on the Shoot website. The free Microsoft .NET should also be installed using the Shoot link.

Shoot may be edited to obey verbal commands such as "start engines", "maximum thrust", "undercarriage up", "flaps retract", "trim nose down", "deploy spoilers", "reverse thrust", "view exterior" - or whatever you choose. Try it and add more immersion to your flying.

===Did you know?===

* ...that FlightGear is made of roughly 3,000,000 lines of code and would cost more than $42,000,000 if created from scratch? <small>(Metrics from [http://www.ohloh.net/p/flightgear/analyses/latest ohloh.net])</small>

* ...that in version 2.0, fellow pilots' chat messages could be ignored on [[multiplayer]] by checking the ignore box in the pilot list?
For upcoming releases, pilots' aircraft will also be able to be ignored. This is part of a strong offensive against "trolling" that disrupts MP flying.<br>

* ...that the USS Nimitz [[Howto: Carrier|aircraft carrier]] has deck elevators that can be lowered/raised to go below deck?
Toggle them up/down in your ATC Options menu under Carrier; Check-Apply raises them, unchecked-apply lowers them.

[[Category:FlightGear Newsletter|2010 06]]

FlightGear Newsletter June 2010

2010-06-28T13:08:37Z

MILSTD: /* Server wanted: Continuous Integration for FlightGear */

{{newsletter}}
{{TOC_right}}

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

==Development news==
===Server wanted: Continuous Integration for FlightGear ===
The FlightGear project has started using a build server for [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] purposes and automating software builds, the [http://hudson-ci.org/ Hudson] based build server is currently running on a home box as a prototype. The server will need a proper home if it moves beyond the prototype stage. If anyone wishes to volunteer or help sponsor a proper server (with a reasonably symmetric connection) to run Hudson, please get in touch - any Unix will do, for Ubuntu/Debian there's an easy apt.get source available. All the setup can be done remotely, given SSH access. The disk, memory, CPU and bandwidth requirements are pretty moderate, due to our low commit rate. For additional details, please see [[FlightGear Build Server]].

===SquawkGear: Bringing VATSIM to FlightGear!===
{{Main article|SquawkGear}}
SquawkGear is the much-awaited client that allows FlightGear users to connect to the largest and most realistic sim server in the world: [http://vatsim.net/ VATSIM]. VATSIM is simply a network that can, in theory, take any sim, although the current ones are X-Plane and Microsoft Flight Simulator. Using addons like SquawkBox for MSFS, pilots must adhere to strict rules about realism. A valid [[flight plan]] must always be submitted before takeoff, for instance. And pilots must contact [[Air Traffic Control]] before any actions.

SquawkGear brings this wonderful server to FlightGear. While installation is not as simple as that of VATSIM clients for MSFS, pilots are now able to connect to the VATSIM network and use chat and voice to communicate with other players and ATC. Since [[scenery]] is very different between sims, aircraft do not always appear where they are supposed to be; a MSFS user might see you hovering a few feet above the ground, for instance.

With its first release, SquawkGear is an excellent addon for pilots wishing to get on VATSIM without having to buy the payware sims. It is strongly recommended that you '''read all manuals''' before connecting to VATSIM; not only because installation is tricky, but also because there are certain rules to be followed on VATSIM. You will find that your [[KSFO]] on VATSIM is a thousand times more under control than your KSFO on one of the [[Howto: Multiplayer|mpservers]]!

''Special thanks to Ivan (Reed) for all of his work!''

===Bombable air combat add-on updated===
The [http://www.flightgear.org/forums/viewtopic.php?f=2&t=5742 Bombable air combat add-on to FlightGear] received a major update in June. Bombable now has these features:

* Dogfight against other FlightGear pilots over multiplayer with Sopwith Camel, SPAC VII, Fokker DR 1 Triplane, or A6M2 Zero
* Explode/burn when you crash
* Exceeding aircraft limitations (excess g-forces, overspeed) adds damage to your aircraft and finally leads to shutdown/crash
* Shootable/bombable moving AI tanks, jeeps, ships, and aircraft that catch fire, burn, explode, sink, crash, etc.
* AI scenarios that allow you to use FlightGear aircraft for air-to-ground, air-to-sea, and air-to-air combat missions against these targets

==In the hangar==
===Boeing 787 and CRJ-200===
''nickyivyca'' is currently working on the [[Boeing 787]]. He corrected the [[FDM]] and changed some details in the model.
More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8203 in the forums].

He has also been working in the [[CRJ-200]]:

''"The CRJ-200 and 787 were made with very similar systems and such. Neither had a 2.0 compatible AP. So, I found out what was wrong with the one for the 787 first, and made those changes to the CRJ here. Both worked. I also did some FDM improvements, like moving the engines to where they really are and adding gear smoke and contrails."'' - says he [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8329 in the forum thread].

===Cessna T-37===
''richter'' and ''snipey'' are working together in improving the Cessna T-37. Here is a list of items that have been improved/created:

'''Model:'''
* Completely remodeled canopy;
* Main gear wheel wells and covers.
'''Sound:'''
* Interior-exterior sound level difference.
'''Instruments:'''
* Basic flight instruments.

More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8354 at the forum].

===CH-47 Chinook===
''MOJO'' is tuning the CH-47. He spent some time adding external cosmetics which main purpose is to add more detail to the Chinook. He added antenna and aerials, domed windows, pitot tubes, winch, engine hub details and started with the internal cargo bay. He intends to be adding an animated refuel probe and will be including several liveries. His ultimate aim for the CH-47 Chinook is to attempt to get the model more defined and realistic.

===Cirrus Vision SF50===
''Zexe'' created a SF50 model. It is still at a very early stage. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8352 here].

===MiG-15bis===
''vitos'' improved the MiG-15bis model, and released it. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7486 here].

===MB-339 PAN===
The MB-339 PAN aircraft [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8604 was updated by ''Albert''] to work with [[FlightGear]] version 2.0.0.

===Curtiss P-40 Warhawk===
''jackmermod'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8621 is developing a P-40 model]. It is already complete, and to be done are the animations and textures. Development of the P-40 Warhawk is coming along very quick, although a full release date is unknown.

===X-29A===
''Intel-Qube'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8485 is currently revamping] the experimental X-29A aircraft. Here is a list of items that have been improved/created:

* A new, more realistic [[FDM]] is on the way;
* Landing gear has been redone and is now much more aesthetically pleasing;
* New exhaust will now dilate based on throttle as it should;
* The cockpit panel has been entirely rebuilt, is far more detailed, and will likely have interactive switches in the final release;
* The model is more ''"anatomically correct"''.

===Il-96-400/T===
The Il-96-400/T [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 has been updated] to version 3, with more accurate model and a better panel, among other little fixes.

===C-130 Hercules===
The [[C-130]] Hercules [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8629 is receiving some updates] from ''glazmax'' and ''helijah''. These updates include FDM and instruments fixes and improvements.

===San Antonio LPD17===
Browsing through the files, ''HHS'' [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8351 found a rotorcraft carrier model] and made a scenario to run it, which is available on [[Git]].

==Scenery corner==
===Nighttime London Gatwick===
London Gatwick (EGKK) is being further improved and is in the second phase of development - night textures. All the buildings and features are currently being modified by ''karla'' to give suitable lighting and make London Gatwick even more attractive to FlightGear commercial fliers. Landing or taking off from Gatwick at night should add much to your enjoyment of the game - and most likely extend the hours you enter in your pilot's log.
Further improvements and many minor changes are also being made to the existing models and daytime textures.
The link shows an image of the part completed airport at night http://www.donlavelle.net/flightgear/flightgear19.html.

The new scenery will be released early in July.

===Dubai airport gets busy===
With the terrain updates that were discussed in the [[FlightGear Newsletter March 2010#Dubai is coming up|March edition]] still in our minds, we now have another feature for the area; taking it yet another step closer to a bussy and realistic representation of the real emirate!

After looking jealously at the greatly enhanced airport [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) and the latest highlight Gatwick (EGKK) Mike ([[User:D-SKY1|D-SKY1]]) decided to create [[Interactive_Traffic|interactive traffic]] for [[Dubai International Airport]] (OMDB). Based on the existing airport layout in FlightGear the traffic pattern for taxiing between gates and runways has been created in [[TaxiDraw]] next to a timetable for runway usage.

Although no model work is done (yet) a big bunch of scheduled flights is now added to this important hub in the middle east. As Dubai is home port for Emirates Airlines (UAE) only Emirates flights are included. Within the next weeks more scheduled flights for AI traffic at Dubai will be added. During the process of creating AI traffic he tried to stay as close as possible to the real life timetable for Dubai International Airport querying several sources for double checking.

As Emirates Airlines (UAE) is one of the most important customers for the [[Airbus A380]] (UAE just ordered another 30 units of A380) the Emirates Airlines livery has been added to AI aircraft A380. Additionally some minor errors in several traffic files concerning changed [[ICAO]] codes for some airports have been removed.

All changes are available via [[Git]]. Enjoy the enhancements; and always follow [[SID]]s and [[STAR]]s to prevent collisions.

===Meadows Field and FGSignMaker===
''skyop'' released his improvements to the Meadows Field (KBFL) scenery. Read [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8466 this topic] for more information.

He is also writing [[FGSignMaker]], a tool to generate taxiway sign codes written in JavaScript. More information on taxiway signs can be found [[Signs|here]].

===Landcover additions===
Connecticut, Oshkosh (Wisconsin, USA) and the Toronto Harbor have been added to the [[FlightGear]] mapserver. They will be released to the public with the next scenery build, or alternatively the shapefiles can be downloaded and compiled by the user.

This is in addition to the other numerous improvements to the land cover which are pending with the next scenery release, which includes (but is not limited to) France; Madrid, Spain; London, England; Bonn, Germany; Western Washington, USA; Northwest Oregon, USA; Phoenix, Arizona, USA; Washington, DC, and Baltimore, Maryland, USA; Rhode Island; Hawaii; and Long Island, New York, USA.

Landcover development is ongoing.

===LFLJ and EDDF===
After one year of having released these sceneries (LFLJ/EDDF), ''papillon81'' returned to make changes (some of them big) at them.
More information: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=5238&st=0&sk=t&sd=a#p84745 EDDF], [http://www.flightgear.org/forums/viewtopic.php?f=5&t=1436&st=0&sk=t&sd=a&start=30#p84800 LFLJ].

==Multiplayer News==
===Atlas Virtual Airlines' leaders recognized!===
[[Atlas Virtual Airlines]], FlightGear's most populated airline, has been a hit success in its inaugural months since opening in mid-April. The airline, however, couldn't have made it without the guidance of its two current leaders: ''MaverickAlex'' (Alex Park) and ''SkyWlf77'' (Jason Sheperd). Besides sinking their own cash into the airline for site domain and software, these two founding members have sorted out many mis-judgements of Atlas and helped to form a strong and community-bonding airline. Jason, the vice-chairman and moderator, helped revamp AVA's standing on the forums and turned many former anti-Atlas-ers into supporting members, which has been very beneficial for the FlightGear multiplayer community. Thanks to him, members can now feel confident to join an airline that was, just months ago, in the midst of intense controversy. Sheperd has taken a strong stand against arguments and flame wars on the Forums, intent on preventing the locked-topics and arguing members that degraded the VA Community during the VA "Dark Ages". But now, Atlas has flourished into a friendship-filled and happy organization that members find enjoyment and fun in.

Meanwhile, Alex, the current chairman and administrator, independently designed an awesome and top-of-the-line VA website for Atlas pilots. He has also worked with nightmares of coding to get drawing-board ideas implemented. And on top of it all, Alex is finishing up his Bombardier Dash-8 400Q, designed especially for Atlas Express flights. This very nicely modeled aircraft will also be available to the public, underlining how Atlas Virtual Airlines is really benefiting all of FlightGear. Alex is the brains behind it all that makes Atlas so sophisticated. His partner, Jason, has the ideas and people-person skills that gives Atlas the openness and fun that attracts its 50-plus members. So, from all of Atlas and those who follow it, thank you, Jason and Alex!

BRIEFS: Atlas celebrated its 50th member this month, a landmark achievement for a VA that is still newborn!

==Aircraft Review==
'''This month: B-25 Mitchell'''

[[Image:B-25.jpg|thumb|270px|A B-25 in the air near KATL]]
The [[B-25]] served in almost every theater in World War II. From Europe to the Pacific, the Mitchell was there. One of the most famous missions accomplished by B-25s was the Doolittle Raid on Tokyo, when a group of 16 B-25s attacked the Japanese mainland, raising morale in the United States, and changing the priorities of the Imperial Japanese Navy, and possibly changing the direction of the war.

The flightgear model looks good on the outside. The author has done a lot of work on the textures, and this is improved even more by some excellent liveries made by Gooneybird that have been added to the B-25 base package by the author. The landing gear, engines and canopies are all carefully modeled, too.

The Cockpit is a little bit threadbare, with no chairs, two pilot figures, and the standard six instruments, which is more than enough to fly with. The only other issue I could come up with was the lack of weapons, but that is only an aesthetic problem. The B-25 handles nicely both on the ground and in the air. I can't talk about accuracy, however, as I have never flown in a B-25, so I don't know how it 'feels' in the air.

The Mitchell sounds great, too!

''Review by Armchair Ace''

==From the community==
===LinuxTAG===
Once again, a team of FlightGear enthusiasts operated a booth during the four days of this year's [http://www.linuxtag.org/ LinuxTAG], the most important place for Linux and open source software in Europe. Besides to it's main purpose of presenting FlightGear to a public audience, LinuxTag becomes more and more '''the''' place for a meeting of core FlightGear developers and users. A technical discussion between James, Alex and Matthias has the potential to become a ''FlightGear legend'' and will probably lead to a multithreaded processing within the simulator's core. Alex also held a public presentation about the integration of [http://www.linuxtag.org/2010/en/program/free-conference/all-events/details.html?talkid=329 "Android for pilots"] with fgfs. [http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Alex%20Perry%20-%20Android%20for%20Pilots%20-%20Integration%20with%20the%20FlightGear%20Flight%20Simulator.pdf]

An exciting first contact was initiated between FlightGear team members and a hardware vendor resulting in an idea to operate a shared presentation of powerful hardware running a powerful flight simulator at the next year's LinuxTAG - to proof the claim "where .com meets .org".

===FlightGear on YouTube===
* ''edubletooth'' captured a [http://www.youtube.com/watch?v=EeQUfnHLs_Q bunch of landings] at the airports with the world's most famous approach: [[Princess Juliana International Airport|Princess Juliana]] in the Netherlands Antilles. Make sure to bend when a 777-200 or maybe even a mighty [[Boeing 747|747]] is passing just meters over your head!
* [http://www.youtube.com/watch?v=nzCcqtkTUT8 This excellent video] proves that ''Howto'' Oscar (we already mentioned him last month) does more than creating howtos. Together with Don's extremely detailed simulation of Gatwick Airport (EGKK), Oscar's video angles make this an interesting and pleasant video to watch.

==And finally...==
===Your own Copilot===
How about having your own Copilot to help you fly your heavy metal? Imagine: You're at 3000 ft making a hand controlled descent to EGKK 26L in your [[Boeing 777-200|777-200ER]]: "flaps down"; check airspeed and altitude; you're now five miles out; "undercarriage down"; reduce speed a little more; "flaps down"; you seem to be slightly overspeed; "spoilers"; touch down "brakes" then "reverse thrust"; "flaps retract"; now take a look at the detailed scenery while taxiing to your stand; "view" and "zoom out".

Those using Windows can employ '''Shoot''' - a free user-editable voice command utility. This may be used concurrently with FlightGear to recognize spoken words or phrases and carry out keyboard actions - including sequential or Shift/Alt/Ctrl... keying. Unfortunately Linux users do not have access to such a powerful utility.

[http://clans.gameclubcentral.com/shoot Download Shoot 1.6.4] and install it on your PC. You also need the Microsoft Speech API (SAPI) which is also free; the link is given on the Shoot website. The free Microsoft .NET should also be installed using the Shoot link.

Shoot may be edited to obey verbal commands such as "start engines", "maximum thrust", "undercarriage up", "flaps retract", "trim nose down", "deploy spoilers", "reverse thrust", "view exterior" - or whatever you choose. Try it and add more immersion to your flying.

===Did you know?===

* ...that FlightGear is made of roughly 3,000,000 lines of code and would cost more than $42,000,000 if created from scratch? <small>(Metrics from [http://www.ohloh.net/p/flightgear/analyses/latest ohloh.net])</small>

* ...that in version 2.0, fellow pilots' chat messages could be ignored on [[multiplayer]] by checking the ignore box in the pilot list?
For upcoming releases, pilots' aircraft will also be able to be ignored. This is part of a strong offensive against "trolling" that disrupts MP flying.<br>

* ...that the USS Nimitz [[Howto: Carrier|aircraft carrier]] has deck elevators that can be lowered/raised to go below deck?
Toggle them up/down in your ATC Options menu under Carrier; Check-Apply raises them, unchecked-apply lowers them.

[[Category:FlightGear Newsletter|2010 06]]

FlightGear Newsletter June 2010

2010-06-28T13:08:10Z

MILSTD: /* Server wanted: Continuous Integration for FlightGear */ linking to wikipedia CI article

{{newsletter}}
{{TOC_right}}

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

==Development news==
===Server wanted: Continuous Integration for FlightGear ===
The FlightGear project has started using a build server for [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] purposes and automating software builds, the [http://hudson-ci.org/ Hudson] based build server is currently running on a home box as a prototype. The server will need a proper home if it moves beyond the prototype stage. If anyone wishes to volunteer a proper server (with a reasonably symmetric connection) to run Hudson, please get in touch - any Unix will do, for Ubuntu/Debian there's an easy apt.get source available. All the setup can be done remotely, given SSH access. The disk, memory, CPU and bandwidth requirements are pretty moderate, due to our low commit rate. For additional details, please see [[FlightGear Build Server]].

===SquawkGear: Bringing VATSIM to FlightGear!===
{{Main article|SquawkGear}}
SquawkGear is the much-awaited client that allows FlightGear users to connect to the largest and most realistic sim server in the world: [http://vatsim.net/ VATSIM]. VATSIM is simply a network that can, in theory, take any sim, although the current ones are X-Plane and Microsoft Flight Simulator. Using addons like SquawkBox for MSFS, pilots must adhere to strict rules about realism. A valid [[flight plan]] must always be submitted before takeoff, for instance. And pilots must contact [[Air Traffic Control]] before any actions.

SquawkGear brings this wonderful server to FlightGear. While installation is not as simple as that of VATSIM clients for MSFS, pilots are now able to connect to the VATSIM network and use chat and voice to communicate with other players and ATC. Since [[scenery]] is very different between sims, aircraft do not always appear where they are supposed to be; a MSFS user might see you hovering a few feet above the ground, for instance.

With its first release, SquawkGear is an excellent addon for pilots wishing to get on VATSIM without having to buy the payware sims. It is strongly recommended that you '''read all manuals''' before connecting to VATSIM; not only because installation is tricky, but also because there are certain rules to be followed on VATSIM. You will find that your [[KSFO]] on VATSIM is a thousand times more under control than your KSFO on one of the [[Howto: Multiplayer|mpservers]]!

''Special thanks to Ivan (Reed) for all of his work!''

===Bombable air combat add-on updated===
The [http://www.flightgear.org/forums/viewtopic.php?f=2&t=5742 Bombable air combat add-on to FlightGear] received a major update in June. Bombable now has these features:

* Dogfight against other FlightGear pilots over multiplayer with Sopwith Camel, SPAC VII, Fokker DR 1 Triplane, or A6M2 Zero
* Explode/burn when you crash
* Exceeding aircraft limitations (excess g-forces, overspeed) adds damage to your aircraft and finally leads to shutdown/crash
* Shootable/bombable moving AI tanks, jeeps, ships, and aircraft that catch fire, burn, explode, sink, crash, etc.
* AI scenarios that allow you to use FlightGear aircraft for air-to-ground, air-to-sea, and air-to-air combat missions against these targets

==In the hangar==
===Boeing 787 and CRJ-200===
''nickyivyca'' is currently working on the [[Boeing 787]]. He corrected the [[FDM]] and changed some details in the model.
More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8203 in the forums].

He has also been working in the [[CRJ-200]]:

''"The CRJ-200 and 787 were made with very similar systems and such. Neither had a 2.0 compatible AP. So, I found out what was wrong with the one for the 787 first, and made those changes to the CRJ here. Both worked. I also did some FDM improvements, like moving the engines to where they really are and adding gear smoke and contrails."'' - says he [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8329 in the forum thread].

===Cessna T-37===
''richter'' and ''snipey'' are working together in improving the Cessna T-37. Here is a list of items that have been improved/created:

'''Model:'''
* Completely remodeled canopy;
* Main gear wheel wells and covers.
'''Sound:'''
* Interior-exterior sound level difference.
'''Instruments:'''
* Basic flight instruments.

More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8354 at the forum].

===CH-47 Chinook===
''MOJO'' is tuning the CH-47. He spent some time adding external cosmetics which main purpose is to add more detail to the Chinook. He added antenna and aerials, domed windows, pitot tubes, winch, engine hub details and started with the internal cargo bay. He intends to be adding an animated refuel probe and will be including several liveries. His ultimate aim for the CH-47 Chinook is to attempt to get the model more defined and realistic.

===Cirrus Vision SF50===
''Zexe'' created a SF50 model. It is still at a very early stage. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8352 here].

===MiG-15bis===
''vitos'' improved the MiG-15bis model, and released it. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7486 here].

===MB-339 PAN===
The MB-339 PAN aircraft [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8604 was updated by ''Albert''] to work with [[FlightGear]] version 2.0.0.

===Curtiss P-40 Warhawk===
''jackmermod'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8621 is developing a P-40 model]. It is already complete, and to be done are the animations and textures. Development of the P-40 Warhawk is coming along very quick, although a full release date is unknown.

===X-29A===
''Intel-Qube'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8485 is currently revamping] the experimental X-29A aircraft. Here is a list of items that have been improved/created:

* A new, more realistic [[FDM]] is on the way;
* Landing gear has been redone and is now much more aesthetically pleasing;
* New exhaust will now dilate based on throttle as it should;
* The cockpit panel has been entirely rebuilt, is far more detailed, and will likely have interactive switches in the final release;
* The model is more ''"anatomically correct"''.

===Il-96-400/T===
The Il-96-400/T [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 has been updated] to version 3, with more accurate model and a better panel, among other little fixes.

===C-130 Hercules===
The [[C-130]] Hercules [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8629 is receiving some updates] from ''glazmax'' and ''helijah''. These updates include FDM and instruments fixes and improvements.

===San Antonio LPD17===
Browsing through the files, ''HHS'' [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8351 found a rotorcraft carrier model] and made a scenario to run it, which is available on [[Git]].

==Scenery corner==
===Nighttime London Gatwick===
London Gatwick (EGKK) is being further improved and is in the second phase of development - night textures. All the buildings and features are currently being modified by ''karla'' to give suitable lighting and make London Gatwick even more attractive to FlightGear commercial fliers. Landing or taking off from Gatwick at night should add much to your enjoyment of the game - and most likely extend the hours you enter in your pilot's log.
Further improvements and many minor changes are also being made to the existing models and daytime textures.
The link shows an image of the part completed airport at night http://www.donlavelle.net/flightgear/flightgear19.html.

The new scenery will be released early in July.

===Dubai airport gets busy===
With the terrain updates that were discussed in the [[FlightGear Newsletter March 2010#Dubai is coming up|March edition]] still in our minds, we now have another feature for the area; taking it yet another step closer to a bussy and realistic representation of the real emirate!

After looking jealously at the greatly enhanced airport [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) and the latest highlight Gatwick (EGKK) Mike ([[User:D-SKY1|D-SKY1]]) decided to create [[Interactive_Traffic|interactive traffic]] for [[Dubai International Airport]] (OMDB). Based on the existing airport layout in FlightGear the traffic pattern for taxiing between gates and runways has been created in [[TaxiDraw]] next to a timetable for runway usage.

Although no model work is done (yet) a big bunch of scheduled flights is now added to this important hub in the middle east. As Dubai is home port for Emirates Airlines (UAE) only Emirates flights are included. Within the next weeks more scheduled flights for AI traffic at Dubai will be added. During the process of creating AI traffic he tried to stay as close as possible to the real life timetable for Dubai International Airport querying several sources for double checking.

As Emirates Airlines (UAE) is one of the most important customers for the [[Airbus A380]] (UAE just ordered another 30 units of A380) the Emirates Airlines livery has been added to AI aircraft A380. Additionally some minor errors in several traffic files concerning changed [[ICAO]] codes for some airports have been removed.

All changes are available via [[Git]]. Enjoy the enhancements; and always follow [[SID]]s and [[STAR]]s to prevent collisions.

===Meadows Field and FGSignMaker===
''skyop'' released his improvements to the Meadows Field (KBFL) scenery. Read [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8466 this topic] for more information.

He is also writing [[FGSignMaker]], a tool to generate taxiway sign codes written in JavaScript. More information on taxiway signs can be found [[Signs|here]].

===Landcover additions===
Connecticut, Oshkosh (Wisconsin, USA) and the Toronto Harbor have been added to the [[FlightGear]] mapserver. They will be released to the public with the next scenery build, or alternatively the shapefiles can be downloaded and compiled by the user.

This is in addition to the other numerous improvements to the land cover which are pending with the next scenery release, which includes (but is not limited to) France; Madrid, Spain; London, England; Bonn, Germany; Western Washington, USA; Northwest Oregon, USA; Phoenix, Arizona, USA; Washington, DC, and Baltimore, Maryland, USA; Rhode Island; Hawaii; and Long Island, New York, USA.

Landcover development is ongoing.

===LFLJ and EDDF===
After one year of having released these sceneries (LFLJ/EDDF), ''papillon81'' returned to make changes (some of them big) at them.
More information: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=5238&st=0&sk=t&sd=a#p84745 EDDF], [http://www.flightgear.org/forums/viewtopic.php?f=5&t=1436&st=0&sk=t&sd=a&start=30#p84800 LFLJ].

==Multiplayer News==
===Atlas Virtual Airlines' leaders recognized!===
[[Atlas Virtual Airlines]], FlightGear's most populated airline, has been a hit success in its inaugural months since opening in mid-April. The airline, however, couldn't have made it without the guidance of its two current leaders: ''MaverickAlex'' (Alex Park) and ''SkyWlf77'' (Jason Sheperd). Besides sinking their own cash into the airline for site domain and software, these two founding members have sorted out many mis-judgements of Atlas and helped to form a strong and community-bonding airline. Jason, the vice-chairman and moderator, helped revamp AVA's standing on the forums and turned many former anti-Atlas-ers into supporting members, which has been very beneficial for the FlightGear multiplayer community. Thanks to him, members can now feel confident to join an airline that was, just months ago, in the midst of intense controversy. Sheperd has taken a strong stand against arguments and flame wars on the Forums, intent on preventing the locked-topics and arguing members that degraded the VA Community during the VA "Dark Ages". But now, Atlas has flourished into a friendship-filled and happy organization that members find enjoyment and fun in.

Meanwhile, Alex, the current chairman and administrator, independently designed an awesome and top-of-the-line VA website for Atlas pilots. He has also worked with nightmares of coding to get drawing-board ideas implemented. And on top of it all, Alex is finishing up his Bombardier Dash-8 400Q, designed especially for Atlas Express flights. This very nicely modeled aircraft will also be available to the public, underlining how Atlas Virtual Airlines is really benefiting all of FlightGear. Alex is the brains behind it all that makes Atlas so sophisticated. His partner, Jason, has the ideas and people-person skills that gives Atlas the openness and fun that attracts its 50-plus members. So, from all of Atlas and those who follow it, thank you, Jason and Alex!

BRIEFS: Atlas celebrated its 50th member this month, a landmark achievement for a VA that is still newborn!

==Aircraft Review==
'''This month: B-25 Mitchell'''

[[Image:B-25.jpg|thumb|270px|A B-25 in the air near KATL]]
The [[B-25]] served in almost every theater in World War II. From Europe to the Pacific, the Mitchell was there. One of the most famous missions accomplished by B-25s was the Doolittle Raid on Tokyo, when a group of 16 B-25s attacked the Japanese mainland, raising morale in the United States, and changing the priorities of the Imperial Japanese Navy, and possibly changing the direction of the war.

The flightgear model looks good on the outside. The author has done a lot of work on the textures, and this is improved even more by some excellent liveries made by Gooneybird that have been added to the B-25 base package by the author. The landing gear, engines and canopies are all carefully modeled, too.

The Cockpit is a little bit threadbare, with no chairs, two pilot figures, and the standard six instruments, which is more than enough to fly with. The only other issue I could come up with was the lack of weapons, but that is only an aesthetic problem. The B-25 handles nicely both on the ground and in the air. I can't talk about accuracy, however, as I have never flown in a B-25, so I don't know how it 'feels' in the air.

The Mitchell sounds great, too!

''Review by Armchair Ace''

==From the community==
===LinuxTAG===
Once again, a team of FlightGear enthusiasts operated a booth during the four days of this year's [http://www.linuxtag.org/ LinuxTAG], the most important place for Linux and open source software in Europe. Besides to it's main purpose of presenting FlightGear to a public audience, LinuxTag becomes more and more '''the''' place for a meeting of core FlightGear developers and users. A technical discussion between James, Alex and Matthias has the potential to become a ''FlightGear legend'' and will probably lead to a multithreaded processing within the simulator's core. Alex also held a public presentation about the integration of [http://www.linuxtag.org/2010/en/program/free-conference/all-events/details.html?talkid=329 "Android for pilots"] with fgfs. [http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Alex%20Perry%20-%20Android%20for%20Pilots%20-%20Integration%20with%20the%20FlightGear%20Flight%20Simulator.pdf]

An exciting first contact was initiated between FlightGear team members and a hardware vendor resulting in an idea to operate a shared presentation of powerful hardware running a powerful flight simulator at the next year's LinuxTAG - to proof the claim "where .com meets .org".

===FlightGear on YouTube===
* ''edubletooth'' captured a [http://www.youtube.com/watch?v=EeQUfnHLs_Q bunch of landings] at the airports with the world's most famous approach: [[Princess Juliana International Airport|Princess Juliana]] in the Netherlands Antilles. Make sure to bend when a 777-200 or maybe even a mighty [[Boeing 747|747]] is passing just meters over your head!
* [http://www.youtube.com/watch?v=nzCcqtkTUT8 This excellent video] proves that ''Howto'' Oscar (we already mentioned him last month) does more than creating howtos. Together with Don's extremely detailed simulation of Gatwick Airport (EGKK), Oscar's video angles make this an interesting and pleasant video to watch.

==And finally...==
===Your own Copilot===
How about having your own Copilot to help you fly your heavy metal? Imagine: You're at 3000 ft making a hand controlled descent to EGKK 26L in your [[Boeing 777-200|777-200ER]]: "flaps down"; check airspeed and altitude; you're now five miles out; "undercarriage down"; reduce speed a little more; "flaps down"; you seem to be slightly overspeed; "spoilers"; touch down "brakes" then "reverse thrust"; "flaps retract"; now take a look at the detailed scenery while taxiing to your stand; "view" and "zoom out".

Those using Windows can employ '''Shoot''' - a free user-editable voice command utility. This may be used concurrently with FlightGear to recognize spoken words or phrases and carry out keyboard actions - including sequential or Shift/Alt/Ctrl... keying. Unfortunately Linux users do not have access to such a powerful utility.

[http://clans.gameclubcentral.com/shoot Download Shoot 1.6.4] and install it on your PC. You also need the Microsoft Speech API (SAPI) which is also free; the link is given on the Shoot website. The free Microsoft .NET should also be installed using the Shoot link.

Shoot may be edited to obey verbal commands such as "start engines", "maximum thrust", "undercarriage up", "flaps retract", "trim nose down", "deploy spoilers", "reverse thrust", "view exterior" - or whatever you choose. Try it and add more immersion to your flying.

===Did you know?===

* ...that FlightGear is made of roughly 3,000,000 lines of code and would cost more than $42,000,000 if created from scratch? <small>(Metrics from [http://www.ohloh.net/p/flightgear/analyses/latest ohloh.net])</small>

* ...that in version 2.0, fellow pilots' chat messages could be ignored on [[multiplayer]] by checking the ignore box in the pilot list?
For upcoming releases, pilots' aircraft will also be able to be ignored. This is part of a strong offensive against "trolling" that disrupts MP flying.<br>

* ...that the USS Nimitz [[Howto: Carrier|aircraft carrier]] has deck elevators that can be lowered/raised to go below deck?
Toggle them up/down in your ATC Options menu under Carrier; Check-Apply raises them, unchecked-apply lowers them.

[[Category:FlightGear Newsletter|2010 06]]

FlightGear Newsletter June 2010

2010-06-28T13:07:32Z

MILSTD: /* Development news */ linking to Hudson based CI server article

{{newsletter}}
{{TOC_right}}

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

==Development news==
===Server wanted: Continuous Integration for FlightGear ===
The FlightGear project has started using a build server for continuous integration purposes and automating software builds, the [http://hudson-ci.org/ Hudson] based build server is currently running on a home box as a prototype. The server will need a proper home if it moves beyond the prototype stage. If anyone wishes to volunteer a proper server (with a reasonably symmetric connection) to run Hudson, please get in touch - any Unix will do, for Ubuntu/Debian there's an easy apt.get source available. All the setup can be done remotely, given SSH access. The disk, memory, CPU and bandwidth requirements are pretty moderate, due to our low commit rate. For additional details, please see [[FlightGear Build Server]].

===SquawkGear: Bringing VATSIM to FlightGear!===
{{Main article|SquawkGear}}
SquawkGear is the much-awaited client that allows FlightGear users to connect to the largest and most realistic sim server in the world: [http://vatsim.net/ VATSIM]. VATSIM is simply a network that can, in theory, take any sim, although the current ones are X-Plane and Microsoft Flight Simulator. Using addons like SquawkBox for MSFS, pilots must adhere to strict rules about realism. A valid [[flight plan]] must always be submitted before takeoff, for instance. And pilots must contact [[Air Traffic Control]] before any actions.

SquawkGear brings this wonderful server to FlightGear. While installation is not as simple as that of VATSIM clients for MSFS, pilots are now able to connect to the VATSIM network and use chat and voice to communicate with other players and ATC. Since [[scenery]] is very different between sims, aircraft do not always appear where they are supposed to be; a MSFS user might see you hovering a few feet above the ground, for instance.

With its first release, SquawkGear is an excellent addon for pilots wishing to get on VATSIM without having to buy the payware sims. It is strongly recommended that you '''read all manuals''' before connecting to VATSIM; not only because installation is tricky, but also because there are certain rules to be followed on VATSIM. You will find that your [[KSFO]] on VATSIM is a thousand times more under control than your KSFO on one of the [[Howto: Multiplayer|mpservers]]!

''Special thanks to Ivan (Reed) for all of his work!''

===Bombable air combat add-on updated===
The [http://www.flightgear.org/forums/viewtopic.php?f=2&t=5742 Bombable air combat add-on to FlightGear] received a major update in June. Bombable now has these features:

* Dogfight against other FlightGear pilots over multiplayer with Sopwith Camel, SPAC VII, Fokker DR 1 Triplane, or A6M2 Zero
* Explode/burn when you crash
* Exceeding aircraft limitations (excess g-forces, overspeed) adds damage to your aircraft and finally leads to shutdown/crash
* Shootable/bombable moving AI tanks, jeeps, ships, and aircraft that catch fire, burn, explode, sink, crash, etc.
* AI scenarios that allow you to use FlightGear aircraft for air-to-ground, air-to-sea, and air-to-air combat missions against these targets

==In the hangar==
===Boeing 787 and CRJ-200===
''nickyivyca'' is currently working on the [[Boeing 787]]. He corrected the [[FDM]] and changed some details in the model.
More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8203 in the forums].

He has also been working in the [[CRJ-200]]:

''"The CRJ-200 and 787 were made with very similar systems and such. Neither had a 2.0 compatible AP. So, I found out what was wrong with the one for the 787 first, and made those changes to the CRJ here. Both worked. I also did some FDM improvements, like moving the engines to where they really are and adding gear smoke and contrails."'' - says he [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8329 in the forum thread].

===Cessna T-37===
''richter'' and ''snipey'' are working together in improving the Cessna T-37. Here is a list of items that have been improved/created:

'''Model:'''
* Completely remodeled canopy;
* Main gear wheel wells and covers.
'''Sound:'''
* Interior-exterior sound level difference.
'''Instruments:'''
* Basic flight instruments.

More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8354 at the forum].

===CH-47 Chinook===
''MOJO'' is tuning the CH-47. He spent some time adding external cosmetics which main purpose is to add more detail to the Chinook. He added antenna and aerials, domed windows, pitot tubes, winch, engine hub details and started with the internal cargo bay. He intends to be adding an animated refuel probe and will be including several liveries. His ultimate aim for the CH-47 Chinook is to attempt to get the model more defined and realistic.

===Cirrus Vision SF50===
''Zexe'' created a SF50 model. It is still at a very early stage. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8352 here].

===MiG-15bis===
''vitos'' improved the MiG-15bis model, and released it. More information [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7486 here].

===MB-339 PAN===
The MB-339 PAN aircraft [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8604 was updated by ''Albert''] to work with [[FlightGear]] version 2.0.0.

===Curtiss P-40 Warhawk===
''jackmermod'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8621 is developing a P-40 model]. It is already complete, and to be done are the animations and textures. Development of the P-40 Warhawk is coming along very quick, although a full release date is unknown.

===X-29A===
''Intel-Qube'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8485 is currently revamping] the experimental X-29A aircraft. Here is a list of items that have been improved/created:

* A new, more realistic [[FDM]] is on the way;
* Landing gear has been redone and is now much more aesthetically pleasing;
* New exhaust will now dilate based on throttle as it should;
* The cockpit panel has been entirely rebuilt, is far more detailed, and will likely have interactive switches in the final release;
* The model is more ''"anatomically correct"''.

===Il-96-400/T===
The Il-96-400/T [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 has been updated] to version 3, with more accurate model and a better panel, among other little fixes.

===C-130 Hercules===
The [[C-130]] Hercules [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8629 is receiving some updates] from ''glazmax'' and ''helijah''. These updates include FDM and instruments fixes and improvements.

===San Antonio LPD17===
Browsing through the files, ''HHS'' [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8351 found a rotorcraft carrier model] and made a scenario to run it, which is available on [[Git]].

==Scenery corner==
===Nighttime London Gatwick===
London Gatwick (EGKK) is being further improved and is in the second phase of development - night textures. All the buildings and features are currently being modified by ''karla'' to give suitable lighting and make London Gatwick even more attractive to FlightGear commercial fliers. Landing or taking off from Gatwick at night should add much to your enjoyment of the game - and most likely extend the hours you enter in your pilot's log.
Further improvements and many minor changes are also being made to the existing models and daytime textures.
The link shows an image of the part completed airport at night http://www.donlavelle.net/flightgear/flightgear19.html.

The new scenery will be released early in July.

===Dubai airport gets busy===
With the terrain updates that were discussed in the [[FlightGear Newsletter March 2010#Dubai is coming up|March edition]] still in our minds, we now have another feature for the area; taking it yet another step closer to a bussy and realistic representation of the real emirate!

After looking jealously at the greatly enhanced airport [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) and the latest highlight Gatwick (EGKK) Mike ([[User:D-SKY1|D-SKY1]]) decided to create [[Interactive_Traffic|interactive traffic]] for [[Dubai International Airport]] (OMDB). Based on the existing airport layout in FlightGear the traffic pattern for taxiing between gates and runways has been created in [[TaxiDraw]] next to a timetable for runway usage.

Although no model work is done (yet) a big bunch of scheduled flights is now added to this important hub in the middle east. As Dubai is home port for Emirates Airlines (UAE) only Emirates flights are included. Within the next weeks more scheduled flights for AI traffic at Dubai will be added. During the process of creating AI traffic he tried to stay as close as possible to the real life timetable for Dubai International Airport querying several sources for double checking.

As Emirates Airlines (UAE) is one of the most important customers for the [[Airbus A380]] (UAE just ordered another 30 units of A380) the Emirates Airlines livery has been added to AI aircraft A380. Additionally some minor errors in several traffic files concerning changed [[ICAO]] codes for some airports have been removed.

All changes are available via [[Git]]. Enjoy the enhancements; and always follow [[SID]]s and [[STAR]]s to prevent collisions.

===Meadows Field and FGSignMaker===
''skyop'' released his improvements to the Meadows Field (KBFL) scenery. Read [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8466 this topic] for more information.

He is also writing [[FGSignMaker]], a tool to generate taxiway sign codes written in JavaScript. More information on taxiway signs can be found [[Signs|here]].

===Landcover additions===
Connecticut, Oshkosh (Wisconsin, USA) and the Toronto Harbor have been added to the [[FlightGear]] mapserver. They will be released to the public with the next scenery build, or alternatively the shapefiles can be downloaded and compiled by the user.

This is in addition to the other numerous improvements to the land cover which are pending with the next scenery release, which includes (but is not limited to) France; Madrid, Spain; London, England; Bonn, Germany; Western Washington, USA; Northwest Oregon, USA; Phoenix, Arizona, USA; Washington, DC, and Baltimore, Maryland, USA; Rhode Island; Hawaii; and Long Island, New York, USA.

Landcover development is ongoing.

===LFLJ and EDDF===
After one year of having released these sceneries (LFLJ/EDDF), ''papillon81'' returned to make changes (some of them big) at them.
More information: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=5238&st=0&sk=t&sd=a#p84745 EDDF], [http://www.flightgear.org/forums/viewtopic.php?f=5&t=1436&st=0&sk=t&sd=a&start=30#p84800 LFLJ].

==Multiplayer News==
===Atlas Virtual Airlines' leaders recognized!===
[[Atlas Virtual Airlines]], FlightGear's most populated airline, has been a hit success in its inaugural months since opening in mid-April. The airline, however, couldn't have made it without the guidance of its two current leaders: ''MaverickAlex'' (Alex Park) and ''SkyWlf77'' (Jason Sheperd). Besides sinking their own cash into the airline for site domain and software, these two founding members have sorted out many mis-judgements of Atlas and helped to form a strong and community-bonding airline. Jason, the vice-chairman and moderator, helped revamp AVA's standing on the forums and turned many former anti-Atlas-ers into supporting members, which has been very beneficial for the FlightGear multiplayer community. Thanks to him, members can now feel confident to join an airline that was, just months ago, in the midst of intense controversy. Sheperd has taken a strong stand against arguments and flame wars on the Forums, intent on preventing the locked-topics and arguing members that degraded the VA Community during the VA "Dark Ages". But now, Atlas has flourished into a friendship-filled and happy organization that members find enjoyment and fun in.

Meanwhile, Alex, the current chairman and administrator, independently designed an awesome and top-of-the-line VA website for Atlas pilots. He has also worked with nightmares of coding to get drawing-board ideas implemented. And on top of it all, Alex is finishing up his Bombardier Dash-8 400Q, designed especially for Atlas Express flights. This very nicely modeled aircraft will also be available to the public, underlining how Atlas Virtual Airlines is really benefiting all of FlightGear. Alex is the brains behind it all that makes Atlas so sophisticated. His partner, Jason, has the ideas and people-person skills that gives Atlas the openness and fun that attracts its 50-plus members. So, from all of Atlas and those who follow it, thank you, Jason and Alex!

BRIEFS: Atlas celebrated its 50th member this month, a landmark achievement for a VA that is still newborn!

==Aircraft Review==
'''This month: B-25 Mitchell'''

[[Image:B-25.jpg|thumb|270px|A B-25 in the air near KATL]]
The [[B-25]] served in almost every theater in World War II. From Europe to the Pacific, the Mitchell was there. One of the most famous missions accomplished by B-25s was the Doolittle Raid on Tokyo, when a group of 16 B-25s attacked the Japanese mainland, raising morale in the United States, and changing the priorities of the Imperial Japanese Navy, and possibly changing the direction of the war.

The flightgear model looks good on the outside. The author has done a lot of work on the textures, and this is improved even more by some excellent liveries made by Gooneybird that have been added to the B-25 base package by the author. The landing gear, engines and canopies are all carefully modeled, too.

The Cockpit is a little bit threadbare, with no chairs, two pilot figures, and the standard six instruments, which is more than enough to fly with. The only other issue I could come up with was the lack of weapons, but that is only an aesthetic problem. The B-25 handles nicely both on the ground and in the air. I can't talk about accuracy, however, as I have never flown in a B-25, so I don't know how it 'feels' in the air.

The Mitchell sounds great, too!

''Review by Armchair Ace''

==From the community==
===LinuxTAG===
Once again, a team of FlightGear enthusiasts operated a booth during the four days of this year's [http://www.linuxtag.org/ LinuxTAG], the most important place for Linux and open source software in Europe. Besides to it's main purpose of presenting FlightGear to a public audience, LinuxTag becomes more and more '''the''' place for a meeting of core FlightGear developers and users. A technical discussion between James, Alex and Matthias has the potential to become a ''FlightGear legend'' and will probably lead to a multithreaded processing within the simulator's core. Alex also held a public presentation about the integration of [http://www.linuxtag.org/2010/en/program/free-conference/all-events/details.html?talkid=329 "Android for pilots"] with fgfs. [http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Alex%20Perry%20-%20Android%20for%20Pilots%20-%20Integration%20with%20the%20FlightGear%20Flight%20Simulator.pdf]

An exciting first contact was initiated between FlightGear team members and a hardware vendor resulting in an idea to operate a shared presentation of powerful hardware running a powerful flight simulator at the next year's LinuxTAG - to proof the claim "where .com meets .org".

===FlightGear on YouTube===
* ''edubletooth'' captured a [http://www.youtube.com/watch?v=EeQUfnHLs_Q bunch of landings] at the airports with the world's most famous approach: [[Princess Juliana International Airport|Princess Juliana]] in the Netherlands Antilles. Make sure to bend when a 777-200 or maybe even a mighty [[Boeing 747|747]] is passing just meters over your head!
* [http://www.youtube.com/watch?v=nzCcqtkTUT8 This excellent video] proves that ''Howto'' Oscar (we already mentioned him last month) does more than creating howtos. Together with Don's extremely detailed simulation of Gatwick Airport (EGKK), Oscar's video angles make this an interesting and pleasant video to watch.

==And finally...==
===Your own Copilot===
How about having your own Copilot to help you fly your heavy metal? Imagine: You're at 3000 ft making a hand controlled descent to EGKK 26L in your [[Boeing 777-200|777-200ER]]: "flaps down"; check airspeed and altitude; you're now five miles out; "undercarriage down"; reduce speed a little more; "flaps down"; you seem to be slightly overspeed; "spoilers"; touch down "brakes" then "reverse thrust"; "flaps retract"; now take a look at the detailed scenery while taxiing to your stand; "view" and "zoom out".

Those using Windows can employ '''Shoot''' - a free user-editable voice command utility. This may be used concurrently with FlightGear to recognize spoken words or phrases and carry out keyboard actions - including sequential or Shift/Alt/Ctrl... keying. Unfortunately Linux users do not have access to such a powerful utility.

[http://clans.gameclubcentral.com/shoot Download Shoot 1.6.4] and install it on your PC. You also need the Microsoft Speech API (SAPI) which is also free; the link is given on the Shoot website. The free Microsoft .NET should also be installed using the Shoot link.

Shoot may be edited to obey verbal commands such as "start engines", "maximum thrust", "undercarriage up", "flaps retract", "trim nose down", "deploy spoilers", "reverse thrust", "view exterior" - or whatever you choose. Try it and add more immersion to your flying.

===Did you know?===

* ...that FlightGear is made of roughly 3,000,000 lines of code and would cost more than $42,000,000 if created from scratch? <small>(Metrics from [http://www.ohloh.net/p/flightgear/analyses/latest ohloh.net])</small>

* ...that in version 2.0, fellow pilots' chat messages could be ignored on [[multiplayer]] by checking the ignore box in the pilot list?
For upcoming releases, pilots' aircraft will also be able to be ignored. This is part of a strong offensive against "trolling" that disrupts MP flying.<br>

* ...that the USS Nimitz [[Howto: Carrier|aircraft carrier]] has deck elevators that can be lowered/raised to go below deck?
Toggle them up/down in your ATC Options menu under Carrier; Check-Apply raises them, unchecked-apply lowers them.

[[Category:FlightGear Newsletter|2010 06]]

Portal:Developer

2010-06-28T13:02:44Z

MILSTD: adding link to Hudson build server article

{{PortalMenu}}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:100%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="1" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">The Developer Portal</h2>
|-
|style="color:#000;"|
This portal is for developers contributing to FlightGear. If you want to help with FlightGears development, it's a good idea to subscribe yourself to the [http://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear devel] mailing list. The [http://sourceforge.net/mailarchive/forum.php?forum_name=flightgear-devel list archive] is also available and should be searched before posting the same question.<br><br>
'''Please choose a sub-portal:'''
* [[Portal:Developer/3D Modelers|3D Modelers]]
* [[Portal:Developer/Aircraft|Aircraft]]
* [[Portal:Developer/Scenery|Scenery]]<br><br>
'''The FlightGear project is looking for organizations/individuals who would be willing to help sponsor a fulltime project coordinator/manager to help oversee the overall development process If you are interested in helping or have anything else to contribute to this issue, please subscribe to the the [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11813.html FlightGear Devel mailing list] to discuss details.''' (Note that the FlightGear project can apply for free funding/sponsoring with [http://www.nlnet.nl nlnet]-applications are to be sent [http://www.nlnet.nl/foundation/request/index.html here]-you can help prepare a template for applying: [[Funding Application]])
|}
|}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Current Events, Efforts/Branches & Work in Progress</h2>
|-
|style="color:#000;"|
*[[FlightGear Package Manager]] (New! Alpha release of [[Java]]/[[XML]] package manager!)
*[[Walk View‎]] (New! walk view code!)
*[[FlightGear Contest]]
'''[[Work in progress|More...]]'''

|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Latest Organizational Issues</h2>
|-
|style="color:#000;"|
* [[ FlightGear Build Server ]]
* [[ Project Infrastructure Enhancements ]]
* [[ Source Code Management Issues ]]
* [[Google Summer of Code Candidate Projects]] - application template to allow community members to prepare a possible application to decrease the effort required to actually apply
* [[Programming Resources]]
* [[ Tools of the Trade ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">FlightGear Issues</h2>
|-
|style="color:#000;"|
* [[Pending Patches]] (2 listed for the moment)
* [[Segfaults]] - Reproducible Critical Bugs in FlightGear
* [[Showstoppers]] - Annoying Issues in FlightGear
* [[FlightGear Glitches]] (graphical/scenery related glitches)
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Improvement Initiatives</h2>
|-
|style="color:#000;"|
* [[Improving Helicopter Realism]]
* [[Improving Glider Realism]]
* [[Usability Improvements]] (list of related feature requests)
* [[Proposals:Eye_Candy_related|Eye Candy & Effects]] (list of related feature requests)
'''[[:Category:Code_Cleanup|More...]]'''

|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Compiling</h2>
|-
|style="color:#000;"|
* [[ Building FlightGear - Linux]]
* [http://macflightgear.sourceforge.net/home/documents/how-to-build-flightgear-cvs-on-mac-os-x/ Building FlightGear - Mac OS X]
* [[ Building FlightGear - Windows]]
* [[ Building FlightGear Launch Control ]]
* [[ Building Terragear ]]
* [[ Building_terragear-cs_in_Ubuntu_64|Building Terragear in Ubuntu]]
* [[ Updating FlightGear on Windows]]
* [[ OpenSceneGraph ]]
* [[ Using TortoiseCVS with FlightGear ]]
* [[ FlightGear and Git ]]
* [[ FlightGear Package Manager ]]

|-
|}

|class="MainPageBG" style="width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Contributing</h2>
|-
|style="color:#000;"|
* [[Howto:Extending Nasal]]
* [[Howto:Creating new Subsystems]]
* [[Howto:Working with the Property Tree API]]
* [[ Code Cleanup ]]
* [[ Contributor Repositories ]] mirrors, branches and forks privately maintained by contributors
* [[ Submitting Patches ]]
* [[ Technical Reports ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Code Internals</h2>
|-
|style="color:#000;"|
* [[Command Parameters]]
* [[ File Formats ]]
* [[ Initialization Sequence ]]
* [[ Nasal scripting language ]]
* [[ Property Tree ]]
* [[ UML Diagrams ]]
* [[ YASim ]]
* [[ FlightGear 1.0 aircraft names for command line‎|1.0.0 a/c names for command line]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Todo</h2>
|-
|style="color:#000;"|
* [[ Bugs ]]
* [[ Feature Requests / Proposals / Ideas ]]
* [[ FGFS Todo ]]
* [[ FlightGear Expo Checklist ]]
* [[ Long Term Goals ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Done</h2>
|-
|style="color:#000;"|
* [[ Changes since 0.9.10 ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">HowTos</h2>
|-
|style="color:#000;"|

* [[Howto: Set up a multiplayer server|Set up a multiplayer server]]
'''[[:Category:Howto|More...]]'''
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Nasal scripting</h2>
|-
|style="color:#000;"|
* [[ Nasal FAQ ]]
* [[ Nasal scripting language ]]
* [[ Nasal Snippets ]]
* [[ Nasal Modules ]]
* [[ Nasal Style Guide ]]
* [[ Writing simple scripts in %22nasal%22 ]]
* [[ Walk View‎]]
* [[Howto: Nasal in scenery object XML files]]
* [[Howto:Extending Nasal]]
|}
|}

__NOTOC__
__NOEDITSECTION__

== Developer Documentation ==
=== RFC Topics ===
'''Clarification:''' In its current form, the RFC section is exclusively based on and covered by previous mailing list and forum discussions (as well as various wiki entries), as such it is not supposed to reflect work in progress (RFC="Request For Comments" and not WIP), but is rather to be seen as an attempt to provide comprehensive analyses and summaries of key issues identified in various FlightGear related discussions and feature requests (which are to be linked to in the corresponding resource sections, if that didn't yet take place, it's because of most of these RFCs being indeed WIP).

Thus, RFC entries are not meant to imply anyone "working" on any of these issues, in fact only because an RFC entry is listed here doesn't necessarily mean that work on that particular issue is prioritized or generally endorsed by the FlightGear community.
These RFC documents are however intended to hopefully help increase and maintain awareness of long-standing issues and challenges affecting FlightGear's evolution and overall development progress in order to solicit community feedback about possible approaches to address these in an efficient and structured fashion.
Anybody is welcome to comment on, help refine and develop new strategies to tackle the challenges presented in these and future RFCs.

* [[A local weather system]] - improving the FlightGear weather system to make it more configurable and feature rich
* [[Autopilot Enhancements]] - enhancing the autopilot infrastructure.
* [[Backwards Compatibility Initiative]] - discussing possible ways to improve FlightGear's backwards compatibility.
* [[Canvas Properties]] - discussing ways to add a 2D drawing API to FlightGear that is property driven
* [[CDI instrument]] - collection of information relating to creating a formal CDI instrument in FG
* [[Decoupling the AI Traffic System]] - discussing possible ways to decouple the AI traffic system from FlightGear in order to improve overall performance and synchronize AI state across multiplayer clients
* [[Distributed Interactive Simulation|Multiplayer Enhancements]] - discussing possible steps to enhance FlightGear's Multiplayer support.
* [[Modularizing, parallelizing and distributing FlightGear]] - splitting fgfs into distinct components that are to be run as separate processes using the property tree for IPC purposes in order to leverage SMP platforms and distribution/remoting to help FlightGear become more scalable.
* [[FDM engine feature standardization]] - discussing possible steps to standardize feature support of mainstream FlightGear FDM engines.
* [[FlightGear Glass Cockpits]] - discussing required infrastructure changes to enable non-developers to easily access FlightGear-internals in order to enable them to model complex glass cockpit-type aircraft instrumentation systems.
* [[FlightGear Headless]] - discussing required steps to enable FlightGear to be used as its own regression testing framework
* [[FlightGear Sessions]] - discussing possible steps to finally allow aircraft to be reliably switched at runtime.
* [[OpenGL GUI RESOURCES|Potential alternatives to Plib's PUI library]] - collection of cross-platform GUI libraries that work with OpenGL
* [[Formalizing Aircraft Status]] - discussing suggestions about how to more properly describe aircraft development status.
* [[Keyboard function priority list]] - reorganizing FlightGear keybindings.
* [[Next Generation Scenery ]] - revamping the FG scenery engine.
* [[Property Tree Reorganization]] - reorganizing the property tree (i.e. implementing and enforcing existing property/node naming conventions).
* [[Recommended Property Tree Enhancements]] - discussing possible property tree enhancements to help ensure integrity of crucial runtime state.
* [[Recommended Project Policies]] - discussing recommended policies for future contributions to the project.
* [[Remote Properties]] - introduces a small but powerful extension to the property tree in order to allow properties to be maintained in a different (remote) instance of a property tree, that is transparently accessed using a network socket.
* [[Simplifying Aircraft Deployment]] - identifying potential steps to simplify deployment of FlightGear aircraft.

[[es:Portal:Desarrollo]]

Advanced weather

2010-06-08T21:54:57Z

MILSTD: /* Feature requests on the C++ side */ adding link to related discussion from flightgear forums

Status: May. 2010

The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.

When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.

A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for Flightgear could be created using mainly existing technology and code.

== Scales for weather phenomena ==

Real weather phenomena are determined by processes occurring at vastly different size scales. At the large end of the scale is the system of low and high pressure regions and fronts between cold and warm air masses, which have spatial size scales of O(1000) km. At the other end of the scale are very localized phenomena, for instance a dark tarmac surface heated by sunlight acting as the source point of a thermal updraft resulting in a Cumulus cloud. Both size scales are relevant for the Flightgear experience - an airliner on a longhaul flight is able to observe large-scale weather fronts from above, whereas a glider pilot needs a reasonable simulation of local updrafts and sinks tied to terrain features in a credible way for a realistic flight experience. A local weather system therefore needs to

* simulate weather phenomena at different scales
* ideally work offline as well as online
* allow modification by the user on various scales
* be reasonably fast to run in real-time

The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) physically accurate description of processes in the atmosphere, but needs to be a credible mockup of such a description in which heuristic rules replace simulation.

To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the Flightgear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the ruleset determines how realistic the weather system will appear).

In the following, the technology for such a local weather system needed at the relevant scales is outlined - first for the situation offline, followed by ideas how it could be connected with the METAR system in online use.

=== Small scale - effect volumes and average conditions ===

To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active.

The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The Flightgear AI system already has examples of structures which in essence are EVs - <b>thermal</b> and <b>thunderstorm</b>. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system <b>weather</b> in which essentially all weather parameters inside the volume could be set by XML tags.

On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the Flightgear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models).

Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.

EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.

=== Mid scale - weather tiles ===

Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models.

As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front.

Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warmfront', 'trailing edge of warmfront', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by chosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).

The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warmfront' tile could for example have the rules

* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft
* make sure the models are spaced sufficiently far apart
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft
(...)

The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles.

Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.

<center>
[[File:Clouds-coldfront02.jpg|400px]]
</center>

=== Large scale - tile placement rules ===

To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.

If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.

Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.

== Connection with the METAR system ==

Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:

* selection of tile type
* placement of EVs and models inside the tile
* continuously varying weather parameters

=== Selection of tile type ===

If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.

=== Placement of EVs and models inside the tile ===

At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).

=== METAR and continuously varying weather parameters ===

If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).

To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure <i>p</i> is known at <i>n</i> positions, such that the pressure at position <i>i</i> is <i>p_i</i> and the distance between aircraft and <i>i</i> is <i>d_i</i>, then a good approximation of the local pressure is

p = (sum p_i (1/d_i)) / (sum 1/d_i)

as this will make the pressure at position <i>i</i> equal to <i>p_i</i> and lead to the average of the individual pressures if the distance to all METAR stations is the same.

== Related Discussions ==
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms] (06/2010)
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010)
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)

== Connection with the Multiplayer system ==

(should be written by someone who knows what the Multiplayer system can and cannot do)

== Feature requests on the C++ side ==

Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms discussion] from 06/2010.

To aid current development, a few features would be nice to have from the C++ side for good performance of the code:

* cloud transformations: Two view-axis based model transformation routines are available with an xml animation tag with the billboard animation. The problem is that neither of those is very useful for cloud models. It would probably help a lot in terms of performance to have more transformations available which are more suitable for cloud models: 1) one-axis position vector based rotation (yaw) 2) two-axis position vector based rotation which does not roll the model (yaw and pitch). Each of those should optionally support the specification of ranges (i.e. pitch only between -20 and +20 deg) and also a minimal distance beyond which the model is not rotated any more. 3) and 4) one and two axis position vector based rotations as above which blend at small distance into view-axis based rotations (these are computationally more expensive, but appear more realistic at small distances). Possibly even more transformations.

=> this can be done inside the shader code very conveniently, so there is probably no need to C++ it after all

* weather properties: Make visibility, wind direction, windspeed, turbulence, thermal lift, pressure, temperature and humidity in an easy way writable from Nasal. Most (except thermal lift) are currently indirectly writable by writing the config and calling environment reinit, but that's not a good solution.

* terrain elevation: For thermal convection and barrier clouds, rapid sampling of terrain elevation is needed. Can there be a way to rapidly receive terrain elevation info only in Nasal for a whole set of pre-specified coordinates which performs better than geoinfo() calls?

* terrain exposure to sun: Again, for thermal convection, a frequent problem involving lots of trigonometry would be - given a coordinate, find a 100 m x 100 m square area around that point. Find the orientation of that area in space (i.e. compute its normal). Given the time and date as input, compute the position of the sun, and based on surface normal and sun angle, compute the amount of thermal energy flux through the surface compared to the maximal one (i.e. when the sun is directly overhead flat terrain, surface normal || sun angle). So, a function f(coordinates, time, date) which returns a number between 0 (no sun exposure, e.g. during night) and 1 (maximal sun exposure). Computing this in Nasal a few 1000 times might be unreasonably expensive...

== Current development status ==

The current version 0.6 supports placement of effect volumes for visibility, rain, snow and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, external models of precipitation and (with a CVS patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a rudimentary set of tile selection rules to simulate the long-range change of real weather. As an example, the picture shows Nimbostratus clouds with precipitation seen from outside.

<center>
[[File:Clouds-nimbostratus.jpg|400px]]
</center>

[http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.61.tgz Local Weather package v0.6(Thorsten)]

[http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]

Advanced weather

2010-06-08T21:53:12Z

MILSTD: /* Related Discussions */ Updating section with latest discussions from FlightGear forums

Status: May. 2010

The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.

When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.

A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for Flightgear could be created using mainly existing technology and code.

== Scales for weather phenomena ==

Real weather phenomena are determined by processes occurring at vastly different size scales. At the large end of the scale is the system of low and high pressure regions and fronts between cold and warm air masses, which have spatial size scales of O(1000) km. At the other end of the scale are very localized phenomena, for instance a dark tarmac surface heated by sunlight acting as the source point of a thermal updraft resulting in a Cumulus cloud. Both size scales are relevant for the Flightgear experience - an airliner on a longhaul flight is able to observe large-scale weather fronts from above, whereas a glider pilot needs a reasonable simulation of local updrafts and sinks tied to terrain features in a credible way for a realistic flight experience. A local weather system therefore needs to

* simulate weather phenomena at different scales
* ideally work offline as well as online
* allow modification by the user on various scales
* be reasonably fast to run in real-time

The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) physically accurate description of processes in the atmosphere, but needs to be a credible mockup of such a description in which heuristic rules replace simulation.

To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the Flightgear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the ruleset determines how realistic the weather system will appear).

In the following, the technology for such a local weather system needed at the relevant scales is outlined - first for the situation offline, followed by ideas how it could be connected with the METAR system in online use.

=== Small scale - effect volumes and average conditions ===

To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active.

The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The Flightgear AI system already has examples of structures which in essence are EVs - <b>thermal</b> and <b>thunderstorm</b>. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system <b>weather</b> in which essentially all weather parameters inside the volume could be set by XML tags.

On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the Flightgear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models).

Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.

EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.

=== Mid scale - weather tiles ===

Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models.

As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front.

Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warmfront', 'trailing edge of warmfront', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by chosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).

The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warmfront' tile could for example have the rules

* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft
* make sure the models are spaced sufficiently far apart
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft
(...)

The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles.

Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.

<center>
[[File:Clouds-coldfront02.jpg|400px]]
</center>

=== Large scale - tile placement rules ===

To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.

If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.

Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.

== Connection with the METAR system ==

Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:

* selection of tile type
* placement of EVs and models inside the tile
* continuously varying weather parameters

=== Selection of tile type ===

If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.

=== Placement of EVs and models inside the tile ===

At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).

=== METAR and continuously varying weather parameters ===

If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).

To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure <i>p</i> is known at <i>n</i> positions, such that the pressure at position <i>i</i> is <i>p_i</i> and the distance between aircraft and <i>i</i> is <i>d_i</i>, then a good approximation of the local pressure is

p = (sum p_i (1/d_i)) / (sum 1/d_i)

as this will make the pressure at position <i>i</i> equal to <i>p_i</i> and lead to the average of the individual pressures if the distance to all METAR stations is the same.

== Related Discussions ==
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms] (06/2010)
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010)
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)

== Connection with the Multiplayer system ==

(should be written by someone who knows what the Multiplayer system can and cannot do)

== Feature requests on the C++ side ==

To aid current development, a few features would be nice to have from the C++ side for good performance of the code:

* cloud transformations: Two view-axis based model transformation routines are available with an xml animation tag with the billboard animation. The problem is that neither of those is very useful for cloud models. It would probably help a lot in terms of performance to have more transformations available which are more suitable for cloud models: 1) one-axis position vector based rotation (yaw) 2) two-axis position vector based rotation which does not roll the model (yaw and pitch). Each of those should optionally support the specification of ranges (i.e. pitch only between -20 and +20 deg) and also a minimal distance beyond which the model is not rotated any more. 3) and 4) one and two axis position vector based rotations as above which blend at small distance into view-axis based rotations (these are computationally more expensive, but appear more realistic at small distances). Possibly even more transformations.

=> this can be done inside the shader code very conveniently, so there is probably no need to C++ it after all

* weather properties: Make visibility, wind direction, windspeed, turbulence, thermal lift, pressure, temperature and humidity in an easy way writable from Nasal. Most (except thermal lift) are currently indirectly writable by writing the config and calling environment reinit, but that's not a good solution.

* terrain elevation: For thermal convection and barrier clouds, rapid sampling of terrain elevation is needed. Can there be a way to rapidly receive terrain elevation info only in Nasal for a whole set of pre-specified coordinates which performs better than geoinfo() calls?

* terrain exposure to sun: Again, for thermal convection, a frequent problem involving lots of trigonometry would be - given a coordinate, find a 100 m x 100 m square area around that point. Find the orientation of that area in space (i.e. compute its normal). Given the time and date as input, compute the position of the sun, and based on surface normal and sun angle, compute the amount of thermal energy flux through the surface compared to the maximal one (i.e. when the sun is directly overhead flat terrain, surface normal || sun angle). So, a function f(coordinates, time, date) which returns a number between 0 (no sun exposure, e.g. during night) and 1 (maximal sun exposure). Computing this in Nasal a few 1000 times might be unreasonably expensive...

== Current development status ==

The current version 0.6 supports placement of effect volumes for visibility, rain, snow and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, external models of precipitation and (with a CVS patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a rudimentary set of tile selection rules to simulate the long-range change of real weather. As an example, the picture shows Nimbostratus clouds with precipitation seen from outside.

<center>
[[File:Clouds-nimbostratus.jpg|400px]]
</center>

[http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.61.tgz Local Weather package v0.6(Thorsten)]

[http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]

Improving Glider Realism

2010-06-08T21:46:13Z

MILSTD: adding link to A local weather system and updating TE vario section due to availability of a TE compensated vario in FG/HEAD (git)

[http://www.flightgear.org FG Home] >> [[Main Page | Wiki]] >> [[Portal:Developer |Development portal]] >> Improving Glider Realism

This section lists the areas that have a significant impact on soaring realism. This wiki has additional relevant information in the [[Soaring]] area.

Note that as of 06/2010, weather modeling is under active development: [[A local weather system]] - for additional details you may want to check back with the flightgear forums or mailing lists.

Other open source simulators that provide support for simulating gliders, and that may be useful when improving FlightGear's support for gliding, include:

* http://sourceforge.net/projects/slopesoaringsim/ (GPL)
* http://sourceforge.net/projects/zsim/ (OSG based)
* http://sourceforge.net/projects/glider3d/

== Gliders ==

This section reviews the design issues affecting the user aircraft.

=== Flight Model ===

Of course, gliders need a custom-designed flight model.

=== Glider external 3D models ===

This is the best understood bit of glider simulation... designing a decent 3D model. You can tell if it's any good just by looking at it, although performance plays a part too. For the current FG glider state of the art, here's the ASK21:

[[Image:Ask21 external2.jpg|500px]]

=== Glider cockpit 3D models ===

Less well understood, but still not rocket science, gliders need a good 3d model for the cockpit with the panel and the various levers (joystick, flaps, airbrakes, water ballast, landing gear). The current (April 2009) panels are displayed below - functional but a bit sparse compared to real gliders:

==== ASK 21 Panel ====
[[Image:Ask 21 cockpit.jpg|500px]]

==== DG300 Panel ====
[[Image:DG-300-Cockpit.jpg|500px]]

==== FSX Comparison ====

The (upcoming) Aerosoft Discus sets the high ground for glider cockpit and panel modelling. To see how high the bar has been raised [http://www.specific-3d-design.de/resources/Discus%20Panel.jpg see here]

=== Gauges ===

Unfortunately it is not possible to create a decent glider by simply copying across existing instruments from a power aircraft. The minimum instrument set is an altimeter, air speed indicator, and variometer. The variometer (vario) is unique to soaring.

Glider instruments are generally 80mm or 57mm in diameter. This standardisation makes it easier to add/remove/move instruments in the panel.

The mandatory instruments are the altimeter and the air speed indicator. These two and the main variometer are generally 80mm diameter instruments. The panel often includes a 'flight computer' with a digital display showing a variety of flight parameters which also takes up an 80mm 'hole' on the panel. The flight computer often drives a separate 'slave' variometer often in a 57mm hole.

==== Variometer ====

At its simplest, a variometer is a rate of climb indicator. However, this pure (uncompensated) indication of vertical speed is very poor for climbing effectively in thermals as the effect of the vertical movement of the air is swamped by the pilot's actions with the control column (so called 'stick thermals'). Since the 1930's, real gliding variometers have used some method to compensate for the climb rate induced by the pilot pushing or pulling on the control column.

It is ''common'' for a glider panel to have more than one variometer - the largest (80mm) analogue dial may be displaying Total Energy compensated climb rate (see immediately below) while a smaller dial connected to the flight computer may be displaying Netto or speed-to-fly.

* ''Total energy compensation''. If the glider is climbing, a factor can be subtracted from the indicated lift if the glider is decelerating, and the reverse during descent. So if the glider is neither accelerating or decelerating the absolute rate of climb (or sink) will be shown.
** Potential energy = mass x G x height (or height = energy / (mass x G))
** Kinetic energy = 0.5 x mass x velocity squared
** if in time period 't' the glider goes from height 'h1'..'h2' and speed 'v1'..'v2':
** uncompensated vario reading = (h2-h1)/t
** TE adjustment = height the glider would have gained if it hadn't accelerated / time
** = (change in kinetic energy / (mass x G))/t
** = ((0.5 * mass * v2^2 - 0.5 * mass * v1^2) / (mass x G)) / t
** = (v2^2 - v1^2) / 2Gt where G = 9.81 meters per second per second
** TE reading = uncompensated reading + TE adjustment
** '''TE reading = (h2-h1)/t + (v2^2 - v1^2) / (19.62*t)'''
** (all units meters, seconds, meters per second)

* ''Netto compensation''. The design sink rate of the glider at the current airspeed is added to the total energy vario reading, so the variometer actually displays the vertical rate of the air outside the glider. For a perfectly compensated instrument, the vario will show zero in still air regardless of the airspeed of the aircraft

* ''Speed-to-fly'' display. Generally in a glider, if the variometer needle moves negative you assume sinking air and ''speed up''. Or if the vario needle indicates lift you ''slow up'' and if the lift is good enough you pull up into a turn. So for cruising flight you continually speed up and slow down according to what the vario is doing - this is called ''dolphin flying'' and is a particularly efficient way of flying cross-country, giving you more time in lift (because you slow down) and less time in sink (because you speed up). But what is the optimum speed to fly in any given rising or sinking air? To take out the guesswork, some electronic variometers (those slaved from a flight computer) are configured to read in the lift/sink value but indicate ''positive if you should slow down'', and ''negative if you should speed up''. To an uninitiated observer, the gauge looks like an ordinary variometer - even though the computation being performed is more complex, the needle moves up (slow down) and down (speed up) in a natural way, just like an 'ordinary' vario.

In order of complexity, the uncompensated 'rate of climb' vario is the simplest but less useful, the TE vario is still pretty simple but a ''lot'' more useful, the Netto vario is a fair bit more complex requiring the gauge to know the glide performance of the glider at every speed and ballast load, and the speed-to-fly vario is fairly complex to code as it has to know the Netto stuff plus tables for the optimum speed to fly at different ballast settings and external lift/sink rates.

Please Note that as of 06/2010 there is now a TE compensated variometer available in FlightGear HEAD: [http://gitorious.com/fg/fgdata/trees/master/Aircraft/Instruments-3d/glider/vario/ilec-sc7 $FG_ROOT/Aircraft/Instruments-3d/glider/vario/ilec-sc7]. It has been implemented for the [http://gitorious.com/fg/fgdata/trees/master/Aircraft/ASK13 ASK13 glider].

People interested in adding this instrument to other gliders, will want to refer to the [http://gitorious.com/fg/fgdata/blobs/master/Aircraft/Instruments-3d/glider/vario/ilec-sc7/README_install README_install file].

Also see:

* http://en.wikipedia.org/wiki/Variometer#Total_Energy_Compensation
* http://soaringlab.blogspot.com/2009/11/total-energy-compensation-explained.html
* http://soaringlab.blogspot.com/2009/11/total-energy-compensation-explained_08.html
* http://www.auf.asn.au/groundschool/variometer.html
* http://www.lsc-schliersee.de/Ausbildung/Streckenfliegen/Dateien/TE-Vario_in_the_Flowfield_of_Thermals.pdf
* http://www.hkavionics.com/Bohli_man/ba_vario1e.pdf
* http://www.borgeltinstruments.com/Gusts.pdf

==== Flight Computer ====

These electronic instruments primarily drive slave variometers of various types (see above) and compute your ''arrival height'' at the next waypoint or final destination (for which they are generally connected to a GPS). The screenshot below is taken from the Aerosoft Discus for FSX - this flight computer is the most complex gauge ever created for FSX, containing 3500 lines of code to perform computations then displayed through the simple interface, i.e. the slave variometer needle (top left), the 'petal' variometer needle on the display itself, and the digital numeric displays. The other analogue gauges (ASI, TE vario, engine tachometer) are not connected to the flight computer. An open source implementation of a "gliding computer" is available in the form of [http://www.xcsoar.org/ XCSoar] for Pocket PCs.

[[Image:Glider flight computer.jpg]]

==== IGC file logger ====

To compare flights with others, it helps to have a log of your flight in the 'IGC format'. This is a text file with an agreed format, with some header rows and then one-row-per-timestamp for the lat/long/alt.

The specification for the IGC format log file is available [http://www.fai.org/gliding/gnss/tech_spec_gnss.asp on the FAI website].

The full specification has become unbelievably tortuous, but most of the records are optional and an example of a working file would be:

AXXXb21_sim_probe 2.55
HFDTE070608
HFFXA035
HFPLTPILOTINCHARGE: not recorded
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:DG
HFGIDGLIDERID:B21
HFDTM100GPSDATUM: WGS-1984
HFRFWFIRMWAREVERSION: 2.55
HFRHWHARDWAREVERSION: 2008
HFFTYFRTYPE: sim_probe by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator
HFCIDCOMPETITIONID:B21
HFCCLCOMPETITIONCLASS:Microsoft Flight Simulator
I013638FXA
B1658174040958N07737022WA0094000940000
B1658214040875N07737069WA0095200952000
B1658254040811N07737136WA0095300953000
... and more B records for the rest of the file
G123456789

IGC files can be uploaded to [http://www.everytrail.com/view_trip.php?trip_id=162108 everytrail.com] or can be converted by [http://www.gpsvisualizer.com/map_input?form=googleearth gpsvisualizer.com] for viewing in Google Earth.
Also, there's an open source tool available, named [http://sourceforge.net/projects/gpligc/ "gpligc"].

== Enviroment lift modelling ==

This section reviews the requirements for the environment modelling, in particular the simulation of the vertical component of air movement on which gliders depend for soaring flight.

=== Thermals ===

=== Ridgelift ===

A paper on the efficient calculation of ridge lift is available [http://carrier.csi.cam.ac.uk/forsterlewis/soaring/sim/fsx/dev/sim_probe/sim_probe_paper.html from Ian Forster-Lewis].
This is now implemented in CVS. Ridge lift is enabled by default but may be disabled by using
--prop:/environment/ridge-lift/enabled=0
on the command line or by setting this property at runtime.

The FlightGear issues are also discussed in [http://www.flightgear.org/forums/viewtopic.php?f=6&t=3377 this forum thread]

=== Wave ===

== Multiplayer ==

Solo soaring is all about admiring the scenery, and multiplayer soaring is predominantly about comparing times to complete the same cross-country task.

User talk:Fadimo305

2010-06-08T17:26:43Z

MILSTD: 1 MB+ image upload in bitmap format

Hey,

thanks for your wiki edits! Writing info down and uploading screenshots is really appreciated! However, a couple of things that I would like to let you know:
* copying large paragraphs from Wikipedia (like you did on the [[IL-96-400 Long Ranger(T)]] article) is not the goal of this wiki. Just a couple of lines about the aircraft will do. In addition to that you can provide a link to the Wikipedia article, in case someone enjoys reading more about the aircraft. The rest of the FG-wiki article can then concentrate on the aircraft in FlightGear.
* please upload images with descriptive filenames. I cannot track [[:File:1z5hr43.bmp|1z5hr43.bmp]] down to the aircraft that I see in the picture for example. Something like Il-96_jet_airways.bmp would be much more descriptive.
* the author cell in the [[:Template:Infobox Aircraft|aircraft infobox]] is meant to list the authors of the FG-aircraft, not the wiki-article author ;)

Don't take this personal, just some tips to keep the wiki clean and informative. It would be nice if you could keep these things in mind with futher edits.

Thanks!
Regards,

[[User:Gijs|Gijs]] 15:58, 8 June 2010 (UTC)

= 06/2010: Image uploads =
And while you are at it, please try to refrain from uploading images in bitmap format, there are more suitable image formats, which also do not require as much space as bmp files (consider jpg or png for example). If you are on Windows, you can use image conversion programs like XnView or IrfanView to resize and convert bitmap images to other formats. You may also want to check out the GIMP, which is also available for Linux--[[User:MILSTD|MILSTD]] 17:26, 8 June 2010 (UTC)

User talk:Gijs

2010-06-08T17:22:11Z

MILSTD: Your git related edits/deletions

= 06/2010: Your Git related edits/deletions =
Hi, why exactly was the paragraph about Tortoise Git removed from the article, without adding it back to the Windows specific article ([http://wiki.flightgear.org/index.php?title=FlightGear_and_Git&diff=21852&oldid=21848])?
Also please note that the windows article that you linked to, is not any longer just about accessing the Git repositories, but specifically about using these together with pre-compiled binaries in order to obtain an updated version of FlightGear: http://wiki.flightgear.org/index.php/FlightGear_Git_on_Windows
Even though this page was initially meant to become the equivalent of http://flightgear.org/cvs.html?
So the scope of these pages seems either currently somewhat ill-defined or some users are making simply pretty unfortunate edits?
--[[User:MILSTD|MILSTD]] 17:22, 8 June 2010 (UTC)

= Your recent Edits =
Hi,
I noticed that you undid my edit to the helicopter page. Perhaps you should look at this page: [[Special:DoubleRedirects]]
I was trying to correct the DoubleRedirct #4. I assumed this would do it but I was apparently wrong. Perhaps you could take a look at it.
Thanks for your help

[[User:Stepfaw|Stepfaw]] 19:30, 30 September 2009 (UTC)
:Hi Stepfaw,
:I fixed the double redirect for you. Take a look at the Recent changes to see what I did. I really appreciate the fact that you try to keep the double redirects to a minimum. Well done!
:Regards,
:[[User:Gijs|Gijs]] 19:36, 30 September 2009 (UTC)

----
Hi
Thank you for formatting my new article on the Canadian Warplane Heritage Museum. This was my first article and I was having a hard time formating it to look like the others.

Stepfaw

: Hi Stepfaw,
: Thanks a lot for creating the article ;) By creating articles and looking at other articles you'll soon learn how to create even better articles!
: Cheers, [[User:Gijs|Gijs]] 04:15, 19 August 2009 (EDT)
: PS, please sign your messages on talk pages with four tildes (~).

----

Hi!

We've talked about this before, however I would like to ask you now ''clearly'' to '''please''' stop removing boilerplate contents from wiki pages only because they may not yet be sufficiently populated in your opinion (or anyone else's for that matter)!

You are free to remove whatever references to such pages you may consider unnecessary or annoying at this time and add classifying markup, however removing initial contents (structural boilerplate or not) from such pages or possibly removing even complete pages (regardless of whether they contain contents or not) is definitively wrong and could indeed be considered discouraging and hardly constructive.

Please don't get me wrong, as I've said before: your recent wiki contributions are extremely appreciated, however whoever started a page should clearly be considered the "owner" or at least "maintainer" of the page initially, this applies certainly as long as a page must be considered "work in progress".

There is hardly any point in trying to instruct people how to make their contributions as long as they remain self-contained and do not necessarily affect other people. Unreferenced FlightGear-related pages would certainly satisfy these criteria.

Thank you

----
Hi,

I don't know why you're so upset. Since the last time we talked to each other I've removed nothing. I just add some of the pages you (and others) created to the [[:Category:Afd|Article Considered for Deletion category]]. I completely understand your feelings when i've did something that you don't agree with, but please take a closer look before you start telling me what I'm doing wrong. I know I removed some of your category's, but I've removed no pages since the last conversation between us.

The webmaster is the only one who's able to remove pages. Users could only remove content, but that could be reset by any user (including you). With the new category (and corresponding template) we could now consider articles for deletion. The webmaster could remove them if it's not needed or if there's something else wrong. If you're not agree with the (upcoming) deletion of an article in this category you could talk about it at it's talk page. The article may be removed from the category ('''but only by the webmaster!''') when someone has edit it, expand it or make it better etc.

Thanks
[[User:Gijs|Gijs]] 06:03, 9 March 2008 (EDT)

=Citing Wikipedia?=

Hi Giijs,

I saw you used a paragraph from the PBY Catalina Wikipedia entry on the Catalina page here. Normally one should provide the source when quoting like that (I doubt Wikipedia would complain, though). It is better to rewrite the information in your own words. IMHO I also don't find the information about the US military use of the PBY that relevant on our page since the PBY in FlightGear is unarmed, civilian and French.

Cheers,
[[User:AndersG|AndersG]] 10:21, 16 September 2008 (EDT)
: I agree Anders. I will stop copying the information. I thought it would be nice to have some info about the real plane to, but we should write our own as you said. Sorry. [[User:Gijs|Gijs]] 10:59, 16 September 2008 (EDT)

=Contacting you via the forum PM function=
Hey Gijs,

I sent you a PM three days ago about the ground signs. Did you receive it? I just sent another one to test how I can contact you directly. I'm asking because I contacted you via the PM function about one or two months ago and never got an answer either.

Cheers, David [[User:D-79|D-79]] 07:48, 22 August 2009 (EDT)

: Well, I did receive your last PM, but the earlier ones I've never seen. Maybey I should clean up my inbox more often? :)
: [[User:Gijs|Gijs]] 06:20, 23 August 2009 (EDT)

You did receive my last PM, as far as I can see. It's the one with the subject "Test PM" and you answered it.

David [[User:D-79|D-79]] 13:26, 23 August 2009 (EDT)

Talk:Route manager

2010-06-07T22:31:23Z

MILSTD: adding links to problem reports from the flightgear.org forums

= Issues reported on the forums =
* [http://www.flightgear.org/forums/viewtopic.php?f=25&t=8317 Route Manager]
* [http://www.flightgear.org/forums/viewtopic.php?f=25&t=8345 2.0 Route Manager]
* [http://www.flightgear.org/forums/viewtopic.php?f=25&t=8295 Route Manager Issue/Other questions]
* [http://www.flightgear.org/forums/viewtopic.php?f=25&t=8048 Route Manager and AP]

Talk:Redesigning the Replay System

2010-06-07T18:57:16Z

MILSTD: /* Related */

= Related =
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26123.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg12621.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17034.html (serialization)
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19471.html Replay mode improvement suggestion...]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15655.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27849.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg28332.html
* http://flightgear.org/forums/viewtopic.php?f=17&t=2766&p=26459&hilit=generic+protocol#p26459

= Replay Discussions from the forums =
questions, feature requests and suggestions:
* http://flightgear.org/forums/viewtopic.php?f=2&t=6824&p=61025&hilit=replay#p61025
* http://flightgear.org/forums/viewtopic.php?f=4&t=6284&p=53640&hilit=replay#p53640
* http://flightgear.org/forums/viewtopic.php?f=6&t=6328&p=52818&hilit=replay#p52818
* http://flightgear.org/forums/viewtopic.php?f=6&t=6290&p=51907&hilit=replay#p51907
* http://flightgear.org/forums/viewtopic.php?f=2&t=6186&p=49780&hilit=replay#p49780
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=46028&hilit=replay#p46028
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=45947&hilit=replay#p45947
* http://flightgear.org/forums/viewtopic.php?f=4&t=1917&p=45009&hilit=replay#p45009
* http://flightgear.org/forums/viewtopic.php?f=2&t=5400&p=40479&hilit=replay#p40479
* http://flightgear.org/forums/viewtopic.php?f=2&t=4969&p=36949&hilit=replay#p36949
* http://flightgear.org/forums/viewtopic.php?f=2&t=4876&p=36069&hilit=replay#p36069
* http://flightgear.org/forums/viewtopic.php?f=6&t=3085&p=28982&hilit=replay#p28982
* http://flightgear.org/forums/viewtopic.php?f=2&t=2766&p=27109&hilit=replay#p27109
* http://flightgear.org/forums/viewtopic.php?f=2&t=2057&p=15804&hilit=replay#p15804
* http://flightgear.org/forums/viewtopic.php?f=6&t=6875&p=65878&hilit=replay#p65878

= Suggested Approaches =
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17035.html re-implementing replay on top of the generic protocol facility]
* [http://flightgear.org/forums/viewtopic.php?f=2&t=1697&p=12549 Using ARINC 429 for logging flight data]
* from a conceptual point of view, the replay system has the same requirements as the multiplayer system: it has to work with arbitrary aircraft/vehicles and arbitrary combinations of properties (differing among aircraft), thus a subscription based approach is most promising, as it has been frequently suggested and favored in multiplayer related discussions

Portal:Developer

2010-06-07T18:30:53Z

MILSTD:

{{PortalMenu}}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:100%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="1" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">The Developer Portal</h2>
|-
|style="color:#000;"|
This portal is for developers contributing to FlightGear. If you want to help with FlightGears development, it's a good idea to subscribe yourself to the [http://lists.sourceforge.net/lists/listinfo/flightgear-devel FlightGear devel] mailing list. The [http://sourceforge.net/mailarchive/forum.php?forum_name=flightgear-devel list archive] is also available and should be searched before posting the same question.<br><br>
'''Please choose a sub-portal:'''
* [[Portal:Developer/3D Modelers|3D Modelers]]
* [[Portal:Developer/Aircraft|Aircraft]]
* [[Portal:Developer/Scenery|Scenery]]<br><br>
'''The FlightGear project is looking for organizations/individuals who would be willing to help sponsor a fulltime project coordinator/manager to help oversee the overall development process If you are interested in helping or have anything else to contribute to this issue, please subscribe to the the [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11813.html FlightGear Devel mailing list] to discuss details.''' (Note that the FlightGear project can apply for free funding/sponsoring with [http://www.nlnet.nl nlnet]-applications are to be sent [http://www.nlnet.nl/foundation/request/index.html here]-you can help prepare a template for applying: [[Funding Application]])
|}
|}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Current Events, Efforts/Branches & Work in Progress</h2>
|-
|style="color:#000;"|
*[[FlightGear Package Manager]] (New! Alpha release of [[Java]]/[[XML]] package manager!)
*[[Walk View‎]] (New! walk view code!)
*[[FlightGear Contest]]
'''[[Work in progress|More...]]'''

|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Latest Organizational Issues</h2>
|-
|style="color:#000;"|
* [[ Project Infrastructure Enhancements ]]
* [[ Source Code Management Issues ]]
* [[Google Summer of Code Candidate Projects]] - application template to allow community members to prepare a possible application to decrease the effort required to actually apply
* [[Programming Resources]]
* [[ Tools of the Trade ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">FlightGear Issues</h2>
|-
|style="color:#000;"|
* [[Pending Patches]] (2 listed for the moment)
* [[Segfaults]] - Reproducible Critical Bugs in FlightGear
* [[Showstoppers]] - Annoying Issues in FlightGear
* [[FlightGear Glitches]] (graphical/scenery related glitches)
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Improvement Initiatives</h2>
|-
|style="color:#000;"|
* [[Improving Helicopter Realism]]
* [[Improving Glider Realism]]
* [[Usability Improvements]] (list of related feature requests)
* [[Proposals:Eye_Candy_related|Eye Candy & Effects]] (list of related feature requests)
'''[[:Category:Code_Cleanup|More...]]'''

|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Compiling</h2>
|-
|style="color:#000;"|
* [[ Building FlightGear - Linux]]
* [http://macflightgear.sourceforge.net/home/documents/how-to-build-flightgear-cvs-on-mac-os-x/ Building FlightGear - Mac OS X]
* [[ Building FlightGear - Windows]]
* [[ Building FlightGear Launch Control ]]
* [[ Building Terragear ]]
* [[ Building_terragear-cs_in_Ubuntu_64|Building Terragear in Ubuntu]]
* [[ Updating FlightGear on Windows]]
* [[ OpenSceneGraph ]]
* [[ Using TortoiseCVS with FlightGear ]]
* [[ FlightGear and Git ]]
* [[ FlightGear Package Manager ]]

|-
|}

|class="MainPageBG" style="width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Contributing</h2>
|-
|style="color:#000;"|
* [[Howto:Extending Nasal]]
* [[Howto:Creating new Subsystems]]
* [[Howto:Working with the Property Tree API]]
* [[ Code Cleanup ]]
* [[ Contributor Repositories ]] mirrors, branches and forks privately maintained by contributors
* [[ Submitting Patches ]]
* [[ Technical Reports ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Code Internals</h2>
|-
|style="color:#000;"|
* [[Command Parameters]]
* [[ File Formats ]]
* [[ Initialization Sequence ]]
* [[ Nasal scripting language ]]
* [[ Property Tree ]]
* [[ UML Diagrams ]]
* [[ YASim ]]
* [[ FlightGear 1.0 aircraft names for command line‎|1.0.0 a/c names for command line]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Todo</h2>
|-
|style="color:#000;"|
* [[ Bugs ]]
* [[ Feature Requests / Proposals / Ideas ]]
* [[ FGFS Todo ]]
* [[ FlightGear Expo Checklist ]]
* [[ Long Term Goals ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Done</h2>
|-
|style="color:#000;"|
* [[ Changes since 0.9.10 ]]
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">HowTos</h2>
|-
|style="color:#000;"|

* [[Howto: Set up a multiplayer server|Set up a multiplayer server]]
'''[[:Category:Howto|More...]]'''
|-
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Nasal scripting</h2>
|-
|style="color:#000;"|
* [[ Nasal FAQ ]]
* [[ Nasal scripting language ]]
* [[ Nasal Snippets ]]
* [[ Nasal Modules ]]
* [[ Nasal Style Guide ]]
* [[ Writing simple scripts in %22nasal%22 ]]
* [[ Walk View‎]]
* [[Howto: Nasal in scenery object XML files]]
* [[Howto:Extending Nasal]]
|}
|}

__NOTOC__
__NOEDITSECTION__

== Developer Documentation ==
=== RFC Topics ===
'''Clarification:''' In its current form, the RFC section is exclusively based on and covered by previous mailing list and forum discussions (as well as various wiki entries), as such it is not supposed to reflect work in progress (RFC="Request For Comments" and not WIP), but is rather to be seen as an attempt to provide comprehensive analyses and summaries of key issues identified in various FlightGear related discussions and feature requests (which are to be linked to in the corresponding resource sections, if that didn't yet take place, it's because of most of these RFCs being indeed WIP).

Thus, RFC entries are not meant to imply anyone "working" on any of these issues, in fact only because an RFC entry is listed here doesn't necessarily mean that work on that particular issue is prioritized or generally endorsed by the FlightGear community.
These RFC documents are however intended to hopefully help increase and maintain awareness of long-standing issues and challenges affecting FlightGear's evolution and overall development progress in order to solicit community feedback about possible approaches to address these in an efficient and structured fashion.
Anybody is welcome to comment on, help refine and develop new strategies to tackle the challenges presented in these and future RFCs.

* [[A local weather system]] - improving the FlightGear weather system to make it more configurable and feature rich
* [[Autopilot Enhancements]] - enhancing the autopilot infrastructure.
* [[Backwards Compatibility Initiative]] - discussing possible ways to improve FlightGear's backwards compatibility.
* [[Canvas Properties]] - discussing ways to add a 2D drawing API to FlightGear that is property driven
* [[CDI instrument]] - collection of information relating to creating a formal CDI instrument in FG
* [[Decoupling the AI Traffic System]] - discussing possible ways to decouple the AI traffic system from FlightGear in order to improve overall performance and synchronize AI state across multiplayer clients
* [[Distributed Interactive Simulation|Multiplayer Enhancements]] - discussing possible steps to enhance FlightGear's Multiplayer support.
* [[Modularizing, parallelizing and distributing FlightGear]] - splitting fgfs into distinct components that are to be run as separate processes using the property tree for IPC purposes in order to leverage SMP platforms and distribution/remoting to help FlightGear become more scalable.
* [[FDM engine feature standardization]] - discussing possible steps to standardize feature support of mainstream FlightGear FDM engines.
* [[FlightGear Glass Cockpits]] - discussing required infrastructure changes to enable non-developers to easily access FlightGear-internals in order to enable them to model complex glass cockpit-type aircraft instrumentation systems.
* [[FlightGear Headless]] - discussing required steps to enable FlightGear to be used as its own regression testing framework
* [[FlightGear Sessions]] - discussing possible steps to finally allow aircraft to be reliably switched at runtime.
* [[OpenGL GUI RESOURCES|Potential alternatives to Plib's PUI library]] - collection of cross-platform GUI libraries that work with OpenGL
* [[Formalizing Aircraft Status]] - discussing suggestions about how to more properly describe aircraft development status.
* [[Keyboard function priority list]] - reorganizing FlightGear keybindings.
* [[Next Generation Scenery ]] - revamping the FG scenery engine.
* [[Property Tree Reorganization]] - reorganizing the property tree (i.e. implementing and enforcing existing property/node naming conventions).
* [[Recommended Property Tree Enhancements]] - discussing possible property tree enhancements to help ensure integrity of crucial runtime state.
* [[Recommended Project Policies]] - discussing recommended policies for future contributions to the project.
* [[Remote Properties]] - introduces a small but powerful extension to the property tree in order to allow properties to be maintained in a different (remote) instance of a property tree, that is transparently accessed using a network socket.
* [[Simplifying Aircraft Deployment]] - identifying potential steps to simplify deployment of FlightGear aircraft.

[[es:Portal:Desarrollo]]

Howto talk:Adding gun effects

2010-06-07T18:06:48Z

MILSTD: Created page with 'At some point, you may want to move this article to Howto: Add Gun Effects, add a category:howto tag to it and then link to it from the Aircraft/Developers Howto section: htt…'

At some point, you may want to move this article to [[Howto: Add Gun Effects]], add a category:howto tag to it and then link to it from the Aircraft/Developers Howto section: http://wiki.flightgear.org/index.php/Portal:Developer/Aircraft

Redesigning the Replay System

2010-06-07T15:23:09Z

MILSTD:

{{Stub}}
Also see [[Proposals:Replay related]] and [[Talk:Proposals:Replay related]].

The [[Instant Replay]] system in its current form is not able to deal with many possible FlightGear use/case scenarios, among others it has currently the following known limitations:
* replaying environmental state (time, weather, visibility) is not yet supported
* replaying AI state (traffic, ATC) is not yet supported
* replaying flights with specific custom aircraft animations is not yet fully supported
* replaying flights done with aircraft that make use of Nasal scripts for some advanced features is not yet sufficiently supported (or standardized)

Also, the replay system is directly related to a number of other important use/case scenarios, such as:
* saving/loading whole flights (see prerecorded flights)
* saving/loading in-flight "situations"
* resuming flights at a particular position in time

While there are several other systems/techniques (such as the generic protocol or logging systems, or the ac-state.nas script to save aircraft state) being used to compensate for some of the shortcomings of the current replay system, it is still getting obvious that there needs to be an orchestrated effort to redesign the instant replay subsystem to make it become more flexible and configurable, so that it provides key functionality in a standardized fashion.

= Current Implementation =

Note: The latest source code of the replay subsystem can be found in [http://gitorious.com/fg/flightgear/trees/next/src/Aircraft $FG_SRC/Aircraft/replay.(c|h)xx]

* 07/2003: "I have implimented a first stab at an instant replay system and have just commited it to CVS. The system continuously records your flight data and allows you to play back your flight."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "Saving flight data at full resolution can quickly burn up a lot of RAM, so at the moment, only the most recent 60 seconds is stored at full resolution."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "The next most recent 10 minutes is stored at a resolution of one snap shot every 0.5 seconds."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "The most recent hour of data is stored at a resolution of one snap shot every 5 seconds."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "(We might need/want to tune these values a bit as we use the system more.) However, this gives the most resolution to the most recent portion of the flight, and can save up to an hour's worth of flight data without using a huge amount of memory."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "Each snapshot is time stamped with the simulation time. During replay, the system finds the two snapshots that straddle the replay time and linearly interpolates between them. This way, we can record the data as best as is possible given the current rendering speed, even with varying frame rates with possible lost frames and aren't forced to take extraordinary measures to get a consistent sampling rate."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "Then when the data is replayed, this interpolation scheme gives us smooth playback even if the recorded frame rate is wildly (or slightly) different from the playback frame rate. This also gives us smooth interpolation for older data that is recorded at a slower rate. And we can play back the recorded flight at a rate that has a 1 to 1 match with "real" time."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "This scheme would also allow us to smoothly fast forward the replay, or replay in super smooth "Slo-Mo-Gear" (patent pending) :-) We could probably also rewind as well as fast forward if we really wanted to."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "The sim is put into "pause" mode while the buffer data is replayed. This has some side effects because many subsystems do not run when the simulator is paused. This needs to be looked at a bit more. Specifically some of the viewer code isn't run. You can switch views with the "v" series of keys, but you can't rotate a particular view with shift-number pad, and the chase views don't track quite right in replay mode"[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

* 07/2003: "Also, I don't and can't and won't record "everything". This means things like AI or multiplayer traffic, weather conditions, and other things are beyond the scope of this system at this time."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15120.html]

= Community Feedback about Instant Replay Issues =
* "Be warned that there are multiple bugs in the recording/playback system, including FG code, simgear code, and FG data. Some of the bugs have been found and fixed. Others have not."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26789.html]
* "First off, what parameters are logged by it, or what defines if a parameter is logged by it? ie, thrust reverser use do not replay, but flaps do. This doesn't seem to be by model builder choice (?), unless Instant Replay is tied into multi-player parameters?"[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27066.html]

* 05/2010: "We recognized that to record hours of high resolution flight data would blow up the memory footprint of FlightGear on any PC. So we went for a balance"[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27074.html]

* 05/2010: "We record the most recent 60 seconds of data at full resolution, then the previous "n" minutes (I forget the exact number) is recorded at 1 second intervals. And then I think we go even further back recording at an even sparser interval. This way you get something as far back as you like, and you get high detail if you replay the last 60 seconds." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27074.html]

* 05/2010: "Originally, the recorder got turned off during the replay. Now the recorder continues to record while you replay ... so you are recording the replay as you replay it and you sort of end up with a recursive infinite loop. This actually has a nice feature that when you replay a flight, it loops for ever until you quit the replay, but know that each time through you are replaying a recording of the previous replay, and losing resolution each time through the cycle. So that's a bug, it needs to be fixed, I haven't had a chance to dig into it." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27074.html]

* 05/2010: "The problem with this particular bug is that because you are recording as you replay, you never actually get to see that 60 seconds of highly detailed data (assuming you replay more than 60 seconds which most people probably do.) So we are missing out on all the subtle nuances of your landing when you replay your landing for instance." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27074.html]

* 05/2010: "One other thing. The data structure that is recorded is the FGNativeFDM structure defined in src/Network/native_fdm.hxx. You do bring up a good question: what values should be recorded every frame? Given that aircraft designers can make up their own properties and drive them with nasal or other means, we can't know in advance a fixed set of property names that cover every situation." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27074.html]

* 05/2010: "So for the replay system we decided to go with a fixed, pre-defined binary structure ... and then you do live with a few replay warts if you are viewing an aircraft that uses "non-standard" properties ... and that's not a knock on the aircraft designer ... some airplanes have more than 4 engines, the AN-225 has like 185 landing gear assemblies, many aircraft have unique control systems and control surfaces ... and we can't take 20 minutes worth of snapshots of the entire property tree @ 60hz ... not on my PC anyway." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27074.html]

* 05/2010: "So the 60 second marker you mention is interesting ... that could correspond with the system that records the most recent 60 seconds at a high data rate. There could be some boundary logic there that didn't take every possible situation into consideration." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27074.html]

Talk:Feature Requests / Proposals / Ideas

2010-06-07T15:14:14Z

MILSTD: /* Related Discussions */ adding more related discussions from flightgear.org forums

= Related Discussions =
* http://flightgear.org/forums/viewtopic.php?f=6&t=5936 (end user requests, somewhat uninformed)
* [http://www.flightgear.org/forums/viewtopic.php?f=18&t=8269 development poll] flightgear.org forums
* [http://www.flightgear.org/forums/viewtopic.php?f=18&t=7702 ideas for the next flightgear release]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25061.html

= Cleanup =
This article has been marked as requiring cleanup, and I agree.
I think one simple way to clean up this page would be to provide a (sortable) table template, so that all items can be put into a corresponding table.
Suggested columns would be:
* description
* required skills (C++, OpenGL, Modeling etc)
* component (FDM, GUI, SOUND etc)
* estimated time to complete (complexity)
* popularity rank

= using a dedicated tracker =
While this whole section looks definitely useful, I would seriously consider implementing it via some sort of separate bug tracker, eventually this should have many advantages. For example, upcoming versions of bugzilla are planned to provide support for automatic roadmap creation based on requests. Likewise, you could actually group requests into appropriate categories, possibly based on Flightgear components/subsystems.

What do you guys think?

----

= more stuff from the archives: =

* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg11195.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18181.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg11931.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg28554.html
* [http://www.flightgear.org/forums/viewtopic.php?t=1134 Wishlist] - taken from the forum

= Controversy regarding proposal to use the SF.net tracker =
Quote:
'''Please note:''' We now have a a tracker on SourceForge at [http://sourceforge.net/tracker/?group_id=583].
Please list your bug/feature request/enhancement/idea on SourceForge as well as here.

Well, personally I am not sure if adding such advice is a particularly good idea at this time:

* this tracker has been around for ~8 years, so far it's always been pretty much ignored - by developers and contributors, as well as by most users
* there are certain restrictions when using SF.net resources (i.e. volunteer maintainers would also require sourceforge accounts, and they would explicitly need to be given the corresponding privileges by the project administrator)
* the SF.net tracker is not the most convenient tool to use
* there are meanwhile several other, more feature-rich trackers available, which would also allow for regular backups to be easily done and store offsite
* various other people have in the past proposed to set up trackers, even to maintain and administrate them: to no avail!
* some people even went as far as setting up complete systems, only to see them being rejected in the end [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg02071.html]
and most importantly:
* ''' afaIk: developers ''never'' officially agreed to use a tracker (and this tracker in particular) so far''' [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg08705.html]
* in fact, people have been previously advised explicitly by core developers, '''not''' to use this particular tracker [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg08702.html]

And the latter two points are actually the most important ones: whatever clever system people may set up,as long
as there is no official consensus regarding the use of one particular system (among all developers), this is going
to be a fruitless effort.

This whole thing would only be likely to work, once the key people behind the project (i.e.long-term developers and contributors) decide to actually '''use''' a tracker system (and also WHICH one).

Until this decision has been made and clearly stated, it would not be particularly wise to start using any sort of additional tracker system (however poor this one might actually be).

Thus, I would refrain from encouraging people to possibly spend lots of time on migrating the current list of
issues from the wiki to the SF.net tracker, or even just using other trackers at all.

Apart from that, the fact that the SF.net tracker is available, doesn't change the static nature of the wiki:

Also, as this is a static page <strike>and no searchable bug tracking system,</strike> '''no longer true - see
above re SourceForge tracker''' [...]

Don't get me wrong, using a tracker is definitively a good idea and '''needed''', however some decision making needs to take place before that can happen.--[[User:MILSTD|MILSTD]] 09:08, 19 March 2008 (EDT)

Portal:Developer/Aircraft

2010-06-07T13:35:39Z

MILSTD: adding new howto

{{PortalMenu}}

{|style="border-spacing:8px; margin:0px -8px; width:100%;"
|class="MainPageBG" style="width:100%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="1" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">The Aircraft Portal</h2>
|-
|style="color:#000;"|
This portal is for developers of [[FlightGear]] [[aircraft]]. And tends to be a home for aircraft related articles. See the [[Portal:Developer|developers portal]] for more articles about development
in general
|}
|}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"

! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Livery</h2>
|-
|style="color:#000;"|
* [[ Howto: Edit a livery|Edit a livery ]]
* [[ Livery over MP]]
|}

{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">FDM</h2>
|-
|style="color:#000;"|
* [[Howto: Add thrust reversal|Add thrust reversal]]
* [[Flight Dynamics Model]]
* [[JSBSim Commander]]
* [[JSBSim]] • [[UIUC]] • [[YASim]]
* [[Howto: Name fuel tanks|Name fuel tanks]]
|-
|}

{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Autopilot</h2>
|-
|style="color:#000;"|
* [[Autopilot Configuration Reference]]
* [[Howto: Design an autopilot]]
* [http://www.flightgear.org/Docs/XMLAutopilot/ Customizing the XML Autopilot]
* [[Autopilot Tuning Resources]]
|}

{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Route Manager</h2>
|-
|style="color:#000;"|
* [[Route Manager]]
* [[Route manager internals]]
* [[GPS]]
* [[GPS internals]]
* [[Inertial Navigation System]]
|}

|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">General</h2>
|-
|style="color:#000;"|
* [http://wiki.flightgear.org/index.php/Category:Aircraft_TODO Aircraft Todo]
* [[Aircraft Information Resources]]
* [[Aircraft Manuals]]
* [[Avionics Development Resources]]
|}

{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Nasal Scripting</h2>
|-
|style="color:#000;"|
* [[Nasal scripting language]]
* [[Writing simple scripts in "nasal"]]
|}

|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Modeling</h2>
|-
|style="color:#000;"|
* [[ Howto: Shader Programming in FlightGear]]
* [[Howto: 3D Aircraft Models|3D Aircraft Models]]
* [[3D Model Rotates Around Nose]]
* [[Howto: Add aircraft lights|Add aircraft lights]]
* [[Howto: Decrease the number of faces|Decrease the number of faces]]
* [[Model Import and Export]]
* [[Modeling - Getting Started]]
* [[:Category:Modeling|Modeling Category]]
* [[Modeling Resources]]
* [[Normals and Transparency Tutorial]]
* [http://wiki.flightgear.org/index.php/Copyright_Inquiry Copyright Inquiry]

* [[AC3D]] • [[Blender]] • [[SketchUp]] • [[Wings 3D]]
|-
|}

|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Howtos</h2>
|-
|style="color:#000;"|

* [[Howto: Make an aircraft|Make an aircraft]]
* [[Howto: Make a helicopter|Make a helicopter]]
* [[Howto: Use The Normal Map Effect in Aircraft]]
* [[Howto: Configure views in FlightGear|Configure views in FlightGear]]
* [[Creating instruments for FG|Create instruments]]
* [[Tutorials|Create interactive tutorials]]
* [[Howto: Define speed limits|Define speed limits]]
* [[Howto: Implement wing flex|Implement wing flex]]
* [[Howto: Implement pushback|Implement pushback]]
* [[Howto: Implent Generic tyre smoke|Generic tyre smoke]]
* [[Howto: Create a custom version of FlightGear]]
* [[Walk View‎]]
|}
|}

__NOTOC__
__NOEDITSECTION__

[[es:Portal:Desarrolladores/Aeronaves]]
[[pt:Portal:Desenvolvedorpara/Avião]]

Howto:Create a custom version of FlightGear

2010-06-07T13:32:02Z

MILSTD: /* Disabling Features */

{{Stub}}

= Intro =
This article is dedicated to providing an introduction to "[http://en.wikipedia.org/wiki/Mod_(computer_gaming) modding]" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by [http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346 a question posted to the FlightGear forums in June/2010].

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

= Getting Started =
The largest part of FlightGear by far is its base package (referred to as [[$FG_ROOT]]), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation (watch out for space requirements), so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder to work with a fresh, unmodified FlightGear version.

'''Note:''' Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable to point FlightGear to the customized version.

= Reducing Size =
Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

= Removing Resources =
You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working.
Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

= Proceeding =

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

= Disabling Features =

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first (and check if FlightGear still starts up) before removing anything!

The FlightGear wiki is usually also a good place to look for documentation on disabling certain features, another easy way to look how features can be disabled is using fgrun and watching the command line that it dynamically builds when you change settings in the UI.

= Customizing Preferences.xml =

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )

= Getting Help =
If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.

[[Category:Howto]]

Howto:Create a custom version of FlightGear

2010-06-07T13:30:40Z

MILSTD: /* Getting Started */

{{Stub}}

= Intro =
This article is dedicated to providing an introduction to "[http://en.wikipedia.org/wiki/Mod_(computer_gaming) modding]" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by [http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346 a question posted to the FlightGear forums in June/2010].

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

= Getting Started =
The largest part of FlightGear by far is its base package (referred to as [[$FG_ROOT]]), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation (watch out for space requirements), so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder to work with a fresh, unmodified FlightGear version.

'''Note:''' Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable to point FlightGear to the customized version.

= Reducing Size =
Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

= Removing Resources =
You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working.
Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

= Proceeding =

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

= Disabling Features =

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first before removing anything!

The FlightGear wiki is usually also a good place to look for documentation on disabling certain features, another easy way to look how features can be disabled is using fgrun and watching the command line that it dynamically builds when you change settings in the UI.

= Customizing Preferences.xml =

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )

= Getting Help =
If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.

[[Category:Howto]]

$FG ROOT

2010-06-07T13:26:08Z

MILSTD:

'''$FG_ROOT''' is refered to as the main directory of [[FlightGear]], containing the so called ''base package'' ([[aircraft]], [[scenery]], [[Menubar|GUI]] files etc). Also see [[Structure of the Base Package]].

On Mac OS X, $FG_ROOT is not installed automatically. See [[New to FlightGear#Installing on Mac OS X|New to FlightGear]] for an installation manual.

===Common paths===
* '''Mac OS X:''' <tt>Applications/FlightGear.app/Contents/Resources/data/</tt>
* '''Ubuntu:''' <tt>/usr/share/games/FlightGear/</tt>
* '''Windows:''' <tt>%ProgramFiles%/FlightGear/data/</tt>

[[Category:Special directories]]

[[nl:$FG_ROOT]]

Howto:Create a custom version of FlightGear

2010-06-07T13:21:01Z

MILSTD: /* Proceeding */

{{Stub}}

= Intro =
This article is dedicated to providing an introduction to "[http://en.wikipedia.org/wiki/Mod_(computer_gaming) modding]" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by [http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346 a question posted to the FlightGear forums in June/2010].

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

= Getting Started =
The largest part of FlightGear by far is its base package (referred to as [[$FG_ROOT]]), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation, so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder.

'''Note:'''Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable.

= Reducing Size =
Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

= Removing Resources =
You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working.
Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

= Proceeding =

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

= Disabling Features =

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first before removing anything!

The FlightGear wiki is usually also a good place to look for documentation on disabling certain features, another easy way to look how features can be disabled is using fgrun and watching the command line that it dynamically builds when you change settings in the UI.

= Customizing Preferences.xml =

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )

= Getting Help =
If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.

[[Category:Howto]]

Howto:Create a custom version of FlightGear

2010-06-07T13:20:24Z

MILSTD: /* Getting Help */

{{Stub}}

= Intro =
This article is dedicated to providing an introduction to "[http://en.wikipedia.org/wiki/Mod_(computer_gaming) modding]" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by [http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346 a question posted to the FlightGear forums in June/2010].

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

= Getting Started =
The largest part of FlightGear by far is its base package (referred to as [[$FG_ROOT]]), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation, so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder.

'''Note:'''Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable.

= Reducing Size =
Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

= Removing Resources =
You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working.
Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

= Proceeding =

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first before removing anything!

= Customizing Preferences.xml =

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )

= Getting Help =
If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.

[[Category:Howto]]

Howto:Create a custom version of FlightGear

2010-06-07T13:17:14Z

MILSTD: /* Getting Started */

{{Stub}}

= Intro =
This article is dedicated to providing an introduction to "[http://en.wikipedia.org/wiki/Mod_(computer_gaming) modding]" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by [http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346 a question posted to the FlightGear forums in June/2010].

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

= Getting Started =
The largest part of FlightGear by far is its base package (referred to as [[$FG_ROOT]]), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation, so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder.

'''Note:'''Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable.

= Reducing Size =
Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

= Removing Resources =
You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working.
Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

= Proceeding =

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first before removing anything!

= Customizing Preferences.xml =

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )

= Getting Help =
If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.

The FlightGear wiki is usually also a good place to look for documentation on disabling certain features, another easy way to look how features can be disabled is using fgrun and watching the command line that it dynamically builds when you change settings in the UI.

[[Category:Howto]]

Howto:Create a custom version of FlightGear

2010-06-07T13:16:57Z

MILSTD: /* Intro */

{{Stub}}

= Intro =
This article is dedicated to providing an introduction to "[http://en.wikipedia.org/wiki/Mod_(computer_gaming) modding]" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by [http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346 a question posted to the FlightGear forums in June/2010].

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

= Getting Started =
The largest part of FlightGear by far is its base package (referred to as $FG_ROOT), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation, so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder.

'''Note:'''Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable.

= Reducing Size =
Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

= Removing Resources =
You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working.
Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

= Proceeding =

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first before removing anything!

= Customizing Preferences.xml =

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )

= Getting Help =
If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.

The FlightGear wiki is usually also a good place to look for documentation on disabling certain features, another easy way to look how features can be disabled is using fgrun and watching the command line that it dynamically builds when you change settings in the UI.

[[Category:Howto]]

Howto:Create a custom version of FlightGear

2010-06-07T13:16:40Z

MILSTD: Turning forum question into new HowTo: http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346

{{Stub}}

= Intro =
This article is dedicated to providing an introduction to "[http://en.wikipedia.org/wiki/Mod_(computer_gaming) modding]" FlightGear in order to create customized "mini versions" of it for specific use/case scenarios, such as for example UAV simulation, the creation of this article was inspired by [ http://www.flightgear.org/forums/viewtopic.php?f=18&t=8346 a question posted to the FlightGear forums in June/2010].

If you have any questions please use this article's discussion page, and please do feel free to update and improve this article with your own experiences and recommendations, thanks!

= Getting Started =
The largest part of FlightGear by far is its base package (referred to as $FG_ROOT), especially the Aircraft and Scenery folders. Thus, this HowTo will currently be focused on reducing the size of the base package, without touching any of the binaries yet.

To get started creating a custom version of FlightGear, you could simply copy the whole directory tree of the FlightGear installation to a new directory and start removing everything that is obviously not needed for your particular purpose (i.e. UAV).

Please note that this will basically create a copy of your complete FlightGear installation, so if your local installation already contains any modifications or additional scenery/aircraft packages, you might instead want to install another FlightGear version in parallel, in a different folder.

'''Note:'''Advanced users may simply want to copy only their base package ($FG_ROOT) folder, instead of the whole installation tree, and start up FlightGear using their usual fgfs/fgrun binaries with a properly set --fg-root= parameter or $FG_ROOT environment variable.

= Reducing Size =
Creating a customized, mini version of FlightGear is not all that difficult, really - because it mostly means to remove anything that you don't need.

So, creating a mini version of FlightGear is mostly a matter of defining your requirements (such as required aircraft and scenery) in the first place before really removing anything that you might need later on. So make a list of all the features that you really need and make another list of all the features that you are certain you won't need.

= Removing Resources =
You will probably want to take an incremental (i.e. step by step) approach to disabling and removing folders and files from the base package, to ensure that you don't break anything in your customized version.

Whenever you make modifications to your custom version, you will afterwards want to make sure that FlightGear still starts up properly.

Probably, a good way of proceeding would be to first disable subsystems via preferences.xml and then simply RENAME the folders in the base package. This would ensure that you don't delete anything yet, but that FlightGear still cannot access these resources any longer.

Similarly, make sure to keep a pristine copy of the last working preferences.xml file around for debugging purposes, so that you can fall back to using that file if anything should stop working.

You will want to make sure to repeatedly run FlightGear after each modification to ensure that it is still working.
Also, make sure to watch out for any unusual warnings or error messages shown in the console/startup window.

So if there should be a problem, you can just as easily rename the corresponding folder back to its original name to see if the problem persists or if it's gone.

= Proceeding =

Then there are numerous other ways to reduce the size of the base package, just by looking into other base package folders that contain resources that are simply not applicable to your use case, such as for example many instruments, certain textures (i.e. seasons) or 3D models.

If you are uncertain whether a certain folder can be removed completely, you could just as well remove/rename individual files to see if these in particular are required or not.

Also, for a mini version of FlightGear specific to UAV use, you would probably not need resources like those contained in the AI, ATC or Traffic folders - assuming that you fully disable those systems via preferences.xml

On the other hand, you really have to make sure to properly and fully disable all those subsystems that may depend on those resources being present, otherwise the custom version of FlightGear may no longer start up properly, and simply refuse to work!

This is because those subsystems will not be able to complete their initialization if they fail to find certain base package resources, so make sure to disable those systems first before removing anything!

= Customizing Preferences.xml =

This is where the "customizing" part comes in. You will probably want to open $FG_ROOT/preferences.xml and edit it to suit your needs.

This includes changing the default startup position (KSFO) and aircraft (c172p), as well as disabling all subsystems that you won't need.

Also, you should refrain from outright deleting any entries in that file if you don't understand them fully, it is usually better to just comment out passages using XML comments (enclosing the original markup in )

= Getting Help =
If you don't know the purpose of a certain folder or file, you could check back with the FlightGear forums or mailing lists and ask for help there, most long time users will be able to tell you if a certain folder or file is needed for your specific goals or not.

The FlightGear wiki is usually also a good place to look for documentation on disabling certain features, another easy way to look how features can be disabled is using fgrun and watching the command line that it dynamically builds when you change settings in the UI.

[[Category:Howto]]

Category talk:Update-Required(GIT instead of CVS)

2010-06-06T18:37:30Z

MILSTD: Created page with 'This may better be implemented using templates instead of a dedicated category?'

This may better be implemented using templates instead of a dedicated category?

Building FlightGear - Linux

2010-06-06T18:35:55Z

MILSTD: /* Instructions */

{{Languages|Building_FlightGear_-_Linux}}

{{Main article|Building Flightgear}}

__TOC__

This section describes how to build FlightGear on Linux system.

Compiling FlightGear is not a task for novice users. Thus, if you're a beginner (we all were once) on a platform which binaries are available for, we recommend postponing this task and just starting with the binary distribution to get you flying.

Or if you develop on Ubuntu or Debian, consider trying the script described in [[Scripted Compilation on Linux Debian/Ubuntu]].

== Requirements ==
Before you can compile FlightGear, you need to have the following installed on your computer:

'''C++ compiler'''

These are: c++, cpp, gcc, g++ found under the /usr/bin directory. You will also need to have the tools '''autoconf''' and '''automake1.9''' installed.

'''CVS'''

Yes, the program is called 'CVS'. This is used for downloading the latest set of source code. Windows developers may wish to see [[Using TortoiseCVS with FlightGear]].

'''[[OpenGL]] support'''

More specifically, your system needs the support for hardware accelerated graphics. You can check for this by running the following in a [[command line]]:

glxinfo | grep direct

Note: To run the above command, you need to have the tool '''mesa-utils''' installed.

You should then see:

direct rendering: Yes

This means you are good to go as far as OpenGL support is concerned.

If you see:

direct rendering: No

Don't panic yet. This may just mean some required libraries for hardware accelerated graphic are missing. Go ahead and try installing plib 1.8.5 and its dependencies first. If you still get the above message, then you will need to do some googling and troubleshoot yourself.

== Dependencies ==
FlightGear is dependent on quite a few number of libraries. You do not need to compile all of them yourself, but you will at least need to have their development version installed. For example, the development version for package plib1.8.5 is plib1.8.5'''-dev'''.

The dependency is summarized in the following tree. Please note that each library has its own dependencies, and most of these are not shown here.

* FlightGear
** [http://kcat.strangesoft.net/openal.html OpenAL]
** SimGear
*** [http://plib.sourceforge.net/ PLIB]. Since march 2008, you will need version 1.8.5 - your distro probably supplies 1.8.4 still.
**** For versions pre march/2008: (Free)GLUT or SDL (We recommend the use of SDL over Free/GLUT, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16153.html however since march 2008, FreeGLUT as well as SDL are both considered depreciated, please only use --enable-osgviewer during configuration instead])
*** [[ OpenSceneGraph ]] (svn trunk for FlightGear/CVS and the latest preceding OSG release for a FlightGear release)
*** You also need the development files for several basic libraries to build the software, among them the following (the package names are for Debian and derivatives(?)):
**** libfreetype6-dev
**** libjpeg62-dev
**** libungif4-dev
**** libtiff4-dev
**** libpng12-dev
**** libxmu-dev
**** libxi-dev
**** zlib1g-dev
**** libglut3-dev

If you attack the above dependencies in the order listed below, you should be good:

1. Glut. Most distributions include glut packages, although you may have to hunt for them. Make sure you install both the glut and glut-devel packages, otherwise FlightGear may be able to compile but won't run correctly.

2. Zlib. Most distributions install the basic zlib libraries by default, but not the development portions. If you don't have zlib.h, you probably need to install the zlib-devel package for your distribution.

3. Plib - portability libraries and scene graph.

4. [[ OpenSceneGraph ]]

5. SimGear - Simulation support libraries. If you are building FlightGear from CVS, you need the CVS version of SimGear. If you have strange build errors, one of the first things to check is that you have an up-to-date version of SimGear built and installed.

==== APT-GET List ====
This is a list of all the apt-get commands I had to do while compiling FG, SG, and OSG on a mostly clean Ubuntu 64 system. It is a list of all the libraries you and your computer needs to compile FG, SG, OSG, and PLib. All you have to do is copy the full command, paste it in Terminal, enter your password, and it will download all the packages for you, and install them too. The full command is at the bottom, and I hope someone finds it useful :) sub-dependencies (dependencies of the dependencies) are not included as they are installed automatically by apt-get. If anyone sees something missing, please add it.

cvs - to get SG and FG <br>
subversion - to get OSG <br>
build-essential - to build (includes GCC, and other build tools) <br>
cmake - OSG Uses this <br>
ccmake-curses-gui -- OSG Uses this <br>
libpng-dev - to enable FG to use PNG textures<br>
libfreetype6-dev - fonts<br>
libjpeg-dev<br>
libungif4-dev<br>
libtiff-dev<br>
libxmu-dev<br>
libxi-dev<br>
libglut3-dev<br>
libalut-dev - sound<br>
libboost-dev - makes coding for some developers easier<br>
automake - needed by ./autogen.sh files<br>
autoconf - needed by ./autogen.sh files<br>
libfltk1.1-dev - You will need this if you will be using FGRun<br>
-----------
<pre>
sudo apt-get install cvs subversion build-essential cmake libpng-dev libfreetype6-dev
libjpeg-dev libungif4-dev libtiff-dev libxmu-dev libxi-dev libglut3-dev libalut-dev
libboost-dev automake autoconf libfltk1.1-dev
</pre>
-----------
Total size is about 230 MB, depending on what you already have from other applications.

This list might seem a bit short, but the sub-dependencies all add up :) The dependencies will be listed by apt-get when you use the command.

== Compiling ==
Assuming you are root, do:
cd /usr/local/src

<b>Note:</b> When tracking a fast changing software like FlightGear/CVS it is highly advisable to install it in a separate directory. That way one can also easily build and reinstall without being root, which greatly reduces the risk of messing up one's system.
To install in a directory of your choice add the <tt>--prefix</tt> argument to configure. E.g. <tt>./configure --prefix=$HOME/FlightGear</tt>. I would recommend installing all of OSG, plib, SimGear and FlightGear with the same prefix.

=== Getting and compiling SimGear ===

'''Step 1:'''

Login to the cvs server and checkout the latest version of SimGear's source code with:
cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 login
CVS passwd: guest

cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 co source

'''Step 2:'''

Since all the source code will be downloaded into a directory called '''source''', you will need to rename the directory into something more meaningful.

Rename the above directory by doing:
mv source simgear

Next, go into the directory and make preparations for the compilation:
cd simgear
./autogen.sh
./configure

Note that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command

'''Step 3:'''

Compile and install SimGear by doing:
make; make install

''Note:'' with gcc 4.2 or later,on some platforms, you can get compiling errors about alc.h like:

'<anonymous>' has incomplete type
take a look at http://bugs.gentoo.org/166723

=== Getting and compiling FlightGear ===

'''Step 1:'''

To login to the cvs version and checkout the latest version of Flightgear's source code, use:
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login
CVS passwd: guest

cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co source

A directory with the name '''source''' will then be created with all of Flightgear's source code downloaded into it.

'''Step 2:'''

To rename the above directory, use the following command:
mv source flightgear

Next, go into the folder and make preparations for the compilation:
cd flightgear
./autogen.sh
./configure

Note that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command.
If you didn't install OSG globally or in the same prefix as SimGear and FlightGear, you have to pass the OSG directory to the configure-command like this:
./configure --prefix=/path/to/fgInstallation --with-osg=/path/to/osg/installation --enable-osgviewer
In this case you have to tell your system where to find the OSG libraries before you can run flightgear:
export LD_LIBRARY_PATH=/path/to/osgInstallation/lib:$LD_LIBRARY_PATH

'''Step 3:'''

Now you can compile and install Flightgear by:
make; make install

'''Step 4:'''

Get the data directory:
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co data

And install it in (or as) /usr/local/share/FlightGear
mv data /usr/local/share/FlightGear

== Ubuntu and Debian users ==
If you wish you can use the [[Scripted_Compilation_on_Linux_Debian/Ubuntu]] script to have Flightgear compiled in one shot under both Ubuntu and Debian systems.

Debian users who prefer to build it without script may look at [[Building_Flightgear_-_Debian]].

== External links ==
=== Instructions ===
* [[ MSYS ]]
* [[ MinGW/cross-compiler ]]
* [[ CodeBlocks IDE ]]
* [[ OpenSUSE 10.1 10.2 ]]
* [http://www.geoffmclane.com/fg/fgmsvc7.htm MSVC7 *.Net]
* [http://www.oflebbe.de/oflebbe/FlightGear/index.html MSVC8 aka Visual 2005]
* [http://macflightgear.sourceforge.net/home/documents/ Mac OS X (0.9.10 and CVS)]

{{Building}}

[[Category:Update-Required(GIT instead of CVS)]]

Talk:Building FlightGear - Linux

2010-06-06T18:34:41Z

MILSTD: Update required WRT CVS vs. GIT use

== 06/2010: Update required WRT CVS vs. GIT use==
There are a number of articles which still refer to CVS instead of GIT, so there should probably be a new category added to such pages to indicate that these pages need to be updated accordingly.

== TODO: introduce and discuss fgfs-builder ==
ftp://ftp.uni-duisburg.de/FlightGear/Misc_rag/fgfs-builder

== proposal about building FG and OSG related items ==

- First change the obsoletes references to Plib
(do we need to keep them somewhere because of the remaining plib branch ?)
--> done

- Give some explanation about what we win with OSG.

- Gather some help tips on how to get and build the FG patched OSG.

- List the more common problems encountered when running FG with OSG, mark them as fixed when done.

- A link is given to gdb, some examples and associated context would be great.

== Windows? ==

Any chance of getting a thorough guide on how to set up a dev environment for Flight Gear in Windows? I'm attempting to right now, but I'm already on day 2 with no luck, and apparently according to this site: http://www.geoffmclane.com/fg/ it's not even possible on my current system set-up, as I have MSVC6, and it would extremely nice to know for sure.

If I can get this to work in the end I'll post something, but until then ...

FG will not compile with msvc6, it was allready a lot of work to adapt the code a few years ago (declaration of indices in a for statement, some templates could not compile as is, etc). Now that FG uses OSG wich is very C++, it's harder to use VC6. The best is surely to use the free version of msvc 2005.

== using script for ubuntu/debian ==

may I add the download_and_compile.sh script to the page for the Ubuntu (And soon even Debian) users ? I have well tested it on 8.04 and 8.10 both 32 and 64 bits

Now it automatically compiles:

* plib 1.8.5
* osg from svn
* simgear from cvs
* FlighGear from cvs
* fgrun from svn
* fgcom from svn
* atlas from cvs

script can downloaded [http://brisa.homelinux.net/fgfs/download_and_compile.sh here].

If you agree I can make a section under this article explaining the usage.

Talk:FlightGear Glass Cockpits

2010-06-05T17:29:07Z

MILSTD: adding pointers to ARINC 661 discussions taken from forums/mailing list

= ARINC 661 =
* http://www.flightgear.org/forums/viewtopic.php?f=6&t=8122
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27902.html

= Computing LNAV/VNAV Performance (from jsbsim mailing list)=
* http://www.davi.ws/avionics/TheAvionicsHandbook_Cap_15.pdf

= Links to related Discussions =
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg11635.html
* http://flightgear.org/forums/viewtopic.php?f=4&t=1571&p=11074
* http://marc.info/?l=flightgear-devel&m=119034407621183&w=2
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg05960.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10688.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01147.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg05372.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00943.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg14064.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg14063.html
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04939.html
* http://marc.info/?l=flightgear-devel&m=109196093609088&w=2
* http://marc.info/?l=flightgear-devel&m=109196046720056&w=2
* http://marc.info/?l=flightgear-devel&m=109182969814053&w=2
* http://marc.info/?l=flightgear-devel&m=109172801805270&w=2
* http://marc.info/?l=flightgear-devel&m=107273856906951&w=2
* http://marc.info/?l=flightgear-devel&m=105600915831677&w=2
* http://marc.info/?l=flightgear-devel&m=102378579610140&w=2
* http://marc.info/?l=flightgear-devel&m=102370047101815&w=2
* http://marc.info/?l=flightgear-devel&m=111669922929148&w=2

* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20521.html Discussion to encourage improvements in FlightGear's avionics department]

Talk:Redesigning the Replay System

2010-06-05T12:58:01Z

MILSTD: /* Related */

= Related =
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17034.html (serialization)
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg28332.html
* http://flightgear.org/forums/viewtopic.php?f=17&t=2766&p=26459&hilit=generic+protocol#p26459

= Replay Discussions from the forums =
questions, feature requests and suggestions:
* http://flightgear.org/forums/viewtopic.php?f=2&t=6824&p=61025&hilit=replay#p61025
* http://flightgear.org/forums/viewtopic.php?f=4&t=6284&p=53640&hilit=replay#p53640
* http://flightgear.org/forums/viewtopic.php?f=6&t=6328&p=52818&hilit=replay#p52818
* http://flightgear.org/forums/viewtopic.php?f=6&t=6290&p=51907&hilit=replay#p51907
* http://flightgear.org/forums/viewtopic.php?f=2&t=6186&p=49780&hilit=replay#p49780
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=46028&hilit=replay#p46028
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=45947&hilit=replay#p45947
* http://flightgear.org/forums/viewtopic.php?f=4&t=1917&p=45009&hilit=replay#p45009
* http://flightgear.org/forums/viewtopic.php?f=2&t=5400&p=40479&hilit=replay#p40479
* http://flightgear.org/forums/viewtopic.php?f=2&t=4969&p=36949&hilit=replay#p36949
* http://flightgear.org/forums/viewtopic.php?f=2&t=4876&p=36069&hilit=replay#p36069
* http://flightgear.org/forums/viewtopic.php?f=6&t=3085&p=28982&hilit=replay#p28982
* http://flightgear.org/forums/viewtopic.php?f=2&t=2766&p=27109&hilit=replay#p27109
* http://flightgear.org/forums/viewtopic.php?f=2&t=2057&p=15804&hilit=replay#p15804
* http://flightgear.org/forums/viewtopic.php?f=6&t=6875&p=65878&hilit=replay#p65878

= Suggested Approaches =
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17035.html re-implementing replay on top of the generic protocol facility]
* [http://flightgear.org/forums/viewtopic.php?f=2&t=1697&p=12549 Using ARINC 429 for logging flight data]
* from a conceptual point of view, the replay system has the same requirements as the multiplayer system: it has to work with arbitrary aircraft/vehicles and arbitrary combinations of properties (differing among aircraft), thus a subscription based approach is most promising, as it has been frequently suggested and favored in multiplayer related discussions

Talk:Redesigning the Replay System

2010-06-05T12:56:29Z

MILSTD: /* Related */

= Related =
* http://www.mail-archive.com/flightgear-devel@flightgear.org/msg28332.html
* http://flightgear.org/forums/viewtopic.php?f=17&t=2766&p=26459&hilit=generic+protocol#p26459

= Replay Discussions from the forums =
questions, feature requests and suggestions:
* http://flightgear.org/forums/viewtopic.php?f=2&t=6824&p=61025&hilit=replay#p61025
* http://flightgear.org/forums/viewtopic.php?f=4&t=6284&p=53640&hilit=replay#p53640
* http://flightgear.org/forums/viewtopic.php?f=6&t=6328&p=52818&hilit=replay#p52818
* http://flightgear.org/forums/viewtopic.php?f=6&t=6290&p=51907&hilit=replay#p51907
* http://flightgear.org/forums/viewtopic.php?f=2&t=6186&p=49780&hilit=replay#p49780
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=46028&hilit=replay#p46028
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=45947&hilit=replay#p45947
* http://flightgear.org/forums/viewtopic.php?f=4&t=1917&p=45009&hilit=replay#p45009
* http://flightgear.org/forums/viewtopic.php?f=2&t=5400&p=40479&hilit=replay#p40479
* http://flightgear.org/forums/viewtopic.php?f=2&t=4969&p=36949&hilit=replay#p36949
* http://flightgear.org/forums/viewtopic.php?f=2&t=4876&p=36069&hilit=replay#p36069
* http://flightgear.org/forums/viewtopic.php?f=6&t=3085&p=28982&hilit=replay#p28982
* http://flightgear.org/forums/viewtopic.php?f=2&t=2766&p=27109&hilit=replay#p27109
* http://flightgear.org/forums/viewtopic.php?f=2&t=2057&p=15804&hilit=replay#p15804
* http://flightgear.org/forums/viewtopic.php?f=6&t=6875&p=65878&hilit=replay#p65878

= Suggested Approaches =
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17035.html re-implementing replay on top of the generic protocol facility]
* [http://flightgear.org/forums/viewtopic.php?f=2&t=1697&p=12549 Using ARINC 429 for logging flight data]
* from a conceptual point of view, the replay system has the same requirements as the multiplayer system: it has to work with arbitrary aircraft/vehicles and arbitrary combinations of properties (differing among aircraft), thus a subscription based approach is most promising, as it has been frequently suggested and favored in multiplayer related discussions

Talk:Redesigning the Replay System

2010-06-05T12:55:00Z

MILSTD: /* Suggested Approaches */

= Related =
* http://flightgear.org/forums/viewtopic.php?f=17&t=2766&p=26459&hilit=generic+protocol#p26459

= Replay Discussions from the forums =
questions, feature requests and suggestions:
* http://flightgear.org/forums/viewtopic.php?f=2&t=6824&p=61025&hilit=replay#p61025
* http://flightgear.org/forums/viewtopic.php?f=4&t=6284&p=53640&hilit=replay#p53640
* http://flightgear.org/forums/viewtopic.php?f=6&t=6328&p=52818&hilit=replay#p52818
* http://flightgear.org/forums/viewtopic.php?f=6&t=6290&p=51907&hilit=replay#p51907
* http://flightgear.org/forums/viewtopic.php?f=2&t=6186&p=49780&hilit=replay#p49780
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=46028&hilit=replay#p46028
* http://flightgear.org/forums/viewtopic.php?f=6&t=5535&p=45947&hilit=replay#p45947
* http://flightgear.org/forums/viewtopic.php?f=4&t=1917&p=45009&hilit=replay#p45009
* http://flightgear.org/forums/viewtopic.php?f=2&t=5400&p=40479&hilit=replay#p40479
* http://flightgear.org/forums/viewtopic.php?f=2&t=4969&p=36949&hilit=replay#p36949
* http://flightgear.org/forums/viewtopic.php?f=2&t=4876&p=36069&hilit=replay#p36069
* http://flightgear.org/forums/viewtopic.php?f=6&t=3085&p=28982&hilit=replay#p28982
* http://flightgear.org/forums/viewtopic.php?f=2&t=2766&p=27109&hilit=replay#p27109
* http://flightgear.org/forums/viewtopic.php?f=2&t=2057&p=15804&hilit=replay#p15804
* http://flightgear.org/forums/viewtopic.php?f=6&t=6875&p=65878&hilit=replay#p65878

= Suggested Approaches =
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17035.html re-implementing replay on top of the generic protocol facility]
* [http://flightgear.org/forums/viewtopic.php?f=2&t=1697&p=12549 Using ARINC 429 for logging flight data]
* from a conceptual point of view, the replay system has the same requirements as the multiplayer system: it has to work with arbitrary aircraft/vehicles and arbitrary combinations of properties (differing among aircraft), thus a subscription based approach is most promising, as it has been frequently suggested and favored in multiplayer related discussions

Talk:Redesigning the Replay System

2010-06-05T12:52:42Z

MILSTD: /* Related */