RE: [Flightgear-devel] AI carrier
> I want to share a few impressions from my first landing on the nimitz. > The carrier still does not move, but the wires are working with a demo > implementation in JSBSim. > > Pics from the replay: > > http://na.uni-tuebingen.de/~frohlich/carrier/ > > :) Nice pics. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
Hi all, I want to share a few impressions from my first landing on the nimitz. The carrier still does not move, but the wires are working with a demo implementation in JSBSim. Pics from the replay: http://na.uni-tuebingen.de/~frohlich/carrier/ :) More will come soon! Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
Hi, Good progress so far. I managed to clean up that pure proof of concept to something more readable. On Freitag 29 Oktober 2004 02:34, David Culp wrote: > Thanks for your input. Forward your code to Erik. I will do so. But not before tuedsay or wednesday, I have to leave now ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Donnerstag 28 Oktober 2004 22:08, Andy Ross wrote: > Matthias Froelich wrote: > > This case kind of works for the arrester wires. The braking force is > > just hacked into the gear code. But this is just to be able to test. > > What would probably be a better idea (at least for YASim) would be to > model the braking force as a *distance* over which the aircraft will > be stopped. In the real world, they have to calibrate the wires for > the exact aircraft configuration that is going to be landing. > > You would figure out what constant acceleration would stop the > aircraft in the distance available, and simply apply that force "at" > the tailhook and "towards" the center of the arrestor wire. I am talking with Vivian Meazza about that topic. He has more or less own experiences with those wires. He knows much about them and how they are built. I think we will get something well suited. > The catshot is actually harder: in real life, the force is at the > bottom of the nosegear. But if you apply that to the dynamics model > the aircraft will want to tilt backwards as it accelerates. Real > aircraft don't do this because the nosegear is artificially compressed > and held that way during the shot. Maybe the easiest way to simulate > this would be to apply the force at the nose, or some other point > forward of the c.g. and above the gear. Yep this is problematic. I think one should apply the force like it is applied in a real aircraft. Take a fixed position of the nose gear strut about 30 cm above the ground level. Then apply the force at this position in direction of a point 50cm ahead of the nose gear on ground level. When this force is applied the nose gear is compressed and the aircraft accelerates. When the aircraft tries to raise it's nose the force will pull it back downwards ... > I'm honestly looking for something to get me back into FlightGear > development. I can do the YASim integration if you guys have an > interface ready for the "ground velocity" and "arrestor wire position" > values. Ok, great. May be you will get preliminary patches soon ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Thu, 28 Oct 2004 20:56:45 -0400, Ampere wrote in message <[EMAIL PROTECTED]>: > b) I don't have FlightGear installed, as I am still trying to get > direct rendering to work on my ATI 9200 in Linux. ;-) ..' lspci -vvv |grep -A 10 vga ' says? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
Can't. a) I'm not a programmer, so I will break things. b) I don't have FlightGear installed, as I am still trying to get direct rendering to work on my ATI 9200 in Linux. ;-) Ampere On October 28, 2004 08:34 pm, David Culp wrote: > Thanks for your input. Forward your code to Erik. > > > Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Thursday 28 October 2004 07:17 pm, Ampere K. Hardraade wrote: > Using that method, it is going to be a pain modelling deck with more > complex geometry. I can't imagine how much work it will take to create a > ski jump. > > It will be easier in the long run to define an object in a model file as > the solid deck. Thanks for your input. Forward your code to Erik. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
Using that method, it is going to be a pain modelling deck with more complex geometry. I can't imagine how much work it will take to create a ski jump. It will be easier in the long run to define an object in a model file as the solid deck. Ampere On October 28, 2004 09:36 am, David Culp wrote: > http://home.comcast.net/~davidculp2/decks.jpg ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] AI carrier
Andy Ross wrote: > Matthias Froelich wrote: > > This case kind of works for the arrester wires. The braking force is > > just hacked into the gear code. But this is just to be able to test. > > What would probably be a better idea (at least for YASim) would be to > model the braking force as a *distance* over which the aircraft will > be stopped. In the real world, they have to calibrate the wires for > the exact aircraft configuration that is going to be landing. That would seem to fit the bill nicely > You would figure out what constant acceleration would stop the > aircraft in the distance available, and simply apply that force "at" > the tailhook and "towards" the center of the arrestor wire. Near enough for me. > The catshot is actually harder: in real life, the force is at the > bottom of the nosegear. But if you apply that to the dynamics model > the aircraft will want to tilt backwards as it accelerates. Real > aircraft don't do this because the nosegear is artificially compressed > and held that way during the shot. Maybe the easiest way to simulate > this would be to apply the force at the nose, or some other point > forward of the c.g. and above the gear. I don't think that's quite right. The catapult tow arm is fitted about half way up the nosewheel leg, so the force is forward and down. We should be able to model that. UK carriers used strops attached to hooks on the fuselage. > I'm honestly looking for something to get me back into FlightGear > development. I can do the YASim integration if you guys have an > interface ready for the "ground velocity" and "arrestor wire position" > values. > Welcome back ... propellers? Had you forgotten? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
Matthias Froelich wrote: > This case kind of works for the arrester wires. The braking force is > just hacked into the gear code. But this is just to be able to test. What would probably be a better idea (at least for YASim) would be to model the braking force as a *distance* over which the aircraft will be stopped. In the real world, they have to calibrate the wires for the exact aircraft configuration that is going to be landing. You would figure out what constant acceleration would stop the aircraft in the distance available, and simply apply that force "at" the tailhook and "towards" the center of the arrestor wire. The catshot is actually harder: in real life, the force is at the bottom of the nosegear. But if you apply that to the dynamics model the aircraft will want to tilt backwards as it accelerates. Real aircraft don't do this because the nosegear is artificially compressed and held that way during the shot. Maybe the easiest way to simulate this would be to apply the force at the nose, or some other point forward of the c.g. and above the gear. I'm honestly looking for something to get me back into FlightGear development. I can do the YASim integration if you guys have an interface ready for the "ground velocity" and "arrestor wire position" values. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Donnerstag 28 Oktober 2004 18:36, Vivian Meazza wrote: > Mathias Froelich ahs done some work for areas on the ground, and if I > understand his code correctly (I'll send a copy to you) he uses triangles. > I would favour that solution anyway, because it is easy to divide the deck > into triangles which fit the area exactly, thus avoiding the situation of > the aircraft with at least one leg in mid air. That code I wrote is very hackish at the moment nothing more than a proof of concept. Also that stuff is not limited to triangles or rectangles. What it does is using leafs of the scenegraph to describe the deck/wires and most likely the cat too. In our current scenegraph library all rectangles are more or less triangulated by default. So what you can see in that code is some processing of triangles. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Donnerstag 28 Oktober 2004 15:36, David Culp wrote: > When the aircraft gets close (say 1 mile, <300 feet) the carrier will start > checking to see if the aircraft position is within any of the reactangles. > This will require a lot of coordinate transformation, and it would be good > to get the fastest algorithm possible. > > ***-> Any ideas here? <-*** Yes, the cache algorythm I described. Put those rectangles into the scenegraph, attache ssgUserData with longitudinal and rotational velocity to that leafs. Use a refinde ground model I hope to publish soon. And you are done. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Donnerstag 28 Oktober 2004 00:59, Ampere K. Hardraade wrote: > On October 27, 2004 04:18 pm, David Culp wrote: > > 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: > deck > This way, other portions on the aircraft carrier can be definied as solid > if one desires. > > It should also be the aircraft's responsibility to check whether this > SolidObject is within the aircraft's boundary. > > 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. Defining extra surfaces for carrier decks might be a good idea. But I think that these geometry should be put inside the scenegraph. The can be marked invisible either with using the ssgInvisible branch or by putting them into a seperate branch whitch is not used for renendering at all. On every update the carrier class needs to update their positions and their speed. The benefit of putting those surfaces into the scenegraph is that we can use intersection test routines we already need for ground reactions too. No need to implement things twice. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Mittwoch 27 Oktober 2004 22:18, David Culp wrote: > The current AI objects are not solid, so landing on the carrier is > impossible until we solidify the deck. 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. When the 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. If so the > current elevation will be overridden with a call to > globals->get_scenery()->set_cur_elev(deck_height). I haven't done this yet, > but I think it would be better than trying to manipulate the hit list. I guess that this is not sufficient. We need to know at least the speed of that patch. But even then, our current state where the physics depend on the framerate is not really a good thing. Let me elaborate: The physics of our FDM depend on the ground level below the aircraft. But the ground level is only computed every frame. So The ground level is more accurate with different frame rates. The bad effect of this could be seen if you try to start on a runway with a slope. You will see the aircraft moving below several ten centimeters below ground depending on the framerate, speed of the aircraft and slope of the runway. Just because the FDM takes the runway level at the location we had some time ago. If this is significat lower you will move below ground. That effect will be even worse if your deck will move. May be it will move at some day with rought sea. The FDM will see then groundlevels varying with more or less big steps. The smaller the framerate the bigger the steps. I am all more for physics which is invariant with respect to changes of the framerate. If we put the decks and wires into the scenegraph together with some information how they move with respect to the earth, we can compute the location of the deck at any time. To make the intersection teste less computional intensive I build up a small cache of the environment around the aircraft. The benefit is that we can request ground level and speed of the triangle below the hook/gear at any location. Carrier operation will be possible. Starting on a runway with a slope will work (The swiss glacier pilots might be thankfull :) ... We can even model the influence of different ground types (A B52 will not well taxi on grass...). We can make the beaver model work, since we know when we move on water. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Mittwoch 27 Oktober 2004 23:01, David Culp wrote: > > Yep. I guess this means that the "ground" position and velocity > > vectors will need to be passed in to the FDMs. I'd also recommend > > against passing in orientation and rotational velocity vectors at the > > moment - first do the steady level case. > > Yes, I'm a believer in getting something simple working first. In this > case, for a non-pitching, non-rolling carrier, we only need to send two > additional numbers (ground height is already sent from FG, so the FDM won't > know whether it's getting ground height and deck height, and won't care). > The numbers are something like deck_velocity_east and deck_velocity_north. > > The FDM can build a deck velocity vector from this, constraining > deck_velocity_down to 0.0 for now. I am currently working on that stuff together with Vivian Meazza. There is a proof of concept code available at the moment. I sent this privatly to him because of the mail size limit on this list. This case kind of works for the arrester wires. The braking force is just hacked into the gear code. But this is just to be able to test. At first I think we sould build up the environment in flightgear to make that work. Later implement the physics in more detail. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] AI carrier
David Culp wrote: > > > 3) Make the decks solid. > > 9) Make island solid > > Here's how I think we can solidify the decks and island. First we need to > define some rectangles (2? 3? a variable list?). > > http://home.comcast.net/~davidculp2/decks.jpg Mathias Froelich ahs done some work for areas on the ground, and if I understand his code correctly (I'll send a copy to you) he uses triangles. I would favour that solution anyway, because it is easy to divide the deck into triangles which fit the area exactly, thus avoiding the situation of the aircraft with at least one leg in mid air. http://myweb.tiscali.co.uk/vmeazza/FlightGear/deck.jpg We can get the co-ords quite easily, I think, relative to the model origin from the .ac file. > > Each rectangle is defined in the carrier config file, in carrier body > coordinates. > > x-offset > y-offset > angle > length > width > height We could do it in X,Y,Z world co-ords. That's an easy conversion from the co-ordinates of the carrier origin, and it deals with any vertical surfaces we might need. So: X1,Y1,Z1,X2,Y2,Z2,X3,Y3,Z3 . . . as many times as you need > When the aircraft gets close (say 1 mile, <300 feet) the carrier will > start > checking to see if the aircraft position is within any of the reactangles. > This will require a lot of coordinate transformation, and it would be good > to > get the fastest algorithm possible. > > ***-> Any ideas here? <-*** How about doing it from the aircraft perspective? That's done already for scenery. > > After all rectangles are processed the highest height value is kept, and > this > is then used to override the scenery height using > globals->get_scenerey()->set_cur_elev(height). > > I think if we make the island's rectangle about 5 feet above deck height, > then > we'll get a crash if you fly into it. Come to think of it, we need a > better > crash response from the the sim. Maybe a "crash" dialog would suffice. If we do triangles this might be implicit > > Note that this is just the first phase in completing the deck. Once we > have > it solid then we can do catapult and wire placement, which will require > even > more coordinate transformations. > Mathias is already well down the road for arrester wires on the ground. The algorithm is roughly: Is there is a wire in the triangle? If yes, then test for the hook catching it (using one of plib's functions: sgIsectLinesegPlane), Which checks if a line (the wire) defined as (X1,Y1,Z1), (X2,Y2,Z2) intersects with a plane. In this case the plane is defined by the co-ords of the hook on the last and this iteration. If caught, then tell the FDM ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
> 3) Make the decks solid. > 9) Make island solid Here's how I think we can solidify the decks and island. First we need to define some rectangles (2? 3? a variable list?). http://home.comcast.net/~davidculp2/decks.jpg Each rectangle is defined in the carrier config file, in carrier body coordinates. x-offset y-offset angle length width height When the aircraft gets close (say 1 mile, <300 feet) the carrier will start checking to see if the aircraft position is within any of the reactangles. This will require a lot of coordinate transformation, and it would be good to get the fastest algorithm possible. ***-> Any ideas here? <-*** After all rectangles are processed the highest height value is kept, and this is then used to override the scenery height using globals->get_scenerey()->set_cur_elev(height). I think if we make the island's rectangle about 5 feet above deck height, then we'll get a crash if you fly into it. Come to think of it, we need a better crash response from the the sim. Maybe a "crash" dialog would suffice. Note that this is just the first phase in completing the deck. Once we have it solid then we can do catapult and wire placement, which will require even more coordinate transformations. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] AI carrier
> > project schedule: > > > > 1) Derive a new AICarrier class (me, just did it) > > 2) Refine the carrier visually (done, set to Erik for upload to cvs) > > 3) Make the decks solid. > > 4) Improve FDM gear reactions to accomodate moving "ground" (Mathias) > > 5) Improve FDM to include external forces (catapult, wire) (Mathias) > > 6) Improve carrier to include "meatball" (aka Projector Landing Sight) > > 7) Add pitching and rolling deck capability > > 8) Add wind and turbulence effects > > 9) Make island solid > > 10) Enhance carrier appearance. > I've completed a first cut at resurrecting USS Nimitz: http://myweb.tiscali.co.uk/vmeazza/FlightGear/USS_Nimitz.jpg I think it will do for the development of arrester wires. There are some things which need doing e.g. re-alignment of catapult tracks, but I thought could wait awhile. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] AI carrier
Mathias Froelich has also got some work underway, so we can add to the schedule > project schedule: > > 1) Derive a new AICarrier class (me, just did it) > 2) Refine the carrier visually (Vivian, doing it now) > 3) Make the decks solid. > 4) Improve FDM gear reactions to accomodate moving "ground" (Mathias) > 5) Improve FDM to include external forces (catapult, wire) (Mathias) > 6) Improve carrier to include "meatball" (aka Projector Landing Sight) > 7) Add pitching and rolling deck capability > 8) Add wind and turbulence effects > 9) Make island solid > 10) Enhance carrier appearance. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] AI carrier
Arnt Karlsen wrote: > > 7) Add pitching and rolling deck capability > > ..heave too. > Someone like to write a Ship Dynamic Model? :-) Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Wed, 27 Oct 2004 18:56:52 -0500, David wrote in message <[EMAIL PROTECTED]>: > 7) Add pitching and rolling deck capability ..heave too. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
Making the entire carrier solid? Regarding the CAT-aircraft attachment: I am hoping that the attachment point on the aircraft will also allow tugs to tow aircrafts around. Ampere On October 27, 2004 07:56 pm, David Culp wrote: > 9) ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
> Don't forget apparent wind speed and direction discontinuites > between on deck and in air ! Actually I *do* plan on forgetting that, for now ;) That's the kind of thing that can be added in later phases. Here's what I think would be a good project schedule: 1) Derive a new AICarrier class (me, just did it) 2) Refine the carrier visually (Vivian, doing it now) 3) Make the decks solid. 4) Improve FDM gear reactions to accomodate moving "ground" 5) Improve FDM to include external forces (catapult, wire) 6) Improve carrier to include "meatball" 7) Add pitching and rolling deck capability 8) Add wind and turbulence effects 9) ? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] AI carrier
David Culp writes: > > 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. Don't forget apparent wind speed and direction discontinuites between on deck and in air ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
I am thinking of something more generic than Carrier. Ampere On October 27, 2004 07:13 pm, David Culp wrote: > 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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
> > 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: > deck > 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
Re: [Flightgear-devel] AI carrier
On October 27, 2004 04:18 pm, David Culp wrote: > 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: deck This way, other portions on the aircraft carrier can be definied as solid if one desires. It should also be the aircraft's responsibility to check whether this SolidObject is within the aircraft's boundary. 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. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
> Yep. I guess this means that the "ground" position and velocity > vectors will need to be passed in to the FDMs. I'd also recommend > against passing in orientation and rotational velocity vectors at the > moment - first do the steady level case. Yes, I'm a believer in getting something simple working first. In this case, for a non-pitching, non-rolling carrier, we only need to send two additional numbers (ground height is already sent from FG, so the FDM won't know whether it's getting ground height and deck height, and won't care). The numbers are something like deck_velocity_east and deck_velocity_north. The FDM can build a deck velocity vector from this, constraining deck_velocity_down to 0.0 for now. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
On Wed, 27 Oct 2004 15:18:46 -0500 David Culp <[EMAIL PROTECTED]> wrote: Some notes on making an AI carrier. The FDM will have to be changed to allow the aircraft to sit on a deck without the deck sailing away from under it. The difference between the aircraft's and carrier's velocity vectors will be applied to the ground reactions to accelerate the aircraft. That's the first two steps anyway, AFAICT. Yep. I guess this means that the "ground" position and velocity vectors will need to be passed in to the FDMs. I'd also recommend against passing in orientation and rotational velocity vectors at the moment - first do the steady level case. Or ... I remember at one time that there was a suggestion to allow the Flightgear side to query for gear location, so the specific ground state could be given back to the FDM per-gear. Is that a correct recollection? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
