FlightGear Multiplayer Server: Difference between revisions

m (→‎Future Plans and Development: +related discussions)
Line 21: Line 21:


== Future Plans and Development ==
== 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/
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>
     |title=<nowiki>Re: [Flightgear-devel] Replay system</nowiki>
Line 57: Line 79:
   }}
   }}
</ref>
</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 ==
== Related articles ==