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

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

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

<!-- postrobot seems to be done -->
== 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.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35487516/ 
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
 information in DNS instead of a web service </nowiki> 
  |author =  <nowiki> Torsten Dreyer </nowiki> 
  |date   =  Nov 12th, 2016 
  |added  =  Nov 12th, 2016 
  |script_version = 0.40 
  }}</ref>


it is absolutely agreed how char strings are encoded/transmitted is a vast waste... thus adding new 'types` is a needed possibility<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35487847/ 
  |title  =  <nowiki> Re: [Flightgear-devel] Proposal for storing the mp server
 information in DNS instead of a web service </nowiki> 
  |author =  <nowiki> Geoff McLane </nowiki> 
  |date   =  Nov 13th, 2016 
  |added  =  Nov 13th, 2016 
  |script_version = 0.40 
  }}</ref>


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.   <ref> {{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27298821/
     |title=<nowiki>Re: [Flightgear-devel] Replay system</nowiki>
     |author=<nowiki>ThorstenB</nowiki>
     |date=<nowiki>2011-04-02</nowiki>
}} </ref>

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.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28062569/
     |title=<nowiki>Re: [Flightgear-devel] flight recorder / replay system</nowiki>
     |author=<nowiki>Csaba Halász</nowiki>
     |date=<nowiki>2011-09-08</nowiki>
   }}
</ref>

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 [[Multiplayer protocol|XDR-encoding]] the corresponding properties.

The main thing that aircraft developers would still have to do is to create a corresponding "flightrecorder" configuration (see {{Readme file|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.<ref>{{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=270498#p270498
  | title  = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date   = Dec 29th, 2015
  | added   = Dec 29th, 2015
  | script_version = 0.25
  }}</ref>

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.<ref>{{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=270526#p270526
  | title  = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date   = Dec 29th, 2015
  | added   = Dec 29th, 2015
  | script_version = 0.25
  }}
</ref>

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).<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35487039/ 
  |title  =  <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
 Model for FlightGear AI Traffic </nowiki> 
  |author =  <nowiki> James Turner </nowiki> 
  |date   =  Nov 12th, 2016 
  |added  =  Nov 12th, 2016 
  |script_version = 0.40 
  }}</ref>

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

== External Links ==
* http://fgms.freeflightsim.org {{dead link|2019-05}}

== Footnotes ==
<references/>

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