FlightGear Multiplayer Server: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Remove quotes)
Line 13: Line 13:
(Reference: fgms-0.9.13/src/server/fg_server.cxx)
(Reference: fgms-0.9.13/src/server/fg_server.cxx)


{{cquote|You can reach all server admins with fgserver at postrobot dot de It's a pseudo mailing list and I try to keep the list of admins up to
<!-- postrobot seems to be done -->
date as good as I can.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40454.html|title=<nowiki>Re: [Flightgear-devel] New FlightGear Multiplayer Server</nowiki>|author=Oliver Schröder|date=Wed, 10 Jul 2013 13:53:55 -0700}}</ref>|Oliver Schröder}}
== Development ==


As of 07/2013, a bunch of folks are working on re-implementing fgms using the Go programming language, for details check out:
As of 07/2013, a bunch of folks are working on re-implementing fgms using the Go programming language, for details check out:
Line 20: Line 20:
* https://github.com/fgx/go-fgms/blob/master/fgms/
* https://github.com/fgx/go-fgms/blob/master/fgms/


== Development ==
== Future Plans and Development ==
{{FGCquote
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.
  |Thinking about it, it should also be possible to join some of the<br/>
   <ref> {{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27298821/
multiplayer and replay code. The replay system could use the existing<br/>
encoder of the multiplay manager to generate the data packets - but<br/>
then record them locally instead of transmitting them via UDP. During<br/>
replay, these packets could then also be decoded by existing<br/>
multiplayer code. Might be worth a thought, if someone wanted to dig<br/>
in this area.
   |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27298821/
     |title=<nowiki>Re: [Flightgear-devel] Replay system</nowiki>
     |title=<nowiki>Re: [Flightgear-devel] Replay system</nowiki>
     |author=<nowiki>ThorstenB</nowiki>
     |author=<nowiki>ThorstenB</nowiki>
     |date=<nowiki>2011-04-02</nowiki>
     |date=<nowiki>2011-04-02</nowiki>
  }}
}} </ref>
}}


{{FGCquote
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.
  |My idea would have been to drop the classic replay functionality, and<br/>
Eventually we could also have offline rendering with custom camera paths and such goodies.
instead use the MP subsystem to record both incoming and outgoing data<br/>
<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28062569/
(some extra properties would still need to be recorded, though, such<br/>
as weather stuff). This would allow replay of MP happenings properly.<br/>
Eventually we could also have offline rendering with custom camera<br/>
paths and such goodies.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28062569/
     |title=<nowiki>Re: [Flightgear-devel] flight recorder / replay system</nowiki>
     |title=<nowiki>Re: [Flightgear-devel] flight recorder / replay system</nowiki>
     |author=<nowiki>Csaba Halász</nowiki>
     |author=<nowiki>Csaba Halász</nowiki>
     |date=<nowiki>2011-09-08</nowiki>
     |date=<nowiki>2011-09-08</nowiki>
   }}
   }}
}}
</ref>
 
== Related articles ==
== Related articles ==
* [[Howto: Set up a multiplayer server]]
* [[Howto: Set up a multiplayer server]]
Line 58: Line 44:
* http://fgms.freeflightsim.org
* http://fgms.freeflightsim.org


== Footnotes ==
<references/>
<references/>


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

Revision as of 21:11, 23 March 2016

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:

Future Plans and Development

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.

 [1]

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

Related articles

External Links

Footnotes