FlightGear Multiplayer Server

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

Types of server lists that can be configured in a server configuation:

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

Special callsigns:

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

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

Development

As of 07/2013, a bunch of folks are working on re-implementing fgms using the Go programming language, for details check out:

• http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40451.html
• https://github.com/fgx/go-fgms/blob/master/fgms/

Future Plans and Development

Our multiplayer protocol has a lot of room for being more "energy efficient" and we should be able to push more information around without increasing bandwith. Wx data does not change often and if AI information can be reduced to some waypoint information ("proceed direct FOBAR") it /might/ work. One thing can be said for sure. There will be a requirement updating the fgms installation at some point in the future. Improvements in the protocol are long overdue.

it is absolutely agreed how char strings are encoded/transmitted is a vast waste... thus adding new 'types` is a needed possibility

It should also be possible to join some of the multiplayer and replay code. The replay system could use the existing encoder of the multiplay manager to generate the data packets - but then record them locally instead of transmitting them via UDP. During replay, these packets could then also be decoded by existing multiplayer code. Might be worth a thought, if someone wanted to dig into this area.

ThorstenB's above idea would have been to drop the classic replay functionality, and instead use the MP subsystem to record both incoming and outgoing data (some extra properties would still need to be recorded, though, such as weather stuff). This would allow replay of MP happenings properly. Eventually we could also have offline rendering with custom camera paths and such goodies.

Note that AndersG implemented the whole Dual Control system in scripting space - it would be possible to support the whole thing in a "global" fashion with a handful of minor additions, mainly based on looking at related subsystems, e.g. the Instant Replay (flight recorder) feature - and hooking that up to the Multiplayer system by XDR-encoding the corresponding properties.

The main thing that aircraft developers would still have to do is to create a corresponding "flightrecorder" configuration (see $FG_ROOT/Docs/README.flightrecorder for their aircraft/cockpit to encode the transmission/update semantics accordingly. This could be handled by using XML attributes which are parsed by C++ code to automatically register the corresponding XDR helpers.

Any aircraft that 1) supports multiplayer and 2) supports the flight recorder/replay feature and 3) distributed setups (like those at FSWeekend/LinuxTag), could /in theory/ also support "Dual Control" - certainly once/if the underlying systems are merged. The building blocks to make something like this possible are already there - the difficult stuff is convincing aircraft developers (like yourself) to adopt the corresponding systems (multiplayer and the flight recorder). So the whole "global" thing would be possible to pull off, but it should not be done using Nasal and the existing MP system.

One approach would be to extend the MP protocol into an ‘AI’ protocol, and have the option to run all current AI types (carriers, tankers, scenarios, MP, traffic) via that protocol. With the same prediction in the client (current flightgear side) but nothing else really. Then we run the ‘server’ side which runs scenarios / traffic / carriers as a separate thread or process. Ideally we allow a given FG client to show ‘AI objects’ from multiple sources for testing. When you connect to an ‘MP’ server you’re really joining a consistent simulation environment, whether that be a local server, local thread or an Internet server. Oh, weather should also fit into this ideally, so again weather comes from ‘the world’, again that might simply mean a local thread commonly but as soon as you’re flying MP it should be more. This is quite achievable but we need to decouple some code from the local property tree, and have some way to configure the systems (eg current weather and scenarios GUIs).

Related articles

• Howto: Set up a multiplayer server
• MPmap
• Howto: Multiplayer

External Links

• http://fgms.freeflightsim.org ^{[dead link]}