Decoupling the AI traffic system: Difference between revisions

<references/>

Decouple the AI traffic system from FlightGear so that it may eventually become a standalone component to be run in a separate thread or process where all communications with the fgfs core process would be handled and dispatched through an IPC-enabled version of the property tree (see [[Remote Properties]]), which would ultimately not only help improve runtime performance (of FlightGear, as well as the AI system) but also provide a possibility to handle AI state synchronization across multiple FlightGear multiplayer clients by feeding in all AI traffic via the FlightGear multiplayer server, so that all connected clients would get to see identical AI traffic, that is properly synchronized.

}}

* "[...]I think a more flexible approach may be "self-contained" modules communicating by passing "properties" over TCP. The "remote" FDM is already a possibility and there is an example of a remote joystick but how easy would it be to break up the rest of flightgear?"[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09046.html]

For additional details regarding partioning FlightGear into distinct modules that may be run as standalone processes doing IPC via the property tree, please also see [[Modularizing, parallelizing and distributing FlightGear]].

* "If one of the computers taking part in the multiplayer network has generated a bunch of AI aircraft, will they all be propagated to the rest of the multiplayer members ? If so, you might be able to dodge the processor load of full aircraft simulations, by having two computers with one having the human and a graphics display and the other having all the AI and no graphics display. Just a thought. "[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08701.html]

* "Yes - you still need the "pilot" logic however it's done. It certainly won't be wasted."[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg08744.html]

* "the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario" [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18423.html]

* "Is there a way to create new instances of AIAircraft or another kind on the fly, just by adding some nodes in the property tree, or running a command from the telnet interface, that is, without modifying the source code ? Is there something planned in this direction ?"[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26021.html]

* "Curt and I have agreed that we need some sort of DCS (Distributed Content System) that synchronizes instances of dynamic models between multiple running versions of FlightGear. That way a multi display setup of FlightGear will work with ATC/AIModels/AI Traffic (and MultiPlayer) code enabled." [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26053.html]

* "Well I guess, a basic solution would be to have a master/slave mode for the AIModels subsystem, where the master computer does the "intelligent" AIModels work, and sends the resulting data across the network. The remaining computers, wouldn't have the AIModels system do anything, except process the incoming data." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00332.html]

* "Should not be necessary. All you do is to output the AI aircraft positions to all clients connected. The server itself fetches the data from the internet or whatever the source. No need to have a client for every AI plane."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13215.html]

* "This would also be a great way to help start factoring out the current AI Traffic code, so that it may run separately from flightgear, possibly even standalone directly on the machine hosting a server!" [http://sourceforge.net/tracker/index.php?func=detail&aid=1849308&group_id=161928&atid=821811]

* "What's even more important: having such a capability would mean that we automatically end up with a very convenient high level tool to EASILY stress-test multiplayer servers and the underlying multiplayer code!! Of course, this capability should be optional and configurable to ensure that not arbitrary "multi-aircraft clients" can connect to a server and bring it to a breakdown by inserting thousands of traffic nodes. But if there is a way for authenticated/trusted clients to employ such functionality, it would be really awesome."[http://sourceforge.net/tracker/index.php?func=detail&aid=1849308&group_id=161928&atid=821811]

* "It seems like it should be possible to setup a number of AI aircraft andthen have pretty tight control over their behavior via the property system." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15033.html]

* "In the future we could also consider to have one server handling all AI objects for the clients to have a coherent environment. Imagine that you are training landing on the Nimitz with your friends but the ship is at a different position on each client. This would be very weird. "[http://www.mail-archive.com/flightgear-devel@flightgear.org/msg34063.html]

* "But what about if the MP server, in addition to mpdummy, had a dummy player for Nimitz (and perhaps Foch and Eisenhower as well), with the purpose of holding a stationery position for MP carrier users to use in common when there is no MP carrier playing?"

* "This makes it more realistic because all AI objects will at last be in sync.. like all objects are in sync to humans in real life."

* "As you want to do it as an external application anyway, maybe the best way is to use the multiplayer protocol" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13211.html]

* "In a way you "fake" connected players on your customized server." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13215.html]