----- 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
> > and interactions at a general level sufficient to write procedures to do
> > ANYTHING that can be done with a plane. Directly controlling an aircraft
> > FDM just insures that the generic procedures dont exceed the performance
> > capabilities of a specific plane, and can be tailored to specific
> > 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

> 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

Flightgear-devel mailing list

Reply via email to