https://wiki.flightgear.org/w/api.php?action=feedcontributions&user=Tom-cat&feedformat=atomFlightGear wiki - User contributions [en]2024-03-28T08:31:03ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=User:Tom-cat&diff=69906User:Tom-cat2014-04-23T04:22:21Z<p>Tom-cat: </p>
<hr />
<div>Areas I'm interested in:<br />
<br />
== Infrastructure ==<br />
* Work on an automated test system integrated with the C.I. server (Jenkins)<br />
<br />
== Scenery ==<br />
* Help with the San Francisco scenery<br />
* Look at scenery for Italy derived from CORINE landcover<br />
<br />
== Models ==<br />
* Model the Space Shuttle (http://gitorious.org/space-shuttle)</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Howto:Start_core_development&diff=66046Howto:Start core development2013-12-27T05:39:06Z<p>Tom-cat: /* Patches */</p>
<hr />
<div><br />
<br />
''01/2012: I have taken my [http://flightgear.org/forums/viewtopic.php?f=18&t=14870#p146436 forum response] and copied/pasted it here. Everybody is invited to contribute. While we do have a [[Volunteer]] page, we don't currently have a page dedicated to people wanting to contribute to the C++ source code, so this is an attempt to get something like this started.''<br />
<br />
= How the Project works (Suggested reading!) =<br />
Please see this short essay here: http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971<br />
= Welcome to FlightGear =<br />
<br />
Hi, and welcome to FlightGear!<br />
<br />
You have probably come here to learn more about implementing new features for FlightGear.<br />
<br />
Often, implementing new ideas and features doesn't necessarily require C++ knowledge, FlightGear has become so flexible and powerful that it is increasingly configurable even without touching the C++ source code. This is an important advantage, because building FG from source and finding your away around two fairly complex code bases (i.e. [[SimGear]] and [[FlightGear]]) can be a daunting task, even for experienced C++ developers.<br />
<br />
This isn't to say that C++ / programming knowledge wouldn't be useful though. And if that's where your interests are, you are certainly invited to contribute to the C++ code, too. <br />
<br />
== Not yet familiar with C++ ? ==<br />
<br />
If you don't yet know what a compiler is, what C++ is or how programming works, you may want to check out [[Howto: Understand the FlightGear development process]].<br />
<br />
While learning how to program is definitely possible, learning C++ in particular and becoming familiar with a complex code base like FG/SG does take a certain amount of time. In particular, setting up a working build environment to build FG from source, can be a daunting task for people without any corresponding background knowledge.<br />
<br />
If you know for sure, that you want to learn C++, we have a collection of helpful resources here: [[Resources#C.2B.2B_Courses|C++ resources]]. This includes a bunch of animated screen casts (i.e. video tutorials) on youtube: http://www.youtube.com/view_play_list?p=1D6727247CA35794<br />
<br />
== Developing without programming is possible and appreciated ==<br />
<br />
For non coding-related ideas on how to to start contributing, there's a dedicated article at [[Volunteer]]. Creating new aircraft, cockpits, scenery, instruments, GUI dialogs, etc. doesn't require any programming knowledge at all. If that's what you are interested in, please check out the links at the [[Portal:Developer|Developer Portal]].<br />
<br />
== Coding but not in C++ (scripting) ==<br />
<br />
If you are definitely interested in coding, but not in building FlightGear from source (C++), you may want to look into [[Nasal]] programming instead, which is FlightGear's built in scripting language, and doesn't require anything besides FlightGear itself.<br />
<br />
Many new ideas or features won't require any modifications to the C++ source code at all.<br />
You could probably get started and implement many ideas without even touching an IDE or a compiler for quite a while.<br />
<br />
That might actually be the easiest route for you to proceed in the beginning. Programming knowledge would obviously still be useful, because Nasal scripting is "real programming", many programming concepts (loops, functions, classes, events etc) you'll encounter in Nasal will seem familiar to people with previous programming experience.<br />
<br />
The "Nasal" programming language built into FG is syntactically very close to C and C++, it looks a lot like JavaScript - so you could run your own code inside FG without having to build FG from source, no need for compilers or an IDE. FlightGear IS the run time environment for Nasal code.<br />
<br />
If you are looking for immediate results, Nasal is probably the most promising route - simply because you don't need to look into all the tedious, non-coding related issues.<br />
<br />
For example, the tutorial system built into FG is entirely implemented in scripting space, and fully XML-configurable: [[Tutorials]]<br />
<br />
This means that you can create/modify and improve tutorials just by editing plain text files with any conventional text editor.<br />
<br />
There are many more things possible using Nasal, just see the wiki.<br />
<br />
And if you find something not being possible in scripting space, you could either fire up your IDE and extend the interpreter or ask another contributor to provide a corresponding patch.<br />
<br />
== Shader programming ==<br />
If you are not interested in C++ programming, but also not in Nasal scripting, there's another option: [[Shader|GLSL Shader programming]]. FlightGear has an extremely powerful "effects" framework and support for running GLSL shaders. While programming shaders for FlightGear doesn't by default require being a C++ developer, being able to build FG from source and knowing C++ can be really helpful though, especially in order to expose new properties to shaders (i.e. improving the property tree <-> shader interface).<br />
<br />
= Hacking the C++ code =<br />
<br />
From now on, this article will provide the required pointers to get you started hacking the FlightGear source code. Ideally, you already know C++, or a language very close to it, like C or Java. <br />
Also, you should preferably already have experience building programs from source code, otherwise this may seem pretty frustrating if you do this for the first time, simply because FlightGear has meanwhile become a fairly complex code base with many dependencies that need to be satisfied and built in a certain order.<br />
<br />
= Initial advice =<br />
<br />
Our advice would be: Start small, start simple, communicate a lot and most importantly '''release early & often''' (i.e. use topic branches and commit frequently, and encourage others to provide feedback)<br />
<br />
* if you know you want to contribute to the source code, make sure that you are actually able to build FG from source, you can get help using the forum, the mailing list, the issue tracker or live support using IRC chat - we have articles on building FG on various platforms, see [[Building FlightGear]]<br />
* read the documentation (wiki, $FG_ROOT/Docs, $FG_SRC/mini-docs)<br />
* it also helps running DoxyGen or Source Navigator to navigate the various source trees<br />
* start making tiny modifications to existing stuff (aircraft, scenery, source code etc)<br />
* try to get to grips with how git works (we have some resources to get you started, using GUI frontends like qgit or a good IDE can be helpful)<br />
* register an account at gitorious<br />
* clone the FG project (SimGear, FlightGear, fgdata)<br />
* browse the issue tracker for bug reports/feature requests, help triage problems, maybe provide patches too (i.e. to mute compiler warnings, to fix memory leaks, fix/add comments, clean up/refactor source code)?<br />
* search the archives (forum and mailing list) for discussions related to your area of interest, these contain often valuable pointers that may save you hours of work<br />
* subscribe to the developers mailing list<br />
* ask for advice/projects there<br />
* check out the wiki for ideas to get started (Watch out, there are plenty of "ideas" listed here, but not all of them are up to date or even "good" ideas, so talk to fellow contributors first before spending any significant amounts of time implementing something)<br />
* coordinate your effort with others, i.e. communicate your intentions early and ask for advice<br />
* release early and often<br />
* don't get frustrated :-)<br />
* enjoy!<br />
<br />
= Project architecture =<br />
FlightGear itself consists of a number of different projects and dependencies (libraries), please refer to gitorious for details. Most of FlightGear's supporting code is increasingly getting moved to the "SimGear" project.<br />
<br />
Basically, FlightGear depends on SimGear, while SimGear depends on some 3rd party libraries such as OpenSceneGraph (for rendering), plib (utility functions, joystick support, GUI etc), OpenAL (sound) and others like boost.<br />
<br />
Once you have satisfied all dependencies and built them in the right order, you can start FlightGear.<br />
Note however that FlightGear also has a run time dependency: its so called "base package", i.e. the data package that contains all resources such as scenery, GUI files, aircraft, sounds and so on. We commonly refer to this as "$FG_ROOT".<br />
<br />
The FG source tree is commonly referred to as $FG_SRC, while the SimGear source tree is often referred to as $SG_SRC.<br />
<br />
A while ago, Jim Wilson posted the following advice on the devel list:<br />
<br />
If you are familiar with C++ then you should have no trouble figuring things out. Take a look at the SGSubsystem class. This is the base for all the subsystems in flightgear. The most frequently used functions in this class are the init and the update functions.<br />
<br />
Then take time to look at a few subsystems. Generally for most subsystems you can figure that the update function gets called once per frame.<br />
<br />
The frame loop is in $FG_SRC/Main.cxx (function mainloop). Here you will see the various subsystem's update calls and the sequence they are done in. What I mean by frame loop is this loop is repeated for each frame (note the rendering down the bottom of it). There is also an event subsystem that is used to schedule calls to update() of certain subsystems on a timer interval.<br />
<br />
With this general overview (don't try to understand every line of code yet), you should be able to locate bits of code that you are interested in by<br />
perusing the directories of modules. Like I said most subsystems are based on SGSubsystem, so you should be able to locate implementations of init() and<br />
update(). Also note that some subsystems are updated by others, so if you don't see the update() called from in the mainloop then do a text search<br />
through the modules to find the code that actually does call the update() (look for references to the class you are interested in).<br />
<br />
Finally you will want to familiarize yourself with the data that is exposed in the property tree. This is an excellent learning tool. When running<br />
FlightGear, bring up the Property browser from the file menu. This property tree is essential for much of the way in which configuration and data output<br />
are handled in FlightGear. For example the flight instruments are all configured using xml defined references to values in the property tree in<br />
order to position needles, etc. Changing property values can be used to alter the configured behavior of FlightGear at startup using parameters and/or xml declarations, or on the fly using C++ property class functions in the code or from several other interfaces including the property browser (for example: try adjusting the cloud layer settings in the property browser under environment/clouds, you will see the effect right away).<br />
<br />
Speaking of instruments, you might want to take a look at how some of the instrumentation configuration (Aircraft/Instrumentation/*.xml files in the<br />
base package) in order to get an idea of how different parts of flightgear can be configured to communicate with other parts in a certain way through the<br />
property tree. You can also look at the preferences.xml file to see an example of how startup configuration for various subsystems is handled through<br />
the property tree.<br />
<br />
By browsing the properties and tracing interesting data items to the code they are output from or read by, you can learn a lot about how FlightGear works. When you see something interesting do a text search through the source code for that property name and you will find out how it is utilized.<br />
<br />
Welcome aboard and do feel free to post any questions to the list as they come up.<br />
<br />
= The source code =<br />
<br />
FlightGear is multi-platform software, that runs on all major versions of MS Windows, Mac OS and Linux. That means, the FlightGear source code also needs to be written and maintained with cross-platform considerations in mind. <br />
<br />
The core FlightGear source code itself is largely written in C++, some C and a bunch of helper scripts. FlightGear is based on OpenGL (NOT DirectX !), OSG (OpenSceneGraph) and OpenAL (for sound). An increasing number of features are implemented in scripting space, using a high level scripting language called [[Nasal]], Nasal scripts are maintained in the base package ($FG_ROOT).<br />
<br />
The SimGear and FlightGear source trees both make use of the [[Building using CMake|CMake]] build system as of 2012.<br />
<br />
The FlightGear project uses the decentralized source code management system "git" see [[Git]] for more info.<br />
<br />
The project sources are hosted at gitorious: http://gitorious.org/fg/<br />
<br />
If you know for sure that you'd like to fiddle with the core source code, you'll inevitably need to be able build FG from source, this is also documented in our wiki, a more recent article is to be found here: http://wiki.flightgear.org/Howto:_Build_FlightGear_with_NetBeans_using_CMake<br />
<br />
You can find tutorials for different platforms/OS at the end of the article.<br />
<br />
= Continuous Integration (CI) =<br />
<br />
For CI purposes, there's a dedicated build server running which rebuilds the FlightGear sources for a handful of important platforms. The server provides a simple and quick overview, it can be found here: http://flightgear.simpits.org:8080/<br />
<br />
Please see [[FlightGear Build Server]] for more information.<br />
<br />
= Patches =<br />
<br />
Regarding patches, please see: [[Submitting Patches]].<br />
<br />
Note that this article is meanwhile somewhat deprecated and these days using gitorious (and filing merge requests there) is pretty much encouraged. If your patch is related to a previously reported bug/defect, you can obviously also use the issue tracker (see below).<br />
<br />
In general, the FlightGear gitorious project is the entry point for new developers: http://gitorious.org/fg/<br />
<br />
Some more recommendations can be found at [[Recommended Project Policies]].<br />
<br />
In general, it is always a good idea to clone the FG repositories (i.e. SimGear, FlightGear and FGData) and start working on your own branch there. This will enable fellow contributors to easily keep track of your work, so that they can test your changes and provide feedback as required. <br />
<br />
To send patches upstream, gitorious merge requests are recommended. The details of which are covered at [[Merge request]].<br />
<br />
A list of active FlightGear core developers is to be found at [[:Category:FlightGear Core developers|FlightGear Core developers]].<br />
<br />
= Ongoing efforts =<br />
<br />
Anybody working on FG's source code, should be aware of the [[FGViewer]] trend (decoupling the viewer from the simulation using a [http://wiki.flightgear.org/FlightGear_Headless headless mode] 1) to improve frame rate and latencies, but 2) also to support distributed multi-screen setups) and also the long-term goal to use [http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00108.html OSG's CompositeViewer] for all of the FG views - so modifications to the existing viewer in $FG_SRC/Viewer should probbaly keep these things in mind to align well with other ongoing developments: http://wiki.flightgear.org/Howto:Use_a_Camera_View_in_an_Instrument#osgViewer::CompositeViewer<br />
<br />
An old PDF describing some of the challenges that FlightGear developers are trying to solve through HLA/[[FlightGear CIGI Support (Common Image Generator Interface)|CIGI]] adoption can be found at: http://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.pdf<br />
<br />
The FlightGear state of all HLA things is documented at: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)<br />
<br />
Introductory HLA resources are collected at: http://wiki.flightgear.org/Developing_with_HLA#Resources<br />
<br />
In developer's terms, that mostly boils down to:<br />
* expect more and more viewer functionality to be decoupled from the simulator (fgviewer being the prototype here)<br />
* expect more and more viewer/GUI features to be made optional through a [[FlightGear Headless]] mode during startup<br />
* expect the 2D rendering backend (GUI, instruments, HUDs etc) to be increasingly unified through the [[Canvas]] system<br />
* expect [[FGPanel|FGPanel standalone panel rendering]] functionality to be merged back into the main fgfs code base, provided through [[FGViewer]]<br />
* expect more work towards better system-wide reinit/reset support: http://wiki.flightgear.org/Reset_%26_re-init<br />
* expect more and more launcher features to be integrated and provided as part of FlightGear [http://flightgear.org/forums/viewtopic.php?f=35&t=21004&p=191451&hilit=#p191451]<br />
* expect FDMs to become re-initializable at runtime, expect support for multiple FDMs per session<br />
* expect more subsystem to become re-initializable at runtime, so that they can be dynamically enabled/disabled to facilitate the fgviewer and headless efforts: http://wiki.flightgear.org/FlightGear_Run_Levels<br />
* expect more and and more mainloop subsystems to eventually become standalone threads/processes (that is, HLA federates) (FDM, AI traffic, scripting etc) to guarantee better viewer performance<br />
* expect the existing multiplayer system to be completely phased out and replaced by HLA<br />
* expect [[Property Tree/Native Protocol Slaving|multi-instance slaving]] to be formalized and reimplemented through [[FGViewer]] and [[HLA]]<br />
* expect Nasal scripting integration to be increasingly decoupled from the fgfs main loop<br />
* expect OSG CompositeViewer to be eventually adopted (almost certainly not during the next 12 months though)<br />
<br />
Basically, help facilitate these change by at least not making these things more difficult through your own code<br />
<br />
For doxygen docs, see: http://docs.freeflightsim.org/<br />
<br />
In less broader (and more outdated) terms, a list of the latest development efforts can be found at http://wiki.flightgear.org/Category:Core_development_projects<br />
If you have anything to add, please feel free to create a new wiki article.<br />
Also, contributing such news to the FlightGear [[Next newsletter|newsletter]] is another good idea.<br />
<br />
If you are looking for ideas to get involved one way or another, some of the more long-term issues and most annoying glitches are discussed at [[Request for comments]]. <br />
<br />
However, please take everything you'll find there with a grain of salt, because many of these articles haven't been updated over the years, so what may have seemed like a great idea 2-3 years ago, may already be depreciated meanwhile. On the other hand, those articles may still help you get a better understanding of architectural issues. In case of doubt, please get in touch with fellow developers.<br />
<br />
Also, there's another outdated category titled "Code Cleanup": http://wiki.flightgear.org/Category:Code_Cleanup<br />
<br />
Another option would be taking a look at the "Google Summer of Code" category which also lists project ideas collected over the years: [[GSoC: Candidate Projects]]. We also have a separate sub forum for GSoC here: http://flightgear.org/forums/viewforum.php?f=38<br />
<br />
In other words: '''pick your poison :)'''<br />
<br />
= Issue tracking =<br />
<br />
Ideas (feature requests actually) and bug reports are ideally reported using the issue tracker here: http://flightgear-bugs.googlecode.com/<br />
<br />
Please make sure to first search the issue tracker before possibly reporting a dupe, thanks!<br />
<br />
This is also an excellent place to get started helping and contributing to FG, i.e. by triaging bug reports, discussing feature requests, posting patches or finding new ideas to work on. This is also a very good place to get in touch with other core developers.<br />
<br />
Also, if you have some new ideas in mind, and would like to extend FlightGear in some way, it's a good idea to use the issue tracker to make feature requests. Fellow FlightGear developers will be able to provide feedback regarding your feature request and tell you directly if and how exactly your idea can be best implemented.<br />
<br />
For example, to view a list of feature requests that were accepted by other core developers, just go to: https://code.google.com/p/flightgear-bugs/issues/list?can=2&q=FeatureRequest%20status%3Aaccepted<br />
<br />
= Talking to fellow FlightGear developers =<br />
Most core development related discussions are handled using the developers mailing list: http://www.flightgear.org/mail.html<br />
<br />
There's a fully searchable archive available here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/<br />
<br />
In addition, the FlightGear forums are increasingly used for interesting development related discussions, please note though that these are usually not specific to FG core development, but instead general development (aircraft, scenery, shaders, scripting): http://flightgear.org/forums/<br />
<br />
If there's something particular that you are interested in, it's always a good idea to search these resources (wiki, forum, mailing list) to find related discussions.<br />
<br />
= Flight dynamics =<br />
Improving the flight dynamics often doesn't require any C++ changes, FlightGear provides a powerful FDM interface and different FDM engines (namely JSBSim and YaSim), both of which are entirely configurable by using XML files.<br />
<br />
For JSBSim, please see: http://jsbsim.sourceforge.net/<br />
<br />
= Important docs =<br />
There's a wealth of documentation to get you started available in [http://gitorious.org/fg/fgdata/trees/master/Docs $FG_ROOT/Docs]<br />
<br />
<br />
Even more documentation can be found in our wiki, here: http://wiki.flightgear.org/<br />
<br />
The wiki is divided into different "portals", you'll probably be interested in the developers portal here: http://wiki.flightgear.org/Portal:Developer<br />
<br />
You are obviously invited to start your own wiki articles, in order to document your projects or help improving existing documentation. Also, some core developers actually use the wiki to post their own development roadmaps. For example, see: [[Plan-zakalawe]] or [[Project Rembrandt]].<br />
<br />
== FlightGear ==<br />
Don't worry if your C++ experience should be dated: In many parts, the FlightGear code base is still somewhat archaic and not very modern, so you won't find too many occurrences of really advanced C++ concepts, in many places you'll just find simple "C with classes" uses, some STL and inheritance. <br />
But complex C++ features (such as advanced templates or meta-programming are not too common actually).<br />
<br />
One of the simplest ways to add new features to FlightGear is adding new commands to it, so called "fgcommands" (i.e. "FlightGear commands"). <br />
For additional information, please see this tutorial: [[Howto: Add new fgcommands to FlightGear]].<br />
<br />
== Programming resources ==<br />
If you need to read up on something programming related, such as C++, the STL, OpenGL, shaders etc, the wiki has plenty of programming resources to get you started: [[Resources]].<br />
<br />
== SimGear ==<br />
The SimGear code base is somewhat less archaic and more modern actually. And if you are interested in contributing to the OpenGL/SceneGraph department, you'll inevitably need to look into OpenSceneGraph (OSG), too - which really is "modern C++".<br />
<br />
SimGear is fairly well-maintained code base that contains a fair amount of doxygen comments, that means that it's easy to create doxygen documentation for SimGear. For example, see: http://simgear.sourceforge.net/doxygen/<br />
<br />
Note that, at the time of reading, this may be outdated, so if you are interested in using the latest doxygen docs, you are well advised to run doxygen against your own latest simgear clone.<br />
<br />
Also, you can get a fair amount of information out of the FG sources by running them through doxygen, too.<br />
<br />
== Plain C ? (Nasal) ==<br />
If your C++ is rusty and you'd just like to get started quickly, there are also certain FG components that are strictly (largely) pure C, the Nasal interpreter is just one example (Nasal is FlightGear's built in scripting language): http://wiki.flightgear.org/Nasal_scripting_language<br />
<br />
The Nasal interpreter is part of the SimGear project, and can be found in $SG_SRC/nasal: http://gitorious.org/fg/simgear/trees/next/simgear/nasal<br />
<br />
Adding new extension functions to the built-in Nasal interpreter is documented here: [[Howto: Extend Nasal]].<br />
<br />
There's also a separate wiki article providing a list of known issues related to the Nasal interpreter itself: [[Improving Nasal]], specifically see [[Nasal Maintenance]].<br />
<br />
None of this requires any C++ knowledge!<br />
<br />
Only the scripting interface connecting the Nasal interpreter and FlightGear is implemented in C++, it can be found in $FG_SRC/Scripting: http://gitorious.org/fg/flightgear/trees/next/src/Scripting<br />
<br />
Basically, the scripting interface implements a custom SGSubsystem, so that the Nasal interpreter can be run as a FlightGear system. In addition, all FlightGear-specific extension functions are to be found there. Increasingly, this folder also contains wrappers to map FlightGear classes to Nasal space in an OOP fashion, so that not just functions, but full "objects" are provided, which are computed lazily. If that's what you are interested in, you should take a look at the NasalPositioned.cxx source code, which demonstrates how this is done.<br />
<br />
In other words, even without knowing C++, you can contribute to FlightGear core by extending the Nasal system. If you have some specific project in mind, you could probably implement it largely in scripting space using Nasal and only augment it as required with new extension functions in C space.<br />
<br />
= Getting started =<br />
Once you have found an area you are interested in, you can search the wiki, archives (mailing list and forums) or the issue tracker to find suitable projects to work on, for example: http://code.google.com/p/flightgear-bugs/issues/list?can=2&q=nasal&colspec=ID+Type+Status+Priority+Summary+Aircraft+Milestone&cells=tiles<br />
<br />
== Talk about your plans ==<br />
Before you start any serious efforts, please make sure to get in touch with other contributors. Ideally, using the developers mailing list or the forum. This is to ensure that others know about your plans, i.e. to avoid duplicate work, but also conflicting approaches. <br />
<br />
Often, FlightGear developers have certain ideas and plans for their projects, so it's good to coordinate your ideas with fellow contributors. In addition, you can get valuable feedback from experienced contributors this way, which may save you countless hours of time and lots of frustration.<br />
<br />
You may even find people interested in your idea and teaming up with you!<br />
<br />
== Scripting Hooks ==<br />
Another straightforward way to get started adding C++ code is using the [[Nasal/CppBind]] framework to expose built-in C++ classes to Nasal and enable base package contributors to make use of these, without bugging core developers to implement certain features directly. For C++ developers it is generally less time consuming (and often more rewarding) to implement abstract frameworks and infrastructure, rather than individual features.<br />
<br />
While the number of core developers has been decreasing during the last 12-18 months, we do have an increasing number of base package developers, so implementing generic hooks for them makes sense because core developers cannot possibly implement each requested feature.<br />
<br />
== Adding new subsystems ==<br />
If you are interested in adding new subsystems to FG, you may want to check out this: [[Howto:Create new subsystems]].<br />
<br />
Also, we have a step-by-step guide illustrating how a new system can be added to FlightGear, going into more detail. See [[Howto:Create a 2D drawing API for FlightGear]]<br />
<br />
== The property tree ==<br />
The FlightGear property tree is documented here: [[Howto:Work with the Property Tree API]]<br />
<br />
= Some Ideas =<br />
<br />
== CompositeViewer support ==<br />
This is a long-standing feature request, for details, please see [[CompositeViewer Support]].<br />
<br />
== JPEGFactory ==<br />
<br />
{{cquote|actually the entire JPEGFactory option could likely be removed, and replaced with using the osgDB Image plugins to create a JPEG or PNG. And then it wouldn't need to be a CMake option at all. If anyone would like to attempt this, please ask and I can suggest where to start, it's a nice small project<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40211.html|title=<nowiki>Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling</nowiki>|author=James Turner|date=Tue, 11 Jun 2013 22:40:38 -0700}}</ref>|James Turner}}<br />
<br />
{{cquote|<nowiki>It's turned off for build reasons, not because it's new or untested. I believe <br />
many people have used it exactly the way you describe. If you encounter <br />
problems, they should be easy to fix and patches are welcome!<br />
<br />
(The build reasons could actually be solved by using OSGDB to write out the <br />
files instead of using libjpeg directly - this would mean the feature could be <br />
enabled all the time, i.e removed from CMake, and also we could write out PNGs <br />
instead of JPEGs if desired - if you have any interested in doing this, I can <br />
point you at examples since the screenshot code was converted to do the same <br />
thing recently -it's probably a couple of hours hacking at most)<br />
</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40749.html|title=<nowiki>Re: [Flightgear-devel] --jpg-httpd command line option</nowiki>|author=<nowiki>James Turner</nowiki>|date=<nowiki>Tue, 17 Sep 2013 04:17:15 -0700</nowiki>}}</ref>|<nowiki>James Turner</nowiki>}}<br />
<br />
{{cquote|<nowiki>If someone decides to jump into this, another feature that would be cool<br />
would be to stream the display out as a video stream which could then be<br />
played by any number of video players on a remote computer (like mplayer.)<br />
ffmpeg probably would provide library support to make this pretty<br />
straightforward, but I haven't had a chance to dive in and see how<br />
easy/hard it would be.<br />
<br />
One area where this feature could be useful is in UAV research and<br />
simulation where you'd like to emulate a live video feed back to a ground<br />
station. It could also be fun for sharing/broadcasting your simulator<br />
session and probably could be made to work with a web video server.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40751.html|title=<nowiki>Re: [Flightgear-devel] --jpg-httpd command line option</nowiki>|author=<nowiki>Curtis Olson</nowiki>|date=<nowiki>Tue, 17 Sep 2013 11:51:00 -0700</nowiki>}}</ref>|<nowiki>Curtis Olson</nowiki>}}<br />
<br />
{{cquote|<nowiki>I wanted to capture the FG imagery and<br />
stream it over the web... (or some similar solution)<br />
</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10533.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}<br />
<br />
{{cquote|<nowiki>I've seen other<br />
apps that can do this so I know it's technically possible, and I imagine<br />
not too much coding once you figure out the magic to make it happen.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40751.html|title=<nowiki>Re: [Flightgear-devel] --jpg-httpd command line option</nowiki>|author=<nowiki>Curtis Olson</nowiki>|date=<nowiki>Tue, 17 Sep 2013 11:51:00 -0700</nowiki>}}</ref>|<nowiki>Curtis Olson</nowiki>}}<br />
<br />
{{cquote|<nowiki>VLC does this better than ffmpeg, so it's probably a good idea to study it's <br />
codebase for streaming code. Also, MJPEG is nice, but as a container I'd <br />
choose Ogg/Theora instead of H264 since they're entirely open.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40756.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}<br />
<br />
{{cquote|<nowiki>Note if you want actual good performance from this system, there's much smarter <br />
things that could be done, such as grabbing the frame buffer each normal <br />
rendering frame, instead of re-rendering the scene each time an HTTP get is <br />
received. That would need much more drastic changes to the system however.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40757.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}<br />
<br />
{{cquote|<nowiki>And obviously it does require that cmake finds the <br />
JPEG includes and libraries... I had earlier compiled <br />
and installed jpeg-9 into my 3rdParty folder... <br />
<br />
This dependency would go away if OSGDB was used, <br />
as James mentioned, but then JPEG would probably have <br />
to be found during the OSG build, unless OSG has <br />
alternate built-in jpeg code... not sure...<br />
<br />
Thereafter, running fgfs.exe with --jpg-httpd=1234 <br />
worked fine by putting http://localhost:1234 is a <br />
browser, and bingo had a jpg image of the screen <br />
in the browser ;=)) cool stuff...<br />
<br />
Of course it is a 'static' image, and had to refresh <br />
to get updated images of the flight... or an extension <br />
added to provide an actual video feed as Curt mentioned...<br />
<br />
So I would say it worked as advertised</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40884.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}<br />
<br />
Also see: {{Issue|924}}.<br />
<br />
We could probably also look at using the [[Canvas]] system with some additional hooks, i.e. for getting a handle to the osg::Image, so that it can be serialized through Nasal and some cppbind glue, that would make it possible to depreciate the JPEGFactory code and use the Canvas system instead (i.e. unifying the 2d rendering backend). <br />
<br />
Being able to render camera views to a canvas texture has been previously requested a number of times, e.g. for implementing "mirrors" or tail cameras (A380) [http://flightgear.org/forums/viewtopic.php?f=6&t=13798] [http://flightgear.org/forums/viewtopic.php?f=37&t=20057&p=184301#p184284] [http://www.flightgear.org/forums/viewtopic.php?f=6&t=13798&hilit= ]<br />
[http://www.flightgear.org/forums/viewtopic.php?f=6&t=6184&hilit= ] [http://www.flightgear.org/forums/viewtopic.php?f=4&t=3353&p=31252&hilit=#p31252 ], and getting a handle to the buffer for serialization purposes would also allow us to reimplement the screenshot feature on top of canvas/Nasal, and even serve live image data through the httpd component.<br />
<br />
* [[Howto:Use a Camera View in an Instrument]]<br />
* [[Canvas_Properties#Serializing_a_canvas_to_a_buffer_or_file]]<br />
<br />
<references/><br />
<br />
= Finally =<br />
<br />
...please don't get discouraged if you shouldn't get too much feedback in the beginning, probably many contributors are busy preparing the next release: http://wiki.flightgear.org/Release_plan<br />
<br />
Lack of feedback doesn't necessarily mean that nobody likes your project or your ideas, probably it just means that you need to do some networking to get in touch with other contributors. <br />
<br />
Usually, getting involved in the forum, the issue tracker or in merge request discussions via gitorious is a good idea to familiarize yourself with the project. Please keep in mind that we get to see plenty of people each month announcing some fancy new FlightGear-related projects, so your signal/noise ratio is pretty important here. It's pretty likely that the type of feedback you get will be improving once you start contributing patches and help triage bug reports.<br />
<br />
People announcing that they want to work on FlightGear, without knowing C/C++ or without having ever built software from source, obviously have to face a steep learning curve, and we are aware of that.<br />
<br />
Sometimes, it may even take good ideas a while to be recognized as such, even if suggested by seasoned long-term contributors. So, please don't interpret lack of feedback as a general lack of interest.<br />
<br />
[[Category:Howto]]<br />
[[Category:Core developer documentation]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=FlightGear_Git_on_Mac_OS_X&diff=57141FlightGear Git on Mac OS X2013-01-12T21:04:33Z<p>Tom-cat: /* Download and install OpenSceneGraph trunk */</p>
<hr />
<div>{{FlightGearGitOn}}<br />
== Please read this, important! ==<br />
This page is under heavy developement! It shows how you can probably succeed with installing your own FlightGear Developement Version on OSX 10.5 or 10.6, on a Intel-based Mac. This page is experimental and this building should not be used unless you know what you do with your computer. Keep in mind that installing developer versions of software can crash your computer ;-) <span style="color:#FF0000">'''Please do not start to mail to the FlightGear- or SimGear Devel-Mailinglist with FlightGear OSX installing problems related to this Wiki, ask your questions or report errors in the forum in postings/threads related to this page! --> http://flightgear.org/forums/viewtopic.php?f=21&t=14175<br />
'''<br />
<br />
== Before you start, move other installs out of system root ==<br />
The build system for FlightGear changed 2011 to cmake. When you want to follow this wiki and get a new clean install you should remove all former installs of plib, PLIB.Framework, OpenSceneGraph, simgear and flightgear. Depending on location where you installed FlightGear GIT version (NOT MacFlightGear!), you have to remove a lot of stuff i.e. in /usr/include, /usr/lib, /usr/local/lib, /usr/local/include etc. (depends where you installed before, but default is /usr/local/...). It is probably better NOT TO DELETE this stuff, keep the content in a safe place, but out of system root.<br />
<br />
== Default installing locations ==<br />
This guide installs the software with default paths on your system (MacPorts in /opt/local/ - other parts in /usr and /usr/local). There is only one framework (to be placed manually) in /Library/Frameworks. '''Use your own configuration options to get your preferred locations!'''. Do not post linking errors in the forum or the lists when you decide to use your own search paths.<br />
<br />
== Requirements ==<br />
System Requirements: OSX 10.5.8 (Leopard) or higher, and an Intel Mac.<br />
Other requirements: Basic knowledge of using Terminal on OSX, Xcode Dev Tools, MacPorts<br />
You are going to install:<br />
Xcode Dev Tools, MacPorts, boost, cmake, plib, ALUT.framework, OpenSceneGraph, git, SimGear and finally FlightGear<br />
<br />
'''This action will take more than 2 hours!'''<br />
<br />
== Install ==<br />
<br />
=== Install Xcode Developer Tools ===<br />
Download and install Xcode Dev Tools for OSX<br /><br />
for OSX 10.5.8 you need Dev Tools 3.1.4 [http://meandmark.com/blog/2009/10/downloading-older-versions-of-xcode How to get older dev tools versions]<br /> <br />
for OSX 10.6 (x86_64) you can use Dev Tools 3.2.6<br /><br />
[http://developer.apple.com/technologies/xcode.html http://developer.apple.com/technologies/xcode.html]<br />
Note that apple charges for version 4.0 and later and it is hard to find the links for older versions. However you can still use the required version for flightgear [3.2 or later] for free and you don’t need Dev Tools >= 4 [http://meandmark.com/blog/2009/10/downloading-older-versions-of-xcode How to get older dev tools versions]<br />
Update : Xcode is free (again ?) but is normally installed with Apple's appstore now.<br />
<br />
=== Install MacPorts ===<br />
Download and install [http://www.macports.org/install.php MacPorts]<br /><br />
Note: With already installed MacPorts it could be a good idea to first decactivate all other ports for this wiki. More information: http://guide.macports.org/#installing.macports.upgrade.<br />
<br />
=== Update MacPorts ===<br />
In terminal type<br />
sudo port selfupdate<br />
<br />
As of november 2011 you should get MacPorts 2.0.3<br />
<br />
Maybe you need also to upgrade your ports a bit, then type<br />
<br />
sudo port upgrade outdated<br />
<br />
=== Download and Install GIT ===<br />
There are different possibilities to install GIT. <br />
Option 1: install via MacPorts in Terminal with "sudo port install git-core"<br />
<br />
Option 2: Download and install GIT for OSX. Grab the latest version from<br />
[http://code.google.com/p/git-osx-installer/ http://code.google.com/p/git-osx-installer/]<br />
<br />
=== Install ''boost'' (1.47.0) with MacPorts ===<br />
sudo port install boost +universal<br />
Note: this step can take more than 30 minutes! Boost is made for drinking more tea.<br />
<br />
=== Install ''cmake'' (2.8.6) with MacPorts ===<br />
sudo port install cmake +universal<br />
<br />
=== Install '''plib''' (1.8.5) +universal ===<br />
just install plib via MacPorts<br />
sudo port install plib +universal<br />
<br />
=== Install the ALUT.framework ===<br />
Note: This framework is provided by James T. This is not official! James posted this download link in the develist and the link to the framework can change. Linking to the OpenAL/alut.h header and compilation of official freealut fails on my OSX 10.5.8 with FlightGear, and there is also no port avaiable at the moment. Big thanks to James for providing this framework (universal).<br />
Download here '''(temporary location!)''': [http://files.goneabitbursar.com/fg/alut-osx-universal.zip]<br /><br />
Unzip and move the ALUT.framework folder to /Library/Frameworks<br />
<br />
=== Download and install OpenSceneGraph trunk ===<br />
<br />
'''Remark 1:''' This is the most complicated part. Be sure you have all deps for OpenSceneGraph installed when you change some cmake settings like cocoa/ioimage (32/64-bit) instead of quicktime/carbon (32-bit only). Maybe you will need ''tiff'', ''jpeg'' and ''libpng'' installed to get some OSG Plug-ins compiled correctly. All this libs are available trough macports i.e. with "sudo port install tiff jpeg libpng" etc. Dont forget to add "+universal" port variant when you want to compile for more than one target ("i386;x86_64").<br />
<br />
'''Remark 2:''' Be careful what frameworks you have installed in /Lybrary/Frameworks. I edited some scenery for flightgear and that was the reason I had some geo frameworks installed. I had to move this frameworks to a safe place during OSG compilation, out of path (i.e. GDAL, GEOS, GSL, PROJ and especially UnixImageIO.framework).<br />
<br />
<br />
Checkout OpenSceneGraph trunk with<br />
git clone https://github.com/openscenegraph/osg.git OpenSceneGraph<br />
<br />
Make a copy of the "OpenSceneGraph" folder you get, maybe you need a fresh clone again when it fails.<br />
<br />
cd OpenSceneGraph<br />
<br />
For compiling with imageio/'''cocoa''', target architecture '''i386 AND x86_64''':<br />
cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Release \<br />
-DCMAKE_OSX_SYSROOT='''/Developer/SDKs/MacOSX10.5.sdk''' -DCMAKE_OSX_ARCHITECTURES="i386;x86_64" \<br />
-DCMAKE_OSX_DEPLOYMENT_TARGET='''10.5''' -DCMAKE_MINSIZEREL_POSTFIX= -DBUILD_OSG_APPLICATIONS=OFF \<br />
-DCMAKE_RELWITHDEBINFO_POSTFIX= -DOSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX=imageio \<br />
-DOSG_WINDOWING_SYSTEM=Cocoa -Wno-dev<br />
<br />
Alternate for compiling with imageio/'''carbon''', target architecture '''i386/32-bit only''':<br />
cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Release \<br />
-DCMAKE_OSX_SYSROOT='''/Developer/SDKs/MacOSX10.5.sdk''' -DCMAKE_OSX_ARCHITECTURES="i386;x86_64" \<br />
-DCMAKE_OSX_DEPLOYMENT_TARGET='''10.5''' -DCMAKE_MINSIZEREL_POSTFIX= -DBUILD_OSG_APPLICATIONS=OFF \<br />
-DCMAKE_RELWITHDEBINFO_POSTFIX= -DOSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX=imageio \<br />
-DOSG_WINDOWING_SYSTEM=Carbon -Wno-dev<br />
<br />
Finally:<br />
make<br />
sudo make install<br />
<br />
'''Remarks:''' Compiling OpenSceneGraph often takes more than 30 minutes.<br />
You need to alter the '''10.5''' above to your SDK version. <br />
Also the path to the /Developer directory has changed since xcode 4.2 to be in the /Application/Xcode.app/Contents directory.<br />
<br />
=== Git SimGear/FlightGear/fgdata ===<br />
Create a directory where you want to place your new FlightGear code.<br />
git clone git://gitorious.org/fg/flightgear.git<br />
git clone git://gitorious.org/fg/simgear.git<br />
git clone git://mapserver.flightgear.org/fgdata/ <br />
'''or''' git clone git://gitorious.org/fg/fgdata.git<br />
The fgdata is about 4 GB! You can clone this repo once and later you use ''git pull''. There is other page [[FlightGear and Git]] about using the FlightGear Gitorious GIT Repos. There is also an alternate GIT repo on mapserver.flightgear.org: http://mapserver.flightgear.org/git/.<br />
<br />
=== Install SimGear (!new since nov 2011: cmake build) ===<br />
cd to the simgear directory and type<br />
export CFLAGS="-g -O2 -fPIC -arch i386 -arch x86_64"<br />
export CXXFLAGS="-g -O2 -fPIC -arch i386 -arch x86_64"<br />
cmake . -DJPEG_FACTORY=1 -DCMAKE_INSTALL_PREFIX=/usr/local<br />
make<br />
sudo make install<br />
<br />
=== Install FlightGear (!new since nov 2011: cmake build) ===<br />
cd to the flightgear directory and type<br />
export CFLAGS="-g -O2 -fPIC -arch i386 -arch x86_64"<br />
export CXXFLAGS="-g -O2 -fPIC -arch i386 -arch x86_64"<br />
cmake . -DJPEG_FACTORY=1 -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_FGADMIN=OFF -DWITH_FGPANEL=OFF<br />
make<br />
sudo make install<br />
<br />
As of november 2011 fgadmin and fgpanel won’t compile here on OSX. Set -DENABLE_FGADMIN=OFF -DWITH_FGPANEL=OFF to ON when you want to give it a try ...<br />
<br />
=== Using Xcode for compilation ===<br />
You can add -G Xcode to above cmake statements to let cmake create the needed xcode project files. Open the created .xcodeproj files and build it using ⌘ + B or choosing the menu Product=>Build. You may need to set the build target "ALL_BUILD>My Mac 64-bit" or what ever your target is and the configuration in the menu Product=>"Edit Scheme" where you can set the build configuration to "Debug" or "Release" under the "Run" tab. Once successfully compiled you need to install the build on the terminal since the standard target location of the files need root privileges. So change directory to your osg, simgear or flightgear git directory containing the .xcodeproj file and execute the command "sudo xcodebuild -target install -configuration Release". The -configuration depends on what you last built usually Release though. Choose -target uninstall to uninstall all related files. <br />
<br />
=== Finish and Testrun ===<br />
<br />
You can use ''fgfs --fg-root=/path/to/fgdata'' and ''--fg-scenery=/path/to/scenery''<br />
fgfs --option1 --option2 ...<br />
type in terminal "fgfs --help -v" to get all current command line options<br />
<br />
[[fr:FlightGear Git sur Mac OS X]]<br />
[[de:FlightGear Git on Mac OS X]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_March_2012&diff=43964FlightGear Newsletter March 20122012-03-08T03:49:04Z<p>Tom-cat: /* KMIA */</p>
<hr />
<div>{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
== Development news ==<br />
<br />
=== FlightGear and HLA (High Level Architecture) ===<br />
<br />
When reading the FlightGear forums or the FlightGear developers mailing list, you'll probably have noticed the term "HLA" being brought up more and more often recently. <br />
<br />
In fact, FlightGear core developers and other contributors seem to bring it up whenever somebody asks about better FlightGear modularization, better concurrency support (i.e. using all your idle CPU power), but also better overall frame rates or a more consistent multiplayer experience and weather environment. <br />
<br />
It seems as if "HLA" is the swiss army knife to deal with many long-time FlightGear challenges.<br />
<br />
So, what is HLA after all? <br />
<br />
In short: HLA, "High Level Architecture", is an industry standard (IEEE 1516) to standardize interactions between component-based simulation architectures in a distributed setup. <br />
<br />
Now, that's a mouthful, right?<br />
<br />
Let's try to describe the thing in simpler terms: Most programs (like FlightGear) have a single large code base where all subsystems get their processing time assigned by so called "main loop" which sequentially iterates over all systems and calls their "update" routine, to give each system time to do its work (update weather, update GUI, update AI, update FDM, update sound etc). <br />
<br />
Unfortunately, this also means that every subsystem running as part of the main loop has a direct effect on the simulation frame rate, i.e. the total run time cost of each complete update iteration is determined by the time spent in each individual routine, i.e. the total update time adds up: FDM+SOUND+AI+GUI etc<br />
<br />
Whenever you add a new system, you need to add it to the program's main loop and add new source files to the code base of the program. This involves rebuilding FlightGear from source. <br />
<br />
In HLA, the general idea is to split up a large simulation into a subset of smaller simulations which are interlinked exchanging information (objects and events) to create a consistent simulation environment using a well-defined interface. This division makes it possible to run these simulations in different thread or even in different processes, even running on other computers.<br />
<br />
Only the information that is really required will be exchanged, so the exchange of this information is the only run time footprint, each simulation is responsible to compute and update its own state. <br />
<br />
Communications between each simulation node take place using a computer network and an API (similar to CORBA). All participating simulations are being managed by a central component, called the "Run-Time Infrastructure" (RTI). <br />
The RTI monitors the overall simulation and manages the distribution of data between all individual nodes, which are called "federates". The simulation in its entirety is called a "federation" in HLA.<br />
<br />
We have started a new article and copied earlier announcements and postings to it, please see [[FlightGear HLA support (High Level Architecture)]].<br />
<br />
=== Mailing list digest ===<br />
<br />
(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list)<br />
<br />
=== Forum digest ===<br />
<br />
=== Git digest ===<br />
<br />
== Interview with a contributor (NAME) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* How long have you been involved in FlightGear?<br />
* What are your major interests in FlightGear?<br />
* What project are you working on right now?<br />
* What do you plan on doing in the future?<br />
* Are you happy with the way the FlightGear project is going?<br />
* What do you enjoy most about developing for FlightGear?<br />
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?<br />
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?<br />
<br />
More questions are being collected here: [[Interview questions]].<br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX <br />
<br />
== Snapshot releases ==<br />
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].<br />
<br />
The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].<br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.<br />
<br />
=== New aircraft ===<br />
<br />
=== Updated aircraft ===<br />
==== Airbus A320neo ====<br />
The [[Airbus A320neo]] have suffer a deep redesign.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
<br />
[[File:KMIAeast.jpg|thumb|250px|KMIA preview in Sketchup]]<br />
=== KMIA ===<br />
<br />
Andyramone has returned from a 1 year Flightgear hiatus to work on modelling the Miami International Airport (KMIA.) There is a basic model already built for the main terminal, which will be available via Terrasync mid-march. <br />
<br />
The plan is then to work on improving the model by adding more accurate textures, night textures, movable jetways, and a more accurate airport layout, with the potential to move to a 8.50 airport layout. The surrounding hangars, buildings and Cargo hangar to the south will also be added as they are built. <br />
<br />
All models will be GPL compliant and available via Terrasync.<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
* The [[OpenRadar]] project is looking for a new maintainer.<br />
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Did you know ===<br />
<br />
Torsten recently in Git-a new internal command: property-interpolate [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35900.html].<br />
<br />
This exposes the SGInterpolator subsystem to bindings in xml animation <br />
files. The SGInterpolator allows the interpolation of property values <br />
over time and has so far been used via Nasal in aircraft.door.<br />
<br />
For an example, start the Hansajet from git (fgfs --aircraft=Hansajet) <br />
and zoom to the gyrosyn heading indicator left of the HSI. Locate the <br />
black/white knob with "VOR" and "ADF" written on it. Click it (it swaps <br />
the assignment of the needle-driving sources) and notice that it does <br />
rotate smoothly to its new position (it's a 2-position toggle knob).<br />
<br />
Now, look at the overhead panel, either by paning the view up and right <br />
or by pressing shift-v on the keyboard. Locate the six rotary buttons <br />
GEN.1, GEN.2, ALT.1, ALT.2 and the two between the AC and DC <br />
instruments. Move them by clicking their left/right edges. Notice they <br />
move smoothly instead of jumping to the new position.<br />
<br />
Thats done completely without Nasal but from just a few lines in the <br />
animation files. Basically, you have to add two bindings to the <pick> <br />
animation:<br />
1. property-assing the target value describing the state of the button<br />
(that's what you are used to do)<br />
2. property-interpolate the position of the model to it's new state's value<br />
(that's the new binding to add)<br />
3. Animate the model's rotation from the position property, not the <br />
state property<br />
(that's what you have to change)<br />
4. done.<br />
<br />
(see the animations for the object SyncKnob and SyncKnobPick.[LR] in <br />
Aircraft/Hansajet/Models/Sperry-C-6d.xml as an example).<br />
<br />
The use of the property-interpolate may be:<br />
<br />
Change the value of /some/target/property to the constant value of <br />
100.0 over 3 seconds.<br />
<syntaxhighlight lang="xml"><br />
<binding><br />
<command>property-interpolate</command><br />
<property>/some/target/property</property><br />
<value>100.0</value><br />
<time>3</time><br />
</binding><br />
</syntaxhighlight><br />
<br />
Change the value of /some/target/property to the value of <br />
/some/source/property over 0.5 seconds.<br />
<syntaxhighlight lang="xml"><br />
<binding><br />
<command>property-interpolate</command><br />
<property>/some/target/property</property><br />
<property>/some/source/property</property><br />
<time>0.5</time><br />
</binding><br />
</syntaxhighlight><br />
<br />
[[Category:FlightGear Newsletter]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Howto:Use_the_system_monitor&diff=43963Howto:Use the system monitor2012-03-08T03:45:26Z<p>Tom-cat: /* Debugging stuttering */</p>
<hr />
<div>== The system monitor ==<br />
<br />
[[File:System-performance-monitor-fg260.png|400px|thumb|Screen shot showing the system performance monitor available in FG 2.6.0+]]<br />
<br />
In FlightGear >= 2.6.0, use the menu option '''Debug''' => '''Monitor System Performance''' to analyze stutters.<br />
<br />
In a perfect world, min/max/mean values should be almost identical for every subsystem - and standard deviation should be almost 0. <br />
<br />
Larger differences / high standard deviations result in a sloppy simulation and stuttering movements, though they'll hardly influence the frames-per-second value at all.<br />
<br />
Also, imagine a system producing 100 frames in 0.5 seconds, then blocking completely for another 0.5 seconds:<br />
The fps display would still show "100fps", which seems great. But the 0.5 second stutter cause the visual performance to be terrible. <br />
<br />
When evaluating simulation performance, don't get fooled by the frame rate. What's really important to us is the "worst case frame latency". Even if the system is producing a huge average of 100 frames per second, it can still look absolutely crappy, if only a single frame took more than 20-30ms, since that's immediately visible to the human eye. So, we're building a real-time system here, and 20-30ms is our timing constraint.<br />
<br />
That's why it is preferable to display "(worst-case) frame spacing" instead of fps (View => Display Options => Show frame spacing). The frame spacing for the previous example would show "500ms", while a system producing 100 frames with perfectly even spacing would show "10ms".<br />
<br />
So, frame spacing is a much better property to judge visual quality than just watching fps.<br />
<br />
<br />
<br />
The new GUI dialog is available in the menu: "'''Debug'''" => "'''Monitor system performance'''".<br />
<br />
* Only statistics on our "subsystems" are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these).<br />
<br />
* Title bar shows average and worst case frame rate. In a perfect world, all frames should be spaced evenly, so both values should be almost identical. When frames are produced unevenly, then a larger difference between the worst and average frame rate is visible. Needless to say, we should try to get FG to deliver frames evenly, so movements look smooth.<br />
<br />
* Main table shows statistics on the individual subsystems. Helps to identify how much time certain systems currently consume, or which are responsible for jitters resulting in uneven frame rates.<br />
<br />
* A bit background on the FG subsystems may be necessary though to really judge what's going on:<br />
** For example, you'll see the "nasal" subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the "events" subsystem. So, to judge Nasal performance, you'll mainly need to look at "events" (and yes, you'll see time being consumed and jitters being produced there, which is related due to Nasal's current MARK/SWEEP Garbage Collector implementation, i.e. see: [[Improving Nasal]]).<br />
** The "tile-manager" an "ai-model" subsystems may also contain time consumed by the Nasal engine, since each scenery tile and each AI/MP aircraft may trigger a Nasal script ("load"/"unload" hooks).<br />
** The GUI system is another subsystem which may trigger Nasal hooks<br />
** While it is true that the current Nasal mark/sweep garbage collector has been shown to cause occasional stuttering under certain circumstances, the system monitor in its current form is '''not''' suitable to tell you the difference between a badly coded "rogue" script causing stutter or the stuttering being really caused by the Nasal GC. Also, it is worth noting that following good coding practices may actually help decrease the overall pressure on the GC, i.e. by keeping the number of references to be traversed low and pretty constant, but also by not calling unneeded code too frequently using timers or listeners.<br />
<br />
* At the moment, it is unfortunately not yet possible to get timing statistics for individual Nasal scripts or sub modules, but this is something that has been requested by a number of users and so we are looking into making this possible eventually.<br />
<br />
* Statistics data is only collected while the dialog is open (or you manually set /sim/performance-monitor/enabled).<br />
<br />
Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve...<br />
<br />
= Debugging stuttering =<br />
<br />
To put it simple, vertex shader performance is affected by the amount of detail visible in the geometry of scene (number of vertices visible), and of course shader complexity itself, while fragment performance is affected by screen resolution(or window size if you run it windowed) and shader complexity as well. They both affect framerate in the end, since the frame needs to be finished before being put up for display.<br />
Frame delay might be affected by a lot of other stuff, but it's a better measure of smoothness since it displays the "longest" time it had to wait for a frame in a certain amount of time.<br />
There might be some performance lost in high detail scenes, due to the culling (visibility check, and hiding of faces facing away from the camera, or being behind other faces, or too small to display (openscenegraph is smart about that one and it won't "display" faces/parts of objects that would end up too small)) that needs to be done on the scene before it goes through the shaders.<br />
<br />
To test if it's a graphics performance issue, you'd do a couple of tests.:<br />
<br />
First load up the ufo, over detailed scenery, remain static, don't move the view around. Check framerate and frame delay. If they're consistent with each other it might be a graphics performance issue, if not you can be sure there's some other subsystem that does background processing and needs to finish its stuff.<br />
<br />
Move the view around, do you get stutters? If you do, then there's some pressure on your video card's RAM. As it needs to load the new geometry and textures that come into view, it might not have enough space left, so it might need to offload the "old" ones. Even like this framerate should stabilise once you stop moving the view around, or once the rate of movement is slow enough so that the video card can keep up.<br />
<br />
Fly straight and level, at reasonable speeds, keeping the view fixed. Do you get stutters? Is framerate consistent with frame delay? If it is, and you get low fps, again it might be a graphics issue, as new random objects come into view and/or the trees shader creates new ones in the distance. If not I's still suspect another susbsytem being the culprit.<br />
<br />
You can repeat these with some aircraft, see if and how things change.<br />
<br />
In short: if the framerate '''varies along with the Frame Delay''', then it's a graphics performance issue. If framerate is pretty stable, and Frame Delay '''varies more or less wildly''' I'd suspect some other subsystem being the culprit and causing more or less periodic delays as it needs to do it's stuff.<br />
<br />
= Interpreting the OSG on screen stats =<br />
<br />
[[Image:OSG-OnScreen-Stats.png|thumb|400px|Screenshot showing the OSG on screen stats]]<br />
<br />
You can also try to play with osg's frame statistics, you can switch that on from the debug menu.<br />
<br />
Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens <br />
to be a problem.<br />
<br />
A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.<br />
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!<br />
<br />
Once your orange bar is longer than the yellow one, you can start to care for <br />
the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very <br />
different on the same shader.<br />
<br />
And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible.<br />
<br />
== References ==<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35202.html<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html<br />
<br />
<br />
[[Category:Howto]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Howto:Use_the_system_monitor&diff=43962Howto:Use the system monitor2012-03-08T03:41:56Z<p>Tom-cat: /* Debugging stuttering */</p>
<hr />
<div>== The system monitor ==<br />
<br />
[[File:System-performance-monitor-fg260.png|400px|thumb|Screen shot showing the system performance monitor available in FG 2.6.0+]]<br />
<br />
In FlightGear >= 2.6.0, use the menu option '''Debug''' => '''Monitor System Performance''' to analyze stutters.<br />
<br />
In a perfect world, min/max/mean values should be almost identical for every subsystem - and standard deviation should be almost 0. <br />
<br />
Larger differences / high standard deviations result in a sloppy simulation and stuttering movements, though they'll hardly influence the frames-per-second value at all.<br />
<br />
Also, imagine a system producing 100 frames in 0.5 seconds, then blocking completely for another 0.5 seconds:<br />
The fps display would still show "100fps", which seems great. But the 0.5 second stutter cause the visual performance to be terrible. <br />
<br />
When evaluating simulation performance, don't get fooled by the frame rate. What's really important to us is the "worst case frame latency". Even if the system is producing a huge average of 100 frames per second, it can still look absolutely crappy, if only a single frame took more than 20-30ms, since that's immediately visible to the human eye. So, we're building a real-time system here, and 20-30ms is our timing constraint.<br />
<br />
That's why it is preferable to display "(worst-case) frame spacing" instead of fps (View => Display Options => Show frame spacing). The frame spacing for the previous example would show "500ms", while a system producing 100 frames with perfectly even spacing would show "10ms".<br />
<br />
So, frame spacing is a much better property to judge visual quality than just watching fps.<br />
<br />
<br />
<br />
The new GUI dialog is available in the menu: "'''Debug'''" => "'''Monitor system performance'''".<br />
<br />
* Only statistics on our "subsystems" are shown. That's the FG modules running in our single-threaded main loop. Everything outside the main loop isn't shown, i.e. there are no statistics on the GPU or OSG rendering threads (use the OSG statistics screen for these).<br />
<br />
* Title bar shows average and worst case frame rate. In a perfect world, all frames should be spaced evenly, so both values should be almost identical. When frames are produced unevenly, then a larger difference between the worst and average frame rate is visible. Needless to say, we should try to get FG to deliver frames evenly, so movements look smooth.<br />
<br />
* Main table shows statistics on the individual subsystems. Helps to identify how much time certain systems currently consume, or which are responsible for jitters resulting in uneven frame rates.<br />
<br />
* A bit background on the FG subsystems may be necessary though to really judge what's going on:<br />
** For example, you'll see the "nasal" subsystem consuming almost no time at all, so it looks great. However, almost all the nasal code runs in timers, and timers are driven by the "events" subsystem. So, to judge Nasal performance, you'll mainly need to look at "events" (and yes, you'll see time being consumed and jitters being produced there, which is related due to Nasal's current MARK/SWEEP Garbage Collector implementation, i.e. see: [[Improving Nasal]]).<br />
** The "tile-manager" an "ai-model" subsystems may also contain time consumed by the Nasal engine, since each scenery tile and each AI/MP aircraft may trigger a Nasal script ("load"/"unload" hooks).<br />
** The GUI system is another subsystem which may trigger Nasal hooks<br />
** While it is true that the current Nasal mark/sweep garbage collector has been shown to cause occasional stuttering under certain circumstances, the system monitor in its current form is '''not''' suitable to tell you the difference between a badly coded "rogue" script causing stutter or the stuttering being really caused by the Nasal GC. Also, it is worth noting that following good coding practices may actually help decrease the overall pressure on the GC, i.e. by keeping the number of references to be traversed low and pretty constant, but also by not calling unneeded code too frequently using timers or listeners.<br />
<br />
* At the moment, it is unfortunately not yet possible to get timing statistics for individual Nasal scripts or sub modules, but this is something that has been requested by a number of users and so we are looking into making this possible eventually.<br />
<br />
* Statistics data is only collected while the dialog is open (or you manually set /sim/performance-monitor/enabled).<br />
<br />
Anyway, this alone isn't improving anything yet, but having a GUI to conveniently monitor performance will hopefully help us to see where exactly we're having issues - and help us to improve...<br />
<br />
= Debugging stuttering =<br />
<br />
To put it simple, vertex shader performance is affected by the amount of detail visible in the geometry of scene (number of vertices visible), and of course shader complexity itself, while fragment performance is affected by screen resolution(or window size if you run it windowed) and shader complexity as well. They both affect framerate in the end, since the frame needs to be finished before being put up for display.<br />
Frame delay might be affected by a lot of other stuff, but it's a better measure of smoothness since it displays the "longest" time it had to wait for a frame in a certain amount of time.<br />
There might be some performance lost in high detail scenes, due to the culling (visibility check, and hiding of faces facing away from the camera, or being behind other faces, or too small to display (openscenegraph is smart about that one and it won't "display" faces/parts of objects that would end up too small)) that needs to be done on the scene before it goes through the shaders.<br />
<br />
To test if it's a graphics performance issue, you'd do a couple of tests.:<br />
<br />
First load up the ufo, oevr detailed scenery, remain static, don't move the view around. Check framerate and frame delay. If they're consistent with each other it might be a graphics performance issue, if not you can be sure there's some other subsystem that does background processing and needs to finish it's stuff.<br />
<br />
Move the view around, do you get stutters? If you do, then there's some pressure on your video card's RAM. As it needs to load the new geometry and textures that come into view, it might not have enough space left, so it might need to offload the "old" ones. Even like this framerate should stabilise once you stop moving the view around, or once the rate of movement is slow enough so that the video card can keep up.<br />
<br />
Fly straight and level, at reasonable speeds, keeping the view fixed. Do you get stutters? Is framerate consistent with frame delay? If it is, and you get low fps, again it might be a graphics issue, as new random objects come into view and/or the trees shader creates new ones in the distance. If not I's still suspect another susbsytem being the culprit.<br />
<br />
You can repeat these with some aircraft, see if and how things change.<br />
<br />
In short: if the framerate '''varies along with the Frame Delay''', then it's a graphics performance issue. If framerate is pretty stable, and Frame Delay '''varies more or less wildly''' I'd suspect some other subsystem being the culprit and causing more or less periodic delays as it needs to do it's stuff.<br />
<br />
= Interpreting the OSG on screen stats =<br />
<br />
[[Image:OSG-OnScreen-Stats.png|thumb|400px|Screenshot showing the OSG on screen stats]]<br />
<br />
You can also try to play with osg's frame statistics, you can switch that on from the debug menu.<br />
<br />
Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens <br />
to be a problem.<br />
<br />
A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.<br />
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!<br />
<br />
Once your orange bar is longer than the yellow one, you can start to care for <br />
the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very <br />
different on the same shader.<br />
<br />
And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible.<br />
<br />
== References ==<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35202.html<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html<br />
<br />
<br />
[[Category:Howto]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_January_2012&diff=39649FlightGear Newsletter January 20122012-01-25T03:41:26Z<p>Tom-cat: /* In the hangar */</p>
<hr />
<div>{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
== Development news ==<br />
<br />
=== 2.6.0 release preparations ===<br />
On January 17, the release branches were created from our [[Git]] repositories. From then on, no new features (and aircraft) shall be pushed. Only bug fixes are accepted.<br />
<br />
FlightGear 2.6.0 will be released on February 17!<br />
<br />
=== Experiment: A new bounty system ===<br />
If somebody would like a specific feature implemented, it will be posted in the wiki. Then if somebody wants to take on the development, they can start it and if they feel they have fulfilled the requirements, they submit the project to the person who is offering the bounty.<br />
<br />
If it is a feature that many people want, quite often more people are adding to the bounty and then each person decides individually if the result fits their ideas and if they want to pay the bounty.<br />
<br />
A bounty is a specific amount of money for completing a specific task which can be claimed by an individual or group which completed that task.<br />
<br />
Read on at [[Bounty (Overview)]].<br />
<br />
== Lightfield shaders ==<br />
As part of the ongoing efforts to make the skydome scattering [[shader]] blend seamlessly into the terrain under all conditions, substantial work on getting sunrise and sunset conditions right has been done.<br />
<br />
The eventual solution to the problems are lightfield shaders - the shader doesn not assume a single light source for the whole scene, but computes the incident light intensity and hue for each point of the scene dependent on position and altitude. This turns out particularly tricky for the fog, as the visible fog color is really a line integral along points with very different lighting - which is too slow to do real-time, so a good approximation scheme has to be used. The development effort for the lightfield shaders is easily five times the effort for the original terrain haze shader which handles everything during daytime - which illustrates a bit how complex problems sunrises are.<br />
<br />
The shaders handle a variety of conditions and generate spectacular scenes, from the first glow of the predawn sky, via high altitude clouds lighting up before the terrain to full daylight.<br />
<br />
{|<br />
|[[File:Lightfield_shader12.jpg|200px|thumb|Predawn sky light]]<br />
|[[File:Lightfield_shader02.jpg|200px|thumb|Takeoff in predawn light]]<br />
|[[File:Lightfield_shader05.jpg|200px|thumb|High altitude cloud glow]]<br />
|}<br />
<br />
Among other things, the lightfield allows mountain summits and high altitude clouds to be illuminated by morning light before the lower terrain lights up. The scene is rendered faithfully from ground level up to low Earth orbit where the terminator line becomes visible, distorted by the terrain elevation pattern. As an example, here's the Alaska range from 24.000 ft and from 240.000 ft:<br />
<br />
<br />
{|<br />
|[[File:Lightfield_shader01.jpg|200px|thumb|Alaska range from 24.000 ft]]<br />
|[[File:Lightfield_shader04.jpg|200px|thumb|Alaska range from 240.000 ft]]<br />
|}<br />
<br />
The action of the shaders interfaces with the environment conditions. For instance, high altitude haze makes the indirect ground light more red than blue since it causes substantial backscatter to the ground.<br />
<br />
{|<br />
|[[File:Lightfield_shader06.jpg|200px|thumb|Sunrise without high altitude haze]]<br />
|[[File:Lightfield_shader03.jpg|200px|thumb|Sunrise with high altitude haze]]<br />
<br />
|}<br />
<br />
Cloud cover blocks the incident direct light on the haze layer and cause a change in hue of the haze illumination. The Local Weather system provides the necessary interface information - for instance at the egde of a cloud layer, direct light can reach underneath the layer and illuminate the haze, causing a change in the shader response. Also, the self-shading of the haze layer leads to a different haze hue on the ground and at higher altitude.<br />
<br />
{|<br />
|[[File:Lightfield_shader07.jpg|200px|thumb|Sunrise in moderate cloud cover]]<br />
|[[File:Lightfield_shader10.jpg|200px|thumb|Sunrise in thick Stratus cloud cover]]<br />
|[[File:Lightfield_shader11.jpg|200px|thumb|Sunrise in strong cloud cover at layer edge]]<br />
|}<br />
<br />
For low sun, additional shading of the terrain occurs - this is not shading of the terrain itself (which would be reasonably easy to approximate) but shading of the haze by the terrain. This effect goes away when the light attenuation in the fog is too strong:<br />
<br />
{|<br />
|[[File:Lightfield_shader08.jpg|200px|thumb|Haze shading for high visibility]]<br />
|[[File:Lightfield_shader09.jpg|200px|thumb|Haze shading for low visibility]]<br />
|}<br />
<br />
All these effects do not currently mesh with other shaders. While eventually an integration with other projects is discussed, the lightfield shader code will hopefully make its appearance on Git soon as an optional feature.<br />
<br />
As a preview, here's what may come next - a mode detailed light attenuation model in which the darker hue of the fog beneath clouds is really prominent.<br />
<br />
{|<br />
|[[File:Lightfield_shader_next.jpg|200px|thumb|More detailed attenuation model]]<br />
|}<br />
<br />
== Interview with a contributor (Durk Talsma) ==<br />
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''<br />
<br />
* '''What is your forum nickname?''' <br />
Hehe, guess once. ☺<br />
<br />
* '''How long have you been involved in FlightGear?''' <br />
Almost since the beginning, actually. I first heard about the project in 1997, when I got an email from Curt Olson, in response to a posting on the usenet newsgroup rec.aviation.simulators.<br />
<br />
* '''What are your major interests in FlightGear?''' <br />
I like the open nature of the project and the possibility to contribute at various levels. <br />
<br />
* '''What projects are you working on right now?''' <br />
I am actually doing several different things for FlightGear. My main project is developing a fully integrated AI air traffic system that contains autonomous vehicles, an ATC system that interacts with both AI controlled aircraft and with the user controlled aircraft. In addition to that, I am one of the editors of the main website, editor of the FlightGear facebook page, involved in the release process, code committer, and organizer of the annual FlightGear booth at FSWeekend in Lelystad (EHLE). In addition, I have recently taken over the administrator role for taxidraw. <br />
<br />
* '''What do you plan on doing in the future?''' <br />
I don’t expect the AI system ever to be finished, so I’m fully concentrating my coding efforts on this project. <br />
<br />
* '''Why is it that you are interested in flight simulation or aviation in general?'''<br />
As a kid I was fascinated by space travel, the Apollo missions to the moon, etc, watching every program on TV, and reading every book I could lay my hands on. As a six-year old, I visited Schiphol (EHAM) airport for the first time, and that sparked my fascination for the big jet airliners. Kind of like every kid at one stage, I wanted to become a pilot. My real interest in aviation didn’t start until I was nearly 20 though, after visiting an airshow at Leeuwarden airforce base (EHLE). This was around the same time as when I got my first PC, a second hand 286DX, which I bought from a relative living in Germany, with a 40 Mb hard disk and 1 Mb of ram. It had a German version of Microsoft Flight Simulator 4.0 preinstalled. So, in addition to learning to “fly” I learned the German word for “crash” as well. <br />
<br />
* '''Are you happy with the way the FlightGear project is going?''' <br />
Yes absolutely. We are currently in the process of further improving our infrastructure, by setting up things like the release plan, formalizing the rules for commit access, aircraft maintenance, and we’re brainstorming about feature requirements for the long term. Firm ideas are present for modularization of the FlightGear code, and some ideas for an integrated launcher GUI have recently been coined in a very informal setting. It will certainly take quite some time before these plans are all realized, but I think that the project is more vital and alive as ever. I’m also just amazed at some of the recent developments, such as Frederic Bouvier’s project Rembrandt, Thorsten Renk’s, local weather system, or Martin Spott’s ongoing efforts to build a unified infrastructure for scenery generation. <br />
<br />
* '''What do you enjoy most about contributing to FlightGear?'''<br />
I think there are a number of aspects that I really enjoy. One of them is the collaboration with other people. Being part of the development team, we’re all pretty much equals, and regardless of one’s age, background, occupation, political or religious conviction, we all share something we like and like to collaborate on. That is really enjoyable. It may also happen that somebody just jumps in and finds a solution in no time for a problem that has been cracking my brain for ages. For example, Adrian Musceac, recent work on generating AI traffic patterns was really something amazing. Likewise, I enjoy the interaction with many other talented people, such as Brett Harrison, who’s just so amazing at making convincing liveries. Obviously there are many other talented people around whom I really enjoy working with and it’s a shame I can’t name them all. Secondly, I also really enjoy having the privilege of being the first to experience a new feature for the first time. I was the first person ever to see the sun and moon appear in a desktop Flight Simulator, and that is a little bit special. <br />
<br />
* '''Are there any "hidden features" you have worked on in FlightGear that new users may miss?'''<br />
Yes, my original contribution to FlightGear was some code to calculate the position of the Sun, Moon, and even the planets. Both the sun and moon are pretty much taken for granted now, but back then (in 1997) FlightGear was the first PC based simulator that actually had a physical rendering of the sun and moon! Nobody will probably even see the planets, but I got the code almost for free, once I figured out how to calculate the solar and lunar positions, so their a little bit of an Easter egg. After finishing the celestial code, and before starting the AI traffic system, I initiated many projects that I subsequently handed over to others. As such, I have extended the time calculation code to deal with local time, and to allow the user control over the time of day, and implemented the original graphical user interface (GUI) system, and the original 2D cloud layers.<br />
<br />
* '''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' <br />
Be optimistic, be naïve, be realistic, and start modestly. Set yourself an attainable goal! I should probably explain what I mean by this. When we started out, back in 1996-1997, we were what I would now describe as incredibly optimistic in the sense that we believed that we could pull this off, but we were also somewhat naïve in the sense that we really didn’t have any firm idea about the challenges that lay ahead. But, we were able to pull it off, so this shows that we were right after all. But, if you want to contribute don’t start with your magnum opus. Before starting out, take some time to familiarize yourself with the project, get to know the code base, data structure or workflow. In addition, making a good first impression helps. Over the years we’ve seen a tremendous amount of grand ideas and not many of them have materialized, so we’re naturally a little apprehensive you may not find an immediate warm welcome, but if you do come up with a well thought-out idea, you may convince the development team, especially if you can substantiate your ideas with some working code to back it up. <br />
<br />
* '''Have you previously used other flight simulators or simulation software in general?''' <br />
Well, as mentioned before, I started out with FS4, and have pretty much had every version since then, until FS2004. The latter version got me interested in the AI system. When I started playing with the FS2004 equivalent of the ATC system I and began to notice its programming flaws. Determined that I could do this better, I started drawing out my own plans, and since than, I haven’t really touched any other simulator. <br />
<br />
* '''How does FlightGear compare in your opinion?''' <br />
I like FlightGear better because it’s a platform that is constantly moving. I almost exclusively run the cutting edge development version, so occasionally you’re in for a little surprise. Be it positive or negative. But that keeps things a little exciting to me. <br />
<br />
* '''Do you remember what first got you interested in FlightGear? How did you learn about FlightGear? In other words, why did you actually download and try FG?''' <br />
Yeah, that’s a long story. I was reading the usenet rec.aviation.simulators quite frequently at the time, had been exploring Linux for a few years, and finished my C++ programming course at university. This was around 1997, so the Linux distros weren’t as advanced as they are these days, and you still had to do quite a lot yourselves. One particular afternoon, I came across a usenet posting, which read “OPEN LETTER TO ALL FLIGHTSIMULATOR DEVELOPERS”. This was around the time that Microsoft FS97 was the latest version, and many users were dissatisfied. The original poster wanted to write a letter, on behalf of every dissatisfied user, to ask for a better version, asking the big game companies to incorporate their wish list. I responded to the thread, stating that if we really wanted a sim of our own, we should probably do it ourselves. I remember being a little anxious, because I wasn’t sure whether I would actually be able to substantiate that claim, if we were to follow it up. So, a few days later, I was actually a little apprehensive when I opened up my mailbox and found an email from a guy named Curt Olson, inviting me to have a look at, what would eventually become the flightgear.org website. Well, the rest is history I guess...<br />
<br />
* '''What was your first impression about FlightGear?''' <br />
That’s a really interesting question, because there was no FlightGear so to speak of. When I joined, Curt had hacked together a few proof-of-principle demos; the one I downloaded was called linux-demo-0.0.7.tar.gz, if I recall correctly, and it consisted of a small sample of elevation data from a chuck of terrain near Arizona, source code of a primitve (by today’s standards) OpenGL based viewer, a copy of Bruce Jackson’s larcsim FDM, and a simple keyboard interface. But it was exciting to get it to compile, and run!<br />
<br />
* '''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?'''<br />
It’s scalability, open architecture, and the fact that it can be a great test bed for ideas, as well as the fact that there is no need for third party add-ons. By bringing every suitable user contribution into a single repository, we essentially create our own add-ons, and in the long run that should remove the burden from the end user to search for extensions. <br />
<br />
* '''Do you think it is necessary to know how to program in order to contribute to FlightGear?'''<br />
No way. In fact it never really has been a requirement, even in the old days when there was a lot more emphasis on C++ development, we already had a need for non-coding developers. Think about documentation writers, etc. These days, the balance is actually really shifting away from programming to artwork. The FlightGear world is essentially still largely an empty place, so we really have a need for high-quality buildings. Many of the exciting developments going on right now are in the development of new scenery textures, 3D modeling, and livery painting. These are actually skills that I essentially lack, so I have a lot of respect for the people working in these areas. <br />
<br />
* '''Have you ever used FlightGear professionally or for educational purposes?''' <br />
I once tried in my previous job, but the computer we bought for the project had serious overheating issues, so the project never really came off the ground. In the mean time, I found a different job, so the project was shelved. <br />
<br />
* '''What about FlightGear as a "game", do you think it can be used as such?''' <br />
Probably, I like to use FlightGear purely for fun, so usually I just make up my own challenges, such as performing a bad weather landing, taking off and landing on an aircraft carrier, or playing with my latest AI/ATC code. Once finished, the ATC code will add a little bit of a game element, because it will expect you to fly specific routes, arrive at specific locations at a specific time, so as not to clash with other traffic etc etc. The system isn’t finished yet, but with some hacking I did quite recently manage to complete a traffic circuit under guidance of the ATC system, and it’s quite tricky to do right. So, there are some “gamey” aspects of FlightGear that are quite realistic and hopefully challenging. Having said that, I see absolutely no need for any formal gaming rules, or game like features such as setting off explosives and the like. Like many of the other developers, I like to keep FlightGear civil(ized). I don’t object to simulating military aviation though, as long as it doesn’t serve the purpose of glorifying death and destruction. <br />
<br />
* '''On average, how much time do you spend working with/contributing to FlightGear?'''<br />
Hard to say, it varies quite a bit with my day job requirements, but I think on average maybe one or two hours a day.<br />
<br />
* '''Which of the more recent FlightGear developments do you consider most interesting/appealing?'''<br />
There are quite a few. Of the individual projects, I really think that project Rembrandt (Frederic Bouvier’s shadow rendering code) is really exciting. But so is the new effort to unify all the shaders, the atmospheric haze and scattering, and Thorsten Renk’s local weather. I’m also quite happy with the progress we made with the AI traffic/ATC system, even though it’s not finished yet. But, what I think is perhaps even more exciting are some of the long-term infrastructural changes we have recently discussed. I can’t say too much about that yet, because many of the ideas haven’t been formalized yet, but making FlightGear more modularized by making use of HLA technology, and perhaps a more integrated GUI and launcher program are some of the exciting developments that I can see happening in a few years from now. <br />
<br />
* '''Is there some feature that you'd truly like to see in FlightGear one day?''' <br />
Yeah, there are some. Obviously, I’d like to see my own project come to it’s full potential, but in addition to that, I would like to see full scenery development of the polar regions of our planet. One year ago I visited Antarctica in real life, and this is just a very exciting area for flying. I’d also like to see the possibility of lower earth orbital space flight, more seamless terrain textures.<br />
<br />
* '''What do you think could be done to attract even more new users and contributors to FlightGear?''' <br />
Establish a good balance between developing new stuff and doing some public relations work. For the project the key question for survival is not to attract many users, but to attract potential contributors. Obviously, the way to do this is to attract many users, and to hope that there will be a few potential contributors among them. <br />
<br />
* '''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' <br />
Nothing really special; just use your everyday courtesy, and keep realizing that we’re all volunteers. I’m usually not that active on the forum or mailing list, but I can tell from 15 years of experience that an intelligent and reasonable response is far more likely to create some momentum than a hurried response that is written in a spur of emotion. Also, I have observed that there is hardly any relation between action and words on either the mailing list or the forum. So when your new to the community, just hang around, get to know the characters and try to establish whom you can trust to be a knowledgeable source of information and who just raises a lot of dust. <br />
<br />
* '''Have you ever recommended FlightGear to other users, friends/family?'''<br />
Not really, my friends and family aren’t really into flight simulation.<br />
<br />
* '''Is there anything else you'd like to share with us?''' <br />
Yeah, have a lot of fun, and if you can try to contribute something to the project. <br />
<br />
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX<br />
<br />
== Snapshot releases ==<br />
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshots depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].<br />
<br />
The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].<br />
<br />
== Nasal for newbies ==<br />
<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
<br />
== In the hangar ==<br />
<br />
All the way back in May 2011, we adopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.<br />
<br />
=== New aircraft ===<br />
<br />
The '''Curtiss JN-4 "Jenny"''' has been added by helijah.<br />
<br />
* [http://helijah.free.fr/flightgear/les-appareils/jenny/appareil.htm Download page]<br />
<br />
=== Updated aircraft ===<br />
==== Douglas DC-3 C47 ====<br />
The [[Douglas DC-3-C47|Douglas DC-3 C47]] has been updated by the PAF team. The improvements have mainly been made in the cockpit because that is where the pilots spend most of their time (hopefully!), but many other details have been given around.<br />
<br />
* [http://equipe-flightgear.forumactif.com/t835-hangar-de-la-paf Download]<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=4&t=13629 Forum topic]<br />
<br />
=== Liveries ===<br />
All liveries that were not available as downloads have been removed from the [[livery database]]. Most of those got lost when the former server suddenly quit (all the way back in December 2009). As we were able to save the list of liveries, they ended up in the database eventough the files got lost.<br />
<br />
To save liveries from future server failures, backups are nowadays made on a regularly basis.<br />
<br />
== Scenery corner ==<br />
=== Topologically clean datasets ===<br />
[[File:IJburg_clc2000_vs_clc2006.png|thumb|270px|A Dutch artificial island currently under construction, as visualized with CLC2000 (top) and CLC2006 (lower) and [[OSM]] data.]]<br />
Martin now has what should be topologically clean CLC2000v15 and VMap0 edition 5.0 datasets. These have been loaded into the [http://mapserver.flightgear.org/ Landcover-DB] as replacements for the old VMap0 and CLC layers.<br />
<br />
Thanks to the great folks at GRASS GIS, most notably Markus M., the procedure of cleaning large vector datasets like [[CORINE]] is now a matter<br />
of just a few days and runs on a machine with far less than 32 GByte of main memory! One year ago, cleaning CORINE took about one and a half<br />
months to complete just one single (!) of multiple iterations and you never knew if somebody would reboot the server while the job was still running (which actually happened several times).<br />
<br />
Having topologically clean datasets is a very important step for at least two reasons:<br />
# TerraGear's overall stability is expected to increase with topologically clean vector data.<br />
# Merging custom land cover data (like John Holden's great work) into the "Custom Scenery" layer (at MapServer) had been failing in some cases due to topological inconsistencies. These failures are expected to disappear with topologically clean vector data.<br />
# As soon as the various tools are working in a predictable manner, the driving motivation behind all the effort can be revived, which is to build an infrastructure for re-compiling the respective terrain tiles on a regular, maybe daily schedule after the land cover has been updated in a certain region.<br />
<br />
A clean CLC2006 is provided as well, but because that one's still incomplete (and work in progress, actually) CLC2000 is considered more important. CLC2006 focused mainly on the identification and mapping of land cover changes between 2000 and 2006.<ref>[http://sia.eionet.europa.eu/CLC2006 Corine Land Cover 2006, Eionet]</ref> All land cover changes bigger than 5 ha have been mapped. CLC2006 is significantly more up to date in some areas, as can be seen in the image on the right.<br />
<br />
=== TerraGear GUI updates ===<br />
After a couple of months of little (to none) development, Gijs released a new Windows binary of the [[TerraGear GUI]]. Other OS are supported, but require it to be build from source. <br />
<br />
The GUI runs pretty stable now, provides helpfull error messages and can guide you through the entire process of scenery generation. Updates include:<br />
* OpenStreerMap added to the automatic download feature. Material suggestions are given as well.<br />
* Bring up to date to today's TerraGear builds.<br />
* Most tools have a progress bar to give you a live overview of the progress.<br />
* Remove unnecessary texts and error messages.<br />
Besides all that, several (small) bugs have been fixed.<br />
<br />
=== Dutch windturbines ===<br />
[[File:Prinses_Amaliawindpark_overview.png|thumb|270px|Overviewing the 60 wind turbines of Prinsess Amaliawindpark, 20km west of the Netherlands.]]<br />
The Netherlands have slightly less than 1900 windturbines at the moment. Since this month, 757 of them are in FlightGear!<br />
<br />
Adding them is relatively easy. Since we have a generic windturbine model available (<tt>Models/Power/windturbine.xml</tt>), it's just a matter of finding the GPS coordinates. Some of the larger windparks list locations on their websites. Other windturbines can be positioned based on the FlightGear scenery (with [[CORINE]] data, for more accuracy), or via satellite imagery. Some countries even have a site similar to [http://www.w-i-n-d.nl this website] from the Dutch government, that has a map that shows the locations of all windturbine(park)s.<br />
<br />
Locations for windturbines and other shared objects can be easily submitted via [http://scenemodels.flightgear.org/submission/shared/ the new submission form], that we mentioned in last month's newsletter.<br />
<br />
For the offshore Prinses Amaliawindpark, a custom windturbine model has been made. Resembling the Vestas V80-2.0 MW edition. [http://scenemodels.flightgear.org/modeledit.php?id=2418 The model] can be easily re-used on other offshore windparks, via the method described above.<br />
<br />
=== Airports ===<br />
==== Congonhas - Brazil ====<br />
[[File:Grupofgbrsmall.png|right]]<br />
The Airport of Congonhas is currently being modeled, completely from scratch, by the [http://www.grupofgbr.com.br Grupo FG BR]. Download our logo and link us, please.<br />
{{#ev:youtube|tUQCMTmQ-5Y}}<br />
<br />
== FlightGear users ==<br />
=== 360 degrees motion simulator ===<br />
''Contributed by Samuel DeRose''<br />
<br />
Several years ago during a trip to Washington DC, my family got tickets to a flight simulator ride at the [http://www.nasm.si.edu/ Air and Space Museum]. All of us were amazed at the innovation of the Smithsonian's interactive simulator ride, having grown accustom to the common, mediocre, hydraulic-platform simulators often seen at carnivals and amusement parks. These simulators could roll 360 degrees, continuously, and could tilt about 30 degrees along the pitch axis.<br />
<br />
Inspired by that experience, our group ("Team Viper") is attempting to create an even better version. Like the one at the Air and Space Musuem, ours will roll 360 degrees. In addition we also intend to allow 360 degrees of motion along the pitch axis. Since our family are huge Battlestar Glactica fans we thought it would be fun to theme the interior of the simulator as a Viper fighter from the show.<br />
<br />
One big challenge for us is the physical construction of the simulator, but an even greater feat lies in the software to control the motion platform. In order for the game to feel real (and also to avoid motion sickness), the visuals that will be displayed across three 22" monitors need to be fully synced to what the rider feels in his inner ear and his stomach. Thankfully we found FlightGear, which allows us to easily read the plane's flight dynamics from the sim so we can calculate the angles to orient the motion platform.<br />
<br />
More info, videos and updates at the website: [http://www.the-viper.org the-viper.org]<br />
<br />
{{#ev:youtube|brSW-y0dEOo}}<br />
<br />
=== Worldwide unique paragliding simulator ===<br />
ActiveFly is a simulator just for paragliding. It let's you practice paragliding on the ground. <br />
<br />
{{cquote|In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated. The brakes are extended and retracted via servos, simulating steering forces as they occur in a particular situation. The pilot will try to keep these forces constant by pulling or releasing the brakes. His actions can be viewed on a monitor and subsequently evaluated, allowing him to check the results and monitor progress as he develops his piloting skills.|[http://www.activefly.com/simulator_en.htm ActiveFly.com]}}<br />
As visualizing system they use FlightGear. <br />
<br />
Some bigger images which shows the sim in action can be found [http://aufwindfreunde.de/fotoalbum/simulator_training_27022011/simulator_training_27022011.htm in this gallery].<br />
<br />
{{#ev:youtube|YFcHebPaiEs}}<br />
<br />
Maybe they should use some of our new generated sceneries.<br />
But great to see how FlightGear can be used in many ways!<br />
<br />
== Aircraft of the month ==<br />
<br />
== Airport of the month ==<br />
<br />
== Screenshot of the month ==<br />
[[File:C172p-SanFrancisco.png|800px]]<br />
<br />
Cessna c172p near San Francisco flying over the ocean.<br />
<br />
== Suggested flights ==<br />
===Khorog, Tajikistan===<br />
<br />
[[File:Fw190HinduKush.jpeg|right|thumb|Approaching a bank of snow-covered mountains in the south of the Hindu Kush]]<br />
Surrounded by spectacular mountains and nestled in the end of a valley, Khorog Airfield (UT1C) makes an interesting place to land. It can only be approached by flying down the curved valley that snakes in from the North. Flying from here to OPCH (Chitral, Pakistan) at around 500ft AGL all the way is a wonderful way to explore the Hindu Kush mountains.<br />
<br />
If you bring a piston engined aircraft, be prepared to adjust the mixture as you climb - at the highest point in the flight, you will be at around 22000ft. Also, don't forget to carry plenty of fuel - there are very few airfields in the Hindu Kush that exist in FlightGear. This is a scenery bug that will hopefully be fixed in the future.<br />
<br />
More amazing places to visit can be found at [[Suggested Flights]].<br />
<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on YouTube ===<br />
* [http://www.youtube.com/user/FlyTristarairlines?feature=watch Trez] started a new video series Final Approach:<br />
** [http://www.youtube.com/watch?v=Au6eS6Y6sYY&list=PL60A11F004175486E&index=1&feature=plcp episode 1]<br />
* Dave shared a [http://www.youtube.com/watch?v=VInCXCTi6OA nice approach] to El Dorado International Airport (SKBO)<br />
* [http://www.youtube.com/watch?v=nkoQCr47ddY Highway to Hell] by Kamus Tupolev 214 ILS Dusk APP KSFO /--28R--\ /><br />
* [http://www.youtube.com/watch?v=jdBXlKmLXtQ Manual Approach] MD-BFC landing in TNCM<br />
==== 12 Days of Flight Tips ====<br />
From December 26th to January 6th, [http://www.youtube.com/user/osjcag Oscar] uploaded a daily series in which he gave quick tips in flying and the use of FlightGear.<br />
{| class="vatop" valign="top"<br />
! align="left" |<br />
! align="left" |<br />
|valign="top"|<br />
*[http://www.youtube.com/watch?v=RbB5Sn_ag-A Day 1 - FG 2.4 Map]<br />
*[http://www.youtube.com/watch?v=hLB7jui1U5c Day 2 - Useful Keys]<br />
*[http://www.youtube.com/watch?v=L1aNBV7JBIs Day 3 - Animated Jetways]<br />
*[http://www.youtube.com/watch?v=hz1c8nuY62U Day 4 - Approach & Landing tips!]<br />
*[http://www.youtube.com/watch?v=CeFpvAR6sqg Day 5 - Wiki & Newsletter]<br />
*[http://www.youtube.com/watch?v=0HjkFHatYMI Day 6 - Rendering Options]<br />
|valign="top"|<br />
*[http://www.youtube.com/watch?v=_LcZ93Q33D4 Day 7 - Cockpit Instruments]<br />
*[http://www.youtube.com/watch?v=rITkJyTb5-Q Day 8 - Brake After Landing]<br />
*[http://www.youtube.com/watch?v=CLCXwuWvDGQ Day 9 - Virtual Airlines]<br />
*[http://www.youtube.com/watch?v=HdVCVH0XMXM Day 10 - Manual Flight Tips]<br />
*[http://www.youtube.com/watch?v=NeDMwBMg6Gs Day 11 - Multiplayer ATC]<br />
*[http://www.youtube.com/watch?v=9FSdbw_c9qA Day 12 - Crosswind Landing Tips]<br />
|}<br />
Or watch all the episodes in [http://www.youtube.com/watch?v=RbB5Sn_ag-A&list=PL569D227E5E767F3D a playlist].<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
* The [[OpenRadar]] project is looking for a new maintainer.<br />
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Did you know ===<br />
<br />
{{Appendix}}<br />
<br />
[[Category:FlightGear Newsletter|2012 01]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=FlightGear_hangars&diff=32288FlightGear hangars2011-06-12T04:38:48Z<p>Tom-cat: /* Hangars */</p>
<hr />
<div>''See [[Links]] for an overall listing of FlightGear related external websites''<br />
<br />
FlightGear has [[aircraft]] and other content available from 3rd-party hangars, some which are GPL compatible and also included in official distributions while others are independent. Aircraft versions range from requiring a developmental build, to being compatible with the latest primary release, to requiring an older version. <br />
<br />
Be careful with external links! <br />
<br />
=== Official hangars ===<br />
* [http://www.flightgear.org/Downloads/aircraft-2.0.0/ FlightGear Official 2.0 Hangar]<br />
* [http://gitorious.org/fg/fgdata/trees/master/Aircraft Git Hangar] (for [[Git]] builds)<br />
* [http://liveries.flightgear.org FlightGear Liveries]<br />
<br />
=== Hangars ===<br />
* [http://alphashangar.co.nr/ Alpha-J's Hangar] (Aircraft, Liveries, Scenery, AI, etc.)<br />
* [http://www.gidenstam.org/FlightGear/Airships/ Anders Lighter-than-air Hangar] <br />
* <s>[http://bravosflightgear.yolasite.com/ Bravo's FlightGear] (Airbus A318-100) </s><br />
* [http://ltts.crlt.indiana.edu/grn/flightgear/ Buckaroo's Hangar] (Lockheed 1049H Constellation, Grumman Goose, McDonnell Douglas MD-81) (& a yasim intro)<br />
* [http://members.cox.net/davidculp/hangar.html Dave's Hangar] (also [http://daveshangar.blogspot.com/ Dave's Hangar Blog])<br />
* [http://www.sol2500.net/flightgear/aircraft.html DFaber Hangar] (Eurofighter, PC-6, Bf 109, Beufighter, F4U, Ju 52, DH Mosquito, G. Albatross, F-86, and more)<br />
* [http://flier95-flightgear.blogspot.com/ Flier95's Hangar] (Blog format)<br />
* [http://charles.ingels.free.fr/flightgear/ French FlightGear Hangar] (FR) (Aermacchi MB326, Dassault Mirage F1 Mikoyan Gurevitch Mig 31 Foxhound, and more)<br />
* [http://fgnl.freehostia.com/ Gijs Hangar] (Aircraft, Liveries, Scenery, Vehicles)<br />
* [http://pagesperso-orange.fr/GRTux/tux/index-en.html GRTux Hangar] (28+ aircraft and add-ons)<br />
* [http://hcilab.uniud.it/pan/downloads.html HCI Lab - University of Udine] (Aermacchi MB339 Frecce Tricolori)<br />
* [http://helijah.free.fr/flightgear/hangar.htm Helijah FlightGear Hangar] (156+ original aircraft)<br />
* [http://hhfgfs.weebly.com/index.html Hellcat's FlightGear Hangar] (scenarios, skins, film inspired aerospace vehicles) <br />
* [http://www.hoerbird.net/aircrafts.html Hoerbird Hangar] (misc. projects)<br />
* [http://icestar-fghangar.web44.net/ Icecode's & Star's Hangar] (under development)<br />
* [http://mysite.verizon.net/vzeuyecs/ Kent Esbenshade's Boneyard Hangar] (Classic aircraft)<br />
* [http://flightgear.bplaced.de/ longfly's hangar] (not only German!)<br />
** [http://flightgear.bplaced.de/filemanager/aircraft-list/index.html list of all aircrafts] (under development)<br />
* [http://nickfg.blogspot.com/ Nick's FlightGear Hangar] (Blog, CRJ-200)<br />
* [http://members.cox.net/scotsg8r/hangar/ N-SCOT's Hangar] (5+ liveries & mods)<br />
* [http://theomegahangar.webs.com Omega Hangar] (Mobile Stairway)<br />
* [http://sites.google.com/site/pjedvajflightgear/ pjedvaj's Hangar] (Sukhoi T-50 PAK-FA,, Mikoyan-Gurevich MiG-21bis, Pilatus PC-21, Pilatus PC-9M) <br />
* [http://thefancyflightgearhangar.blogspot.com the fancy flight gear hangar] (a few well made aircraft)<br />
* [http://presteshangar.wikidot.com/start Prestes Hangar] (many non-english aircraft articles)<br />
* [http://riktov.synthasite.com/ Riktov's FlightGear Hangar] (BN-2 Islander, Giant Marshmallow Man)<br />
* [http://digilander.libero.it/scighera_fg/index.html Scighera's Hangar] (models & liveries)<br />
* [http://skyopshangar.byethost17.com/ Skyop's FlightGear Hangar] (717, 757-200, A300, A320-family, A330-300, A340-300, ATR 72, CRJ900, Paper airplane, & scenery)<br />
* [http://seahorseCorral.org/flightgear_aircraft.html Stewart's SEA-horse Aircraft Hanger]<br />
* [http://sydhangar.daffodil.uk.com/ Syd's Hangar ] (older 1.9 versions) [https://sites.google.com/site/sydshangar/ Syd's Google Hangar ] (newer 2.0 versions)<br />
* [http://macflightgear.sourceforge.net/home/aircraft Tat's Aircraft for FlightGear] (A6M2 "Zero", J7W, Ki-84, T-4, HondaJet, OH-1, K5Y1, RV-6A, YS-11)<br />
* [http://vicmar.weebly.com/ VicMar] (Yanagisawa Gen H-4, Stung Biker, Quad Bikes, SRN4, Water Skier, G2 Thunderpack, Martin Jetpack)<br />
* [http://www.treborlogic.com/fgfs/hangar/ Yourgod's Hangar: Douglas DC-8]<br />
* [https://www.gitorious.org/airbus-aircraft Airbus Aircraft Development Git] (A320, A330, A340-300, A380 - various authors)<br />
<br />
==== Livery hangars ====<br />
* [http://berwickskins.yolasite.com/ Berwick-skins]<br />
* [http://dliveryhangar.synthasite.com/ Dodger4's Livery Hangar]<br />
* [http://jchnd.blogspot.com/ JcHnd's Liveries for FlightGear]<br />
* [http://mojos-hangar.webs.com/ MOJO's Flightgear Livery Hangar]<br />
* [http://simbabeathangar.webs.com/ Simbabeat's Livery Hangar]<br />
<br />
==== Homepages, blogs, etc. ====<br />
<br />
* [http://geoffmclane.com/fg/index.htm FlightGear Build Centre]<br />
* [http://www.flightgearcanada.ca/ FlightGear Canada] (The home of everything Canadian for FlightGear)<br />
* [http://www.fguk.eu/ FlightGear United Kingdom] <br />
* [http://www.flightgear-germany.de/ FlightGear Germany] (DE)<br />
* [http://flightgear2009.blogspot.com/ Flight Gear Brasil 2009] (non-english)<br />
* [http://www.shialeweb.com/caballerosaguila/news.php Caballeros Aguila] (non-english)<br />
* [http://www.emmerich-j.de/FGFS/index.html jomo's FlightGear Homepage]<br />
* [http://tehwarlock.tk/ Tehwarlock Blog]<br />
* [http://flightgearblog.blogspot.com/ FlightGear Blog] (Last post Dec. 2008)<br />
* [http://www.jaunty.bplaced.net/flightgear/index.php a small FlightGear page]<br />
* [http://www.vivefg.org/ Vive FlightGear!] Aircrafts, scenery, manuals and forum (non-english)<br />
* [http://flightgear.mxchange.org/ Quix0r's FlightGear Website] Simple tutorials and fgdata.bundle<br />
<br />
=== Other FlightGear repositories/mirrors ===<br />
* [http://www.unitedfreeworld.com/ unitedfreeworld] (scenery, plane models, and livery)<br />
* [http://www.flightgearplanes.com Flightgear Planes Website]<br />
* [http://ftp.riken.go.jp/pub/FreeBSD/distfiles/flightgear-aircrafts/ Older versions of FlightGear aircraft] <br />
<br />
=== Old Hangars ===<br />
* [http://croo.murgl.org/fgfs/index.html A-10 and A-6 stuff]<br />
* [http://www.ae.uiuc.edu/m-selig/apasim/Aircraft-uiuc.html UIUC Hangar] (for FGFS 0.7.8, last update 2002) <br />
<br />
=== Related content ===<br />
* [[Table of models]]<br />
* [[Aircraft]] - [[Helicopter]] - [[Vehicle]]<br />
<br />
[[Category:List]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_June_2011&diff=32287FlightGear Newsletter June 20112011-06-12T04:24:50Z<p>Tom-cat: /* Skyline of Dubai */</p>
<hr />
<div>{{newsletter}}<br />
{{TOC_right|limit=2}}<br />
<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
== Development news ==<br />
== Nasal for newbies ==<br />
== New software tools and projects ==<br />
<br />
== FlightGear addons and mods ==<br />
== In the hangar ==<br />
The lightmap has been extended by a "factor property". Aircraft authors can now bind the intensity of a lightmap to a property (eg. <tt>/controls/lighting/panel-norm</tt>), making the lighting more vivid. Read more in the [[Howto: Lightmap|lightmap howto]].<br />
<br />
=== New aircraft ===<br />
=== Updated aircraft ===<br />
'''Bf-109 G14'''<br />
<br />
The Bf109 G14 now has a bump- and specmapped 3D Model, a revised FDM and an improved 3D Cockpit with functional controls. The logo selection system has been added, along with some new liveries. <br />
<br />
The Throttle now sets the desired Manifold pressure and maintains it, even with changing altitude.<br />
<br />
Note to Livery makers: The external textures have been consolidated into one file for easier maintenance.<br />
<br />
{{Gallery|improved Cockpit|109-7.png|new Liveries|109-3.png|bump- and specmapped|109-5.png}}<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Skyline of Dubai ===<br />
[[File:Dubai_skyline.png|thumb|270px]]<br />
Gijs started modeling one of the highest, fastest changing and most interesting skylines in the world: Dubai's. The former village in the desert is <br />
nowadays home to the tallest structure in the world, the largest shopping mall and it has more supertall skyscrapers than any other city. A perfect city to discover by [[C172p]], or one of the [[Helicopter|helis]]. With a great deal of challenging landing spots for the later vehicles.<br />
<br />
So far little over 20 buildings have been modeled, some of which are currently untextured and low-poly. Nevertheless they help give you the right Dubai-feel!<br />
<br />
=== Airports ===<br />
<br />
== Aircraft of the month ==<br />
== Airport of the month ==<br />
== Screenshot of the month ==<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on youtube ===<br />
The channel flightgearUK has been set up on YouTube by Liam, and will soon feature tutorials, video reviews and promotional videos of high quality to show the latest and best features in FlightGear.. It is hard currently to find any high quality videos of FlightGear (with the exception of Oscar and Skyop of course), especially with the most modern of features, and based primarily on Civil aviation- especially in comparison to some of the videos by other flight Sims, so it is a personal ambition of mine to greatly improve the popularity of the sim through mixed media. You can see the very first of the videos right here: http://www.youtube.com/watch?v=rZbpWC5EGv8 Unfortunately recorders for mac are very limited, but I hope to get the framerate up from that first (test) video. Reviews in particular, are yet to be done on youtube for FlightGear- and will be recorded in my own voice ;).<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
<br />
The [http://fgrc.tk/ Flightgear Rotor Club] is kicking off it's 2nd multiplayer event on July 2, 2011. This month's event is a Combat Search and Rescue scenario, which involves going deep behind enemy lines into Laotian territory to rescue two downed airmen.<br />
<br />
See the [http://www.flightgear.org/forums/viewtopic.php?f=10&t=12379 forum topic] for more information about the event.<br />
<br />
=== Virtual airlines ===<br />
=== FlightGear events ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
* The [[OpenRadar]] project is looking for a new maintainer.<br />
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Did you know ===<br />
<br />
[[Category:FlightGear Newsletter|2011 06]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_February_2011&diff=28816FlightGear Newsletter February 20112011-02-25T09:59:23Z<p>Tom-cat: /* FlightGear events */</p>
<hr />
<div>[[image:magagazine.png|link=List_of_FlightGear_Newsletters]]<br />
{{newsletter}}<br />
{{TOC_right}}<br />
''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
<br />
== FlightGear events ==<br />
Anticipating [http://www.linuxtag.org/ LinuxTag 2011], the most important place for Linux and open source software in Europe, a Video Contest has been started [http://flightgear.org/forums/viewtopic.php?f=19&t=11059 at the forum]. We have strong evidence that, again FlightGear will be present at the show with its own booth and the FlightGear presentation team is looking for a video to present the best features of FlightGear in a short movie during the show. The creator of the chosen video wins one of the rare and famous FlightGear t-shirts, a pair of cool 3d-red-cyan glasses and free admission to the LinuxTag 2011 in Berlin, Germany. Deadline for entries is April, 24th 2011 12.00 UTC.<br />
[http://flightgear.org/forums/viewtopic.php?f=19&t=11059 read more..]<br />
<br />
== Development news ==<br />
===Sound files for 3D Audio===<br />
There seems to be some confusion about what types of sound files are supported for 3D audio rendering. Let's explain a bit more about how 3D audio works.<br />
<br />
A 3D audio, or spatialized audio, implementation consists of one listener (like the OpenGL viewer) and multiple audio sources. A listener is placed at a specific location and has an orientation (view direction). Sources are placed in the scene at their own location and have an emission direction which is used to calculate the sound cone for non omni-directional sounds (sound sources that sound louder in one direction and softer or even quiet in the opposite direction). Sound sources can best be seen as a single dot emitting sound waves.The relative positions of the sources and the listener is used to calculate where the sources should be positioned in the listeners sound sphere.<br />
<br />
If a sound source would be anything but mono it is almost impossible to guess how to handle all the channels in 3D space;<br />
* Do they get mixed together?<br />
* Do the tracks get positioned with a slight offset to each other? This in effect means mixing them together when the source is not close to the listener.<br />
* Do they get positioned at the same location but with a sound direction offset of 180⁰? This means mixing them together if the sound is omni-directional.<br />
<br />
There is something to say for any of the choices but you can bet that if one of the three was chosen someone else comes by and wants it to be different.<br />
<br />
For this reason it is specified that only mono files will be used for 3D audio processing and stereo files will be mixed using the stereo mixer instead. Trying to set a position or direction for a stereo file will result in an error like:<br />
''Failed to load WAV file: Unsupported mode within an otherwise usable file type''<br />
<br />
===Lightmaps supported===<br />
{{Main article|Howto: Lightmap}}<br />
[[File:Boeing 747-400 lightmap exterior.png|thumb|[[747-400]] with lightmapped exterior.]]<br />
[[User: Gijs|Gijs]] has been working on lightmap support in FlightGear, with the help of [[User: AndersG|AndersG]]. Lightmaps are image files that define what pixels of a texture should be lighten, how intense and what color. Ideal for night lights on liveries (no need to create a special lights .png file for each single livery; like we used to do) and cockpit panels. Currently there is very limited support for lightmaps. There is not yet a good conditional available for example, and it won't work in combination with other [[shaders]].<br />
<br />
== Nasal for newbies ==<br />
== New software tools and projects ==<br />
===Arduino and FlightGear===<br />
<br />
[[File:Arduinofgfs.jpg]]<br />
<br />
<br />
Get a more real experience flying '''FlightGear''' using real instruments.<br />
<br />
'''Arduino''' is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software.<br />
<br />
'''FlightGear''' IO interfaces allows easy development of hardware that can improve the immersion and realism of flightsim.<br />
<br />
The output protocols allows hardware to act on simulation data in real time.<br />
<br />
It takes minutes to have a LCD panel displaying Speed, Heading and Altitude.<br />
<br />
<br />
The input protocols allows FlightGear to act on hardware events in real time.<br />
<br />
Again, it takes minutes to create a switchboard that would allow you to control:<br />
<br />
* Landing Gear<br />
* Flaps<br />
* Rudder<br />
* Hud on/off<br />
* airbrakes and more.<br />
<br />
<br />
<br />
Sample code is available at [http://gitorious.org/arduinocockpit]<br />
<br />
Videos and Posts on FlightGear Forum at:<br />
[http://www.flightgear.org/forums/viewtopic.php?f=18&t=11146]<br />
<br />
[http://www.flightgear.org/forums/viewtopic.php?f=18&t=11126]<br />
<br />
===OSS Linux headtrack for FlightGear===<br />
Developed by Ralph Glass and Meir Michanie.<br />
<br />
[[File:Headtracking-dialog.resized.png]]<br />
<br />
<br />
'''EasyHeadTrack''' is an Addon for '''Flightgear''' that allows you to use a simple webcam in order to track the pilot position in the x,y and z axis.<br />
'''EasyHeadTrack''' just works out of the box.<br />
<br />
* It is available for '''Linux'''.<br />
* Simple '''FlightGear''' interface.<br />
* Configurable within '''FlightGear'''.<br />
* Just works (no need to recalibrate when it looses track)<br />
* Only webcam required, face tracking with '''opencv''' without any markers<br />
* X,Y,Z axis supported<br />
* Not quite as sensible as marker based solutions but good enough, so no need to wear a funny hat ;-)<br />
<br />
<br />
'''EasyHeadTrack''' is available at [http://gitorious.org/headtrack]<br />
<br />
Videos and Posts on the forum at: [http://www.flightgear.org/forums/viewtopic.php?f=6&t=10664&p=113548]<br />
<br />
<br />
Download the new EasyHeadtrack for FlightGear at [http://gitorious.org/headtrack]<br />
<br />
== FlightGear addons and mods ==<br />
== In the hangar ==<br />
=== New aircraft ===<br />
=== OH-6 Cayuse ===<br />
[[File:OH-6.png|200px|thumb|left|OH-6 over LEMD airport.]]<br />
Icecode and Star have started developing the [[Hughes OH-6 Cayuse]]. OH-6 Cayuse (nicknamed "Loach", after the requirement acronym LOH - light Observation Helicopter) is a single-engine light helicopter with a four-bladed main rotor used for personnel transport, escort, attack missions, and observation.<br />
<br />
=== Updated aircraft ===<br />
<br />
==== Pilatus PC-21 ====<br />
[[User:pjedvaj|pjedvaj]] and [[User:Johan G|Johan G]] started to work on [[Pilatus PC-21]]. FDM will be the same as in original package with new systems and animations added. It has a new high-poly 3D model. New landing gear models and liveries are being developed. Final release will include all glass cockpit with MFD's and HUD. Temporary cockpit in this development stage has only a generic 2D panel.<br />
<br />
==== Mikoyan-Gurevich MiG-21bis ====<br />
pjedvaj resumed his work on [[MiG-21|Mikoyan-Gurevich MiG-21bis]]. Rudder issue is fixed and GSh-23 gun is now fully functional. Landing gear animations are now complete. Further development is concentrated on cockpit and instruments. New liveries are also on the way.<br />
<br />
=== Liveries ===<br />
<br />
== Scenery corner ==<br />
=== Airports ===<br />
====LIMW Aeroport Regional de la Vallee d'Aoste "Corrado Gex", Aosta (Italy)====<br />
[[File:AOSTA_F-sig.jpg|left|thumb|LIMW Aosta (pic by F-sig)]]Another small airport in the Alps, for those simmers who like VFR within mountains, like the Monte Bianco (Mont Blanc) and the Cervino (Matterhorn).<br />
The updating started with the extension of the taxiway to the end of rwy 27 (to reflect works recently done in the reality); the new LIMW.dat has been already forwarded to Martin.<br />
The modelled buildings include:<br />
* The Control Tower<br />
* 3 old fashioned Hangars<br />
* The new hangars (some 130 m long)<br />
<br />
The sliding doors of the 3 old hangars move to shutdown position at sunset (nasal script developed by ot-666).<br />
<br />
The above model are already included in the Repository.<br />
<br />
====LOIU Innsbruck Hospital Heliport (Austria)====<br />
[[File:LOIU_Innsbruck_Hospital_Heliport.jpg|left|thumb|LOIU Innsbruck Hospital Heliport ]]This heliport is located on top of the main hospital building in Innsbruck, just a stone throw away from LOWI airport Austria and the LOJO oamtc helicopter base.<br />
<br />
The model features night illumination and 2 stage obstruction and helipad lights.<br />
<br />
Obstruction and helipad lights are activated at night and if the visibility is below 4500meter + switch to a higher setting for extreme low visibility conditions. Thanks to the help of scighera the lights and the scenery model will work with FG 1.9.1 and up.<br />
<br />
The model will be send to martin as soon as possible, but a preview version is already available at the forum.<br />
<br />
== Aircraft of the month ==<br />
[[File:M18B Dromader 02.png|thumb|center|400px|<center>[[PZL-Mielec M-18 Dromader]] (screenshot)</center>]] <br />
== Airport of the month ==<br />
[[Image:LSZH_001.jpg|thumb|center|400px|<center>[[Zürich Airport|Zürich Airport, Switzerland]] (Non-simulated image)</center>]]<br />
<br />
== Screenshot of the month ==<br />
[[File:Ah-1_vietnam_firebase.png|thumb|center|600px|<center>Firebase-- M113, AH-1 Cobra, and SAMs</center>]]<br />
<br />
== Suggested flights ==<br />
== Aircraft reviews ==<br />
<br />
== Wiki updates ==<br />
===New articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
</DynamicArticleList><br />
===New aircraft articles===<br />
<DynamicArticleList><br />
type=new<br />
count=10<br />
categoryRoot=Aircraft<br />
</DynamicArticleList><br />
===Most popular newsletters===<br />
<DynamicArticleList><br />
type=hot<br />
count=5<br />
categoryRoot=FlightGear Newsletter<br />
</DynamicArticleList><br />
<br />
== Community news ==<br />
=== FlightGear on youtube ===<br />
http://www.youtube.com/watch?v=QdaIA6Y3VSU Busting the Tower<br />
<br />
=== New tutorials and screencasts ===<br />
=== Forum news ===<br />
=== Multiplayer ===<br />
=== Virtual airlines ===<br />
<br />
== Useful links ==<br />
== And finally ... ==<br />
The FlightGear presentation team is asking for your help! To be able to continue the excellent work at events like [[FSweekend]] and [http://www.linxutag.org/ LinuxTag] and to keep the allways growing equipment up-to-date and running, a PayPal account for donations has been set up. <br />
<br />
If you think, they did a good job at presenting and promoting FlightGear and if you want to support them in having the best booth during the show, please consider donating a few Euros, Dollars, Pounds, Crowns, Yen, Francs, Afghanis, Dinars, Pesos or whatever your currency might be to '''donations@flightgear.org''' using [http://www.paypal.com PayPal].<br />
<br />
<small>All donations will be used for the sole purpose of adding to or maintaining the equipment used at the shows. Donations are not tax deductable yet.</small><br />
<br />
<br />
=== Contributing ===<br />
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common misconception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something. <br />
<br />
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].<br />
<br />
=== Call for volunteers ===<br />
The [[OpenRadar]] project is looking for a new maintainer.<br />
<br />
The [[TerraGear GUI]] project is looking for programmers to help create a GUI frontend for [[TerraGear]] [http://flightgear.org/forums/viewtopic.php?f=5&t=7485#p102005].<br />
<br />
The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.<br />
<br />
=== Reminder: Google's Summer of Code 2011 ===<br />
FlightGear project is planning to participate in [[GSoC]] 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all, and has not participated in past years.<br />
<br />
So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to [http://flightgear.org/forums/viewforum.php?f=38 get in touch].<br />
<br />
''Thanks for reading FlightGear Newsletter February 2011''<br />
<br />
[[Category:FlightGear Newsletter]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=User:Tom-cat&diff=27946User:Tom-cat2011-01-27T06:56:02Z<p>Tom-cat: </p>
<hr />
<div>Areas I'm interested in:<br />
<br />
== Infrastructure ==<br />
* Work on an automated test system integrated with the C.I. server (Hudson)<br />
<br />
== Scenery ==<br />
* Help with the San Francisco scenery<br />
* Look at scenery for Italy derived from CORINE landcover<br />
<br />
== Models ==<br />
* Model the Space Shuttle (http://gitorious.org/space-shuttle)</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Harrier&diff=27061Harrier2010-12-29T07:54:13Z<p>Tom-cat: Redirected page to British Aerospace Harrier</p>
<hr />
<div>#REDIRECT[[British Aerospace Harrier]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=PBY-Catalina&diff=27059PBY-Catalina2010-12-29T07:37:16Z<p>Tom-cat: Redirected page to Consolidated Aircraft PBY Catalina</p>
<hr />
<div>#REDIRECT[[Consolidated Aircraft PBY Catalina]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=F-14b&diff=27058F-14b2010-12-29T07:25:46Z<p>Tom-cat: Redirected page to Grumman F-14 Tomcat</p>
<hr />
<div>#REDIRECT[[Grumman F-14 Tomcat]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=F-106-dart&diff=27057F-106-dart2010-12-29T07:25:03Z<p>Tom-cat: Redirected page to Convair F-106 Delta Dart</p>
<hr />
<div>#REDIRECT[[Convair F-106 Delta Dart]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Eurofighter&diff=27056Eurofighter2010-12-29T07:23:49Z<p>Tom-cat: Redirected page to Eurofighter Typhoon</p>
<hr />
<div>#REDIRECT[[Eurofighter Typhoon]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Ec135&diff=27055Ec1352010-12-29T07:21:57Z<p>Tom-cat: Redirected page to Eurocopter EC135</p>
<hr />
<div>#REDIRECT[[Eurocopter EC135]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=E3B&diff=27054E3B2010-12-29T07:21:10Z<p>Tom-cat: Redirected page to Boeing E-3 Sentry</p>
<hr />
<div>#REDIRECT[[Boeing E-3 Sentry]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Cub&diff=27053Cub2010-12-29T07:19:25Z<p>Tom-cat: Redirected page to Piper J3 Cub</p>
<hr />
<div>#REDIRECT[[Piper J3 Cub]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=CRJ-900&diff=27052CRJ-9002010-12-29T07:18:21Z<p>Tom-cat: Redirected page to Bombardier CRJ-900</p>
<hr />
<div>#REDIRECT[[Bombardier CRJ-900]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Cri-cri&diff=27051Cri-cri2010-12-29T07:17:33Z<p>Tom-cat: Redirected page to Colomban Cri-cri</p>
<hr />
<div>#REDIRECT[[Colomban Cri-cri]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Couzinet70&diff=27050Couzinet702010-12-29T07:16:54Z<p>Tom-cat: Redirected page to Couzinet 70</p>
<hr />
<div>#REDIRECT[[Couzinet 70]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=ComperSwift&diff=27049ComperSwift2010-12-29T07:15:48Z<p>Tom-cat: Redirected page to ComperSwift Comper</p>
<hr />
<div>#REDIRECT[[ComperSwift Comper]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Colditz&diff=27048Colditz2010-12-29T07:14:32Z<p>Tom-cat: Redirected page to Colditz Cock</p>
<hr />
<div>#REDIRECT[[Colditz Cock]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=CitationX&diff=27047CitationX2010-12-29T07:10:12Z<p>Tom-cat: Redirected page to Cessna Citation X</p>
<hr />
<div>#REDIRECT[[Cessna Citation X]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Citation-Bravo&diff=27046Citation-Bravo2010-12-29T07:09:32Z<p>Tom-cat: Redirected page to Cessna Citation Bravo</p>
<hr />
<div>#REDIRECT[[Cessna Citation Bravo]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Citation&diff=27045Citation2010-12-29T07:08:34Z<p>Tom-cat: Redirected page to Cessna 550 Citation II</p>
<hr />
<div>#REDIRECT[[Cessna 550 Citation II]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Ch53e&diff=27044Ch53e2010-12-29T07:06:31Z<p>Tom-cat: Redirected page to Sikorsky CH-53E Super Stallion</p>
<hr />
<div>#REDIRECT[[Sikorsky CH-53E Super Stallion]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Ch47&diff=27043Ch472010-12-29T07:04:42Z<p>Tom-cat: Redirected page to CH-47 Chinook Helicopter</p>
<hr />
<div>#REDIRECT[[CH-47 Chinook Helicopter]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=C310&diff=27042C3102010-12-29T07:01:34Z<p>Tom-cat: Redirected page to Cessna C310</p>
<hr />
<div>#REDIRECT[[Cessna C310]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=C150&diff=27041C1502010-12-29T07:00:50Z<p>Tom-cat: Redirected page to Cessna 150</p>
<hr />
<div>#REDIRECT[[Cessna 150]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=C130&diff=27040C1302010-12-29T06:59:53Z<p>Tom-cat: Redirected page to Lockheed C-130 Hercules</p>
<hr />
<div>#REDIRECT[[Lockheed C-130 Hercules]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=CanberraBI8&diff=27039CanberraBI82010-12-29T06:58:41Z<p>Tom-cat: Redirected page to English Electric Canberra</p>
<hr />
<div>#REDIRECT[[English Electric Canberra]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Boeing314&diff=27038Boeing3142010-12-29T06:55:57Z<p>Tom-cat: Redirected page to Boeing 314</p>
<hr />
<div>#REDIRECT[[Boeing 314]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Bf109&diff=27037Bf1092010-12-29T06:55:12Z<p>Tom-cat: Redirected page to Messerschmitt Bf 109</p>
<hr />
<div>#REDIRECT[[Messerschmitt Bf 109]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Beech99&diff=27035Beech992010-12-29T06:53:04Z<p>Tom-cat: Redirected page to Beechcraft Model 99</p>
<hr />
<div>#REDIRECT[[Beechcraft Model 99]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Beaufighter&diff=27034Beaufighter2010-12-29T06:52:07Z<p>Tom-cat: Redirected page to Bristol Beaufighter</p>
<hr />
<div>#REDIRECT[[Bristol Beaufighter]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=B1900d&diff=27033B1900d2010-12-29T06:50:57Z<p>Tom-cat: Redirected page to Beechcraft B1900D</p>
<hr />
<div>#REDIRECT[[Beechcraft_B1900D]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=ASK21&diff=27032ASK212010-12-29T06:48:21Z<p>Tom-cat: Redirected page to Schleicher ASK 21</p>
<hr />
<div>#REDIRECT[[Schleicher ASK 21]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=ASK13&diff=27031ASK132010-12-29T06:47:28Z<p>Tom-cat: Redirected page to ASK-13 sailplane</p>
<hr />
<div>#REDIRECT[[ASK-13 sailplane]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Apache&diff=27030Apache2010-12-29T06:46:36Z<p>Tom-cat: Redirected page to AH-64 Apache</p>
<hr />
<div>#REDIRECT[[AH-64 Apache]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=ANT-20&diff=27029ANT-202010-12-29T06:45:52Z<p>Tom-cat: Redirected page to Tupolev ANT-20</p>
<hr />
<div>#REDIRECT[[Tupolev ANT-20]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Alphajet&diff=27028Alphajet2010-12-29T06:45:03Z<p>Tom-cat: Redirected page to Dornier Alpha Jet</p>
<hr />
<div>#REDIRECT[[Dornier Alpha Jet]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Alouette-III&diff=27027Alouette-III2010-12-29T06:44:11Z<p>Tom-cat: Redirected page to Aérospatiale Alouette III</p>
<hr />
<div>#REDIRECT[[Aérospatiale Alouette III]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Alouette-II&diff=27026Alouette-II2010-12-29T06:43:13Z<p>Tom-cat: Redirected page to Aérospatiale Alouette II</p>
<hr />
<div>#REDIRECT[[Aérospatiale Alouette II]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Albatross&diff=27025Albatross2010-12-29T06:41:29Z<p>Tom-cat: Redirected page to Grumman Albatross</p>
<hr />
<div>#REDIRECT[[Grumman Albatross]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Aerocar&diff=27024Aerocar2010-12-29T06:39:34Z<p>Tom-cat: Redirected page to Taylor Aerocar</p>
<hr />
<div>#REDIRECT[[Taylor Aerocar]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=AH-1&diff=27023AH-12010-12-29T06:38:13Z<p>Tom-cat: Redirected page to AH-1 Cobra</p>
<hr />
<div>#REDIRECT [[AH-1 Cobra]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=AirCrane&diff=27022AirCrane2010-12-29T06:37:16Z<p>Tom-cat: Redirected page to S-64 Skycrane</p>
<hr />
<div>#REDIRECT [[S-64 Skycrane]]</div>Tom-cathttps://wiki.flightgear.org/w/index.php?title=Aerostar-700&diff=27021Aerostar-7002010-12-29T06:35:40Z<p>Tom-cat: Redirected page to Piper Aerostar</p>
<hr />
<div>#REDIRECT [[Piper Aerostar]]</div>Tom-cat