Hooray wrote:https://sourceforge.net/p/flightgear/mailman/message/35486799/
Durk wrote:I've just added a little module called fgtraffic, which doesn't do anything
except print "Hello World". But, it's an important first step to get some
experience with cmake and helps me to organize my thoughts about how to set
up a modular AI system.
Just briefly, I suggest to check out F-JJTH's original FGAIS code:
http://wiki.flightgear.org/FGAISThat code can already "inject" arbitrary traffic into fgms using the MP protocol, using a tiny subset of the whole protocol.
In addition, if your intention is to maintain compatibility with existing data files, you will sooner or later realize that you will inevitably also need access to certain FG subsystems - IcecodeGL ended up implementing a SimGear based SGApplication framework for his FGRadar client:
http://wiki.flightgear.org/FGRadarThis whole thing works by setting up a single SGSubsystemMgr, so that you can directly reuse existing FG Subsystems (think properties, autopilot) without causing additional work.
Ultimately, this approach would mean that even things like tanker.nas or the Bombable addon (both of which are using your AI system) could be running in a standalone fashion if people really wanted to (in fact, SGApplication contains a stripped-down Nasal interpreter, too).
In the light of Mathias' and Stuart's ongoing HLA work, it would make sense to come up with an abstract base class/interface to encapsulate protocol specifics, i.e. something like "MPTransport" so that any new code does not contain hard-coded assumptions about the MP protocol being the only transport mechanism:
http://wiki.flightgear.org/High-Level_A ... ent_Status