Re: [Flightgear-devel] Compile prob, can't find the broken lib
Josh Babcock wrote: /usr/local/include/AL/alut.h:17:21: error: altypes.h: No such file or directory Huh, is there any chance you have two versions of the header files installed? Do I just need to get the CVS version and compile it? It should not be needed, but it does work. Erik ___ 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
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. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 feedback
Bohnert Paul wrote: All, When the 150 was statred it was postioned with it's wheels below the runway surface. Adding z-m offset and pitch-deg offset to the c150.xml file places the 150 on the runway surface. PropertyList pathcessna150.ac/path offsets z-m 0.45/z-m pitch-deg 2.0/pitch-deg /offsets texture-pathVintage/texture-path Moving the model up caused the pilot view to be too low. In c150-set.xml adding 0.45 to the y-offset-m corrected the pilot view. view internal archive=ytrue/internal config x-offset-m archive=y-0.25/x-offset-m y-offset-m archive=y0.81/y-offset-m z-offset-m archive=y2.30/z-offset-m pitch-offset-deg-10/pitch-offset-deg /config /view Thanks all for the work on the 150. Paul B You should try the lastest cvs version, commited a few days ago. The plane should be above the ground now. Thanks. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] jpeg-factory in simgear and flightgear
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. regards, Oliver. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] MSVC7.1 CVS Oct 25 - 2 compile errors
Hi, My CVS update of Oct 25 pulled in lots of 'changed' files, and had two problems with the compiles. They were simple fixes ... SG/source - fastmath.cxx Had to put the include of fastmath.hxx in front of #include simgear/constants.h, since constants.h also sucks in math.h ... through compiler.h ... fastmath.hxx correctly defines _USE_MATH_DEFINES, under a _MSC_VER switch, before including math.h, which works fine ... This is to define a value for M_LN2 ... this error has come and gone, over YEARS ... sometimes I would just drop in a define ... FG/source - tacan.cxx I made this fix some weeks back, but forgot to mention it ... Talk about a 'sanity check' ... the line MSVC dies on or about line 368 - if (frequency_khz 9620 and frequency_khz = 12130)return frequency_khz/100; I added the following - #ifdef _MSC_VER if (frequency_khz 9620 frequency_khz = 12130)return frequency_khz/100; #else // !#ifdef _MSC_VER if (frequency_khz 9620 and frequency_khz = 12130)return frequency_khz/100; #endif // #ifdef _MSC_VER y/n but maybe the author, Vivian, would not mind using '', instead of 'and' ;=)) Assume gcc compiler accepts '', as well as 'and' ... FG/data Lots of new files, that I had read about here ... On running FG, it exited, with the last few console messages - Adding subsystem lighting Initializing OpenAL sound manager Audio initialization failed! Adding subsystem fx ATC Display ATC Manager WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.atis WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.tower WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.ground WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.approach From file sounds sample = C:/FG0981/FlightGear/data/ATC/default.wav Fatal error: Failed to load wav file. Each of these files exist in the ATC folder ... Abandoning my own OpenAL compile from CVS source, I downloaded some new, mid Oct, OpenAL WIN32 binaries, with windows installer included, removed my hand-built stuff, and bingo, the sound works again ... but still get the above WARNINGS ... from current console output - Adding subsystem lighting Initializing OpenAL sound manager Adding subsystem fx ATC Display ATC Manager WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.atis WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.tower WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.ground WARNING - INVALID type found in C:/FG0981/FlightGear/data/ATC/default.approach From file sounds sample = C:/FG0981/FlightGear/data/ATC/default.wav Opened word data file ATC/default.vce OK... ATC Transmissions Current Unix calendar time = 1130405441 warp = 0 Current GMT = 10/27/2005 9:30:41 ATC Dialog System AI Manager Am at present ignoring these WARNINGS ... but wonder what is the INVALID type found ... and why? OT a little - Obtaining the console output is quite difficult in windows ... you must jump on the [pause] key at the right time, else what you want to see will have scrolled out of my already enlarged console buffer ... I have tried every which way to redirect this output ... with things like log.txt, or 2log.txt 12 ... but NOTHING seems to work ... it seems the sg_log() initialisation undoes the command line redirection? Do other windows users have this problem, or has someone solved how to re-direct the output to a file? As usual, hope this helps ... at least the MSVC, windows users Geoff. EOF _ MyCareer.com.au: Visit the NEW Salary Survey http://www.mycareer.com.au/salary-survey/?s_cid=203697 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Hi, Thanks LeeE (Debian) and Oliver C. (Linux) for your --fog-disable --visability=12 tries ... this is almost, I say ALMOST, enough to get me to switch to a *nix system ;=)) =IF= I had got my no fog, maximum visibility, and disabled clouds, running, one of my next questions would have been - Why is it ALWAYS so dark in the distance? ;=/ This can be at noon, and it is the same all around ... and even if the sun is more over the distance scene, morning or evening, it is ALWAYS rendered black in the distance, except when fog is enabled ... then it is rendered all white ... ;=)) Judging by the size of the 'squares' on the ground, I guess Oliver's image must be from about 4 feet, and when I climb to this height I get a TOTAL BLACK scene below me ... only when I descend does the ground become lighted ... This is with the default visibility, whatever that is, and no fog ... of course, if I set the visibility to 6m, the MAXIMUM I can use without getting a memory ABORT, then looking straight down, the ground is lighted, but the distance is BLACK ... It definitely feels as if the lighting effect is taken from the position of the viewing aircraft, and certainly not from the actual position of the sun ... But, for the moment, I must settle for my windows less memory ;=(( Regards, Geoff. PS: I have put some images on this page - http://geoffmclane.com/fg/fgfs-017.htm since it is quite hard to explain ... It also includes my OpenAL change, and other things ... see separate post ... EOF _ REALESTATE: biggest buy/rent/share listings http://ninemsn.realestate.com.au ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Santa's r[ae]i?ndeer
Erik Hofman Vassilii Khachaturov wrote: Why are the bells commented out in raindeer-sound.xml? They do sound cute. I think it's a leftover from a previous test. It's corrected now. What happened to the poor reindeers' antlers? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Santa's r[ae]i?ndeer
On Thursday 27 October 2005 14:19, Vivian Meazza wrote: What happened to the poor reindeers' antlers? V. I take it you're not aware of Reindeer Service Bulletin 63-11-05 SE 15? The antlers were removed to improve 'engine out' characteristics after the infamous 'Rudolph food-poisoning' incident. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC7.1 CVS Oct 25 - 2 compile errors
Quoting Geoff Air: Hi, My CVS update of Oct 25 pulled in lots of 'changed' files, and had two problems with the compiles. They were simple fixes ... SG/source - fastmath.cxx ... FG/source - tacan.cxx Geoff, I submitted these changes to Erik yesterday evening and he commited then few hours ago. You should cvs update again. -Fred BTW, according to your webpage, we are more or less neighbours now. I am several RER B station farther from Paris. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Santa's r[ae]i?ndeer
Dave Martin wrote: On Thursday 27 October 2005 14:19, Vivian Meazza wrote: What happened to the poor reindeers' antlers? V. I take it you're not aware of Reindeer Service Bulletin 63-11-05 SE 15? The antlers were removed to improve 'engine out' characteristics after the infamous 'Rudolph food-poisoning' incident. Speaking of engine out, I assume everyone has seen this one: http://www.funnyhumor.com/jokes/1158.php 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile prob, can't find the broken lib
Erik Hofman wrote: Josh Babcock wrote: /usr/local/include/AL/alut.h:17:21: error: altypes.h: No such file or directory Huh, is there any chance you have two versions of the header files installed? Do I just need to get the CVS version and compile it? It should not be needed, but it does work. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d How embarrassing, I checked for duplicate libs, but not for duplicate header files. Error messages from /usr/local should have tipped me off. I nixed the local header files and now it is getting past AL just fine. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Santa's r[ae]i?ndeer
On Thu, 2005-10-27 at 14:19 +0100, Vivian Meazza wrote: Erik Hofman Vassilii Khachaturov wrote: Why are the bells commented out in raindeer-sound.xml? They do sound cute. I think it's a leftover from a previous test. It's corrected now. What happened to the poor reindeers' antlers? V. Correct me if I am wrong but isn't there supposed to be eight reindeers? What became of the other four? George Patterson ___ 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
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. 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Santa's r[ae]i?ndeer
On Thursday 27 October 2005 15:18, George Patterson wrote: Correct me if I am wrong but isn't there supposed to be eight reindeers? What became of the other four? George Patterson Cutbacks. The Lapland Reindeer Union fought it but Santa Inc. won in the end. -- 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] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Geoff Air wrote: Hi, Thanks LeeE (Debian) and Oliver C. (Linux) for your --fog-disable --visability=12 tries ... this is almost, I say ALMOST, enough to get me to switch to a *nix system ;=)) =IF= I had got my no fog, maximum visibility, and disabled clouds, running, one of my next questions would have been - Why is it ALWAYS so dark in the distance? ;=/ This can be at noon, and it is the same all around ... and even if the sun is more over the distance scene, morning or evening, it is ALWAYS rendered black in the distance, except when fog is enabled ... then it is rendered all white ... ;=)) Judging by the size of the 'squares' on the ground, I guess Oliver's image must be from about 4 feet, and when I climb to this height I get a TOTAL BLACK scene below me ... only when I descend does the ground become lighted ... This is with the default visibility, whatever that is, and no fog ... of course, if I set the visibility to 6m, the MAXIMUM I can use without getting a memory ABORT, then looking straight down, the ground is lighted, but the distance is BLACK ... It definitely feels as if the lighting effect is taken from the position of the viewing aircraft, and certainly not from the actual position of the sun ... Ok, --disable-fog does *not* disable fog. Try this ;-) cvs -z3 diff -u -- renderer.cxx (in directory F:\dvlp\FG\source\src\Main\) @@ -472,7 +477,9 @@ glEnable( GL_FOG ); glFogi( GL_FOG_MODE, GL_EXP2 ); glFogfv( GL_FOG_COLOR, l-adj_fog_color() ); -} +} else +glDisable( GL_FOG ); + Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 feedback
On Thu, 27 Oct 2005, Harald JOHNSEN wrote: Bohnert Paul wrote: All, When the 150 was statred it was postioned with it's wheels below the runway surface. Adding z-m offset and [snip] You should try the lastest cvs version, commited a few days ago. The plane should be above the ground now. [snip] Harald, I still have problems with a CVS update from this morning. If, say, I appear at KSFO rwy 28R, and then use the Location dialog to reposition to LLBG rwy 3, I get the following (--log-level=info) lines and the model freezes: Deleting a sample Deleting a sample Deleting a sample Deleting a sample Deleting a sample Crash: Attempted to fly under ground. Playing audio after 14.8417 sec: intense ground contact However, if I just start up there, like fgfs --log-level=info --aircraft=c150 --airport=LLBG --runway=3 it works all right. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] recent 737 autopilot change
In the recent 737 autopilot change, we see that the only improvement is the change of the target speet. diff -u -2 -r1.15 -r1.16 --- 737-set.xml 18 Oct 2005 16:32:23 - 1.15 +++ 737-set.xml 27 Oct 2005 08:34:40 - 1.16 @@ -110,5 +110,5 @@ target-altitude-ft type=double4000.0/target-altitude-ft heading-bug-deg type=double283.0/heading-bug-deg -target-speed-kt type=double200.0/target-speed-kt +target-speed-kt type=double165.0/target-speed-kt /settings /autopilot However, I am surprised to see that the target speed is hardwired here. AFAIK, the heavies use different target speeds dependant on the density altitude and aircraft landing weight. I don't know how big the difference can be within the possible range of the allowed landing weights. Can a 737 specialist sched some more light, please? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] c150 low G.
Just been having a muck about with the C150, apart from the low weight due to lack of pilot mass, I've been flying it much like I used to fly the real thing. One thing we used to do on climbout was 'clear ahead', just push the nose down for a moment to check we weren't about to eat another aircraft. When this is done on the FG c150, the engine stutters (FDM program fuel starvation on neg-G?) According to the HUD, it stutters at about +0.30G. In the real aircraft, we could make 0G manouevers that could last for a couple of seconds without the engine missing. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CPU usage issue
Hey all, I have a Windows build of FlightGear, and have recently discovered when the FlightGear window is minimized, the CPU usage jumps up to 100%. Does anyone have any idea why this happens? What can be done to fix this? Thanks, Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] LibGL error
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
[Flightgear-devel] FlightGear CVS compile error
I'm getting these errors while compiling CVS FlightGear, with CVS SimGear. Using gcc version 3.4.1, linux system if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -I/usr/local/include -g -O2 -D_REENTRANT -MT environment_ctrl.o -MD -MP -MF .deps/environment_ctrl.Tpo -c -o environment_ctrl.o environment_ctrl.cxx; \ then mv -f .deps/environment_ctrl.Tpo .deps/environment_ctrl.Po; else rm -f .deps/environment_ctrl.Tpo; exit 1; fi environment_ctrl.cxx: In member function `virtual void FGMetarEnvironmentCtrl::update_metar_properties(const FGMetar*)': environment_ctrl.cxx:608: error: passing `const FGMetar' as `this' argument of `SGMetarVisibility SGMetar::getMinVisibility()' discards qualifiers environment_ctrl.cxx:610: error: passing `const FGMetar' as `this' argument of `SGMetarVisibility SGMetar::getMaxVisibility()' discards qualifiers environment_ctrl.cxx:612: error: passing `const FGMetar' as `this' argument of `SGMetarVisibility* SGMetar::getDirVisibility()' discards qualifiers environment_ctrl.cxx:642: error: passing `const FGMetar' as `this' argument of `std::vectorSGMetarCloud, std::allocatorSGMetarCloud SGMetar::getClouds()' discards qualifiers make[2]: *** [environment_ctrl.o] Error 1 Any Ideas? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] recent 737 autopilot change
On Thursday 27 Oct 2005 20:20, Vassilii Khachaturov wrote: In the recent 737 autopilot change, we see that the only improvement is the change of the target speet. diff -u -2 -r1.15 -r1.16 --- 737-set.xml 18 Oct 2005 16:32:23 - 1.15 +++ 737-set.xml 27 Oct 2005 08:34:40 - 1.16 @@ -110,5 +110,5 @@ target-altitude-ft type=double4000.0/target-altitude-ft heading-bug-deg type=double283.0/heading-bug-deg -target-speed-kt type=double200.0/target-speed-kt +target-speed-kt type=double165.0/target-speed-kt /settings /autopilot However, I am surprised to see that the target speed is hardwired here. AFAIK, the heavies use different target speeds dependant on the density altitude and aircraft landing weight. I don't know how big the difference can be within the possible range of the allowed landing weights. Can a 737 specialist sched some more light, please? V. Hello Vassilii, these aren't 'hardwired' values but defaults. The values declared here, in the aircraft 'set' file create the corresponding nodes in the property tree and their values can be changed using panel instruments, GUIs, the property browser, nasal scripts and the telnet and http interfaces. The file that defines the characteristics of the autopilot is Aircraft/737/Systems/737-autopilot.xml If you have a look at this you'll see that the relevant autopilot PID controllers read their reference values from the property tree nodes holding the values declared in the aircraft 'set' file. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CPU usage issue
On Thursday 27 Oct 2005 20:28, Drew wrote: Hey all, I have a Windows build of FlightGear, and have recently discovered when the FlightGear window is minimized, the CPU usage jumps up to 100%. Does anyone have any idea why this happens? What can be done to fix this? Thanks, Drew Hmm.. when running FG my CPU usage is always at 100% although the total usage is split between user and system utilisation, with user taking the vast majority. I've noticed that if I bump up the anti-aliasing settings to high values I see a much higher system utilisation and lower frame rates, so I could imagine that minimising the FG window could do funny things to the frame rate and skew the user/system ratio. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CPU usage issue
Drew wrote: I have a Windows build of FlightGear, and have recently discovered when the FlightGear window is minimized, the CPU usage jumps up to 100%. Does anyone have any idea why this happens? What can be done to fix this? Didn't this subject come up before? Note that CPU usage is at 100% is neither a bug nor a problem by itself. Do you need more CPU for calculating something else? Are your other applications unresponsive? FlightGear, like most games or real-time simulations, has a frame-based main loop. It calculates a frame, renders it, and then immediately goes back to the start of the loop to render the next one. That keeps the frame rate as high as possible given the resources available. There is currently no provision for throttling the frame rate in situations where the window is minimized, although I suppose that could be done. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CPU usage issue
If you can throttle the frame rate when the window is open, can't it be throttled when it's minimized? When I have the window open, it runs at about 60% utilization, not 100.On 10/27/05, Andy Ross [EMAIL PROTECTED] wrote: Drew wrote: I have a Windows build of FlightGear, and have recently discovered when the FlightGear window is minimized, the CPU usage jumps up to 100%.Does anyone have any idea why this happens?What can be done to fix this?Didn't this subject come up before?Note that CPU usage is at 100%is neither a bug nor a problem by itself.Do you need more CPU forcalculating something else?Are your other applications unresponsive? FlightGear, like most games or real-time simulations, has aframe-based main loop.It calculates a frame, renders it, and thenimmediately goes back to the start of the loop to render the next one.That keeps the frame rate as high as possible given the resources available.There is currently no provision for throttling the frame rate insituations where the window is minimized, although I suppose thatcould be done.Andy___ Flightgear-devel mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] recent 737 autopilot change
On Thursday 27 Oct 2005 20:20, Vassilii Khachaturov wrote: In the recent 737 autopilot change, we see that the only improvement is the change of the target speet. [snip] Hello Vassilii, these aren't 'hardwired' values but defaults. The values declared here, in the aircraft 'set' file create the corresponding nodes in the property tree and their values can be changed using panel instruments, GUIs, the property browser, nasal scripts and the telnet and http interfaces. I certainly understand that one can change the property during runtime; I am definitely guilty of not reading into the aircraft model before righting the original mail in this thread. What is more, is that I missed the data/Aircraft/737/Systems 737-autopilotV4.xml update, where the actually important stuff had happened. I thus assumed that all the cure (in the log message that was common for both the changes) was in changing the above default, and hence inquired! sorry for wasting everybody's time... Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 low G.
When this is done on the FG c150, the engine stutters (FDM program fuel starvation on neg-G?) According to the HUD, it stutters at about +0.30G. In the real aircraft, we could make 0G manouevers that could last for a couple of seconds without the engine missing. 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). I have no clue as to quantitative charasteristics of the two and which one happens first. (Sorry I don't have time for more research at the moment). 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). V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear CVS compile error
I'm getting these errors while compiling CVS FlightGear, with CVS SimGear. ... Please double-check your version of metar.hxx in SimGear. Mine (1.6) has ... Vassilii Thanks Vassilii, that was it. I must have botched my cvs commands earlier. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 low G.
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. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
