FlightGear Multiplayer Server: Difference between revisions
m (→Future Plans and Development: +related discussions) |
|||
| Line 45: | Line 45: | ||
| script_version = 0.25 | | script_version = 0.25 | ||
}}</ref> | }}</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> | |||
== Related articles == | == Related articles == | ||
Revision as of 21:21, 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:
- 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)
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
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]
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.[3]
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.[4]
Related articles
External Links
Footnotes
- ↑ ThorstenB (2011-04-02). Re: [Flightgear-devel] Replay system.
- ↑ Csaba Halász (2011-09-08). Re: [Flightgear-devel] flight recorder / replay system.
- ↑ Hooray (Dec 29th, 2015). Re: Global Feature Suggestion for FlightGear: Cockpit Sharin.
- ↑ Hooray (Dec 29th, 2015). Re: Global Feature Suggestion for FlightGear: Cockpit Sharin.