Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Thu, 2005-02-24 at 07:03, Jorge Van Hemelryck wrote: On Tue, 22 Feb 2005 11:09:04 + Steve Hosgood wrote: If I just type fgfs or fgfs --disable-sound, all I get is the splash screen and plenty of disk-grinding noises followed by the splash-screen disappearing and the single-word message Killed on stdout. Actually, I've seen the exact same behaviour [...] glxinfo said that direct rendering was enabled, but my fgfs (CVS compile from a few days ago) behaved the same as Steve's. I haven't had a chance to try it with Simon's suggestion (disabling dlists) yet. Simon Hollier's suggestion worked for me! At altitude, I get about 40-60fps with fgfs running fullscreen on a G200. I've not checked when closer to the ground. Meanwhile, I get around 340 fps from glxgears in its default smallscreen startup configuration. I'd hardly have thought that this counted as slow 3D rendering. Which brings us back to try and detect features at runtime ? Is this possible ? At the very least, Simon's suggestion about use-display-list=false should be in the FAQ or possibly have fgfs default to working that way out of the box, and a item under display tuning in the manuals suggest setting it to true under certain circumstances. Auto-detection would be nice too of course. The way things are now, it's a certain first-time-newbie killer, and unlikely to further fgfs's progress. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Thu, 24 Feb 2005 08:03:36 +0100, Jorge wrote in message [EMAIL PROTECTED]: On Tue, 22 Feb 2005 11:09:04 + Steve Hosgood wrote: If I just type fgfs or fgfs --disable-sound, all I get is the splash screen and plenty of disk-grinding noises followed by the splash-screen disappearing and the single-word message Killed on stdout. (I tried the --disable-sound option to try and avoid possible troubles with OpenAL). (...) It does seem that the length of time between the splash-screen appearing and the killed (or aborted) message might be dependant on the amount of RAM (or maybe the amount of swap) available. Actually, I've seen the exact same behaviour, and even managed to see how fast RAM was being filled, by switching to a terminal and using the top command. My system : laptop P4 2.4GHz 1Gb RAM, 800Mb swap ATI Radeon Mobility 9000 ..' lspci -v |grep -A 15 VGA '? (My 9250 on DRI is reported as a 9200 PRO) Mandrake 10.1 Linux kernel 2.6.8.1 xorg 6.7.0, radeon open-source driver When the fgfs process reached 1.8Gb, it got killed by the kernel's out-of-memory killer (I saw it in /var/log/messages afterwards). glxinfo said that direct rendering was enabled, but my fgfs (CVS compile from a few days ago) behaved the same as Steve's. I haven't had a chance to try it with Simon's suggestion (disabling dlists) yet. However, I have managed to make ATI's closed-source fglrx driver work now, and have had a nice increase in the framerate, compared to what I had with the radeon driver on XFree86 4.3.0 (which I had before I switched to xorg). Here's a table to sum up what I have found using different drivers (fgfs figures are for sparse areas, at a reasonable altitude i.e. near the ground or on the ground, and for a default visibility value). without acceleration glxgears ~240fps, fgfs ~1fps XFree86 4.3.0, open-source radeon driver glxgears ~2100fps, fgfs ~5-25fps depending on view direction (?) I usually had to disable specular highlight... xorg 6.7.0, open-source radeon driver glxgears ~2180fps, fgfs ~35-50fps (yay!!) specular highlight enabled All this may point to the fact that the 3D driver is often responsible for these drops in framerate, maybe because of unsupported features that make the driver fall back to indirect rendering. Which brings us back to try and detect features at runtime ? Is this possible ? ..yes, even while booting up the box; for an example, boot a knoppix with ' expert ' on the boot command line. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Total Energy instrument
From: Paul Surgeon [EMAIL PROTECTED] I'm an ASEL pilot (without glider training) but I was of the impression that the variometer was a slightly modified pitot tube connected to a VSI. That sounds about right. As far as I know one can hook up most variometers to any TE probe. The easy non-software thing to do is to hook up a second VSI simulation to the pitot simulation instead of the static simulation. Then, take the VSI instrument and change the artwork to look like a vario and add a second rotation layer. The first rotation layer watches the normal VSI simulation, the second rotation layer watches the new pitot VSI except that it is cumulative to the first and in the other direction. What also differs between some designs which use a TE probe is the inclusion or exclusion of a flask that is used to average the reading out. In the C++, I'd simply copy the altimeter code (which has both data sources) and the VSI code (which has the low pass filter and the like) and merge them into a new function. Other than that, there isn't much coding needed. Are you trying to simulate the aircraft instrument or are you trying to provide the same value as an expensive air data computer would yield ? I'm trying to simulate an aircraft instrument. Do you have all the information you need, or should I ask for help ? From: Dave Culp [EMAIL PROTECTED] From what I've seen from googling this stuff it looks like the TE vario is midway between a standard vario and a netto vario in capability. http://www.borgeltinstruments.com/Gusts.html In flight the pressure at the TE Probe is the sum of the static pressure and the suction produced due to airspeed. At constant airspeed the TE probe acts like a static source and the variometer indicates the rate of change of static pressure converted to equivalent rate of climb or sink. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Total Energy instrument
On Thursday, 24 February 2005 18:49, Alex Perry wrote: The easy non-software thing to do is to hook up a second VSI simulation to the pitot simulation instead of the static simulation. Then, take the VSI instrument and change the artwork to look like a vario and add a second rotation layer. The first rotation layer watches the normal VSI simulation, the second rotation layer watches the new pitot VSI except that it is cumulative to the first and in the other direction. Well I already have most of the artwork done - I just need a valid TE variable to plug into my needle animation. In the C++, I'd simply copy the altimeter code (which has both data sources) and the VSI code (which has the low pass filter and the like) and merge them into a new function. Other than that, there isn't much coding needed. Ok that sounds easy enough. I'll look into that when I reach that stage. Do you have all the information you need, or should I ask for help ? I'll yell for help when I get to the maths part. :) Thanks Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Total Energy instrument - Was Instrument headaches
On Wednesday 23 February 2005 18:51, Paul Surgeon wrote: On Wednesday, 23 February 2005 20:07, Alex Perry wrote: 1. Create a new Variometer instrument module i C++. If I was able to create a Total Energy Tube module it still leaves me without a way to perform calculations and logic that are vario specific. I'm an ASEL pilot (without glider training) but I was of the impression that the variometer was a slightly modified pitot tube connected to a VSI. That sounds about right. As far as I know one can hook up most variometers to any TE probe. However some electronic varios don't use a TE probe but rather a set of pressure transducers. What also differs between some designs which use a TE probe is the inclusion or exclusion of a flask that is used to average the reading out. Are you trying to simulate the aircraft instrument or are you trying to provide the same value as an expensive air data computer would yield ? I'm trying to simulate an aircraft instrument. Paul There are 'Energy Worm' and 'Energy Marker' features that can be enabled in the Hud so it's possible that the data you need is already being calculated. To enable these features set enable_energy_worm and enable_energy_marker to true in the hudladder.xml file for the hud you're using However, I had to comment out a couple of lines in the src code to get it to work every time - sometimes it was on the hud but at other times it was as though it wasn't enabled. The src file to amend is hud_ladr.cxx and I had to comment out the test on ilcanclaw == 1 and it's closing brace. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Building js_demo
I'm trying to build the 0.9.8 js_demo utility under Windows using nmake and I keep getting: fatal error u1035: syntax error : expected ':' or '=' seperator Stop. I'm running nmake from the man directory using [nmake Makefile.in install]. Any ideas? Thanks, Vance ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Scenery Object Database
On Wednesday 23 February 2005 09:48, Erik Hofman wrote: Martin Spott wrote: Cheers, Martin. P.S.: Who created the static B737 and B747 models that are sitting at KSFO ? I think Innis did the 737, but the 747 I wouldn't know. It could be a good time to remove both static planes since the Traffic manager gets quite powerful already. :-) Yes, technically we're up to the point now, where the static aircraft could be replaced by dynamic aircraft models. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Scenery Object Database
On Wednesday 23 February 2005 14:19, Innis Cunningham wrote: Erik Hofman writes I think Innis did the 737, but the 747 I wouldn't know. It could be a good time to remove both static planes since the Traffic manager gets quite powerful already. No I did the 747 David M did the 737 and yes the statics I would think can be consigned to history.Actually the 747 has now been recruited into the AI fleet so you have not seen the last of it just yet.:-) Cheers Innis Sounds cool. Innis, I assume you refer to the traffic files you sent me earlier? I'm afraid I still haven't had a chance to look at them, although its still on my todo list. In the mean time, I started doing some prepatory work on taxiway following. I'm slowing my pace a little bit though, coming out of an extremely busy period at work. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Thu, 24 Feb 2005 16:21:07 +0100 Arnt Karlsen wrote: ..' lspci -v |grep -A 15 VGA '? (My 9250 on DRI is reported as a 9200 PRO) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 1732 Flags: bus master, stepping, 66Mhz, medium devsel, latency 255, IRQ 11 Memory at f000 (32-bit, prefetchable) [size=128M] I/O ports at d800 [size=256] Memory at e780 (32-bit, non-prefetchable) [size=64K] Expansion ROM at effe [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] More info on seg fault, How?
I'm getting seg faults 25% - 50% of the time when I try to start fg. This is on a fresh install of Mandrake 10.1 with the latest CVS of plib, simgear, flightgear, with the latest nvidia drivers. e.g. [EMAIL PROTECTED] mat]$ fgfs --fg-root=/home/Flightgear/data --fg-scenery=/home/Flightgear/World/work/Scenery-old --airport-id=LFMN --runway=4L --aircraft=b1900d --enable-game-mode --enable-random-objects --enable-horizon-effect --timeofday=noon --enable-ai-models --atlas=socket,out,5,localhost,5500,udp --verbose it then crashes before or during the spash screen, like this. [hash.c:395] failed read [hash.c:395] failed read [hash.c:395] failed read Segmentation fault (core dumped) I'm finding it hard to cause the seg fault happen, it seems to be intermittent. Is there a way to get more info from FG other than using --verbose ? Cheers Mat -- Matthew Churchill Ltd 16 Pollard Houses North Down Street London N1 9BJ UK Tel:+44 (0)207 8371019 Fax:+44 (0)207 8372761 email: [EMAIL PROTECTED] begin:vcard fn:Matthew Churchill n:Churchill;Matthew org:Matthew Churchill Ltd adr;dom:North Down Street;;16 Pollard House;London;;N1 9BJ email;internet:[EMAIL PROTECTED] tel;work:+44 (0)207 8371019 tel;fax:+44 (0)207 8372761 tel;cell:+44 (0)7971 505097 x-mozilla-html:FALSE url:http://www.matthewchurchill.com version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] More info on seg fault, How?
mat churchill wrote : I'm getting seg faults 25% - 50% of the time when I try to start fg. This is on a fresh install of Mandrake 10.1 with the latest CVS of plib, simgear, flightgear, with the latest nvidia drivers. e.g. [EMAIL PROTECTED] mat]$ fgfs --fg-root=/home/Flightgear/data --fg-scenery=/home/Flightgear/World/work/Scenery-old --airport-id=LFMN --runway=4L --aircraft=b1900d --enable-game-mode --enable-random-objects --enable-horizon-effect --timeofday=noon --enable-ai-models --atlas=socket,out,5,localhost,5500,udp --verbose it then crashes before or during the spash screen, like this. [hash.c:395] failed read [hash.c:395] failed read [hash.c:395] failed read Segmentation fault (core dumped) I'm finding it hard to cause the seg fault happen, it seems to be intermittent. Is there a way to get more info from FG other than using --verbose ? One of these options : --log-level=bulk --log-level=debug --log-level=info --log-level=warn --log-level=alert -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: More info on seg fault, How?
* mat churchill -- Thursday 24 February 2005 22:18: I'm getting seg faults 25% - 50% of the time when I try to start fg. This is on a fresh install of Mandrake 10.1 with the latest CVS of plib, simgear, flightgear, with the latest nvidia drivers. [...] it then crashes before or during the spash screen, like this. [...] Is there a way to get more info from FG other than using --verbose ? (0) compile link plib/sg/fgfs with 'debug' symbols (-g option) (1) make sure that you get core files. You may have to set ulimit -c unlimited (or some reasonable size instead of unlimited) in ~/.profilerc or ~/.bashrc or elsewhere. (2a) either wait until fgfs crashes: then load the core file into gdb (the gnu debugger): $ gdb `which fgfs` core.fgfs.123456 (whereby the core file name may look differently. The names aresettable in newer Linux kernels. This is what I use: $ echo core.%e.%p /proc/sys/kernel/core_pattern (2b) or run fgfs in gdb already: $ gdb --args fgfs --airport-id=LFMN ... (3) on the gdb prompt that you get for both (2a) and (2b) you can inspect the code. First list a backtrace: (gdb) bt after which you get a list of all stack frames, with the current one on top, from which this was called as next, etc. If you don't know what to do with all the info, send the backtrace to the list. I assume, though, that it's a local problem. Good for us. Bad for you. ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: More info on seg fault, How?
* Melchior FRANZ -- Thursday 24 February 2005 22:48: (0) compile link plib/sg/fgfs with 'debug' symbols (-g option) adding -O0 may be useful, too. (Turns off optimization and can make the debugger output easier to understand.) (2b) or run fgfs in gdb already: $ gdb --args fgfs --airport-id=LFMN ... Here you have to start the program excution with run. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Thu, 24 Feb 2005 22:08:51 +0100, Jorge wrote in message [EMAIL PROTECTED]: On Thu, 24 Feb 2005 08:03:36 +0100 Jorge Van Hemelryck wrote: xorg 6.7.0, open-source radeon driver glxgears ~2180fps, fgfs ~35-50fps (yay!!) specular highlight enabled Oops, I kind of mixed everything up here... I meant : xorg 6.7.0, open-source radeon driver glxgears ~2180fps, fgfs crashed (out-of-memory killed) last time I tried... xorg 6.7.0, closed-source fglrx driver glxgears ~1945fps, fgfs ~35-50fps (yay!!) specular highlight enabled ! ..http://x.org/ Latest News X11R6.8.2 has been Released -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: More info on seg fault, How?
* mat churchill -- Thursday 24 February 2005 23:09: Is this what I should be getting ? [EMAIL PROTECTED] mat]$ gdb `which fgfs` /home/mat/core.3564 [less interesting parts] Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 #0 0x4032fc4b in jhash_get () from /usr/lib/libopenal.so.0 Yes. But here should be a few lines more. Anyway: the crash happens in libopenal and I recommend to download openal from their cvs and compile sg/fgfs again. http://www.openal.org/downloads.html m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] error compiling fresh fgrun cvs
For the last several days I have been getting the following error when compiling fgrun from cvs. main.o(.text+0x18e): In function `main': /usr/local/source/fgrun/src/main.cxx:87: undefined reference to `Fl::lock()' So I removed all the files and do a clean co from cvs. I still get the same error. Any ideas? I am running FC2 (with all the uptodate updates). Thanks for any help, Dave P. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Camera/FOV/View Frustum question.
Can anyone explain to me how the camera, and view frustum, and field of view is setup fot the inside a 3d cockpit view versus an outside view? There have been a lot of fingers in the code since I last looked at it (years ago) and I'm missing a key piece of the puzzle. Hopefully none of this comes off as a rant ... I know we are doing some complex stuff here and there are complex interactions. First let me explain what I need to do. I need to configure an asymmetric view frustum. I need to place 3 monitors next to each other, aligned along a flat plane. The view drawn in each monitor needs to be projected on that same flat plane. I cannot just set a view offset for the side channels because the view won't come out right. If I simply rotate the view offset and take a symmetric view frustum, the plane of projection will be perpendicular to the viewer in each channel. That won't work for this particular application and it's not what I need. I need to configure an actual asymmetric view frustum for each side channel. If someone thinks they can help me, but is confused by my description, I'm happy to explain this further. Think about this from a top down view. Imagine I have a single super wide screen monitor and imagine the view frustum that goes along with that. Now imagine I want to replace the super wide monitor with 3 normal sized monitors, but otherwise generate the exact same display output. I need to chop up the one wide frustum into 3 frustums, but keep the original shape so if you put the 3 small frustums together, you get the original wide frustum. Said another way, the plane of projection of all 3 views needs to be the same. From the top down you can see that the center frustum will be symmetrical, but the two side channels will have to be asymmetric. So that's what I need to do. I did some playing in the code to intercept the actual frustum being used by calling ssgGetFrustum(). I can look at the values and change the left/right sides of the frustum. This yields the results I want, except for view #0 (the inside the 3d cockpit view.) My hack works for the aircraft model and 3d cockpit as seen from the inside, but the rest of the scene (i.e. the terrain) is completely screwed up. So somehow, the camera/view parameters must be getting set separately for the outside geomtry versus the 3d cockpit geometry. Can anyone explain how/where this happens. At the risk of making this message more complicated, I was planning to get an asymmetric view frustum by configuring a single triple-wide, normal-height screen, grabbing the view frustum values after they've been set by all the incomprehensible, ultra-optimized flightgear magic, then adjust the left/right values to get the portion of the screen that I want, and then rewrite the frustum. This is an awful, awful, terrible, ugly hack, but the view matrix setup code is now ultra-optimized and pretty much impenitrable to me. Going back to my original query. My little experiment to pan the view frustum side to side using this technique worked great in all the external views, but totally screwed up the outside world in view #0 ... I ended up with extreme overzoom and no panning relative to the outside scenery, but the 3d cockpit worked ok and panned as I was hoping it would. For what it's worth, I think the same issue is happening with the TR tiled rendering routines that generate the ultra-highres tiled screen shots ... that code suffers the same problem in view #0 with the outside world seen through extreme overzoom (i.e. you only get a tiny, itsy, bitty bit of the outside world expanded to fill the screen.) I'm extremely desperate to get this figured out and working in the next day or so!!! 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] Camera/FOV/View Frustum question.
From: Curtis L. Olson Sent: Thursday, 24. Feb 2005 23:37 -0500 To: FlightGear developers discussions Ok it's too late for me to be a lot of help right now. A couple of things. 1) Does everything work ok in other lookfrom views (where the camera rotates from a viewpoint). The second tower view that lets you look around the airport does that. If that works then the matrices are fine (lookfrom views all use the same matrices). 2) Look at FGAircraftModel::draw in FlightGear/src/Model/acmodel.cxx. There is a hack in there that resets the near/far plane and clears the depth buffer. I can't see what you see and it is too late for thinking hard let alone firing up flightgear and playing with the tiled dump. But those are the only two things I can think of that are done differently for the 3D cockpit view. Oh...hmmm...you were talking about 3D, right? If not then look at the 2D panel code. It does some weird things with the frustrum. And if that's it look at the panel config for one of those clear panels because they don't frig with the frustrum. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: error compiling fresh fgrun cvs
* Dave Perry -- Friday 25 February 2005 03:52: main.o(.text+0x18e): In function `main': /usr/local/source/fgrun/src/main.cxx:87: undefined reference to `Fl::lock()' So I removed all the files and do a clean co from cvs. I still get the same error. Any ideas? I am running FC2 (with all the uptodate updates). I had the same problem. fgrun does since very recently use threads, but fltk hadn't been compiled with threads on SuSE 9.2. (I dropped them a line and hope that they'll change that in the next release.) Seems that FC2 suffers from the same problem. You need to compile fltk with --enable-shared --enable-threads. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
