----- 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
