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