On 11/12/03 at 11:06 PM John Barrett wrote:
>Yes I would prefer an ac+fdm+autopilot solution strictly for realism
>purposes -- but anything that instances planes controled by FG needs to be
>hooked into my network code so that ac status updates can be made visible
>all other participants.

Not necessarily - the current AI could simply be turned off when in
multiplayer mode a la MSFS.

>AIPlane definitly meets some of my needs based on the descriptions and a
>quick peek at the code. The main area where AIPlane falls short IMO is the
>hard coded AI functionality -- so here we go:
>I would like to request your ideas and wishes for an aircraft AI scripting
>language sufficiently generic in scope to handle piloting any aircraft
>running on FG. I can see right off that it must be event driven, able to
>interupt its current procedure/task in response to external inputs, able
>process complicated nested procedures with completion of a "statement"
>on the current aircraft state or external inputs such as radio message or
>radar. It must span every level of interaction from "turn the plane to a
>specific heading" or "change altitude to a specified level" at the low
>up to extremely abstract commands like "fly the plane to to a specified
>airport and land" which would encompass all the procedures and
>neccessary to take off from one airport and land at another, including all
>standard interactions with ATC and other planes along the way.
>At the bottom end, the script module should generate commands suitable to
>feed to an autopilot, AIPlane or, if desirable, directly to the plane
>simulated (I havent looked at how kb/stick inputs interface to the
>simulation - do they feed into the fdm ??) -- this may end up requiring
>multiple "output" interfaces for the scripting engine.
>The reason I was looking at ac+fdm+ap is the autopilot provided
>out-of-the-box low level code to manuever the plane without the AI code
>needing to know the specifics of how to make the plane perform a given
>manuever. Adding low level capabilities to the autopilot would the expand
>the range of capabilities for the AI scripts. (think of the autopilot as
>hardcoded manuevers that form the core of the AI language -- anything more
>complicated than that would be handled by scripted AI procedures based on
>the core manuevers)
>Another thought just hit me -- the engine will have to handle the idea
>different planes may have different low level routines, for instance, how
>you setup and perform a takeoff is different for every plane, so a generic
>script in common use by many planes must use the low level routines for
>specific plane being controlled, wether or not that low level routine is
>hard coded or scripted (i.e. aircraft specific commands/procedures
>more generic code in any shared command/procedure library)
>Any other ideas and suggestions of what such an aircraft scripting/AI
>language/engine might need ??

Ugh!  Not ugh as in a terrible idea, but ugh as in terribly complicated and
makes my head hurt just thinking about it!

Personally I'd always start simple - just use the built in scripting
language (PSL) to put desired planes in a property tree

eg /AI/LocalTraffic/KRHV/Light-Single/N14687

and have the AI manager instantiate them if the user gets near, and the AI
system drive them,

or alternatively, just manipulate the position and orientation of the plane
directly, write it to a property, and have the AI manager or possibly the
model manager render it.

The AI code at the moment is very immature and changing quite quickly.  To
a certain extent, my primary motivation in producing it was to provide
input to the ATC system - I never really intended to get into the AI
modelling.  Interfacing with it scriptwise in the way you describe is
probably, erm, quite ambitious!  What I have found is that you can start
off with a nice code design and ideas in theory, but in practice things
rapidly get very complicated, tricky, and most of all ugly.  Any GA plane
flying VFR really has to be able to fly a traffic circuit at the end.
Flying a circuit AI is ugly!  What happens if you're following the user,
and the user is much further out than (s)he should be.  Cut inside him?
Follow her round far too wide?  If there's no gap in traffic that could put
the pattern wide for the duration of the session.  Approaching an airport
on a cross country, it's OK if you happen to come from the staight in
direction, or at 45 degrees to the downwind leg, but what about the other
directions.  There's loads of different possibilities for pattern entry
around, most of them quite tricky to fly AI, let along whilst trying to
avoid other traffic.  Currently it doesn't even try to avoid other traffic
in the air, only on the runway.  Just deciding where to fly is hard, before
the mechanics of flight are even considered.  In retrospect, it might have
been easier to start with AI airliners flying defined flightplans, but FG
is still very much a GA sim, so thats where I started.  At the moment there
is no clean separation of 'where to fly' and 'how to fly' in the AI code -
I intended to at first but things have got messy in there and separating it
out is not a high priority for me at the moment.  For instance,
FGAILocalTraffic often directly manipulates the speed, pitch, position etc
in the fly a circuit code, whereas it should just be commanding target
descent rates, turn rates, Vx or Vy climb, cruise at 100knots etc, and have
FGAIPlane actually fly it directly.  Once a separation like this is
acomplished, it would be much easier for a scripting language to interface
at a 'where to fly' level.

I not trying to put you off - I welcome all efforts in this area.  I'm a
believer in starting simple and getting some code out there though.
Personally, for a first iteration of a multiplayer server, I'd turn the ATC
and AI off in all the clients, and just get to the point where several of
us could connect to the server, fly together at one airport without
starting on top of each other, and possibly exchange messages.  Once we can
actually fly together on it, it'll seem much more tangible.

Good luck!

Cheers - Dave    

Flightgear-devel mailing list

Reply via email to