> > One way to do this will be to define the deck(s) > > as a set of rectangles; I think two should do it, but maybe more. > > user aircraft gets close to the deck (using radar range and altitude) the > > AICarrier will start checking to see if the aircraft is within the area > > bounded by any of the rectangles. > > A seperate class should be made for the deck, call SolidObject. It should > be activiate by using XML. For example: > <solid>deck</solid> > This way, other portions on the aircraft carrier can be definied as solid > if one desires.
I've just made a seperate class for the carrier, called AICarrier, which is derived from AIShip. I expect the AICarrier will have a list of rectangles that represent decks. > It should also be the aircraft's responsibility to check whether this > SolidObject is within the aircraft's boundary. I don't see the point of having the FDM's know anything about carriers. The FDM already knows where the ground is. All we have to do is let the carrier override this value. The airplane thinks it's on the ground. > The aim is not to limit the use of this code on the carrier only. It is > best to be able to reuse the code on other areas. I don't think we're on the same page here. The deck is owned by the carrier. Unless the carrier exists the decks won't exist either. Unless you want to put decks elsewhere? Like in the movie "Sky Captain", with airborne carriers? You can give the AICarrier that shape and put it in the sky if you like. It won't know the difference. Dave -- **************************** David Culp [EMAIL PROTECTED] **************************** _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
