Re: [Flightgear-devel] Build Problem Under Cygwin
Jonathan Polley wrote: > I just tried to build FlightGear under Cygwin. When I build, I get the following: > > In file included from glut_shapes.c:59: > /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token > In file included from glut_shapes.c:61: > glut_shapes.h:12:1: warning: "APIENTRY" redefined > In file included from /usr/include/w32api/GL/glu.h:37, > from glut_shapes.c:59: > /usr/include/w32api/GL/gl.h:80:1: warning: this is the location of the previous > definition > make[5]: *** [glut_shapes.o] Error 1 > make[5]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky/cloud > s3d' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' > make: *** [all-recursive] Error 1 > > This is true even after I do a make clean. This is because HAVE_WINDOWS_H is not defined by the configure script. Try : CXXFLAGS=-DHAVE_WINDOWS_H ./configure -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem Under Cygwin
Yes, I ran into this problem as well. I work around it by temporarily renaming the /usr/X11R6 directory, i.e., cd /usr mv X11R6/ X11R6.tmp cd cd src/SimGear [build commands] cd ../FlightGear/source [build commands] cd /usr mv X11R6.tmp X11R6 I realize that this is a bit of kludge, but I works, and allows me to keep my cygwin X11 installed (which I'm using at work to interface to a linux box, and would like to keep current on my home windows machine as well). On Tuesday 16 March 2004 03:50, Curtis L. Olson wrote: > Hopefully someone who knows the answer will jump in and correct me if I'm > wrong, but this sounds like the errors people were getting when they > installed the cygwin X11 packages. These provide conflicting versions of > the opengl headers which cause the build to fail. I think the current > solution is to uninstall the X11 packages (and possibly send a nice note > off to the cygwin development team informing them that this needs to be > addressed some day.) > > Regards, > > Curt. > > Jonathan Polley wrote: > > I just tried to build FlightGear under Cygwin. When I build, I get the > > following: > > > > In file included from glut_shapes.c:59: > > /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token > > In file included from glut_shapes.c:61: > > glut_shapes.h:12:1: warning: "APIENTRY" redefined > > In file included from /usr/include/w32api/GL/glu.h:37, > > from glut_shapes.c:59: > > /usr/include/w32api/GL/gl.h:80:1: warning: this is the location of the > > previous definition > > make[5]: *** [glut_shapes.o] Error 1 > > make[5]: Leaving directory > > `/home/jwpolley/fgdev/SimGear/simgear/scene/sky/cloud s3d' > > make[4]: *** [all-recursive] Error 1 > > make[4]: Leaving directory > > `/home/jwpolley/fgdev/SimGear/simgear/scene/sky' make[3]: *** > > [all-recursive] Error 1 > > make[3]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' > > make: *** [all-recursive] Error 1 > > > > This is true even after I do a make clean. > > > > Thanks, > > > > Jonathan Polley > > > > > > Of COURSE they can do that. They're engineers! > > > > ___ > > Flightgear-devel mailing list > > [EMAIL PROTECTED] > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem Under Cygwin
I deleted my cygwin installation and started from scratch (somehow, I had X installed previously). Unfortunately, even though I made sure that X11 was not installed, the problem didn't go away. plib builds just fine, it is just SimGear that is having a problem. I will try to fiddle around a bit more tomorrow. Thanks for the help, Jonathan Polley On Mar 15, 2004, at 9:46 PM, Jon Berndt wrote: Hopefully someone who knows the answer will jump in and correct me if I'm wrong, but this sounds like the errors people were getting when they installed the cygwin X11 packages. These provide conflicting versions of the opengl headers which cause the build to fail. I think the current solution is to uninstall the X11 packages (and possibly send a nice note off to the cygwin development team informing them that this needs to be addressed some day.) I don't recall running into this one, but it would not surprise me if something like this was the case. I've gotten some strange things happening with CygWin if I have KDE or the X11 packages installed AND I also have the DISPLAY environment variable set to something. It's been a long time, so I don't remember exactly what the case was. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] gcc problems
Orthonormalize writes:
> does anyone know why i can't compile the following program?
> for some reason gcc doesn't like plib/ul.h.
> $ cat test.c
> #include
> int main()
> {
> return 1;
> }
> $ gcc -I/cygdrive/c/cygwin/usr/include test.c
PLib is a c++ library and gcc doesn't know that, so
either
1) rename test.c test.cpp or test.cxx so gcc will call g++
or
2) invoke g++ directly i.e. g++ test.c
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gcc problems
does anyone know why i can't compile the following
program?
for some reason gcc doesn't like
plib/ul.h.
$ cat test.c
#include
int main(){return 1;
}
$ gcc -I/cygdrive/c/cygwin/usr/include test.cIn
file included from test.c:2:/usr/include/plib/ul.h:135: error: syntax error
before "ulClock"/usr/include/plib/ul.h:136: error: syntax error before '{'
token/usr/include/plib/ul.h: In function
`getRawTime':/usr/include/plib/ul.h:151: error: syntax error before
"public"/usr/include/plib/ul.h:170: error: syntax error before
"const"/usr/include/plib/ul.h:177: error: syntax error before '{'
token/usr/include/plib/ul.h:222: error: storage class specified for
parameter `ulErrorCallback'/usr/include/plib/ul.h:227: error: syntax
error before "ulErrorCallback"/usr/include/plib/ul.h:228: error: syntax
error before "cb"/usr/include/plib/ul.h:235: error: storage class specified
for parameter `ulDir'
/usr/include/plib/ul.h:239: error: syntax error
before "bool"/usr/include/plib/ul.h:245: error: syntax error before
"ulDir"/usr/include/plib/ul.h:247: error: syntax error before '*'
token/usr/include/plib/ul.h:253: error: syntax error before
"bool"/usr/include/plib/ul.h:263: error: storage class specified for
parameter `_ulEndianTest'/usr/include/plib/ul.h:263: error: parameter
`_ulEndianTest' is initialized/usr/include/plib/ul.h:266: error: storage
class specified for parameter `_ulEndianSwap'/usr/include/plib/ul.h:266:
error: syntax error before '{' token/usr/include/plib/ul.h:668: error:
syntax error before "public"/usr/include/plib/ul.h:674: error: syntax error
before '{' token/usr/include/plib/ul.h:686: error: syntax error before '{'
token/usr/include/plib/ul.h:693: error: syntax error before '{'
token/usr/include/plib/ul.h:704: error: syntax error before '*'
token/usr/include/plib/ul.h:704: error: storage class specified for
parameter `bool'/usr/include/plib/ul.h:704: error: `bool' declared as
function returning a function/usr/include/plib/ul.h:705: error: storage
class specified for parameter `ulCompareFunc'/usr/include/plib/ul.h:711:
error: syntax error before "class"/usr/include/plib/ul.h:721: error: syntax
error before "bool"/usr/include/plib/ul.h:723: error: syntax error before
'*' token/usr/include/plib/ul.h:752: error: syntax error before '{'
token/usr/include/plib/ul.h:755: error: syntax error before
"ulCompareFunc"/usr/include/plib/ul.h:758: error: conflicting types for
`removeNode'/usr/include/plib/ul.h:757: error: previous declaration of
`removeNode'/usr/include/plib/ul.h:760: error: syntax error before
"const"/usr/include/plib/ul.h:762: error: syntax error before
"fn"/usr/include/plib/ul.h:764: error: syntax error before
"destroyfn"/usr/include/plib/ul.h:768: error: storage class specified for
parameter `ulStrDup'/usr/include/plib/ul.h:769: error: storage class
specified for parameter `ulStrNEqual'/usr/include/plib/ul.h:770: error:
storage class specified for parameter `ulStrEqual'test.c:5: error:
syntax error before '{' token
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Visualising forces
Jim Wilson writes: > > Norman Vine said: > > > Jim Wilson writes: > > > > > > Currently it is > > > possible to control all aspects of the camera position and angle through the > > > property tree (in the /sim/current-view path), > > > > I see 'heading' and 'pitch' but not 'roll'. > > I guess I must be missing something ? > > > > Best > > > > Norman > > > > "/sim/current-view/heading-offset-deg" > > "/sim/current-view/goal-heading-offset-deg" > > "/sim/current-view/pitch-offset-deg" > > "/sim/current-view/goal-pitch-offset-deg" > > "/sim/field-of-view" > > "/sim/current-view/view-number" > > "/sim/current-view/axes/long" > > "/sim/current-view/axes/lat" > > "/sim/current-view/ground-level-nearplane-m" > > Oops...that is a bug. The interface is there, at least partly...something is > missing though. I think with the mouse and keyboard manipulation we're only > using two of the axes which might explain why that one snuck by. IIRC viewer 'roll' has not been possible since the 'grand rewrite' but I won't bring up quaternions again oops. :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Visualising forces
Norman Vine said: > Jim Wilson writes: > > > > Currently it is > > possible to control all aspects of the camera position and angle through the > > property tree (in the /sim/current-view path), > > I see 'heading' and 'pitch' but not 'roll'. > I guess I must be missing something ? > > Best > > Norman > > "/sim/current-view/heading-offset-deg" > "/sim/current-view/goal-heading-offset-deg" > "/sim/current-view/pitch-offset-deg" > "/sim/current-view/goal-pitch-offset-deg" > "/sim/field-of-view" > "/sim/current-view/view-number" > "/sim/current-view/axes/long" > "/sim/current-view/axes/lat" > "/sim/current-view/ground-level-nearplane-m" Oops...that is a bug. The interface is there, at least partly...something is missing though. I think with the mouse and keyboard manipulation we're only using two of the axes which might explain why that one snuck by. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Build Problem Under Cygwin
> Hopefully someone who knows the answer will jump in and correct me if I'm > wrong, but this sounds like the errors people were getting when they > installed the cygwin X11 packages. These provide conflicting versions of > the opengl headers which cause the build to fail. I think the current > solution is to uninstall the X11 packages (and possibly send a nice note > off to the cygwin development team informing them that this needs to be > addressed some day.) I don't recall running into this one, but it would not surprise me if something like this was the case. I've gotten some strange things happening with CygWin if I have KDE or the X11 packages installed AND I also have the DISPLAY environment variable set to something. It's been a long time, so I don't remember exactly what the case was. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Visualising forces
Jim Wilson writes: > > Currently it is > possible to control all aspects of the camera position and angle through the > property tree (in the /sim/current-view path), I see 'heading' and 'pitch' but not 'roll'. I guess I must be missing something ? Best Norman "/sim/current-view/heading-offset-deg" "/sim/current-view/goal-heading-offset-deg" "/sim/current-view/pitch-offset-deg" "/sim/current-view/goal-pitch-offset-deg" "/sim/field-of-view" "/sim/current-view/view-number" "/sim/current-view/axes/long" "/sim/current-view/axes/lat" "/sim/current-view/ground-level-nearplane-m" ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgfs.cxx
i assume fgfs.cxxfgfs.hxx get created by the configure script as i don't see them in the Main directory. since i can't get configure to work, is there anyway someone who is using .NET/Vc7 can send me these files? thanks, john ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] wrong plib version (but I have the right version 1.6.0)
i'm using msvstudio .NET . i've installed cygwin and run autogen.sh. but when i run configure i get the following output: which says configure is finding the wrong version of plib. it want 1.6.0 but i've tried both 1.6.0 AND 1.7.0. has anyone seen this before? $ ./configurechecking for a BSD-compatible install... /usr/bin/install -cchecking whether build environment is sane... yeschecking for gawk... gawkchecking whether make sets $(MAKE)... yeschecking whether make sets $(MAKE)... (cached) yeschecking for gcc... /cygdrive/c/msvstudio/Vc7/bin/cl.exechecking for C compiler default output file name... conftest.exechecking whether the C compiler works... yeschecking whether we are cross compiling... nochecking for suffix of executables... .exechecking for suffix of object files... objchecking whether we are using the GNU C compiler... nochecking whether /cygdrive/c/msvstudio/Vc7/bin/cl.exe accepts -g... yeschecking for /cygdrive/c/msvstudio/Vc7/bin/cl.exe option to accept ANSI C... none neededchecking for style of include used by make... GNUchecking dependency style of /cygdrive/c/msvstudio/Vc7/bin/cl.exe... nonechecking how to run the C preprocessor... /cygdrive/c/msvstudio/Vc7/bin/cl.exe -Echecking whether we are using the GNU C++ compiler... nochecking whether /cygdrive/c/msvstudio/Vc7/bin/cl.exe accepts -g... nochecking dependency style of /cygdrive/c/msvstudio/Vc7/bin/cl.exe... nonechecking for ranlib... ranlibchecking for a BSD-compatible install... /usr/bin/install -cchecking whether ln -s works... yeschecking build system type... i686-pc-cygwinchecking host system type... i686-pc-cygwinBuilding with default multiplayer supportBuilding with FGEnvironmentchecking for egrep... grep -Echecking for ANSI C header files... yeschecking for sys/types.h... yeschecking for sys/stat.h... yeschecking for stdlib.h... yeschecking for string.h... yeschecking for memory.h... yeschecking for strings.h... nochecking for inttypes.h... nochecking for stdint.h... nochecking for unistd.h... nochecking pthread.h usability... nochecking pthread.h presence... nochecking for pthread.h... nochecking windows.h usability... yeschecking windows.h presence... yeschecking for windows.h... yeschecking for extra include and lib directories... + found /usr/X11R6/include + found /usr/X11R6/libchecking int daylight variable... yeschecking long timezone variable... yesno fancy X11 checkchecking for pthread_exit in -lpthread... nochecking for library containing inet_addr... nochecking for library containing socket... nochecking for library containing main... none requiredchecking for library containing cos... none requiredchecking for library containing dlclose... nochecking GL/glut.h usability... yeschecking GL/glut.h presence... yeschecking for GL/glut.h... yesWin32 specific hacks...Will link apps with -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32checking how to run the C++ preprocessor... /cygdrive/c/msvstudio/Vc7/bin/cl.exe -Echecking plib/ul.h usability... nochecking plib/ul.h presence... yesconfigure: WARNING: plib/ul.h: present but cannot be compiledconfigure: WARNING: plib/ul.h: check for missing prerequisite headers?configure: WARNING: plib/ul.h: see the Autoconf documentationconfigure: WARNING: plib/ul.h: section "Present But Cannot Be Compiled"configure: WARNING: plib/ul.h: proceeding with the preprocessor's resultconfigure: WARNING: plib/ul.h: in the future, the compiler will take precedenceconfigure: WARNING: ## -- ##configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ##configure: WARNING: ## -- ##checking for plib/ul.h... yeschecking for plib 1.6.0 or newer... wrong versionconfigure: error: Install plib 1.6.0 or later first... John [EMAIL PROTECTED] /cygdrive/c/Play/FlightGear-0.9.3 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Problem Under Cygwin
Hopefully someone who knows the answer will jump in and correct me if I'm wrong, but this sounds like the errors people were getting when they installed the cygwin X11 packages. These provide conflicting versions of the opengl headers which cause the build to fail. I think the current solution is to uninstall the X11 packages (and possibly send a nice note off to the cygwin development team informing them that this needs to be addressed some day.) Regards, Curt. Jonathan Polley wrote: I just tried to build FlightGear under Cygwin. When I build, I get the following: In file included from glut_shapes.c:59: /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token In file included from glut_shapes.c:61: glut_shapes.h:12:1: warning: "APIENTRY" redefined In file included from /usr/include/w32api/GL/glu.h:37, from glut_shapes.c:59: /usr/include/w32api/GL/gl.h:80:1: warning: this is the location of the previous definition make[5]: *** [glut_shapes.o] Error 1 make[5]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky/cloud s3d' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' make: *** [all-recursive] Error 1 This is true even after I do a make clean. Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Build Problem Under Cygwin
I just tried to build FlightGear under Cygwin. When I build, I get the following: In file included from glut_shapes.c:59: /usr/include/w32api/GL/glu.h:230: error: syntax error before '*' token In file included from glut_shapes.c:61: glut_shapes.h:12:1: warning: "APIENTRY" redefined In file included from /usr/include/w32api/GL/glu.h:37, from glut_shapes.c:59: /usr/include/w32api/GL/gl.h:80:1: warning: this is the location of the previous definition make[5]: *** [glut_shapes.o] Error 1 make[5]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky/cloud s3d' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene/sky' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear/scene' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/jwpolley/fgdev/SimGear/simgear' make: *** [all-recursive] Error 1 This is true even after I do a make clean. Thanks, Jonathan Polley Of COURSE they can do that. They're engineers! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Visualising forces
> > Currently I think we're interested in making the viewer and FDM totally > > independent of each other, so something else that manipulates the property > > tree values would be the best way to go. > > Extreme G's, obviously, should slam the head around a bit. Maybe the nasal script could do this: if G's > 3 or 4 then peripheral vision disappears, and you start to get tunnel vision if G's < -1 or -2 for a second or two then entire screen has a reddish tint to it (Decathalons sure can be fun!) Wendell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Visualising forces
David Megginson said: > Jim Wilson wrote: > > > Currently I think we're interested in making the viewer and FDM totally > > independent of each other, so something else that manipulates the property > > tree values would be the best way to go. My thought is the viewer is on its > > way to SimGear soon. Anyway, just wanted to mention this before something > > was added to make the viewer more FDM dependent. Maybe this is another nasal > > script candidate? > > We had something like that for a while with the 2D panel, but it wasn't on > by default and I don't think many people used it. > > There's no need to add a direct dependency: the forces are all published to > the property tree, and the viewer could optionally use them from there. > Personally, I've never experienced more than 2G or less than (close to) 0G > in flight, and neither forces much head movement: you sense it more through > your muscle resistence than your head actually moving up/down/left/right. > Extreme G's, obviously, should slam the head around a bit. That's pretty much that same as what I said, except that the viewer should not start using hardcoded FDM output paths. Doing that is not going to be a whole lot different than a adding a direct c++ dependency. Currently it is possible to control all aspects of the camera position and angle through the property tree (in the /sim/current-view path), so it'd probably make sense to at least prototype using the scripting tool. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Visualising forces
Not to mention blackout/redout from extreme G's. -Ethan >From: David Megginson <[EMAIL PROTECTED]> >Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> >To: FlightGear developers discussions <[EMAIL PROTECTED]> >Subject: Re: [Flightgear-devel] Visualising forces >Date: Mon, 15 Mar 2004 18:29:42 -0500 >MIME-Version: 1.0 >Received: from baron.me.umn.edu ([128.101.142.119]) by mc1-f3.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Mon, 15 Mar 2004 15:30:32 -0800 >Received: from localhost ([127.0.0.1] helo=baron.me.umn.edu)by baron.me.umn.edu with esmtp (Exim 3.36 #1 (Debian))id 1B31XL-0007oq-00; Mon, 15 Mar 2004 17:30:23 -0600 >Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull)by baron.me.umn.edu with esmtp (Exim 3.36 #1 (Debian))id 1B31Wm-0007oj-00for <[EMAIL PROTECTED]>; Mon, 15 Mar 2004 17:29:48 -0600 >Received: from cpe000c414eb955-cm014490118788.cpe.net.cable.rogers.com([24.43.66.150] helo=attglobal.net)by outbound.mailhop.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.20)id 1B31Wk-000AwW-RHfor [EMAIL PROTECTED]; Mon, 15 Mar 2004 18:29:47 -0500 >X-Message-Info: QIy1oIULmHch3Nn8PmebqGz+fqP5Na8O >Message-ID: <[EMAIL PROTECTED]> >User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;rv:1.6) Gecko/20040312 Debian/1.6-3 >X-Accept-Language: en >References: <[EMAIL PROTECTED]> >In-Reply-To: <[EMAIL PROTECTED]> >X-Mail-Handler: MailHop Outbound by DynDNS.org >X-Report-Abuse-To: [EMAIL PROTECTED] >X-MHO-User: dmeggin >X-BeenThere: [EMAIL PROTECTED] >X-Mailman-Version: 2.1.4 >Precedence: list >List-Id: FlightGear developers discussions >List-Unsubscribe: , >List-Archive: >List-Post: >List-Help: >List-Subscribe: , >Errors-To: [EMAIL PROTECTED] >Return-Path: [EMAIL PROTECTED] >X-OriginalArrivalTime: 15 Mar 2004 23:30:34.0779 (UTC) FILETIME=[83C5E6B0:01C40AE5] > >Jim Wilson wrote: > >>Currently I think we're interested in making the viewer and FDM >>totally >>independent of each other, so something else that manipulates the >>property >>tree values would be the best way to go. My thought is the viewer >>is on its >>way to SimGear soon. Anyway, just wanted to mention this before >>something >>was added to make the viewer more FDM dependent. Maybe this is >>another nasal >>script candidate? > >We had something like that for a while with the 2D panel, but it >wasn't on by default and I don't think many people used it. > >There's no need to add a direct dependency: the forces are all >published to the property tree, and the viewer could optionally use >them from there. Personally, I've never experienced more than 2G or >less than (close to) 0G in flight, and neither forces much head >movement: you sense it more through your muscle resistence than your >head actually moving up/down/left/right. Extreme G's, obviously, >should slam the head around a bit. > > >All the best, > > >David > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel Fast. Reliable. Get MSN 9 Dial-up - 3 months for the price of 1! (Limited-time Offer) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Visualising forces
Jim Wilson wrote: Currently I think we're interested in making the viewer and FDM totally independent of each other, so something else that manipulates the property tree values would be the best way to go. My thought is the viewer is on its way to SimGear soon. Anyway, just wanted to mention this before something was added to make the viewer more FDM dependent. Maybe this is another nasal script candidate? We had something like that for a while with the 2D panel, but it wasn't on by default and I don't think many people used it. There's no need to add a direct dependency: the forces are all published to the property tree, and the viewer could optionally use them from there. Personally, I've never experienced more than 2G or less than (close to) 0G in flight, and neither forces much head movement: you sense it more through your muscle resistence than your head actually moving up/down/left/right. Extreme G's, obviously, should slam the head around a bit. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Visualising forces
Roy Vegard Ovesen said: > How about shifting the pilot-viewpoint-posistion proportional to the > forces that act on the pilot in order to visualise them. A high g force > would push the pilot down in his seat, shifting the viewpoint down etc. > > This is used in "IL-2 Sturmovik" and I think it does a good job of showing > the forces that the pilot experience. > Currently I think we're interested in making the viewer and FDM totally independent of each other, so something else that manipulates the property tree values would be the best way to go. My thought is the viewer is on its way to SimGear soon. Anyway, just wanted to mention this before something was added to make the viewer more FDM dependent. Maybe this is another nasal script candidate? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Test flights to test IGC file format
>> I'm trying to add import/export of IGC file formats capability (within the >> Network folder, as nmea, garmin, atlas, etc.) >This is a great idea ! Thank you. >Therefore we have simulators :-) you're completely right >For real life IGC files you might want to ask the people at KFlog, >http://www.kflog.org/. I'm sure they can supply you with anything you need I've just downloaded the Kflog source code. I'm planning to use it to validate the FG-generated IGC files when I just finished the generating code. What I was looking is for FLIGHTGEAR native files for small flights, just to save me time to put the FG simulator to fly by myself (I'm not good doing so at the moment). If someone could provide me with several flights of different flying conditions that will undoubtely save me time to test the IGC files generation Thank you for your interest. - ¿Todavía no navegás con Keko? Hacé click aquí: http://www.keko.com.ar ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Visualising forces
How about shifting the pilot-viewpoint-posistion proportional to the forces that act on the pilot in order to visualise them. A high g force would push the pilot down in his seat, shifting the viewpoint down etc. This is used in "IL-2 Sturmovik" and I think it does a good job of showing the forces that the pilot experience. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AIRCRAFT DESIGN
Josh Babcock wrote: I always wondered why LOD is generally calculated based on distance in sims, and not on the number of polys rendered. Distance is pretty meaningless when you have a a variable FOV, which lots of 3d sims and games do. Is there some reason I don't know about other than habit? Distance is something that is easy and simple and inexpensive to calculate which is important if you are drawing hundreds of models. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] xml - multiple includes
> The problem there is that whitespace is allowed in filenames on some OS's, > so we'd have to escape it, and things would get fairly messy. Thanks Dave, I'll just keep the autothrottle stuff separate and leave the rest where it is. That'll do. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AIRCRAFT DESIGN
[EMAIL PROTECTED] wrote: Curts, I am trying to undestand the aircraft development. I started reading the UFO design, I read ufo.cxx and I would like to know if there is a tool to change the UFO model. Regards, Carlos Renato I always wondered why LOD is generally calculated based on distance in sims, and not on the number of polys rendered. Distance is pretty meaningless when you have a a variable FOV, which lots of 3d sims and games do. Is there some reason I don't know about other than habit? Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] xml - multiple includes
David Culp wrote: I'm trying to reduce the 737 xmlauto config to a manageable size by splitting it up into three parts, one each for autothrottle, pitch modes, and roll modes. This won't parse: Is there a way to do multiple includes (other than an include for each pid-controller seperately, which would be a last resort)? XML attribute names have to be unique. We could change to code to support something like this: ... The problem there is that whitespace is allowed in filenames on some OS's, so we'd have to escape it, and things would get fairly messy. The best approach is usually to do the include off of a subelement instead, but I see how that's awkward with all the top-level pid-controller elements. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Training costs
From: Martin Spott <[EMAIL PROTECTED]> > David Megginson wrote: >> Fuel costs don't help, obviously, but they're a relatively small percentage >> of the cost of operating a plane (i.e. doubling the fuel cost might increase >> the >> cost of flying by 25%). Is maintenance more expensive? Is it taxation >> and government fees? Obviously, the money's not going into the equipment >> they rent you. > > Maintenance _is_ expensive, because aircraft used for commercial > training (not in a flight club) need to have commercial maintenance. > Another part is fuel cost, because we're supposed to pay twice as much > in Europe compared to North America. > And - last but not least - the owner of an aircraft probably needs to > pay the rates to his bank you need some sort of amortization. > > > At the Ottawa Flying Club, the 150's that most people train in do not have > > DME, [...] > > The 150 that I fly most of the time doesn't even have an artificial > horizon :-) For the San Diego rental market, where a non-modern non-upgraded IFR C172 (eg 160 hp, N series, dual NAV/COM, ILS/DME) rents for about $1/minute, that cost splits into four equal $0.25/minute components for the following: * Fuel (including fuel taxes), which is about $1/gal more than car fuel; * Insurance (minimum hull and third party liability); * Maintenance (airframe, engine and avionics only), includes owner repairs; * Overhead (parking, washing, administration, etc, etc). You're welcome to draw your own conclusions from those numbers. If the facility's accident rate, or the airport accident rate, is equal to or greater than the national average, the insurance cost basically doubles. Note that depreciation is not listed, since older C172s do not lose value, and there is no allowance in those numbers for any profit for the owner. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AIRCRAFT DESIGN
[EMAIL PROTECTED] wrote: Curts, I am trying to undestand the aircraft development. I started reading the UFO design, I read ufo.cxx and I would like to know if there is a tool to change the UFO model. Hi Carlos, If you are you trying to create a new aircraft, then for most normal cases you shouldn't need to do anything with the code. I've never personally created an aircraft, but in general you need to: 1. Configure the flight dynamics model. Typically you would pick JSBSim if you have a lot of detailed flight information and need/want to match the original plane very closely. Otherwise, if you have sketchy flight information or want something that flies reasonably well, and want to get going quickly, YASim is a good choice. Both involve creating an ascii config file with the proper parameters. 2. Make a 3d model. If you want a pretty picture from an outside view you can create a 3d model and texture it. You can set up gear and control surfaces and do a variety of complex and cool animations. Check out the gear on the yf23 or seahawk which includes animated suspention. 3. Create an instrument panel. You can build a fully interactive 3d cockpit if you like. People have put in pilots with animated arms and legs and done other crazy stuff. 3d cockpits can be fully "clickable" and interactive if you set them up that way. 4. Take care of some of the details like creating a custom sound configuration if you want, creating a detailed electrical model if you like, and setting up the various autopilot modes and tweaking the gains for your aircraft. None of these require any programming or compiling. You can do all of it, including building custom instruments by editing text files and creating objects in your favorite 3d modeling package. The J3 Cub might be a reasonably simple example to look at for just starting out. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: xml - multiple includes
* David Culp -- Monday 15 March 2004 16:04: > I'm trying to reduce the 737 xmlauto config to a manageable size by splitting > it up into three parts, one each for autothrottle, pitch modes, and roll > modes. This won't parse: > >include="737-autopilot-pitch-modes.xml" > include="737-autopilot-roll-modes.xml"> > What about this: ... not that I've tried ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
On 15 Mar 2004 at 15:11, Erik Hofman wrote: > D Luff wrote: > > > c172, and possibly more involved, is there any chance of putting a range LOD on > > the whole > > model that swaps it out for a very low poly version from a certain distance away? > > I have no > > idea of the work involved to create a low poly version from an existing model, so > > please forgive > > this request if it's a time-consuming task. > > Maybe you could quit rapidly go to a model consisting of three > double-sided, textured quads that are perpendicular to each other (X,Y,Z)? > The trouble is that it's possible to zoom in quite a lot whilst flying to see what the AI traffic are up to, but due to the nature of the zoom (fov reduction) I suspect that the LOD of the model won't change, so it would be best if it looked at least something like what it's meant to! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
On 15 Mar 2004 at 9:41, David Megginson wrote: > D Luff wrote: > > > Couple of requests - could the pa28 instruments get a range lod in the same manner > > as the > > c172, and possibly more involved, is there any chance of putting a range LOD on > > the whole > > model that swaps it out for a very low poly version from a certain distance away? > > I have no > > idea of the work involved to create a low poly version from an existing model, so > > please forgive > > this request if it's a time-consuming task. > > It's not a hard task. Blender has a face-reduction function built in that > does a wonderful job simplifying models -- the only problem is that you lose > the UV mappings, so you have to spend an hour or so remapping textures. > > I will happily make the source for any of my Blender models (pa28, c172p, > j3cub, dc3) available to anyone who wants to play with them; as a matter of > fact, we should probably set up a permanent home for this stuff (*not* in > the base package, though). > Could you mail me the pa28 and c172dpm (the yellowish one) source please, and I'll have a play at some point. The low poly versions can loose their textures anyway - over half a mile away it shouldn't matter. A separate CVS repository of base file sources would be an excellent idea - there's other stuff besides models such as the docs that could benefit. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] xml - multiple includes
I'm trying to reduce the 737 xmlauto config to a manageable size by splitting it up into three parts, one each for autothrottle, pitch modes, and roll modes. This won't parse: Is there a way to do multiple includes (other than an include for each pid-controller seperately, which would be a last resort)? Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: AIRCRAFT DESIGN
Now more serious ... * [EMAIL PROTECTED] -- Monday 15 March 2004 15:37: > I started reading the UFO design, I read ufo.cxx and I would like to know if > there is a tool to change the UFO model. What do you mean? Change the 3D model? Any 3D modeler that can generate plib supported file formats should do. http://www.blender.org/ is IMHO a good choice. (It's the ufo.ac file.) Or change the flight model? ufo.cxx *is* the flight model of the ufo. There isn't anything else. If you want to model aircrafts, you should look at how YASim or JSBSim aircrafts are defined (see the *.xml files in the respective directories). m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AIRCRAFT DESIGN
[EMAIL PROTECTED] wrote: Curts, I am trying to undestand the aircraft development. I started reading the UFO design, I read ufo.cxx and I would like to know if there is a tool to change the UFO model. To be honest, the UFO is the worst model to look at when you want to add an aircraft because it has it's own (very simple) FDM written in C++. You would be better of looking at YASim (FlightGear/data/Aircraft-yasim/README.yasim) or JSBSim (http://www.jsbsim.org) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: AIRCRAFT DESIGN
* [EMAIL PROTECTED] -- Monday 15 March 2004 15:37: > Curts, Sorry, I'm no Curt (yet) ... > I started reading the UFO design, I read ufo.cxx and I would like to know if > there is a tool to change the UFO model. Yes. vi(m) m. ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
D Luff wrote: Couple of requests - could the pa28 instruments get a range lod in the same manner as the c172, and possibly more involved, is there any chance of putting a range LOD on the whole model that swaps it out for a very low poly version from a certain distance away? I have no idea of the work involved to create a low poly version from an existing model, so please forgive this request if it's a time-consuming task. It's not a hard task. Blender has a face-reduction function built in that does a wonderful job simplifying models -- the only problem is that you lose the UV mappings, so you have to spend an hour or so remapping textures. I will happily make the source for any of my Blender models (pa28, c172p, j3cub, dc3) available to anyone who wants to play with them; as a matter of fact, we should probably set up a permanent home for this stuff (*not* in the base package, though). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AIRCRAFT DESIGN
Curts, I am trying to undestand the aircraft development. I started reading the UFO design, I read ufo.cxx and I would like to know if there is a tool to change the UFO model. Regards, Carlos Renato ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Low poly model LOD request
D Luff wrote: c172, and possibly more involved, is there any chance of putting a range LOD on the whole model that swaps it out for a very low poly version from a certain distance away? I have no idea of the work involved to create a low poly version from an existing model, so please forgive this request if it's a time-consuming task. Maybe you could quit rapidly go to a model consisting of three double-sided, textured quads that are perpendicular to each other (X,Y,Z)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Low poly model LOD request
I'm currently using the pa28-161 and the c172-dpm models for the AI traffic, both of which I believe are David M's models. These are great models, but there can be quite a few flying around in the field of view within a few miles, and this can have quite an impact on frame rates. And that's without even thinking about statics! Couple of requests - could the pa28 instruments get a range lod in the same manner as the c172, and possibly more involved, is there any chance of putting a range LOD on the whole model that swaps it out for a very low poly version from a certain distance away? I have no idea of the work involved to create a low poly version from an existing model, so please forgive this request if it's a time-consuming task. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio dialog freqency precision
David Luff wrote: The radio dialog seems to have some precision issues. Using the internal property browser, it can be seen that com2 (comm[1] in the internal tree) is set to 118.3 before using the radio dialog. Using the dialog to set com1 to 118.1, it can be seen from the properties that com1 and com2 are now set to 118.08 and 118.33 respectively. I've added an epsilon to the AI code to get the transmissions to show up where applicable, but I'm not entirely sure that the radio dialog should be doing this! We could avoid this problem by using integers instead of floating-point numbers: for example, instead of frequency-mhz=118.8 we could have frequency-khz=118800 That would probably confuse the hell out of people, though. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Training costs
Martin Spott wrote: Maintenance _is_ expensive, because aircraft used for commercial training (not in a flight club) need to have commercial maintenance. Another part is fuel cost, because we're supposed to pay twice as much in Europe compared to North America. And - last but not least - the owner of an aircraft probably needs to pay the rates to his bank you need some sort of amortization. Yes, but all three of these apply in North America as well: maintenance standards are higher for commercially-registered aircraft, commerical insurance costs are ridiculous (they've forced many FBOs and schools out of business since September 11 2001), and North American FBO's also have bank loans to pay. You can factor out the fuel cost by looking at dry rental rates. For example, in Ottawa a Cessna 150 rents for CAD 69/hour (USD 53/hour) dry. There must be a reason that the same couldn't apply in Europe, only with the pilot paying USD 30-40/hour for fuel instead of USD 15-20/hour. I'm betting that government intervention (regulation, taxes, etc.) has something to do with it. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] tile queue
On 15 Mar 2004 at 7:14, David Culp wrote: > I'm getting alot of this: "Alert: catching up on tile delete queue" > on the console, in "quiet mode", while flying the T-38. There doesn't seem to > be any effect on the sim, though. Is there a way to make this go away? > > see http://baron.flightgear.org/pipermail/flightgear-devel/2004-February/025791.html You can make it go away by moving the tile manager initialisation in fg_init.cxx from before the view initialisation to after it. As far as I can see from a fair bit of testing this has no adverse affect on the fdm or viewer init, but I haven't checked through the fdm init code enough to actively push for this change yet. I have sometimes seen a slight pause on a Cygwin box when this happens, it's definitely something that should be sorted at some point. The pollution of the tile cache by the AI code mentioned in the thread above should now be fixed in CVS - AI traffic now only determines ground elev when in visual range, which by definition means with an already loaded tile. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] tile queue
I'm getting alot of this: "Alert: catching up on tile delete queue" on the console, in "quiet mode", while flying the T-38. There doesn't seem to be any effect on the sim, though. Is there a way to make this go away? Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Radio dialog freqency precision
The radio dialog seems to have some precision issues. Using the internal property browser, it can be seen that com2 (comm[1] in the internal tree) is set to 118.3 before using the radio dialog. Using the dialog to set com1 to 118.1, it can be seen from the properties that com1 and com2 are now set to 118.08 and 118.33 respectively. I've added an epsilon to the AI code to get the transmissions to show up where applicable, but I'm not entirely sure that the radio dialog should be doing this! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Training costs
David Megginson wrote: > Fuel costs don't help, obviously, but they're a relatively small percentage > of the cost of operating a plane (i.e. doubling the fuel cost might increase > the cost of flying by 25%). Is maintenance more expensive? Is it taxation > and government fees? Obviously, the money's not going into the equipment > they rent you. Maintenance _is_ expensive, because aircraft used for commercial training (not in a flight club) need to have commercial maintenance. Another part is fuel cost, because we're supposed to pay twice as much in Europe compared to North America. And - last but not least - the owner of an aircraft probably needs to pay the rates to his bank you need some sort of amortization. > At the Ottawa Flying Club, the 150's that most people train in do not have > DME, [...] The 150 that I fly most of the time doesn't even have an artificial horizon :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem compiling latest jsbsim
Frederic Bouvier wrote: Hi, I have problems compiling today's JSBsim with MSVC. I had to patch the sources like this : ; - SG_USING_STD(sqrt); +// SG_USING_STD(sqrt); because sqrt is not a member of std:: Is this declaration really necessary ? I see that is included 11 lines before and it should declare sqrt in the global namespace, not in the std namespace, so why a 'using std::sqrt;' here ? Is it required for cygwin or linux or another unix ? Actually I have no idea how math.h could define something in namespace std since it is a C header file. Maybe most unices put C definitions in namespace std by default, but they *must* be available outside of the std namespace also (IMHO). Committed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
