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