2,561
edits
Decoupling the AI traffic system: Difference between revisions
Jump to navigation
Jump to search
m
→Goals
m (→Goals) |
m (→Goals) |
||
| Line 3: | Line 3: | ||
= Goals = | = Goals = | ||
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, 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. | 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, 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. | ||
= Partitioning Rationale = | |||
* "It'd be worth identifying which subsystems are the big time sinks (FDM? AItraffic?) to prioritise this." [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18063.html] | |||
* "I think the main targets for parallelization are the rendering pipeline and various "add-on" systems, like the traffic manager."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16400.html] | |||
* "[...]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] | |||
* "Instead of thinking of FG as a single threaded application, it needs to be a collection of standalone programs that run collaboratively - go back to thinking in terms of the external FDM option."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22936.html] | |||
* "I agree that the approach you suggest, of starting with a single subsystem/module is probably the best way to start tackling this issue."[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg09064.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]]. | |||
= Background Information = | = Background Information = | ||