Re: [Flightgear-devel] deprecated or antiquated header
On Thursday 27 March 2003 23:43, Bernie Bright wrote: On Thu, 27 Mar 2003 21:24:39 -0700 WillyB [EMAIL PROTECTED] wrote: Yes.. that was from TerraGear.. there are/were others from FG... but no idea how to change it so they are not there. I ran into this today... In file included from /usr/include/c++/3.2/backward/strstream:51, from uiuc_2DdataFileReader.h:6, from uiuc_2DdataFileReader.cpp:76: /usr/include/c++/3.2/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. StdC++ deprecates strstream in favor of sstream. Unfortunately not all compilers support the newer ostringstream and istringstream classes so we have to live with the warnings for now. On the other hand we could add a test for sstream to configure. Some code changes would also be required. Cheers, Bernie Ah .. I see... Thanks Bernie WillyB ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
- Original Message - From: Erik Hofman [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 2:50 PM Subject: [Jsbsim-devel] MSFS Aircrafts Hi, How come whenever I release an aircraft for JSBSim, a few weeks later I see an anouncement on avsim.org that this type of aircraft will be available to MSFS with a realistic flight model? Very few MSFS AC have 'realistic' flight models. ;) Though AVSIM reviewers and a bunch of desktop pilots often think they are. It happened with the F-16, it happened with the F-104 and it will happen with the F-15 also! Oh well, maybe I'm just paranoid. Erik FS2K+ can't use realistic values of Cm_q and Cn_r at Mach 0.7/30,000 ft or higher I've had to increase those two by 50% or more to get enough pitch and yaw stability so the crappy 'autopilot' in FS2K2 won't make an AC porpoise or even lose ALT control. In the jets, MS defaults and 99% of FS 2'nd party AC are set with dampings 4 to 20X realistic values. Assuming Cm_q = -20 is ealistic. -5.0 is more likely for the Fighters mentioned above. Further, I found a 30 lb AC isn't stable in FS2K2 with nominal SD's. Nor did scaling it to 80 lbs help. Lighter FS2K2 AC may jitter on the runway unless Roll MoI is increased above the real value. Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
- Original Message -
From: David Megginson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 4:08 PM
Subject: re: [Jsbsim-devel] MSFS Aircrafts
Erik Hofman writes:
How come whenever I release an aircraft for JSBSim, a few weeks
later I
see an anouncement on avsim.org that this type of aircraft will be
available to MSFS with a realistic flight model?
At least one MSFS designer reads these lists and has been in touch
with me about the 310 model (which I designed). I don't consider that
a problem -- the person I corresponded with, at least, wanted to share
ideas and feed fixes back into our data. In any case, it's worth
remembering that we take many of our stability numbers from other
people's work (like Roskam's).
I guess Roskam's SC Vol 1 has quite a few good SD listings.
However, some AC may have dropped out of the more recent editions. I
accidentally ended up with SC Vol 2, which has some curves showing Mach
variations with and without aeroelasticity included. The rest is on FB
control systems.
I think that an application-independent public database of stability
coefficients would be a worthwhile project in itself. It would be
useful for FlightGear, XPlane, and MSFS, and we'd end up with a much
bigger pool of contributors.
Hmm. Maybe I'll start on that.
David
I don't know how much can be explicitely set for X-Plane. Which is
claimed to 'calculate everything panel by panel'. FG and MSFS use
similar flight models, though one has to know how to convert when
non-linearities come into play.
Further, MSFS appears to only model slower AC well. Above 25,000
ft or so, especially at higher Mach numbers the code probably doesn't
step fast enough and some dampings have to be increased to keep an AC
stable. However, other SD's appear to apply quite well.
Regardless, a general database of Stability Derivatives and
other details would be quite useful. Powerplants also. Even basic
formulas. Also, Spreadsheets and programs to calculate performance
from basic elements. ***
One thing MS developers have is access to a lot of real pilots. Who
can at least give some idea if an AC 'feels right'. All the way to
747's. Further, they are good at scanning Flight Manuals that might be
hard to obtain otherwise. ;) We also have airline employees with
access for photographing cockpits etc. By hook and crook I also
managed to obtain a couple of Boeing Performance Engineering Manuals on
jet transports. One contains proprietary data on drags, lift, and
turbine matrices.
I'll point more of the engineers fooling with MSFS to
sci.aeronautics. One works for 'a big AC company' and has copied
several aerodynamics books from their library. Classics such as one by
Whittle on turbines.
Ron
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [BUG] fgfs core-dumps with --airport=kemt
Just out of curiosity I've recently tried to request a few invalid airports and noticed that lower case IDs crash fgfs. The reason is the following: runways.cxx:314 searches for the kemt airport (320) and kemt is indeed found, despite the lower case letters. But then the loop (329) compares the requested runways (kemt) with the ones from the database (all KEMT!), so the while loop is instantly finished, FGRunways::search returns with neither a valid runway, nor with NN. Consequence: crash when the invalid runway is accessed in runways.cxx:196. How to reproduce: fgfs --aircraft=ufo --airport=kemt Now, this isn't exactly hard to fix. The ideal fix, however, would IMHO be to normalize every input of runway and airport-id to upper case letters. This would require to add a Listener to their properties, but this looks a little bit over-engineered. So, should I provide a patch for a suboptimal solution? Or do the Listener thing instead? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Control column behavior modelling
On Fri, 28 Mar 2003, David Megginson wrote: A home-computer joystick or yoke might have a little spring in it, but in general, it's going to be far too easy for the computer user to create an elevator deflection, and the plane's going to feel unstable. There are two solutions to this problem (other than building a full, force-feedback console). One is to exaggerate the coefficients to make the nose more stable than it should be, but that sort-of sucks. The better solution -- which I stole from Andy Ross -- is to square the joystick axes (preserving sign), so that small joystick movements are less sensitive than large ones: [...] Now, the pilot will have to move the joystick 50% of the way just to get a 25% elevator deflection, and a 10% joystick deflection will result in only a 1% elevator deflection, so the plane will seem more stable. This is still far from perfect, but it's better. Or, modelling the control column as having substantial mechanical staying power, and treating the joystick input as the force applied to move it rather than as the control column position. I must admit I haven't yet looked into the code, and besides I've never flown a real airplane so I can't comment on how actual control columns feel. I think MSFS98 models the control column as having infinite mechanical staying power in the absence of force applied to it by the pilot, and I happen to like the feel of it (of course, it also makes me lazy in applying trim :-) I may be off my rocker here; I'm not a pilot; rarely boot into Windows; and I'm still dicking with the FreeBSD joystick interface to plib more often than I'm flying B747's into the SF Bay :-) (the good news is that the FreeBSD USB joystick interface is coming along and works well with the CH Flightsim yoke -- hope to clean up the code and submit it to the plib folks this weekend). Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
- Original Message - From: David Megginson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 28, 2003 8:22 AM Subject: Re: [Jsbsim-devel] MSFS Aircrafts Ron Freimuth writes: One thing MS developers have is access to a lot of real pilots. Who can at least give some idea if an AC 'feels right'. All the way to 747's. That's harder than you might think: how a plane feels to the pilot depends as much on control loading as on responsiveness ... A pilot familiar with that plane is almost certainly going to find it very unstable in the pitch axis, and complain that the nose bounces up and down too much. In the real plane, the dynamic pressure from the relative wind tends to hold the control surfaces in one spot, and it takes a bit of effort to move them from where they want to be (a *lot* of effort for a big deflection). A home-computer joystick or yoke might have a little spring in it, but in general, it's going to be far too easy for the computer user to create an elevator deflection, and the plane's going to feel unstable. I flew a Level C Falcon 20 a couple of years ago. It used variable rate springs on the yoke to give an indication of aerodynamic loading. Same as the real FA-20. Other than the fact that the real Yoke took more force than my MS Sidewinder JS, I didn't find it hard to adapt to. Nor did I feel my non-FFB Sidewinder was far different. I'm used to the small, non-varying spring forces, use a light touch and have a horizon indicator turned on so I can get attitiude dynamics visually and by force. My main problem is the backlash in my overused Sidewinder. However, trying to control the FA-20 on the TO roll with the steering knob, rather than the rudder pedals, was not easy. ;) OTOH, WWII AC had manually linked control surfaces and required all the pilot's strength to fully maneuver. Some AC required pitch trim to be set closely; the pilot couldn't get an AC off the ground otherwise. No real pilots think FFB is realistic. I bought a 'Wingman FFB' and it gives the illusion of way too much sensitivity. Even with a lot of fake 'spring centering' set the forces were weak. Moving the base to 45 degrees resulted in the stick moving and the AC pitching or rolling also. The forces were too weak for the first 50% deflection, then increased more rapidly and I could feel cogging. Not at all smooth. Jerry Beckwidth's 1% SS sets the control moment vs q tables to emulate the limits of the pilot's strength. In combination with Cl_p, etc. this generates CFS AC that roll and turn at the published rates. There are two solutions to this problem (other than building a full, force-feedback console). One is to exaggerate the coefficients to make the nose more stable than it should be, but that sort-of sucks. The better solution -- which I stole from Andy Ross -- is to square the joystick axes (preserving sign), so that small joystick movements are less sensitive than large ones: PS1, a good 747 simulator mentions 'exponential' response to JS movements. Fly! allowed one to change the exponential effect. Possibly it is misnamed, x^n involves an exponent, perhaps it was 'n' that could be varied. MSFS2K appears to have changed to some intrinsic non-linear mapping compared to FS98. FS/CFS AIR files have 'gearing' tables that let one shape the control moment sensitivity as desired. I tend to set them at 0.80 at neutral elevator deflection. The problem with this is that the control surfaces drop in moment/force as they increase in deflection (similar to flaps). This is in the opposite direction. I've set the rudder 'gearing' something like an inverted W; this reduces sensitiivty in the middle and at the higher deflections.In the end, a flat 'gearing' curve may be a good compromise in MSFS. Especially since FS2K+ appears to have some 'exponential' effect added implicitly. Fly!, and MS FS/CFS allow one to change 'null zone' and 'sensitivity' for the JS in the menu. Lower sensitivity adds more low pass filtering to the JS command, not less ultimate movement. This mainly affects AC with fast control actuation, such as aerobatic AC. A nominal setting adds a time constant of perhaps 0.1 second. Which is about what one might expect from hydraulic actuators on AC that use them. -1.0 = -1.00 -0.5 = -0.25 0.0 = 0.00 0.5 = 0.25 1.0 = 1.00 Now, the pilot will have to move the joystick 50% of the way just to get a 25% elevator deflection, and a 10% joystick deflection will result in only a 1% elevator deflection, so the plane will seem more stable. This is still far from perfect, but it's better. I do rapid full forward, full back JS deflections and check that the G level changes about the same amount + and -. Say 1.0G (level) to +3.5G full back, and -1.0G full forward. Considering the different up and down elevator limits the G force should change
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
A pilot familiar with that plane is almost certainly going to find it very unstable in the pitch axis, and complain that the nose bounces up and down too much. In the real plane, the dynamic pressure from the relative wind tends to hold the control surfaces in one spot, and it takes a bit of effort to move them from where they want to be (a *lot* of effort for a big deflection). A home-computer joystick or yoke might have a little spring in it, but in general, it's going to be far too easy for the computer user to create an elevator deflection, and the plane's going to feel unstable. Just an idea -- if someone were to build proper force-feedback yoke/pedals/etc., would FlightGear be able to drive them realistically? I.e., is force on the controls part of the FDM? Fly! allowed one to change the exponential effect. Possibly it is misnamed, x^n involves an exponent, perhaps it was 'n' that could be varied. MSFS2K appears to have changed to some intrinsic non-linear mapping compared to FS98. I don't know about Fly!, but exponential traditionally is a misnomer. A lot of RC transmitters allow you to set it, but that usually means that the response is proportional until you reach a certain deflection, then makes a kink and the control starts reacting with more authority, but still linearly. No such thing as an exponential function, which is probably because exponentiation is rather difficult to implement in analogue electronics. Fly!, and MS FS/CFS allow one to change 'null zone' and 'sensitivity' for the JS in the menu. Lower sensitivity adds more low Is the null zone there in a real aircraft (backlash), or just a feature of the sim to allow the pilot to go and grab a cup of coffee? -1.0 = -1.00 -0.5 = -0.25 0.0 = 0.00 0.5 = 0.25 1.0 = 1.00 This is a good response, but it also implies that at 0 deflection, the control is totally nonresponsive (gradient is zero). Shouldn't we simply add a linear term here? That would make the control linear around the centre and transition into a square response at higher deflections. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
--- Major A [EMAIL PROTECTED] wrote: A pilot familiar with that plane is almost certainly going to find it very unstable in the pitch axis, and complain that the nose bounces up and down too much. In the real plane, the dynamic pressure from the relative wind tends to hold the control surfaces in one spot, and it takes a bit of effort to move them from where they want to be (a *lot* of effort for a big deflection). A home-computer joystick or yoke might have a little spring in it, but in general, it's going to be far too easy for the computer user to create an elevator deflection, and the plane's going to feel unstable. Just an idea -- if someone were to build proper force-feedback yoke/pedals/etc., would FlightGear be able to drive them realistically? I.e., is force on the controls part of the FDM? The flight control system in JSBSim will allow for it as it stands, but work would have to be done to get that info to FG. Also, none of our models currently calculate the forces. Fly! allowed one to change the exponential effect. Possibly it is misnamed, x^n involves an exponent, perhaps it was 'n' that could be varied. MSFS2K appears to have changed to some intrinsic non-linear mapping compared to FS98. I don't know about Fly!, but exponential traditionally is a misnomer. A lot of RC transmitters allow you to set it, but that usually means that the response is proportional until you reach a certain deflection, then makes a kink and the control starts reacting with more authority, but still linearly. No such thing as an exponential function, which is probably because exponentiation is rather difficult to implement in analogue electronics. Fly!, and MS FS/CFS allow one to change 'null zone' and 'sensitivity' for the JS in the menu. Lower sensitivity adds more low Is the null zone there in a real aircraft (backlash), or just a feature of the sim to allow the pilot to go and grab a cup of coffee? -1.0 = -1.00 -0.5 = -0.25 0.0 = 0.00 0.5 = 0.25 1.0 = 1.00 This is a good response, but it also implies that at 0 deflection, the control is totally nonresponsive (gradient is zero). Shouldn't we simply add a linear term here? That would make the control linear around the centre and transition into a square response at higher deflections. Umm, I think that he's trying to reduce the response around the center. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Major A writes: Is the null zone there in a real aircraft (backlash), or just a feature of the sim to allow the pilot to go and grab a cup of coffee? I think it's a different attempt to compensate for the lack of control loading. -1.0 = -1.00 -0.5 = -0.25 0.0 = 0.00 0.5 = 0.25 1.0 = 1.00 This is a good response, but it also implies that at 0 deflection, the control is totally nonresponsive (gradient is zero). Shouldn't we simply add a linear term here? That would make the control linear around the centre and transition into a square response at higher deflections. I'm not sure that I understand the problem. As soon as you move the control, it is no longer at zero and will get a gradually increasing response. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
This is a good response, but it also implies that at 0 deflection, the control is totally nonresponsive (gradient is zero). Shouldn't we simply add a linear term here? That would make the control linear around the centre and transition into a square response at higher deflections. I'm not sure that I understand the problem. As soon as you move the control, it is no longer at zero and will get a gradually increasing response. Yes, but wouldn't it be better to have at least a small amount of control around the centre? I think it would make things more natural. The best example I can think of now is aileron -- a linear term would make it easier to keep the aircraft level. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Major A writes: Yes, but wouldn't it be better to have at least a small amount of control around the centre? You do. Unlike a dead zone, this approach has no location where moving the joystick will not produce some kind of input. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trouble compiling: undefined reference to ssgCullAndDraw(ssgRoot*) ???
John, Have you compiled plib with the same compiler as the rest of the code? Curt. John A. Gallas writes: Hello all, I downloaded the cvs source tree for the first time yesterday and all the compiling went okay, but it won't link. Here is the output: [EMAIL PROTECTED] Main]$ make g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -L/usr/X11R6/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o logger.o opti ons.o splash.o util.o viewer.o viewmgr.o location.o ../../src/Aircraft/libAircra ft.a ../../src/ATC/libATC.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit /libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libCon trols.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/F DM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../ ../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSi m/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUC Model/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Input/libInput.a ../../src /Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/Netwo rk/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a .. /../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/l ibAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Objects/libObject s.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environmen t/libEnvironment.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen -lsg math -lsgbucket -lsgdebug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lpli bfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lplibpsl -lmk4 -lz -lglut - lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lpthread -lm -lplibsl -lplib sm -lm main.o: In function `trRenderFrame()': /home/john/myfiles/FlightGear/src/Main/../../src/Scenery/scenery.hxx:323: undefined reference to `ssgCullAndDraw(ssgRoot*)' /home/john/myfiles/FlightGear/src/Main/../../src/Scenery/scenery.hxx:323: undefined reference to `ssgCullAndDraw(ssgRoot*)' /home/john/myfiles/FlightGear/src/Main/../../src/Scenery/scenery.hxx:323: undefined reference to `ssgCullAndDraw(ssgRoot*)' main.o: In function `fgRenderFrame()': /home/john/myfiles/FlightGear/src/Main/../../src/Scenery/scenery.hxx:323: undefined reference to `ssgCullAndDraw(ssgRoot*)' /home/john/myfiles/FlightGear/src/Main/../../src/Scenery/scenery.hxx:323: undefined reference to `ssgCullAndDraw(ssgRoot*)' main.o:/home/john/myfiles/FlightGear/src/Main/../../src/Scenery/scenery.hxx:323: more undefined references to `ssgCullAndDraw(ssgRoot*)' follow collect2: ld returned 1 exit status make: *** [fgfs] Error 1 [EMAIL PROTECTED] Main]$ Im using the current cvs versions of plib and SimGear, which compiled and installed without a problem. Do I need to update something else? Thanks very much, John Gallas __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Major A writes: Just an idea -- if someone were to build proper force-feedback yoke/pedals/etc., would FlightGear be able to drive them realistically? I.e., is force on the controls part of the FDM? You could build a software interface to your hardware that could read the appropriate control position, apply some sort of control algorithm, and drive your force feedback motor appropriately. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Ron, I must admid it, you have made my day. :-) Erik Very few MSFS AC have 'realistic' flight models. ;) Though AVSIM reviewers and a bunch of desktop pilots often think they are. FS2K+ can't use realistic values of Cm_q and Cn_r at Mach 0.7/30,000 ft or higher I've had to increase those two by 50% or more to get enough pitch and yaw stability so the crappy 'autopilot' in FS2K2 won't make an AC porpoise or even lose ALT control. In the jets, MS defaults and 99% of FS 2'nd party AC are set with dampings 4 to 20X realistic values. Assuming Cm_q = -20 is ealistic. -5.0 is more likely for the Fighters mentioned above. Further, I found a 30 lb AC isn't stable in FS2K2 with nominal SD's. Nor did scaling it to 80 lbs help. Lighter FS2K2 AC may jitter on the runway unless Roll MoI is increased above the real value. Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
