----- 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
> 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
> 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

Reply via email to