[Flightgear-devel] TerraGear on AIX ....
After the psychological strain increased significantly ;-) I tried to build the whole TerraGear stuff on my RS6k. This is a really laborious taks because you have to provide lots of manual fixes (GTS' 'configure' fails to parse `glib-config --version`, Makefiles often miss '-lsgstructure -lsgprops', sometimes include SimGear libraries that are not necessary at all , lots of other stupid things without a common schema :-(( Finally I got to this point: osprey: 14:13:04 /usr/local/src/TerraGear/src/Prep/GSHHS make [...] g++ -mcpu=604e -mtune=604e -mpowerpc-gpopt -mpowerpc-gfxopt -O3 -L/opt/gnu/lib -L/usr/local/lib -L/opt/freeware/lib -static-libgcc -s -L/opt/FlightGear/lib -L/usr/X11R6/lib -o gshhs main.o gshhs_split.o ../../../src/Lib/Polygon/libPolygon.a ../../../src/Lib/Geometry/libGeometry.a ../../../src/Lib/poly2tri/libpoly2tri.a -lsgdebug -lsgbucket -lsgmath -lsgmisc -lsgstructure -lsgprops -lsgxml -lgenpolyclip -lz -lm ld: 0711-317 ERROR: Undefined symbol: .zero_triangulateio ld: 0711-317 ERROR: Undefined symbol: .triangulate ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: *** [gshhs] Error 1 I'd think these symbols should be part of 'libgts', at least other similar symbols are, but these two are not. Does this stem from the fact that I use GTS-0.7.3 maybe instead of GTS-0.7.2 ? 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TerraGear on AIX ....
Quoting Martin Spott : After the psychological strain increased significantly ;-) I tried to build the whole TerraGear stuff on my RS6k. This is a really laborious taks because you have to provide lots of manual fixes (GTS' 'configure' fails to parse `glib-config --version`, Makefiles often miss '-lsgstructure -lsgprops', sometimes include SimGear libraries that are not necessary at all , lots of other stupid things without a common schema :-(( Finally I got to this point: osprey: 14:13:04 /usr/local/src/TerraGear/src/Prep/GSHHS make [...] g++ -mcpu=604e -mtune=604e -mpowerpc-gpopt -mpowerpc-gfxopt -O3 -L/opt/gnu/lib -L/usr/local/lib -L/opt/freeware/lib -static-libgcc -s -L/opt/FlightGear/lib -L/usr/X11R6/lib -o gshhs main.o gshhs_split.o ../../../src/Lib/Polygon/libPolygon.a ../../../src/Lib/Geometry/libGeometry.a ../../../src/Lib/poly2tri/libpoly2tri.a -lsgdebug -lsgbucket -lsgmath -lsgmisc -lsgstructure -lsgprops -lsgxml -lgenpolyclip -lz -lm ld: 0711-317 ERROR: Undefined symbol: .zero_triangulateio ld: 0711-317 ERROR: Undefined symbol: .triangulate ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: *** [gshhs] Error 1 I'd think these symbols should be part of 'libgts', at least other similar symbols are, but these two are not. Does this stem from the fact that I use GTS-0.7.3 maybe instead of GTS-0.7.2 ? GTS was only used for terrafit ( or was it arrayfit ? ) that was superceded by the python version terrafit.py The other utilities and libraries do not use GTS. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Getting data out of FlightGear
As promised, I've attached the files that I modified to make FlightGear work with my client software. These modifications allow my client software to receive the correct values out of FlightGear using the native-fdm network setting. I started with the FlightGear v0.9.6 release files to make the changes, so any changes made to these files in CVS since this release have not been incorporated. Also, these modifications were developed and tested on a Windows (WinXP) machine only. However, I was able to build FlightGear with both Cygwin and VC++ v6.0 using these modifications and found no difference in the performance. Thanks again to all of those who responded to my plea for help! I hope that I can repay the help that you have provided me. I'm a newbie as far as FlightGear is concerned, but based on my work and my experience with FlightGear, I hope to try and get more involved with using and developing/adding on to the software. chuck net_fdm.hxx Description: Binary data native_fdm.cxx Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TerraGear on AIX ....
Frederic Bouvier wrote: The other utilities and libraries do not use GTS. Aaah, I see, apparently 'libGeometry.a' provides and uses these calls: osprey: 15:14:29 /usr/local/src/TerraGear/src/Prep/GSHHS nm ../../../src/Lib/Geometry/libGeometry.a | grep triangulate .triangulate U - .zero_triangulateio U - but the linker apparently fails to handle this correctly. Might this be an explanation that aims at the correct target ? 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 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] How does the Replay Subsystem work?
Title: How does the Replay Subsystem work? Hi, I am trying to read flight data from a FDR (Flight Data Recorder, black box) and input some of the data into FlightGear's Replay system to display the flight. If using the Replay functionality in the FlightGear and I only care some of the values such as: -Longitude, latitude, altitude, agl -v_north, v_east, v_down -phi, theta, psi All these for displaying the aircraft's attitude, position, trajectory. While I don't care those values such as control surfaces, engines status, instruments related, and etc. I tried to import the data (lon,lat,) I want to use into the Replay subsystem and hardcode those control surfaces, engines/tanks status, and etc. At the beginning, I set the replay_master as true and I got the program started in replay mode. But the problem is, I failed to see the aircraft moving which supposed to be because I have the lon, lat, alt, groundspeed keep changing. So my question is, how does the Replay subsystem work in FlightGear? Does it use the control surfaces' (and other control elements like engines) changes as the inputs and then use the FDM to recalculate all the outputs again? Can anyone give me any guidance on what direction I should go? Appreciate if I can get your input. Thanks! Regards, Heckel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TerraGear on AIX ....
Frederic Bouvier wrote: The other utilities and libraries do not use GTS. Fine, the following patch removes the dependency on GTS. Can we now drop GLIB as well ? - snip -- --- configure.ac.original Mon Aug 2 14:09:10 2004 +++ configure.acTue Nov 30 15:30:53 2004 @@ -51,10 +51,9 @@ AC_SUBST(AR) AC_SUBST(ARFLAGS) -dnl Add gts/glib includes, this will probably need to be made more +dnl Add glib includes, this will probably need to be made more dnl flexible in the future. AC_CHECK_PROG(GLIB, glib-config, yes, no) -AC_CHECK_PROG(GTS, gts-config, yes, no) if test $GLIB = no; then echo @@ -69,21 +68,7 @@ exit 1 fi -if test $GTS = no; then - echo - echo Unable to find gts-config. - echo - echo This program is needed to determine the compiler flags needed for - echo the gts library. Please make sure this linrary is installed and - echo the program is in the search path. - echo - echo Please read README.gts for more details. - echo - exit 1 - -fi - -SUPPORT_FLAGS=`gts-config --cflags` `glib-config --cflags` +SUPPORT_FLAGS=`glib-config --cflags` CPPFLAGS=$CPPFLAGS $SUPPORT_FLAGS #CFLAGS=$CFLAGS $SUPPORT_FLAGS #CXXFLAGS=$CXXFLAGS $SUPPORT_FLAGS @@ -144,7 +129,7 @@ AC_SEARCH_LIBS(cos, m) base_LIBS=$LIBS -support_LIBS=`gts-config --libs` `glib-config --libs` +support_LIBS=`glib-config --libs` AC_SEARCH_LIBS(XCreateWindow, X11) AC_SEARCH_LIBS(XShmCreateImage, Xext) @@ -253,18 +238,6 @@ AC_CHECK_HEADER(nurbs++/nurbsS.h) AM_CONDITIONAL(HAVE_NURBS, test x$ac_cv_header_nurbspp_nurbsS_h = xyes ) AC_LANG_POP - -AC_CHECK_HEADER(gts.h) -if test x$ac_cv_header_gts_h != xyes; then -echo -echo You *must* have the gts library installed on your system to build -echo TerraGear! -echo -echo Please see README.gts for more details. -echo -echo configure aborted. -exit -fi dnl Check if Generic Polygon Clipping library is installed dnl (from http://www.cs.man.ac.uk/aig/staff/alan/software/) - snip -- 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TerraGear on AIX ....
Quoting Martin Spott : Frederic Bouvier wrote: The other utilities and libraries do not use GTS. Fine, the following patch removes the dependency on GTS. Can we now drop GLIB as well ? Yes, but you need to remove ArrayFit from Prep/Makefile.am -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data In directory baron:/tmp/cvs-serv3809 Modified Files: preferences.xml Log Message: Comment out the nimitz for now. Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott [EMAIL PROTECTED] Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? It uses the AC3D crease directive, which stock plib doesn't support. More importantly, FlightGear still tries to load the Nimitz even when I'm starting at an airport thousands of miles from KSFO. Is there any way to bind those AI's to a specific area, the way we do with static scenery? All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TerraGear on AIX ....
Frederic Bouvier wrote: Yes, but you need to remove ArrayFit from Prep/Makefile.am and 'testgts' from Array/Makefile.am (which appears to be the only reference to GTS): --- Makefile.am.originalSat Aug 30 14:00:15 2003 +++ Makefile.am Tue Nov 30 15:50:19 2004 @@ -2,7 +2,7 @@ libArray_a_SOURCES = array.cxx array.hxx -noinst_PROGRAMS = testarray testgts +noinst_PROGRAMS = testarray testarray_SOURCES = testarray.cxx @@ -10,12 +10,5 @@ $(top_builddir)/src/Lib/Array/libArray.a \ -lsgbucket -lsgmath -lsgmisc -lsgdebug -lsgxml \ $(support_LIBS) -lz - -testgts_SOURCES = testgts.cxx - -testgts_LDADD = \ - $(top_builddir)/src/Lib/Array/libArray.a \ - -lsgbucket -lsgmath -lsgmisc -lsgdebug -lsgxml \ - $(support_LIBS) -lz INCLUDES = -I$(top_srcdir)/src Thanks, 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
David Megginson wrote: On Tue, 30 Nov 2004 14:55:29 + (UTC), Martin Spott [EMAIL PROTECTED] Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? It uses the AC3D crease directive, which stock plib doesn't support. At 03:47 today. Modified Files: nimitz.ac Log Message: Remove crease tag so that people without custom patched versions of plib can still run FlightGear. :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
* Martin Spott -- Tuesday 30 November 2004 15:55: Erik Hofman wrote: Comment out the nimitz for now. Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? Yes, he did. But Vivian's changes from today refer to a file nimitz-complex.ac, which isn't in CVS, and was apparently not sent to Erik. This made fgfs abort for me: WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\ Models/Geometry/Nimitz/nimitz-complex.ac' for reading Fatal error: Failed to load 3D model There are other things to fix as well. While landing the FA-18A on the carrier worked beautifully after applying Mathias' patches directly, the recent changes to cvs don't allow carrier landings at all. The aircraft falls through the deck, even though I have the alternative carrier-enabled JSBSim version still installed. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TerraGear on AIX ....
Martin Spott wrote: osprey: 14:13:04 /usr/local/src/TerraGear/src/Prep/GSHHS make [...] g++ -mcpu=604e -mtune=604e -mpowerpc-gpopt -mpowerpc-gfxopt -O3 -L/opt/gnu/lib -L/usr/local/lib -L/opt/freeware/lib -static-libgcc -s -L/opt/FlightGear/lib -L/usr/X11R6/lib -o gshhs main.o gshhs_split.o ../../../src/Lib/Polygon/libPolygon.a ../../../src/Lib/Geometry/libGeometry.a ../../../src/Lib/poly2tri/libpoly2tri.a -lsgdebug -lsgbucket -lsgmath -lsgmisc -lsgstructure -lsgprops -lsgxml -lgenpolyclip -lz -lm ld: 0711-317 ERROR: Undefined symbol: .zero_triangulateio ld: 0711-317 ERROR: Undefined symbol: .triangulate ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: *** [gshhs] Error 1 Problem solved: I have to add '../../Lib/TriangleJRS/libTriangleJRS.a'. If in manage to get this undertaking to an end then I'll post a resume. It would be nice if someone were willing to incorporate the necessary changes into the TerraGear 'autoconf/automake' mimics, 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TerraGear on AIX ....
Martin Spott wrote:
Problem solved: I have to add '../../Lib/TriangleJRS/libTriangleJRS.a'.
If in manage to get this undertaking to an end then I'll post a resume.
It would be nice if someone were willing to incorporate the necessary
changes into the TerraGear 'autoconf/automake' mimics,
In order to complete the SimGear build I did the following modification
to the SimGear serial port support:
--- serial.cxx.original Sun Nov 21 22:25:01 2004
+++ serial.cxx Tue Nov 30 17:50:36 2004
@@ -129,7 +129,7 @@
// config.c_cflag |= CLOCAL;
-#if ! defined( sgi )
+#if !defined( sgi ) !defined(_AIX)
// disable hardware flow control
config.c_cflag = ~(CRTSCTS);
#endif
@@ -234,11 +234,11 @@
speed = B19200;
} else if ( baud == 38400 ) {
speed = B38400;
+#if defined( linux ) || defined( __FreeBSD__ )
} else if ( baud == 57600 ) {
speed = B57600;
} else if ( baud == 115200 ) {
speed = B115200;
-#if defined( linux ) || defined( __FreeBSD__ )
} else if ( baud == 230400 ) {
speed = B230400;
#endif
Please add this or a comparable construct to SimGear - AIX apparently
doesn't know this method of toggling CRTSCTS neither does it know about
57600 and 115200 Bit/s on a serial line.
Thanks,
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
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data preferences.xml, 1.161, 1.162
* Jon Stockill -- Tuesday 30 November 2004 16:39: At 03:47 today. Modified Files: nimitz.ac Log Message: Remove crease tag so that people without custom patched versions of plib can still run FlightGear. :-) Yes, and at ... um ... right *now*: $ cd $FG_ROOT/Models/Geometry/Nimitz/ $ find -name \*.ac|xargs grep crease|wc -l 248 so today's Nimitz has all the creases again. And FWIW: $ cd $FG_ROOT/Aircraft/ $ find -name \*.ac|xargs grep crease|wc -l 890 m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Melchior FRANZ * Jon Stockill -- Tuesday 30 November 2004 16:39: At 03:47 today. Modified Files: nimitz.ac Log Message: Remove crease tag so that people without custom patched versions of plib can still run FlightGear. :-) Yes, and at ... um ... right *now*: $ cd $FG_ROOT/Models/Geometry/Nimitz/ $ find -name \*.ac|xargs grep crease|wc -l 248 so today's Nimitz has all the creases again. And FWIW: $ cd $FG_ROOT/Aircraft/ $ find -name \*.ac|xargs grep crease|wc -l 890 Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? I've been using 'crease' for a month or so now - The Spitfire/Seafire also uses it. It's absolutely no problem for me to remove it, but it seems a shame since it definitely improves appearance. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza [EMAIL PROTECTED] wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. By the way, are you certain now that the crease patch is in the plib CVS? Since the loaders are not an integral part of the plib core, one alternative would be to maintain our own AC3D loader in FlightGear, based on the plib one. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
David Megginson On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza [EMAIL PROTECTED] wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. Absolutely right, but here we are talking FG cvs with plib cvs (or not as the case might be) By the way, are you certain now that the crease patch is in the plib CVS? No, I'm not. I know Mathias forwarded it, and, as I said, I thought that Wolfram had uploaded it. I'm using one of our patched versions because plib cvs doesn't work with Cygwin, or at least didn't when I last looked a week or so ago (joystick problems). Hence my question. Since the loaders are not an integral part of the plib core, one alternative would be to maintain our own AC3D loader in FlightGear, based on the plib one. In effect we are. I use the plib version provided on Martin Spott's site. Very satisfactory and stable it is too, but of course it has to be maintained. If plib has a problem with accepting patches, then perhaps this is the way to go. Nice to get this one sorted. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
Vivian Meazza wrote: Absolutely right, but here we are talking FG cvs with plib cvs (or not as the case might be) Right, but if we depend on plib cvs, we could never again make a stable release until plib rolls the current cvs version into a stable release ... that puts us in a bad position. 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data preferences.xml, 1.161, 1.162
Vivian Meazza wrote: Sorry guys, I sent today's Nimitz before I realized that Curt was removing crease tokens. Mind you, after all the effort we went to get it in ... I'm a bit confused here. Mathias submitted a patch to plib, and I thought that Wolfram Kuss had uploaded it. What's the problem - NIH (Not Invented Here) or what? I've been using 'crease' for a month or so now - The Spitfire/Seafire also uses it. It's absolutely no problem for me to remove it, but it seems a shame since it definitely improves appearance. As a project, FlightGear needs to depend on the stable releases of the stuff it depends on, not cvs development trees. That get's to be too big of a mess. Many distributions include the latest stable version of plib, and that is often easier to build. It's ok for developers to use cvs versions of our dependencies, as long as they don't break compatibility with the latest stable version. 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: datapreferences.xml, 1.161, 1.162
Melchior FRANZ wrote: * Martin Spott -- Tuesday 30 November 2004 15:55: Erik Hofman wrote: Comment out the nimitz for now. Hm ? I thought Curt just made it working with stock PLIB - is it still broken ? Yes, he did. But Vivian's changes from today refer to a file nimitz- complex.ac, which isn't in CVS, and was apparently not sent to Erik. This made fgfs abort for me: WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\ Models/Geometry/Nimitz/nimitz-complex.ac' for reading Fatal error: Failed to load 3D model Just delete -complex There are other things to fix as well. While landing the FA-18A on the carrier worked beautifully after applying Mathias' patches directly, the recent changes to cvs don't allow carrier landings at all. The aircraft falls through the deck, even though I have the alternative carrier-enabled JSBSim version still installed. Yes - that doesn't seem to work. I've tried going back to a date before Mathias' patch, and the patch doesn't apply properly. We appear to have got out of set somewhere along the line. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
David Megginson wrote: On Tue, 30 Nov 2004 18:40:53 -, Vivian Meazza No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. I'm not convinced that this actually is the point. FlightGear has a history of depending on a moving PLIB CVS target - Curt has 'convinced' Steve Baker more than once to issue a PLIB release right before the next FlightGear release. My custom patched versions of plib-package is far more stable than PLIB CVS trees that have been mandantory many times in the past - it even carries a time stamp :-) [...] By the way, are you certain now that the crease patch is in the plib CVS? This is the key point: PLIB folks (core developers) typically don't feel much urge to commit a patch that they didn't invent themselves or that servers their own purpose. Steve decided that he didn't have much use for Mathias' patch so no one actually bothered to commit, 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 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
* Vivian Meazza -- Tuesday 30 November 2004 20:30: I use the plib version provided on Martin Spott's site. Very satisfactory and stable it is too, [...] A few of our models do still not work properly with applied crease patch. dhc2 b1900d Citation-II All of them show holes where the instruments should be. I had posted a working version of the dhc2 but finally gave up fixing that, because this should be done by the respective author(s?; Sid?). All of these aircrafts are very well done, btw, and the former two are a joy to fly! (well, I don't like the b1900d's and the citation's pitch-down behavior, but that's a different story. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
On Tue, Nov 30, 2004 at 09:21:23AM -0500, Chuck Cole wrote: As promised, I've attached the files that I modified to make FlightGear work with my client software. These modifications allow my client software to Hi Chuck, this is already a lot better than the old solution. (Specifically, the bools were a problem!) I'd still recommend to replace time_t by double, since time_t ``is more likely to vary in size between platforms'' than double. Perhaps even replace all long's by floats. Same argument: float is 4 bytes on all architectures I know of while this is _not_ true for long. Now when will there be the next FG binary distribution with these incorporated! :-) Cheers -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
... and _do_ bump the version number!! Cheers -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! net_fdm.hxx Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: datapreferences.xml, 1.161, 1.162
* Vivian Meazza -- Tuesday 30 November 2004 20:47: Melchior FRANZ wrote: WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\ Models/Geometry/Nimitz/nimitz-complex.ac' for reading Fatal error: Failed to load 3D model Just delete -complex Sure. I know how to fix trivial problems like these. I made a link instead. But this does still not wholly solve the problem, because now we are lacking a couple of textures that were removed. No problem, as long as the carrier is disabled, anyway. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How does the Replay Subsystem work?
[EMAIL PROTECTED] wrote: Hi, I am trying to read flight data from a FDR (Flight Data Recorder, black box) and input some of the data into FlightGear's Replay system to display the flight. If using the Replay functionality in the FlightGear and I only care some of the values such as: -Longitude, latitude, altitude, agl -v_north, v_east, v_down -phi, theta, psi All these for displaying the aircraft's attitude, position, trajectory. While I don't care those values such as control surfaces, engines status, instruments related, and etc. There is a file called acms.xml in FlightGear/data/Protocol/ (base package) which was used for the helicopter playback. Now to play back the data using that file you will have to use the latest version of FlightGear compiled with --enable-sp-fdms If the file format as described by the acms.xml file corresponds to the data you have you will be able to play the data by running: fgfs --aircraft=c172p \ --generic=file,in,1,path_to_FDR_file,acms \ --fdm=acms I tried to import the data (lon,lat,) I want to use into the Replay subsystem and hardcode those control surfaces, engines/tanks status, and etc. At the beginning, I set the replay_master as true and I got the program started in replay mode. But the problem is, I failed to see the aircraft moving which supposed to be because I have the lon, lat, alt, groundspeed keep changing. This is because the default FDM will override these values. You will have to use --fdm=null or --fdm=acms So my question is, how does the Replay subsystem work in FlightGear? Does it use the control surfaces' (and other control elements like engines) changes as the inputs and then use the FDM to recalculate all the outputs again? With the above description it will only mode the model in the scenery. Lots of stuff can be done by extending the code though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Mon, 29 Nov 2004 23:50:36 -0500, Chris wrote in message [EMAIL PROTECTED]: On Tue, 30 Nov 2004 06:33:36 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: It's pretty neat technology. No decompression is required as reading a texture is done on the fly when it's required. If only a portion of the compressed texture is used in a scene then only the required pixels of the texture are decoded and used. One would be able to stick nearly 768MB of textures onto a video card with 128MB of VRAM. The IO saved is enormous if you were trying to send all those textures to the video card for each frame. It does sound really, really cool. One concern: how widespread is the availability of these two OpenGL extensions? ..or, which video cards can , and, can not use these extensions? (I can use that info now, I'm looking for a new card now.) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Martin Spott No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. I'm not convinced that this actually is the point. FlightGear has a history of depending on a moving PLIB CVS target - Curt has 'convinced' Steve Baker more than once to issue a PLIB release right before the next FlightGear release. My custom patched versions of plib-package is far more stable than PLIB CVS trees that have been mandantory many times in the past - it even carries a time stamp :-) So it is, and it works with Cygwin. [...] By the way, are you certain now that the crease patch is in the plib CVS? This is the key point: PLIB folks (core developers) typically don't feel much urge to commit a patch that they didn't invent themselves or that servers their own purpose. Steve decided that he didn't have much use for Mathias' patch so no one actually bothered to commit, As I thought - NIH. I'm underwhelmed. So where do we go from here - do our own loaders? Maintain our own version of PLIB? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
Melchior FRANZ wrote: * Vivian Meazza -- Tuesday 30 November 2004 20:47: Melchior FRANZ wrote: WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/\ Models/Geometry/Nimitz/nimitz-complex.ac' for reading Fatal error: Failed to load 3D model Just delete -complex Sure. I know how to fix trivial problems like these. I made a link instead. But this does still not wholly solve the problem, because now we are lacking a couple of textures that were removed. No problem, as long as the carrier is disabled, anyway. Of course you can. I'll check the textures. Disabled - do you mean broken? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Vivian Meazza wrote: Martin Spott No, it's just a matter of stability. We don't want FlightGear releases to have to depend on prerelease CVS versions of plib, so we have to wait until the next plib official release. I'm not convinced that this actually is the point. FlightGear has a history of depending on a moving PLIB CVS target - Curt has 'convinced' Steve Baker more than once to issue a PLIB release right before the next FlightGear release. My custom patched versions of plib-package is far more stable than PLIB CVS trees that have been mandantory many times in the past - it even carries a time stamp :-) So it is, and it works with Cygwin. [...] By the way, are you certain now that the crease patch is in the plib CVS? This is the key point: PLIB folks (core developers) typically don't feel much urge to commit a patch that they didn't invent themselves or that servers their own purpose. Steve decided that he didn't have much use for Mathias' patch so no one actually bothered to commit, As I thought - NIH. I'm underwhelmed. So where do we go from here - do our own loaders? Maintain our own version of PLIB? Don't forget we are all open-source developers here. The plib guys are volunteers just like us. It's pretty easy to be critical and jump ship (so to speak.) It's harder to live with each other and work towards the common good of everyone ... especially with the weird characters that show up on the open-source scene. We all are busy. Steve is extremely busy. It doesn't hurt to follow up on these things (more than once if needed.) If done in a sensitive way, you can usually accomplish reasonable things with reasonable people. Just keep in mind that we are all volunteers, all have day jobs, many of us have families, we can't all sit and monitor the FG or plib mailing lists 24/7 and drop everything to address every issue that comes up immediately when it comes up. And also, please be aware that with the volume of mail that most of us get, if we can't do something right away (which is often/usually the case) the email quickly gets buried beneath a flood of newer requests and problems. I'm always waiting for that lull in the action which would allow me to go back through my inbox(s) and address some of the backlog, but such a lull never (or rarely) happens. Perhaps as a direct suggestion to the immediate issue of the crease patch, we should get more FG people onboard as plib contributors with cvs access so we can make direct contributions and get this fixed? 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:datapreferences.xml, 1.161, 1.162
* Vivian Meazza -- Tuesday 30 November 2004 23:02: * Melchior FRANZ wrote: [...] we are lacking a couple of textures that were removed. No problem, as long as the carrier is disabled, anyway. I'll check the textures. Disabled - do you mean broken? No, I mean the fact that the nimitz_demo scenario was commented out in preferences.xml. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Curtis L. Olson wrote: We all are busy. Steve is extremely busy. It doesn't hurt to follow up on these things (more than once if needed.) If done in a sensitive way, you can usually accomplish reasonable things with reasonable people. I don't think anyone here is attempting to blame Steve for being extremely busy. The simple question is - trying to get back to the starting point - if it makes sense to hold back valuable improvement in FlightGear just because you rely on a scene graph library where you have to wait several months until 1.) someone is convenient with having a look at your submission and 2.) this submission _might_ show up in a release. I created my private PLIB packages in an attempt to circumvent this 'lock' - until some better solution comes up. These packages carry a 'time stamp' and everyone is free to reference these. Perhaps as a direct suggestion to the immediate issue of the crease patch, we should get more FG people onboard as plib contributors with cvs access so we can make direct contributions and get this fixed? This might be the ultimate solution. Until you/we are there, feel free to rely on the 'intermediate', 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 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] error building FlightGear on RH Linux 7.2 with gcc 2.9.6
Hi , I get the following error when making FlightGear: main.cxx: in function 'bool fgMainInit(int, char **): main.cxx:747: assuming on overloaded member function the offending line contains: fgRegisterDrawHandler(FGRenderer::update); Can someone tell me how to fix this? Regards, Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Build Problem Under MacOS X 10.3
I tried building with the latest MacOS changes from CVS and found one problem. When compiler.h gets generated, the symbol SG_GLUT_H gets defined to be OpenGL/glut.h when it needs to be defined as GLUT/glut.h. It is a part of the GLUT framework and not the OpenGL framework. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] error building FlightGear on RH Linux 7.2 with gcc 2.9.6
Ron King wrote: Hi , I get the following error when making FlightGear: main.cxx: in function 'bool fgMainInit(int, char **): main.cxx:747: assuming on overloaded member function the offending line contains: fgRegisterDrawHandler(FGRenderer::update); Can someone tell me how to fix this? Ron, for what it's worth RH 7.2 is *really* old, and gcc-2.96 was kind of a half-baked cvs snapshot that RedHat grabbed for various [debatable] reasons. It had a lot of bugs and caused a lot of grief for a lot of people. If upgrading is any kind of option, I would highly recommend upgrading to something newer. There are a lot of good options these days, Fedora, Debian, RedHat, Suse, Mandrake, etc. etc. etc. Personally, I've been fiddling with Fedora Core 2/3 lately and have been pretty happy with it. I've managed to find a couple annoyances, but generally it's a *lot* (and I can't emphasize the word *lot* enough) better than RH 7.2/7.3. I still run Debian for my servers, but for a desktop machine, Fedora Core is pretty good. I realize that doesn't help your immediate problem (which I don't have an answer for), but if there is any possible way for you to upgrade, I think you will be a *lot* happier. Also, don't forget that you need decent 3d hardware acceleration to run FG which for most people probably means an nvidia or ati card that was built this century. I don't know how well modern nvidia/ati cards can be made to work with the really old kernel you must have if you are running RH 7.2. 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] error building FlightGear on RH Linux 7.2 with gcc 2.9.6
On Tue, 30 Nov 2004 20:51:40 -0600, Curtis wrote in message [EMAIL PROTECTED]: Ron, for what it's worth RH 7.2 is *really* old, and gcc-2.96 was kind of a half-baked cvs snapshot that RedHat grabbed for various [debatable] reasons. It had a lot of bugs and caused a lot of grief ..staying with this old un-updated RH-7.2 might be _the_ way to help Microsoft prove Wintendo is safer than Linux!. ;-) for a lot of people. If upgrading is any kind of option, I would ..try a live cd, Knoppix.net for details, docs etc, if you like it, just install it off the cd to harddisk. After that, updates are a breeze, apt-get update ; apt-get upgrade ; apt-get autoclean instead of those mile long rpm -Uvh *.rpm trashed guess command lines. highly recommend upgrading to something newer. There are a lot of good options these days, Fedora, Debian, RedHat, Suse, Mandrake, etc. etc. etc. Personally, I've been fiddling with Fedora Core 2/3 lately and have been pretty happy with it. I've managed to find a couple annoyances, but generally it's a *lot* (and I can't emphasize the word *lot* enough) better than RH 7.2/7.3. ..I'm told Fedora Core 1 Legacy (FC1L) is better than Fedora Core 2 (FC2), how does Fedora Core 3 compare to those? I still run Debian for my servers, but for a desktop machine, Fedora Core is pretty good. I realize that doesn't help your immediate problem (which I don't have an answer for), but if there is any possible way for you to upgrade, I think you will be a *lot* happier. ..I use Debian for everything, and hook people with DamnSmallLinux.org and clusterKnoppix, if you're a Linux newbie, you wanna go the Knoppix route to Debian, if you're a seasoned Red Hat guy, you wanna go the FC1L route until Curtis convinces me FC3 is better than FC2 and FC1L. ..Fedore also has the netselect and apt-get magic now, but only a fraction of the software Debian has available. Myself, I went from Red Hat to Debian before Fedora and Knoppix rose out of the dust, and spent the last 1.5 year or so unlearning the RedHat-isms. ;-) Also, don't forget that you need decent 3d hardware acceleration to run FG which for most people probably means an nvidia or ati card that was built this century. I don't know how well modern nvidia/ati cards can be made to work with the really old kernel you must have if you are running RH 7.2. ..this is on an old box, Ron? Fedora Core 2 is _heavy_ for boxes of RH-7.2 vintage, IMWEWFC2. (I spent a week getting a lan test box working good enough for delivery before the client told me But Debian is okay with me. Duh! ;-) ) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:data
Curtis L. Olson wrote: Perhaps as a direct suggestion to the immediate issue of the crease patch, we should get more FG people onboard as plib contributors with cvs access so we can make direct contributions and get this fixed? I looked at the developer list of the plib project ( http://sourceforge.net/project/memberlist.php?group_id=382 ) and was amazed that a project with so many developers ( 23 ) has so much difficulties to commit the simple patch. I even don't speak about the crease patch, but the windows joystick was broken and my one liner never got commited even with multiple reminders. Among the list of plib registered developers, some are frequently contributing to the flightgear project : - Alex Perry - Curtis Olson - Norman Vine -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
