Talk:Decoupling the AI traffic system: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(converted external links pointing on own wiki to internal links)
m (Switch to the {{forum url}} template for all forum links.)
Line 10: Line 10:
* [[Distributed_Interactive_Simulation]]
* [[Distributed_Interactive_Simulation]]
* [[Proposals:AI Traffic related]]
* [[Proposals:AI Traffic related]]
* http://flightgear.org/forums/viewtopic.php?f=5&t=6807&p=60580
* {{forum url|p=60580}}
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18295.html headless traffic injector]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18295.html headless traffic injector]

Revision as of 07:42, 11 June 2019

Further Notes

  • even in an "offline scenario", FlightGear could internally use a local/loopback multiplayer server (fgms) and run the AI traffic component in a separate thread or process to feed in traffic - this would be reliable and keep things very straightforward, because FlightGear could make the assumption that a running fgms instance is always available. Similarly, other global state could also be managed and propagated using such an internal fgms instance. This would simplify the design quite a bit.
  • basically, this is already possible without making any modifications to the FG MP protocol: simply by using a dedicated UDP connection for each AI traffic client, instead of directly writing to the FG property tree in order to spawn new AI traffic instances.
  • at some point, private (local) fgms instances could by default allow arbitrary AI traffic to be published, while standalone (public) fgms instances should probably be configurable to enable/disable AI traffic propagation from possibly untrusted clients.

Also see