Re: [Flightgear-devel] gnome 3 ?

2011-06-03 Thread Guillaume Chauvat
Le 03/06/2011 06:10, Curtis Olson a écrit :
 Is anyone here running gnome 3 (and you would probably know if you
 were.) :-)

 I just loaded up Fedora 15 on a test machine and my first comment was
 hmmm...  I haven't tried to get FlightGear running.  I guess I can't
 imagine why it wouldn't run just fine although the desktop requires
 accelerated opengl hardware so I hope there won't be too much
 competition for resources when running FlightGear.

 Does anyone have any feed back on issues or problems specific to the
 new gnome 3 desktop scheme? Building/running FlightGear?

 Looks like the linux desktop folks have stopped chasing windows and
 are now chasing mac?   Quote from an online review: gnome 3 gives you
 any color theme you like ... if you like black.

 Is gnome 3 viable for real work?

 I've heard gnome 3 and intuitive mentioned in the same sentence.
  I guess I'm going to have to go lookup the definition of intuitive
 again -- oh here it is -- something that makes obvious sense after
 you've figured it out. :-)

 Curt.
 -- 
 Curtis Olson:
 http://www.atiak.com - http://aem.umn.edu/~uav/
 http://aem.umn.edu/%7Euav/
 http://www.flightgear.org - http://gallinazo.flightgear.org

Hello,

I recently installed GNOME 3 on Debian and there is no problem with
FlightGear. I have a nVidia GT240 graphic card.

GNOME 3 is not yet very stable on my machine, but it was my choice to
install packages from the experimental repository :-). It was difficult
for me to get used to it at the beginning, but now I find it very
practical. But it is harder to configure than before (not only the
theme, but everything else) and I think it's a bad idea.
gnome-tweak-tool and dconf-editor help a bit If you don't know them already.

Guillaume



signature.asc
Description: OpenPGP digital signature
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] High altitute/speed flights terrain engine problems

2011-06-03 Thread thorsten . i . renk
 If two users in parallel flying spacecrafts will see the same good then
 there is no problem. But everything on Nasal is on local level, not
 global core level.

At least one of us is confused about how things are structured.

My understanding is that there's nothing in Flightgear which guarantees
that two users flying parallel get to see the same. My understanding of
the multiplayer protocol is that it largely exchanges position information
of models and submodels, in addition to model and livery path.

If we're flying over Seattle, and you have the default scenery and I the
Pacific Northwest custom scenery, I will see different terrain than you
do. If I don't have your aircraft model installed, then I will see a
placeholder (I think a funny-coloured glider) at your position. If I'm
running live weather and you have 'Fair Weather' selected, I might have
few hundred meters visibility and rain whereas you fly next to me in
bright sunshine.

Similarly, I don't see how you could guarantee that two spacecraft users
see the same, unless they have the same models/textures/scripts for
rendering Earth from high altitude installed.

I have no idea what you mean by the distinction of Nasal being on a local
level and the core on a global level. If you look into /Nasal/, you find
scripts like multiplayer.nas, tanker.nas or redout.nas which are available
whatever aircraft you have installed or whatever aircraft you are in -
just as the core, they are part of every Flightgear session.

But, see above, neither core nor scripts are ever global in the sense that
they'd be the same for every user - if you run GIT and I run 2.0.0, the
core is obviously not the same.

 Scenery models usually exist on the whole FG level...

 Earth is not scenery.

Well, that's precisely my point, isn't it? You don't need a new terrain
engine if you stop thinking about planets from high above as 'terrain'. 
From a Celestia perspective, Earth is just a sphere with a very high
resolution texture and reflection and normalmap shaders. That's something
Flightgear has the functionality to render without much ado or additional
coding - as a scenery model.

So if, for spaceflight, you write a /Nasal/earthview.nas which
periodically checks altitude and loads a large enough scenery model above
40 km while it de-activates the default terrain, you have solved the
problem of implementing Celestia-like views of Earth in Flightgear.

 So if choice is between redoing things what's already done and including
 that things I would prefer including. There is four or five Open Source
 space simulators and most of them is not so addable for modder or even
 usable for end user. If them authors could put their efforts together
 then we could have best space sim already.

If that would happen, it would be very nice. It also would be nice if
people would send me their GPL-compatible photographs of Cb clouds so that
I could improve my thunderstorm textures which are rather lousy at the
moment. It would also be nice if people would pool their resources to
create a nice GPL-compatible database of aerial images so that we'd have
raw material for texturing.

All that doesn't just seem to happen... so I have to make do with what
happens. It's a bit up to you - if you can get off a demo of a nice Earth
view from space using existing technology, the likelihood of getting more
people interested in working on the issue increases. If you wait for the
best solution to be implemented up front, you may be lucky, but it also
may be a long wait.

Cheers,

* Thorsten


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Object distance fading color

2011-06-03 Thread thorsten . i . renk
 I'll see what I can come up with this weekend.

Thanks, much appreciated!

 On another note: I seem to remember you had another request for the
 weather system but I was too busy to remember it. Do you remember what
 that was?

I was toying with the idea to model diffuse high-altitude haze by coloring
the skydome as a function of altitude, i.e. paint the zenith a bit more
hazy without touching the horizon and remove that effect again as you get
above the haze layer - I believe that might create a better impression of
such diffuse layers than placing texture sheets into the scene.

Cheers,

* Thorsten


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] modelling an battery powered electric motor MAV

2011-06-03 Thread Gaurav Tendolkar
I am modelling an battery powered electric motor MAV.
In JSBsim the battery does not discharge.

00178 FGElectric::CalcFuelNeed(void)00179 {00180   return 0;00181 }

now i want to write a code where fuel is the power supplied by battery.
by knowing the total stored energy we will calculate time to discharge.

How do i make the changes to the code come to effect in flightgear ?
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] gnome 3 ?

2011-06-03 Thread Stefan Seifert
On Friday 03 June 2011 06:10:24 Curtis Olson wrote:

 Looks like the linux desktop folks have stopped chasing windows and are now
 chasing mac?   Quote from an online review: gnome 3 gives you any color
 theme you like ... if you like black.

s/linux desktop/Gnome/
There's still KDE and all the lighter desktops available which do not force 
anything on you.

And according to a phoronix comparison, the KDE window manager seems most of 
the time to be the one affecting performance the least. And if that's still too 
much, deactivating desktop effects is just a shortcut away.

http://www.phoronix.com/scan.php?page=articleitem=linux_desktop_managers1num=1

Stefan

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [Fwd: Crash in latest GIT/master]

2011-06-03 Thread ThorstenB
On 03.06.2011 04:58, Roland Häder wrote:
 I have found more:
 http://pastebin.com/UrE81hNW
Looks like an OSG installation problem. There is always an 
osgPlugins-2.x.y subdirectory for an OSG 2.x.y installation. I don't 
think this could be a general error with OSG 2.8.4.

 2.8.4 is latest stable release.
They are currently testing osg 2.8.5-RC2. Final call for tests has been 
made. You could also try this version. If anything wasn't working there, 
you still have a day or two to raise the issue to OSG.

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] gnome 3 ?

2011-06-03 Thread Chris Baines
I use Gnome 3 and FlightGear and it works well. I do like the Shell,
and after a while it does grow on you.

The main problem I think is that people logically think that as Gnome
3 is released the Shell is completed, where that is far from the
truth, much of the work is still to be done.

As you point out its hard to configure and might not be as intuitive
as it could be but it looks like an alright base to work from.

On 3 June 2011 08:54, Stefan Seifert n...@detonation.org wrote:
 On Friday 03 June 2011 06:10:24 Curtis Olson wrote:

 Looks like the linux desktop folks have stopped chasing windows and are now
 chasing mac?   Quote from an online review: gnome 3 gives you any color
 theme you like ... if you like black.

 s/linux desktop/Gnome/
 There's still KDE and all the lighter desktops available which do not force
 anything on you.

 And according to a phoronix comparison, the KDE window manager seems most of
 the time to be the one affecting performance the least. And if that's still 
 too
 much, deactivating desktop effects is just a shortcut away.

 http://www.phoronix.com/scan.php?page=articleitem=linux_desktop_managers1num=1

 Stefan

 --
 Simplify data backup and recovery for your virtual environment with vRanger.
 Installation's a snap, and flexible recovery options mean your data is safe,
 secure and there when you need it. Discover what all the cheering's about.
 Get your free trial download today.
 http://p.sf.net/sfu/quest-dev2dev2
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] fgdata merge request 91:Animated Jetways

2011-06-03 Thread Martin Spott
Ryan M wrote:

 * Jetways are disabled by default due to noticeable FPS impacts.

I'm feeling slightly uneasy with the current state because people don't
get any jetways at all if they disable the flag in order to preserve
performance.  Personally I'd prefer a solution which keeps static
jetways and just disables the animation if people feel like the need
to.

While I'm at it, I'd like to point to another, presumably more severe
issue: The elevation of every of the animated jetways is hardcoded into
the respective 'ICAO.jetway.xml' files.  Now take into account that
ground elevation is subject to change with almost _every_ rebuild of
the corresponding region and airfield surface 
From my perspective this calls for a more considerate solution.

For the static scenery models at Scenemodels we're having a stupid
but pretty functional and robust procedure to adjust the elevation of
every model to the current World Scenery.  This doesn't work for the
way how elevation is being stored in the jetway XML files.

 Currently the Models/Airport/Jetway folder is still in the commit. I can
 remove it if this is inappropriate.

Indeed, this would have been better 

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

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] modelling an battery powered electric motor MAV

2011-06-03 Thread Curtis Olson
Hi Gaurav,

For questions specific to JSBSim code, you might also ask on the jsbsim
mailing list (details at www.jsbsim.org) -- although I'm sure several of the
developers are subscribe to both flightgear and jsbsim devel lists.

One other thought if you want to avoid changing C++ code or you wish to
support versions of FlightGear that are already released, is that you might
be able to create a simple battery model using Nasal (flightgear's embedded
scripting language.)  You could perhaps limit maximum throttle position
based on the output of your battery simulation to simulate the what happens
as your battery is used up (or to simulate an aging battery, etc.)

I know batteries are pretty complex if you dig into them, but you could
probably hack something simple really quickly that would get you 90% of the
way there and cover most of the situations you would be concerned about.

Curt.


On Fri, Jun 3, 2011 at 2:49 AM, Gaurav Tendolkar grvtendol...@gmail.comwrote:

 I am modelling an battery powered electric motor MAV.
 In JSBsim the battery does not discharge.

 00178 FGElectric::CalcFuelNeed(void)00179 {00180   return 0;00181 }

 now i want to write a code where fuel is the power supplied by battery.
 by knowing the total stored energy we will calculate time to discharge.

 How do i make the changes to the code come to effect in flightgear ?



 --
 Simplify data backup and recovery for your virtual environment with
 vRanger.
 Installation's a snap, and flexible recovery options mean your data is
 safe,
 secure and there when you need it. Discover what all the cheering's about.
 Get your free trial download today.
 http://p.sf.net/sfu/quest-dev2dev2
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel




-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] modelling an battery powered electric motor MAV

2011-06-03 Thread Ron Jensen
On Friday 03 June 2011 01:49:30 Gaurav Tendolkar wrote:
 I am modelling an battery powered electric motor MAV.
 In JSBsim the battery does not discharge.

 00178 FGElectric::CalcFuelNeed(void)00179 {00180   return 0;00181 }

 now i want to write a code where fuel is the power supplied by battery.
 by knowing the total stored energy we will calculate time to discharge.

 How do i make the changes to the code come to effect in flightgear ?

Consuming fuel requires a loss of mass. I'm sure you don't intend that, so I 
would recommend looking at other methods. Like Curt suggested, you could 
create your own system using JSBSim functions (recommend) or NASAL. You can 
use these properties to calculate the power consumed by the engine:
 propulsion/engine/power-hp
 propulsion/engine/propeller-rpm
(These are JSBSim properties, in FlightGear they are preceded by /fdm/jsbsim/)

This code snippet for the JSBSim FCS block will reduce the throttle by the 
normalized battery voltage.
Setting the value of (/fdm/jsbsim/)propulsion/battery-volt-norm is left to 
you.

  property value=1.0 propulsion/battery-volt-norm/property
  channel name=battery
   pure_gain name=throttle   
input fcs/throttle-cmd-norm /input
gain propulsion/battery-volt-norm /gain
output fcs/throttle-pos-norm /output
   /pure_gain
  /channel

Good luck,
Ron

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Rating System Redux

2011-06-03 Thread ThorstenB
Hi Stuart and all,

  http://wiki.flightgear.org/Formalizing_Aircraft_Status

We have some (too few!) aircraft providing documentation / tutorials, 
i.e. how to start, how to use instruments... I like extremely 
detailed/realistic aircraft, and I'm not asking everyone to provide 
cheating autostart options. But realistic FDMs/cockpits/... are still of 
little use when people don't know how to use them. So, wouldn't it be a 
good idea to make the level of documentation/tutorials part of the new 
rating system? Especially since that's certainly of interest to new 
users (new to FG, or just new to the aircraft).

So, how about adding Documentation and Tutorials rating section, like:

0: no documentation/tutorials available
1: aircraft key bindings dialog available, basic documentation included 
(i.e. readme.txt)
2: tutorials on basic aircraft operation available (at least start-up)
3: advanced tutorials available (start-up, autopilot, approach/landing 
configuration)
4: highly advanced training tutorials available (i.e. covering 
emergencies/engine-failures etc)

You can certainly argue on how many points these are worth (compared to 
FDM/cockpit realism etc). But it shouldn't be ignored completely.

Any thoughts?

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Rating System Redux

2011-06-03 Thread Stuart Buchanan
On Fri, Jun 3, 2011 at 6:56 PM, ThorstenB wrote:
 Hi Stuart and all,

   http://wiki.flightgear.org/Formalizing_Aircraft_Status

 We have some (too few!) aircraft providing documentation / tutorials,
 i.e. how to start, how to use instruments... I like extremely
 detailed/realistic aircraft, and I'm not asking everyone to provide
 cheating autostart options. But realistic FDMs/cockpits/... are still of
 little use when people don't know how to use them. So, wouldn't it be a
 good idea to make the level of documentation/tutorials part of the new
 rating system? Especially since that's certainly of interest to new
 users (new to FG, or just new to the aircraft).

You may have seen that I've proposed putting it at least partly within the
 Systems  rating, as really it is related to operating those systems.

Thus far, my proposal is that for a Systems:3 rating, there must be
either in-sim instructions or a tutorial for the correctly modelled engine
startup.  I think that is reasonable, and will allow new users to at least
start the engine, if not get into the air.

We could extend that such that for each of the modelled systems for a given
rating there must be either
- in-sim help/checklist
- in-sim tutorial
- referenced documentation elsewhere (Manual, wiki, freely available PoH)

Does that seem reasonable or too draconian?

The problem with having it as a completely separate rating is that when
calculating an overall status for the aircraft  it dilutes the other ratings
(in particular FDM) unless one starts weighting the different ratings.

-Stuart

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Hudson Mac

2011-06-03 Thread HB-GRAL
Hi Hudson

I see that FlightGear-next-mac fails since some days because of some 
missing plib headers. Is next-mac not followed anymore on hudson, is 
FlightGear-mac-cmake reference now ?

Cheers, Yves

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Rating System Redux

2011-06-03 Thread Hal V. Engel
On Friday, June 03, 2011 11:45:26 AM Stuart Buchanan wrote:
 On Fri, Jun 3, 2011 at 6:56 PM, ThorstenB wrote:
  Hi Stuart and all,
  
http://wiki.flightgear.org/Formalizing_Aircraft_Status
  
  We have some (too few!) aircraft providing documentation / tutorials,
  i.e. how to start, how to use instruments... I like extremely
  detailed/realistic aircraft, and I'm not asking everyone to provide
  cheating autostart options. But realistic FDMs/cockpits/... are still of
  little use when people don't know how to use them. So, wouldn't it be a
  good idea to make the level of documentation/tutorials part of the new
  rating system? Especially since that's certainly of interest to new
  users (new to FG, or just new to the aircraft).
 
 You may have seen that I've proposed putting it at least partly within the
  Systems  rating, as really it is related to operating those systems.

There are some things that should be covered in the in-sim help or a pilots 
handbook that are related to the FDM such as Vne, stall speeds, service 
ceiling and the like.  So perhaps there is an FDM component to this as well 
but this is probably a nit and having it covered in the Systems catigory seems 
OK to me.

 
 Thus far, my proposal is that for a Systems:3 rating, there must be
 either in-sim instructions or a tutorial for the correctly modelled engine
 startup.  I think that is reasonable, and will allow new users to at least
 start the engine, if not get into the air.
 
 We could extend that such that for each of the modelled systems for a given
 rating there must be either
 - in-sim help/checklist
 - in-sim tutorial
 - referenced documentation elsewhere (Manual, wiki, freely available PoH)
 
 Does that seem reasonable or too draconian?

This strikes me as an OK approach.  As the systems being modeled get more 
complex and/or numerous having everything covered by in-sim help/check lists 
is not feasible (IE. the help text becomes too big).   But there is also a 
need for more documentation as more systems are added to the model.  Having 
some basic aircraft help (perhaps startup, take off and landing check lists 
along with some other basic info) and referring users to a pilot's handbook 
that covers in detail how these systems work IRL should be enough to satisfy 
this requirement.  

For many aircraft getting the pilots handbook is not hard but it can take some 
research to find.  I had considered adding the pilots handbook to my aircraft 
directory in a Docs subdirectory since it has been put in the public domain by 
US.gov (IE. no IP issues - something that will not be the case for all 
aircraft).  But the best of the handbooks available is fairly large (around 54 
meg) and I am a little hesitant to add it since adding the handbook almost 
doubles the download size of the aircraft. 

I didn't even think about this when rating my aircraft since I had assumed 
that most if not all aircraft with with a shot at something beyond a beta 
rating would either have extensive in-sim documentation or a pilots handbooks 
would be available.  For me adding this requirement to the rating system would 
not affect how I scored my model but it may impact others.

 
 The problem with having it as a completely separate rating is that when
 calculating an overall status for the aircraft  it dilutes the other
 ratings (in particular FDM) unless one starts weighting the different
 ratings.
 
 -Stuart
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel