Again, this is something that the JSBSim FCS components could handle - you
need building blocks.
Reading about the flight control system of the thrust vectoring fa-18 HARV in
http://techreports.larc.nasa.gov/ltrs/PDF/NASA-96-tm110216.pdf
and loooking at the released MATLAB code of a
Eric L Hathaway wrote:
Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with
the above configure script check for truncf (I haven't checked it out on
RedHat 9 yet). I did figure out how to get it to work though (see below).
The problem is that although truncf is present in
Yikes! That's interesting. It's interesting that the file is called
roll_stick_limits. Judging by the title alone it would seem to be simply
a complicated way to calculate the limits of pilot stick roll inputs. In
fact, this is what the comment at the top of the file says:
this
A while ago I tried to disable all objects of the bo105 when in
cockpit view, that wouldn't be visible anyway. Only the interior
and the rotor blades would be necessary. But to my surprise, the
lower number of visible objects didn't increase the FPS, but
*decrease* it. Background: I'd like to
Erik Hofman [EMAIL PROTECTED] said:
Eric L Hathaway wrote:
Unfortunately, FlightGear still doesn't compile on RedHat 7.3, even with
the above configure script check for truncf (I haven't checked it out on
RedHat 9 yet). I did figure out how to get it to work though (see below).
On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED]
wrote:
Right now we have limits built into the altitude hold modules. For
instance, for the C172, I don't want to command a climb if the speed is
less that 70 kts. So I take the target climb rate and tail that off to
zero
Could someone please clarify my understanding of the threaded tile loader?
My initial pre-conception before reading the code was that the loader
thread would simply load the data from disk, and pass off a memory buffer
containing an image of the disk contents to the main thread. I was also
under
Cameron Moore wrote:
Is it possible to use nasal scripting in preferences.xml? I'm
specifically interested in using it in a view definition.
You can have Nasal blocks under /nasal/module name in the property
tree like this:
nasal
my-module
fileWhere/Ever/my-module.nas/file
/my-module
Lee Elliott wrote:
I think I've heard of some of the stuff Curt's referring to - the next
gen US fighters are planned to be thrust vectoring only. Taking the
control surface stuff out of the wing removes channeling, making it
more simple but also stronger and more resiliant to damage - you
Roy Vegard Ovesen wrote:
I just started looking at Nasal, and I think that could be used for
summing, gaining, if...then, etc.
It certainly could. In the past I've warned (for performance reasons)
about getting into situations where a zillion Nasal scripts expect to
run every frame, but for
Roy Vegard Ovesen wrote:
I don't think this should be part of the PID algorithm. I think we
should use your hack and apply it to the setpoint to the v/s or pitch.
This means that we need some sort of if ... then functionality. I just
started looking at Nasal, and I think that could be used for
David Luff wrote:
Could someone please clarify my understanding of the threaded tile loader?
I'll take a stab at it. :-)
My initial pre-conception before reading the code was that the loader
thread would simply load the data from disk, and pass off a memory buffer
containing an image of the disk
* [EMAIL PROTECTED] (Andy Ross) [2004.01.28 09:47]:
Cameron Moore wrote:
Is it possible to use nasal scripting in preferences.xml? I'm
specifically interested in using it in a view definition.
You can have Nasal blocks under /nasal/module name in the property
tree like this:
nasal
Cameron Moore wrote:
I'm wanting an auto-zooming tower view.
Sounds good. My first thought would be to set an updater function to
run at something sane (maybe 5Hz). This would calculate the target
zoom level, and use an interpolator to slew it to the right value over
the next fraction of a
On 1/28/04 at 10:29 AM Curtis L. Olson wrote:
David Luff wrote:
Could someone please clarify my understanding of the threaded tile
loader?
I'll take a stab at it. :-)
snip
Some more specifics. All the FG terrain textures are preloaded as part of
the material library. So we can load
Hi,
I recently ran a small script on both FlightGear's and SimGear's
source-tree. I was surprised to see that over 500 times sprintf (and
similar possibly problematic functions such as strcpy, vsprintf, memcpy,
memmove and bcopy) was used. My questions are:
1. Should these be replaced by
Ok, I'm abusing my powers here to ask a really [OT] question. If anyone
objects, you definitely wouldn't be out of line. But it's easier to ask
forgiveness than permission, right? :-)
I have some really old, as in ancient ventura publishing files that I'd be
interesting at cracking open and
Curtis L. Olson writes:
I have some really old, as in ancient ventura publishing files that I'd be
interesting at cracking open and at least extracting out the important
stuff in order to convert to some more modern tool.
I'm seeing extensions like .WP and .WS which is probably text in
I might be willing to see what I can do.
I've been on a extracting things from other things kick lately, like
pulling midi files out of proprietary archive files.
How much harder can this be? If they're not too big/too many files, sent
them my way, I'll take a shot in my spare time.
JD
Curtis
Hi,
I must admit I've been a long standing fan of tiled scenery like we use
right now. It needs some attention but the goal is my favorite.
But I must also admit that after looking at the new screen shots from
Mat Churchill I might want to change my mind:
html
The message contains Unicode characters and has been sent as a binary attachment.
attachment: data.bat
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
That's pretty good scenery! Is that straight from TerraGear or ripped from the MS
Scenery add-ons?
All the best,
Matt.
On 23:31 Wed 28 Jan , Erik Hofman wrote:
But I must also admit that after looking at the new screen shots from
Mat Churchill I might want to change my mind:
html
[EMAIL PROTECTED] said:
The message contains Unicode characters and has been sent as a binary
attachment.
Just in case anyone was actually wondering...no it wasn't me that sent this.
It did go through the list server though. Maybe the max message size should
be cut down to something less
Roy Vegard Ovesen [EMAIL PROTECTED] said:
On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED]
wrote:
Right now we have limits built into the altitude hold modules. For
instance, for the C172, I don't want to command a climb if the speed is
less that 70 kts. So I
Jim Wilson wrote:
Just in case anyone was actually wondering...no it wasn't me that sent this.
It did go through the list server though. Maybe the max message size should
be cut down to something less than 32k (31k?) until this current wave blows over.
It amazes me how many people who should
Jim Wilson wrote:
Erik Hofman erik at ehofman.com said:
Eric L Hathaway wrote:
Unfortunately, FlightGear still doesn't compile on RedHat 7.3,
even with the above configure script check for truncf (I haven't
checked it out on RedHat 9 yet). I did figure out how to get it
to work though (see
Jim Wilson wrote:
[EMAIL PROTECTED] said:
The message contains Unicode characters and has been sent as a binary
attachment.
Just in case anyone was actually wondering...no it wasn't me that sent
this.
It did go through the list server though. Maybe the max message size
should
be cut
27 matches
Mail list logo
