[Flightgear-devel] re:Mac OS X related install command concern during FG (+ dep) builds
The configure script log contains the following: checking for a BSD-compatible install... /usr/bin/install -c Perhaps it needs to first check for /usr/bin/install -C and use that instead if available? While using -c doesn't force a complete rebuild, it changes enough dependencies to rebuild a lot which it really shouldn't need to, especially FlightGear. Thanks! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/sound soundmgr_openal.cxx, 1.7, 1.8
Curtis L. Olson schrieb:
Log Message:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on freebsd ...
[...]
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
This test will break if r == 0
CU,
Christian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Carrier
Hi, Part of the carrier code is sent to Erik. The code seems to trigger a bug on irix. Therefore I have choosen to split the changes into smaller ones, which might be a good idea anyway. On *top* of the patch sent to Erik (I expect that to go in :), the following updated set of patches is available from ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier-20041121 Apply carrier-operations.diff to flightgears source directory. Put JSBSim-dropin.tar.bz2 into the JSBSim subdirectory. Apply data.diff to the data directory. Use the slightly updated FA-18.tar.bz2. For completeness, the patch sent to Erik is available with the groundcache.tar.gz on the same ftp server. User visible changes are: Mostly keybindings. Since H/h are already used for the hud. The h'O'ok is now controlled via O/o. To arrest the aircraft's launchbar at the cat user the L key (applying the brakes is no longer suffucuent). To arrest the aircraft the aircrafts velocity wrt the carrier needs to be zero. You will notice that the aircraft is fixed at the cat by a slight pitching of the aircraft. As usual apply flaps and thrust. Then pressing C will launch the aircraft. Non user visible changes: Much cleanup/code documentation. Put the groundcache into its own class. Little changes in the way the launchbar/holdback is modeled. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Traffic Manager update
Hi Everybody, The last couple of months have been extremely busy for me, so there wasn't much time left for FlightGear. But during the last week or so I managed to tweak my local copy of FlightGear so that the traffic manager controlled aircraft's behavior is extended in significant ways. To list some of the changes, A.I. traffic can now: - Be initialized while on the ground and remain parked until the scheduled time for take-off. - instead of disappearing at the end of a flight, load a new flight plan and wait in parking position until the next scheduled departure time. - communicate back to the traffic manager which aircraft have been deleted from the AIModels manager. The last part of the code would allow for flights that have gone out of user range to be deleted and recreated when necessary. I'm not using the latter part of the code though. I haven't submitted the new code yet, because I'd like to test it a little more. Hopefully I'll get it out sometime this week. Next, I'm thinking about creating some more traffic in and out of KSFO. Although there is no realistic aircraft parking yet, having some traffic moving at KSFO makes the area a lot more interesting. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
Lee Elliott wrote: I also believe the main gear was designed to tolerate less than perfect strips. Yes, the main gear looks to be very 'robust'. But I still wonder why they paid attention to these features. To my knowledge the TSR-2 was designed for long range and high cruise speed. This sort of aircraft typically doesn't need rough, short strips, they could safely operate from distant bases Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Curtis L. Olson wrote: I don't think my first attempt at an isnan() fix worked ... I ended up in an infinite loop. I've tried a less elegant/brute force approach and that seems to work. We actually got FG up and running on a FreeBSD machine tonight (woohoo!) Yeah ! Welcome to a wonderful world ! Did you use the current RELEASE, did you use OpenAL and PLIB from the ports or did you build them yourselves ? OpenAL compiles wihtout hassle, PLIB needed some fixes - I think some joystick stuff. I avoided the trouble and took the port ;-) but I'll try to build PLIB CVS this week in order to get the 'crease'-patch working, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/sound soundmgr_openal.cxx, 1.7, 1.8
Christian Mayer wrote:
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
This test will break if r == 0
Oops, duhhh! Thanks!
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS:
Martin Spott wrote: Curtis L. Olson wrote: I don't think my first attempt at an isnan() fix worked ... I ended up in an infinite loop. I've tried a less elegant/brute force approach and that seems to work. We actually got FG up and running on a FreeBSD machine tonight (woohoo!) Yeah ! Welcome to a wonderful world ! Did you use the current RELEASE, did you use OpenAL and PLIB from the ports or did you build them yourselves ? OpenAL compiles wihtout hassle, PLIB needed some fixes - I think some joystick stuff. I avoided the trouble and took the port ;-) but I'll try to build PLIB CVS this week in order to get the 'crease'-patch working, Jim Couch set up a freebsd machine and gave me an account on it. I don't know what release he installed, but it was running gcc-3.3.3 if that says anything to you. If you tell me the magic command, I can check the release. He already had plib built (I think from ports). He also had openal already built ... I'm not sure where that came from (probably ports?) I don't have direct access to the machine, but Jim reports that plib doesn't detect his USB joystick on FreeBSD. Any ideas? The kernel is detecting it and logging an entry with the joystick name, but nothing shows up inside plib. We aren't sure if it's a FreeBSD issue or Plib issue at this point. OpenAL does not work correclty with FG on FreeBSD ... Jim reports getting some sound ... it's almost like the sound is played at the correct frequency, but compressed so that it comes out 20x too fast. We also saw FG crash more times than it worked on FreeBSD ... that's a little disconcerting ... I haven't had a chance to look into that yet. But we at least got it all to compile and did get it up and running a couple times. Anyway, it's not perfect on FreeBSD, but it's a lot better than where we started yesterday. Regads, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Carrier
Hi, Apply carrier-operations.diff to flightgears source directory. Put JSBSim-dropin.tar.bz2 into the JSBSim subdirectory. Apply data.diff to the data directory. Use the slightly updated FA-18.tar.bz2. Note that if you drop this in atop the current JSBSim code I'm not quite sure what will happen. It appears as though these changes will overwrite and remove recent changes for: - tabular data output - cross-platform fixes - various minor formatting issues I'll comment more later (it's my anniversary today). Generally, looks like pretty minor impact to JSBSim. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Sunday 21 November 2004 21:58, Arnt Karlsen wrote: On Sun, 21 Nov 2004 21:32:12 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Lee Elliott wrote: I also believe the main gear was designed to tolerate less than perfect strips. Yes, the main gear looks to be very 'robust'. But I still wonder why they paid attention to these features. To my knowledge the TSR-2 was designed for long range and high cruise speed. This sort of aircraft typically doesn't need rough, short strips, they could safely operate from distant bases ..you forget this plane was made to fight WWIII. ;-). In a nut shell, you've got it. The requirements spec was very demanding and to a degree lead to it's failure. Even so, albeit after prolonged development, it seems as though it was coming pretty close to actually meeting those requirements when the project was cancelled. I've read that if just any one of those requirements had been relaxed just a little the a/c would have cost a lot less to produce and been a lot easier to actually manufacture. Many, if not most of the people involved in the project seem to believe that it was dropped more for political reasons (it had the potential to upset the balance of powers) rather than technical/manufacturing problems (there have been a surprisingly high number of books written about the TSR2) and considering the original specs requirements, it's likely that the TSR2 would still be in service today, had they ever got into production and service. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Traffic Manager update
On Sunday 21 November 2004 20:55, Durk Talsma wrote: Hi Everybody, The last couple of months have been extremely busy for me, so there wasn't much time left for FlightGear. But during the last week or so I managed to tweak my local copy of FlightGear so that the traffic manager controlled aircraft's behavior is extended in significant ways. To list some of the changes, A.I. traffic can now: - Be initialized while on the ground and remain parked until the scheduled time for take-off. - instead of disappearing at the end of a flight, load a new flight plan and wait in parking position until the next scheduled departure time. - communicate back to the traffic manager which aircraft have been deleted from the AIModels manager. The last part of the code would allow for flights that have gone out of user range to be deleted and recreated when necessary. I'm not using the latter part of the code though. I haven't submitted the new code yet, because I'd like to test it a little more. Hopefully I'll get it out sometime this week. Next, I'm thinking about creating some more traffic in and out of KSFO. Although there is no realistic aircraft parking yet, having some traffic moving at KSFO makes the area a lot more interesting. Cheers, Durk Looking forward to seeing this in action. Sounds like fun:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SimGear Compile error - related to openal
Hi, all, I encountered a compile error when make the simgear-0.3.7 for FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have plib and Zlib done. What I did: - download OpenAL from CVS. - put the openal in /usr/local/source - cd openal/linux $ ./autogen.sh $ ./configure $ make $ make install - cd /usr/local/source/SimGear-0.3.7/simgear $ make I got: g++ -g -O2 -D_REENTRANT -o openal_test1.exe openal_test1.o ../../simgear/deb ug/libsgdebug.a -lwinmm -ldsound -ldxguid -lole32 openal_test1.o(.text+0xc7d): In function `main': /usr/local/source/SimGear-0.3.7/simgear/sound/openal_test1.cxx:43: undefined ref erence to `_alutInit' openal_test1.o(.text+0xc82):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:44: undefined reference to `_alGetError' openal_test1.o(.text+0xc87):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:45: undefined reference to `_alGetError' openal_test1.o(.text+0xd81):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:74: undefined reference to `_alListenerfv' openal_test1.o(.text+0xd94):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:75: undefined reference to `_alListenerfv' openal_test1.o(.text+0xda7):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:76: undefined reference to `_alListenerfv' openal_test1.o(.text+0xde7):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:101: undefined reference to `_alGenBuffers' openal_test1.o(.text+0xdec):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:102: undefined reference to `_alGetError' openal_test1.o(.text+0xec6):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:114: undefined reference to `_alutLoadWAVFile' openal_test1.o(.text+0xecb):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:116: undefined reference to `_alGetError' openal_test1.o(.text+0xf8e):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:121: undefined reference to `_alBufferData' openal_test1.o(.text+0xf93):/usr/local/source/SimGear-0.3.7/simgear/soun d/openal _test1.cxx:122: undefined reference to `_alGetError' openal_test1.o(.text+0x1044):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:126: undefined reference to `_alutUnloadWAV' openal_test1.o(.text+0x105a):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:128: undefined reference to `_alGenSources' openal_test1.o(.text+0x105f):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:129: undefined reference to `_alGetError' openal_test1.o(.text+0x1092):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:133: undefined reference to `_alSourcei' openal_test1.o(.text+0x10b0):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:134: undefined reference to `_alSourcef' openal_test1.o(.text+0x10ce):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:135: undefined reference to `_alSourcef' openal_test1.o(.text+0x10eb):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:136: undefined reference to `_alSourcefv' openal_test1.o(.text+0x1108):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:137: undefined reference to `_alSourcefv' openal_test1.o(.text+0x1129):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:138: undefined reference to `_alSourcei' openal_test1.o(.text+0x1137):/usr/local/source/SimGear-0.3.7/simgear/sou nd/opena l_test1.cxx:140: undefined reference to `_alSourcePlay' collect2: ld returned 1 exit status make: *** [openal_test1.exe] Error 1 Can anyone help me? What should I do? Thanks. Regards, Heckel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: source/simgear/sound soundmgr_openal.cxx, 1.7, 1.8
On Sonntag 21 November 2004 22:46, Curtis L. Olson wrote:
Christian Mayer wrote:
+ #if defined (__FreeBSD__)
+ inline int isnan(double r) { return !(r 0 || r 0); }
+ #endif
This test will break if r == 0
According to IEEE, NaN is the only fp value that is not equal to itself. That
is, the code snippet:
inline int isnan(double r) { return r != r; }
should work on any IEEE machine.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
