RE: [Flightgear-devel] Taildragger takeoff and landing
Lee Elliott wrote Sent: 28 July 2004 21:32 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Taildragger takeoff and landing On Wednesday 28 July 2004 01:45, Andy Ross wrote: Jim Wilson wrote: Have I had this backwards all along? I knew of the incidence angle on the hstab, but always thought that positive values meant the leading edge was higher than with a negative incidence angle The number is a (conventional, right handed) rotation about the Y axis, which in YASim's coordinate system points out the left wingtip. So a positive incidence points down. Unless there's a sign bug (or three, or five...) in there somewhere. And Lee's surprise was right: you *can't* map a control to INCIDENCE in the control mapper. My head was ahead of the implementation. I've definitely intended to do this (and maybe I've worked on it at some point) but looking at CVS the code just ain't there. Sorry. Andy Heh! - I'm still a bit confused:) I had a look at the dc3 update, where the incidence had been set on the hstab but when I tried using it, it made no difference to the solution, and I couldn't detect any change in the behaviour. I was sure that the hstab incidence was set by the solver (as the 'tail incidence') The incidence +- issue threw me as well - like the others, I've been using +ve incidence to angle the wing up at the leading edge. It does seem to work that way though... My 2p on the 'does lift suck or blow', just to stir it up a bit more, is that the Wrights found that the lift was not perpendicular to the wing/aerofoil axis but was angled forward (they attached spring balances to their kites and measured the force required to hold them, and found that this force was lower that they'd calculated). On more refined aerofoils most of the lift comes from the leading edge region, where the acceleration is highest, although some of the more recent 'super-critical' aerofoils produce lift further back. There again, while I'm reasonably up on physics, I'd only claim to understand about 2/3rds of what I read about aerodynamics. Curiously enough, I was only quite recently discussing bow-waves and drag in relation to sprint racing kayaks with someone:) I rather like this explanation of lift. http://www.grc.nasa.gov/WWW/K-12/airplane/bernnew.html Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim strangeness [was Taildragger takeoff and landing]
David Megginson wrote: Andy Ross wrote: Uh... YASim doesn't model wash effects, so there really isn't any process by which a pure control input would generate force. Are you sure you weren't just sitting in a stiff wind? Can anyone else replicate this? I cannot reproduce it on my system: fgfs [EMAIL PROTECTED] --aircraft=j3cub I put on the parking brake (who'd have thought the J3 Cub had a parking brake?) and tried moving all of the control surfaces. They had no effect on the aircraft, either with the engine on or with the engine off. Then maybe wind has crept in there somehow... I'll check tonight. All the best, Matthew ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoffs and landings
Dave Perry wrote: Sent: 29 July 2004 01:48 To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Taildragger takeoffs and landings David Megginson wrote: This problem has little effect on normal flight, but it matters a lot for the landing and takeoff rolls of taildraggers -- without it, they have an unrealistic tendency to nose over. I have been tied up with an upgrade to SuSe 9.1 and wanted to comment on the tail dragger set up discussion. 1. I updated CVS last night and the changes to the J3 Cub make it impossible to do a full-stall 3 point landing. 2. It is not true that a wheel landing should end with applying full down elevator. In fact, you want to be almost at zero decent rate when the mains touch and then a little forward pressure is usually required to keep the immediate slight increase in angle of attach from putting you back in the air, since you have not yet stalled. 3. In a real cub, it takes very little relative wind to keep the tail up. So in a head wind of say 10 knots, you can lift the tail with forward pressure as soon as you apply power. I have seen pilots hold the brakes, apply power and lift the tail at zero ground speed. I really thought the way the cub was in fgfs before these changes was very realistic. I would do 4 touch and goes in the length of 29R at KSFO with all of them wheel landings. Were you really having trouble with nose overs with the cub? I have real hours hours in Stinson 108 Voyager, Taylorcraft (almost identical to the cub), Cessna 140 and 170, Luscome Silverair, Citabra, Champ, and probably other tail draggers that I have forgotten. Also, even though it is usual to have the CG slightly ahead of the wing center of lift so the tail plane is providing negative lift in level flight, many aircraft when fully loaded have the tail plane providing some positive lift. I flew my Comanche 250 from Denver to Duluth, MN, on to DSM, and back to Denver with 4 passengers and baggage to the point that I only could fill the inboards to stay below 2900 lbs (max gross). The trim was very much different at all speeds. With just two in the front seats and no baggage, the trim for approach is much more up elevator trim than at cruise (tail plane has negative lift). But fully loaded, the trim changes very little as you slow up for approach. This could be because the CG is more aft fully loaded, so the tail plane is carrying some of the load. I have never been totally happy with the DC3 ground handling. It has always been too slow on acceleration in bringing the tail up and it would try and fly with the tail still on the ground and if you tried to get the tail up with forward pressure, it was way too easy to get in a porpoise. Moving the CG as far forward as possible helped and increasing the horizontal stab effectiveness also helped. I had also made the length longer. The real DC3 tail came up very quickly, very similar to the cub in reality. I have not flown the fgfs DC3 since the recent changes. I will try it and then comment some more. Good discussion, Have you tried the Spitfire yet? I would be grateful for any comments you might have. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon S Berndt wrote: On Wed, 28 Jul 2004 23:55:09 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon S Berndt wrote: That's because it's _mostly_ (or entirely) the sucking action above the wing that contributes the most to lift. No, that is the *result* of lift, not the *cause*. No, you're mixing up cause and effect. I have been thinking about this over night and think I agree with you here. I've been biased be a comment a teacher (which I respected much) once told me but which after thinking about it some more is unrelated to this subject. BTW. My comment about the non-existence of pulling forces come from the same issue. Without the existence of pulling forces adhesive and cohesive forces wouldn't even exist. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --version parameter to fgfs
Jim Wilson wrote: There are no pre-release tags, but you could probably do a cvs checkout by date if you wanted to be sure. yes, thanks for that - actually, that's also what I've come up with in the meantime, just checked the 1.11 revision out ... but a compressed download of the entire directory structure would certainly have been faster :-) Also there is -of course- quite a lot of CVS related stuff in the checkout. A couple of minutes ago I created the patch, don't know if it works though, as I don't have the actual pre2-release installed locally, will need to wait for feedback - posted the link to the users mailing list. This link to a cvs log shows the date/time that pre2 was finalized: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/version?cvsroot=FlightGear-0.9 Note that this log happens to refer to the file that contains the version number. It's called version and is located in the base package directory. Yes, sure - I did see that file (and also checked its contents) when I looked for version information about the base package, but it states only 0.9.4 - this even though I am _definitely_ using 0.9.5 *PRE*, so having at least the exact version information of the base package available would certainly make sense-including details about PRE-releases etc. But then, also not to have to rely on cvs-specific files which would not necessarily be available in a release version and hence won't be suitable to determine the base package version in general. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon Berndt wrote: One more thing: think of a baseball or better yet a lightweight ball. How do those things curve? I wouldn't know. I haven't thought about that one yet. My first impression would be that of the cohesive and adhesive forces again. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Tony Peden wrote: I hope you guys realize that this is an ages old debate that still goes on in the relevant academic circles. Yes. There is nothing wrong with fixing this for once and for all isn't there? :-D Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Jim Wilson wrote: Curtis L. Olson said: Sounds fine, I wasn't planning on rolling out the official release today anyway. Tomorrow is probably the earliest ... more likely friday. Just a heads up: there is a minor (as in easy to fix) issue with building SimGear using gcc 2.96 that was introduced earlier today. I emailed Erik about it. Which should be fixed by now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
Chris Metzler wrote: Josh sent me along a few screenshots to illustrate the ground poly bugginess he's seeing near airports. They can be found at: http://www.speakeasy.net/~cmetzler/fgfs-screen-002.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-003.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-004.jpg Weird stuff. What airports are these? There's a similar, but much less severe problem at the end of runway 14/32 at Leeds/Bradford (EGNM). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] create craters and smoke effect
CHANDRASEKHAR ACHALLA wrote: I was also wondering if flightgear already has the fire and smoke effects. Regarding my last reply on that topic I had a quick look at sourceforge for the specific name of the project that I mentioned. It's named FlightGear CombatZone - but, well that specific project is already pretty old and doesn't have any files published, nor does it have a real webpage: https://sourceforge.net/projects/fgcombatzone/ But on the other hand there are plenty of other opensource projects which already do what you seem to need, the first coming to my mind would be bzflag - a tank (combat) simulation which is also based on SimGear and makes already use of things like explosions, fire, smoke and collision detection: https://sourceforge.net/projects/bzflag/ I did some quick searches for other 3D projects in that category, but I think it would probably be really the easiest to look into the bzflag sources, on the one hand because that stuff is already SimGear based and hence it would probably be pretty straight forward to borrow some lines/fragments of code, and on the other hand bzflag has also an _incredibly large_ user AND *DEVELOPER* ( 50 !)community, so odds are good that your questions are answered pretty soon. If bzflag alone is not sufficient already, here are some other opensource projects that might be useful for your purposes and which can be easily found at sourceforge, while some of these don't yet have any files/source released, contacting the developers might help you anyways: __ 3D FX Function library is a set of functions that will make your programming life much easier. Already featuring lensflares, particle systems, explosions, etc, we hope to port to as many languages as possible. https://sourceforge.net/projects/dbdev/ An explosion simulator for 3D real time applications https://sourceforge.net/projects/explosion/ This project is a 3D engine developed in opengl. We want to develope a tool box with allows everyone to program 3D-demos using easy XML script. We need to program animation of 3d objects, humanoides, particle simulations, 2D/3D effects, transitions,... https://sourceforge.net/projects/cymagine/ VRGL, is a modified OpenGL runtime library for visual effects useful in virtual reality applications. It is intended for use with precompiled 3D graphics engines, like the one in Unreal Tournament 2003. https://sourceforge.net/projects/vrgl/ An OpenGL Framework to build graphic effects and demos. Focuses on speed and performance rather than compatibility and portability. Currently based on OpenGL, the framework is meant to support software rendering in the future. https://sourceforge.net/projects/glsilent/ C++ 3D graphics library for game developers, researchers, and students. It is a base of robust and high performance code common to most 3D projects. https://sourceforge.net/projects/g3d-cpp/ FreeSOLID is a library for collision detection of three-dimensional objects undergoing rigid motion and deformation. FreeSOLID is designed to be used in interactive 3D graphics applications. https://sourceforge.net/projects/freesolid/ OpenDynamics is a real-time 3D physics simulation core including collision resolution. A C library, it consists of modules providing linear algebra, newtonian dynamics, collision and contact resolution, some constraints, aerodynamics and explosions. https://sourceforge.net/projects/opendynamics/ The Phoenix Open Source Flight Simulator project is designed to create the ultimate base for combat flight simulators. Every piece will be designed as modular as possible allowing component switching and a great opportunity for community development. https://sourceforge.net/projects/phoenixosfs/ The Combat Simulator Project is an open source project started by flight sim enthusiasts eager for a serious hardcore flight simulator. https://sourceforge.net/projects/csp/ G3C provides the main features for 3D-game developers: 3D rendering engine based on openGL, collision detection, physical rules, p2p network... A game-sample will be avaible, binding a wargame, a flight simulator, a first person shooter, a MMOG... https://sourceforge.net/projects/g3c/ This library is an effort to provide a collision detection library for generic polyhedra. Its purpose is mainly for 3D games where accurate detection is needed between two non-simple objects. https://sourceforge.net/projects/coldet/ Interactive Dynamics Library - Indy C++ library for rigid body dynamics, specifically aimed at games. Project will hopefully support full collision detection, collision and contact resolving, springs, constraints, etc. https://sourceforge.net/projects/indy/ 3D Engine featuring : Particles systems, hierarchical animation, portal rendering, collision detection via BSPs, ISOSurfaces managing, NURBS, animated
Re: [Flightgear-devel] lights flaring on runways in FG
On Thu, 29 Jul 2004 00:08:31 -0400 Josh Babcock [EMAIL PROTECTED] wrote: Moving just a few inches any direction or changing the view angle makes these things change wildly, or even go away. In fact, in the right spot they will flicker on and off. They only seem to appear when I am over an airport. There is also a poly in the dc3 model that does this no matter where I am. It always shows up from inside the cockpit as a bright orange vertical stripe on the left side of the windscreen. It looks texture mapped. I have to position the view angle just right to see it. Hmm. I see various problems at various airports, including these two, such as tears along seams in the terrain -- like there's an abrupt jump in ground elevation without any effort to connect the two levels -- but they typically aren't severe, no more than a meter or so vertically, and I don't see polygons up in the air. And I don't see any problem with the DC-3. I want to say that this is something odd about your drivers, but I'm too ignorant of this stuff to be sure. Is it only ATI people that see this stuff? Do all ATI people see this stuff -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpEQUpZX6kGQ.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
Chris Metzler wrote: On Thu, 29 Jul 2004 00:08:31 -0400 Josh Babcock [EMAIL PROTECTED] wrote: Moving just a few inches any direction or changing the view angle makes these things change wildly, or even go away. In fact, in the right spot they will flicker on and off. They only seem to appear when I am over an airport. There is also a poly in the dc3 model that does this no matter where I am. It always shows up from inside the cockpit as a bright orange vertical stripe on the left side of the windscreen. It looks texture mapped. I have to position the view angle just right to see it. Hmm. I see various problems at various airports, including these two, such as tears along seams in the terrain -- like there's an abrupt jump in ground elevation without any effort to connect the two levels -- but they typically aren't severe, no more than a meter or so vertically, and I don't see polygons up in the air. And I don't see any problem with the DC-3. I want to say that this is something odd about your drivers, but I'm too ignorant of this stuff to be sure. Is it only ATI people that see this stuff? Do all ATI people see this stuff The problem at EGNM I mentioned is on several NVidia based systems. As I said though - it's nowhere near as severe as in those screenshots. I'll try and grab an example tonight. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Erik Hofman said: Jim Wilson wrote: Curtis L. Olson said: Sounds fine, I wasn't planning on rolling out the official release today anyway. Tomorrow is probably the earliest ... more likely friday. Just a heads up: there is a minor (as in easy to fix) issue with building SimGear using gcc 2.96 that was introduced earlier today. I emailed Erik about it. Which should be fixed by now. It is. Thanks! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
Chris Metzler wrote: On Thu, 29 Jul 2004 00:08:31 -0400 And I don't see any problem with the DC-3. I want to say that this is something odd about your drivers, but I'm too ignorant of this stuff to be sure. Is it only ATI people that see this stuff? Do all ATI people see this stuff Personally, I would say that while there do seem to be some issues specific to ATI cards, I cannot complain in general as the overall performance seems a lot better than using a better card, regarding ATI I've come to the conclusion that it's just a matter of disabling the right options to reduce the problems (like the mentioned lack of updates in specific parts of the client area) and to make the whole situation bearable. On the ATI issues I am going to download some other plib applications in order to specifically look out for similar problems but also performance, maybe it's really not that much related to FlightGear itself but rather plib ? That would at least make sense if I don't find _any_ plib app where I achieve more than 10-15 FPS with the nvidia card ;-) Regarding the idea to profile the openGL specific parts of FlightGear I have to say that I did download the mentioned software but to be honest: I wouldn't have the slightest clue about what to look for, so the best thing I could possibly offer is to log everything and make the logs available - but the evaluation of these logs would probably be a totally diffferent issue :-/ On the other hand I had a closer look at this openGL logging application and I think one might attempt to get representative results by adding the functionality to FlightGear itself (a debugging version) and try to run some basic flight data replay (or something similar to utilize openGL for a specific amount of time which should be available in all versions) on as many machines as possible. Maybe one could then find essential differences by comparing the collected logs ? (just guessing) Even though I did personally also consider running other (more performant) Windows openGL applications in order to see in what way they deal differently with the accelerator card, possibly it's really about enabling specific options on some boards ?! Boris P.S.: Sorry Erik for typing more than 5 lines of text :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --version parameter to fgfs
Boris Koenig said: Jim Wilson wrote: There are no pre-release tags, but you could probably do a cvs checkout by date if you wanted to be sure. yes, thanks for that - actually, that's also what I've come up with in the meantime, just checked the 1.11 revision out ... but a compressed download of the entire directory structure would certainly have been faster :-) Also there is -of course- quite a lot of CVS related stuff in the checkout. A couple of minutes ago I created the patch, don't know if it works though, as I don't have the actual pre2-release installed locally, will need to wait for feedback - posted the link to the users mailing list. This link to a cvs log shows the date/time that pre2 was finalized: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/version?cvsroot=FlightGear-0.9 Note that this log happens to refer to the file that contains the version number. It's called version and is located in the base package directory. Yes, sure - I did see that file (and also checked its contents) when I looked for version information about the base package, but it states only 0.9.4 - this even though I am _definitely_ using 0.9.5 *PRE*, so having at least the exact version information of the base package available would certainly make sense-including details about PRE-releases etc. But then, also not to have to rely on cvs-specific files which would not necessarily be available in a release version and hence won't be suitable to determine the base package version in general. That's true. You are probably just too late this time around. It is an interesting idea having release to release patch files, but I am not sure what would be involved. On the subject of versions, if you do not have the correct matching base package version installed then FlightGear should give a message like this: Base package check failed ... Found version 0.9.4 at: ../../Base/fgfsbase Please upgrade to version: 0.9.5-pre3 That is pretty straight forward, so I doubt you are seeing a mismatch. I suppose if somehow you had an issue with autoconf (the version number for the program is set in configure.ac)... This wouldn't make much sense. Why don't you experiment a little (look at your configuration, etc) and maybe even change the number in the version file to see if you get the message. Perhaps there is a bug there. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] lights flaring on runways in FG
Boris Koenig writes: That would at least make sense if I don't find _any_ plib app where I achieve more than 10-15 FPS with the nvidia card ;-) I have many PLib applications that run at a rock steady 70hz, my screen refresh rate, on a NVIDIA GeForce 2 in a PIII 733 On the other hand I had a closer look at this openGL logging application and I think one might attempt to get representative results by adding the functionality to FlightGear itself Low level OpenGL logging is already built into FlightGear but you need to hard-compile it in. There are no instructions other then the source code as if one can't read the code then one has no reason to have this capability as they certainly won't understand the resulting output :-) possibly it's really about enabling specific options on some boards ?! !!! it's about *disenabling* specific options on some boards !!! Yup, there is enough variability in machines that there is no 'one size' fits all. The default settings are a compromise between reasonable performance on most semi modern machines and what the hard core entusiasts want in terms of 'eye candy' One thing non-coders could do that would be useful would be to start collecting these machine specific tips on a web page somewhere like the Wiki . Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
On Thu, 29 Jul 2004 14:04:57 +0100 Jon Stockill [EMAIL PROTECTED] wrote: The problem at EGNM I mentioned is on several NVidia based systems. As I said though - it's nowhere near as severe as in those screenshots. I'll try and grab an example tonight. I'm on an Nvidia card (finally), and what I see at EGNM is this: at the beginning of 14, along the right side of the displaced threshhold, I see a seam where the terrain suddenly jumps up about a meter in elevation, leaving a sky-colored gap between (vertical, thus only visible from one side). Is this what you see? If so, I see that sort of thing too, near most large airports. I suspect it's not a FlightGear thing so much as a TerraGear thing -- I suspect it's an artifact of the smoothing done in making things flat for the runways etc. But I dunno. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpC3OHditdGT.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
Chris Metzler wrote: On Thu, 29 Jul 2004 14:04:57 +0100 Jon Stockill [EMAIL PROTECTED] wrote: The problem at EGNM I mentioned is on several NVidia based systems. As I said though - it's nowhere near as severe as in those screenshots. I'll try and grab an example tonight. I'm on an Nvidia card (finally), and what I see at EGNM is this: at the beginning of 14, along the right side of the displaced threshhold, I see a seam where the terrain suddenly jumps up about a meter in elevation, leaving a sky-colored gap between (vertical, thus only visible from one side). Is this what you see? If so, I see that sort of thing too, near most large airports. I suspect it's not a FlightGear thing so much as a TerraGear thing -- I suspect it's an artifact of the smoothing done in making things flat for the runways etc. But I dunno. Yes - that's it. I can't remember the exact relative positioning in the sim, but in real life that's about the point where the road disappears under the end of the runway. Could that be the cause? ISTR a similar problem at RAF Finningley (EGXI) where a railway crosses the end of the runway (it should be just on the boundary of the airfield, but the VMAP and/or airfield accuracy cause an overlap. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Erik Hofman said: Jon Berndt wrote: One more thing: think of a baseball or better yet a lightweight ball. How do those things curve? I wouldn't know. I haven't thought about that one yet. My first impression would be that of the cohesive and adhesive forces again. Well Jim's make it up as you go along Physics manual says that there is greater pressure against the air molecules in front of the moving ball. Thus there is greater friction against those molecules than the air molecules to the side or behind. If the ball has a sidespin, then the slightly better traction (friction) on the front side will cause the ball to move in the direction opposite that of the forward surface of the spinning ball (as a result of something Newton said). Adding this sideways movement to the ball's trajectory produces a curve. The ball's momentum (speed), air density, size of the ball (amount trailing air turbulance), alignment of the planets, proximity to Fenway park, political persuasion, and the rate of spin will affect outcome. For a demonstration (or proof that I am wrong) see: http://www.grc.nasa.gov/WWW/K-12/airplane/foil2b.html Disclaimer: Use this information at your own risk. I will not be responsible for any broken noses, windows, or egos that result from the application of this theory. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --version parameter to fgfs
Jim Wilson wrote: Boris Koenig said: But then, also not to have to rely on cvs-specific files which would not necessarily be available in a release version and hence won't be suitable to determine the base package version in general. That's true. You are probably just too late this time around. Well, to be honest - that was NOT my idea, I just also thought the idea would be pretty good and didn't mind to create the requested patch. The actual idea and patch-script come from Stewart Andreason on the users mailing list: His current patch script requires a (to be patched) version of the FlightGear base root directory and an archive with an updated version of that directory tree. It then creates a diff of these two trees and that diff tree is then packaged into an archive - so you would normally only have to untar that said diffed archive into your old base package in order to obtain a recent base package. While the script itself looks pretty good and does seem to work, there are some minor things that could be improved, like being able to either use another directory/archive as source/target. Also, it doesn't yet seem to take those files/folders properly into account which need to be removed/replaced from the old release. It is an interesting idea having release to release patch files, but I am not sure what would be involved. Yes it could indeed turn out to be quite useful in general, one of the easier ideas would be to have checksums for each file/folder and simply store these checksums within a specific file in FlightGear's data root directory. This checksum file would then contain each folder/file (absolute position) with the appropriate checksum. A simple syntax might already be sufficient: file:/data/aircraft/whatever.xml chk:0f32e4f8a97c (optionally also file size) One would then use a shell script to take care of all changes within the CVS, either that script is executed automatically after each commit - or it is run by cron job. It would then simply create a detailed checksum list for each revision. In order to update a release the patch script would merely have to compare the local (old) copy of the checksums file with the latest version of the base package, that way it could track down all necessary changes. So, in order to create a patch file one would mainly need to: - download specific files from cvs - remove/replace specific files Basically, one would execute a stripped down cvs update - but of course this could also be web-based or use the viewcgi perl script to retrieve the files from CVS. So, all (new/changed) downloaded files would then be put into a corresponding patch archive. Additionally that script should take two other things into consideration, 1) all files/directories that should NOT be put into the release patch (i.e. CVS stuff) 2) also those files/folders that don't reside in the data repository, but also need to be updated/packaged into new base releases (the documentation/manuals would be such a case, cause they are stored separately). -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Thu, 29 Jul 2004 15:01:28 - Jim Wilson [EMAIL PROTECTED] wrote: Jon Berndt wrote: One more thing: think of a baseball or better yet a lightweight ball. How do those things curve? Well Jim's make it up as you go along Physics manual says that there is greater pressure against the air molecules in front of the moving ball. ... etc. Strike 1. Hint: If the curve ball is spinning about a vertical axis, what does this say about the flow of air on the left and right sides of the ball? Here's the windup ... and the pitch ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
Jon Stockill wrote: Chris Metzler wrote: On Thu, 29 Jul 2004 14:04:57 +0100 Jon Stockill [EMAIL PROTECTED] wrote: The problem at EGNM I mentioned is on several NVidia based systems. As I said though - it's nowhere near as severe as in those screenshots. I'll try and grab an example tonight. I'm on an Nvidia card (finally), and what I see at EGNM is this: at the beginning of 14, along the right side of the displaced threshhold, I see a seam where the terrain suddenly jumps up about a meter in elevation, leaving a sky-colored gap between (vertical, thus only visible from one side). Is this what you see? If so, I see that sort of thing too, near most large airports. I suspect it's not a FlightGear thing so much as a TerraGear thing -- I suspect it's an artifact of the smoothing done in making things flat for the runways etc. But I dunno. Yes - that's it. I can't remember the exact relative positioning in the sim, but in real life that's about the point where the road disappears under the end of the runway. Could that be the cause? ISTR a similar problem at RAF Finningley (EGXI) where a railway crosses the end of the runway (it should be just on the boundary of the airfield, but the VMAP and/or airfield accuracy cause an overlap. At least one of my screenshots (KADW) had no roads involved. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon S Berndt wrote: On Thu, 29 Jul 2004 15:01:28 - Jim Wilson [EMAIL PROTECTED] wrote: Jon Berndt wrote: One more thing: think of a baseball or better yet a lightweight ball. How do those things curve? Well Jim's make it up as you go along Physics manual says that there is greater pressure against the air molecules in front of the moving ball. ... etc. Strike 1. Hint: If the curve ball is spinning about a vertical axis, what does this say about the flow of air on the left and right sides of the ball? Here's the windup ... and the pitch ... Ok, then how do you explain a frisbee that can curve either way, even though it's always thrown with the same direction of spin. And please include the coriolis effect in your explanation (now that it is implimented in JSBSim.) Thank you. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Thu, 29 Jul 2004 10:34:16 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Ok, then how do you explain a frisbee that can curve either way, even though it's always thrown with the same direction of spin. And please include the coriolis effect in your explanation (now that it is implimented in JSBSim.) Thank you. :-) Gyroscopic stabilization and tilt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] lights flaring on runways in FG
Jon Stockill wrote Sent: 29 July 2004 14:05 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] lights flaring on runways in FG Chris Metzler wrote: On Thu, 29 Jul 2004 00:08:31 -0400 Josh Babcock [EMAIL PROTECTED] wrote: Moving just a few inches any direction or changing the view angle makes these things change wildly, or even go away. In fact, in the right spot they will flicker on and off. They only seem to appear when I am over an airport. There is also a poly in the dc3 model that does this no matter where I am. It always shows up from inside the cockpit as a bright orange vertical stripe on the left side of the windscreen. It looks texture mapped. I have to position the view angle just right to see it. Hmm. I see various problems at various airports, including these two, such as tears along seams in the terrain -- like there's an abrupt jump in ground elevation without any effort to connect the two levels -- but they typically aren't severe, no more than a meter or so vertically, and I don't see polygons up in the air. And I don't see any problem with the DC-3. I want to say that this is something odd about your drivers, but I'm too ignorant of this stuff to be sure. Is it only ATI people that see this stuff? Do all ATI people see this stuff The problem at EGNM I mentioned is on several NVidia based systems. As I said though - it's nowhere near as severe as in those screenshots. I'll try and grab an example tonight. There are some problems of levels over at EGMH (Manston). Much improved aver previous scenery releases though. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon S Berndt wrote: On Thu, 29 Jul 2004 10:34:16 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Ok, then how do you explain a frisbee that can curve either way, even though it's always thrown with the same direction of spin. And please include the coriolis effect in your explanation (now that it is implimented in JSBSim.) Thank you. :-) Gyroscopic stabilization and tilt. Which gets us to the one milion dollar question: Can you frisbee on mars? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Erik Hofman wrote: Jon S Berndt wrote: On Thu, 29 Jul 2004 10:34:16 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Ok, then how do you explain a frisbee that can curve either way, even though it's always thrown with the same direction of spin. And please include the coriolis effect in your explanation (now that it is implimented in JSBSim.) Thank you. :-) Gyroscopic stabilization and tilt. Which gets us to the one milion dollar question: Can you frisbee on mars? You can, but south of the equator it will break the opposite direction. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Curtis L. Olson wrote: Erik Hofman wrote: Jon S Berndt wrote: On Thu, 29 Jul 2004 10:34:16 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Ok, then how do you explain a frisbee that can curve either way, even though it's always thrown with the same direction of spin. And please include the coriolis effect in your explanation (now that it is implimented in JSBSim.) Thank you. :-) Gyroscopic stabilization and tilt. Which gets us to the one milion dollar question: Can you frisbee on mars? You can, but south of the equator it will break the opposite direction. I like it when people share their valuable experiences ... :-) So, the next time I'm there I'll be careful ! Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Curtis L. Olson wrote: Erik Hofman wrote: Jon S Berndt wrote: On Thu, 29 Jul 2004 10:34:16 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Ok, then how do you explain a frisbee that can curve either way, even though it's always thrown with the same direction of spin. And please include the coriolis effect in your explanation (now that it is implimented in JSBSim.) Thank you. :-) Gyroscopic stabilization and tilt. Which gets us to the one milion dollar question: Can you frisbee on mars? You can, but south of the equator it will break the opposite direction. It must be a great sight, the first man on Mars playing frisbee with a colleague. Erik (Now I start to wonder why we always smash our probes on the surface of Mars). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Thu, 29 Jul 2004 19:37:08 +0200 Boris Koenig [EMAIL PROTECTED] wrote: I like it when people share their valuable experiences ... :-) So, the next time I'm there I'll be careful ! Why? You won't hit anything! :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Thu, 29 Jul 2004 19:38:44 +0200 Erik Hofman [EMAIL PROTECTED] wrote: (Now I start to wonder why we always smash our probes on the surface of Mars). NASA does it by design. (Well ... except for the Mars Polar Lander.) :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Segmentation Fault: (was Re: [Flightgear-devel] Ready for next release?)
Hmm, I hate to spoil the party, but I did get a segmentation fault in FlightGear today (running 0.9.5-pre3). I'm not sure when it happened, since I started FlightGear this morning and letting it fly between KSFO and EHAM (which appears to become my favorite test route :-)), while I went off to work. The crash happened somewhere in around 63-degs North and 84-west, based on the console output from terrasync., so that was probably after about 4 or 5 hours of running. Unfortunatly, being in a hurry this morning I didn't run flightgear from within gdb, so I don't have any idea yet what might have caused it. I do seem to see these kind of chrashes more with the 747 (yasim) than with any of the other jets (jsbsim) I've tried, but that's only a working hypothesis for now. Any Ideas, suggestions? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
On Thursday 29 July 2004 03:06, Chris Metzler wrote: cc'ing this to make sure you see the reply . . . On Sat, 24 Jul 2004 17:07:55 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Lee Elliott replying to Josh Babcock: I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Could you post screenshots ? Josh sent me along a few screenshots to illustrate the ground poly bugginess he's seeing near airports. They can be found at: http://www.speakeasy.net/~cmetzler/fgfs-screen-002.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-003.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-004.jpg Weird stuff. What airports are these? -c That's what I'm seeing too. I notice it on most airfields and I certainly get it at KSFO, and I can see it happening at KOAK and KHAF, in the distance - some these polys get stretched pretty big. I don't think it's an airfield specific thing. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
On Thursday 29 July 2004 05:08, Josh Babcock wrote: Chris Metzler wrote: cc'ing this to make sure you see the reply . . . On Sat, 24 Jul 2004 17:07:55 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Lee Elliott replying to Josh Babcock: I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Could you post screenshots ? Josh sent me along a few screenshots to illustrate the ground poly bugginess he's seeing near airports. They can be found at: http://www.speakeasy.net/~cmetzler/fgfs-screen-002.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-003.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-004.jpg Weird stuff. What airports are these? -c KADW, and two from KONT. I have all the visual bells and whistles turned on except enhanced runway lighting, which also acts really weird (in fact, I think I'll send along some screenies of that too). Latest fglrx drivers on an old Radeon 8500. Kernel 2.4.22, XFree86 4.3.0. Moving just a few inches any direction or changing the view angle makes these things change wildly, or even go away. In fact, in the right spot they will flicker on and off. They only seem to appear when I am over an airport. There is also a poly in the dc3 model that does this no matter where I am. It always shows up from inside the cockpit as a bright orange vertical stripe on the left side of the windscreen. It looks texture mapped. I have to position the view angle just right to see it. Josh Ah - there's a slight difference - I get them on distant airfields too. This is on a 9200. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Segmentation Fault: (was Re: [Flightgear-devel] Ready for next release?)
Durk Talsma wrote: Hmm, I hate to spoil the party, but I did get a segmentation fault in FlightGear today (running 0.9.5-pre3). I'm not sure when it happened, since I started FlightGear this morning and letting it fly between KSFO and EHAM (which appears to become my favorite test route :-)), while I went off to work. The crash happened somewhere in around 63-degs North and 84-west, based on the console output from terrasync., so that was probably after about 4 or 5 hours of running. Unfortunatly, being in a hurry this morning I didn't run flightgear from within gdb, so I don't have any idea yet what might have caused it. I do seem to see these kind of chrashes more with the 747 (yasim) than with any of the other jets (jsbsim) I've tried, but that's only a working hypothesis for now. Any Ideas, suggestions? I know the missing files you mentioned earlier spoiled it for me right at startup. They have to be included, otherwise it looks really bad on FlightGear. Could you explain which files are missing exactly? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Segmentation Fault: (was Re: [Flightgear-devel] Ready for next release?)
Yes, the following files were missing. Curt wrote me yesterday that he had missed them somehow while updating from cvs, but that he has them now and thus be in the final release. The segfault I'm getting is not related to these missing files though, because that would only give a problem during initialization. Cheers, Durk Traffic/KLM/MD11/PH-KCA.xml Traffic/KLM/MD11/PH-KCB.xml Traffic/KLM/MD11/PH-KCC.xml Traffic/KLM/MD11/PH-KCD.xml Traffic/KLM/MD11/PH-KCE.xml Traffic/KLM/MD11/PH-KCF.xml Traffic/KLM/MD11/PH-KCG.xml Traffic/KLM/MD11/MD11.xml Traffic/KLM/KLM.xml Traffic/UAL/737/N388UA.xml Traffic/UAL/737/N376UA.xml Traffic/UAL/737/N377UA.xml Traffic/UAL/737/N390UA.xml Traffic/UAL/737/737.xml Traffic/UAL/UAL.xml Traffic/fgtraffic.xml On Thursday 29 July 2004 20:53, Erik Hofman wrote: I know the missing files you mentioned earlier spoiled it for me right at startup. They have to be included, otherwise it looks really bad on FlightGear. Could you explain which files are missing exactly? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgfs aborted with the dc3
Jim Wilson wrote: Run with --log-level=debug to see which SubSystem that occurs in. Could be an xml bug. I did. Here is where it aborts: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to -2.67116ft... ...initializing sea-level radius... lat = 37.6135 alt = -2.67116 ...initializing velocities... ...initializing Euler angles... End common FDM init Aborted Here is how I launched it. ./bin/fgfs --aircraft=dc3 --log-level=debug Dave P. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Dave Perry wrote: End common FDM init Aborted Here is how I launched it. XML parse errors in YASim files become aborts. I'd look very carefully at your dc3.xml file and make sure it doesn't contain extraneous information (cvs collision warnings, etc...) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
On Thu, 29 Jul 2004 16:47:19 -0700 Andy Ross [EMAIL PROTECTED] wrote: Dave Perry wrote: End common FDM init Aborted Here is how I launched it. XML parse errors in YASim files become aborts. I'd look very carefully at your dc3.xml file and make sure it doesn't contain extraneous information (cvs collision warnings, etc...) FWIW, with today's CVS I couldn't reproduce this. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpX2ZXV669Pu.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Taildragger takeoffs and landings
Vivian Meazza wrote; /Have you tried the Spitfire yet? // //I would be grateful for any comments you might have. // // // /I had flown it for the first time last night, but mostly at altitude. Very maneuverable and feels like a high performance ac wrt aileron - rudder coordination. Since this thread is about ground handling with a tail dragger, I flew it tonight to see how it was to do takeoffs and landings. The mains are longer and closer together than most modern ac, so it should not be easy. After several takeoffs with the tail locked that were near ground loops, I decided to try it with the tail wheel unlocked so I would get more early feedback on the correct rudder inputs. Actually, this made my takeoffs much better as I was moving the rudder early to keep the nose straight. In a real tail dragger, you have the rudder moving early and often until the tail is up and you are fast enough to be near takeoff. This went so well that I made several passes of touch and goes. It does a real nice full stall landing and with the tail castering, I was able to apply power and keep it straight through takeoff. After about 6 touch-n-goes with no ground loop, I felt quite comfortable. I did notice that it has a tendency to drop a wing at low speeds. This is made worse by the long main gear if you start to yaw on takeoff. But this is what I would expect from the gear torque in a yaw on the ground. I really enjoy this ac and will be flying a lot more. It is a challenge! And having the CH pedals with proportional brakes makes it more reasonable. I would not like to use the twist of a joystick for rudder with so much challenge. Thanks for making this great addition to fgfs! Dave P. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
