[Flightgear-devel] Cygwin - Compile errors

[Vivian Meazza]

This mornings' cvs fails to compile here under Cygwin with the following
error:

MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)':
MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is
ambiguous

/usr/include/plib/ul.h:334: note: candidates are: void ulEndianSwap(unsigned
int
*) 
/usr/include/plib/ul.h:350: note:  void ulEndianSwap(int*) 


I have up-to-date plib, sg, and fg cvs versions.
 
Since I don't need MIDG-II, I've fixed it locally by removing MIDG-II.cxx
from the makefile.

Regards,

Vivian

 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Cygwin - Compile errors

[Erik Hofman]

Vivian Meazza wrote:

This mornings' cvs fails to compile here under Cygwin with the following
error:

MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)':
MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is
ambiguous


This should be fixed.


Since I don't need MIDG-II, I've fixed it locally by removing MIDG-II.cxx
from the makefile.


What, again?
:-)

Erik

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] Cygwin - Compile errors

[Vivian Meazza]

Erik Hofman

> 
> Vivian Meazza wrote:
> > This mornings' cvs fails to compile here under Cygwin with the following
> > error:
> >
> > MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)':
> > MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is
> > ambiguous
> 
> This should be fixed.
> 
> > Since I don't need MIDG-II, I've fixed it locally by removing MIDG-
> II.cxx
> > from the makefile.
> 
> What, again?
> :-)
> 

er ... as usual :-) Quickest way - and involves absolutely no thought. 

Thanks!

Vivian 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] weird crash in sgMakeLeaf()

[Ralf Gerlich]

Hi all,

I did some further analysis on this bug and I found that in line 237 of 
leaf.cxx


texcoord = texcoords[ tex_index[i] ];

tex_index[i] is negative in the case of the crash. Specifically, the 
value in my case is 0x8000, which looks like a 
short-to-int-conversion problem. (Yes, the custom scenery is pretty 
detailed in some parts and yes, I'm working on a reduction of vertices 
as well ;-)


IIRC there was a change to the scenery code from short to int some time ago.

Regards,
Ralf

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] fonts for HUD

[rhett3]

Reply to Michael Krizansky,

Thank you for replying.  My browser mangled the attachment, however.  
The reference is not in cockpit.cxx, and the problem may go back to a 
change made by Norman Vine, who changed the
definitions for textString in hud_labl.cxx to eliminate any reference to 
GLUT fonts.  Now they come from some source that appears to be loaded in 
Main/fg_init.cxx.  But I can't figure out how to control this, and I 
don't want to hardwire it, until I get desperate.


BTW: one change that I have made to cockpit.cxx is to add a set of 
function calls to get variables needed for a twin engine jet, such as 
pctN1 and ITT.  These could be generalized for more engines.


Thank you again.

Rex du Pont
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] A question regarding accurate taxiways information

[Vassilii Khachaturov]

> Since FAA has airport diagrams in PDF format, would it be possible to extract
> taxiways information

BTW, the tower and the beacon, if any, can also be extracted from it,
as well as the windsocks, ILS hold lines etc.

> directly from a PDF file such as this
> http://204.108.4.16/d-tpp/0510/00375AD.PDF to produce taxiways usable in
> FlightGear?
>

1) by some kind of image processing following the Ghostview output.
Of course, since the internal graphics is vector, it might be possible
to infer more from various rendered resolutions.

2) Other approach would be to reverse engineer the original PS, if any,
from the PDF --- I'm afraid it's not very gratifying...

3) Yet another approach would be to ask the FAA for the data source feed
--- after all, this is U.S. government work that is in public domain.

And, of course, this is only a US-related solution...

Vassilii



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] fonts for HUD

[Norman Vine]

rhett3 writes:
> 
> Reply to Michael Krizansky,
> 
> Thank you for replying.  My browser mangled the attachment, however.  
> The reference is not in cockpit.cxx, and the problem may go back to a 
> change made by Norman Vine, who changed the
> definitions for textString in hud_labl.cxx to eliminate any reference to 
> GLUT fonts.  Now they come from some source that appears to be loaded in 
> Main/fg_init.cxx.  But I can't figure out how to control this, and I 
> don't want to hardwire it, until I get desperate.


Huh  If you look closely this change was a no-op
eg it just removed an unused paraameter from the calling macro
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/src/Cockpit/hud_labl.cxx.diff?r1=1.1&r2=1.2&cvsroot=FlightGear-0.9

I haven't been following this thread so I don't really know
what the problem is but FWIW  Glut Fonts have not been
used in FGFS at least in the cockpit code for quite some time.  

Considerably longer ago then the above cosmetic change

Cheers

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: [Terragear-devel] Re: Terragear, 64 bit

[Martin Spott]

Hello Jason,

Jason Cox wrote:

>  now if I can just get the land mass from e00

Which source did you intend to pick the data from ?

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] HUD fonts for Norman Vine

[rhett3]

Norman,

The problem is I need to change the font that is showing on my HUD
to make it larger (and brighter).  I cannot figure out where this is done.
It seems to refer back to properties in some way, but I can't find where
the lever is.  If I change the sizes in the programs in Cockpit, nothing
happens.  If the program is not using the GL fonts, what is it using and
how does one change one or more instances in the HUD? 


Thanks,

Rex du Pont
[EMAIL PROTECTED]



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] [fixed] weird crash in sgMakeLeaf()

[Ralf Gerlich]

Hi,

this patch should fix the bug.

Regards,
Ralf

Ralf Gerlich schrieb:

Hi all,

I did some further analysis on this bug and I found that in line 237 of 
leaf.cxx


texcoord = texcoords[ tex_index[i] ];

tex_index[i] is negative in the case of the crash. Specifically, the 
value in my case is 0x8000, which looks like a 
short-to-int-conversion problem. (Yes, the custom scenery is pretty 
detailed in some parts and yes, I'm working on a reduction of vertices 
as well ;-)


IIRC there was a change to the scenery code from short to int some time 
ago.


Regards,
Ralf
Index: simgear/io/sg_binobj.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/io/sg_binobj.cxx,v
retrieving revision 1.8
diff -u -r1.8 sg_binobj.cxx
--- simgear/io/sg_binobj.cxx	1 Oct 2005 11:41:59 -	1.8
+++ simgear/io/sg_binobj.cxx	11 Oct 2005 17:16:08 -
@@ -240,8 +240,8 @@
 	if ( nbytes > buf.get_size() ) { buf.resize( nbytes ); }
 	char *ptr = buf.get_ptr();
 	sgReadBytes( fp, nbytes, ptr );
-	int count = nbytes / (idx_size * sizeof(short));
-	short *sptr = (short *)ptr;
+	int count = nbytes / (idx_size * sizeof(unsigned short));
+	unsigned short *sptr = (unsigned short *)ptr;
 	int_list vs; vs.clear();
 	int_list ns; ns.clear();
 	int_list cs; cs.clear();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] HUD fonts for Norman Vine

[Norman Vine]

> 
> The problem is I need to change the font that is showing on my HUD
> to make it larger (and brighter).  I cannot figure out where this is done.
> It seems to refer back to properties in some way, but I can't find where
> the lever is.  If I change the sizes in the programs in Cockpit, nothing
> happens.  If the program is not using the GL fonts, what is it using and
> how does one change one or more instances in the HUD? 

The HUD uses PLIB Fonts these are *much* faster then the Glut Fonts

The code has been considerably reworked, albeit a  long time ago, 
since I implemented the PLIB Font mechanisms.

That said I believe you want to look at hud.hxx

class fgText {
  
void Draw(fntRenderer *fnt,int digits) {


HTH

Norman

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] How does the weather work in FlightGear?

[Adam Dershowitz]

On Oct 10, 2005, at 10:26 AM, Ampere K. Hardraade wrote:On October 10, 2005 03:37 am, Erik Hofman wrote: Buchanan, Stuart wrote: FlightGear can fetch the current weather at yourstarting airport, or you can set the wind, cloudlayers etc manually. I don't know if the weatherconditions are global, or change as you fly todifferent locations. It interprets the data from the nearest METAR station. The data isfetched from noaa.gov.Erik In my opinion, it would be better if data from multiple nearby METAR stations is used instead of fetching data from only one station.  I often fly with real-weather-fetch enabled, and the plane gets a huge jolt whenever the weather is updated.  The change in the visual aspects is also too sudden.  Using data from multiple METAR stations could avoid the above problems and allow us to have a smooth transistion in weather.AmpereThis is not as obvious as it would first seem.  Some weather phenomena have very sharp transitions and some are gradual.  So I don't think that "interpolating weather" is a trivial thing to do.  For example a cold front is often a very well defined line with rain right along the front.  In that case the weather right nearby is the best indicator and a METAR from 5 miles away could give a completely different story.  Airmass thunderstorms are another example where very local weather is what matters.  To make maters worse the METAR will just have temperature and wind, so you would have to look at a few different locations and times to figure out that a front has passed.  And the local geography (mountains, lake effects, shore lines) can also be a significant issue.I am not saying that it could not be done, just that it would take some real thought and real understanding of weather phenomena for it to apply in the general case rather than just in a few specific case and make things worse other times. --Adam ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] [fixed] weird crash in sgMakeLeaf()

[Alberico, James F]

Ralf,

Thanks for the patch.  This sounds exactly like the problem I had in
May, when trying very high-res data generated from TerraGear.  See the
May archives for details.  Found the max nodes was 32767, based on data
type.  TerraGear didn't complain when generating 40K, but was losing
bits in the output.  FG crashed when trying to read the resulting
scenery.

Regards,

Jim 

> 
> Hi,
> 
> this patch should fix the bug.
> 
> Regards,
> Ralf
> 
> Ralf Gerlich schrieb:
> > Hi all,
> > 
> > I did some further analysis on this bug and I found that in 
> line 237 
> > of leaf.cxx
> > 
> > texcoord = texcoords[ tex_index[i] ];
> > 
> > tex_index[i] is negative in the case of the crash. 
> Specifically, the 
> > value in my case is 0x8000, which looks like a 
> > short-to-int-conversion problem. (Yes, the custom scenery is pretty 
> > detailed in some parts and yes, I'm working on a reduction 
> of vertices 
> > as well ;-)
> > 
> > IIRC there was a change to the scenery code from short to int some 
> > time ago.
> > 
> > Regards,
> > Ralf
> 

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 24

[Curtis L. Olson]

Steve Knoblock wrote:


Can you point this dummy to where the nasal electical system or
documents are?
 



Sorry I have to make this quick, but the "nasal electrical system" is 
simply a nasal script that impliments the electrical system.  There 
should be an example in the c172 folder ... look for something like 
c172-electrical.nas (or something similar.)  The -set.xml file 
can reference aircraft specific nasal scripts so that's what you need to 
do to activate the electrical system.


The nasal script is specific code to impliment a specific aircraft's 
electrical system, but the overall structure could be copied and adapted 
to new aircraft.  But each aircraft will need it's own aircraft specific 
script.


Other than that, the script just runs every frame and reads and sets 
property values appropriately.


Regards,

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

[Flightgear-devel] CVS version/terrasync DB problem with UG25, LL62: crash(bo105)/strange(ufo)

[Vassilii Khachaturov]

When I start the CVS version at the UG25 airport with bo105 (yesterday's
CVS data, the day before CVS sources), it core dumps on startup as
follows:

#0  yasim::Turbulence::getTurbulence (this=0xad2cee0, loc=0x4fea8008,
alt=nan(0x40), up=0xbfffed60, turbOut=0xbfffedb0) at
Turbulence.cpp:100
#1  0x081cfc13 in yasim::Model::localWind (this=0xa698c24, pos=0xbfffee90,
s=0xbfffefb0, out=0xbfffeea0, alt=7.8685184e+09) at Model.cpp:537
#2  0x081cf4e3 in yasim::Model::calcForces (this=0xa698c24, s=0xbfffefb0)
at Model.cpp:399
#3  0x081cca9c in yasim::Integrator::calcNewInterval (this=0xa698c28)
at Integrator.cpp:176
#4  0x081c4e84 in yasim::FGFDM::iterate (this=0xa698c20, dt=0.0083377)
at FGFDM.cpp:91
#5  0x081bf030 in YASim::update (this=0xa6984f8, dt=0.05080627835587)
at YASim.cxx:212
#6  0x080575a5 in fgUpdateTimeDepCalcs () at main.cxx:170
#7  0x08058174 in fgMainLoop () at main.cxx:478
#8  0x0808cc75 in GLUTidle () at fg_os.cxx:114
#9  0x40410c67 in glutMainLoop () from /usr/lib/libglut.so.3
#10 0x0805ac76 in fgMainInit (argc=6, argv=0xb864) at main.cxx:1012
#11 0x0805703a in main (argc=1340768264, argv=0x4fea8008) at
bootstrap.cxx:193

We are talking about the CVS preferences.xml here, w/o any
real-world-wx-fetch.

The core dump is always at the same place (pointers are different).

If I do it with the ufo, it starts in some white warp space (cockpit view
-- solid white around the aircraft, same w/chase etc.)
and from the tower one doesn't see anything at all.

The last released version just hangs if I start it up there --- the
splash screen never goes away!

Now if I take a UFO and fly from a nearby airport to UG25 (say, from
UGGG), then one sees solid white instead of the runway --- broken scenery,
or broken fgfs?

See a screenshot of what I am talking about at
http://www.tarunz.org/~vassilii/Images/fg/UG25-cutout.jpg

A similar thing happens at LL62 (crash of the CVS version/cutout):
http://www.tarunz.org/~vassilii/Images/fg/LL62-cutout.jpg

I thought there some problem with the ""
airport data scenery automatic generation, but, e.g. JY07 is all right.

I'm running Debian Linux 2.6.8-2-686,
NVRM version: NVIDIA Linux x86 NVIDIA Kernel Module  1.0-7174  Tue Mar 22
06:44:39 PST 2005
GCC version:  gcc version 3.3.5 (Debian 1:3.3.5-13)
Model:   GeForce2 MX/MX 400
IRQ: 169
Video BIOS:  03.11.00.07.00
Card Type:   AGP

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.3
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control
client glx vendor string: NVIDIA Corporation
client glx version string: 1.3

When I'm testing the CVS version, it uses the CVS simgear as well.
All the other packages (plib, openal etc) are debian ones.

HTH,
Vassilii


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] military etc airport beacon?

[Vassilii Khachaturov]

Does the airports source database include the military designation?
If yes, then it would add to the realism to have the different beacons,
e.g., military airfield == GREN/white/white (see
http://www.faa.gov/ATpubs/AIM/Chap2/aim0201.html ).

Vassilii


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] [PATCH] README.multiplayer update

[Vassilii Khachaturov]

I've updated README.multiplayer to reflect the recent changes.
I'm not addressing the released/cvs incompatibility issue in there,
hopefully this is fine.

Index: data/Docs/README.multiplayer
===
RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v
retrieving revision 1.1
diff -u -p -r1.1 README.multiplayer
--- data/Docs/README.multiplayer21 Aug 2004 08:57:29 -  1.1
+++ data/Docs/README.multiplayer12 Oct 2005 00:23:45 -
@@ -54,19 +54,65 @@ is the sort of implementation that we ar
 visual simulator.


-For use with a server (when one is created):
-
+For use with a server:
+--
+Oliver Schroeder has created a server for multiplayer flightgear use.
+The server acts as a packet forwarding mechanism. When it
+receives a packet, it sends it to all other active players.
+Future versions might be more scalable, only forwarding information
+on the planes in the receiving player's vicinity.
+
+Check out the server homepage 
+for the current status. You can either download the server for
+some local use, or join the developers on the existing servers.
+
+Pigeon  has created a web page monitoring
+two such servers, showing the traffic in a Google map environment.
+See .
+
+Options needed to enable multiplayer game with a server:
 Player1:
---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500
+--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002
 --callsign=player1

 Player2:
---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5501
+--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002
 --callsign=player2

-Playern:
---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5502
---callsign=playern
+...

-The server would simply act as a packet forwarding mechanism. When it
-receives a packet, it sends it to all other active players.
+PlayerN:
+--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002
+--callsign=playerN
+
+Note that if every player using a particular server, such as one of those
+listed on the Pigeon's page, needs to have a unique callsign, not
+already in use on that server.
+
+If you are sitting behind a NAT'ting firewall, then you need to forward
+the incoming traffic on the firewall outer (visible to the internet)
+address arriving at the UDP port you use (5002 in the case above)
+over to your private LAN address. In this case, use your PRIVATE LAN address
+as . Example (if your private LAN address is 10.0.0.1,
+in order to play on pigeond.net):
+
+fgfs --multiplay=in,10,10.0.0.1,5002 --multiplay=out,10,pigeond.net,5002
+   --callsign=...UNIQUE callsign here...
+
+If you and the server are in the same address space (i.e., both have a public
+IP address or both are on the same private LAN), you hopefully don't need to
+mess with any firewalls.
+
+If you don't see other players playing on the same server in your flightgear,
+check that you have followed the above router configuration guidelines.  Check
+that you don't have any LOCAL firewall running on your computer preventing the
+flightgear network traffic flow.
+
+Finally, use ethereal(1) or tethereal(1) to capture the UDP traffic on the port
+that you are using, and see if you observe both incoming and outgoing packets.
+
+It's a good idea to talk to the IRC channel #flightgear on irc.flightgear.org
+while flying on one of the public servers. Also, it makes sense for every user
+on the same server to use the same weather setup, e.g., the real weather
+METAR feed, selected by setting to true the real-world-weather-fetch and
+control-fdm-atmosphere properties.


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

RE: [Flightgear-devel] (electrical) Flightgear-devel Digest, Vol 30, Issue 24

[Jon Berndt]

Curt wrote:

> The nasal script is specific code to impliment a specific aircraft's
> electrical system, but the overall structure could be copied and adapted
> to new aircraft.  But each aircraft will need it's own aircraft specific
> script.

I'll add that there are probably several ways to do various 
mechanical/electrical system
models. You may recall from Summer 2005 JSBSim newsletter an article about the 
L410
aircraft model done by Jiri Javurek. They use the JSBSim flight control 
components to
model various systems in ways I had not considered before. For example (and 
this is "old
format" - the current format in FlightGear CVS - JSBSim specification):

 

  

  



/systems/l410/battery1-ok == 1
/systems/l410/battery2-ok == 1

  

  



/systems/l410/battery1-ok == 1
/systems/l410/battery2-ok == 1

  

  
 INPUT   fcs/battery-all-ok
 GAIN 1
 OUTPUT  /systems/l410/battery-all-ok
  

  
 INPUT   fcs/battery-one-ok
 GAIN 1
 OUTPUT  /systems/l410/battery-one-ok
  

  

  



/systems/electrical/outputs/bus28v > 10
/systems/electrical/outputs/bus36v > 10
/systems/electrical/outputs/bus115v > 10

  
  
 INPUT   fcs/spec-turn
 GAIN 1
 OUTPUT  /controls/switches/specbus_28v_115v_36v
  

  etc.

It's quite an impressive use of the components.

Jon


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d