----- Original Message ----- 
From: "David Luff" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Wednesday, November 12, 2003 8:20 PM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......

> On 11/12/03 at 8:08 PM John Barrett wrote:
> >
> >Sounds good -- like most of what I'm looking for is there -- would
> >definitly
> >like to look over the code and see how much work to hook it into my
> network
> >setup
> >
> Sorry - I thought you were looking for an fdm-autopilot based solution,
> else I'd have mentioned this!
> It would actually be very useful for the AI logic development if Atlas
> could then work as a client and display all the traffic.  Could be the
> basis of the human ATC station as well, by adding altitude labels to the
> display in Atlas.
> Cheers - Dave

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 to
all other participants.

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 to
process complicated nested procedures with completion of a "statement" based
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 end,
up to extremely abstract commands like "fly the plane to to a specified
airport and land" which would encompass all the procedures and interactions
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 being
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 the
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 that
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 the
specific plane being controlled, wether or not that low level routine is
hard coded or scripted (i.e. aircraft specific commands/procedures override
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 ??

Flightgear-devel mailing list

Reply via email to