When it comes to the hard-coded AI/scenario system, there are a number of restrictions in place, even just when dealing with fixed-wing aircraft - flug mentioned a number of these on and off over the years in the context of his dog-fighting addon - Durk seemed generally supportive of addressing these eventually -however, more recently, he seems to have realized that a completely different approach is needed - which is summarized at:
http://wiki.flightgear.org/FGTrafficIn the meantime, a scripted (Nasal-based) approach is likely to provide the most bang for the buck - at least for the time being:
http://wiki.flightgear.org/Scripted_AI_ObjectsCurt even once implemented a whole piloting-scheme in Nasal space:
This would be based on the method used by tanker.nas, i.e Durk's AI system merely being used to instantiate the 3D model, with all the high-level logic residing in scripting space, possibly augmentioned through other C++ hooks (e.g. PID controllers). More recently, a number of core developers discussed the same approach on the devel list:
http://wiki.flightgear.org/FGTraffic#ScriptingThorsten recently summed up these restrictions:
Thorsten wrote: Right now what we can do is have property rules (or AP tags) prepared at startup time and (at least in JSBSim) we can switch the channel to active when we need it, but we can not dynamically instance property rule or AP computing chains.
Note that this would be fully in line with Torsten's original plans on providing a scripting-space enabled version of his property rules, so that these would not need to be fixed or pre-defined in a static fashion - which is a restriction that is also limiting other areas in FlightGear, where the same subsystem could be a great technology-enabler (e.g. most Canvas animations could be handled that way, which would allow us to get rid of tons of Nasal callbacks invoked via timers and listeners).
Torsten's original idea being this:
Subject: 2 Questions: vacuum & electricalTorsten wrote:I think, performance of Nasal code and XML based property rules is pretty close. The big advantage of the property rules is that they don't produce garbage that a garbage collector has to clean up. But as nothing in life comes for free (except FlightGear, of course) XML tends to be much more verbose - as you correctly stated.
[...]
I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind. This _might_ end up in something like
- Code: Select all
var myPid = pidController.new();
myPid.Td = 0.0001;
myPid.Ti = 123.4;
myPid.Kp = 0.2;
myPid.input = "/foo";
myPid.reference = "/bar";
myPid.output = "/baz";
etc, etc.
There's actually a long-standing list of ideas on reusing the autopilot/property rule system for such purposes:
http://wiki.flightgear.org/Nasal/CppBin ... erty_Rules