Re: [Flightgear-devel] Newbie - MSVC Linking problem
You need to add wsock32.lib in your flightgear project Cheers, -Fred - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 29, 2002 7:29 PM Subject: [Flightgear-devel] Newbie - MSVC Linking problem I am new to FlightGear and have been trying to build it with MSVC 6. I have Service Pack 5 installed. I am able to build all libaries: plib, SimGear, etc.. I have the projects set for Debug Multithreaded DLL. When I try to build FlightGear I receive the following linker errors: FGfdmSocket.obj : error LNK2001: unresolved external symbol _connect@12 net.lib(netSocket.obj) : error LNK2001: unresolved external symbol _connect@12 FGfdmSocket.obj : error LNK2001: unresolved external symbol _htons@4 [ lots of WinSock unresolved symbols] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim: yasim
Hi Andy, Now that your five minutes of fame are over, I'd like to ask you to remove the creation of the yasim program in a default build, because it has a lot of dependancy problems for me (IRIX/MipsPro). First it needs all objects files from src/Main and libFlight.a from src/FDM but also libssg, which requires -lGL -lplubul and -lplibsg and so on. I'll try to see if I can illiminate most of them by only adding the YASim object files required by yasim-test instead of including libYASim as a whole. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] UIUC recoring files
Hi, After recent changes the UIUC aircraft seem to generate a uiuc_record.dat file. I would like to ask the UIUC developers to leave this option(?) off for production files included in the FlightGear base package. They are left in the current directory where FlightGear is called from, which causes the files to get scattered all over the system. :-( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim stuff
Andy Ross writes: > And Curt: this should also fix the tile loader bug where the data gets > corrupted if you fly the A-4 for 3600km. I don't thinkg it can't get > that far anymore. :) Andy, We have a property called "/sim/freeze/fuel" when this is "true" the idea is to make the fuel quantity diminish, but everything else works normally. This is useful in training when you want to deal with one set of numbers or practice the same thing over and over again. How hard would it be to read the value of this property and not subtract from the fuel quantities when this is true? 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] YASim: yasim
Erik Hofman wrote: > Now that your five minutes of fame are over, I'd like to ask you to > remove the creation of the yasim program in a default build, because > it has a lot of dependancy problems for me (IRIX/MipsPro). > > First it needs all objects files from src/Main and libFlight.a from > src/FDM but also libssg, which requires -lGL -lplubul and -lplibsg and > so on. > > I'll try to see if I can illiminate most of them by only adding the > YASim object files required by yasim-test instead of including > libYASim as a whole. Hrm... libYASim.a is a static library. It doesn't (well, shouldn't) have dependency information in it. Some of the files reference the rest of FlightGear, but none are linked into the yasim executable. Are you sure about this error? It sounds like the Irix linker is getting itself into a weird mode. The whole point of a static library is that you put a bunch of code into it without regard for who needs what and sort it all out at link time. What does your ar command look like to link the library? I'm wondering if this is a bug in autoconf or libtool on Irix. I mostly copied this stuff from the Input directory, and don't see any obvious differences. The libInput files also reference the rest of FlightGear, SimGear, plib and GL. I'm wondering why don't you get the same errors with js_demo and fgjs? Certainly using only object files will work to remove the libYASim dependencies. But you'll also need the sgmisc, sgdebug and sgxml libraries. If these also have dependencies on plib or GL, then you're still going to have the same problem with pulling in unrelated libraries. 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] UIUC recoring files
At 11/30/02, Erik Hofman wrote: Hi, After recent changes the UIUC aircraft seem to generate a uiuc_record.dat file. I would like to ask the UIUC developers to leave this option(?) off for production files included in the FlightGear base package. They are left in the current directory where FlightGear is called from, which causes the files to get scattered all over the system. :-( I forgot to comment out the record lines w/ the last update to the Sopwith Camel. I just posted an update to the cvs to stop this recording w/ the Camel. From what I see, none of the other UIUC airplanes have recording turned on, so it only should have happened w/ the Sopwith Camel assuming you have an update-to-date base package cvs (and assuming I'm not missing anything, which is what happened in the first place!). FYI - With the UIUC planes, the default is no recording. Recording options can be turning on w/ lines inside the aircraft.dat files (e.g. see lines after the '*' in ~/fgfsbase/Aircraft/UIUC/sopwithCamel-v1-nl/aircraft.dat). When it is on, running fgfs will produce a stream of sim data to the file uiuc_record.dat to the current dir. I always run from the same dir, so there's only one file. This way files don't end up "all over the system", which would be a bummer. Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim: yasim
Andy Ross writes: > Hrm... libYASim.a is a static library. It doesn't (well, shouldn't) > have dependency information in it. Some of the files reference the > rest of FlightGear, but none are linked into the yasim executable. > > Are you sure about this error? It sounds like the Irix linker is > getting itself into a weird mode. The whole point of a static library > is that you put a bunch of code into it without regard for who needs > what and sort it all out at link time. What does your ar command look > like to link the library? I'm wondering if this is a bug in autoconf > or libtool on Irix. > > I mostly copied this stuff from the Input directory, and don't see any > obvious differences. The libInput files also reference the rest of > FlightGear, SimGear, plib and GL. I'm wondering why don't you get the > same errors with js_demo and fgjs? > > Certainly using only object files will work to remove the libYASim > dependencies. But you'll also need the sgmisc, sgdebug and sgxml > libraries. If these also have dependencies on plib or GL, then you're > still going to have the same problem with pulling in unrelated > libraries. Andy, It's my understanding that the Irix linker isn't as smart as the gnu linker when it comes to figuring out what is needed or not. For instance pretend you have a library with one function that references something in OpenGL land. If you link in that library under Irix, you must also link with libGL because something in that lib references it, even if it's never used by your application. That means we can end up linking in a bunch of odd seemly unrelated stuff in order to make the Irix linker happy. That's not 100% pleasant, but I guess I can think of worse things to have done to me. 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
[Flightgear-devel] Error from latest CVS
Hello, Updated CVS this morning at 8:22 EST, tried compiling a bit later. Got the following error(s): g++ -g -O2 -L/usr/X11R6/lib -o js_demo js_demo.o -lplibsl -lplibsm -lplibul -lm js_demo.o: In function `main': /home/wde/FG/src/Input/js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' /home/wde/FG/src/Input/js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' collect2: ld returned 1 exit status Being inexperienced with C++, I got lost trying to trace the cause. The only updates that CVS showed were in FlightGear and plib. Tried to disable just that bit, but ties to other files only made the problem worse. Suggestions from the experts? BTW, c++ is gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.1). -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error from latest CVS
William Earnest writes: > Updated CVS this morning at 8:22 EST, tried compiling a bit later. > Got the following error(s): > > g++ -g -O2 -L/usr/X11R6/lib -o js_demo js_demo.o -lplibsl -lplibsm > -lplibul -lm > js_demo.o: In function `main': > /home/wde/FG/src/Input/js_demo.cxx:21: undefined reference to > `jsJoystick::jsJoystick(int)' > /home/wde/FG/src/Input/js_demo.cxx:84: undefined reference to > `jsJoystick::read(int *, float *)' > collect2: ld returned 1 exit status > > Being inexperienced with C++, I got lost trying to trace the cause. > The only updates that CVS showed were in FlightGear and plib. > Tried to disable just that bit, but ties to other files only made the > problem worse. Suggestions from the experts? BTW, c++ is gcc version > 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.1). There were some updates to plib that are probably causing this. The JS routines were split out into their own library. We probably need to link with -lplibjs if it exists. I haven't updated to the latest plib cvs recently so I haven't looked closely at this. 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] Error from latest CVS
Curtis L. Olson wrote: William Earnest writes: > Updated CVS this morning at 8:22 EST, tried compiling a bit later. >Got the following error(s): > >g++ -g -O2 -L/usr/X11R6/lib -o js_demo js_demo.o -lplibsl -lplibsm >-lplibul -lm >js_demo.o: In function `main': >/home/wde/FG/src/Input/js_demo.cxx:21: undefined reference to >`jsJoystick::jsJoystick(int)' >/home/wde/FG/src/Input/js_demo.cxx:84: undefined reference to >`jsJoystick::read(int *, float *)' >collect2: ld returned 1 exit status > > Being inexperienced with C++, I got lost trying to trace the cause. >The only updates that CVS showed were in FlightGear and plib. >Tried to disable just that bit, but ties to other files only made the >problem worse. Suggestions from the experts? BTW, c++ is gcc version >2.96 2731 (Red Hat Linux 7.2 2.96-112.7.1). There were some updates to plib that are probably causing this. The JS routines were split out into their own library. We probably need to link with -lplibjs if it exists. I haven't updated to the latest plib cvs recently so I haven't looked closely at this. Regards, Curt. Hi again, Stuck that lib in the Makefile, and those 2 errors vanished. The new one is: /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libplibjs.a(jsLinux.o): In function `jsJoystick::rawRead(int *, float *)': /home/wde/PL/src/js/jsLinux.cxx:148: undefined reference to `ulSetError(ulSeverity, char const *,...)' collect2: ld returned 1 exit status Progress in small increments... Maybe I should try backing off several days on plib until it all syncs up? -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Error from latest CVS
William Earnest wrote: > js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' > js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' Recent plib changes have turned the joystick routines from an inlined header file into a real library. You need to add a -lplibjs to the _LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. Looking at this, by the way, was what got me to add the command line YASim compiler to the default build. Normally I fear automake/autoconf. :) Responding to a later note: > Stuck that lib in the Makefile, and those 2 errors vanished. The new > one is: > > Progress in small increments... The order is important. The -lplibjs must come before -lplibul to get the dependencies correct. Remember to do the same thing to your src/Main/Makefile.am, or else the fgfs binary will get the same error. 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] Error from latest CVS
Sounds like you'll also need -lplibul ... William Earnest writes: > Curtis L. Olson wrote: > > > William Earnest writes: > > > > > Updated CVS this morning at 8:22 EST, tried compiling a bit later. > > >Got the following error(s): > > > > > >g++ -g -O2 -L/usr/X11R6/lib -o js_demo js_demo.o -lplibsl -lplibsm > > >-lplibul -lm > > >js_demo.o: In function `main': > > >/home/wde/FG/src/Input/js_demo.cxx:21: undefined reference to > > >`jsJoystick::jsJoystick(int)' > > >/home/wde/FG/src/Input/js_demo.cxx:84: undefined reference to > > >`jsJoystick::read(int *, float *)' > > >collect2: ld returned 1 exit status > > > > > > Being inexperienced with C++, I got lost trying to trace the cause. > > >The only updates that CVS showed were in FlightGear and plib. > > >Tried to disable just that bit, but ties to other files only made the > > >problem worse. Suggestions from the experts? BTW, c++ is gcc version > > >2.96 2731 (Red Hat Linux 7.2 2.96-112.7.1). > > > > > > There were some updates to plib that are probably causing this. The > > JS routines were split out into their own library. We probably need > > to link with -lplibjs if it exists. I haven't updated to the latest > > plib cvs recently so I haven't looked closely at this. > > > > Regards, > > > > Curt. > > Hi again, > > > Stuck that lib in the Makefile, and those 2 errors vanished. The new > one is: > > /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libplibjs.a(jsLinux.o): > In function `jsJoystick::rawRead(int *, float *)': > /home/wde/PL/src/js/jsLinux.cxx:148: undefined reference to > `ulSetError(ulSeverity, char const *,...)' > collect2: ld returned 1 exit status > > Progress in small increments... Maybe I should try backing off > several days on plib until it all syncs up? > > -- > Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA > Computers, like air conditioners, work poorly with Windows open. > > > ___ > 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] Error from latest CVS
Andy Ross writes: > William Earnest wrote: > > js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' > > js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' > > Recent plib changes have turned the joystick routines from an inlined > header file into a real library. You need to add a -lplibjs to the > _LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. Unfortunately we can't just add -lplibjs to the _LDADD lines, this will break the build for everyone with a anything earlier than this week's plib cvs. Specifically we want to be able to build with the most recent official plib stable release. We really need to add a check for libplibjs.a in the configure script so it only get's added if it exists ... I sense this change might cause a bit of misery for people ... Curt. > > Looking at this, by the way, was what got me to add the command line > YASim compiler to the default build. Normally I fear > automake/autoconf. :) > > Responding to a later note: > > > Stuck that lib in the Makefile, and those 2 errors vanished. The new > > one is: > > > > Progress in small increments... > > The order is important. The -lplibjs must come before -lplibul to get > the dependencies correct. Remember to do the same thing to your > src/Main/Makefile.am, or else the fgfs binary will get the same error. > > 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 -- 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] Error from latest CVS
Curtis L. Olson wrote: Andy Ross writes: >William Earnest wrote: > > js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' > > js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' > >Recent plib changes have turned the joystick routines from an inlined >header file into a real library. You need to add a -lplibjs to the >_LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. Unfortunately we can't just add -lplibjs to the _LDADD lines, this will break the build for everyone with a anything earlier than this week's plib cvs. Specifically we want to be able to build with the most recent official plib stable release. We really need to add a check for libplibjs.a in the configure script so it only get's added if it exists ... I sense this change might cause a bit of misery for people ... Curt. >Looking at this, by the way, was what got me to add the command line >YASim compiler to the default build. Normally I fear >automake/autoconf. :) > >Responding to a later note: > > > Stuck that lib in the Makefile, and those 2 errors vanished. The new > > one is: > > > > Progress in small increments... > >The order is important. The -lplibjs must come before -lplibul to get >the dependencies correct. Remember to do the same thing to your >src/Main/Makefile.am, or else the fgfs binary will get the same error. > >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 Hello, Although not the final solution, Andy's hints were enough to give a successful compile. At execution, get a segfault right after the "Done reading panel instruments" message. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] plibjs
> Andy Ross writes: > > William Earnest wrote: > >> js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' > >> js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' > > > > Recent plib changes have turned the joystick routines from an inlined > > header file into a real library. You need to add a -lplibjs to the > > _LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. Curt comments: > Unfortunately we can't just add -lplibjs to the _LDADD lines, this > will break the build for everyone with a anything earlier than this > week's plib cvs. Specifically we want to be able to build with the > most recent official plib stable release. I'm tempted to suggest that the CVS tree of FGFS depends on the CVS of PLIB. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] plibjs
Alex Perry writes: > > Andy Ross writes: > > > William Earnest wrote: > > >> js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' > > >> js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' > > > > > > Recent plib changes have turned the joystick routines from an inlined > > > header file into a real library. You need to add a -lplibjs to the > > > _LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. > > Curt comments: > > Unfortunately we can't just add -lplibjs to the _LDADD lines, this > > will break the build for everyone with a anything earlier than this > > week's plib cvs. Specifically we want to be able to build with the > > most recent official plib stable release. > > I'm tempted to suggest that the CVS tree of FGFS depends on the CVS of PLIB. Then what happens when we go to release our next version. If we can't coerce the plib people into doing a new 'stable' release from their cvs code on our schedule, then we are stuck with a flightgear release that depends on a particular plib cvs version (not necessarily the head.) But it is tempting ... especially when there are fixes in plib cvs that we *need*. 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] plibjs
From: "Alex Perry" <[EMAIL PROTECTED]> > > Andy Ross writes: > > > William Earnest wrote: > > >> js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' > > >> js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' > > > > > > Recent plib changes have turned the joystick routines from an inlined > > > header file into a real library. You need to add a -lplibjs to the > > > _LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. > > Curt comments: > > Unfortunately we can't just add -lplibjs to the _LDADD lines, this > > will break the build for everyone with a anything earlier than this > > week's plib cvs. Specifically we want to be able to build with the > > most recent official plib stable release. > > I'm tempted to suggest that the CVS tree of FGFS depends on the CVS of PLIB. I think libplibjs has been there for a while (at least present in 1.6.0) even if it was empty until few days ago. It should be harmless to specify -lplibjs in the makefile ( Well, in fact '-lplibjs -lplibul' ) Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim stuff
Curtis L. Olson wrote: > We have a property called "/sim/freeze/fuel" [...] How hard would it > be to read the value of this property and not subtract from the fuel > quantities when this is true? Roger that. Just to be sure I got it right: when this value is "true", the simulator behaves like it used to. The fuel in the tanks doesn't change, nor does the weight distribution. When it is false, fuel is consumed normally. Is that right? 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] YASim: yasim
Erik Hofman wrote: > I'll try to see if I can illiminate most of them by only adding the > YASim object files required by yasim-test instead of including > libYASim as a whole. OK, I've checked in a Makefile.am that does exactly that. It still works for me; is Irix happier? 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] plibjs
Hey, I think you are right. Yup, I think we can just go ahead and drop -libplibjs into whereever it is needed. Regards, Curt. Frederic Bouvier writes: > From: "Alex Perry" <[EMAIL PROTECTED]> > > > > Andy Ross writes: > > > > William Earnest wrote: > > > >> js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' > > > >> js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float > *)' > > > > > > > > Recent plib changes have turned the joystick routines from an inlined > > > > header file into a real library. You need to add a -lplibjs to the > > > > _LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. > > > > Curt comments: > > > Unfortunately we can't just add -lplibjs to the _LDADD lines, this > > > will break the build for everyone with a anything earlier than this > > > week's plib cvs. Specifically we want to be able to build with the > > > most recent official plib stable release. > > > > I'm tempted to suggest that the CVS tree of FGFS depends on the CVS of > PLIB. > > I think libplibjs has been there for a while (at least present in 1.6.0) > even > if it was empty until few days ago. It should be harmless to > specify -lplibjs > in the makefile ( Well, in fact '-lplibjs -lplibul' ) > > Cheers, > > -Fred > > > > ___ > 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] New YASim stuff
Andy Ross writes: > Curtis L. Olson wrote: > > We have a property called "/sim/freeze/fuel" [...] How hard would it > > be to read the value of this property and not subtract from the fuel > > quantities when this is true? > > Roger that. Just to be sure I got it right: when this value is > "true", the simulator behaves like it used to. The fuel in the tanks > doesn't change, nor does the weight distribution. When it is false, > fuel is consumed normally. Is that right? Right, when fuel-freeze is true, fuel quantity doesn't change. 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] plibjs
Curtis L. Olson wrote: > Alex Perry wrote: > > I'm tempted to suggest that the CVS tree of FGFS depends on the > > CVS of PLIB. > > Then what happens when we go to release our next version. If we > can't coerce the plib people into doing a new 'stable' release from > their cvs code on our schedule, then we are stuck with a flightgear > release that depends on a particular plib cvs version True, but if that happens then we can write the configure check then instead of now. Put it off in the hope that there will be a new release available. Procrastination is your friend. :) 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] plibjs
Curtis L. Olson writes: > Then what happens when we go to release our next version. If we can't > coerce the plib people into doing a new 'stable' release from their > cvs code on our schedule, then we are stuck with a flightgear release > that depends on a particular plib cvs version (not necessarily the > head.) Or we spend a couple of hours backing out changes. 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] plibjs
David Megginson writes: > Curtis L. Olson writes: > > > Then what happens when we go to release our next version. If we can't > > coerce the plib people into doing a new 'stable' release from their > > cvs code on our schedule, then we are stuck with a flightgear release > > that depends on a particular plib cvs version (not necessarily the > > head.) > > Or we spend a couple of hours backing out changes. Hmmm, that doesn't sound like much fun though, and I'd hate to put that sort of hurdle between us and a release. It turns out that the item that sparked this discussion is mostly a non-issue thanks to the foresight of the plib team, but if we begin depending on plib-cvs features, it doesn't take much creativity to imagine some pretty difficult situations with respect to trying to back out changes in order to get a release out against the current stable plib. I agree though that if we find a bug in plib that directly affects us, or if a new feature was recently added to plib-cvs that would be *really* convenient to use, then it stinks to have to sit on a bug, or ingore a new feature because it hasn't made it into one of their stable releases yet. However, if we depend on a cvs version of plib, then this becomes a *big* problem for package builders because now they need to bundle up a non-released version and ship it with thier distro, and give it a version number. This sort of thing usually causes more problems than it solves. Personally, I think our best bet is to proactively pressure plib to do a new release when they've got something in cvs that we need ... before we get ourselves stuck between a rock and a hard place. 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] UIUC recoring files
Michael Selig wrote: I forgot to comment out the record lines w/ the last update to the Sopwith Camel. I just posted an update to the cvs to stop this recording w/ the Camel. From what I see, none of the other UIUC airplanes have recording turned on, so it only should have happened w/ the Sopwith Camel assuming you have an update-to-date base package cvs (and assuming I'm not missing anything, which is what happened in the first place!). No problem, it happened with JSBSim also in the past (and it might happen again in the future I guess). Thanks for the fix. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim: yasim
Andy Ross wrote: Erik Hofman wrote: > I'll try to see if I can illiminate most of them by only adding the > YASim object files required by yasim-test instead of including > libYASim as a whole. OK, I've checked in a Makefile.am that does exactly that. It still works for me; is Irix happier? Yep it does. Thanks for the quick response. I propose a small change in the Makefile which might make life a little easier in the future, by defining SHARED_SOURCES wich hold (indeed) all the files that are shared between the library and the stand alone interpreter. Erik --- /home/erik/src/CVS/fgfs/FlightGear/src/FDM/YASim/Makefile.amSat Nov 30 22:50:13 2002 +++ Makefile.am Sat Nov 30 23:10:11 2002 @@ -1,7 +1,6 @@ noinst_LIBRARIES = libYASim.a -libYASim_a_SOURCES = \ -YASim.cxx YASim.hxx \ +SHARED_SOURCES = \ Airplane.cpp Airplane.hpp \ Atmosphere.cpp Atmosphere.hpp \ BodyEnvironment.hpp \ @@ -23,6 +22,8 @@ Vector.hpp \ Wing.cpp Wing.hpp +libYASim_a_SOURCES = YASim.cxx YASim.hxx $(SHARED_SOURCES) + bin_PROGRAMS = yasim # Link the yasim executable against the individual object files rather @@ -33,27 +34,7 @@ # I think that it's permissible to list the same source files more # than once in a Makefile.am. Hopefully this doesn't break anything. -yasim_SOURCES = yasim-test.cpp \ -Airplane.cpp Airplane.hpp \ -Atmosphere.cpp Atmosphere.hpp \ -BodyEnvironment.hpp \ -ControlMap.cpp ControlMap.hpp \ -FGFDM.cpp FGFDM.hpp \ -Gear.cpp Gear.hpp \ -Glue.cpp Glue.hpp \ -Integrator.cpp Integrator.hpp \ -Jet.cpp Jet.hpp \ -Math.cpp Math.hpp \ -Model.cpp Model.hpp \ -PistonEngine.cpp PistonEngine.hpp \ -PropEngine.cpp PropEngine.hpp \ -Propeller.cpp Propeller.hpp \ -RigidBody.cpp RigidBody.hpp \ -SimpleJet.cpp SimpleJet.hpp \ -Surface.cpp Surface.hpp \ -Thruster.cpp Thruster.hpp \ -Vector.hpp \ -Wing.cpp Wing.hpp +yasim_SOURCES = yasim-test.cpp $(SHARED_SOURCES) yasim_LDADD = -lsgxml -lsgmisc -lsgdebug
Re: [Flightgear-devel] YASim: yasim
Erik Hofman wrote: > I propose a small change in the Makefile which might make life a > little easier in the future, by defining SHARED_SOURCES wich hold > (indeed) all the files that are shared between the library and the > stand alone interpreter. Indeed. I actually tried that first, but gave up when it died in automake. Apparently I was trying to use shell syntax for the variable instead of make syntax. Or should it be m4? Silly me. :) 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
[Flightgear-devel] Today's new segfault
Hello, With the compile problems resolved, still getting a consistent segfault just after "Done reading panel instruments". The other repeatable clue is that the fgfs window never appears. Running Linux 2.4.19, GeForce2 MX, 384MB mem, X11R6 4.10 (I think). Had been working with the CVS of yesterday 9AM. An old executable from about 3 weeks ago brings up the window and splash pictures, but fails much later due to base changes. Get a large (155MB) core dump that gdb can't understand. All other X usage here is normal. Can anyone think of what could have broken the window creation? -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] BAC TSR2
Hi Lee, That is really a very nice 3D model. It'd be better with a somewhat lower poly count. The elevator response seems a little sluggish for the type of aircraft (and the degree of animation in the tail). Also, and maybe this is a question for Andy as well, the model is pitched down a couple degrees at startup. The 3D model however, is correctly oriented longitudinally with the airframe. On the ground the aircraft should sit with what looks to be about a 3 degree pitch up. The nose gear is "taller". I take it the settings that control gear compression should make this happen so that the aircraft is oriented correctly on the ground. Best, Jim "Curtis L. Olson" <[EMAIL PROTECTED]> said: > I have committed the TSR2 to CVS. Here's a web page with a bit more > info: > > http://www.aemann.pwp.blueyonder.co.uk/aircraft/british/tsr2.html > > It's a neat plane. Looks like it needs a bit of tweaks for the > animation (gear/gear doors goe backwards) and it is crying out for a > texture artist to make it spiffy, but even so, it's a neat addition. > > fgfs --aircraft=tsr2-yasim > > 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 > > > Lee Elliott writes: > > I've taken the liberty of attaching a .tar.gz file containing a .3ds model of > > a BAC-TSR2, a yasim config file based on the correct figures (where I could > > find them) and the -set.xml and model.xml files to fly it. > > > > I'm primarily a 3d'er and originally did the TSR2 for a picture I'm working > > on but when I got fgfs running (Debian Linux) I couldn't resist loading it in > > and trying to get it to fly. The model was created in Realsoft3D and > > exported as .3ds. > > > > I've been able to tag the various sub-objects, to animate them but the export > > process appears to 'flatten' any object hierarchy I set up and I'm guessing > > this is necessary for sequential animations - I couldn't set up the correct > > sequential rotations to properly bring the main u/c in. Also, in real life, > > there are several other u/c doors that should open and close in sequence to > > get the gear in and apparently the sequence was quite complex. > > > > On the ground though, it is as shown (so I didn't need to model the extra > > doors for my picture anyway;) > > > > It could do with some airbrakes too, both for the model and for the fdm. As > > with the extra u/c doors, I didn't need them for the picture and they haven't > > been modelled. > > > > As well as not being able to preserve object hierarchies when I export from > > Realsoft3D's native object format to .3ds, I'm not able to preserve textures > > or colour-mapping either, so the aircraft appears all white. > > > > Hopefully, someone might like to add the extra doors and airbrakes, which > > shouldn't be too difficult, and put some texturing on it - mostly white > > anyway, for the prototypes, or a contemporary RAF scheme if someone wants to > > pretend that it entered service. > > > > The yasim fdm model, as said, cannot be regarded as accurate. However, while > > it is based on the specs for the real aircraft, where I could find them, the > > measurments are probably only accurate to about 1 metre. That's assuming I > > was measuring the right things in the first place;) Other bits that I wasn't > > sure about i.e. flaps, ailerons etc. have been hacked out of the a4 or the > > 747. > > > > It could do with some 'refinment' by people who know what they're doing, but > > it seems to fly about right, or rather, as I'd imagine:) (me want a > > forward-looking ski-toe terrain avoidance radar:) > > > > Anyway, I'm happy for the whole lot to be released under the same licence and > > conditions as the rest of the fgfs stuff, either as a part of fgfs or by > > anyone else who will also follow those same licence and condition terms. > > > > I've also got a reasonable yasim b52 flying but no moveable bits on the model > > yet, a vulcan with a similar simple 3d model using a grossly hacked c310 > > jbsim fdm (right numbers where I could find them but powered by a couple of > > XLRs) and a Saunders-Roe SR45 Princess flying boat model and yasim fdm (can't > > get it into the air with propellors but substituting equivilent jets (2.5x > > factor) got it flying. I've started on a EE/BAC Lighting FMk6 model but I'll > > probably be doing a Fairchild A-10 and an Antonov An-225 first. > > > > I figure this is the best way I can contribute to the fgfs project, and l'd > > like to be able to offer something. > > > > LeeE > > > ___ > 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
Re: [Flightgear-devel] Today's new segfault
William Earnest wrote: > With the compile problems resolved, still getting a consistent > segfault just after "Done reading panel instruments". The other > repeatable clue is that the fgfs window never appears. I'm not aware of any current crashing bugs. Can you run it in gdb and get a stack trace? If you're not used to the debugger, just get into the FlightGear source directory and do "gdb src/Main/fgfs". Then type "run" at the gdb prompt and let the program do its thing. When it dies, "backtrace" can be used to get a stack trace. Post the results. :) 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] Newbie - MSVC Linking problem
Thanks Fred..I'm able to compile..but the file size is alot smaller (around a meg) than the binary distribution. The program starts, but then dies soon after. I'll keep messing with it. Again thanks for the help, Michael
Re: [Flightgear-devel] Today's new segfault
Andy Ross wrote: William Earnest wrote: > With the compile problems resolved, still getting a consistent > segfault just after "Done reading panel instruments". The other > repeatable clue is that the fgfs window never appears. I'm not aware of any current crashing bugs. Can you run it in gdb and get a stack trace? If you're not used to the debugger, just get into the FlightGear source directory and do "gdb src/Main/fgfs". Then type "run" at the gdb prompt and let the program do its thing. When it dies, "backtrace" can be used to get a stack trace. Post the results. :) Andy Andy, OK, here's the results. Failure was the same, came at the same point in startup. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 1732)] 0x4034a300 in __strtod_internal (nptr=0x9265808 "500", endptr=0x0, group=0) at strtod.c:440 440 strtod.c: No such file or directory. in strtod.c Current language: auto; currently c (gdb) bt #0 0x4034a300 in __strtod_internal (nptr=0x9265808 "500", endptr=0x0, group=0) at strtod.c:440 #1 0x0839a149 in SGPropertyNode::getDoubleValue (this=0x921e8d8) at /usr/include/stdlib.h:295 #2 0x08081051 in doComparison (left=0x8bec900, right=0x921e8d8) at fg_props.cxx:1017 #3 0x08081967 in FGComparisonCondition::test (this=0x8e092f0) at fg_props.cxx:1068 #4 0x08080d50 in FGAndCondition::test (this=0x8d4bad8) at /usr/include/g++-3/stl_vector.h:219 #5 0x082c9a2c in SelectAnimation::update (this=0x924b2a8) at model.cxx:440 #6 0x082c6467 in animation_callback (entity=0x8d2b338, mask=1) at /usr/include/plib/ssg.h:319 #7 0x083c8f6e in ssgEntity::preTravTests (this=0x8d2b338, test_needed=0xbf8004ec, which=1) at ssgEntity.cxx:194 #8 0x083cf3bc in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800508, test_needed=138186606) at ssgSelector.cxx:61 #9 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800568, test_needed=138186606) at ssg.h:1156 #10 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800568, test_needed=138186606) at ssgSelector.cxx:64 #11 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf8005c8, test_needed=138186606) at ssg.h:1156 #12 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf8005c8, test_needed=138186606) at ssgSelector.cxx:64 #13 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800628, test_needed=138186606) at ssg.h:1156 #14 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800628, test_needed=138186606) at ssgSelector.cxx:64 #15 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800688, test_needed=138186606) at ssg.h:1156 #16 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800688, test_needed=138186606) at ssgSelector.cxx:64 #17 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf8006e8, test_needed=138186606) at ssg.h:1156 #18 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf8006e8, test_needed=138186606) at ssgSelector.cxx:64 #19 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800748, test_needed=138186606) at ssg.h:1156 #20 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800748, test_needed=138186606) at ssgSelector.cxx:64 #21 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf8007a8, test_needed=138186606) at ssg.h:1156 #22 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf8007a8, test_needed=138186606) at ssgSelector.cxx:64 #23 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800808, test_needed=138186606) at ssg.h:1156 #24 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800808, test_needed=138186606) at ssgSelector.cxx:64 #25 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800868, test_needed=138186606) at ssg.h:1156 #26 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800868, test_needed=138186606) at ssgSelector.cxx:64 #27 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf8008c8, test_needed=138186606) at ssg.h:1156 #28 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf8008c8, test_needed=138186606) at ssgSelector.cxx:64 #29 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800928, test_needed=138186606) at ssg.h:1156 ---Type to continue, or q to quit--- #30 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800928, test_needed=138186606) at ssgSelector.cxx:64 #31 0x083c8fe7 in ssgEntity::cull_test (this=0x8d2b338, f=0x8bec900, m=0xbf800988, test_needed=138186606) at ssg.h:1156 #32 0x083cf3d7 in ssgSelector::cull (this=0x8d2b338, f=0x8bec900, m=0xbf800988, test_needed=138186606) at ssgSelector.cxx:64 #33 0x083c8fe7 in ssgEntity::cull_test (
[Flightgear-devel] RE : Binary Space Partitioning ?
Title: Message I take it you guys are running some sort of binary space partitioning, what is the type you use ? Danie Heath RisC Com cc +27 12 654 5100 083 412 6904 [EMAIL PROTECTED] www.risccom.co.za
