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
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
mane
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 o
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 o
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
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'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 v
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 tw
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 /home/cvsroot/FlightGear/F
James Turner wrote:
> Well ... basically, but some of the landing modes get pretty involved.
> For example, you need to calculate the roll angle to counter-act the
> crosswind, and then prior to touch-down you need to convert roll into
> crab to avoid an engine scrape. Even DC-10 autopilots (which
Curtis L. Olson wrote:
> James Turner wrote:
> > Now, the problem is that such systems (as far as I can tell) expect to
> > drive a CDI bar on the HSI based on distance (in nm) off course. So, I
> > have two problems:
>
> Someone correct me if I'm wrong, but my understanding is that the
> needle d
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 s
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 si
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
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)
>
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 Bost
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 t
Slightly off topic, but I found the following post from Sunday on
dri-devel:
http://sourceforge.net/mailarchive/forum.php?thread_id=772607&forum_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
p
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
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
smalles
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 wr
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 th
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 "r
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 w
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 most
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 c
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
Jim Wilson wrote:
> But I'm still hitting top at just over FL300. When I switch to the
> old weathercm to see if I can get the FL360 yasim won't initialize the
> 747 (tried dc3 and c172 and they both come up).
Sorry, I wasn't clear. Not the weathercm stuff -- YASim used to use
its own Atmospher
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
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 dangerousl
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 YA
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'
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
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
> 500
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 numb
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:
> 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
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:
> On the other hand it could be lift. A possible clue: when I'm having
> trouble the "mach" reading seems to be way too high as compared to the
> KAIS reading just above. Examples:
>
> @ 19000ft 419KIAS MACH=0.91
> @ 23000ft 344KIAS MACH=0.83
Those numbers look correct to me.
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 D
Jim Wilson wrote:
> With everything synced to the current CVS the YASim fdm fails to start
> with 747-yasim on my system. It just spews a bunch of "Fail to unbind
> property" messages and gives up. Flightgear keeps on going however.
> The scene comes up...everything works, but the fdm is dead.
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
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
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
&
Melchior FRANZ wrote:
> The 747 causes some "Error: base =...", but seems to behave
> normal.
These aren't YASim errors. I'm not sure what they mean. If they're
specific to an aircraft, it's probably because I'm exporting (or not
exporting) a value that is confusing someone else. Anyone have a
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 com
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 -- increa
Jon S. Berndt wrote:
> OK. But I am not sure I agree with FlightGear's convention.
It less a FlightGear thing than a PC joystick convention, I believe.
Stomping on the left pedal makes the rudder axis value returned from
the joystick driver positive.
> The rudder Z axis is downward. [...] Perso
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:
> 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.
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 sev
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 jus
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 200
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
James Turner wrote:
> Just noting that the YAsim 747 gets a solution failure for me (updated
> 15 minutes ago).
The current one, right? The one in CVS doesn't work. You need the
most recent ones I posted, which haven't been checked in yet.
> The DC3 works great now, however, except that the VS
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 roun
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
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 com
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 coordi
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
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. Depe
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
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
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]
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 faul
, on to the responses:
Alex Perry wrote:
> 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
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
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
perh
OK, if anyone wants to try it before I get home, the following 5-line
patch adds support for a settable "castering" attribute for gear
objects. Apply it to the YASim directory, and then replace the tail
wheel definition in dc3.xml with this:
Then bind a key to toggle it, and we're set
Marjor A wrote:
> Works, but isn't perfect. At least I can take off now,
Good so far. I didn't claim that the castering would make the plane
pefect, btw. Just more directionally stable while on the ground.
> but if I try to use only one engine, the aircraft soon pitches up and
> crashes with t
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 b
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 of
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 effec
Major Andras wrote:
> When I try to take off with the dc3-yasim, the model seems to drag to
> one side, make the aircraft slide off the runway, and almost
> impossible to get into the air. I think that the side to which the
> drag occurs is the one whose engine was started second. It appears
> tha
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,
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 airc
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
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
>
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 ba
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
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 are
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
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, a
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
Christian Mayer writes:
> David Megginson wrote:
> > Christian Mayer writes:
> >
> > > Oh, BTW, EMACS and VI/VIM are no option for me (vim is great to change
> > > a file, but not to have a overview over a big project)
> >
> > What kind of an overview do you need?
>
> Well, all the stuf a
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 spe
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.
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
double-factored?
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 rea
Curtis L. Olson wrote:
> Bernie Bright writes:
> > Compiling YASim with the new Intel C++ V6 compiler gives the following
> > warning:
> >
> > ../../../../src/FDM/YASim/Model.cpp(260): warning #175: subscript out of
> > range
> > float dist = ground[4] - Math::dot3(ground, _wingCenter);
>
Jim Wilson wrote:
> I think #2 is solvable just by scaling and shifting the 2D panel
> according to the offsets (the 2D panel is already scaled).
The right solution here is to put the panel into the scene graph.
Then you just provide 3D airframe coordinates for the panel corners
and it maps wit
David Megginson wrote:
> I'm starting to wonder if the panel should be a special case at all in
> the 3D model. The currently-available model animations already cover
> all of the movements of the instruments except for text displays, so
> the instruments could simply be part of the 3D model
Erik Hofman wrote:
> "FlightGear" flight simulator software for Linux and Windows
> presented by: Andy Ross of the FlightGear project
I'd just like to point out that this is all Alex's fault. I didn't
have anything to do with it (other than saying "uh,
Erik Hofman wrote:
> I think we should define a fixed value for each flap position,
> otherwise every module looking at the value has to support (>0 &&
> <0.32 or >0.34 && <0.66 or >0.66 && <1.0)!
They do anyway. Many aircraft don't even have fixed flap stations; a
common homebuilt mechanism
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
John Wojnaroski wrote:
> Indicated Airspeed (IAS)
> Calibrated Airspeed (CAS)
> Next comes Equivalent Airspeed (EAS)
> Finally TAS
>
> Bottom line question for the FDM' rs: Would you take a few moments
> to comment/explain how your models handle the various airspeeds.
The FDM interface tre
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
exc
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 e
Jim Wilson wrote:
> Sigh. This is confusing. If I'm not mistaken, the axes as I
> described them are the way plib does them. So apparently what I've
> got now is something that works well for plib people.
To make things even worse, plib uses a different convention from raw
OpenGL. So the p
1101 - 1200 of 1471 matches
Mail list logo
