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
