[Flightgear-devel] gettimeofday, rand, simgear configure
I've just tried configuring a fresh checkout of Simgear on a fresh install of Libranet Linux (Debian Woody based) and the configure script can't find gettimeofday, rand, srand, rand48 and a host of others at the end of the configure script. This breaks timing.cxx :-( Given that simultaneous changes have occurred to both my OS install and the Simgear configure script (according to the CVS logs) I'm not entirely sure where the problem lies! Does anyone have any idea what to do about fixing this? (Plib-1.6.0 compiled OK on the same system and I'm using gcc-3.2 if that's of any relevance.) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gettimeofday, rand, simgear configure
David, The best thing to do would be to look at your config.log and see exactly why those checks are failing. Regards, Curt. David Luff writes: I've just tried configuring a fresh checkout of Simgear on a fresh install of Libranet Linux (Debian Woody based) and the configure script can't find gettimeofday, rand, srand, rand48 and a host of others at the end of the configure script. This breaks timing.cxx :-( Given that simultaneous changes have occurred to both my OS install and the Simgear configure script (according to the CVS logs) I'm not entirely sure where the problem lies! Does anyone have any idea what to do about fixing this? (Plib-1.6.0 compiled OK on the same system and I'm using gcc-3.2 if that's of any relevance.) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program 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
re: [Flightgear-devel] gettimeofday, rand, simgear configure
Curtis L Olson writes:
The best thing to do would be to look at your config.log and see
exactly why those checks are failing.
Hmm, why didn't I think of that? Doh!
The checks that are unexpectedly failing all have references to the Metakit librarys.
The stuff included below (for gettimeofday) is typical. I've compiled Metakit with
the same compiler (3.2), added the install location to ld.so.conf and run ldconfig,
and have no Metakit package installed, so I'm out of ideas :-(
Cheers - Dave
configure:8156: checking for gettimeofday
configure:8199: gcc-3.2 -o conftest -Wall -O2 -D_REENTRANT -I/usr/X11R6/include
-L/usr/X11R6/lib conftest.c -lm -lmk4 5
/usr/local/lib/libmk4.so: undefined reference to `operator new[](unsigned)'
/usr/local/lib/libmk4.so: undefined reference to `vtable for
__cxxabiv1::__si_class_type_info'
/usr/local/lib/libmk4.so: undefined reference to `operator delete(void*)'
/usr/local/lib/libmk4.so: undefined reference to `__gxx_personality_v0'
/usr/local/lib/libmk4.so: undefined reference to `__cxa_pure_virtual'
/usr/local/lib/libmk4.so: undefined reference to `vtable for
__cxxabiv1::__class_type_info'
/usr/local/lib/libmk4.so: undefined reference to `operator delete[](void*)'
/usr/local/lib/libmk4.so: undefined reference to `operator new(unsigned)'
collect2: ld returned 1 exit status
configure:8202: $? = 1
configure: failed program was:
#line 8161 configure
#include confdefs.h
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char gettimeofday (); below. */
#include assert.h
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern C
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char gettimeofday ();
char (*f) ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern C
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_gettimeofday) || defined (__stub___gettimeofday)
choke me
#else
f = gettimeofday;
#endif
;
return 0;
}
configure:8218: result: no
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New Segfault, CVS this AM, gdb stack trace
Hello,
Managed to get more info than usual from an execution crash after
rebuild with 12/11/02 7AM EST CVS. Hope someone can make use of it.
Run on RH 7.1, g++ = 2.96-112.7.1 of RH.
--
Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA
Computers, like air conditioners, work poorly with Windows open.
Done reading panel instruments
Loaded new panel from Aircraft/c172/Panels/c172-vfr-panel.xml
leave NewTgtAirportInit()start of fgInitProps()
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4124)]
0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
241 inline FGSoundMgr *get_soundmgr() const { return soundmgr; }
(gdb) bt
#0 0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
#1 0x08404fd2 in SGRawValueFunctionsbool::setValue (this=0x92a8368,
value=false) at /usr/local/include/simgear/misc/props.hxx:331
#2 0x083817a7 in SGPropertyNode::setBoolValue (this=0x8853aa0, value=false)
at props.cxx:374
#3 0x08382bc6 in SGPropertyNode::tie (this=0x8853aa0, rawValue=@0xb490,
useDefault=true) at props.cxx:1522
#4 0x0807c4f1 in fgInitProps () at ../../src/Main/globals.hxx:254
#5 0x08074a14 in fgInitSubsystems () at fg_init.cxx:1596
#6 0x0805315a in fgIdleFunction () at main.cxx:1314
#7 0x40288123 in idleWait () from /usr/lib/libglut.so.3
#8 0x080561ee in main (argc=1, argv=0xb944) at main.cxx:1815
#9 0x4032c657 in __libc_start_main (main=0x80561d0 main, argc=1,
ubp_av=0xb944, init=0x804def8 _init, fini=0x8452c34 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb93c)
at ../sysdeps/generic/libc-start.c:129
Re: [Flightgear-devel] [OT] BA-609, V-22 derivative aircraft
Carsten.Hoefer wrote: Forgetting about all 'unsafe' situations in helicopters, do we have one in flightgear? Is it possible to model one with the existing flight models we use? Not without a lot of code work. Helicopters have a bunch of effects that don't exist in the current FDMs. Things like asymmetric lift effects would need to be revisited. Both YASim and JSBSim model P factor, which is what the same effect is called on a fixed wing propeller aircraft, via a hack that isn't general enough to handle ~90 degree AoAs. Other stuff, like blade flapping and precession of the main rotor just don't exist and would need to be done from scratch. For myself, I don't find PC simulation of helicopters very interesting. Existing throttles don't have anywhere near enough precision to simulate a collective, IMHO. Helicopter pilots maintain altitude by feeling for very slight changes in vertical acceleration and adjusting with tiny movements of the collective. There's no way we can simulate that well. We could do it with an autopilot like device, of course, but where's the fun in that? You might as well just install Commanche MCMXIV or whatnot to get same level of simulation realism. :) If you want to try hovering in FlightGear, try the Harrier. That thing is really difficult to hover, for all the same reasons that the real aircraft is difficult to hover. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] BA-609, V-22 derivative aircraft
Curtis L. Olson wrote: Tony Peden writes: --- Jim Wilson [EMAIL PROTECTED] wrote: Hmmmthat should thin the ranks down on Wall St even more. ... IMHO that thing even looks dangerous :-) More dangerous than a helicopter? ... It sounds like avoiding the vortex ring state... I think the big danger is at landing or takeoff. ... The big problematic area for this class of aircraft historically has been the transition between hover, or rotor based operation and flying, where the wings are important. That regime is unstable and recovery difficult. Regards, Charlie H. -- C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg. - Bjarne Stroustrup ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SimGear configure problem (metakit)
With the latest SimGear CVS, I'm getting this in config.log: configure:8649: checking for ftime configure:8699: gcc-3.2 -o conftest -g -O1 -finline-limit=6 -finline-functions -D_REENTRANT -I/usr/X11R6/include -L/usr/X11R6/lib conftest.c -lm -ljpeg -lmk4 5 /usr/local/lib/libmk4.so: undefined reference to `operator new[](unsigned)' /usr/local/lib/libmk4.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/local/lib/libmk4.so: undefined reference to `operator delete(void*)' /usr/local/lib/libmk4.so: undefined reference to `__gxx_personality_v0' /usr/local/lib/libmk4.so: undefined reference to `__cxa_pure_virtual' /usr/local/lib/libmk4.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/local/lib/libmk4.so: undefined reference to `operator delete[](void*)' /usr/local/lib/libmk4.so: undefined reference to `operator new(unsigned)' collect2: ld returned 1 exit status I rebuilt with the metakit supplied in the SimGear CVS repository, made sure I used gcc-3.2 for both, made sure there was no other metakit installed, etc. etc. Is anyone else seeing this? There's been a lot of recent activity around configure.ac, and something might have broken: revision 1.11 date: 2002/12/10 20:54:08; author: curt; state: Exp; lines: +60 -14 More tweaks to the configure script. revision 1.10 date: 2002/12/10 19:12:34; author: curt; state: Exp; lines: +73 -80 - Refactoring configure.ac a bit to use $host (please test on your platform) - Use include GLUT_H instead of refering to the file directly since Mac unfortunately chose to put this in GLUT/glut.h :-( revision 1.9 date: 2002/12/09 22:36:38; author: curt; state: Exp; lines: +35 -44 James Turner: I've had to hack Simgear's configure.ac quite a bit [for Mac OS X], using the Plib one as a reference. The basic construct (a big switch statement based on the target type) is nice, I think, since it moves lots of IRIX / cygwin / OS-X specialties out of the way cleanly. Much more re-factoring of the current tests in configure is possible if people are able to test. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear configure problem (metakit)
David Megginson wrote: configure:8649: checking for ftime configure:8699: gcc-3.2 -o conftest -g -O1 -finline-limit=6 -finline-functions -D_REENTRANT -I/usr/X11R6/include -L/usr/X11R6/lib conftest.c -lm -ljpeg -lmk4 5 /usr/local/lib/libmk4.so: undefined reference to `operator new[](unsigned)' It looks to me like a gcc invocation (as opposed to g++) is being used to compile a C program, but linking against a C++ library (metakit). So whatever library operator new is in isn't there. Using gcc to compile C++ does work, but I suspect you have to pass it a .cxx or .cpp or .cc file to get support. My guess is that metakit shouldn't be there. It certainly isn't needed to test for the presence of ftime. Maybe it got added to the wrong library list? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear configure problem (metakit)
David Megginson writes: With the latest SimGear CVS, I'm getting this in config.log: configure:8649: checking for ftime configure:8699: gcc-3.2 -o conftest -g -O1 -finline-limit=6 -finline-functions -D_REENTRANT -I/usr/X11R6/include -L/usr/X11R6/lib conftest.c -lm -ljpeg -lmk4 5 /usr/local/lib/libmk4.so: undefined reference to `operator new[](unsigned)' /usr/local/lib/libmk4.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/local/lib/libmk4.so: undefined reference to `operator delete(void*)' /usr/local/lib/libmk4.so: undefined reference to `__gxx_personality_v0' /usr/local/lib/libmk4.so: undefined reference to `__cxa_pure_virtual' /usr/local/lib/libmk4.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/local/lib/libmk4.so: undefined reference to `operator delete[](void*)' /usr/local/lib/libmk4.so: undefined reference to `operator new(unsigned)' collect2: ld returned 1 exit status those are all C++ symbols you need to either 1) use g++ instead of gcc or 2) link with -lsupc++ -lstdc++ if you don't have libsupc++.a But my question is Where is the requirement for -lmk coming from this is the only reference to metakit in configure.ac and it only checks for the header dnl Check for system installed metakit AC_CHECK_HEADER(mk4.h) if test x$ac_cv_header_mk4_h != xyes; then echo echo Metakit not found, you will need to install this first. echo Please read the README.metakit for more information. exit fi Are you explicitly adding -lmk to your $LIBS ?? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear configure problem (metakit)
Norman Vine writes: But my question is Where is the requirement for -lmk coming from this is the only reference to metakit in configure.ac and it only checks for the header dnl Check for system installed metakit AC_CHECK_HEADER(mk4.h) if test x$ac_cv_header_mk4_h != xyes; then echo echo Metakit not found, you will need to install this first. echo Please read the README.metakit for more information. exit fi Are you explicitly adding -lmk to your $LIBS ?? No, and I wasn't experiencing this problem a few days ago. I'm using autoconf 2.57. I'll do more investigation. However, this line does appear in configure.ac (line 307): LIBS=$saved_LIBS -lmk4 Presumably, LIBS should be set back to saved_LIBS after the following test, but it isn't. I'll see if this fixes the problem, then will commit the change. Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear configure problem (metakit)
Andy Ross writes: It looks to me like a gcc invocation (as opposed to g++) is being used I missed that completely. Thanks. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear configure problem (metakit)
David Megginson writes: No, and I wasn't experiencing this problem a few days ago. I'm using autoconf 2.57. I'll do more investigation. However, this line does appear in configure.ac (line 307): LIBS=$saved_LIBS -lmk4 Presumably, LIBS should be set back to saved_LIBS after the following test, but it isn't. I'll see if this fixes the problem, then will commit the change. Try adding LIBS=$saved_LIBS after the metakit version check and see if that cleans it up. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] SimGear configure problem (metakit)
Curtis L. Olson writes: Try adding LIBS=$saved_LIBS after the metakit version check and see if that cleans it up. Yes, that does the trick, and I see it's now in CVS. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
Has anyone built FlightGear 0.9.1 for Mac OS X yet? I'd like to be able to add the mac version to the downloads section at some point. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] New Segfault, CVS this AM, gdb stack trace
I'm suddenly seeing this here myself ... anyone track this down yet?
Curt.
William Earnest writes:
Hello,
Managed to get more info than usual from an execution crash after
rebuild with 12/11/02 7AM EST CVS. Hope someone can make use of it.
Run on RH 7.1, g++ = 2.96-112.7.1 of RH.
--
Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA
Computers, like air conditioners, work poorly with Windows open.
Done reading panel instruments
Loaded new panel from Aircraft/c172/Panels/c172-vfr-panel.xml
leave NewTgtAirportInit()start of fgInitProps()
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4124)]
0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
241 inline FGSoundMgr *get_soundmgr() const { return soundmgr; }
(gdb) bt
#0 0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
#1 0x08404fd2 in SGRawValueFunctionsbool::setValue (this=0x92a8368,
value=false) at /usr/local/include/simgear/misc/props.hxx:331
#2 0x083817a7 in SGPropertyNode::setBoolValue (this=0x8853aa0, value=false)
at props.cxx:374
#3 0x08382bc6 in SGPropertyNode::tie (this=0x8853aa0, rawValue=@0xb490,
useDefault=true) at props.cxx:1522
#4 0x0807c4f1 in fgInitProps () at ../../src/Main/globals.hxx:254
#5 0x08074a14 in fgInitSubsystems () at fg_init.cxx:1596
#6 0x0805315a in fgIdleFunction () at main.cxx:1314
#7 0x40288123 in idleWait () from /usr/lib/libglut.so.3
#8 0x080561ee in main (argc=1, argv=0xb944) at main.cxx:1815
#9 0x4032c657 in __libc_start_main (main=0x80561d0 main, argc=1,
ubp_av=0xb944, init=0x804def8 _init, fini=0x8452c34 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb93c)
at ../sysdeps/generic/libc-start.c:129
--
Curtis Olson IVLab / HumanFIRST Program 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
re: [Flightgear-devel] gettimeofday, rand, simgear configure
--- David Luff [EMAIL PROTECTED] wrote:
Curtis L Olson writes:
The best thing to do would be to look at your
config.log and see
exactly why those checks are failing.
Hmm, why didn't I think of that? Doh!
The checks that are unexpectedly failing all have
references to the Metakit librarys. The stuff
included below (for gettimeofday) is typical. I've
compiled Metakit with the same compiler (3.2), added
the install location to ld.so.conf and run ldconfig,
and have no Metakit package installed, so I'm out of
ideas :-(
Cheers - Dave
configure:8156: checking for gettimeofday
configure:8199: gcc-3.2 -o conftest -Wall -O2
-D_REENTRANT -I/usr/X11R6/include -L/usr/X11R6/lib
conftest.c -lm -lmk4 5
/usr/local/lib/libmk4.so: undefined reference to
`operator new[](unsigned)'
/usr/local/lib/libmk4.so: undefined reference to
`vtable for __cxxabiv1::__si_class_type_info'
/usr/local/lib/libmk4.so: undefined reference to
`operator delete(void*)'
/usr/local/lib/libmk4.so: undefined reference to
`__gxx_personality_v0'
/usr/local/lib/libmk4.so: undefined reference to
`__cxa_pure_virtual'
/usr/local/lib/libmk4.so: undefined reference to
`vtable for __cxxabiv1::__class_type_info'
/usr/local/lib/libmk4.so: undefined reference to
`operator delete[](void*)'
/usr/local/lib/libmk4.so: undefined reference to
`operator new(unsigned)'
collect2: ld returned 1 exit status
configure:8202: $? = 1
configure: failed program was:
#line 8161 configure
#include confdefs.h
/* System header to define __stub macros and
hopefully few prototypes,
which can conflict with char gettimeofday ();
below. */
#include assert.h
/* Override any gcc2 internal prototype to avoid an
error. */
#ifdef __cplusplus
extern C
#endif
/* We use char because int might match the return
type of a gcc2
builtin and then its argument prototype would
still apply. */
char gettimeofday ();
char (*f) ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern C
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
/* The GNU C library defines this for functions
which it implements
to always fail with ENOSYS. Some functions are
actually named
something starting with __ and the normal name
is an alias. */
#if defined (__stub_gettimeofday) || defined
(__stub___gettimeofday)
choke me
#else
f = gettimeofday;
#endif
;
return 0;
}
configure:8218: result: no
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Maybe nothing, but shouldnt you be using g++-3.2 (as
in C++ compiler instead of letting configure decide)
I looks to me you have enviroment variable CC set.
That would account why new and delete are missing,
they are C++ function.
My 2 cents
Leon
=
My Flight Gear Multiplayer Stuff (work-in-progress):
http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/
OK, I admit it: My girlfriend's just an object to me.
Unfortunately, there is some information hiding, but
thankfully, she's fairly encapsulated, nicely modular, and
has a very well defined interface!
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Segfault, CVS this AM, gdb stack trace
Looks like fgInitProps() needs to have the sound manager initialized
first. When it ties /sim/freeze/master, this calls setFreeze() which
needs to have a valid globals-get_sound_mgr(). We might also be able
to test if sound_mgr is null and not try to mess with it.
Regards,
Curt.
William Earnest writes:
Hello,
Managed to get more info than usual from an execution crash after
rebuild with 12/11/02 7AM EST CVS. Hope someone can make use of it.
Run on RH 7.1, g++ = 2.96-112.7.1 of RH.
--
Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA
Computers, like air conditioners, work poorly with Windows open.
Done reading panel instruments
Loaded new panel from Aircraft/c172/Panels/c172-vfr-panel.xml
leave NewTgtAirportInit()start of fgInitProps()
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4124)]
0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
241 inline FGSoundMgr *get_soundmgr() const { return soundmgr; }
(gdb) bt
#0 0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
#1 0x08404fd2 in SGRawValueFunctionsbool::setValue (this=0x92a8368,
value=false) at /usr/local/include/simgear/misc/props.hxx:331
#2 0x083817a7 in SGPropertyNode::setBoolValue (this=0x8853aa0, value=false)
at props.cxx:374
#3 0x08382bc6 in SGPropertyNode::tie (this=0x8853aa0, rawValue=@0xb490,
useDefault=true) at props.cxx:1522
#4 0x0807c4f1 in fgInitProps () at ../../src/Main/globals.hxx:254
#5 0x08074a14 in fgInitSubsystems () at fg_init.cxx:1596
#6 0x0805315a in fgIdleFunction () at main.cxx:1314
#7 0x40288123 in idleWait () from /usr/lib/libglut.so.3
#8 0x080561ee in main (argc=1, argv=0xb944) at main.cxx:1815
#9 0x4032c657 in __libc_start_main (main=0x80561d0 main, argc=1,
ubp_av=0xb944, init=0x804def8 _init, fini=0x8452c34 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb93c)
at ../sysdeps/generic/libc-start.c:129
--
Curtis Olson IVLab / HumanFIRST Program 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] howto add a 3D plane ingame ?
Our (ACE/ICE) multiplayer engine is ready to draw planes in the game now, but I cant seem to figure out how to add them to the drawing graph in a way that I can actually see them. Does anyone know how to do this or know the pitfalls why is it failing ? Tries so far: --- class fgPeer::FGModelPlacement (from Model/model.cxx) loading a .ac-model(Geometry/Models/glider.ac) in init() Adding the ssgEntity from FGModelPlacement.getSceneGraph() to the Flight Gear Graph using the following 2 functions: globals-get_scenery()-get_models_branch()-addKid(myFGPeer) -or- (which one is good ?) globals-get_scenery()-get_scene_graph()-addKid(myFGPeer) as seen in Model/modelmgr.cxx. and calling FGModelPlacement.setPostion(...) FGModelPlacement.setOrientation(...) FGModelPlacement.update() everytime a new update arives. --- I've checked ATC/AIEntity and this has the same layout but has a transform function instead of a update() function, in case this matters (?) Any help would be just great since I have to give a presentation of the project on monday :( Leon (code snapshots can be downloaded at the site below) = My Flight Gear Multiplayer Stuff (work-in-progress): http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ OK, I admit it: My girlfriend's just an object to me. Unfortunately, there is some information hiding, but thankfully, she's fairly encapsulated, nicely modular, and has a very well defined interface! __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] J3 Cub won't converge
Andy, With the latest YASim changes, the J3 Cub won't converge for me (and others.) I get the following: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to -0.000431126ft... ...initializing sea-level radius... lat = 37.6117 alt = -0.000431126 ...initializing velocities... ...initializing Euler angles... End common FDM init ... long pause ... YASim solution results: Iterations: 10002 Drag Coefficient: 65.0039 Lift Ratio: 37.0762 Cruise AoA: -0.641666 Tail Incidence: 1.91857 Approach Elevator: 0 CG: -0.876, -0.000, -0.114 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations Any ideas? Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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] Default startup aircraft
How close are we to making a 3d cockpit enabled C172 be our default startup aircraft? I notice that we can't operate the mixture, throttle, flaps via panel clicks and some of the knob click areas are a little off. Any thing else? The more I run with the 3d panels the more I like them, and the more I dislike the 2d panels (although we still need to support 2d panels for various reasons.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] howto add a 3D plane ingame ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07:09, giovedì 12 dicembre 2002, ace project wrote this piece of wisdom: Our (ACE/ICE) multiplayer engine is ready to draw planes in the game now, but I cant seem to figure out how to add them to the drawing graph in a way that I can actually see them. Does anyone know how to do this or know the pitfalls why is it failing ? Have you checked in the NetworkOLK code? Thanks, David - -- If you give someone a program, you will frustrate them for a day. If you teach them how to program, you will frustrate them for a lifetime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE997bpZOfFgbBAbXARAj8bAKCjtlVarW2dV3tUexBD3Do+oM89qgCeMVAJ etKR4Y4Sp9cP5DQPzYp3ZD4= =yhIP -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] J3 Cub won't converge
Curtis L. Olson wrote: With the latest YASim changes, the J3 Cub won't converge for me (and others.) Confirmed. Sorry, I didn't test this one. Any ideas? No, sadly. A quick spot check shows that it fails for pretty much all sane configuration changes. And the thing that *should* return it to the same behavior it had before the recent update (setting idrag to 1.429) doesn't work either. Odd. I honestly haven't a clue. I'll tear things apart and watch the solution step by step and see what I come up with. Hopefully it's something simple. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Default startup aircraft
Curtis L. Olson writes: I notice that we can't operate the mixture, throttle, flaps via panel clicks and some of the knob click areas are a little off. Any thing else? The more I run with the 3d panels the more I like them, and the more I dislike the 2d panels (although we still need to support 2d panels for various reasons.) Well, let's start cleaning them up. I don't think we're too far off, and with Andy's patch to make hotspots visible, it should be easy to debug the mouse problems and to add new hotspots for 3D instruments. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Objects obj.cxx,1.12,1.13
Modified Files: obj.cxx Log Message: Have DummyBSphereEntity inherit from ssgBranch instead of ssgEntity, to allow building with the latest plib CVS. Uh, I appreciate this one _very_ much because it enables me to follow the current development. 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
Re: [Flightgear-devel] [OT] BA-609, V-22 derivative aircraft
I think the big danger is at landing or takeoff. If you lose an engine or have any sort of mechanical failure on a single side, you are going to hit hard at some really odd angle. The engines are capable to deliver _enormous_ power for a short time in case of an engine failure - I believe this only works for a couple of minutes, afterwards the are fried ;-) But their most error prone part are not the engines but the way too short time frame for such a difficult development. Several prototypes and at least one pre-series plane crashed because of software failures killing several crews and passengers :-((( 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] Default startup aircraft
David Megginson writes: Well, let's start cleaning them up. I don't think we're too far off, and with Andy's patch to make hotspots visible, it should be easy to debug the mouse problems and to add new hotspots for 3D instruments. That sounds great. I think our support for fully operation 3d cockpits is really cool and definitely worth showing off up front. (But like you say, with a few minor clean ups first.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] howto add a 3D plane ingame ?
--- David Findlay [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07:09, giovedì 12 dicembre 2002, ace project
wrote this piece of wisdom:
Our (ACE/ICE) multiplayer engine is ready to draw
planes in the game now, but I cant seem to figure
out
how to add them to the drawing graph in a way that
I
can actually see them.
Does anyone know how to do this or know the
pitfalls
why is it failing ?
Have you checked in the NetworkOLK code? Thanks,
David
I've checked that one to, but I haven't seen it in
action yet (It worked Linux-only right?)
Both initialistation look similair:
---
FGModelPlacement::init (const string path)
{
ssgBranch * model = fgLoad3DModel(path);
if (model != 0)
_position-addKid(model);
_selector-addKid(_position);
_selector-clrTraversalMaskBits(SSGTRAV_HOT);
}
void
FGModelPlacement::update ()
{
_location-setPosition( _lon_deg, _lat_deg, _elev_ft
);
_location-setOrientation( _roll_deg, _pitch_deg,
_heading_deg );
sgMat4 POS;
sgCopyMat4(POS, _location-getTransformMatrix());
sgVec3 trans;
sgCopyVec3(trans, _location-get_view_pos());
for(int i = 0; i 4; i++) {
float tmp = POS[i][3];
for( int j=0; j3; j++ ) {
POS[i][j] += (tmp * trans[j]);
}
}
_position-setTransform(POS);
}
---
Versus
---
new_ele-fgd_sel = new ssgSelector;
new_ele-fgd_pos = new ssgTransform;
ssgEntity *fgd_obj =
globals-get_model_loader()-load_model(
tuxcopter.ac );
fgd_obj-clrTraversalMaskBits( SSGTRAV_HOT );
new_ele-fgd_pos-addKid( fgd_obj );
new_ele-fgd_sel-addKid( new_ele-fgd_pos );
ssgFlatten( fgd_obj );
ssgStripify( new_ele-fgd_sel );
fgd_scene-addKid( new_ele-fgd_sel );
fgd_scene-addKid( fgd_obj );
---
=
My Flight Gear Multiplayer Stuff (work-in-progress):
http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/
OK, I admit it: My girlfriend's just an object to me.
Unfortunately, there is some information hiding, but
thankfully, she's fairly encapsulated, nicely modular, and
has a very well defined interface!
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Default startup aircraft
Curtis L. Olson writes: David Megginson writes: Well, let's start cleaning them up. I don't think we're too far off, and with Andy's patch to make hotspots visible, it should be easy to debug the mouse problems and to add new hotspots for 3D instruments. That sounds great. I think our support for fully operation 3d cockpits is really cool and definitely worth showing off up front. (But like you say, with a few minor clean ups first.) I'd like to use the 172P rather than the 172R as our default, once it's ready. The model is much better, though it's still missing a couple of 3D items in the cockpit. The dimensions are more realistic, etc. etc. It even has an animated trim: fgfs --aircraft=c172p-3d All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] howto add a 3D plane ingame ?
First,
My excuses if the message got posted multiple times
!copypaste screwed up...
--- David Findlay [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07:09, giovedì 12 dicembre 2002, ace project
wrote this piece of wisdom:
Our (ACE/ICE) multiplayer engine is ready to draw
planes in the game now, but I cant seem to figure
out
how to add them to the drawing graph in a way that
I
can actually see them.
Does anyone know how to do this or know the
pitfalls
why is it failing ?
Have you checked in the NetworkOLK code? Thanks,
David
I've checked that one to, but I haven't seen it in
action yet (It worked Linux-only right?)
Both initialistation look similair:
---
FGModelPlacement::FGModelPlacement ()
: _lon_deg(0),
_lat_deg(0),
_elev_ft(0),
_roll_deg(0),
_pitch_deg(0),
_heading_deg(0),
_selector(new ssgSelector),
_position(new ssgTransform),
_location(new FGLocation)
{
}
FGModelPlacement::init (const string path)
{
ssgBranch * model = fgLoad3DModel(path);
if (model != 0)
_position-addKid(model);
_selector-addKid(_position);
_selector-clrTraversalMaskBits(SSGTRAV_HOT);
}
void
FGModelPlacement::update ()
{
_location-setPosition( _lon_deg, _lat_deg, _elev_ft
);
_location-setOrientation( _roll_deg, _pitch_deg,
_heading_deg );
sgMat4 POS;
sgCopyMat4(POS, _location-getTransformMatrix());
sgVec3 trans;
sgCopyVec3(trans, _location-get_view_pos());
for(int i = 0; i 4; i++) {
float tmp = POS[i][3];
for( int j=0; j3; j++ ) {
POS[i][j] += (tmp * trans[j]);
}
}
_position-setTransform(POS);
}
---
Versus
---
new_ele-fgd_sel = new ssgSelector;
new_ele-fgd_pos = new ssgTransform;
ssgEntity *fgd_obj =
globals-get_model_loader()-load_model(
tuxcopter.ac );
fgd_obj-clrTraversalMaskBits( SSGTRAV_HOT );
new_ele-fgd_pos-addKid( fgd_obj );
new_ele-fgd_sel-addKid( new_ele-fgd_pos );
ssgFlatten( fgd_obj );
ssgStripify( new_ele-fgd_sel );
fgd_scene-addKid( new_ele-fgd_sel );
fgd_scene-addKid( fgd_obj );
---
Spotted differences, don't know what they mean yet:
- olk : uses fgd_scene as root of the tree.
- model : uses globals-get_scenery-...
- olk : uses no path to load a model
- model : uses a relative path to a model, error
possible here.
- olk : uses
globals-get_model_loader()-load_model(...)
- model : first adds model to _position, then
_position to _selector. modelmgr takes care of adding
model to the tree (so does my code)
- olk : uses ssgFlattern, dont know what this is
(yet)
- olk : uses ssgStripify, dont know what this is
(yet)
Uhmmm, enough food for me to look into. Any other
hints ?
(I'm to bed now, time to process the info in deep
sleep)
Leon
=
My Flight Gear Multiplayer Stuff (work-in-progress):
http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/
OK, I admit it: My girlfriend's just an object to me.
Unfortunately, there is some information hiding, but
thankfully, she's fairly encapsulated, nicely modular, and
has a very well defined interface!
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Random stats
These may or may not be interesting, but here are some recent stats for anyone who cares. In the last year, the biggest month for the web server was September when we did the 0.8.0 release. We did 180615 web hits in a single day (Sep. 13). This month when we released 0.9.0 we had a day (Dec. 4) where we hit 206997 web server hits in a single day. We were in the middle of moving the primary web server to new hardware then, and dns hadn't totally flushed through the system, so the old machine got 34167 hits on that same day, so really we did 241164 hits that day. From the ftp server stats, over the last 8 days, about 1800 copies of the prebuilt windows version have been downloaded ... that's about 225 downloads a day ... and that's just on the primary ftp site not including any of the mirrors. 700 people have downloaded the cd-rom image over the same time period ... that's almost 90 people a day. (I just updated that to the 0.9.1 version today by the way.) :-) Only 55 people have downloaded the Mac version. That ought to go up as soon as we get a 0.9.1 version built for Mac, and also as our Mac support get's better. Previously even the prebuilt binary has been a bear to get going. I'm trying to add reasonable Mac support to my FlightGear cd, but I'm waiting on a 0.9.1 build before I continue with that. The ftp server has been pushing almost 12Gb of data out per day. Again, this doesn't include any of the mirror sites. The primary ftp server now has a user limit of 15. We run pretty close to that *all* the time. Slots do open up frequently, but they are also grabbed frequently. If you are trying to get through, keep trying, or try one of the mirror sites. http://seneca.me.umn.edu/mrtg/ftpcount.html I was looking at linux counter site the other day: http://counter.li.org/ This guy is trying to get some sort of estimate of total linux users in the world ... he presents a bunch of different guesses based on various estimation methods. He concludes that if you get to pick a number and pick the factor you multiply it by, you can come up with any answer you want. This gave me an idea. I thought it might be interesting to use the flight simulator approach to estimating total users of an operating system. 1. Determine number of windows users in the world today. 2. Determine the number of them that run MSFS. These numbers are probably available someplace. 3. factor = Total/MSFS. 4. Determine the number of flightgear users running a particular platform. 5. Multiply by factor to get the total world wide users of that platform. Ok, sorry for getting so off topic ... :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
re: [Flightgear-devel] Default startup aircraft
David Megginson writes: Curtis L. Olson writes: David Megginson writes: Well, let's start cleaning them up. I don't think we're too far off, and with Andy's patch to make hotspots visible, it should be easy to debug the mouse problems and to add new hotspots for 3D instruments. That sounds great. I think our support for fully operation 3d cockpits is really cool and definitely worth showing off up front. (But like you say, with a few minor clean ups first.) I'd like to use the 172P rather than the 172R as our default, once it's ready. The model is much better, though it's still missing a couple of 3D items in the cockpit. The dimensions are more realistic, etc. etc. It even has an animated trim: fgfs --aircraft=c172p-3d Yup, that's the one I've been using. It has a wierd jitter on the ground in the gear model that also causes it to spin slowly left. I don't know if that is something in the aero config or in the gear code, but I'd like to put that on the gripe list as well. But over all it is really nice, and after flying with the 3d cockpit for a little bit, you can really get used to it. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] J3 Cub won't converge
I wrote: Curtis L. Olson wrote: With the latest YASim changes, the J3 Cub won't converge for me (and others.) Confirmed. Sorry, I didn't test this one. OK, fixed. The model was almost converging, but wasn't getting close enough to the threshold. It was oscillating around the right values, but each iteration moved to far to be considered done. This is a problem with this kind of heuristic. Just moving the solution precision targets a tiny bit was sufficient to fix the problem. I should probably make this number settable in the configuration file, for aircraft that run into problems. It affected the Cub because it's small and light -- relative changes in performance per-AoA and per-knot (i.e. the first derivatives of the solution functions) are higher. The problem is therefore stiff, in the lingo of computation differential equations. One exacerbating factor that I noticed is that the Cub we model has a *monster* elevator. Holding the aircraft at its stall AoA requires only 35% back stick. Is that really correct? I changed the lift parameter on the hstab from 1.7 to 1.3 and seemed to get better results. I've never flown one, though, so I hesitate to check the change in. As above, this makes the moment per elevator derivative bigger and the problem stiffer. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Default startup aircraft
Curtis L. Olson writes: Yup, that's the one I've been using. It has a wierd jitter on the ground in the gear model that also causes it to spin slowly left. I don't know if that is something in the aero config or in the gear code, but I'd like to put that on the gripe list as well. Noted. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] BA-609, V-22 derivative aircraft
The big problematic area for this class of aircraft historically has been the transition between hover, or rotor based operation and flying, where the wings are important. That regime is unstable and recovery difficult. This does not have to be as difficult as it is with the V-22. The Osprey is designed for being stuffed into _very_ small space below a ship's deck. If they had more space then it would have been possible to improve security simply by increasing the wing span, 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] 0.9.1 for Mac OS X 10.1.5
I would really like to build it, but since I haven't been able to access CVS since the roll out of 0.9.1, I can't. It's odd that only the CVS FlightGear and SimGear don't work (plib works just great). If someone would like to help me get CVS access again, I would love to build the MacOS 10.1 version. I know that CVS access is not strictly required to get the Mac version to build, but it makes things much easier for me to submit the required changes. Jonathan Polley On Wednesday, Dec 11, 2002, at 02:31PM, Curtis L. Olson [EMAIL PROTECTED] wrote: Has anyone built FlightGear 0.9.1 for Mac OS X yet? I'd like to be able to add the mac version to the downloads section at some point. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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 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] Re: J3 Cub won't converge
Andy Ross [EMAIL PROTECTED] writes: OK, fixed. The model was almost converging, but wasn't getting close enough to the threshold. It was oscillating around the right values, but each iteration moved to far to be considered done. This is a problem with this kind of heuristic. Just moving the solution precision targets a tiny bit was sufficient to fix the problem. I should probably make this number settable in the configuration file, for aircraft that run into problems. after updating to the latest cvs, i can't fly the a4-yasim anymore: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to -0.000431126ft... ...initializing sea-level radius... lat = 37.6117 alt = -0.000431126 ...initializing velocities... ...initializing Euler angles... End common FDM init YASim solution results: Iterations: 10002 Drag Coefficient: 9.68511 Lift Ratio: 168.785 Cruise AoA: 2.77861 Tail Incidence: -3.89015 Approach Elevator: -0.557698 CG: -0.721, -0.000, 0.092 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations i wonder if the above-mentioned fixed broke the a4? the j3cub works. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ld: Undefined symbols error linking fgfs 0.9.1
Quoth Andy Ross: Some of the missing symbols (slScheduler et. al.) should be found in the Plib sl library, which for some reason doesn't appear on your linker command line. The reason is that $HOSTTYPE is not macintosh, it is powerpc. I checked 10.0.4 and 10.1 on a TiBook, and 10.2 on a G4 tower, and uname -p reports powerpc in all three instances. So I don't know where the original value macintosh came from. There are three instances of '$HOSTTYPE = macintosh' in configure that need to be changed to powerpc. See below. I am getting to the final link again, but getting a much different error. Progress! # less configure [...] # Check for audio support echo $as_me:$LINENO: checking for audio support 5 echo $ECHO_N checking for audio support... $ECHO_C 6 audio_LIBS= if test -r /usr/include/soundcard.h \ -o -r /usr/include/linux/soundcard.h \ -o -r /usr/include/machine/soundcard.h \ -o -r /usr/include/audio.h \ -o x$ac_cv_header_windows_h = xyes \ -o $HOSTTYPE = macintosh; then cat confdefs.h \_ACEOF #define ENABLE_AUDIO_SUPPORT 1 _ACEOF audio_LIBS=-lplibsl -lplibsm [...] # ./configure [...] checking for audio support... no [...] Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
On Wednesday 11 December 2002 6:30 pm, Jonathan Polley wrote: I would really like to build it, but since I haven't been able to access CVS since the roll out of 0.9.1, I can't. It's odd that only the CVS FlightGear and SimGear don't work (plib works just great). If someone would like to help me get CVS access again, I would love to build the MacOS 10.1 version. I know that CVS access is not strictly required to get the Mac version to build, but it makes things much easier for me to submit the required changes. Check the FGFS and simgear sites. When Curt split the dev and stable branches he did it with separate repositories, so the log in changed. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Random stats
In the last year, the biggest month for the web server was September when we did the 0.8.0 release. We did 180615 web hits in a single day (Sep. 13). This month when we released 0.9.0 we had a day (Dec. 4) where we hit 206997 web server hits in a single day. We were in the middle of moving the primary web server to new hardware then, and dns hadn't totally flushed through the system, so the old machine got 34167 hits on that same day, so really we did 241164 hits that day. I thought several web mirrors were also included into your counter. I strongly believe at least the hits of www.de.projectgear.org are counted. The ftp server has been pushing almost 12Gb of data out per day. Again, this doesn't include any of the mirror sites. Today I saw the Squid proxy of a Hungarian Benedictine Abbey showing up in my ftp server logfiles. They were downloading FlightGear Senery :-)) 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] 0.9.1 for Mac OS X
I gave it a try last week (Mac OS X 10.2). I had to make a bunch of small fixes to the clouds3d code to get it to compile. Mostly this involved changing int to GLint. Also had to add a current gl context function (Q: why is this needed?). http://homepage.mac.com/walisser/.cv/walisser/Public/FlightGear/clouds3d.diff-binhex.hqx I then found some errors in the xml package. The exception throwing code crashes rather than throwing the exception because it frees the object that is throwing the exception and then trys to use it again. The easy fix is to remove the free (which I've done). Better would be to save the values that are needed later: http://homepage.mac.com/walisser/.cv/walisser/Public/FlightGear/easyxml.diff-binhex.hqx The end result of these changes is a sort-of running version. The clouds3d option doesn't work. It doesn't crash, but eats up huge quantities of memory (300MB+) after running(during fgfs startup) for a few minutes at which point I give up on it. I'm pretty sure none of my changes could have caused this. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Segfault, CVS this AM, gdb stack trace
Hmmm...I'm not getting any sound at all with this afternoon's cvs.
Best,
Jim
Curtis L. Olson [EMAIL PROTECTED] said:
Looks like fgInitProps() needs to have the sound manager initialized
first. When it ties /sim/freeze/master, this calls setFreeze() which
needs to have a valid globals-get_sound_mgr(). We might also be able
to test if sound_mgr is null and not try to mess with it.
Regards,
Curt.
William Earnest writes:
Hello,
Managed to get more info than usual from an execution crash after
rebuild with 12/11/02 7AM EST CVS. Hope someone can make use of it.
Run on RH 7.1, g++ = 2.96-112.7.1 of RH.
--
Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA
Computers, like air conditioners, work poorly with Windows open.
Done reading panel instruments
Loaded new panel from Aircraft/c172/Panels/c172-vfr-panel.xml
leave NewTgtAirportInit()start of fgInitProps()
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4124)]
0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
241 inline FGSoundMgr *get_soundmgr() const { return soundmgr; }
(gdb) bt
#0 0x0807bd47 in setFreeze (f=false) at ../../src/Main/globals.hxx:241
#1 0x08404fd2 in SGRawValueFunctionsbool::setValue (this=0x92a8368,
value=false) at /usr/local/include/simgear/misc/props.hxx:331
#2 0x083817a7 in SGPropertyNode::setBoolValue (this=0x8853aa0, value=false)
at props.cxx:374
#3 0x08382bc6 in SGPropertyNode::tie (this=0x8853aa0, rawValue=@0xb490,
useDefault=true) at props.cxx:1522
#4 0x0807c4f1 in fgInitProps () at ../../src/Main/globals.hxx:254
#5 0x08074a14 in fgInitSubsystems () at fg_init.cxx:1596
#6 0x0805315a in fgIdleFunction () at main.cxx:1314
#7 0x40288123 in idleWait () from /usr/lib/libglut.so.3
#8 0x080561ee in main (argc=1, argv=0xb944) at main.cxx:1815
#9 0x4032c657 in __libc_start_main (main=0x80561d0 main, argc=1,
ubp_av=0xb944, init=0x804def8 _init, fini=0x8452c34 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb93c)
at ../sysdeps/generic/libc-start.c:129
--
Curtis Olson IVLab / HumanFIRST Program 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
--
Jim Wilson - IT Manager
Kelco Industries
PO Box 160
58 Main Street
Milbridge, ME 04658
207-546-7989 - FAX 207-546-2791
http://www.kelcomaine.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Segfault, CVS this AM, gdb stack trace
Jim Wilson writes: Hmmm...I'm not getting any sound at all with this afternoon's cvs. A light slowly begins to glow brighter above my head ... hold on. Looks like I inadvertantly dropped the AC_DEFINE(ENABLE_AUDIO_SUPPORT) so we were getting built without audio support which was why the freeze was crashing when it tried to pause audio playing. I think in this day and age we can just assume audio support and let plib do the rest. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] New Segfault, CVS this AM, gdb stack trace
Hehe...I was just going to send an email on that. Maybe that pause code in fgprops should be ifdef'd with ENABLE_AUDIO_SUPPORT if you decide not to do away with the flag. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson writes: Hmmm...I'm not getting any sound at all with this afternoon's cvs. A light slowly begins to glow brighter above my head ... hold on. Looks like I inadvertantly dropped the AC_DEFINE(ENABLE_AUDIO_SUPPORT) so we were getting built without audio support which was why the freeze was crashing when it tried to pause audio playing. I think in this day and age we can just assume audio support and let plib do the rest. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: J3 Cub won't converge
Andy, For what it's worth, I can reproduce this. Regards, Curt. Alex Romosan writes: Andy Ross [EMAIL PROTECTED] writes: OK, fixed. The model was almost converging, but wasn't getting close enough to the threshold. It was oscillating around the right values, but each iteration moved to far to be considered done. This is a problem with this kind of heuristic. Just moving the solution precision targets a tiny bit was sufficient to fix the problem. I should probably make this number settable in the configuration file, for aircraft that run into problems. after updating to the latest cvs, i can't fly the a4-yasim anymore: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to -0.000431126ft... ...initializing sea-level radius... lat = 37.6117 alt = -0.000431126 ...initializing velocities... ...initializing Euler angles... End common FDM init YASim solution results: Iterations: 10002 Drag Coefficient: 9.68511 Lift Ratio: 168.785 Cruise AoA: 2.77861 Tail Incidence: -3.89015 Approach Elevator: -0.557698 CG: -0.721, -0.000, 0.092 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations i wonder if the above-mentioned fixed broke the a4? the j3cub works. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] Slackware Packages
Jon Stockill writes: New Slackware 8.0/8.1 and 9.0 packages for FlightGear 0.9.1 are now available at http://flightgear.stockill.org.uk/ Thanks! Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
On Wednesday, December 11, 2002, at 06:25 PM, John Check wrote: On Wednesday 11 December 2002 6:30 pm, Jonathan Polley wrote: I would really like to build it, but since I haven't been able to access CVS since the roll out of 0.9.1, I can't. It's odd that only the CVS FlightGear and SimGear don't work (plib works just great). If someone would like to help me get CVS access again, I would love to build the MacOS 10.1 version. I know that CVS access is not strictly required to get the Mac version to build, but it makes things much easier for me to submit the required changes. Check the FGFS and simgear sites. When Curt split the dev and stable branches he did it with separate repositories, so the log in changed. I have looked at both sites and they still show 0.8/0.9 (FlightGear) and 0.2/0.3 (SimGear). I have tried logging into SimGear 0.3.1 and FlightGear 0.9.1 but both fail in the same manner. What is the proper repository? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X
On Wednesday, December 11, 2002, at 06:49 PM, darrell.l.walisser.1 wrote: The end result of these changes is a sort-of running version. The clouds3d option doesn't work. It doesn't crash, but eats up huge quantities of memory (300MB+) after running(during fgfs startup) for a few minutes at which point I give up on it. I'm pretty sure none of my changes could have caused this. I saw the same problem with the 3D clouds earlier. It appeared to be an endian issue as the offending value was 0x200 (or something similar). Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 0.9.1 for Mac OS X
Jonathan Polley writes: On Wednesday, December 11, 2002, at 06:49 PM, darrell.l.walisser.1 wrote: The end result of these changes is a sort-of running version. The clouds3d option doesn't work. It doesn't crash, but eats up huge quantities of memory (300MB+) after running(during fgfs startup) for a few minutes at which point I give up on it. I'm pretty sure none of my changes could have caused this. I saw the same problem with the 3D clouds earlier. It appeared to be an endian issue as the offending value was 0x200 (or something similar). I would suggest ignoring the 3d clouds for now. They still need a lot of TLC before they will really be useful. If 0.9.1 is too much of a hassle to get running, please feel free to submit changes relative to current CVS, and we can do a 0.9.2 release and get a good Mac build for that. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
Jonathan Polley writes: I have looked at both sites and they still show 0.8/0.9 (FlightGear) and 0.2/0.3 (SimGear). I have tried logging into SimGear 0.3.1 and FlightGear 0.9.1 but both fail in the same manner. What is the proper repository? Jonathan, Next time you try to do a cvs update (and fail) send me [offlist] the command you tried, the error messages you received, and the time you tried it. If nothing is obvious from the error messages, I can check the server logs, but I need to know a time since the logs are very large. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program 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] Re: Default startup aircraft
I like the c172p-3d 3d model and 3d cockpit a lot. Three comments/concerns for the recent changes to the flight model: 1. The nose pitch-up when adding flaps seems extreem. If I don't change the elevator trim a lot, the plane actually stalls. If I recall correctly, the Piper Tri-Pacer had a slight pitch up with added flaps. But the Cessna 172 nose pitches down a little and you have to make minor trim changes more like the c182 in FlightGear. 2. The adverse aileron yaw is too much at modrate speeds. In fact, since these changes, the wing leveler auto pilot will cause ever increasing aileron oscillations leading to a crash with the c172p. 3. The rate of descent with full flaps seems less than it should be. What do the rest of you think, especially those with recent real c172 time? It has been several years since I flew the c172. Regards, Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: J3 Cub won't converge
Curtis L. Olson wrote: Alex Romosan wrote: after updating to the latest cvs, i can't fly the a4-yasim anymore: For what it's worth, I can reproduce this. Oddly, I couldn't; the A-4 worked fine. But I did notice a newly induced failure of the (rarely used) Cessna 310 model. I gave it some more thought, and changed the mechanism a little to make the solution converge more slowly. This is checked in now, and I can verify that (at least on my machine) it produces a valid solution for every YASim aircraft in CVS. It is a little slower at the solution, though. The long-wing aircraft (which have more elements) like the 747 take as much as 2 seconds to solve now. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Default startup aircraft
Dave Perry writes: I like the c172p-3d 3d model and 3d cockpit a lot. Three comments/concerns for the recent changes to the flight model: 1. The nose pitch-up when adding flaps seems extreem. If I don't change the elevator trim a lot, the plane actually stalls. If I recall correctly, the Piper Tri-Pacer had a slight pitch up with added flaps. But the Cessna 172 nose pitches down a little and you have to make minor trim changes more like the c182 in FlightGear. I have some experience with a very high fidelity C172 model (commercial) based on real, instrumented flight data. Even at speeds as slow as 90 knots the model will come close to looping unless you add a lot of down elevator. I've never tried this in a real C172, but I can see that for a real pilot, pushing forward on the yoke to hold the nose down after applying flaps could become an almost unconcious act. When you are flying from mouse/keyboard it's just not the same and these sorts of effects can be surprising. Even just with flying with a yoke and having your hands on it, you really don't need to add much down force to keep the nose from ballooning. I have no opinions on #2 and #3 right now. Regards, Curt. 2. The adverse aileron yaw is too much at modrate speeds. In fact, since these changes, the wing leveler auto pilot will cause ever increasing aileron oscillations leading to a crash with the c172p. 3. The rate of descent with full flaps seems less than it should be. What do the rest of you think, especially those with recent real c172 time? It has been several years since I flew the c172. Regards, Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] Re: J3 Cub won't converge
Andy Ross writes: Curtis L. Olson wrote: Alex Romosan wrote: after updating to the latest cvs, i can't fly the a4-yasim anymore: For what it's worth, I can reproduce this. Oddly, I couldn't; the A-4 worked fine. But I did notice a newly induced failure of the (rarely used) Cessna 310 model. I gave it some more thought, and changed the mechanism a little to make the solution converge more slowly. This is checked in now, and I can verify that (at least on my machine) it produces a valid solution for every YASim aircraft in CVS. It is a little slower at the solution, though. The long-wing aircraft (which have more elements) like the 747 take as much as 2 seconds to solve now. After my post I also noticed the 747 was broke. Both are now working for me with the latest tweak. Thanks for the quick service. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
re: [Flightgear-devel] Default startup aircraft
On Wed, 2002-12-11 at 17:20, David Megginson wrote: Curtis L. Olson writes: I notice that we can't operate the mixture, throttle, flaps via panel clicks and some of the knob click areas are a little off. Any thing else? The more I run with the 3d panels the more I like them, and the more I dislike the 2d panels (although we still need to support 2d panels for various reasons.) Well, let's start cleaning them up. I don't think we're too far off, and with Andy's patch to make hotspots visible, it should be easy to debug the mouse problems and to add new hotspots for 3D instruments. I'm new to Flightgear, so I don't know if carb heat is simulated. But, in the c172p-3d model, the carburetor heat is stuck in the on position. I'd prefer to be able to turn it off so that I can get all of the climb performance I can... :-) Also, the aircraft C-FGFS has a bit of a more of a left-yaw and left-roll tendency than the climb-prop equipped 145hp Cessna 172 that I rent(N5394T). The ground-adjustable rudder trim tab on 94T is set so that it flies coordinated without any rudder input at 105mph. Other than that, I really like the model and the 3d panel! This particular model feels good and takes about the same amount of effort to fly as the real thing, so I vote for it being the default. -Luke -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Default startup aircraft
On Wed, 2002-12-11 at 21:24, Curtis L. Olson wrote: Dave Perry writes: I like the c172p-3d 3d model and 3d cockpit a lot. Three comments/concerns for the recent changes to the flight model: 1. The nose pitch-up when adding flaps seems extreem. If I don't change the elevator trim a lot, the plane actually stalls. If I recall correctly, the Piper Tri-Pacer had a slight pitch up with added flaps. But the Cessna 172 nose pitches down a little and you have to make minor trim changes more like the c182 in FlightGear. I have some experience with a very high fidelity C172 model (commercial) based on real, instrumented flight data. Even at speeds as slow as 90 knots the model will come close to looping unless you add a lot of down elevator. I've never tried this in a real C172, but I can see that for a real pilot, pushing forward on the yoke to hold the nose down after applying flaps could become an almost unconcious act. When you are flying from mouse/keyboard it's just not the same and these sorts of effects can be surprising. Even just with flying with a yoke and having your hands on it, you really don't need to add much down force to keep the nose from ballooning. I've never noticed a nose-up tendency when I pull on the flaps. But, I tend to pull them on slowly and gently - and at a lower airspeed (= 90mph for landing). The flaps in the C172 make you go down, not up. OTOH, when you have full flaps down and you hit the throttle (in a go-around type situation), the nose almost shoots up into the air. It takes a lot of forward force on the yoke to keep the plane level with the ground. The lack of nose-up when I'm pulling on the flaps may just be because I'm correcting for the nose-up without thinking about it. I'll try to note this (along with the left-roll tendency) the next time I go flying. -Luke -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Slackware Packages
New Slackware 8.0/8.1 and 9.0 packages for FlightGear 0.9.1 are now available at http://flightgear.stockill.org.uk/ Enjoy! -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Random stats
Martin Spott writes: I thought several web mirrors were also included into your counter. I strongly believe at least the hits of www.de.projectgear.org are counted. Well yes, all the mirrors point to the same web counter, but that is more of a gimicy thing anyway ... I wasn't quoting any numbers from that. Instead I was looking at webalizer stats and ftp xfer stats which are local to my machine only. Today I saw the Squid proxy of a Hungarian Benedictine Abbey showing up in my ftp server logfiles. They were downloading FlightGear Senery :-)) You'd think I'd be able to come up with a good response to this, but it must be late ... I guess there are a lot worse things than an endorsement from God ... maybe they were working on the architectual drawings for Earth, phase two ... and rather than start from scratch figured the flightgear 3d terrain would be a good head start... Curt. -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] Re: ld: Undefined symbols error linking fgfs 0.9.1
Your best bet is to check the detailed results in config.log when configure failes a check which you think ought to pass. Regards, Curt. David Drum writes: I am getting to the final link again, but getting a much different error. Progress! # less configure [...] # Check for audio support echo $as_me:$LINENO: checking for audio support 5 echo $ECHO_N checking for audio support... $ECHO_C 6 audio_LIBS= if test -r /usr/include/soundcard.h \ -o -r /usr/include/linux/soundcard.h \ -o -r /usr/include/machine/soundcard.h \ -o -r /usr/include/audio.h \ -o x$ac_cv_header_windows_h = xyes \ -o $HOSTTYPE = macintosh; then cat confdefs.h \_ACEOF #define ENABLE_AUDIO_SUPPORT 1 _ACEOF audio_LIBS=-lplibsl -lplibsm [...] # ./configure [...] checking for audio support... no [...] Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program 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
Re: [Flightgear-devel] 0.9.1 for Mac OS X 10.1.5
On Wednesday 11 December 2002 9:05 pm, Jonathan Polley wrote: On Wednesday, December 11, 2002, at 06:25 PM, John Check wrote: On Wednesday 11 December 2002 6:30 pm, Jonathan Polley wrote: I would really like to build it, but since I haven't been able to access CVS since the roll out of 0.9.1, I can't. It's odd that only the CVS FlightGear and SimGear don't work (plib works just great). If someone would like to help me get CVS access again, I would love to build the MacOS 10.1 version. I know that CVS access is not strictly required to get the Mac version to build, but it makes things much easier for me to submit the required changes. Check the FGFS and simgear sites. When Curt split the dev and stable branches he did it with separate repositories, so the log in changed. I have looked at both sites and they still show 0.8/0.9 (FlightGear) and 0.2/0.3 (SimGear). Those be them. Sorry. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
