Re: [Flightgear-devel] c150 low G.
Dave Martin wrote: On Friday 28 October 2005 02:03, Vassilii Khachaturov wrote: In a real gravity-fed Cessna, there are 2 aspects relevant to the engine problems resulting from negative Gs that I was told about by the instructors. One is the fuel flow (tanks/carb/engine intake manifold) and the other is the oil flow that has gravity-induced return of the oil into the sump. If that stops, it's as disastrous as oil leak --- permanent damage can be done. (As opposed to just engine out due to momentary fuel absense which goes away as soon as one pulls back up and the gravity is restored). This is quite true but it only becomes a problem after a few seconds of sustained *negative* G as opposed to zero G. (Some 152 Aerobats have inverted oil systems to prevent this all together). I have more information on the survivability of engines starved of oil but it's probably not relevant here ;) As for the clearing the climb path, I was told to do some gentle S-turns rather than pushing over the nose in order not to screw up the airspeed and hence the time-to-climb calculations, as well as be less nauseating for the passengers (of course, if executed in a properly coordinated matter). We were training in a busy traffic area (EGBE UK) where other aircraft in unexpected places were a regularity. Typically we would make one check before reaching 650' QNH and turning crosswind. The trick to making the check is to leave the trim set to climb and just push forward momentarily while scanning ahead for anything resembling your own aircraft. Typically, aircraft would re-stabilise in its nominal climb in 10 seconds or so - not an issue when climbing for the training circuit. I can quite safely say that while you would have 'your heart in your mouth' as you pushed forward, it was certainly not even a zero-G motion and the engine certainly wouldn't waiver. Also, in low-G manouvers such as a high-AoA entry to an incipient spin or a 0-G pushover where very low positive G (certainly lower than 0.3G) is sustained for maybe 2 to 3 seconds, the engine would behave as in the cruise. Having flown the manouvers during PPL training (not required but none the less useful) I am adamant that the IO-200 will experience no power-loss down to a small fraction of a G even when sustained for several seconds. Thanks for the feedback, I'll change that. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 low G.
..one check before reaching 650' QNH and turning crosswind. Just re-read my mail this-morning. Worryingly, thats not the first time I've confused QNH and QFE. Hmm, I don't remember the ground being *that* close in the circuit. ;) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jpeg-factory in simgear and flightgear
Am Thursday 27 October 2005 16:55 schrieb Curtis L. Olson: Oliver Schroeder wrote: Hi list. I just stumbled over the jpeg-factory again. Simgear defaults to build with jpeg factory enabled, while flightgear defaults to build without it. So one either has to supply --without-jpeg-factory to simgears configure or --with-jpeg-factory to flightgears. This should be harmonised. I experienced it under Linux and didn't look into it. Maybe the defaults are correctly set under other environments. I believe the defaults are correctly set to both build without, but once you build and install simgear with it, the header file is installed so flightgear autodetects it. If you later build simgear without, that header file will still be installed and flightgear gets confused. You just need to remove the installed simgear header file for jpeg factory and you should be good from that point on. Your are right. Deleting the header file solved this problem. Just for the record, it's $(INLCUDEDIR)/simgear/screen/jpgfactory.hxx regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code
Since this got no bad comments, and since it fixes the bug, I suggest applying the patch. The tread starter, with the patch in there: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039770.html V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code
Vassilii Khachaturov wrote: Since this got no bad comments, and since it fixes the bug, I suggest applying the patch. The tread starter, with the patch in there: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039770.html It's still in my TODO list, hut I wanted to think a bit to see if I can come up with a way to make it work properly. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
Josh, this is what I got with the r200 driver too. I believe it is a problem either in the glx implementation or the dri equivatent of that. May be a gl client lib not fitting exactly together with the server side implementation. Long standing bug. If you get that isolated you may report that at dri-devel. It happens at the time RenderTexture queries visuals. At the time I used the r200, I just worked around by a early hard coded exit in the RenderTexture initialization. Ugly, but worked ... I later hoped that this was fixed by the switch to the standard glX 1.4 pbuffer extensions, but that does not seem to be the case ... Now using fglrx with a newer radeon on that machine. Since that it works fine ... Greetings Mathias On Donnerstag 27 Oktober 2005 23:08, Josh Babcock wrote: OK, I got cvs to compile, but it won't run. Here's the output with export LIBGL_VERBOSE=1 export LIBGL_DEBUG=verbose tower:~$ fgfs --aircraft=c172p libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 Dent: .Dent: ..Dent: CVSDent: EHAMopening file: /usr/local/share/FlightGear/data/Navaids/carrier_nav.dat /usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 31 Current serial number in output stream: 32 Vertex3f: 1 This is using the debian xorg package with the open source radeon driver. glxgears, blender and a host of other OGL software works without a hitch. Any ideas? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] 3D cockpit near plane adjustment
On Donnerstag 27 Oktober 2005 10:41, Erik Hofman wrote: Jim Wilson wrote: Adjusting the near clip plane to 0.10 units (approx 3 inches) is less ambitious, a bit more forgiving for the 3D modelers, and perfectly adequate. This sounds perfectly fine to me. It's committed. And looks even more perfectly to me on my 16 bit 32MB notebook radeon7500 :) Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
Mathias Fröhlich wrote: Josh, this is what I got with the r200 driver too. I believe it is a problem either in the glx implementation or the dri equivatent of that. May be a gl client lib not fitting exactly together with the server side implementation. Long standing bug. If you get that isolated you may report that at dri-devel. It happens at the time RenderTexture queries visuals. At the time I used the r200, I just worked around by a early hard coded exit in the RenderTexture initialization. Ugly, but worked ... I later hoped that this was fixed by the switch to the standard glX 1.4 pbuffer extensions, but that does not seem to be the case ... Now using fglrx with a newer radeon on that machine. Since that it works fine ... Greetings Mathias On Donnerstag 27 Oktober 2005 23:08, Josh Babcock wrote: OK, I got cvs to compile, but it won't run. Here's the output with export LIBGL_VERBOSE=1 export LIBGL_DEBUG=verbose tower:~$ fgfs --aircraft=c172p libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 Dent: .Dent: ..Dent: CVSDent: EHAMopening file: /usr/local/share/FlightGear/data/Navaids/carrier_nav.dat /usr/local/share/FlightGear/data/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 31 Current serial number in output stream: 32 Vertex3f: 1 This is using the debian xorg package with the open source radeon driver. glxgears, blender and a host of other OGL software works without a hitch. Any ideas? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Do you still have that patch around? I would like to play with it. Using fglrx with Debian is extremely painful. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
