FlightGear wiki - User contributions [en]

FGX

2015-02-25T00:21:43Z

Peteffs: Removing dead links and new capers

{{Infobox Software
| title = FGx
| image =
| developedby = Yves Sablonier, Pete Morgan, Geoff McLane
| initialrelease = 2.2.0
| latestrelease = 2.10.0
| writtenin = C++ (Qt)
| os = Mac, Windows, various Linux distributions
| website = [http://fgx.freeflightsim.org fgx.freeflightsim.org]
}}
'''FGx''' is a cross-platform open source graphical launcher application for [[FlightGear]] using Qt. Development began in early 2011 with the purpose of creating a fast and easy to use tool to launch FlightGear on OSX/Mac hence the "x". While initial development targeted the Apple Mac architecture, the Qt development environment allows for cross-platform compatibility between Windows, Mac OS and various Linux distributions.

== FGx Project ==
* Website at [http://fgx.freeflightsim.org fgx.freeflightsim.org].
* Bugs & Source at [https://github.com/fgx/fgx/ github/fgx/fgx/].

== Supported systems ==
Note that FGx has been tested using the prerequisites listed below and may actually work with different OSes and versions. Feel free to update this list if you have additional information.
* Mac OSX
* Fedora
* Ubuntu/Xubuntu and other debian distributions
* Gentoo
* Windows XP/Vista/7

== Related content ==
* [[FGo!]]
* [[FGRun]]

[[Category:FlightGear front ends]]

Howto:Start core development

2015-02-24T04:22:34Z

Peteffs: /* SimGear */

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

= How the Project works (Suggested reading!) =
Please see this short essay here: http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971

Also see [[Implementing new features for FlightGear]]

= Welcome to FlightGear =

Hi, and welcome to FlightGear!

You have probably come here to learn more about implementing new features for FlightGear.

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.

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.

== Not yet familiar with C++ ? ==

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

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.

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

== Developing without programming is possible and appreciated ==

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

== Coding but not in C++ (scripting) ==

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.

Many new ideas or features won't require any modifications to the C++ source code at all.
You could probably get started and implement many ideas without even touching an IDE or a compiler for quite a while.

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.

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.

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. Here's an overview giving you a rough idea about recent Nasal related efforts:

{{Nasal Efforts}}

For example, the tutorial system built into FG is entirely implemented in scripting space, and fully XML-configurable: [[Tutorials]]

This means that you can create/modify and improve tutorials just by editing plain text files with any conventional text editor.

There are many more things possible using Nasal, just see the wiki.

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.

== Shader programming ==
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).

= Hacking the C++ code =

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

= Initial advice =

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)

* 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]]
* read the documentation (wiki, $FG_ROOT/Docs, $FG_SRC/mini-docs)
* it also helps running DoxyGen or Source Navigator to navigate the various source trees
* start making tiny modifications to existing stuff (aircraft, scenery, source code etc)
* 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)
* register an account at gitorious
* clone the FG project (SimGear, FlightGear, fgdata)
* 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)?
* 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
* subscribe to the developers mailing list
* ask for advice/projects there
* 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)
* coordinate your effort with others, i.e. communicate your intentions early and ask for advice
* release early and often
* don't get frustrated :-)
* enjoy!

= Project architecture =
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.

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.

Once you have satisfied all dependencies and built them in the right order, you can start FlightGear.
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".

The FG source tree is commonly referred to as $FG_SRC, while the SimGear source tree is often referred to as $SG_SRC.

A while ago, Jim Wilson posted the following advice on the devel list:

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.

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.

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.

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
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
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
through the modules to find the code that actually does call the update() (look for references to the class you are interested in).

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
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
are handled in FlightGear. For example the flight instruments are all configured using xml defined references to values in the property tree in
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).

Speaking of instruments, you might want to take a look at how some of the instrumentation configuration (Aircraft/Instrumentation/*.xml files in the
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
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
the property tree.

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.

Welcome aboard and do feel free to post any questions to the list as they come up.

= The source code =

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.

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

The SimGear and FlightGear source trees both make use of the [[Building using CMake|CMake]] build system as of 2012.

The FlightGear project uses the decentralized source code management system "git" see [[Git]] for more info.

The project sources are hosted at gitorious: http://gitorious.org/fg/

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

You can find tutorials for different platforms/OS at the end of the article.

= Continuous Integration (CI) =

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/

Please see [[FlightGear Build Server]] for more information.

= Patches =

Regarding patches, please see: [[Submitting Patches]].

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

In general, the FlightGear gitorious project is the entry point for new developers: http://gitorious.org/fg/

Some more recommendations can be found at [[Recommended Project Policies]].

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.

To send patches upstream, gitorious merge requests are recommended. The details of which are covered at [[Merge request]].

A list of active FlightGear core developers is to be found at [[:Category:FlightGear Core developers|FlightGear Core developers]].

= Ongoing efforts =

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

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

The FlightGear state of all HLA things is documented at: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

Introductory HLA resources are collected at: http://wiki.flightgear.org/Developing_with_HLA#Resources

In developer's terms, that mostly boils down to:
* expect more and more scenery functionality to be procedurally added (e.g. [[Terragear_roadmap#Runtime_Airport_Generation|runways, taxiways]], whole airports)
* expect more and more viewer functionality to be decoupled from the simulator (fgviewer being the prototype here)
* expect more and more viewer/GUI features to be made optional through a [[FlightGear Headless]] mode during startup
* expect the 2D rendering backend (GUI, instruments, HUDs etc) to be increasingly unified through the [[Canvas]] system
* expect [[FGPanel|FGPanel standalone panel rendering]] functionality to be merged back into the main fgfs code base, provided through [[FGViewer]]
* expect more work towards better system-wide reinit/reset support: http://wiki.flightgear.org/Reset_%26_re-init
* 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]
* expect FDMs to become re-initializable at runtime, expect support for multiple FDMs per session
* 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
* 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
* expect the existing multiplayer system to be completely phased out and replaced by HLA
* expect [[Property Tree/Native Protocol Slaving|multi-instance slaving]] to be formalized and reimplemented through [[FGViewer]] and [[HLA]]
* expect Nasal scripting integration to be increasingly decoupled from the fgfs main loop
* expect OSG CompositeViewer to be eventually adopted (almost certainly not during the next 12 months though)

Basically, help facilitate these change by at least not making these things more difficult through your own code

For doxygen docs, see: http://docs.freeflightsim.org/

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
If you have anything to add, please feel free to create a new wiki article.
Also, contributing such news to the FlightGear [[Next newsletter|newsletter]] is another good idea.

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

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.

Also, there's another outdated category titled "Code Cleanup": http://wiki.flightgear.org/Category:Code_Cleanup

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

In other words: '''pick your poison :)'''

= Issue tracking =

Ideas (feature requests actually) and bug reports are ideally reported using the issue tracker here: http://flightgear-bugs.googlecode.com/

Please make sure to first search the issue tracker before possibly reporting a dupe, thanks!

Bug reports should ideally be accompanied with a test case to reproduce an issue, but also a backtrace, see: [[Howto:Debugging FlightGear Crashes#Debugging Segfaults & Obtaining Backtraces]].

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.

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.

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

= Talking to fellow FlightGear developers =
Most core development related discussions are handled using the developers mailing list: http://www.flightgear.org/mail.html

There's a fully searchable archive available here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/

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/

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.

= Flight dynamics =
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.

For JSBSim, please see: http://jsbsim.sourceforge.net/

= Important docs =
There's a wealth of documentation to get you started available in [http://gitorious.org/fg/fgdata/trees/master/Docs $FG_ROOT/Docs]

API docs auto generated from source are at http://api-docs.freeflightsim.org/

Even more documentation can be found in our wiki, here: http://wiki.flightgear.org/

The wiki is divided into different "portals", you'll probably be interested in the developers portal here: http://wiki.flightgear.org/Portal:Developer

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

== FlightGear ==
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.
But complex C++ features (such as advanced templates or meta-programming are not too common actually).

One of the simplest ways to add new features to FlightGear is adding new commands to it, so called "fgcommands" (i.e. "FlightGear commands").
For additional information, please see this tutorial: [[Howto: Add new fgcommands to FlightGear]].

== Programming resources ==
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]].

== SimGear ==
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++".

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://api-docs.freeflightsim.org/simgear/

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.

Also, you can get a fair amount of information out of the FG sources by running them through doxygen, too.

== Plain C ? (Nasal) ==
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

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

The longest-standing issue related to Nasal scripting is fixing its Garbage Collector (GC) to become generational, incremental or even concurrent, this is to reduce main loop impact (frame rate & frame spacing), see [[How the Nasal GC works]] to learn more. Almost certainly, we're going to adopt an existing GC library, or even implement an interface to experiment with different GC schemes, and allow those to be selected at startup.

Adding new extension functions to the built-in Nasal interpreter is documented here: [[Howto: Extend Nasal]].

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

None of this requires any C++ knowledge!

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

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 using the [[Nasal/CppBind]] framework, 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_cppbind.cxx source code, which demonstrates how this is done.

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.

= Getting started =
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

== Talk about your plans ==
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.

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.

You may even find people interested in your idea and teaming up with you!

== Scripting Hooks ==
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.

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.

== Adding new subsystems ==
If you are interested in adding new subsystems to FG, you may want to check out this: [[Howto:Create new subsystems]].

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]]

== The property tree ==
The FlightGear property tree is documented here: [[Howto:Work with the Property Tree API]]

= Some Ideas =

== Additional Scripting Bindings ==

{{CppBind Ideas}}

== CompositeViewer support ==
This is a long-standing feature request, for details, please see [[CompositeViewer Support]].

== World Scenery 3.0 ==
The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].

== JPEGFactory ==
{{Note|Also see [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/053287a7-005d-4fd0-a1ee-96f1194ea904%40email.android.com/#msg32398628]}}
{{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}}

{{cquote|<nowiki>It's turned off for build reasons, not because it's new or untested. I believe
many people have used it exactly the way you describe. If you encounter
problems, they should be easy to fix and patches are welcome!

(The build reasons could actually be solved by using OSGDB to write out the
files instead of using libjpeg directly - this would mean the feature could be
enabled all the time, i.e removed from CMake, and also we could write out PNGs
instead of JPEGs if desired - if you have any interested in doing this, I can
point you at examples since the screenshot code was converted to do the same
thing recently -it's probably a couple of hours hacking at most)
</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>}}

{{cquote|<nowiki>If someone decides to jump into this, another feature that would be cool
would be to stream the display out as a video stream which could then be
played by any number of video players on a remote computer (like mplayer.)
ffmpeg probably would provide library support to make this pretty
straightforward, but I haven't had a chance to dive in and see how
easy/hard it would be.

One area where this feature could be useful is in UAV research and
simulation where you'd like to emulate a live video feed back to a ground
station. It could also be fun for sharing/broadcasting your simulator
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>}}

{{cquote|<nowiki>I wanted to capture the FG imagery and
stream it over the web... (or some similar solution)
</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>}}

{{cquote|<nowiki>I've seen other
apps that can do this so I know it's technically possible, and I imagine
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>}}

{{cquote|<nowiki>VLC does this better than ffmpeg, so it's probably a good idea to study it's
codebase for streaming code. Also, MJPEG is nice, but as a container I'd
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>}}

{{cquote|<nowiki>Note if you want actual good performance from this system, there's much smarter
things that could be done, such as grabbing the frame buffer each normal
rendering frame, instead of re-rendering the scene each time an HTTP get is
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>}}

{{cquote|<nowiki>And obviously it does require that cmake finds the
JPEG includes and libraries... I had earlier compiled
and installed jpeg-9 into my 3rdParty folder...

This dependency would go away if OSGDB was used,
as James mentioned, but then JPEG would probably have
to be found during the OSG build, unless OSG has
alternate built-in jpeg code... not sure...

Thereafter, running fgfs.exe with --jpg-httpd=1234
worked fine by putting http://localhost:1234 is a
browser, and bingo had a jpg image of the screen
in the browser ;=)) cool stuff...

Of course it is a 'static' image, and had to refresh
to get updated images of the flight... or an extension
added to provide an actual video feed as Curt mentioned...

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>}}

Also see: {{Issue|924}}.

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

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= ]
[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.

* [[Howto:Use a Camera View in an Instrument]]
* [[Canvas_Properties#Serializing_a_canvas_to_a_buffer_or_file]]

<references/>

= Finally =

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

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.

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.

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.

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.

[[Category:Howto]]
[[Category:Core developer documentation]]
[[ru:Howto:Приступая к разработке ядра]]

Howto:Start core development

2015-02-24T04:21:07Z

Peteffs: links to api docs

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

= How the Project works (Suggested reading!) =
Please see this short essay here: http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971

Also see [[Implementing new features for FlightGear]]

= Welcome to FlightGear =

Hi, and welcome to FlightGear!

You have probably come here to learn more about implementing new features for FlightGear.

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.

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.

== Not yet familiar with C++ ? ==

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

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.

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

== Developing without programming is possible and appreciated ==

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

== Coding but not in C++ (scripting) ==

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.

Many new ideas or features won't require any modifications to the C++ source code at all.
You could probably get started and implement many ideas without even touching an IDE or a compiler for quite a while.

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.

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.

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. Here's an overview giving you a rough idea about recent Nasal related efforts:

{{Nasal Efforts}}

For example, the tutorial system built into FG is entirely implemented in scripting space, and fully XML-configurable: [[Tutorials]]

This means that you can create/modify and improve tutorials just by editing plain text files with any conventional text editor.

There are many more things possible using Nasal, just see the wiki.

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.

== Shader programming ==
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).

= Hacking the C++ code =

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

= Initial advice =

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)

* 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]]
* read the documentation (wiki, $FG_ROOT/Docs, $FG_SRC/mini-docs)
* it also helps running DoxyGen or Source Navigator to navigate the various source trees
* start making tiny modifications to existing stuff (aircraft, scenery, source code etc)
* 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)
* register an account at gitorious
* clone the FG project (SimGear, FlightGear, fgdata)
* 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)?
* 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
* subscribe to the developers mailing list
* ask for advice/projects there
* 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)
* coordinate your effort with others, i.e. communicate your intentions early and ask for advice
* release early and often
* don't get frustrated :-)
* enjoy!

= Project architecture =
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.

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.

Once you have satisfied all dependencies and built them in the right order, you can start FlightGear.
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".

The FG source tree is commonly referred to as $FG_SRC, while the SimGear source tree is often referred to as $SG_SRC.

A while ago, Jim Wilson posted the following advice on the devel list:

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.

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.

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.

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
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
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
through the modules to find the code that actually does call the update() (look for references to the class you are interested in).

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
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
are handled in FlightGear. For example the flight instruments are all configured using xml defined references to values in the property tree in
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).

Speaking of instruments, you might want to take a look at how some of the instrumentation configuration (Aircraft/Instrumentation/*.xml files in the
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
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
the property tree.

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.

Welcome aboard and do feel free to post any questions to the list as they come up.

= The source code =

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.

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

The SimGear and FlightGear source trees both make use of the [[Building using CMake|CMake]] build system as of 2012.

The FlightGear project uses the decentralized source code management system "git" see [[Git]] for more info.

The project sources are hosted at gitorious: http://gitorious.org/fg/

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

You can find tutorials for different platforms/OS at the end of the article.

= Continuous Integration (CI) =

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/

Please see [[FlightGear Build Server]] for more information.

= Patches =

Regarding patches, please see: [[Submitting Patches]].

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

In general, the FlightGear gitorious project is the entry point for new developers: http://gitorious.org/fg/

Some more recommendations can be found at [[Recommended Project Policies]].

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.

To send patches upstream, gitorious merge requests are recommended. The details of which are covered at [[Merge request]].

A list of active FlightGear core developers is to be found at [[:Category:FlightGear Core developers|FlightGear Core developers]].

= Ongoing efforts =

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

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

The FlightGear state of all HLA things is documented at: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

Introductory HLA resources are collected at: http://wiki.flightgear.org/Developing_with_HLA#Resources

In developer's terms, that mostly boils down to:
* expect more and more scenery functionality to be procedurally added (e.g. [[Terragear_roadmap#Runtime_Airport_Generation|runways, taxiways]], whole airports)
* expect more and more viewer functionality to be decoupled from the simulator (fgviewer being the prototype here)
* expect more and more viewer/GUI features to be made optional through a [[FlightGear Headless]] mode during startup
* expect the 2D rendering backend (GUI, instruments, HUDs etc) to be increasingly unified through the [[Canvas]] system
* expect [[FGPanel|FGPanel standalone panel rendering]] functionality to be merged back into the main fgfs code base, provided through [[FGViewer]]
* expect more work towards better system-wide reinit/reset support: http://wiki.flightgear.org/Reset_%26_re-init
* 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]
* expect FDMs to become re-initializable at runtime, expect support for multiple FDMs per session
* 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
* 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
* expect the existing multiplayer system to be completely phased out and replaced by HLA
* expect [[Property Tree/Native Protocol Slaving|multi-instance slaving]] to be formalized and reimplemented through [[FGViewer]] and [[HLA]]
* expect Nasal scripting integration to be increasingly decoupled from the fgfs main loop
* expect OSG CompositeViewer to be eventually adopted (almost certainly not during the next 12 months though)

Basically, help facilitate these change by at least not making these things more difficult through your own code

For doxygen docs, see: http://docs.freeflightsim.org/

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
If you have anything to add, please feel free to create a new wiki article.
Also, contributing such news to the FlightGear [[Next newsletter|newsletter]] is another good idea.

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

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.

Also, there's another outdated category titled "Code Cleanup": http://wiki.flightgear.org/Category:Code_Cleanup

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

In other words: '''pick your poison :)'''

= Issue tracking =

Ideas (feature requests actually) and bug reports are ideally reported using the issue tracker here: http://flightgear-bugs.googlecode.com/

Please make sure to first search the issue tracker before possibly reporting a dupe, thanks!

Bug reports should ideally be accompanied with a test case to reproduce an issue, but also a backtrace, see: [[Howto:Debugging FlightGear Crashes#Debugging Segfaults & Obtaining Backtraces]].

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.

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.

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

= Talking to fellow FlightGear developers =
Most core development related discussions are handled using the developers mailing list: http://www.flightgear.org/mail.html

There's a fully searchable archive available here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/

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/

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.

= Flight dynamics =
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.

For JSBSim, please see: http://jsbsim.sourceforge.net/

= Important docs =
There's a wealth of documentation to get you started available in [http://gitorious.org/fg/fgdata/trees/master/Docs $FG_ROOT/Docs]

API docs auto generated from source are at http://api-docs.freeflightsim.org/

Even more documentation can be found in our wiki, here: http://wiki.flightgear.org/

The wiki is divided into different "portals", you'll probably be interested in the developers portal here: http://wiki.flightgear.org/Portal:Developer

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

== FlightGear ==
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.
But complex C++ features (such as advanced templates or meta-programming are not too common actually).

One of the simplest ways to add new features to FlightGear is adding new commands to it, so called "fgcommands" (i.e. "FlightGear commands").
For additional information, please see this tutorial: [[Howto: Add new fgcommands to FlightGear]].

== Programming resources ==
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]].

== SimGear ==
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++".

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/

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.

Also, you can get a fair amount of information out of the FG sources by running them through doxygen, too.

== Plain C ? (Nasal) ==
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

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

The longest-standing issue related to Nasal scripting is fixing its Garbage Collector (GC) to become generational, incremental or even concurrent, this is to reduce main loop impact (frame rate & frame spacing), see [[How the Nasal GC works]] to learn more. Almost certainly, we're going to adopt an existing GC library, or even implement an interface to experiment with different GC schemes, and allow those to be selected at startup.

Adding new extension functions to the built-in Nasal interpreter is documented here: [[Howto: Extend Nasal]].

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

None of this requires any C++ knowledge!

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

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 using the [[Nasal/CppBind]] framework, 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_cppbind.cxx source code, which demonstrates how this is done.

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.

= Getting started =
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

== Talk about your plans ==
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.

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.

You may even find people interested in your idea and teaming up with you!

== Scripting Hooks ==
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.

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.

== Adding new subsystems ==
If you are interested in adding new subsystems to FG, you may want to check out this: [[Howto:Create new subsystems]].

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]]

== The property tree ==
The FlightGear property tree is documented here: [[Howto:Work with the Property Tree API]]

= Some Ideas =

== Additional Scripting Bindings ==

{{CppBind Ideas}}

== CompositeViewer support ==
This is a long-standing feature request, for details, please see [[CompositeViewer Support]].

== World Scenery 3.0 ==
The Terragear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at [[World Scenery 3.0 roadmap]].

== JPEGFactory ==
{{Note|Also see [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/053287a7-005d-4fd0-a1ee-96f1194ea904%40email.android.com/#msg32398628]}}
{{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}}

{{cquote|<nowiki>It's turned off for build reasons, not because it's new or untested. I believe
many people have used it exactly the way you describe. If you encounter
problems, they should be easy to fix and patches are welcome!

(The build reasons could actually be solved by using OSGDB to write out the
files instead of using libjpeg directly - this would mean the feature could be
enabled all the time, i.e removed from CMake, and also we could write out PNGs
instead of JPEGs if desired - if you have any interested in doing this, I can
point you at examples since the screenshot code was converted to do the same
thing recently -it's probably a couple of hours hacking at most)
</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>}}

{{cquote|<nowiki>If someone decides to jump into this, another feature that would be cool
would be to stream the display out as a video stream which could then be
played by any number of video players on a remote computer (like mplayer.)
ffmpeg probably would provide library support to make this pretty
straightforward, but I haven't had a chance to dive in and see how
easy/hard it would be.

One area where this feature could be useful is in UAV research and
simulation where you'd like to emulate a live video feed back to a ground
station. It could also be fun for sharing/broadcasting your simulator
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>}}

{{cquote|<nowiki>I wanted to capture the FG imagery and
stream it over the web... (or some similar solution)
</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>}}

{{cquote|<nowiki>I've seen other
apps that can do this so I know it's technically possible, and I imagine
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>}}

{{cquote|<nowiki>VLC does this better than ffmpeg, so it's probably a good idea to study it's
codebase for streaming code. Also, MJPEG is nice, but as a container I'd
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>}}

{{cquote|<nowiki>Note if you want actual good performance from this system, there's much smarter
things that could be done, such as grabbing the frame buffer each normal
rendering frame, instead of re-rendering the scene each time an HTTP get is
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>}}

{{cquote|<nowiki>And obviously it does require that cmake finds the
JPEG includes and libraries... I had earlier compiled
and installed jpeg-9 into my 3rdParty folder...

This dependency would go away if OSGDB was used,
as James mentioned, but then JPEG would probably have
to be found during the OSG build, unless OSG has
alternate built-in jpeg code... not sure...

Thereafter, running fgfs.exe with --jpg-httpd=1234
worked fine by putting http://localhost:1234 is a
browser, and bingo had a jpg image of the screen
in the browser ;=)) cool stuff...

Of course it is a 'static' image, and had to refresh
to get updated images of the flight... or an extension
added to provide an actual video feed as Curt mentioned...

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>}}

Also see: {{Issue|924}}.

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

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= ]
[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.

* [[Howto:Use a Camera View in an Instrument]]
* [[Canvas_Properties#Serializing_a_canvas_to_a_buffer_or_file]]

<references/>

= Finally =

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

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.

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.

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.

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.

[[Category:Howto]]
[[Category:Core developer documentation]]
[[ru:Howto:Приступая к разработке ядра]]

Howto:Set up a multiplayer server

2015-02-24T04:16:24Z

Peteffs: fgms website link

This page is dedicated to providing a short overview about installing the [[FlightGear Multiplayer Server]] ('fgms'). The reader is assumed to be reasonably familiar with working in a Unix/Linux shell environment.

== Pre-Requisites ==
* A computer running a variant of *nix to compile and host the server. Speed of the machine isn't of great consequence as the protocol is a multiplexer which doesn't require much processing grunt.
** For specific documentation for setting up on FreeBSD see [[Howto:Set up a multiplayer server on FreeBSD]].
* direct/physical or remote access to the server (i.e. SSH/telnet, a conventional web hosting package will usually '''not''' be sufficient!)-suitable hosting packages are: dedicated root servers, virtual private servers, shell servers - for a collection of '''free''' shell account providers that may be suitable for fgms, see [[Free Shell Providers]] (you may want to check this out if you are interested in running fgms but don't have hosting yet)
* if the server is meant to be a public internet server: an internet connection, featuring sufficient upstream/downstream capabilities (see below for details concerning bandwidth requirements).
* firewall policies will need to be set up to allow for incoming and outgoing UDP traffic for the corresponding ports, the same applies to the administration port (TCP)
* permission to run unattended background processes (this may only be an issue with certain limited hosting packages)
* a working GNU toolchain including gcc/g++ (compiler), make & cmake
* fgms source code, currently version 0.10.23
* about 5-10 MB of hard disk space (mainly required for building the binary)

== Traffic & Bandwidth Considerations ==

Note: Currently (May 2008), the server code basically boils down to a packet multiplexer (i.e. most data is -unconditionally- transmitted to all 'active' clients), which may thus create considerable amounts of traffic; this ought to be taken into consideration due to bandwidth limitations in most hosting packages (i.e. '''fgms may create considerable amounts of traffic!'''). For basic calculations: inbound traffic is 25 Kilobit per second while outbound is 25 Kbits per second for each plane/client that can 'see' another.

By default, assuming a 10hz update interval, each active fgfs client will currently cause I/O traffic of approximately 5 kbytes/sec (one update consuming ~500 bytes) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16016.html].

As client updates have to be propagated to all other active clients by the server, this number has to be multiplied by the number of active clients -1 (i.e. clients within a configurable range, minus the originating client).
In addition, the fgms system allows for traffic updates to be sort of 'mirrored' on (relayed to) other configurable multiplayer/relay servers.

This feature makes it possible for users/clients to use an arbitrary server (with acceptable latency), but still see clients/vehicles connected to different servers. Thus, such relay servers may additionally increase inbound/outbound traffic considerably as all traffic is mirrored/propagated to such relays.

Having more servers should actually decrease the load on each server in high load situations, i.e. when most of the clients are within range of each other. See this
[http://www.gidenstam.org/FlightGear/fgms/fgms_bandwidth_estimates.txt brief note on the theoretical bandwidth behaviour of fgms.]

=== Facts ===
In March 2008, the main fgms multiplayer server (pigeond.net) was reported to consume approximately 15 gb of bandwidth per '''day''', with an average throughput of 200 kB/sec and peak loads of up to ~ 650 kB/sec [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16016.html].

During the same month (the much less used but interconnected) mpserver06.flightgear.org had on average 742 MB incoming and 688 MB outgoing traffic per day (i.e. 72 kbit/sec respective 66 kbit/sec on average).

In September 2009, mpserver 05 had a massive peak bandwidth of 1.0 MB/sec. Average bandwidth consumed was about 9 GB of bandwidth per day. The average bandwidth usage per day is climbing due to more users moving from 02 to 05.

In July 2013, mpserver01 load was reported averaging at 10 MBit/sec

=== Reducing bandwidth requirements ===
Total network traffic is mainly determined by the number of active clients that 'see eachother' and configured mirrors.
If traffic considerations are relevant, the following options exist to reduce overall server/network load:

* configure a relatively low "server.out_of_reach" value, so that clients outside a certain range are not provided with updates (usually about 100 nm on the main server network)
* for virtual gatherings (i.e. fly-ins), have clients use airports and places that do not have lots of other traffic (i.e. in other words, avoid places like standard airports such as KSFO)
* avoid the use of unnecessary relay servers
* if you are not interested in your server being publicly available, only share its address with your friends privately
* for local testing/development purposes, you may want to run only a private fgms session, that may be specific to your LAN or even computer.

== Getting & Building fgms ==

* You will need the build tools cmake and make, and also g++ to compile the fgms application. These can usually be found in the package manager for most the common Linux distributions. You will also need the git client to fetch the source code from the repository, if you plan to download it from the command line interface (see below).

* Once the build tools are installed on your machine, create a directory to hold the source code. This could be named anything, such as fgms. Create it in your user home directory. Note that this WILL NOT be the directory where the program will be compiled.

* Now 'cd' into the directory you just made, where you will run the command to fetch the source code from the git repository (see below).

* To download the latest stable version via HTTP, you can use direct your browse to the URL http://gitorious.org/fgms/fgms-0-x/. Download and unzip the source code, and place it in the directory you created above.

* To download a file directly to your server from an ssh session, you can use git tools with the following command:

$git clone git://gitorious.org/fgms/fgms-0-x.git

== Compiling FGMS ==

For FreeBSD-specific instructions, please see [[Howto:Set up a multiplayer server on FreeBSD]]

NOTE: In general, on any current machine this process should not take longer than about 60 seconds.

* Once you have the source code, 'cd' into the ~/fgms/fgms-0-x/ directory and note the presence of the CMakeLists.txt file and the README.cmake file. Open the README.cmake file and take a minute to read it over. Also, note the path to the CMakeLists.txt file, as you will need this in the following steps.

* Now create a build-fgms directory in your home directory, and 'cd' into it. From inside the ~/build-fgms/ directory, run the cmake command using the path to the CMakeLists.txt as an argument. For example: cmake /home/<user_name>/fgms/fgms-0-x/

* Once the build finishes, you can either run the "cmake --build ..." command as shown in the README.cmake file, or you can simply use "make" to build the program.

* Once the compilation process finishes, you need to install the program using "make install" (as user), or you can also install as root.

* Once the program has been installed, you need to copy the fgms_example.conf file from the /fgms/fgms-0-x/src/server directory, into the build-fgms directory. To do this from inside the /fgms/fgms-0-x/src/server directory, you can use this command: cp ./fgms_example.conf ~/build-fgms/

* Now 'cd' into the build-fgms directory, and rename the file you just copied as "fgms.conf" so that fgms can find the proper configuration.

== Setting up the config file ==

At this point you should have a working 'fgms' binary in the build-fgms directory. If the server will be offline or for private use (i.e. LAN-only, please comment out the relay servers section. This will save bandwidth from the server being consumed.

* Edit the fgms.conf file according to the instructions found elsewhere on this page, then save and close the file.

{{cquote|As long as you are not absolutly sure what you are doing you should:
- disable tracking
- disable HUB setting<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}

{{cquote|fgms will ignore traffic comming from unknown relays and since the multiplayer network is a star topology you should list only mpserver01
as your only relay. Currently mpserver01 is the only HUB, Although multiple HUBs should work I have not tested a multi HUB environment yet.
And for those interrested: Current traffic load on mpserver01 is around 10 MBit/s<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}

{{cquote|your fgms.conf should look like:
<pre>
# basic setting
server.name = mpserver02
server.port = 5000

# you can telnet to this port with this username/password
# and see statistics (nice cisco like CLI)
server.admin_port = 6002
server.admin_user = fred
server.admin_pass = fred

server.admin_enable = fred

# mpserver01 does this
server.tracked = false

# mpserver01 is hub
server.is_hub = false</pre><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}

{{cquote|<pre># don't set this too high
server.out_of_reach = 100

# your only relay should be mpserver01
relay.host = mpserver01.flightgear.org
relay.port = 5000

# you don't need a crossfeed, it's only interresting for fgms-developers
# crossfeed.host = foo.example.com
# crossfeed.port = 5002

# you can add static entries of IPs which get blocked,
# but it's generally not needed and you can add them via
# the admin CLI
# blacklist = 123.123.123.123</pre><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}

== Running FGMS for the first time ==

In addition to its configuration file, FGMS supports a number of configuration parameters that can be passed at startup (and that will by default override any configuration file settings), to get a summary of supported parameters, you may want to run:
$ ./fgms --help

Which should present you with the following output:

<pre>
options are:
-h print this help screen
-a PORT listen to PORT for telnet
-c config read 'config' as configuration file
-p PORT listen to PORT
-t TTL Time a client is active while not sending packets
-o OOR nautical miles two players must be apart to be out of reach
-l LOGFILE Log to LOGFILE
-v LEVEL verbosity (loglevel) in range 1 (few) and 5 (much)
-d do _not_ run as a daemon (stay in foreground)
-D do run as a daemon

the default is to run as a daemon, which can be overridden in the
config file.
commandline parameters always override config file options
</pre>

After having finished the fgms configuration, you can try running fgms and start up fgfs to use the new server.
=== Public Server ===
If you'd like to make it a public server, you can simply use your external (public) IP address to set up the multiplayer in fgfs.

For others to know about your public server you should notify the developers of the existence of your server by posting a message to the [[Mailing list|developers mailing list]].

Add your server to this list: http://wiki.flightgear.org/Howto:Multiplayer#Servers

== Related content ==
* [http://fgms.freeflightsim.org/ Website: fgms.freeflightsim.org]
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

<references/>

[[Category:Howto]]
[[Category:Multiplayer]]

[[fr:Installer un serveur multijoueur]]

TerraGear

2015-02-24T04:09:08Z

Peteffs: Links to API docs

<div style="padding-left:20px;">''Not to be confused with [[TerraSync]], a tool to download scenery on-the-fly.''</div>

[[File:TerraGear The Hague wireframe.png|thumb|270px|A wireframe view of detailed [[CORINE]] and [[OSM]] scenery, generated by TerraGear.]]
'''TerraGear''' is a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations (i.e. 3D models or 3D maps) of the earth for use in real time rendering projects. TerraGear can import 3D data sets such as DEM terrain grids, 2D polygon data sets such as coastlines, city outlines, lake outlines, and 2D raster data sets such as the 1 km NAOO land use/land cover data. It also has tools for generating realistic [[airport]]s, runways, and lighting based on available FAA data.

TerraGear is the primary tool used to generate the [[scenery]] for the [[FlightGear]] project.

== Introduction ==
For a variety of reasons you might want to build terrain yourself, rather than downloading it from the available scenery on FlightGear. For instance, if you use [[TaxiDraw]] to create or modify an airport layout, you might wish to see how that modified airport would look in the Scenery before deciding you're happy with the results. And normally, to see and use the airport in the scenery, it's necessary to submit the modifications to the FlighGear scenery staff and then wait untill the next update of the scenery of that area is available via [[TerraSync]] or in the [http://www.flightgear.org/download/scenery/ official FlightGear Scenery] build. If you can build terrain yourself, you can start using it right away.

Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher resolution vector data (vmap1, Tiger) to get better roads/rivers. For all these reasons learning how to use TerraGear is a good idea.

== Getting TerraGear ==
=== Pre-compiled builds ===
* [http://flightgear.simpits.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip Latest Windows build], built by the [[FlightGear Build Server]].

:*[[TerraGear_Installation_for_Windows|Detailed Windows Installation Instructions]]

=== Source ===
The source is hold in a [[git]] repository at Gitorious.
git clone git://git.gitorious.org/fg/terragear.git

== Compilation ==
=== Dependencies ===
* TerraGear
** [[SimGear]] - '''Not''' simgear-cs! (simgear-dev package)
*** SimGear can be compiled without OSG support thus eliminating many deps, like OSG. Use "-DSIMGEAR_HEADLESS=YES" for a minimal build.
** [http://www.cgal.org/ CGAL] - For high accuracy geometric calculations
** [http://www.gdal.org/ libgdal]

=== Building ===
cmake . [options]
make install
<tt>cmake</tt> options:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Platform specific ===
* Debian: [[Building FlightGear - Debian#TerraGear]]
* Gentoo: <tt>emerge -av terragear</tt> <BR>See [[Building Flightgear - Gentoo]].
* Ubuntu: [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== GUI Tool ==
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]
* [[TerraGear Documentation]]
* [http://api-docs.freeflightsim.org/terragear/ TerraGear API docs]

{{Terra}}
{{Building}}

[[Category:TerraGear| ]]

[[es:TerraGear]]
[[fr:TerraGear]]

SimGear

2014-11-08T01:32:52Z

Peteffs: Link to apidocs

[[File:Flightgear uml associations class diagram.png|thumb|A [[UML Diagrams|UML]] class diagram disclosing the associations between some classes of the FlightGear source code.]]

'''SimGear''' is a set of open source software libraries used by [[FlightGear]]. The 1.0 release was released along with [[FlightGear 1.0]] in December 2007. The project is still developing but the goal is to be "Simulation Kernel", and to be used by other non-FlightGear projects. The project was started in the year 2000.

SimGear, like FlightGear and [[TerraGear]], requires [[PLIB]] for building.

SimGear is a library of supporting code and a downstream dependancy if you plan on compiling FlightGear -- it is not needed to run precompiled binaries. For the api docs see http://api-docs.freeflightsim.org/simgear/ and legacy information see http://www.simgear.org/. '''Note: When compiling FlightGear it is very important to have the matching version of SimGear vs FlightGear.'''

[[FlightGear 1.9.0]] requires SimGear 1.9 if compiling from source.

== Design & Dependencies ==
(This section is largely copied together from the devel list, see [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22720.html])

Simgear and the property system are used in a variety of other projects, so whatever we do, we shouldn't make these low level libraries depend on OSG (which isn't available for instance on a little embedded UAV controller.)

=== OSG data structures ===

Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear
classes, and if you use the property system you may not want to rely on osg.

... also from past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few
viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL.
So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ...

So, even if you will need some more glue code, It would be better to avoid osg classes in simgears parts that are not scenegraph related.
The property system is such an area.

This is not a hard requirement. But we definitely have parts in a simulation that just do not need to know that they run on osg/OpenGL.

Imagine you want to change the viewer library. All the physics is still the same. By mixing osg classes into everything without any type abstraction in
between, you need to rewrite the whole pile of code. Even for parts that do not depend on any viewing crap at all.

That was done during the switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around.
So please avoid having osg::whatever spread around in the whole application.

Appart from that, having more separate code paths in general for the simulation parts and the viewer/scene parts would help for plenty of our
scalability problems a lot. So just thinking about general software design ... So nothing is set in stone here, but it makes sense IMO to head into that
separation where possible/sensible.

More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we
do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ...

What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing
there.

The rule of thumb when to use what is simple:
* If you are in the scene graph most probably osg::... might be a good thing to use.
* If you are in the simulation, network, input system, property system, wherever
not scene graph dependent, use simgears own classes.

So scenegraph means osg::ref_ptr and fg/sg means SGSharedPtr.
And from an abstraction point of view osg* usage should not be visible too much.
Those places where this rule is broken is something I do not like either. As already told, I believe that it is not a good idea to tie a simulation to a
viewer framework. And a scenegraph is nothing more than that ...

So I would not tell that a hard design goal. But If we can make that I believe that we will get a benefit in doing so in the mid/long term.

=== SGReferenced vs. Boost ===
When using std::tr1:shared_ptr you will need two allocations for a new object that is used with the the std::shared_ptr implementation - one for the object and one for the reference count. I like to use that SGReferenced stuff for many small lightweight objects that should not take to much time to create and should not take too much space. That kind of the solution is the most lightweight one I can think of.

Also you can no longer work with raw pointers passed around and use the reference count included in the object since the shared_ptr implementation has
a separate count object. If you do so you will end up with two reference counts for the same object. The current implementation avoids that and make
raw pointer based apis if required.

So alltogether we have with the SG* version something that works equally well than the shared_ptr/weak_ptr pair and provides some extra features I would
like to have.

The SGAtomic counter could make use of the std::atomic at some point - if we add an additional case int the current implementation selection when we have
that available.
This could be done without loosing any of the features we have available in our current SharedPtr/WeakPtr implementation.
The only thing in tr1 is the shared_ptr/weak_ptr. I am Not sure what tr2 includes.

What I am missing in the intrusive pointer is a thread safe implementation of the weak_ptr. Note that we already have that in simgear ...
Not yet thought about that, but is there any chance to implement the weak_ptr semantics together with the intrusive_ptr?

== External Links ==
* Latest Docs - http://api-docs.freeflightsim.org/simgear/
* http://www.simgear.org/

== See also ==
* [[TerraGear]]
* [[FlightGear related projects]]

[[Category:Software]]
[[Category:GPL software]]

Howto:Create a generic protocol

2014-08-18T17:00:57Z

Peteffs: Fix quotes to example

This [[:Category:Howto|howto]] quickly demonstrate's how to create a socket transmitting some FlightGear data live as its running.

For this exercise we name it the '''abc-protocol''' and the properties were interested in are:
# the altitude above ground
# the position of the elevator
# the mode of the altitude hold in the autopilot
* and refreshing five times a second
* on port 6789
* as udp packets
* and read the other side of the wire as
253.256\t elevator=1.3\t aoa-hold\n

== Finding the nodes in the tree ==
The first step is to find where the nodes are in the property tree and unless your familiar with the property tree, then one of the easiest things to do is to launch FlightGear with a httpd server, so that the tree can be browsed to find the node locations. Start FlightGear with:
fgfs --httpd=5400
which will start the webserver on port 5400, then point a web browser at
http://localhost:5400

By navigating the tree its discovered that the properties were interested in are at
# '''/position/altitude-agl-ft'''
# '''/surface-positions/elevator-pos-norm'''
# '''/autopilot/locks/altitude'''

== Creating the .xml file ==
Below is the example abc-protocol.xml file. This file needs to be located within the FlightGear data directory structure at

'''/data/Protocol/abc-protocol.xml'''

<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<line_separator>newline</line_separator>
<var_separator>tab</var_separator>

<chunk>
<name>altitude above ground</name>
<node>/position/altitude-agl-ft</node>
<type>float</type>
<format>%03.2f</format>
</chunk>

<chunk>
<name>elevator position</name>
<node>/surface-positions/elevator-pos-norm</node>
<type>float</type>
<format>elevator=%03.2f</format>
</chunk>

<chunk>
<name>altitude autopilot (wip)</name>
<node>/autopilot/locks/altitude</node>
<type>string</type>
<format>%s</format>
</chunk>

</output>
</generic>
</PropertyList>

The tags are briefly described as
===== <output> =====
Contains the "formatting" protocol for output. Note that the same file can contain an <input> section also for mapping input protocol/formatting (tutorial maybe soon).

===== <line_separator> =====
What character(s) to use as a delimiter to "end" our line/blob of data containing the three values. In this example its '''newline''', but '''\n''' is also acceptable as would another other ascii characters, eg '''##EOL##'''.

===== <var_separator> =====
What character(s) to use as a delimiter of the property values; in this example were using the '''tab''', also '''\t''' is acceptable or even '''@@@'''.

===== <chunk> =====
There are three chunk tags in this example to reflect the three properties were interested in. IMPORTANT, the chunks are output in the order presented in the xml file.

Within each chuck the tags are described as
* '''<name>''' - this is for reference and ease of use, is not necassary and, its not transmitted (eg a <notes> tag). It could be useful elsewhere though eg a shared configuration file with another application.
* '''<node>''' - the property node.
* '''<type>''' - this is the type of value needed for formatting. In our example the autopilot is a string, whilst the other two values as float. Not setting the type can leads to strange stuff happening.
* '''<format>''' - the output format. The altitude and elevator are straighforward printf formatting, whilst the autopilot is "autopilot=%s".

There are many other options which are covered in [[Generic Protocol]]

== Start FlightGear to broadcast ==
So with the abc-protocol.xml file ready, FlightGear can be started with

fgfs --generic=socket,out,5,127.0.0.1,1234,udp,abc-protocol

The '''--generic=socket,out,5,127.0.0.1,1234,udp,abc-protocol''' is the part that runs the socket server and are broken down into the following elements separated by a comma.
* '''socket''' - tell FlightGear to open a socket
* '''out''' - to use the socket to output data ie transmit
* '''5''' - at five times a second
* '''127.0.0.1''' - on the loopback address
* '''1234''' - the UDP port (only required if using TCP/UDP as network protocol)
* '''udp''' - using the udp network protocol
* '''abc-protocol''' - and using the abc-protocol.xml file

''Gotchas - ensure there are no loose spaces between the items eg''
--generic=socket,out,5, 127.0.0.1,1234,udp,abc-protoco
^ oops

== Example Ajax Output ==
<output>
<line_separator>newline</line_separator>
<var_separator>,</var_separator>

<chunk>
<name>altitude above ground</name>
<node>/position/altitude-agl-ft</node>
<type>float</type>
<format>{"altitude":%03.2f</format>
</chunk>

<chunk>
<name>altitude autopilot (wip)</name>
<node>/autopilot/locks/altitude</node>
<type>string</type>
<format>"autopilot": '%s'}</format>
</chunk>
</output>

The above would output:
{"elevator": 0.00,"autopilot": ""}\n

[[Category:Howto|Create a generic protocol]]
[[Category:XML]]

Howto:Create a generic protocol

2014-08-18T16:59:59Z

Peteffs: Correct example which I got wrong before

This [[:Category:Howto|howto]] quickly demonstrate's how to create a socket transmitting some FlightGear data live as its running.

For this exercise we name it the '''abc-protocol''' and the properties were interested in are:
# the altitude above ground
# the position of the elevator
# the mode of the altitude hold in the autopilot
* and refreshing five times a second
* on port 6789
* as udp packets
* and read the other side of the wire as
253.256\t elevator=1.3\t aoa-hold\n

== Finding the nodes in the tree ==
The first step is to find where the nodes are in the property tree and unless your familiar with the property tree, then one of the easiest things to do is to launch FlightGear with a httpd server, so that the tree can be browsed to find the node locations. Start FlightGear with:
fgfs --httpd=5400
which will start the webserver on port 5400, then point a web browser at
http://localhost:5400

By navigating the tree its discovered that the properties were interested in are at
# '''/position/altitude-agl-ft'''
# '''/surface-positions/elevator-pos-norm'''
# '''/autopilot/locks/altitude'''

== Creating the .xml file ==
Below is the example abc-protocol.xml file. This file needs to be located within the FlightGear data directory structure at

'''/data/Protocol/abc-protocol.xml'''

<?xml version="1.0"?>
<PropertyList>
<generic>
<output>
<line_separator>newline</line_separator>
<var_separator>tab</var_separator>

<chunk>
<name>altitude above ground</name>
<node>/position/altitude-agl-ft</node>
<type>float</type>
<format>%03.2f</format>
</chunk>

<chunk>
<name>elevator position</name>
<node>/surface-positions/elevator-pos-norm</node>
<type>float</type>
<format>elevator=%03.2f</format>
</chunk>

<chunk>
<name>altitude autopilot (wip)</name>
<node>/autopilot/locks/altitude</node>
<type>string</type>
<format>%s</format>
</chunk>

</output>
</generic>
</PropertyList>

The tags are briefly described as
===== <output> =====
Contains the "formatting" protocol for output. Note that the same file can contain an <input> section also for mapping input protocol/formatting (tutorial maybe soon).

===== <line_separator> =====
What character(s) to use as a delimiter to "end" our line/blob of data containing the three values. In this example its '''newline''', but '''\n''' is also acceptable as would another other ascii characters, eg '''##EOL##'''.

===== <var_separator> =====
What character(s) to use as a delimiter of the property values; in this example were using the '''tab''', also '''\t''' is acceptable or even '''@@@'''.

===== <chunk> =====
There are three chunk tags in this example to reflect the three properties were interested in. IMPORTANT, the chunks are output in the order presented in the xml file.

Within each chuck the tags are described as
* '''<name>''' - this is for reference and ease of use, is not necassary and, its not transmitted (eg a <notes> tag). It could be useful elsewhere though eg a shared configuration file with another application.
* '''<node>''' - the property node.
* '''<type>''' - this is the type of value needed for formatting. In our example the autopilot is a string, whilst the other two values as float. Not setting the type can leads to strange stuff happening.
* '''<format>''' - the output format. The altitude and elevator are straighforward printf formatting, whilst the autopilot is "autopilot=%s".

There are many other options which are covered in [[Generic Protocol]]

== Start FlightGear to broadcast ==
So with the abc-protocol.xml file ready, FlightGear can be started with

fgfs --generic=socket,out,5,127.0.0.1,1234,udp,abc-protocol

The '''--generic=socket,out,5,127.0.0.1,1234,udp,abc-protocol''' is the part that runs the socket server and are broken down into the following elements separated by a comma.
* '''socket''' - tell FlightGear to open a socket
* '''out''' - to use the socket to output data ie transmit
* '''5''' - at five times a second
* '''127.0.0.1''' - on the loopback address
* '''1234''' - the UDP port (only required if using TCP/UDP as network protocol)
* '''udp''' - using the udp network protocol
* '''abc-protocol''' - and using the abc-protocol.xml file

''Gotchas - ensure there are no loose spaces between the items eg''
--generic=socket,out,5, 127.0.0.1,1234,udp,abc-protoco
^ oops

== Example Ajax Output ==
<output>
<line_separator>newline</line_separator>
<var_separator>,</var_separator>

<chunk>
<name>altitude above ground</name>
<node>/position/altitude-agl-ft</node>
<type>float</type>
<format>{"altitude":%03.2f</format>
</chunk>

<chunk>
<name>altitude autopilot (wip)</name>
<node>/autopilot/locks/altitude</node>
<type>string</type>
<format>"autopilot": '%s'}</format>
</chunk>
</output>

The above would output:
{"elevator": 0.00,"autopilot": ''}\n

[[Category:Howto|Create a generic protocol]]
[[Category:XML]]

FGX

2013-11-14T23:04:54Z

Peteffs: cleanup by pedro

{{Infobox Software
| title = FGx
| image =
| developedby = Yves Sablonier, Pete Morgan, Geoff McLane
| initialrelease = 2.2.0
| latestrelease = 2.10.0
| writtenin = C++ (Qt)
| os = Mac, Windows, various Linux distributions
| website = http://www.fgx.ch
}}
'''FGx''' is a CrossPlatform Open Source graphical launcher application for [[FlightGear]] using Qt. Development began in early 2011 with the purpose of creating a fast and easy to use tool to launch FlightGear on OSX/Mac hence the "x". Howover with Qt is also xplatfrom and adopted as such.

While initial development targeted the Apple Mac architecture, the Qt development environment allows for cross-platform compatibility between Windows, Mac OS and various Linux distributions.

==Getting FGx==
FGx source code is available at [https://github.com/fgx/fgx/ github/fgx/fgx/].

Precompiled binaries are available at http://downloads.fgx.ch and others coming soon..

==Supported Systems==
Note that FGx has been tested using the prerequisites listed below and may actually work with different OSes and versions. Feel free to update this list if you have additional information.
* Mac OSX
* Fedora
* Ubuntu/Xubuntu and other debian distributions
* Gentoo
* Windows XP/Vista/7

==Related content==
===Similar software===
* [[FGo!]]
* [[FGRun]]

[[Category:FlightGear front ends]]

Talk:Nasal Style Guide

2013-10-04T00:13:03Z

Peteffs:

Hi Gijs.. or anyone..

Can i suggest this page is re inserted..

Particular with Recent James comments on Newgroup .. If its OK I will then format.. said pedro ;-)
>>>>>
== Rules ? ==
* No, there's rules, since the codebase contains quite a mixture.
* We could start a wiki page
* only things to really care about.. (said James)

=== Member Vars ===
'''m_''' or '''_''' prefix for member variables

* the '''_''' prefix is widely used but technically illegal by ISO C++
* '''m_''' is a slight preference now

* Some prefer lowerCamelCaseWithoutUnderscores for method and variable names
* but you will find plenty of other places in the code which use all_lower_case
** usually try to follow the style of the code you're working in/near!

=== fully brace conditions ===
* even single line!
* This one is a pain but we've had several bugs with nested ifs-without-braces being modified and introducing logic errors.
* In several cases people forgot C++ is not Python:

if (you do this)
if (you keep do thing)
if (you then do this)
printf("terrible things can happen");
else
printf("This is not python!");
:)

=== Naming ===
Regarding naming, longer names and fewer comments are better. Don't do:
double m_vXr; /// the velocity tachyon flux
better do:
double m_velocityTachyonFlux;

Of course only people with auto-completing editors agree with this! Shorter names are fine for locals or arguments but still aim to be descriptive.

- please make a helper function for the great-circle XTK error function, with some sane name like 'greatCircleCrossTrackError'. And please include a full URL to the aviation formulary link, for future readers of the code.

- where you only want course OR distance, SGGeodesy has some convenience wrappers (I realise in most places in this patch you do want both). This is just to improve readability right now (avoids useless 'az2' declarations), but in the future we might be able to do less work if only one value is needed.

- Avoid UTF-8 degree symbols in comments, it might upset some compilers. We recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM marker.

==== Arithmetic ====
* prefer arithmetic terms in conditions to *always* be parenthesised, we've had some bad bugs due to this, so:
if (a < (b + c))
NOT
if (a < b + c)

==== Complex Conditions ===
* Where boolean conditional get complex, create explicit bools

so instead of:
if ((some complex test) && (some other complex test) && ((another thing) || (still more)))

More readable to do is:

bool answerOfTest1 = some complex text
bool answerOfTest2 = some other complexTest

if (answerOfTest1 && answerOftest2 )

* NOTE: The compiler will get rid of the bool vars, although you might force evaluation of more terms depending on how smart you the optimiser is, but you force yourself to give each boolean expression a name, like 'isWithinOverflightDistance' or 'isWithinInterceptAngle'.
* As a result it becomes much easier for someone else to evaluate the conditional logic and decide if they agree with it or not.
* If the boolean test is used more than once, make it into a helper method
- grep-ing for methods names is*() and has*() in the codebase points to many of these.

Talk:Nasal Style Guide

2013-10-03T23:49:46Z

Peteffs: RFC

Hi Gijs.. or anyone..

Can i suggest this page is re inserted..

Particular with Recent James comments on Newgroup .. If its OK I will then format.. said pedro ;-)
>>>>>

No, there's rules, since the codebase contains quite a mixture. We could start a wiki page, only things I really care about:

m_ or _ prefix for members (_prefix is widely used but technically illegal by ISO C++, m_ is my slight preference now)

fully brace conditions, even single line. This one is a pain but we've had several bugs with nested ifs-without-braces being modified and introducing logic errors. In several cases people forgot C++ is not Python:

if (you do this)
if (you keep do thing)
if (you then do this)
printf("terrible things can happen");
else
printf("This is not python!");

:)

I personally prefer lowerCamelCaseWithoutUnderscores for method and variable names, but you will find plenty of other places in the code which use all_lower_case - usually try to follow the style of the code you're working in/near.

Regarding naming, longer names and fewer comments are better. Don't do:

double m_vXr; /// the velocity tachyon flux

better do:

double m_velocityTachyonFlux;

Of course only people with auto-completing editors agree with this! Shorter names are fine for locals or arguments but still aim to be descriptive.

- please make a helper function for the great-circle XTK error function, with some sane name like 'greatCircleCrossTrackError'. And please include a full URL to the aviation formulary link, for future readers of the code.

- where you only want course OR distance, SGGeodesy has some convenience wrappers (I realise in most places in this patch you do want both). This is just to improve readability right now (avoids useless 'az2' declarations), but in the future we might be able to do less work if only one value is needed.

- Avoid UTF-8 degree symbols in comments, it might upset some compilers. We recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM marker.

- I would prefer arithmetic terms in conditions to *always* be parenthesised, we've had some bad bugs due to this, so:

if (a < (b + c))
NOT
if (a < b + c)

- Where boolean conditional get complex, create explicit bools, so instead of:

if ((some complex test) && (some other complex test) && ((another thing) || (still more)))

I think it's more readable to do:

bool answerOfTest1 = some complex text
bool answerOfTest2 = some other complexTest

if (answerOfTest1 && answerOftest2 && …)

The compiler will get rid of the bool vars, although you might force evaluation of more terms depending on how smart you the optimiser is, but you force yourself to give each boolean expression a name, like 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it becomes much easier for someone else to evaluate the conditional logic and decide if they agree with it or not. If the boolean test is used more than once, make it into a helper method - grep-ing for methods names is*() and has*() in the codebase points to many of these.

User:Peteffs

2013-04-12T11:44:13Z

Peteffs: nu page

Pete's page :-)

FlightGear Multiplayer Server

2013-04-12T11:43:15Z

Peteffs: New home for fgms

'''FGMS''' or '''FlightGear Multiplayer Server''' is a standalone network server for [[FlightGear]] and licensed under the GPL. It allows flying with other pilots over a network inside FGFS.

Types of server lists that can be configured in a server configuation:
# Relay server - the other servers in the network. Each has to have the full list (minus itself) for proper network function.
# Crossfeed server - everything the server receives from local users and other servers is forwarded to the crossfeed server(s). Intended for running several connected fgms instances on the same host, e.g. for providing both a tracked and untracked service, without incurring additional external traffic.
# Tracker - The server sends a digest update for each local user to the tracker every 10 sec.
# HUB - normally Servers do not send packets they receive from a server to other relays. A HUB server sends data from servers to all relays it knows about.

Special callsigns:
* "'''obsXXXX'''" (replace X's with any character you like) allows a connected FlightGear client to view all other MP pilots worldwide (position data and chat messages), yet remain invisible to them and on [[MPmap]].
* "'''mpdummy'''" prevents the pilot from being tracked on FGTracker. Not recommended - if several users use this callsign some will be ignored by the servers. Connect to an untracked server instead.

(Reference: fgms-0.9.13/src/server/fg_server.cxx)

== Related articles ==
* [[Howto: Set up a multiplayer server]]
* [[MPmap]]
* [[Howto: Multiplayer]]

== External Links ==
* http://fgms.freeflightsim.org

[[Category:Multiplayer]]
[[Category:Software]]