Talk:Decoupling the AI traffic system: Difference between revisions
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]] | ||
* | * {{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.