FlightGear wiki - User contributions [en]

Property Tree/Sockets

2022-09-07T02:51:12Z

Tcbetka: /* Using Proprietary/External FDMs */

{{PropertyTree}}
It should be pretty straightforward to use FG to playback a real flight. With FG you can slave multiple instances to one master instance of FG in real time. Slaving a copy of FG to a recorded data stream should be also very similar.

I have instances of FG talking to other copies of FG as well as an external FDM talking to FG using the same structure. There can be packing differences between compilers, but we were pretty careful with the current structure (all values are 4 or 8 bytes) and we don't know of any compilers that pack the structure differently from any other compilers.

You can overwrite most properties using a custom protocol, however you have to ensure that the data you are trying to overwrite isn't being written to by any other subsystems or parts of FlightGear.

This could for example be the FDM, which uses so called "tied properties" - basically, the properties tied by the FDM are not owned by the property tree, they are owned by the FDM and the property tree merely holds references/pointers to the FDM properties.

In a sense, you have to differentiate between input and output properties.

The easiest thing to avoid such problems is to completely disable the corresponding subsystem. In the case of the FDM this can be done by configuring the --fdm=null switch. So that no FDM is instantiated, that might cause conflicts.

On the other hand there are a number of subsystems that cannot currently be directly disabled, these would need to be patched in the source code.

Also, any property which is updated in a hard coded fashion could possibly conflict with your UDP packets. For example, some properties are updated each frame, and while overwriting these properties will not yield an error or warning, your updates would be invalidated due to these hard coded updates in the main loop.

<pre>
The following fgfs parameters will create the control sockets:
--native-ctrls=socket,in,10,127.0.0.1,5600,udp
--native-ctrls=socket,out,10,127.0.0.1,5700,udp

You will likely also need FDM data:
--native-fdm=socket,out,10,127.0.0.1,5500,udp
</pre>

== Getting started ==
One big question is what language/platform are you connecting to?

The easiest thing to do would be to write the other application in C/C++ and just use the exact same structure. If you look at the socket calls you will see that you provide a buffer and a length and it will fill it in with the network data.

You may have to worry about endianess if you are communicating between two different architectures, but in this case, the code converts to/from network byte order so that shouldn't be a problem.

If you want to know the size of different structures such as bool or int or double, there is a function in C/C++ called sizeof(). So you
could do something like "cout << sizeof(bool) << endl;"

== FlightGear vs. WideFS ==
FlightGear can do all that already. You can set up one copy to be a master, and any number of additional copies to be slaves. For each display channel you can specify view offset direction and fov. You can set up anything from a simple 3 monitor display system to some huge convoluted mess if you want to
gang up 20 machines.

== Hardware in the loop ==
Our solution has been to use the FGNetCtrls interface to FG and write a gateway application that would interface our UAV flight control computer (via serial port) to FG (via TCP). This allows us to do hardware-in-the-loop testing of the autopilot system. If preferable, you could also implement the flight control laws in a PC application and "fly" the FG model via a TCP connection.

Actually, flightgear has proven to be a versatile tool for our project. It is also good as a visualization system (either live during flight or for post-mission replay). Once you figure it out, communication with FG is pretty easy. I've just created a C# class to handle all I/O to FG, and can drop it in where needed.

== UAV Visualization ==

This use case is utilized in [https://wiki.paparazziuav.org/wiki/FlightGear Paparazzi autopilot]

And if you are using FlightGear as a visualization system for your UAV (either live or replaying the data) you can turn on multiplayer mode and inject yourself into the multiplayer system. I'm doing that right now. If you want to see my university's UAV in action, go to
mpmap01.flightgear.org right now and click the checkbox next to the Rascal-1 call sign. I'm looping the data and will probably continue looping it for the rest of the day. We don't have a wireless internet connection that available at our flying field, but someday if we are
able to rig something up, we'll be able to inject our live flight data into the multiplayer system which and others could come fly [virtually]
with us. That would be kind of a neat trick.

== Using Proprietary/External FDMs ==
Take a look at net_fdm.* and native_ctrls.* in the FlightGear/src/Network directory. Those are the one you want to use.

Also look at Docs/README.IO

You can turn off the built in flight dynamics engine with the --fdm=null option. Then specify the --native-fdm= and --native-ctrls= options with appropriate parameters. That sets up FlightGear to receive data from an external source. Then all you have to do is look at the UDP packet structure and send data packets from your external software. There maybe some trickier details if you've never done socket communication before, but it's been done many times and there are many examples to look at including the FlightGear code itself. You can configure one "master" copy of FlightGear to control one (or more) other copies of FlightGear in this same way -- this is one way to achieve a multi-screen cockpit display if you don't want to plug multiple monitors into a single computer.

Look in net_fdm.hxx for the variable type and units, as in radians and meters.

The goal is to also include in that subdir some stand along FDM wrapper apps that interface to FlightGear via the ExternalNet interface. These would act as examples for people interested in integrating other FDM codes this way.

I also removed the External fdm because it is replaced by a better named NullFDM fdm. The --fdm=external option is stull supported for backwards compatibility but maps to --fdm=null (which does the same thing.)

So the only command line change would be to go from
<pre>
--native=socket,in,30,,5500,udp --fdm=external
</pre>
to
<pre>
--native=socket,in,30,,5500,udp --fdm=null
</pre>
--fdm=external still works even though --fdm=null is now the 'official' way to do it.

Some of the benefits of running the FDM portion as a standalone app separate from flight gear are:

* you can kill and restart the fdm portion without restarting FG.
* you can change/recompile/rerun the fdm portion without restarting FG.
* when developing the fdm portion, you don't need to spend the overhead of compiling/linking with FG and starting FG from scratch.
* you can interface non-GPL'd flight dynamics code via this mechanism.
* you can run the FDM on a separate machine/OS, separate CPU, you could even develop it in a different computer language.

Almost all if not all of the FGNetFDM values are getting filled in by the fdm. But it is likely that not all fdm's will generate entirely the same output fields, and not all of them will care about entirely the same inputs.

Out of necessity this structure is extended as new needs are discovered. We include a version number in the structure so software on either end can verify they are passing the same version of the contents.

The included source code that can take an instance of NetFDM and translate it into FG properties as well as the code that can build an instance of NetFDM from the current state of the property tree can optionally do it's work in network byte order.

When the structure does change, it is literally trivial to upgrade the other end. Copy over the new structure, see if you care about any of the new fields (usually not) and recompile your software.

If they want the ultimate in flexibility they should use Eric's "generic" output facility because there you can define exactly what output you want via an xml config file and it only changes when you want it to change.

== FlightGear as a Scenery Generator ==
FlightGear has exactly what you are looking for.

Look in src/Network/net_fdm.hxx ... this defines a structure that you can pass to FG. If you run FG with the --fdm=null option you will disable the internal flight dynamics and you will get whatever you pass in with the net_fdm.hxx structure.

Additionally we have a net_ctrls.hxx structure which you can also pass to FG. That will enable the controls (ailerons, flaps, gear, etc.) to be animated in the external views.

FlightGear has been used as an image generator on an FAA Level 3 FTD certified simulator. I've seen people post questions who are also working on leveraging FG as an image generator in one way or another ... either interfacing it to an existing simulator, or trying to import the FG scenery into their existing image generation software, or trying to import their existing image generation scenery back into FG.

There are a couple things to keep in mind that you will run into soon enough.

* You need the airport runway and navaid database to match between FlightGear and PS1. If they don't, you are going to be perfectly lined up on your approach in PS1, and may pop out of the clouds to find yourself severely misaligned with the runway.

* You need PS1 and FG to agree on the ground elevation. FG can be configured to send export the elevation of the ground in the FG world at the current spot, but you'd need to find a way to import that back into PS1. If you can pull that off, then you can properly taxi on FG's non-flat runways, you won't be able to fly underground, you won't crash into mystery terrain that is in PS1, but not if FG, etc. etc.

* You will want to pass along weather parameters to FG so that the wind socks are blowing the right way, the cloud layers are in the right place, etc. etc. And if you use multiple displays, you want them all configured the same way and synced with time so they all draw the sun/moon/ stars in the same place, and have the same shading, coloring, and lighting of the scene.

* On good hardware, FG can run at 60+ fps. If I recall, PS1 updates on the DOS interrupt which is 18.2 hz I think. You will get "jittery" video if you don't sync FG exactly to the PS1 clock, or some multiple of that. I'm not sure if it's possible to run your monitor refresh at an exact multiple of 18.2 so you might just have to live with jittery video which you probably don't mind if you are using MSFS as your reference point. :-)

So for the most part, it is all very doable, and you should be able to get something up and running very quickly, especially if you have some socket networking experience, but there are some things that you'll need to consider and handle to really make it work well.

== FGNetFDM & FGNetCtrl ==
What we did with the FGNetFDM and FGNetCtrls structures was to write separate header files outside the scope of the FlightGear project and put these into the public domain.

There is no problem with including these files in a GPL program such as FlightGear, and also no problem including these files in some other proprietary software.

This is not to be seen as an attempt to circumvent the GPL. It's just a convenience to make communication easier and make FG usable for a larger set of tasks.

It's a good idea to think in terms of a "data" channel and a "command" channel. The data channel would be the NetFDM structure that would get blasted over via UDP at a fast rate (i.e. 60 hz) If you drop a packet, don't spend time trying to resend old data, just send the new data and keep going.

The "command" channel (props/telnet) is a lower bandwidth, high reliablity channel. You are guaranteed that every message gets to the reciever once (and only once.) This is great for setting up weather conditions, time of day, camera parameters, and anything else that might hav

And if you are using FlightGear as a visualization system for your UAV (either live or replaying the data) you can turn on multiplayer mode and inject yourself into the multiplayer system. I'm doing that right now. If you want to see my university's UAV in action, go to mpmap01.flightgear.org right now and click the checkbox next to the Rascal-1 call sign. I'm looping the data and will probably continue looping it for the rest of the day. We don't have a wireless internet connection that available at our flying field, but someday if we are able to rig something up, we'll be able to inject our live flight data into the multiplayer system which and others could come fly [virtually] with us. That would be kind of a neat trick.e an impact on the visuals. We have a convenient "telnet" interface to all the internal properties and built in commands. Anything you can set from the keyboard, or mouse, or gui, you can do from a remote program or script. It's much lower bandwidth, but very convenient.

You can use the net-ctrls and native-ctrl structures in the Network directory to modify the properties to set radio/nav frequencies but that
takes a bit of work to hack the code. Some of which may not be applicable for general use. Approach would be to add the frequency variables to the
network packet and modify the source to load the values from the received packet into the appropriate properties in FG. Then you'll need to create the
network program on the "simulated radio stack" client to build the packet, create the socket connection, and establish network communications. At least
that's the approach I've taken for my 747 project. If you're modestly fluent in C++, the existing code serves as a good example and base to expand to
meet your needs.

One big problem ;-) The network packet loads at whatever rate you select via the socket options and overwrites any and all the property values called out
in the net-ctrls data structure and that includes all the controls for flying. Which is fine if you plan to also control FG with an external machine. I suppose you could "turn off" updating those properties you don't want to update in FGNetCtrls2Props, but that's a messy hack.

I'm assuming you don't need a lot of bandwidth. There are other options less envasive and unless you plan to expand your hardware at some future date
those might meet your needs

The two native protocols compliment each other. Originally they were designed to communicate with an external FDM. FlightGear would send native-ctrls to the remote FDM module, and it would reply with native-fdm data.

You can sync up visuals by only using native-fdm= since that contains all the position and orientation information.

If you also want to syncronize the control inputs (i.e. for animating the external model) you can add that. This comes in really handy if you are running the wright flyer on a 5 projector wrap around visual system. You want to see that big elevator waggling in front of you as you struggle to stay alive for just a few more seconds.

The slaves should use --fdm=null so they don't try to compute their own positional information.

It really depends on what you are trying to do.

I think you'll find most of the information you need in
* src/Network/net_fdm.hxx
and (if you also send control movements)
* src/Network/net_ctrls.hxx
but some processing (like byte order swapping) most likely is in
* src/Network/native_fdm.{hxx,cxx}
and
* src/Network/native_ctrls.{hxx,cxx}

By default, everything that is transferred is done so in network format (big-endian). Sending data in any other format is asking for trouble (i.e., how can I send data from my PowerPC to my x86 box if it is not in network format). Look at source/src/Network/native_ctrls.cxx to see how the data is processed. The sizes are:

* Boolean = 8-bits
* Integer = 32-bits
* Float = 32-bits
* Double = 64-bits

Don't forget data aligment. The C/C++ compiler will pad data so that is alighed per the processor's architecture. This means that an array of three bytes that is followed by an integer will *MOST LIKELY* have a hidden fourth byte applied after the array and before the integer. The compiler will align data on its native boundary (i.e., 32-bit numbers will start on a 32-bit boundary).

Most compilers have a set of switches you can use to control structure padding and alignment. But indeed, there's nothing in the spec that
says what the proper alignment should be.

FWIW, every compiler I know stores each element in order, and pads it up to its "natural" alignment. So this struct takes 8 bytes in memory
on all platforms I know:

struct { int8_t a; int8_t b; int32_t c; }

But this one takes at least 12 (word-size padding is added at the end on most or all compiler):

struct { int8_t a; int32_t b; int8_t c; }

So long as the structure honors those rules, you should be more or less portable. Other options are, obviously, to store everything as a
int32_t and do the bit packing yourself. You'll need to do this in any case if you want endian compatibility. This is one of the many
reasons that dumping structures from memory to I/O is considered
problematic.

In general, You must never send a binary stucture across a network. Even if you get the sizes correct, you'll have endian problems when running different
architectures (PC vs Mac). You must manually ship the data bytes in a defined order and reconstruct it at the other end. At that point, it doesn't matter what the padding or for different compilers (or the order) is because you won't be sending the padding - just the data.

Never block transfer a structure by providing a pointer and size, there is simply no way for that to work cross-platform.

If deciding to use a binary interface, I'd recommend using XDR (RFC 1014) throughout (already used by the MP system).

It's not too far away from what FG currently has (for the more common platforms at least) but has the advantage of being well-defined.

<stdint.h> is indeed a standard C header but *not* in C++ (though it might be included in the future under the name <cstdint>). AFAIK even if <stdint.h> defines the number of bits for the individual types, it does *not* imply anything about where the individual bits live in memory.
Others have brought up issues like alignment, etc.

The net_fdm.hxx and net_ctrls.hxx files are from Flightgear and define two data structures that can be sent and received by fgfs. In your
program you can receive the FGNetCtrls structure, change the parameters you want to control, and send it back.

== Native Socket ==
Before we interface with FlightGear on a socket, consider this demonstration using the native protocol. TODO: explain native protocol
--native=socket,direction,hz,machine,port,type
direction = in, out or bi
hz = number of times per second
machine = machine name or ip address if client (leave empty if server)
port = port, leave empty to let system choose
type = tcp or udp
eg
--native=socket,out,10,,5444,udp
^ no machine so binds to localhost
--native=socket,in,1,192.5.22.33 ,6789,tcp
//**Important**. space = fail ^

An example of slaving two instances of flight gear together on seperate machines
fgfs1: --native=socket,out,30,seattle.com,5500,udp
fgfs2: --native=socket,in,30,tolouse.net,5500,udp --fdm=external

This instructs the first copy of fgfs to send UDP packets in the
native format to a machine called seattle.com on port 5500.

The second copy of fgfs will accept UDP packets (from anywhere) on port 5500.
Note the additional --fdm=external option. This tells the second copy of fgfs to not run
the normal flight model, but instead set the FDM values based on an external source, the network in this case.

[[Category:Property Tree]]

Howto:Set up a multiplayer server

2012-09-30T00:50:08Z

Tcbetka: /* Pre-Requisites */

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

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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.

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:46:15Z

Tcbetka: /* Setting up the config file */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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.

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:45:26Z

Tcbetka: /* Getting & Building fgms */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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

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

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:44:43Z

Tcbetka: /* Installation */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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

* Finally, from inside the build-fgms directory, you can start fgms with the command: ./fgms
If the program starts correctly, you should see several lines of console output with the message "Main server started!" as one of the final lines of output.

== Compiling FGMS ==

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

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

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:44:21Z

Tcbetka: /* Setting up the config file */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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

* Finally, from inside the build-fgms directory, you can start fgms with the command: ./fgms
If the program starts correctly, you should see several lines of console output with the message "Main server started!" as one of the final lines of output.

== Compiling FGMS ==

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

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

== Installation ==

To install fgms, type ''make install''.
If you want to install fgms without root privileges, you will have to customize your configuration and build settings accordingly (please consult the previously mentioned INSTALL file or run ./configure --help for details). To install fgms within a subdirectory of your home directory, named 'bin' you could for example run:

$ PREFIX=~/bin ./configure --prefix=$PREFIX && make install || echo "Oops, there was a problem !"

Depending on whether ~/bin exists already and is already specified in your $PATH environment variable, you may also want to add this folder to $PATH.

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:42:15Z

Tcbetka: /* Getting & Building fgms */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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

* Finally, from inside the build-fgms directory, you can start fgms with the command: ./fgms
If the program starts correctly, you should see several lines of console output with the message "Main server started!" as one of the final lines of output.

== Compiling FGMS ==

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 directory ''src/server'', so copy fgms_example.conf to fgms.conf and edit it to suit your situation. 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.

== Installation ==

To install fgms, type ''make install''.
If you want to install fgms without root privileges, you will have to customize your configuration and build settings accordingly (please consult the previously mentioned INSTALL file or run ./configure --help for details). To install fgms within a subdirectory of your home directory, named 'bin' you could for example run:

$ PREFIX=~/bin ./configure --prefix=$PREFIX && make install || echo "Oops, there was a problem !"

Depending on whether ~/bin exists already and is already specified in your $PATH environment variable, you may also want to add this folder to $PATH.

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:41:21Z

Tcbetka: /* Compiling FGMS */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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

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

* Finally, from inside the build-fgms directory, you can start fgms with the command: ./fgms
If the program starts correctly, you should see several lines of console output with the message "Main server started!" as one of the final lines of output.

== Compiling FGMS ==

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 directory ''src/server'', so copy fgms_example.conf to fgms.conf and edit it to suit your situation. 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.

== Installation ==

To install fgms, type ''make install''.
If you want to install fgms without root privileges, you will have to customize your configuration and build settings accordingly (please consult the previously mentioned INSTALL file or run ./configure --help for details). To install fgms within a subdirectory of your home directory, named 'bin' you could for example run:

$ PREFIX=~/bin ./configure --prefix=$PREFIX && make install || echo "Oops, there was a problem !"

Depending on whether ~/bin exists already and is already specified in your $PATH environment variable, you may also want to add this folder to $PATH.

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:30:16Z

Tcbetka: /* Getting fgms */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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

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

* Finally, from inside the build-fgms directory, you can start fgms with the command: ./fgms
If the program starts correctly, you should see several lines of console output with the message "Main server started!" as one of the final lines of output.

== Compiling FGMS ==
Follow the steps in the file README.cmake. README.cmake is inside the folder just got from git.

(In general, on any current machine this should ''not'' take any longer than 30-60 seconds)

== Setting up the config file ==

At this point you should have a working fgms binary in the directory ''src/server'', so copy fgms_example.conf to fgms.conf and edit it to suit your situation. 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.

== Installation ==

To install fgms, type ''make install''.
If you want to install fgms without root privileges, you will have to customize your configuration and build settings accordingly (please consult the previously mentioned INSTALL file or run ./configure --help for details). To install fgms within a subdirectory of your home directory, named 'bin' you could for example run:

$ PREFIX=~/bin ./configure --prefix=$PREFIX && make install || echo "Oops, there was a problem !"

Depending on whether ~/bin exists already and is already specified in your $PATH environment variable, you may also want to add this folder to $PATH.

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Howto:Set up a multiplayer server

2012-09-30T00:28:14Z

Tcbetka: /* Getting fgms */

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.
* 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 (compiler), gmake & ranlib (to compile the source code)
* fgms source code, currently version 0.9.11 (do not use CVS/HEAD), see: http://fgms.sourceforge.net and http://sourceforge.net/projects/fgms
* 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.

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

=== Hosting Packages known to be suitable for fgms hosting ===
(yet to be filled in)

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

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

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

* Finally, from inside the build-fgms directory, you can start fgms with the command: ./fgms
If the program starts correctly, you should see several lines of console output with the message "Main server started!" as one of the final lines of output.

== Compiling FGMS ==
Follow the steps in the file README.cmake. README.cmake is inside the folder just got from git.

(In general, on any current machine this should ''not'' take any longer than 30-60 seconds)

== Setting up the config file ==

At this point you should have a working fgms binary in the directory ''src/server'', so copy fgms_example.conf to fgms.conf and edit it to suit your situation. 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.

== Installation ==

To install fgms, type ''make install''.
If you want to install fgms without root privileges, you will have to customize your configuration and build settings accordingly (please consult the previously mentioned INSTALL file or run ./configure --help for details). To install fgms within a subdirectory of your home directory, named 'bin' you could for example run:

$ PREFIX=~/bin ./configure --prefix=$PREFIX && make install || echo "Oops, there was a problem !"

Depending on whether ~/bin exists already and is already specified in your $PATH environment variable, you may also want to add this folder to $PATH.

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

== Related content ==
* [[Howto: Multiplayer|Multiplayer howto]]
* [[MPmap]]

[[Category:Multiplayer]]
[[Category:Howto|Set up a multiplayer server]]
[[fr:Installer un serveur multijoueur]]

Building FlightGear - Debian

2011-01-07T19:01:04Z

Tcbetka: /* Note */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or GIT on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver. 

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.debian.org!)
*git, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (min 1.37, 1.40 available for Lenny on backports.debian.org)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or GIT in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. 
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (GIT about 3.5 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

Alternatively, you can directly extract the required include files:
tar xvf boost_1_37_0.tar.bz2 -C $prefix/include --strip 1 --wildcards --no-wildcards-match-slash '*/boost'

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear GIT as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

== Note ==
''From this point forward when providing the "LDFLAGS" string, you should use the path specific to your installation. For 32-bit installations this will probably be the path ending in /lib. In a 64-bit installation, this '''may''' be the path ending in /lib64, but doesn't have to be. You must verify this for your build, because you do not have to include both paths in the following compilations.''

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

The primary gitorious source is known to have trouble cloning the data, the mapserver mirror usually has no problems:
cd $prefix
git clone git://mapserver.flightgear.org/fgdata data

Also, there are bundles (snapshots) available that can be retrieved with your favorite download manager. This way you can resume interrupted downloads. After unpacking only a comparatively small amount of data has to be transferred from the git server to synchronize your repository.
$ cd $prefix
$ wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle
$ git clone fgdata.bundle fgdata
Initialized empty Git repository in fgdata/.git/
warning: unrecognized header: -deg" - /orientation/roll += "-deg" - /position/altitude += "-ft" - /position/altitude-agl += "-ft" - /position/latitude += "-deg" --/position/longitude += "-deg" - /radios/adf/frequencies/selected += "-khz" - /radios/adf/frequencies/
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ cd fgdata
$ git branch master-tmp origin/master
Branch master-tmp set up to track remote branch refs/remotes/origin/master.
$ git remote rm origin
$ git remote add origin git://gitorious.org/fg/fgdata
$ git fetch origin
remote: Counting objects: 5596, done.
remote: Compressing objects: 100% (2919/2919), done.
remote: Total 4266 (delta 2540), reused 2166 (delta 1297)
Receiving objects: 100% (4266/4266), 117.93 MiB | 1374 KiB/s, done.
Resolving deltas: 100% (2540/2540), completed with 628 local objects.
From git://gitorious.org/fg/fgdata
* [new branch] PRE_OSG_PLIB_20061029 -> origin/PRE_OSG_PLIB_20061029
* [new branch] master -> origin/master
* [new tag] last-cvs -> last-cvs
* [new tag] mapserver -> mapserver
$ git branch -D master-tmp
Deleted branch master-tmp.
$ git branch --track master origin/master
Branch master set up to track remote branch refs/remotes/origin/master.
$ git checkout

The bundle may be periodically updated and bundles from different sources need not be the same. The file size for the above bundle dated 2010-06-09 is 2394168314, while the md5 checksum is
$ md5sum fgdata.bundle
2996221bd2b8ab7740f332f49396cf56 fgdata.bundle

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Building FlightGear - Debian

2011-01-07T19:00:20Z

Tcbetka: /* Note: */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or GIT on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver. 

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.debian.org!)
*git, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (min 1.37, 1.40 available for Lenny on backports.debian.org)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or GIT in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. 
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (GIT about 3.5 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

Alternatively, you can directly extract the required include files:
tar xvf boost_1_37_0.tar.bz2 -C $prefix/include --strip 1 --wildcards --no-wildcards-match-slash '*/boost'

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear GIT as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

== Note ==
From this point forward when providing the "LDFLAGS" string, you should use the path specific to your installation. For 32-bit installations this will probably be the path ending in /lib. In a 64-bit installation, this '''may''' be the path ending in /lib64, but doesn't have to be. You must verify this for your build, because you do not have to include both paths in the following compilations.

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

The primary gitorious source is known to have trouble cloning the data, the mapserver mirror usually has no problems:
cd $prefix
git clone git://mapserver.flightgear.org/fgdata data

Also, there are bundles (snapshots) available that can be retrieved with your favorite download manager. This way you can resume interrupted downloads. After unpacking only a comparatively small amount of data has to be transferred from the git server to synchronize your repository.
$ cd $prefix
$ wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle
$ git clone fgdata.bundle fgdata
Initialized empty Git repository in fgdata/.git/
warning: unrecognized header: -deg" - /orientation/roll += "-deg" - /position/altitude += "-ft" - /position/altitude-agl += "-ft" - /position/latitude += "-deg" --/position/longitude += "-deg" - /radios/adf/frequencies/selected += "-khz" - /radios/adf/frequencies/
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ cd fgdata
$ git branch master-tmp origin/master
Branch master-tmp set up to track remote branch refs/remotes/origin/master.
$ git remote rm origin
$ git remote add origin git://gitorious.org/fg/fgdata
$ git fetch origin
remote: Counting objects: 5596, done.
remote: Compressing objects: 100% (2919/2919), done.
remote: Total 4266 (delta 2540), reused 2166 (delta 1297)
Receiving objects: 100% (4266/4266), 117.93 MiB | 1374 KiB/s, done.
Resolving deltas: 100% (2540/2540), completed with 628 local objects.
From git://gitorious.org/fg/fgdata
* [new branch] PRE_OSG_PLIB_20061029 -> origin/PRE_OSG_PLIB_20061029
* [new branch] master -> origin/master
* [new tag] last-cvs -> last-cvs
* [new tag] mapserver -> mapserver
$ git branch -D master-tmp
Deleted branch master-tmp.
$ git branch --track master origin/master
Branch master set up to track remote branch refs/remotes/origin/master.
$ git checkout

The bundle may be periodically updated and bundles from different sources need not be the same. The file size for the above bundle dated 2010-06-09 is 2394168314, while the md5 checksum is
$ md5sum fgdata.bundle
2996221bd2b8ab7740f332f49396cf56 fgdata.bundle

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Building FlightGear - Debian

2011-01-07T18:59:46Z

Tcbetka: /* OpenSceneGraph */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or GIT on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver. 

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.debian.org!)
*git, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (min 1.37, 1.40 available for Lenny on backports.debian.org)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or GIT in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. 
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (GIT about 3.5 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

Alternatively, you can directly extract the required include files:
tar xvf boost_1_37_0.tar.bz2 -C $prefix/include --strip 1 --wildcards --no-wildcards-match-slash '*/boost'

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear GIT as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

== Note: ==
From this point forward when providing the "LDFLAGS" string, you should use the path specific to your installation. For 32-bit installations this will probably be the path ending in /lib. In a 64-bit installation, this '''may''' be the path ending in /lib64, but doesn't have to be. You must verify this for your build, because you do not have to include both paths in the following compilations.

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

The primary gitorious source is known to have trouble cloning the data, the mapserver mirror usually has no problems:
cd $prefix
git clone git://mapserver.flightgear.org/fgdata data

Also, there are bundles (snapshots) available that can be retrieved with your favorite download manager. This way you can resume interrupted downloads. After unpacking only a comparatively small amount of data has to be transferred from the git server to synchronize your repository.
$ cd $prefix
$ wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle
$ git clone fgdata.bundle fgdata
Initialized empty Git repository in fgdata/.git/
warning: unrecognized header: -deg" - /orientation/roll += "-deg" - /position/altitude += "-ft" - /position/altitude-agl += "-ft" - /position/latitude += "-deg" --/position/longitude += "-deg" - /radios/adf/frequencies/selected += "-khz" - /radios/adf/frequencies/
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ cd fgdata
$ git branch master-tmp origin/master
Branch master-tmp set up to track remote branch refs/remotes/origin/master.
$ git remote rm origin
$ git remote add origin git://gitorious.org/fg/fgdata
$ git fetch origin
remote: Counting objects: 5596, done.
remote: Compressing objects: 100% (2919/2919), done.
remote: Total 4266 (delta 2540), reused 2166 (delta 1297)
Receiving objects: 100% (4266/4266), 117.93 MiB | 1374 KiB/s, done.
Resolving deltas: 100% (2540/2540), completed with 628 local objects.
From git://gitorious.org/fg/fgdata
* [new branch] PRE_OSG_PLIB_20061029 -> origin/PRE_OSG_PLIB_20061029
* [new branch] master -> origin/master
* [new tag] last-cvs -> last-cvs
* [new tag] mapserver -> mapserver
$ git branch -D master-tmp
Deleted branch master-tmp.
$ git branch --track master origin/master
Branch master set up to track remote branch refs/remotes/origin/master.
$ git checkout

The bundle may be periodically updated and bundles from different sources need not be the same. The file size for the above bundle dated 2010-06-09 is 2394168314, while the md5 checksum is
$ md5sum fgdata.bundle
2996221bd2b8ab7740f332f49396cf56 fgdata.bundle

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Building FlightGear - Debian

2011-01-07T18:55:47Z

Tcbetka: /* SimGear */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or GIT on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver. 

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.debian.org!)
*git, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (min 1.37, 1.40 available for Lenny on backports.debian.org)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or GIT in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. 
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (GIT about 3.5 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

Alternatively, you can directly extract the required include files:
tar xvf boost_1_37_0.tar.bz2 -C $prefix/include --strip 1 --wildcards --no-wildcards-match-slash '*/boost'

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear GIT as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

(Note: From this point forward when providing the "LDFLAGS" string, you should use the path specific to your installation. For 32-bit installations this will probably be the path ending in /lib. In a 64-bit installation, this '''may''' be the path ending in /lib64. You should verify this for your build, because you do not have to include both paths in the following compilations.)

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

The primary gitorious source is known to have trouble cloning the data, the mapserver mirror usually has no problems:
cd $prefix
git clone git://mapserver.flightgear.org/fgdata data

Also, there are bundles (snapshots) available that can be retrieved with your favorite download manager. This way you can resume interrupted downloads. After unpacking only a comparatively small amount of data has to be transferred from the git server to synchronize your repository.
$ cd $prefix
$ wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle
$ git clone fgdata.bundle fgdata
Initialized empty Git repository in fgdata/.git/
warning: unrecognized header: -deg" - /orientation/roll += "-deg" - /position/altitude += "-ft" - /position/altitude-agl += "-ft" - /position/latitude += "-deg" --/position/longitude += "-deg" - /radios/adf/frequencies/selected += "-khz" - /radios/adf/frequencies/
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ cd fgdata
$ git branch master-tmp origin/master
Branch master-tmp set up to track remote branch refs/remotes/origin/master.
$ git remote rm origin
$ git remote add origin git://gitorious.org/fg/fgdata
$ git fetch origin
remote: Counting objects: 5596, done.
remote: Compressing objects: 100% (2919/2919), done.
remote: Total 4266 (delta 2540), reused 2166 (delta 1297)
Receiving objects: 100% (4266/4266), 117.93 MiB | 1374 KiB/s, done.
Resolving deltas: 100% (2540/2540), completed with 628 local objects.
From git://gitorious.org/fg/fgdata
* [new branch] PRE_OSG_PLIB_20061029 -> origin/PRE_OSG_PLIB_20061029
* [new branch] master -> origin/master
* [new tag] last-cvs -> last-cvs
* [new tag] mapserver -> mapserver
$ git branch -D master-tmp
Deleted branch master-tmp.
$ git branch --track master origin/master
Branch master set up to track remote branch refs/remotes/origin/master.
$ git checkout

The bundle may be periodically updated and bundles from different sources need not be the same. The file size for the above bundle dated 2010-06-09 is 2394168314, while the md5 checksum is
$ md5sum fgdata.bundle
2996221bd2b8ab7740f332f49396cf56 fgdata.bundle

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Building FlightGear - Debian

2011-01-07T18:43:27Z

Tcbetka: /* fgrun */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or GIT on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver. 

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.debian.org!)
*git, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (min 1.37, 1.40 available for Lenny on backports.debian.org)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or GIT in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. 
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (GIT about 3.5 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

Alternatively, you can directly extract the required include files:
tar xvf boost_1_37_0.tar.bz2 -C $prefix/include --strip 1 --wildcards --no-wildcards-match-slash '*/boost'

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear GIT as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

The primary gitorious source is known to have trouble cloning the data, the mapserver mirror usually has no problems:
cd $prefix
git clone git://mapserver.flightgear.org/fgdata data

Also, there are bundles (snapshots) available that can be retrieved with your favorite download manager. This way you can resume interrupted downloads. After unpacking only a comparatively small amount of data has to be transferred from the git server to synchronize your repository.
$ cd $prefix
$ wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle
$ git clone fgdata.bundle fgdata
Initialized empty Git repository in fgdata/.git/
warning: unrecognized header: -deg" - /orientation/roll += "-deg" - /position/altitude += "-ft" - /position/altitude-agl += "-ft" - /position/latitude += "-deg" --/position/longitude += "-deg" - /radios/adf/frequencies/selected += "-khz" - /radios/adf/frequencies/
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ cd fgdata
$ git branch master-tmp origin/master
Branch master-tmp set up to track remote branch refs/remotes/origin/master.
$ git remote rm origin
$ git remote add origin git://gitorious.org/fg/fgdata
$ git fetch origin
remote: Counting objects: 5596, done.
remote: Compressing objects: 100% (2919/2919), done.
remote: Total 4266 (delta 2540), reused 2166 (delta 1297)
Receiving objects: 100% (4266/4266), 117.93 MiB | 1374 KiB/s, done.
Resolving deltas: 100% (2540/2540), completed with 628 local objects.
From git://gitorious.org/fg/fgdata
* [new branch] PRE_OSG_PLIB_20061029 -> origin/PRE_OSG_PLIB_20061029
* [new branch] master -> origin/master
* [new tag] last-cvs -> last-cvs
* [new tag] mapserver -> mapserver
$ git branch -D master-tmp
Deleted branch master-tmp.
$ git branch --track master origin/master
Branch master set up to track remote branch refs/remotes/origin/master.
$ git checkout

The bundle may be periodically updated and bundles from different sources need not be the same. The file size for the above bundle dated 2010-06-09 is 2394168314, while the md5 checksum is
$ md5sum fgdata.bundle
2996221bd2b8ab7740f332f49396cf56 fgdata.bundle

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

OpenSceneGraph

2011-01-06T13:09:06Z

Tcbetka: /* The latest OSG version from svn */

As of October 29th 2006, [[FlightGear]] has migrated graphics functions from [[PLIB]] to '''OpenSceneGraph'''. [[FlightGear 1.9.0]], released Decemeber 22, 2008, marked the release of the OSG version of FlightGear. [[PLIB]] is still used for network, joystick and gui functions.

Thanks to Mathias Fröhlich and Tim Moore, we can use an current OpenSceneGraph SVN version

[[Image:Flightgear uml associations class diagram.png|thumb|270px|An [[UML Diagrams|UML]] class diagram disclosing the associations between some classes of the FlightGear source code.]]

== Getting OpenSceneGraph ==

=== The latest OSG version from svn ===

The OpenSceneGraph project uses [http://svnbook.red-bean.com/nightly/en/index.html Subversion (SVN)].

(Note: The source code should not be downloaded to the build.osg directory, or the build will not work correctly. See below.)

To check out OpenSceneGraph:

svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

The OpenSceneGraph repository includes all parts of OSG you need.

'''Download the latest stable release '''

http://www.openscenegraph.org/projects/osg/wiki/Downloads

'''Various mirrors in case the main OSG site is down (frequently)'''

http://www.freebsd.org/cgi/pds.cgi?ports/graphics/osg

== Compiling OpenSceneGraph ==

OpenSceneGraph uses cmake. Since OSG version 2.7.3 (8th Oct 2008) to build it there is a relatively new version of cmake needed. According to OSGs CMakeLists.txt it's 2.6.1 but cmake 2.6.0-5 from [http://backports.org/dokuwiki/doku.php backports.org] for Debian/Etch does the trick.
It's also possible to comment out lines 25 to 27 in OSGs CMakeLists.txt:
# if(POLICY CMP0008)
# cmake_policy(SET CMP0008 OLD)
# endif(POLICY CMP0008)

A minimal build instruction for unix systems is

mkdir build.osg
cd build.osg
ccmake ../path/to/osg/source
make
make install

On other systems the steps might be different.

Recommended options to set in the ccmake menus:
* Build type: Release
* You don't need to build the examples, wrappers or applications.

=== Installing OpenSceneGraph and FlightGear with --prefix ===

If you use --prefix to choose were to install FlightGear and do not want to install OSG globally on the system this can be done with the following method:

OpenSceneGraph uses cmake so to build it do

mkdir build.osg
cd build.osg
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="${MY_PREFIX}" ../path/to/osg/source
make
make install

or if you want to avoid needing to set LD_LIBRARY_PATH

mkdir build.osg
cd build.osg
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="${MY_PREFIX}" -D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" ../path/to/osg/source
make
make install

Configure and build SimGear and FlightGear with --prefix as usual.

No need to install any quickly changing software globally.

Installing with --prefix is a very nice way to keep several distinct and independent versions of FlightGear around. To start a new $PREFIX directory you'll also need to install plib in it, but that is easy. Most other needed dependencies are usually available through the package system of most Linux distributions (e.g. FreeGLUT, SDL, ALSA, etc).

== Regressions in CVS/HEAD ==
This section is meant to always remain up to date with the latest version in CVS/HEAD, please make sure to add/delete items as necessary.
* feature to disable scenery rendering via /sim/rendering/draw-otw property is not working at the moment (11/2008)

== Current issues (very out of date) ==

* <strike>The 2D Panels and the rendering order of instruments ... is wrong.</strike>

* transparency issues:
** <strike>runway lights shine through panel:</strike>
** runway lights shine through cloud layers in an awkward way:
** 2D-cloud layers flood into cockpit
** The prop of the C172 block the view on the waves of the carrier
** The reflector gun sight on the Seahawk causes other transparent objects (carrier wake etc.) to disappear
** A new overhead window in the C172 (inside out)

* Runway lighting seems to have rendering artefacts on ATI Cards.

* Enhanced runway lighting option in the drop-down menu seems to have no effect - light always appear enhanced.

* <strike>Seneca II HSI: upper instrument clipping issue for NAV/HDG flags, heading bug, pointer</strike>

[[List of 'compatible' aircrafts]] TO BE CONTINUED (NOTE: the list is out of date.)

== Missing features ==
Due to the migration from PLIB to OSG, some of the features seen in past versions of FlightGear are now temporarily non-functional. These are:

* <strike>3D clouds</strike> 3D clouds back thanks to Stuart Buchanan still have some visual artifacts

* <strike>Rendering of some scenes is not perfect.</strike>

* Shadows

* Exhaust shader

* Weather Radar is there, but of course not showing any clouds

* cloud layers don't follow the curve of the earth

* Menu Items have no effect
** Enhanced Runway Lights
** Bump Mapped Clouds

== Miscellaneous OSG benefits ==
* Models and scenery load in a separate thread
* Tree shaders allow "forests" of trees
* Improved precipitation modeling
* "Pick" animations enable greater realism and ease of creation for 3D cockpits
* Multi-monitor views

Mathias: "I think that we should make use in the longer term of the Producers
capabilities for multiple view installations.
But not only multipipe installs will benefit from that. The Producer will also
help to get benefit from multicore SMP machines.
For that the following article is of huge interest:
http://www.donburns.net/OSG/Articles/OSGMP/"

== Getting the PLIB Code ==

Use the tag <tt>PRE_OSG_PLIB_20061029</tt> for checking out the branch with the plib scenegraph.

For SimGear, this works (more or less) as follows:

'''cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 login'''
'''CVS passwd: guest'''
'''cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 co source'''
'''cd source'''
'''cvs up -rPRE_OSG_PLIB_20061029'''

For FlightGear, you have to update the "source" directory:

'''cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login'''
'''CVS passwd: guest'''
'''cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co -rPRE_OSG_PLIB_20061029 source
'''
The data directory should be the CVS HEAD version. Some aircraft, however, have a PRE_OSG_PLIB_20061029 branch that works better with FlightGear/plib, e.g Hawker Hunter.

== External link ==
* http://www.openscenegraph.org/

{{Building}}

[[Category:Software]]

OpenSceneGraph

2011-01-06T13:08:08Z

Tcbetka: /* The latest OSG version from svn */

As of October 29th 2006, [[FlightGear]] has migrated graphics functions from [[PLIB]] to '''OpenSceneGraph'''. [[FlightGear 1.9.0]], released Decemeber 22, 2008, marked the release of the OSG version of FlightGear. [[PLIB]] is still used for network, joystick and gui functions.

Thanks to Mathias Fröhlich and Tim Moore, we can use an current OpenSceneGraph SVN version

[[Image:Flightgear uml associations class diagram.png|thumb|270px|An [[UML Diagrams|UML]] class diagram disclosing the associations between some classes of the FlightGear source code.]]

== Getting OpenSceneGraph ==

=== The latest OSG version from svn ===

The OpenSceneGraph project uses [http://svnbook.red-bean.com/nightly/en/index.html Subversion (SVN)].

(Note: The source code should not be downloaded to the build.osg directory, or the build will not work correctly.)

To check out OpenSceneGraph:

svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

The OpenSceneGraph repository includes all parts of OSG you need.

'''Download the latest stable release '''

http://www.openscenegraph.org/projects/osg/wiki/Downloads

'''Various mirrors in case the main OSG site is down (frequently)'''

http://www.freebsd.org/cgi/pds.cgi?ports/graphics/osg

== Compiling OpenSceneGraph ==

OpenSceneGraph uses cmake. Since OSG version 2.7.3 (8th Oct 2008) to build it there is a relatively new version of cmake needed. According to OSGs CMakeLists.txt it's 2.6.1 but cmake 2.6.0-5 from [http://backports.org/dokuwiki/doku.php backports.org] for Debian/Etch does the trick.
It's also possible to comment out lines 25 to 27 in OSGs CMakeLists.txt:
# if(POLICY CMP0008)
# cmake_policy(SET CMP0008 OLD)
# endif(POLICY CMP0008)

A minimal build instruction for unix systems is

mkdir build.osg
cd build.osg
ccmake ../path/to/osg/source
make
make install

On other systems the steps might be different.

Recommended options to set in the ccmake menus:
* Build type: Release
* You don't need to build the examples, wrappers or applications.

=== Installing OpenSceneGraph and FlightGear with --prefix ===

If you use --prefix to choose were to install FlightGear and do not want to install OSG globally on the system this can be done with the following method:

OpenSceneGraph uses cmake so to build it do

mkdir build.osg
cd build.osg
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="${MY_PREFIX}" ../path/to/osg/source
make
make install

or if you want to avoid needing to set LD_LIBRARY_PATH

mkdir build.osg
cd build.osg
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="${MY_PREFIX}" -D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" ../path/to/osg/source
make
make install

Configure and build SimGear and FlightGear with --prefix as usual.

No need to install any quickly changing software globally.

Installing with --prefix is a very nice way to keep several distinct and independent versions of FlightGear around. To start a new $PREFIX directory you'll also need to install plib in it, but that is easy. Most other needed dependencies are usually available through the package system of most Linux distributions (e.g. FreeGLUT, SDL, ALSA, etc).

== Regressions in CVS/HEAD ==
This section is meant to always remain up to date with the latest version in CVS/HEAD, please make sure to add/delete items as necessary.
* feature to disable scenery rendering via /sim/rendering/draw-otw property is not working at the moment (11/2008)

== Current issues (very out of date) ==

* <strike>The 2D Panels and the rendering order of instruments ... is wrong.</strike>

* transparency issues:
** <strike>runway lights shine through panel:</strike>
** runway lights shine through cloud layers in an awkward way:
** 2D-cloud layers flood into cockpit
** The prop of the C172 block the view on the waves of the carrier
** The reflector gun sight on the Seahawk causes other transparent objects (carrier wake etc.) to disappear
** A new overhead window in the C172 (inside out)

* Runway lighting seems to have rendering artefacts on ATI Cards.

* Enhanced runway lighting option in the drop-down menu seems to have no effect - light always appear enhanced.

* <strike>Seneca II HSI: upper instrument clipping issue for NAV/HDG flags, heading bug, pointer</strike>

[[List of 'compatible' aircrafts]] TO BE CONTINUED (NOTE: the list is out of date.)

== Missing features ==
Due to the migration from PLIB to OSG, some of the features seen in past versions of FlightGear are now temporarily non-functional. These are:

* <strike>3D clouds</strike> 3D clouds back thanks to Stuart Buchanan still have some visual artifacts

* <strike>Rendering of some scenes is not perfect.</strike>

* Shadows

* Exhaust shader

* Weather Radar is there, but of course not showing any clouds

* cloud layers don't follow the curve of the earth

* Menu Items have no effect
** Enhanced Runway Lights
** Bump Mapped Clouds

== Miscellaneous OSG benefits ==
* Models and scenery load in a separate thread
* Tree shaders allow "forests" of trees
* Improved precipitation modeling
* "Pick" animations enable greater realism and ease of creation for 3D cockpits
* Multi-monitor views

Mathias: "I think that we should make use in the longer term of the Producers
capabilities for multiple view installations.
But not only multipipe installs will benefit from that. The Producer will also
help to get benefit from multicore SMP machines.
For that the following article is of huge interest:
http://www.donburns.net/OSG/Articles/OSGMP/"

== Getting the PLIB Code ==

Use the tag <tt>PRE_OSG_PLIB_20061029</tt> for checking out the branch with the plib scenegraph.

For SimGear, this works (more or less) as follows:

'''cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 login'''
'''CVS passwd: guest'''
'''cvs -d :pserver:cvsguest@cvs.simgear.org:/var/cvs/SimGear-0.3 co source'''
'''cd source'''
'''cvs up -rPRE_OSG_PLIB_20061029'''

For FlightGear, you have to update the "source" directory:

'''cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login'''
'''CVS passwd: guest'''
'''cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co -rPRE_OSG_PLIB_20061029 source
'''
The data directory should be the CVS HEAD version. Some aircraft, however, have a PRE_OSG_PLIB_20061029 branch that works better with FlightGear/plib, e.g Hawker Hunter.

== External link ==
* http://www.openscenegraph.org/

{{Building}}

[[Category:Software]]

Autopilot PID controller tuning resources

2009-12-07T01:20:23Z

Tcbetka: /* Getting graphs of Controller action (Linux) */

The [[FlightGear]] [[Autopilot]] is a modular system based on PID controllers. Here are some tips to help tuning such a controller. There is lot of documentation all over the Internet about how to tune the parameters, having this you will have to figure out how the Flightgear PID controller implementation works.

First of all, have a look at the code where you will see the algorithm which is used for our autopilot. Checking existing autopilot configurations in Flightgear aircraft will also help.

There is actually a doc about filters in Flightgear documentation. Filters can be applied on input or ouput values, in other words, before and after the PID controller (execution).

=== FlightGear PID Controller ===
Knowing the algorithm is mandatory, certain values are forbidden, for example they can lead to a division by zero. Then you will have to understand where the parameters apply to act on the chosen correction module. See the schema which is a good reminder while testing.

[[Image:pid_controler.png|thumb|PID parameter's application]]
[[Image:pid_cotroler_data_graph.png|thumb|Datas of an Auto-trim PID Controller displayed as graphs]]

You can find good explanations on how to practically tune the controller. [http://en.wikipedia.org/wiki/PID_controller Wikipedia's article on the PID Controller]

=== Getting graphs of Controller action (Linux) ===
While it's possible to tune a PID controller by testing directly the aircraft behavior under the autopilot control, it can be really useful to get everything in graphical view.

First of all you'll have to turn the PID Controller's debug mode on. That is in the autopilot.xml you are working on. (I didn't try to turn on more than one PID controller's debugging support at the same time).

Then you will get 6 new values displayed on the console at each FG loop. You will need to catch them and format the values in one line. Here is an example of a parser script written in Perl:

<pre>
#!/usr/bin/perl -w
# prints: "input reference P I D output"

while (<STDIN>) {
if ($_ =~ /input\s=\s(-*\d+.*)\sref\s=\s(-*\d+.*)/) {
print STDOUT "$1 $2 ";
} elsif ($_ =~ /P:(-*\d+.*)\sI:(-*\d+.*)\sD:(-*\d+.*)/) {
print STDOUT "$1 $2 $3";
} elsif ($_ =~ /output\s=\s(.*)/) {
print STDOUT " $1\n";
}
}
</pre>

Then you can write them in a file...

<pre>
alexis@linear:~/fgfs$ /usr/local/bin/fgfs 2>&1 | ./PIDcontroller_parser.pl > my_file
</pre>

If you use Linux, You can run Kst simultaneously to read the datas on the fly and watch them displayed together in real time while testing the aircraft.

* [http://kst.kde.org/ Kst, real-time large-dataset viewing and plotting tool]

=== Getting graphs of Controller action (Windows) ===

Under Windows the script of the Linux chapter works (with some minor modifications) together with Live-Graph under Windows, too. Although the output to a logfile is not as fluently as you may experience it under Linux. To get an output you first need a slightly modified version of the above mentioned Perl script:
<pre>
if (<STDIN>) {
print STDOUT "##|##\n";
print STDOUT "Input|Ref|P|I|D|Output\n";
}
while (<STDIN>) {
if ($_ =~ /input\s=\s(-*\d+.*)\sref\s=\s(-*\d+.*)/) {
print STDOUT "$1|$2|";
} elsif ($_ =~ /P:(-*\d+.*)\sI:(-*\d+.*)\sD:(-*\d+.*)/) {
print STDOUT "$1|$2|$3";
} elsif ($_ =~ /output\s=\s(.*)/) {
print STDOUT "|$1\n";
}
}
</pre>

[[Image:Live-graph-datafile-settings.png‎|thumb|Setting the Logfile input]]
[[Image:Livegraph-graph-settings.png‎|thumb|Setting the visuals]]
[[Image:Livegraph-dataseries-settings.png‎|thumb|Finetuning the visuals]]
[[Image:Livegraph-plot.png‎|thumb|Livegraph plotted data]]

The first 4 lines prepare a kind of "header" in the Logfile so that the Grapher can use it. In the while-part I added the pipe sign as separator so that Live-Graph can use the output. Copy and paste these lines into your favorite ASCII text editor and save it to your FG directory (e.g. save as "fgfsparser.pl"). Next you need to install a Perl Interpreter (e.g. [http://www.activestate.com/activeperl Activestate's Active Perl]). Now start Flightgear the following way:
<pre>
path-to-fgfs-binary\fgfs.exe | perl fgfsparser.pl > my_file 2&1
</pre>
Feel free to prepare %fg-root%\preferences.xml to your desired needs if you plan to start at another location (instead of KSFO) or with another plane (instead of Cessna 172p) or if you want to change other options. As an alternative use the command line options to modify the start-up to your desired needs.

The following part describes the visualization of the debug output with [http://www.live-graph.org Live Graph]. Live-Graph is a GPL'd Graph Plotter for Windows systems available at Sourceforge.org.

After installing it start Live-Graph and set the Data file to your output logfile (e.g. "my_file"). Be aware that you don't have an output file before you did not start the process of debug output at least one time. In this case start Flight Gear first and activate the AP function on the autopilot where you activated the debug=true output. Back to Live-Graph: The update frequency works fine with updates at 1 Hz or 2 Hz (every 1 or 2 seconds). Activate "Show tail data" so that your graph will not be overcrowding during the time and keep caching data active or you will experience loss of data which will make your tests useless.

Next you need to define the visual output: set the viewport on the Y-axis from min. -1.5 to max. +1.5. Leaving the scaling to "auto" will create a graph which will not be very easy to read. X-axis set to auto on both sides. It's quite handy to set the horizontal grid (I prefer a grid size of 0.2 to 0.5). And last but not least on X-Axis set "Dataset numbers" as type for the input.

In the Data series window you can switch the single values on and off and define the way how the program should plot the data. Here in the image I acquire the data of a simple wing leveler and therefor I normalize all data to values between 0 and 1. Be aware that my settings are not mandatory. Be creative and play around with different settings until you feel satisfied with the plotted data.
With "debug" in your AP.xml set to "true" you will now get the logfile filled and step by step the data will be visualized in Live-Graph. Now it's time to preset the autopilot to an initial value and to start the testing.

== Alternative Method ==
As an alternative to using the controller's debug output you can use the built in logging system of Flight Gear. This can be configured through the preferences.xml file, or at runtime via the File->Logging menu option.

To tune a controller you would typically display the setpoint property and the controlled property in the same graph. Another property that is interesting too look at is the actuating property, which can be for example the aileron control or the elevator control.
[[Category:Resource]]

Autopilot PID controller tuning resources

2009-12-07T01:19:37Z

Tcbetka: Fixed numerours spelling errors

The [[FlightGear]] [[Autopilot]] is a modular system based on PID controllers. Here are some tips to help tuning such a controller. There is lot of documentation all over the Internet about how to tune the parameters, having this you will have to figure out how the Flightgear PID controller implementation works.

First of all, have a look at the code where you will see the algorithm which is used for our autopilot. Checking existing autopilot configurations in Flightgear aircraft will also help.

There is actually a doc about filters in Flightgear documentation. Filters can be applied on input or ouput values, in other words, before and after the PID controller (execution).

=== FlightGear PID Controller ===
Knowing the algorithm is mandatory, certain values are forbidden, for example they can lead to a division by zero. Then you will have to understand where the parameters apply to act on the chosen correction module. See the schema which is a good reminder while testing.

[[Image:pid_controler.png|thumb|PID parameter's application]]
[[Image:pid_cotroler_data_graph.png|thumb|Datas of an Auto-trim PID Controller displayed as graphs]]

You can find good explanations on how to practically tune the controller. [http://en.wikipedia.org/wiki/PID_controller Wikipedia's article on the PID Controller]

=== Getting graphs of Controller action (Linux) ===
While it's possible to tune a PID controller by testing directly the aircraft behaviour under the autopilot control, it can be really useful to get everything in graphical view.

First of all you'll have to turn the PID Controller's debug mode on. That is in the autopilot.xml you are working on. (I didn't try to turn on more than one PID controller's debugging support at the same time).

Then you will get 6 new values displayed on the console at each FG loop. You will need to catch them and format the values in one line. Here is an example of a parser script written in Perl:

<pre>
#!/usr/bin/perl -w
# prints: "input reference P I D output"

while (<STDIN>) {
if ($_ =~ /input\s=\s(-*\d+.*)\sref\s=\s(-*\d+.*)/) {
print STDOUT "$1 $2 ";
} elsif ($_ =~ /P:(-*\d+.*)\sI:(-*\d+.*)\sD:(-*\d+.*)/) {
print STDOUT "$1 $2 $3";
} elsif ($_ =~ /output\s=\s(.*)/) {
print STDOUT " $1\n";
}
}
</pre>

Then you can write them in a file...

<pre>
alexis@linear:~/fgfs$ /usr/local/bin/fgfs 2>&1 | ./PIDcontroller_parser.pl > my_file
</pre>

If you use Linux, You can run Kst simultaneously to read the datas on the fly and watch them displayed together in real time while testing the aircraft.

* [http://kst.kde.org/ Kst, real-time large-dataset viewing and plotting tool]

=== Getting graphs of Controller action (Windows) ===

Under Windows the script of the Linux chapter works (with some minor modifications) together with Live-Graph under Windows, too. Although the output to a logfile is not as fluently as you may experience it under Linux. To get an output you first need a slightly modified version of the above mentioned Perl script:
<pre>
if (<STDIN>) {
print STDOUT "##|##\n";
print STDOUT "Input|Ref|P|I|D|Output\n";
}
while (<STDIN>) {
if ($_ =~ /input\s=\s(-*\d+.*)\sref\s=\s(-*\d+.*)/) {
print STDOUT "$1|$2|";
} elsif ($_ =~ /P:(-*\d+.*)\sI:(-*\d+.*)\sD:(-*\d+.*)/) {
print STDOUT "$1|$2|$3";
} elsif ($_ =~ /output\s=\s(.*)/) {
print STDOUT "|$1\n";
}
}
</pre>

[[Image:Live-graph-datafile-settings.png‎|thumb|Setting the Logfile input]]
[[Image:Livegraph-graph-settings.png‎|thumb|Setting the visuals]]
[[Image:Livegraph-dataseries-settings.png‎|thumb|Finetuning the visuals]]
[[Image:Livegraph-plot.png‎|thumb|Livegraph plotted data]]

The first 4 lines prepare a kind of "header" in the Logfile so that the Grapher can use it. In the while-part I added the pipe sign as separator so that Live-Graph can use the output. Copy and paste these lines into your favorite ASCII text editor and save it to your FG directory (e.g. save as "fgfsparser.pl"). Next you need to install a Perl Interpreter (e.g. [http://www.activestate.com/activeperl Activestate's Active Perl]). Now start Flightgear the following way:
<pre>
path-to-fgfs-binary\fgfs.exe | perl fgfsparser.pl > my_file 2&1
</pre>
Feel free to prepare %fg-root%\preferences.xml to your desired needs if you plan to start at another location (instead of KSFO) or with another plane (instead of Cessna 172p) or if you want to change other options. As an alternative use the command line options to modify the start-up to your desired needs.

The following part describes the visualization of the debug output with [http://www.live-graph.org Live Graph]. Live-Graph is a GPL'd Graph Plotter for Windows systems available at Sourceforge.org.

After installing it start Live-Graph and set the Data file to your output logfile (e.g. "my_file"). Be aware that you don't have an output file before you did not start the process of debug output at least one time. In this case start Flight Gear first and activate the AP function on the autopilot where you activated the debug=true output. Back to Live-Graph: The update frequency works fine with updates at 1 Hz or 2 Hz (every 1 or 2 seconds). Activate "Show tail data" so that your graph will not be overcrowding during the time and keep caching data active or you will experience loss of data which will make your tests useless.

Next you need to define the visual output: set the viewport on the Y-axis from min. -1.5 to max. +1.5. Leaving the scaling to "auto" will create a graph which will not be very easy to read. X-axis set to auto on both sides. It's quite handy to set the horizontal grid (I prefer a grid size of 0.2 to 0.5). And last but not least on X-Axis set "Dataset numbers" as type for the input.

In the Data series window you can switch the single values on and off and define the way how the program should plot the data. Here in the image I acquire the data of a simple wing leveler and therefor I normalize all data to values between 0 and 1. Be aware that my settings are not mandatory. Be creative and play around with different settings until you feel satisfied with the plotted data.
With "debug" in your AP.xml set to "true" you will now get the logfile filled and step by step the data will be visualized in Live-Graph. Now it's time to preset the autopilot to an initial value and to start the testing.

== Alternative Method ==
As an alternative to using the controller's debug output you can use the built in logging system of Flight Gear. This can be configured through the preferences.xml file, or at runtime via the File->Logging menu option.

To tune a controller you would typically display the setpoint property and the controlled property in the same graph. Another property that is interesting too look at is the actuating property, which can be for example the aileron control or the elevator control.
[[Category:Resource]]

Howto:Multiplayer

2009-09-13T00:59:17Z

Tcbetka: /* Using the Windows launcher / fgrun */

With the '''Multiplayer''' function of [[FlightGear]] you are able to see other pilots and reversed. This makes it possible to fly in formation, [[Howto: Air-Air Refueling|connect to tankers]] controlled by real people or contact real [[ATC]]ers to ask for landing/takeoff clearence.

If you are interested in hosting your own Multiplayer server, you may want to check out [[Howto: Set up a multiplayer server]].

Multiplay may cause extreme [[Howto: Improve Framerates|framerate]] drops, during loading of a new aircraft. Especially heavy models will cause lag. Therefore it is suggested to fly in Europe or somewhere other than KSFO where there are fewer pilots flying around.

== Using the Windows launcher / fgrun ==
[[Image:Multiplayer.jpg|thumb|300px|Multiplayer options in [[FlightGear Wizard|FG Launcher]]]]
#Select your [[aircraft]] and starting airport as normal in [[FlightGear Launch Control|Fgrun]].
#On the next screen, tick the "Multiplayer" box. Also tick the "AI models" box or you will not be able to see the other pilots' aircraft. Enter the callsign of your choice, enter mpserver01.flightgear.org in the "Hostname" box and 5000 into both the "in" and "out" boxes.
#Click run and you'll soon be flying with other pilots!

To confirm that it's working, you can go to the multiplayer map at; http://mpmap02.flightgear.org/ (in Hong Kong).
You will also notice chat messages that say "Hello" indicating pilots that are online and then as they join.
You may wish to use a different server (i.e. "Hostname" entry);

{| class="prettytable" border="1px solid" cellspacing="0" cellpadding="2"
!Server
!Location
![http://fgfs.i-net.hu/modules/fgtracker/ Tracked]
!Maintainer
!Comments
|-
|mpserver01.flightgear.org
|Germany
|Yes
|Oliver Schroeder
|
|-
|mpserver02.flightgear.org
|Hong Kong
|Yes
|Pigeond
|
|-
|mpserver03.flightgear.org
|Germany
|Yes
|
|Down for a long period of time
|-
|mpserver04.flightgear.org
|UK
|Yes
|Jon Stockill
|
|-
|mpserver05.flightgear.org
|Dallas, Texas, USA
|Yes
|Brant Gipson
|
|-
|mpserver06.flightgear.org
|Sweden
|Yes
|Anders Gidenstam
|Only tracked on port 5002
|-
|mpserver07.flightgear.org
|Wisconsin, USA
|Yes
|Tom Betka
|
|}

Use [http://pigeond.net/flightgear/mpstatus/ this] link to check if the MP servers are online.

For more advanced settings, the <tt>Advanced > Network</tt> tab can be opened. You are able to remove the in or out lines only through this method for example.

'''Please Note:''' The multiplayer servers are interconnected; you '''do not''' need to connect to a specific server in order to see other pilots who are on that server. For best performance, you should connect to the server that is geographically closest to you, has the lowest latency (ping time) or is the quietst.

== Using fgfs from the command line ==

First, for those who are very impatient and have a vague idea about what they're doing, the basic arguments to pass to fgfs for multiplayer are these;

--multiplay=out,10,server.ip.address,portnumber
--multiplay=in,10,your.ip.address,portnumber
--callsign=anything

Where portnumber is usually 5000 and your.ip.address is the ip address of the network interface being used by FG to connect to the server - even if that's a local 192.168 type address. Please note that although this limitation has been removed in the most recent versions of the FG server; you should still specify a valid (non-loopback, i.e. not 127.0.0.1) IP address to keep the FG client happy.

With the latest FlightGear (at least with OSG), you can also leave your.ip.address blank. FlightGear will then listen on all network interfaces:

--multiplay=in,10,,5000

=== Now, going more slowly for those who are completely lost... ===

Try the above first, and if it doesn't work, read on.

First of all, you need to know the IP address of the network interface you'll be using for multiplayer FG. If your Internet connection is via an ADSL modem that plugs directly into your computer with a USB connection, you should be able to find your IP address by visiting http://www.whatismyip.com . Please note that your ISP might not give you the same IP address each time - if MP stops working, check this first.

Otherwise, your connection is likely via some kind of router that connects to your computer via an RJ-45, or "Ethernet" connector (similar shape to most Western telephone plugs), or by a wireless link. You need to find the IP address of that network interface.

Under linux, this can be found by logging in as root and typing "ifconfig". You may find more than one interface listed, beginning with "lo" - ignore that one. You should have something like "eth0" or "wlan0" also listed - look through this block of text for "inet addr". This will be followed directly by the number you're looking for, e.g. "inet addr:192.168.0.150"

Under Windows XP, click start, run, and type "cmd". In the terminal window which appears, type "ipconfig" This should show you your IP address - write it down.

With Windows 98, click start, run, and type "winipcfg" to get information about your IP address.

This section _ought_ to be unnecessary now with recent versions of the FG server. If you have problems though, it won't hurt to follow through.

Now, all(!) that remains is to configure your router to forward UDP port 5000 to the IP address you've just found. This is not something that can be described in step-by-step detail, because each manufacturer's configuration interfaces differ greatly. Some tips are given here - if you get stuck, ask nicely on the [[FlightGear IRC channel]] for help (details on the flightgear website).

You should know how to log on to your router's configuration page, usually via a web browser. You are looking for settings pertaining to "port forwarding" "virtual server" "Forwarding Rules" or similar. When you have found the relevant settings, you need to add a rule that forwards port 5000 to the IP address you discovered earlier. If there is a choice given, ensure it is UDP ports that are forwarded. If there is no choice, you may assume that both TCP and UDP are being forwarded. Save your configuration, and most routers will probably then need to be rebooted to apply the changes.

Note: (for BSD users) If you are using a ADSL modem, you might have to put the port forward command into the ppp.conf file rather than firewall. This is because the firewall script will only run each time the machine is booted rather than the ppp line coming back online.

Finally, start FG using the command line given right at the start (if you're using the windows launcher you will find entry boxes for Multiplayer arguments - insert the relevant details there). You will end up with something like this;

fgfs --callsign=MyName --multiplay=in,10,192.168.0.2,5000 --multiplay=out,10,mpserver02.flightgear.org,5000 --airport=KSFO --runway=28R --aircraft=hunter

Choose your own callsign - this is currently limited to seven characters. 

Once you have started FG, you should, if others are flying, see messages in the terminal from which FG was started, similar to the following;

Initialising john51a using 'Aircraft/ufo/Models/ufo.xml'
FGMultiplayRxMgr::ProcessRxData - Add new player. IP: 10.0.0.36,
Call: john51a,model: Aircraft/ufo/Models/ufo.xml

You MUST give your local, behind-the-router IP address for MultiPlayer to work. Trust me on this one!

You should check that your firewall is not causing problems - either turn it off _temporarily_ or add an exception to allow incoming connections on port 5000.

If it's still just not working for you, ask nicely on the [[FlightGear IRC channel]] and someone should be able to assist.

[[Image:MP_Server.jpg|thumb|300px|[[MPMap]] screenshot]]

===Multiplayer Map===
{{Main article|MPMap}}

There is a very nice online map which displays the location of online pilots at http://mpmap02.flightgear.org . You will also find this useful to check that you are successfully connecting to the server.

== Multiplayer Chat ==
{{Main article|Chat Menu}}

To chat with other pilots, go to the "View" menu and select "Chat" at the bottom of the menu. Note that the other pilots may not have their chat box open, so they may not see your messages.
NOTE: Multiplayer chat is not supported by FlightGear 0.9.10 or older.

The shortcut for chatting is "_" (underscore) and it brings up a small window where you can type. By default, other people's messages are displayed at the top of Flightgear's window for a few seconds, but it will appear for a much longer time in the window at View -> Chat. So if you think you've missed anything, go check there.

==Related content==
* [[Howto: Set up a multiplayer server]]
* [[FlightGear Multiplayer Server]]

[[Category:Howto|Multiplayer]]