RE: [Flightgear-devel] ACScript RFC (or FGScript ??)
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 aThis probably doesn't fit your requirements exactly, but for an example you might want to take a look at the following documents:FGScript class reference:http://jsbsim.sourceforge.net/JSBSim/index.htmlExample script:http://cvs.sourceforge.net/viewcvs.py/jsbsim/JSBSim/scripts/c1722.xml?rev=1.14view=markup"Automatic Flight in JSBSim" (PDF)http://jsbsim.sourceforge.net/AutomaticFlightInJSBSim.pdfJSBSim - a FlightGear FDM - apart from driving FlightGear, can also be run by itself in a standalone application in a sort of batch run mode. This is useful for testing and development. To *really* get some good functionality out of standalone JSBSim required us to develop a scripting capability as well as inherent autopilot functionality. As I have mentioned before, JSBSim + script + autopilot =~ GNC, where the scripting provides "G"uidance, the FDM provides "N"avigation, and the FCS/Autopilot provides "C"ontrol. To see what an autopilot definition file could look like, see the simple wing leveler put together completely in a configuration file using JSBSim flight control building blocks (components): http://cvs.sourceforge.net/viewcvs.py/jsbsim/JSBSim/control/c172ap.xml?rev=1.8view=markup I hope these give you someideas that will be helpful. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 5:18 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) 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 The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend -- there is a uhaul in front of my apartment stacked to the ceiling with stuff and we still got loading yet to do today :) Is there anything in the airport datasets that tells where the ends of the runways are ?? and perhaps where the taxiways leading up to the runway are so I can have the server stack up planes waiting for takeoff when they connect to the server ?? Putting me off is not possible :) I think I got this AI engine idea wired at the engine level -- and there is no reason that at the lowest level, the scripting language can't directly maniplulate the elevators/ailerons/rudder/flaps/etc just like the kb/stick controls do. Just means a larger core library of procedures needs to be created -- doesnt matter to me if those procedures are hard-coded (a.k.a autopilot c++ code) or scripted (directly drive the fdm like the kb/stick controls) -- just need to decide which one is the best for the initial implementation :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ACScript RFC (or FGScript ??)
The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend Good move. :-) ;-) Where in Texas? Jon (Houston) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 8:13 AM John Barrett wrote: The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend -- there is a uhaul in front of my apartment stacked to the ceiling with stuff and we still got loading yet to do today :) I'm looking forward to flying on it :-) Is there anything in the airport datasets that tells where the ends of the runways are ?? No, only the origin (unless I'm mistaken), but you can see how I get the ends in void FGAILocalTraffic::GetRwyDetails() in AILocalTraffic.cxx. and perhaps where the taxiways leading up to the runway are so I can have the server stack up planes waiting for takeoff when they connect to the server ?? Not yet (except for KEMT and that format is going to get replaced). Bernie Bright and myself are both working on AFCAD-like taxiway/facilities editors, and once we agree on an acceptable file format, put loading support into the AI/ATC code, and write a tutorial on how to do it, logical taxiway support should grow. I've decided to go ahead and add GA AI traffic flying VFR at and/or between all the tower controlled airports before that though by simply starting them roughly where a hold short might be next to the threshold end of the runway, and finishing them by simply disappearing after turning off the runway. I've found that the following gives a roughly acceptable initial position waiting for the runway: orthopos = Point3D((rwy.width / 2.0 + 10.0) * -1.0, 0.0, 0.0); // TODO - set the x pos to be +ve if a RH parallel rwy. pos = ortho.ConvertFromLocal(orthopos); pos.setelev(aptElev); hdg = rwy.hdg + 90.0; // TODO - reset the heading if RH rwy. (Not in CVS yet). ortho is an instance of the ATC runway aligned simple x-y projection found in ATCProjection.[ch]xx. However, for user operated traffic, the chance of not being placed on a rendered taxiway might be more unacceptable than for AI traffic. The interface to the taxiway stuff when added will be through FGGround (as it is now for the KEMT hardwired taxiways). At the moment the return values are nodes and arcs, and thus the AI traffic must have some knowledge of the internal structure to navigate it. It could easily be modified to supply you with just a lat/lon location and heading of 1st, 2nd, 3rd etc hold position, subject to the mentioned proviso that at the moment we don't have any definition files or load an agreed format (yet). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Jon Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 8:33 AM Subject: RE: [Flightgear-devel] ACScript RFC (or FGScript ??) The only reason I'm not done with the fly together code is I'm packing to move from Kentucky to Texas this weekend Good move. :-) ;-) Where in Texas? Jon (Houston) Plano -- just north of dallas :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 11:48 PM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
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.
My generalized AI airplanes were originally going to be defined in
preferences.xml (like the ai-tanker), something like this for each
instance
desired:
ai-plane
typeprop-transport/type
modelAircraft/DC6/Models/DC6-model.xml/model
start-time2.00/start-time
scriptScripts/ai_script01.xml/script
/ai-plane
The above would instantiate the plane (or truck, boat), assign it a visual
model, indicate how many minutes into the sim session it should appear,
and
indicate the path to this object's script. The script would look like:
script
entry
on
typeelapsed-time/type
value0.50/value
/on
lat35.35628/lat
lon125.573899/lon
elev369.5/elev
heading350.0/heading
/entry
entry
on
typemessage/type
valuetakeoff-you-hoser/value
/on
task
typetakeoff/type
altitude5000.0/altitude
/task
/entry
... and so forth.
The waypoints could be triggered by elapsed time, UTC time, reaching a
waypoint, or message. The details of the takeoff would be handled by the
FDM, knowing what speeds and climb rate are suitable for a
prop-transport.
Dave
--
David Culp
davidculp2[at]comcast.net
Ok -- all you have done is state that takeoff is a procedure to be followed
without defining the procedure (i.e. its hard coded and there is no
variation from that procedure)
procedure takeoff(heading, target_altitude) {
ground=altitude;
throttle=90;
brakes=off;
flaps=15;
on (speed = 140) {
elevators = 20; // pull back on the stick
}
on (alititude ground+50) {
gear=up; // if the plane has retractable gear
}
on (alititude ground+100) {
turnto(heading); // nested procedure, does its actions and
events
// note -- that events are stacked -- any events defined here
are
// still active unless overridden by the nested procedure. When
the
// nested procedure completes, overridden events take effect
again
// also note that since this is in an event check, it gets
checked every
// update loop to maintain the heading
}
on (climbrate 100) {
elevators--;
}
on (climbrate 100) {
elevators++;
}
on (altitude == target_altitude) {
levelplane(target_altitude); // yet another scritped procedure
return;
}
}
}
I'm sure there are further refinements that could be made, but you get the
general idea :)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes:
on (climbrate 100) {
elevators--;
}
on (climbrate 100) {
elevators++;
}
Look out below (and above) which ever comes first! :-)
Curt.
--
Curtis Olson HumanFIRST Program FlightGear Project
Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org
Minnesota http://www.flightgear.org/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message -
From: John Barrett [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 8:45 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
on (speed = 140) {
elevators = 20; // pull back on the stick
}
should have been:
on (speed == 140 altitude=ground) {
elevators = 20; // pull back on the stick
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 8:15 AM Curtis L. Olson wrote:
John Barrett writes:
on (climbrate 100) {
elevators--;
}
on (climbrate 100) {
elevators++;
}
Look out below (and above) which ever comes first! :-)
I used to try flying the Navion like that when I first downloaded FG. I
never ever cleared that ridge after takeoff from P20 until I forced myself
to start pushing the stick down when I wasn't climbing enough. Must check
and see if the Navion still works sometime - I've always thought it would
be nice to do a 3D model and a panel for it sometime as a tribute to where
we've come from. Probably never get round to it though...
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:24 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) Ok -- all you have done is state that takeoff is a procedure to be followed without defining the procedure (i.e. its hard coded and there is no variation from that procedure) Actually, I don't see a need for the AI airplanes to have brakes, elevators, flaps and such. Our visions of AI traffic are much different. Dave -- David Culp davidculp2[at]comcast.net Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. Equally, the script engine output could be taken at a level where there is no FDM to control, for instance the AIPlane class, simply by defining hard coded procedures for that specific interface that override the low level FDM interface, and registering them with the script engine before starting a script. (thats getting complicated, but its much more possible if I know up front that I need to handle multiple aircraft interfaces) Hmmm -- that actually answers the problem I was trying to solve -- the class that interfaces the script engine to a specific aircraft class must define what low level is for the engine by registering the appropriate procedures to control the aircraft, the FDM interface would register routines to control elevators/ailerons/rudder/etc. The AIPlane interface would register turnto(heading) and other more abstract procedures, incidentally cutting out all the lower level scripting designed to control a plane via FDM. Therefore low level control procedures need to be defined in layers so that implementors can pick where to hook in, and have a well defined list of procedures that must be implemented to hook in at that level. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes: Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. I'm jumping into the middle of this conversation, but let me make a few comments. I envision a model where a single client computer will be responsible only for the location of it's single interactive aircraft. It sends it's the information about it's single aircraft to the server. From a multi-player standpoint. Any additional AI aircraft to be seeded into the world, should be handled by the server. The server will create and delete them, the server will fly them, script them, etc. etc. This way, an instance of FlightGear needs to send the position of the aircraft it is responsible for to the server, and then it will receive the positions of any other aircraft (AI or human controlled) in the vicinity. I think step #1 should be to get the client/server stuff working without worrying about any AI aircraft at all. Let's get the communication going so people can fly together. Once that is fleshed out, we can worry about seeding additional AI aircraft into the world to make things more interesting. At that point we can decide how to fly them, script them, animate them, etc. But I think most of that should be handled on the server side. A single instance of flightgear would get the same information on other aircraft regardless of whether they are human or AI controlled. I think this should be kept separate from any system where FlightGear populates it's own world with AI aircraft. I think that should get completely turned off when the multiplayer stuff is activated. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett wrote: - Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 9:24 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) [Dave's message] -- [- Dave's Signature] David Culp davidculp2[at]comcast.net [John's message] John, your email is malformed. :) You include the original text inline, rather than quoted (prefixed by some combination of and whitespace). It looks like you are clicking forward rather than reply to compose your mail. This might seem like a meaningless nit, but it actually causes problems. In this case, the line containing -- above is interpreted by my mail reader (Mozilla) as the beginning of a signature, which get colorized differently than the rest of the mail. There is nothing to tell the reader where the .sig ends and where your message begins, so your message ends up a dull, hard-to-read gray. Even worse, Mozilla helpfully *removes* the signature (and therefore all of your text!) when it quotes the mail into an editor buffer for a reply. Believe it or not, this stuff is actually specified in various RFCs. Microsoft has a horrific record of compliance with those standards, of course, but nonetheless I *have* seen correctly formatted quotes emerge from Outlook Express users. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
David Culp [EMAIL PROTECTED] said: Ok -- all you have done is state that takeoff is a procedure to be followed without defining the procedure (i.e. its hard coded and there is no variation from that procedure) Actually, I don't see a need for the AI airplanes to have brakes, elevators, flaps and such. Our visions of AI traffic are much different. Agreed. It isn't practical with standard hardware to run a full fdm/ap for each AI instance. There needs to be a very rudementary fdm for AI aircraft. No fancy atittude and control stuff. Ground traffic is potentially very complex but in air behavior should be fairly easy. Fly! used to run their AIs for approaches and basically just do a series of touch and gos. This would be easy enough to accomplish by adapting the ils/gs and ap code. But the commands for adjustments should just involve direct changes to attitude and speed (smoothed in a linear fashion), rather than translating control inputs into aerodynamic responses. Otherwise we'll all need a cluster of 3ghz pc's just to run this thing. It certainly would be the only way to mix AI traffic with live pilots when one participant is running in a non-dedicated peer host server mode (which is, IMHO, a worthy goal). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:15 AM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: Very different indeed -- I'm trying to model the pilots deciscion processes and interactions at a general level sufficient to write procedures to do ANYTHING that can be done with a plane. Directly controlling an aircraft via FDM just insures that the generic procedures dont exceed the performance capabilities of a specific plane, and can be tailored to specific aircraft when needed by overriding library procedures with aircraft specific procedures. I'm jumping into the middle of this conversation, but let me make a few comments. I envision a model where a single client computer will be responsible only for the location of it's single interactive aircraft. It sends it's the information about it's single aircraft to the server. From a multi-player standpoint. Any additional AI aircraft to be seeded into the world, should be handled by the server. The server will create and delete them, the server will fly them, script them, etc. etc. And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) This way, an instance of FlightGear needs to send the position of the aircraft it is responsible for to the server, and then it will receive the positions of any other aircraft (AI or human controlled) in the vicinity. I dont see the AIplanes being used on an FG instance running a user plane all that often, but it may happen if a user is running a small server for a simple scenario and a few friends I think step #1 should be to get the client/server stuff working without worrying about any AI aircraft at all. Let's get the communication going so people can fly together. I'm almost there except that I'm packing to move -- I just wanted to talk ahead so I would know where I was going next and make sure the protocol was up to handling the planned usage scenarios Once that is fleshed out, we can worry about seeding additional AI aircraft into the world to make things more interesting. At that point we can decide how to fly them, script them, animate them, etc. But I think most of that should be handled on the server side. A single instance of flightgear would get the same information on other aircraft regardless of whether they are human or AI controlled. I think this should be kept separate from any system where FlightGear populates it's own world with AI aircraft. I think that should get completely turned off when the multiplayer stuff is activated. I think it can all work together with minimal problems based on what I have gleaned from the code so far -- its a question of how the server scales up from a few buddies flying with no or few AI planes, up to 100s of flyers talking to a server managing 100s if not 1000s of human and AI driven aircraft. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 10:29 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett wrote:
- Original Message -
From: David Culp [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Thursday, November 13, 2003 9:24 AM
Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
[Dave's message]
--
[- Dave's Signature]
David Culp
davidculp2[at]comcast.net
[John's message]
John, your email is malformed. :)
You include the original text inline, rather than quoted (prefixed by
some combination of and whitespace). It looks like you are
clicking forward rather than reply to compose your mail. This
might seem like a meaningless nit, but it actually causes problems.
some of my messages get the indents, some dont -- I dont know why
In this case, the line containing -- above is interpreted by my mail
reader (Mozilla) as the beginning of a signature, which get colorized
differently than the rest of the mail. There is nothing to tell the
reader where the .sig ends and where your message begins, so your
message ends up a dull, hard-to-read gray. Even worse, Mozilla
helpfully *removes* the signature (and therefore all of your text!)
when it quotes the mail into an editor buffer for a reply.
My apologies. I've never had a mail reader that messed with the message
content in that way, nor heard of one that did before today
Believe it or not, this stuff is actually specified in various RFCs.
Microsoft has a horrific record of compliance with those standards, of
course, but nonetheless I *have* seen correctly formatted quotes
emerge from Outlook Express users. :)
Like this message did it right, but sometimes it doesnt and I dont know why.
Sometime I even insert the indents by hand (when I notice it)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- 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
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes: And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) Just asking questions here ... let's say that 10 people want to meet up and fly around a particular airport, and each of those 10 interactive sessions by default generates 10 AI aircraft each to make the skies interesting, things could get quite busy. It seems like you'd have to come up with some protocol to arbitrate who instantiates and controls which aircraft distributed accross all the different clients. That sounds like it could get really complex in order to do correctly with out any goof ups. I'm not saying it can't be done, just that it seems like this could quickly grown into an extremly complex system. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
Curtis L. Olson wrote: John Barrett writes: And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) Just asking questions here ... let's say that 10 people want to meet up and fly around a particular airport, and each of those 10 interactive sessions by default generates 10 AI aircraft each to make the skies interesting, things could get quite busy. It seems like you'd have to come up with some protocol to arbitrate who instantiates and controls which aircraft distributed accross all the different clients. That sounds like it could get really complex in order to do correctly with out any goof ups. I'm not saying it can't be done, just that it seems like this could quickly grown into an extremly complex system. I think he meant just one instance of FlightGear feeding the server with the AI traffic (just like it was a client, but in this case a very special one). This seems like a good approach because the AI generator could run on one, or several different machine(s). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 1:19 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: And I envision a client that handles multiple AI aircraft on behalf of a server thats plenty busy enuf handling message passing and other management functionality (this client really it could be considered part of the server, but so much of the code is the same compared to a client, there really isnt a reason not to leverage the existing client code and distribute the processing to other machines, and the same code will be in the server so if the requirements are light enough, the server could be instancing the planes) Just asking questions here ... let's say that 10 people want to meet up and fly around a particular airport, and each of those 10 interactive sessions by default generates 10 AI aircraft each to make the skies interesting, things could get quite busy. It seems like you'd have to come up with some protocol to arbitrate who instantiates and controls which aircraft distributed accross all the different clients. That sounds like it could get really complex in order to do correctly with out any goof ups. I'm not saying it can't be done, just that it seems like this could quickly grown into an extremly complex system. Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) The AI already in place is little used because it's tied to one airport and needs some generalizing. I'm looking forward to network flying, including network AI, but I hope development of local machine AI continues, and that it's not superceded by network AI. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: David Culp [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 2:12 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) The AI already in place is little used because it's tied to one airport and needs some generalizing. I'm looking forward to network flying, including network AI, but I hope development of local machine AI continues, and that it's not superceded by network AI. Thats why I'm approaching an AI/Scripting language the way I am. So it is useful for both net and local usage, and why I'm not so interested in doing a stand-alone server only implementation, but rather tying into the existing aircraft modeling system (wether that is the FDM or AIPlane model, or both most likely). There are far too many usage scenarios to sharply delimit what is client and what is server in my opinion. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 1:48 PM John Barrett wrote: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) Um, my plan was actually to have the sim spawn appropriate random aircraft as the user gets near, and to have each airport populated with statics which can randomly spawn into life. Is there anything wrong with this? Obviously the user should be able to switch this off, and it should be turned off automatically when the sim connects to a server. In the long run it should also be overridable if the user wants to drop in say a file of actual airline routes and times. (The GA stuff should still be random though). IMHO Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett wrote: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? David Luff wrote: Um, my plan was actually to have the sim spawn appropriate random aircraft as the user gets near, and to have each airport populated with statics which can randomly spawn into life. Is there anything wrong with this? Maybe a more productive way to argue about architecture would be to concentrate on the toolbox functionality you *both* are going to need. :) Clearly you both want the ability to tell the system to load up a 747-400 model, position it at this location/orientation/velocity, and update as needed. You both want the ability to enumerate the active AI aircraft in the system, set up an interpolative path for the aircraft, etc... It may be that this will be all the code you two share. A massively multiplayer server will most likely prefer to have a global set of flight plans rather than auto-generating aircraft near the (potentially very large) player set. The server's approach to the same problem (too many AI aircraft for the client to handle) is going to revolve around deciding which of the thousands of AI aircraft to update on which clients at what time. Likewise, it probably won't want auto-generated aircraft polluting the skies around players. So long as you two don't share code at the top level, and instead are simply using the same foundations, you won't care. By analogy: hand two kids a box of legos and they can both play happily. Hand them the same blocks in the form of a space cruiser and you have a fight. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 3:34 PM Subject: Re: [Flightgear-devel] ACScript RFC (or FGScript ??) John Barrett writes: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. These are the sorts of things you might want/need if you are not connected to a MMP server ... as I understand it, the current focus of everything in the src/ATC/ directory is a stand alone fictitious environment not connected to any MP server. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) I suppose we can divide the work up and draw the line any place we like. But my preference would be to control all the AI traffic in the server and not burden the core FlightGear code with it. Note that unless you are 100' away from an airplane, there is no way you are going to be able to tell if it's running real flight dynamics, or some ultra-simple non-physics based engine that just moves the airplane along some predetermined route. 99.% of the time in civilian aviation, you should never get that close to an airplane. Regards, Curt. I'll ask again -- why by default, why not under control of a loaded scenario which defines the planes and patterns -- then having ai planes is a question of did I load a scenario, even a generic one that states for any airport, when a plane gets close, spawn 3 planes doing touch-n-go circuits ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
Andy Ross writes: So long as you two don't share code at the top level, and instead are simply using the same foundations, you won't care. By analogy: hand two kids a box of legos and they can both play happily. Hand them the same blocks in the form of a space cruiser and you have a fight. :) My little brothers would always destroy my lego creations the instant I turned my back in order to build their own. Grrr ... :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
John Barrett writes: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? The server should be loading the scenario. Having an airport spawn aircraft just because someone is close by the airport should not be a default behavior of the simulator. These are the sorts of things you might want/need if you are not connected to a MMP server ... as I understand it, the current focus of everything in the src/ATC/ directory is a stand alone fictitious environment not connected to any MP server. Similarly, if a client is acting as a adjunct to a server, it will need a scenario loaded from the command line, or provided by the server to control its spawning and behavior of AI planes. Without a scenario loaded, or a connection to a server, its just you all by your lonesome (which I had thought was the situation given my experience loading up FG and flying around with the default settings) I suppose we can divide the work up and draw the line any place we like. But my preference would be to control all the AI traffic in the server and not burden the core FlightGear code with it. Note that unless you are 100' away from an airplane, there is no way you are going to be able to tell if it's running real flight dynamics, or some ultra-simple non-physics based engine that just moves the airplane along some predetermined route. 99.% of the time in civilian aviation, you should never get that close to an airplane. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 12:50 PM Andy Ross wrote: John Barrett wrote: Why is an interactive session by default generating AI aircraft without a loaded scenario to control those aircraft ?? David Luff wrote: Um, my plan was actually to have the sim spawn appropriate random aircraft as the user gets near, and to have each airport populated with statics which can randomly spawn into life. Is there anything wrong with this? Maybe a more productive way to argue about architecture would be to concentrate on the toolbox functionality you *both* are going to need. :) Nah, that's simply the most sensibly way. The most productive way is race you to get it finished ;-)) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
David Luff writes: Younger (still destructive) kid went to bed early the other night, so I got to play Lego (Duplo - the next size up bricks) with slightly older kid only. My wife seemed somewhat surprised to find a tower stretching from floor to ceiling when she got in, held in place at the top with blue-tack. Apparently this isn't normal behaviour... My 2 year old daughter got her second duplo set last Christmas (actually before she turned two.) Duplo's are great for towers because the larger block size let's you build big stuff much faster. We've made some wonderfully tall towers here, and my daughter loves to knock them down (usually in mid-construction.) Like you say, us adults have to wait until after bed-time before we can get a good shot at playing with our kids toys. I will assert that this is normal behavior, it's just mostly everyone else that is strange. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
On 11/13/03 at 2:53 PM Curtis L. Olson wrote: My little brothers would always destroy my lego creations the instant I turned my back in order to build their own. Grrr ... :-) Younger (still destructive) kid went to bed early the other night, so I got to play Lego (Duplo - the next size up bricks) with slightly older kid only. My wife seemed somewhat surprised to find a tower stretching from floor to ceiling when she got in, held in place at the top with blue-tack. Apparently this isn't normal behaviour... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- 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
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
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. My generalized AI airplanes were originally going to be defined in preferences.xml (like the ai-tanker), something like this for each instance desired: ai-plane typeprop-transport/type modelAircraft/DC6/Models/DC6-model.xml/model start-time2.00/start-time scriptScripts/ai_script01.xml/script /ai-plane The above would instantiate the plane (or truck, boat), assign it a visual model, indicate how many minutes into the sim session it should appear, and indicate the path to this object's script. The script would look like: script entry on typeelapsed-time/type value0.50/value /on lat35.35628/lat lon125.573899/lon elev369.5/elev heading350.0/heading /entry entry on typemessage/type valuetakeoff-you-hoser/value /on task typetakeoff/type altitude5000.0/altitude /task /entry ... and so forth. The waypoints could be triggered by elapsed time, UTC time, reaching a waypoint, or message. The details of the takeoff would be handled by the FDM, knowing what speeds and climb rate are suitable for a prop-transport. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
