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
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
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
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 ...
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 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]
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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) ?
___
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
28 matches
Mail list logo
