Jim Wilson wrote:
There isn't any information about autopilot features on an a4 that
I've been able to find. But since there is some interest in using
autopilot, a basic configuration has been added to the setup file in
CVS.
The original A4D didn't originally have an autopilot. It was
I lied again:
The perl scripts that generated the ball are attached. The ball.pl
script spits out the .ac file, while balltex.pl generates the texture
Postscript in a very similar manner to the gauge stuff I posted
earlier. Pass it an argument of north/south/east/west/top/bottom to
tell it
Jim Wilson wrote:
Andy Ross wrote:
What might be easier, though, is allowing for a optional 6-element
vertex line that included the normal.
We should be able to load into ac3d. But if we embedded commands
into the name tags we'd be ok.
Ah, I see what you're saying. You're right, your
David Megginson wrote:
For now, Andy, why not just generate a single object containing all of
the surfaces, rather than 6 separate objects? Then plib will have
less trouble with the normals.
Unless I've misunderstood the file format, this won't work. You only
get one texture per object; so
David Megginson wrote:
Andy Ross writes:
Unless I've misunderstood the file format, this won't work. You
only get one texture per object; so I need at least 6 objects.
You can combine all six 128x128 textures into a single 512x512
attitude.rgb file.
Oh. Duh. Yeah, I can do that. :)
I
Alex Romosan wrote:
after the merge of the cube sides in the attitude ball i now have one
huge ball sitting in the middle of the panel. you can find a picture
at http://caliban.lbl.gov/fgfs-screen-002.ppm.
I goofed the radius, sorry. It's currently a 7cm wide ball, which is
too small, but
Tony Peden wrote:
I think you mentioned that it was /accelerations/pilot-g's ?
I'd like to see some direction info added to the name as lateral accel
at the pilot seat is quite often of interest as well as normal.
So maybe:
/accelerations/pilot-normal-g and
/accelerations/pilot-lateral-g
Norman Vine wrote:
Check your editor's help file for 'multi-file grep' or 'multi-file search'
IMHO this is an indispensible editor feature for developing 'large'
projects and most 'good' code editors have this feature builtin so
you don't have to resort to using commandline tools directly.
Martin Spott wrote:
I get that, too. What I'm missing in recent releases is display of the
gear in the outside view and keyboard control of throttle and
flaps. This appeared to be introduced the the recent A-4 updates in
YASim. Can anyone confirm ?
Works for me. Are you sure you have a
David Megginson wrote:
Andy Ross writes:
This panel isn't quite right, though. The center attitude indicator
isn't a flat card, but is in fact a rotating globe.
This might be a good time to mention that we have an alternative
method for creating panels. 3D models can now include other
Curtis L. Olson wrote:
I have a lot of problems flying it well from the mouse. It doesn't
seem to respond well to elevator input ... you get an initial bump
and then pitch oscillations ... I don't know if that's realistic or
not. I'm sure Andy can provide a suitable explanation for why it
David Megginson wrote:
For anyone who'd like further reading on phugoid oscillations, see
Alex Perry wrote:
Nope, only for a given airspeed. The balance between tailplane and
main wing, for a given elevator position, is speed dependent. Thus
phugoids.
I think I should clarify. First off,
David Megginson wrote:
Note that some fighter aircraft, like (I think) the F-4, are
inherently unstable, and if they're modelled correctly we won't be
able to fly them at all by direct controls: we'll need to work though
a fairly sophisticated FCS.
The F-4 is stable. It's actually much
Jon S. Berndt wrote:
IIRC, the F-16 is neutrally stable throughout much of its flight
envelope. The main advantage for having a neutrally stable or unstable
fighter aircraft is agility, quickness in manueverability.
It's a chicken an the egg problem. Any aircraft can have quickness in
Charlie Hotchkiss wrote:
Nimble. Hmm. Wasn't the F16 so responsive that it became the first
fighter to put its pilot to sleep if he yanked to hard on the
controls.
Certainly not the first. GLOC has been an known issue from the very
early days of aviation. There was an experimental fighter
Rick Ansell wrote:
From memory G-Induced Loss of Consciousness (GLOC) is the 'new'
problem - this is caused by the rapid onset of G. Blackout is
progressive and therefore gives a warning. GLOC is sudden and occurs 4
to 6 seconds after the manoeuvre. Its insidious as short periods of
rapidly
Robert Detmers wrote:
Actually the F-4 is unstable, but only marginally. It just means that
the plane would eventually diverge if the pilot did nothing to stop
it.
Not in pitch, certainly? An aircraft that is unstable in pitch, if
you pulled the stick a little bit and got the nose going up
Rick Ansell wrote:
This is my reading to, but the two are usual treated/described as
separate and 'GLOC' was certainly heralded as a new hazard in the
80's. (Back when I religiously read Flight International from cover to
cover each week!)
I hadn't realized this was a new(ish) term. I've
Jim Wilson wrote:
Can anyone ID the left two instruments in the top row and the left
most in the bottom row?
The top left is exhaust temperature (in fahrenheit, I think). To its
right is airspeed in knots. The weird one at the bottom left is
probably a gear indicator; it might plausibly be a
Robert Deters wrote:
Andy Ross wrote:
Robert Deters wrote:
Actually the F-4 is unstable, but only marginally.
Not in pitch, certainly?
Yes in pitch. Besides, I think you are confusing static stability
and dynamic stability.
Er, normally one interprets an unqualified use of stable
Curtis L. Olson wrote:
Melchior FRANZ writes:
Curtis L. Olson wrote:
YASim has had code changes in the last 2,3,4 days so perhaps
something broke? (Hopefully it's not me that's doing something
stupid.) :-)
'Bad' news: Yasim works for me with CVS HEAD from one or two hours
ago.
I'm a pseudonym wrote:
I am using macos 10.1.5 and a saitek x45 usb joystick. The joystick
is getting power (lights up), but neither fgfs joystick tool (fgjs or
js_demo) sees it nor does fgfs when it starts up.
How does one set up a joystick on macos to work with flightgear?
Have you
I believe I've (finally) nailed the flap drag bug in YASim. A good
amount of thought, some work with pencil and paper, and a (IMNSHO)
damn clever application of the small angle approximation worked quite
well. The code changes were actually very modest and well-contained;
no machetes necessary.
I've been playing with the sound system for the A-4. Neat stuff. I
was getting bitten by some strange behavior, though, which I tracked
to an some uninitialized stack variables in fg_sound.cxx. If a sound
is defined without a specific scaling function (i.e., just play this
sound), the volume
Norman Vine wrote:
fgfs --help
exits with an error message about 'options.xml' missing
Shouldn't this be in fgfsbase ??
Apparently, it is in CVS. But the permissions on the file are
incorrect:
turban:/andy/src/fgfsbase$ cvs up options.xml
cvs server: cannot open
Christian Stock wrote:
This is perfect timing, I guess.
I just decided to quit MSFS development 2 days ago and I know the FS2002
bgls inside out. So I can definitely help out here...
Doesn't the 12-step program discourage this sort of thing? I mean,
jumping into a serious commitment so soon
James Turner wrote:
How do you generate a degree symbol under Linux? I was trying to and
failed miserably ...
This is character 0xb0 in the various ISO 8859 character sets (try
man ascii and man iso_8859_1), which essentially replace ASCII on
modern systems. US keyboards won't generate them,
David Megginson wrote:
Since YASim uses the atmosphere model from FGEnvironment (in JSBSim,
it's always 15degC and 29.92inHG at sea level), I tried some
experiments with different settings from KSFO:
Heh, I can just (barely) imaging a day in the Bay Area that peaks
around 95F. But the
Melchior FRANZ wrote:
valgrind reports this bug:
pthread_mutex_destroy: mutex is still in use
at 0x40523AB4: pthread_error (vg_libpthread.c:229)
by 0x405249B5: __pthread_mutex_destroy (vg_libpthread.c:825)
by 0x40625220: _IO_default_finish (in /lib/libc.so.6)
by
Jim Wilson wrote:
Not sure if this relates to the air pressure issue, seems to be a bit more
than that would account for. A few days ago someone reported unusual flap
effects, prior to the corrections to the YASim flight model.
It's a known bug. Curt found it a few months back. The fix is
Tony Peden wrote:
Induced drag is a function of the vortices surrounding the wing.
Those vortices vary in strength with lift, not angle of attack.
Not so. The induced drag of an aircraft in high-speed cruise is much
lower than an aircraft in level flight at stall speed. The lift in
these
Slightly off topic, but I found the following post from Sunday on
dri-devel:
http://sourceforge.net/mailarchive/forum.php?thread_id=772607forum_id=7177
Apparently, ATI have released (binary) Linux drivers for their FireGL
8700/8800 cards. These use the same core as the Radeon 8500, and the
Jim Wilson wrote:
Olivier Grisel said:
Furthermore, I can't hear the landing gear sound for
the 747-yasim
The gear sound is working now in my copy (can't remember if cvs is
working or not). For the most part it gets drowned out by the sound
of the engines. Not sure if on the real thing
Alex Romosan wrote:
it seems to be back. things were working on friday, but this morning
when i tried to fly the 747 out of KOAK i get this:
It looks like you're using the 747.xml file out of the current
fgfsbase CVS. As of the last fix, you need a new file to fix a tail
authority problem
John Check wrote:
Andy Ross wrote:
Checkins to the base package tend to lag the source tree by a few
days. I attached the new file to my mail on Sunday (subject: YASim
747-400 climb).
A few days? That really shouldn't be. Everybody that needs write
access for the base has it, AFAIK
James Turner wrote:
Is there any code in Sim/FlightGear to do generic conversion of a lat /
lon string into a decimal degree value?
And, if it doesn't exist, any suggestions how do a vaguely elegant
implementation?
Heh, that actually sounded kinda fun, so I tried it. Here's the
smallest
Curtis L. Olson wrote:
Has anyone tried to debug the Reset menu crash? I've been looking
at it for an hour and am just going in circles. Half the time I get a
segfault with no backtrace ...
I don't remember what a malloc segfault exactly
means, but I seem to recall that it probably means
Curtis L. Olson wrote:
David Findlay writes:
Anyone know if multitexturing is supported by Plib?
As far as I know, it is not.
This is true of the default plib objects, but not really of plib
itself. The ssgLeaf object is extensible, and supports a draw()
method that you can fill with
Jim Wilson wrote:
David Megginson said:
What happens when you reduce the fuel load?
Hmmm...nothing because it won't reduce. I'm showing full 19k+ lbs
for three tanks no matter what I do with the fraction figure in
the config and can't dump during flight it either.
Yes! That's it!
I lied:
There's another 747.xml file attached.
Sigh... someday I'll get one of these right on the first try.
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in
Michael Basler wrote:
I received the June issue of FlightXPress, a German language
(actually THE German language) language journal on Flight simulation
(http://www.flightxpress.de/) today.
This issue has a one page review on Flightgear written by a Marc Stoering
This actually seems mostly
David Megginson wrote:
The idea is that users should be able to set any reasonable sea-level
pressure and see reasonable behaviour -- that's why I set the tables
up with deltas rather than absolute values. I can see, now, how that
would be a problem at higher altitudes, but what should we
Jim Wilson wrote:
Actually I tried all the way up to 80,000lbs and still ran into
problems in the 25000ft range. There is a little uncertaintly in just
what I'm observing. Basically there is a steady decrease in
attainable airspeed.
I found one bug. There was a property name typo* in
Major A wrote:
This may or may not have anything to do with the jet code, but with
the 747-yasim, I cannot slow the plane below about 280kt in level
flight at 3000ft ASL with throttles at minimum and full flaps, which
makes the plane rather hard to land...
By way of disclosure: there is a
Jim Wilson wrote:
There should be speed brakes which would have helped a lot, but they
might not be implemented yet.
Sure are: /controls/spoilers
There are also a bunch of flaps on a real 747 and I'm not sure which
ones are actually modeled.
All of them; YASim models flaps symbolically as
Jim Wilson wrote:
Think I saw something that was maybe at a fixed weight. Not the full
Flight manual table. When I get home I'll look for it. But I was
suprised at the data. At lower altitudes it was over 4000fpm and was
at least 2000fpm up to and over 3ft. Finally dropped off to
Jim Wilson wrote:
Yeah but look at the values again...we're getting close to tropopause
value at 23000ft. Mach should be well over 600knots at 23000ft,
unless it's _really_ warm.
Mach 1 at the tropopause and above is just about exactly 295 m/s,
which is 573 knots *true* airspeed. The
More evidence. The following quote is from an HTMLized google cache
of a file named 747operations.pdf. The file itself is gone from the
web, unfortunately. It appears to be a POH compiled for an MSFS
virtual airline:
After climbing as described above to 10,000 feet, reduce climb to
500fpm.
Curtis L. Olson wrote:
If we could get a couple people to commit to spend a chunk of time
in the booth, then I think it would *definitely* be worth getting
something organized.
I have a floor pass already, and could easily commit to spending a day
in the booth if needed.
Andy
--
Andrew J.
Jim Wilson wrote:
Andy Ross said:
The bad pilot technique theory is looking pretty good. If YASim can
get to 1400fpm at 300 knots, then I move that it be declared
officially innocent on all counts. :)
Well maybe not yet...it is better with today's patch...but still run
out of steam
I wrote:
First, the air pressures returned from the environment system don't
agree with the standard atmosphere that YASim uses to do its
calibration
Heh, funny that. The new environment manager *is* using YASim's
numbers. :)
Nonetheless, I think I found the problem. In converting the
David Megginson wrote:
Cameron Moore writes:
So, if you contribute to FG and would like to be listed, just let me
know.
Just to repeat something I mentioned before, it's probably a good idea
not to give your location *too* precisely.
Heh, good point. But I like to live dangerously (and
OK, I *think* I have nailed the platform-dependant YASim solution
failures. What I found was that the solution heuristics hid a bunch
of pseudo-chaotic instabilities that were introduced when the approach
elevator trim feature went in a few weeks back. This was
deterministic, but weird --
Jim Wilson wrote:
Andy that works. Haven't been able to download your tar ball (is the
link correct?).
Sigh. Long story: plausible.org is a box in my closet. We lost power
last night. It has a dumb (Asus P5A) ATX motherboard that doesn't
know how to power on following a power loss (it
Jon S. Berndt wrote:
Andy Ross wrote:
last night. It has a dumb (Asus P5A) ATX motherboard that doesn't
know how to power on following a power loss (it comes up in soft-off
You sure you don't have a BIOS setting for that? I've got one on my
m/b. Maybe you need to upgrade your BIOS
David Megginson wrote:
Andy Ross writes:
The way the code works is that it matches some performance curves I
got out of McFarland for a 707 engine. The turbofans on the 747
actually won't be too terribly far off in their thrust performance,
I'd think.
This is probably a dumb question
I wrote:
Jim Wilson wrote:
It appears that the thrust/altitude curve is a bit too steep. [...]
Also there seems to be a greatly exagerated ram effect (not sure
of correct term). It seems that airspeed changes might be affecting
the thrust value too greatly, but I don't have a feel for
Jim Wilson wrote:
The pitch angle seems to be way too high when at altitude (not
climbing) [...] But now I'm thinking that the real issue has to do
with the lift calculation. [...] The altitude starts to decrease
smoothly as IAS passes below 300knots...not in a stall fashion.
This is
Jim Wilson wrote:
This is what I get with the patch. Looks like some of the values did
get a little worse, but not uniformly. The delta values seem to be
oscillating every other iteration? I relisted the prepatch values
after these new values for comparison.
Hrmph. This is getting just
Jim Wilson wrote:
Turn left, you go right and vice versa.
Nothing's changed, so far as I know. Has anyone been playing with the
default bindings?
Which aircraft? YASim, per se, makes no interptetation of any input
properties. It gets told by its configuration file to read a property
(or
Jim Wilson wrote:
Doh! I was wondering why I didn't notice this before...it is turning
correctly. The controls values are the opposite of JSBSim, so in
chase view the rudder animations go the wrong way. I guess that means
almost the same thing in a way...since the control is reversed. If
Julian Foad wrote:
tailDelta is increasing here. At a guess, I'd say maybe the
solution is oscillating.
That's possible. There's nothing fundamental in the design that
prevents oscillating solutions. In fact, there's nothing fundamental
in the math that guarantees a single solution at all
I wrote:
Jim, there's an attached patch to Airplane.cpp that hacks in
different numbers. Could you try this and see if it works? (For all
I know, it might make things worse).
Oops. Here it is:
--- Airplane.cpp21 May 2002 16:45:56 - 1.11
+++ Airplane.cpp27 May 2002
Darren Hammond wrote:
I'm getting the following compile error in FlightGear with the latest
CVS. Plib SimGear are also latest.
undefined reference to `yasim::Airplane::setElevatorControl(int)'
Do a make clean. This function was just recently added. Somehow your
version didn't get
Jim Wilson wrote:
Andy Ross wrote:
I don't think the most recent batch of updates has made it in yet.
Attached is the current version I'm using. I can verify that it works
for me. :)
H...I installed the 747.xml and even did a make clean;make. Still
having the same problem. Any
Jim Wilson wrote:
Andy Ross wrote:
I'm worried that I may have a platform-dependent bug here.
gcc 2.95.2 here on linux. Could it be a hardware issue?
Basically, it's just a math problem, and it *should* give the same
answers on any hardware. Things like roundoff errors get corrected
Charlie Hotchkiss wrote:
So, just for discussion's sake and noting that nobody with detailed
knowledge of and experience with this aircraft has weighed in, I have
questions. Isn't the L/D ratio at high angles of attack different
(poorer) when in ground effect?
Actually, it's better.
Jim Wilson wrote:
Should the Yasim 747 work now? Are there any files that need to be
checked into fgfsbase? I'm still getting the Solution Failure when
starting up the 747...and at some point I'd like to animate the 747
model.
I don't think the most recent batch of updates has made it in
Cameron Moore wrote:
The only things I noticed that need fixing are the offset to get the
model sitting on the ground correctly and there's a reference to a
missing 747 panel in 747-yasim-set.xml.
Agreed. It looks great. The offset problem is almost certainly due
to a difference in
:
Andy Ross wrote:
You started up the engines, firewalled the throttle, let the RPMs
stablize, released the brakes, and the aircraft pitched *up*???
That's clearly unphysical.
Why ? The nose pitches down with power and brake application. So,
releasing the brakes makes the nose pitch up
David Megginson wrote:
Note that I set castering=0 rather than removing the attribute
completely.
I saw it in a slow, taxiing turn at around 10kt or less, but I had
done the modification myself before you posted yours. I'll try it
with exactly your suggestion.
Ah; this is my fault. You
I wrote:
Attached is the DC-3 file I was using last night, which maps the
castering bit to /controls/tailwheel-castering.
I lied again. Now it's attached.
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED]
I wrote:
Major A wrote:
I think the main problem really is the rapid increase in airspeed,
which is unnatural, and doesn't occur if both engines are used.
Bingo. This is a bug in the propeller code [...] (I'm pretty sure it
used to work -- I remember doing hammerhead stalls in the A-4
Charlie Hotchkiss wrote:
Perhaps I'm showing some ignorance here (I'm certainly not a pilot,
much less an expert), but isn't the induced drag in that situation so
large as to preclude reaching flying speed? The wings acting at that
angle much like a drag brake? I read somewhere that pilots
Alex Perry wrote:
I don't know whether YASim models ground effect; if it does, the
tailplane becomes more effective in ground effect and sucks the tail
downwards. That'll exacerbate the torque of the forward gear mounting
position.
Oooh! Good point. YASim does indeed model ground effect
Whee, here we go again. :)
David Megginson wrote:
Andy -- can you actually manage the DC-3 in a ground roll and takeoff?
I have not been able to do so for a long time -- it always ends up
spinning like a top. If you can do it, perhaps it would help if you
posted a step-by-step.
First off,
David Megginson wrote:
1. According to the author, at least, differential braking is bad form
while taxiing the DC-3; you should use differential power instead
except for very tight turns.
I'll buy that. But working dual throttles during the takeoff and
landing rolls can't possibly be
Alex Romosan wrote:
is anybody able to fly the yasim planes with latest cvs and the above
patch? i keep getting:
YASim SOLUTION FAILURE:
Solution failed to converge after 1 iterations
for the a4, harrier, 747.
I appear to have goofed something up with the posted planes. Or
perhaps
Major A wrote:
Sorry, sorry, that should have read tail stuck IN the
ground. Attached screenshot taken within 3sec after releasing brakes,
after this, the plane pitches up even more, and fgfs hangs, moaning
about terrain intersections. Maybe it's the two fronts wheels taking
off rather than
Melchior FRANZ wrote:
When I reported the 747 problem, it had nothing to do with approaching.
The 747 didn't work at all! Not even the scenery was shown, before fgfs
aborted. Just the HUD and the sky.
Right. That was a simpler problem -- a bad configuration file in the
archive that, ahem, no
Melchior FRANZ wrote:
Err ... I'd say it doesn't run because there seems to be some nasty
bug in Yasim or its 747 data. I =do= have a 747 model installed, and
this is what I get before fgfs aborts:
YASim solution results:
Iterations: 10002
Drag Coefficient: 13.1075
Alex Romosan wrote:
Andy Ross [EMAIL PROTECTED] writes:
Remaining outstanding YASim bugs are (people should shout if I've
forgotten something):
i don't know if this a bug or if that's how the modeling is supposed
to work but the a4 is almost unflyable. when i use the controls the
plane
I just commited a YASim patch to fix the approach lift problem I
mentioned this morning. The 747, in particular, behaves much more
sanely on approach. (But remember the fuel load! The model now
starts at only 50% tanks, but that's still quite heavy for an
approach).
The patch requires new
Martin Henne wrote:
Tony Peden wrote:
OK, ha, ha, funny, funny. Joke's over.
Curt, David: I humbly request that such patches not be accepted in the
future.
I definitely agree. It's a violation of almost every netiquette rule,
that is concerned to virus-like behaviour or bandwith
Curtis L. Olson wrote:
So what is the SI unit for direction/heading? Certainly they
wouldn't overload unit names, right? :-)
Oooh, here's a good one!
There *are* no unit names for angles. Angles are unitless numbers.
So to be strict, the SI unit for heading must be the radian. :)
FWIW,
Christian Mayer wrote:
(Note: degrees are still valid as they are *internationally* well
known. slugs aren't)
Actually, there's a very good reason why we use a 360 degree circle.
This number has loads of small integer divisors. What's the inner
angle between the walls of a 4-sided room? 90
David Megginson wrote:
Ralph Jones writes:
It would, indeed, be nice to have a vertical velocity model for simulating
soaring flight. I'm still trying to run down stability derivatives for my
sailplane!
It will be easy to allow you to specify up- or down-drafts for
specific areas; it
Curtis L. Olson wrote:
Here's an interesting option. Recently, I've been chatting with the
author of the KFlog project (http://www.kflog.org/)
What an unfortunate name. Am I the only one who read that and thought
Hm... I wouldn't really have though KDE needed a flogging application
on the
Christian Mayer wrote:
And there are already 1.5 - 2 FDMs that use SI units (BalloonSim and
much more important YASim).
Woo hoo! Just a few short months in the source tree and already YASim
is *much* more important than BaloonSim. World domination, here I
come!
As far as the SI vs. English
Wolfram Kuss wrote:
Andy Ross wrote:
You could also experiment with turning off backface culling instead
of rendering two quads for each direction. In principle, it should
be faster. In practice, it's probably a good way to detect driver
bugs. :)
The speed difference will be very
Julian Foad wrote:
The original code assumed that dt was in milliseconds. The variable
name velocity_rpms presumably stood for revs per millisecond.
Your patch assumes that dt is in 1/120ths of a second.
I believe, although I am not authortative on this, that the dt
parameter specifies an
Here's a patch to model.cxx that restores the proper rotation speed of
the propeller spin.
It just replaces the single 1/6 constant with one that is
(hopefully) more clearly derivable from basic principles. The
original number was off by a factor of 3/25; maybe something got
Curtis L. Olson wrote:
Andy, I think YASim has a bug. :-)
YASim: 0.00 AGL
4.946215 ASL
YASim is saying that the CG is exactly on the ground level
which is physically impossible. It compensates by saying the
ground level is 4.9' above the real
Erik Hofman wrote:
Well It's making it slightly difficult for the sound code. But I saw
YASim does the same.
These numbers are actually generated by the panel code, not the FDM.
Both FDMs just seek the position to the specified control input. In
this case, the panel code adds or subtracts
David Megginson wrote:
1. They're hard to use from inside the 3D cockpit, at least until Andy
gets mouse clicks working on his wrap-around panel; and
I'm still here, I promise! Hopefully I'll have a good whole day this
weekend to devote to flight gear stuff. For those interested in
Curtis L. Olson wrote:
Yes, the propellor spins way to slowly compared to engine rpm. This
might be intentional so that it maintains 'smooth' animation. But,
it is maybe just a little noticably too slow ...
Actually, I think this is a recent change. I remember doing some back
of the
Martin Spott wrote:
Andrew Ross wrote:
Here's a gedanken experiment
A _what_ ? Is this a valid word in your language ? I'm asking because
it definitely has german roots, the word 'gedanken' That's
funny,
The word is, in fact, german. Whether it's valid English or not is an
David Megginson wrote:
Andy Ross writes:
All that being said, did the configuration patch for the takeoff RPMs
do what you want? It was better justified than the idle hack. :)
The plane seems to take off OK, but there are handling problems -- in
a 72kt climb at full power, the nose
Simon Fowler wrote:
Andy Ross wrote:
I'm actually fuzzy on the real reason that high-wing aircraft have a
built-in dihedral-like effect.
Take a look at http://www.monmouth.com/~jsd/how/htm/roll.html . . .
Right. That's basically what I meant by fuzzy -- I understand how
the effect
David Megginson wrote:
I think we've always used +z up. YASim uses +z down internally, if
I recall correctly, but that shouldn't affect anything else.
Heh, actually... YASim is +z up too.
For the record, the YASim internal aircraft coordinate frame:
+ Take your right hand.
+ Point your
1001 - 1100 of 1282 matches
Mail list logo
