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

David Culp

Flightgear-devel mailing list

Reply via email to