----- Original Message ----- From: "Andy Ross" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Sent: Thursday, November 13, 2003 10:46 AM Subject: [Flightgear-devel] ACScript RFC (or FGScript ??)
> [Starting a new thread. John's reply was burried in the parent thread] > > John Barret wrote: > > 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. > > There is some support already in place for using Plib's "psl" language > in FlightGear; it's a sane minilanguage with C-like syntax and > semantics (basic types and functions, basically; no pointers, structs > or arrays). It talks to the rest of FlightGear through the property > tree. You will want to investigate this first; I haven't tried it > yet. I dont know if you caught the post where I gen'd up a simple procedure to give some idea of the action/event structure that I would like the language syntax to describe. Everything is basically off of FDM variables and simple commands to the plane. I would need to get much deeper into PSL to see if it could be used as the core of a scripting engine that could handle nested/stacked event handlers. The C like syntax is a definite plus, but I'm trying to hide the details of the event management logic from the AI designers. Let them concentrate on flying the plane and not worrying about how to implement state/event code. > > I'd caution against a special-purpose language; these things are > almost always just as hard to write as real languages are, and never > quite do as much as you hoped. I'd stick with a general purpose > language, whatever you do. I'd like all the basic features of C, but with the event extensions, A procedure should be nothing but a script that sets up the preconditions for the procedure and a set of event handlers that do the routine adjustments required until the termination event for the procedure occurs. Event handlers are sub-scripts that execute when certain conditions are met, and the conditions are tested every "update()" call to the engine. A procedure can use a nested procedure with its own setup and events that stack on top of the callers events. And lastly, when a nested procedure is called, the engine should check if there is already an instance of that procedure running, and if so, do nothing. (this can be determined by checking for any entries on the event stack that are tagged as belonging to the named procedure) > > And now the plug. :) I wrote a scripting language of my own at one > point (http://www.plausible.org/nasal) which is closer to Perl or > Javascript. It's semantically richer than PSL, supporting all the > stuff you expect like vectors, hashes/objects, garbage collection, > et. al. It's also quite small; a little over 100k of source code > these days. No work has been done to integrate it into > FlightGear/SimGear (I wrote it for my own game project last spring), > but I'd be happy to do so if there was interest. If I'm going to use some other scripting engine as a basis to reduce development time, I'm equally open to your language or PSL as the language core, so long as some way can be found to graft on the event handler model outlined above :) The only requirement I would have for using an existing script engine as a core would be the ability to map script variables to C++ variables. The interface class that ties the engine to a specific aircraft class would be responsible for setting up those mappings, as well as registering any hard-coded procedures specific to that aircraft interface. > > Languages are like religions though. Some people are going to hate > the idea, some people are going to like it except for one or two > things that *have* to be fixed first, some will want to use a > different language. No one seems to want to use PSL yet, though, so > it seems to me like the door is still open for alternatives. :) And thats exactly where I'm at -- C/PSL is nice, but there are these darn features that I dont feel that I can live without :) Based on my experience working with the TCL and JS engines in other projects, what I want should not be horribly difficult to graft on to an existing engine. All that is required is the addition of a few new statements (procedure, on(event), and endproc) and the low level code to handle what they do, and the creation of an "update_events()" method to process the event tree. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
