[Flightgear-devel] ATC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wonder if we could use some of this stuff. http://www.openatc.org David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE85fsZx58m2d272NoRAspWAJ0fySpRWprmXDadVXK/hxaTzj285gCgnlcd YMC8wTCEB8EPbbyViy3BRqg= =DUvq -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: I simply don't know what I'm doing wrong
* Keith Wiley -- Saturday 18 May 2002 00:26: Should I just scrap my entire flightgear directory, throw it away, and start over from scratch? As a last resort, maybe. But you still didn't investigate the bug that you originally reported: remember do ble? /usr/local/src/FlightGear/src/Main/fg_init.cxx:628: undefined reference to `FGNullFDM::FGNullFDM(do ble)' Have you ever looked into fg_init.cxx, line 628? (Things have changed meanwhile, so if you are using CVS HEAD, this won't be in line 628 any more.) Is there really a do ble instead of double? It's not like I've even been doing lots of code modification that might mess up the cvs merge. Ahh, but you =have= modified the code? Nobody else seems to be able to reproduce your problems. Does cvs up report any modifications? (M in the first column.) I'm simply trying to download pure cvs code and it isn't working. This is absolutely ludicrous. I've been banging on this thing for weeks. Did you ever update all or only some files to a particular version or date, as in cvs up -D '2 weeks ago' or cvs up -r1.23 file.cxx? This leaves so-called sticky tags or dates in CVS/Entries. Updating will then always only update to the same sticky versions. In this case update all of your fgfs sources like this: $ cvs up -dPA Mind the A! It brings you back to CVS HEAD, the very last version. Would it be helpful to email the build output to you folks? I don't find it very suggestive myself. Yes. But it's always the same bug(s)? Otherwise checking your RAM is the way to go: memtest86 :-) Many of the errors are of the type no version of such and such a function found, as if the necessary object files never got created prior to the function calls getting linked. How could that occur?! That sounds very much like problems with sticky tags/dates! See above. Unless you have already done a cvs up -A you can try this in your source directory: $ cvs status|grep Sticky|grep -v (none) If it outputs =any= line, then cvs up -A will solve your problems. I realize this is probably not a problem anyone feels like thinking about too hard, but if anyone has ANY idea what I'm doing wrong, I would really appreciate a point in the right direction. We =do= think about it and we =do= care. But it's quite hard to find irreproducible bugs. (A telnet/ssh account on your machine would help. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cheaper 3D clouds?
Hi, Another approach to cliud modelling could be found here: http://nis-lab.is.s.u-tokyo.ac.jp/~nis/abs_cgi.html#pg01 Looking at the images it has about the same looks, but seems to be cheaper in CPU/GPU performance: http://nis-lab.is.s.u-tokyo.ac.jp/~nis/img/cmlcloud1s.jpg http://nis-lab.is.s.u-tokyo.ac.jp/~nis/img/cmlcloud2s.jpg http://nis-lab.is.s.u-tokyo.ac.jp/~nis/img/cmlcloud3s.jpg Documentation can be found here: http://nis-lab.is.s.u-tokyo.ac.jp/~nis/cdrom/pg/PG2001_ryomiya.pdf Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
As a last resort, maybe. But you still didn't investigate the bug that you originally reported: remember do ble? /usr/local/src/FlightGear/src/Main/fg_init.cxx:628: undefined reference to `FGNullFDM::FGNullFDM(do ble)' Have you ever looked into fg_init.cxx, line 628? (Things have changed meanwhile, so if you are using CVS HEAD, this won't be in line 628 any more.) Is there really a do ble instead of double? I think it was just a weird text-grab problem. That typo wasn't in the code. Like I said, the flavor of many of the errors is that a function call can't be linked to a function definition. Here's the most recent build output (from a more recent cvs update, which consequently has errors that are different from those I crashed into a week ago: environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_span_m(int) const': environment_mgr.cxx:206: no matching function for call to `SGCloudLayer::getSpan_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_span_m(int, double)': environment_mgr.cxx:212: no matching function for call to `SGCloudLayer::setSpan_m (double )' environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_elevation_ft(int) const': environment_mgr.cxx:218: no matching function for call to `SGCloudLayer::getElevation_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_elevation_ft(int, double)': environment_mgr.cxx:225: no matching function for call to `SGCloudLayer::setElevation_m (double)' environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_thickness_ft(int) const': environment_mgr.cxx:231: no matching function for call to `SGCloudLayer::getThickness_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_thickness_ft(int, double)': environment_mgr.cxx:238: no matching function for call to `SGCloudLayer::setThickness_m (double)' environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_transition_ft(int) const': environment_mgr.cxx:244: no matching function for call to `SGCloudLayer::getTransition_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_transition_ft(int, double)': environment_mgr.cxx:252: no matching function for call to `SGCloudLayer::setTransition_m (double)' environment_mgr.cxx: In method `const char * FGEnvironmentMgr::get_cloud_layer_type(int) const': environment_mgr.cxx:258: no matching function for call to `SGCloudLayer::getType ()' environment_mgr.cxx:259: `SG_CLOUD_OVERCAST' is not a member of type `SGCloudLayer' environment_mgr.cxx:261: `SG_CLOUD_MOSTLY_CLOUDY' is not a member of type `SGCloudLayer' environment_mgr.cxx:263: `SG_CLOUD_MOSTLY_SUNNY' is not a member of type `SGCloudLayer' environment_mgr.cxx:265: `SG_CLOUD_CIRRUS' is not a member of type `SGCloudLayer' environment_mgr.cxx:267: `SG_CLOUD_CLEAR' is not a member of type `SGCloudLayer' environment_mgr.cxx:260: warning: unreachable code at beginning of switch statement environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_type(int, const char *)': environment_mgr.cxx:277: `Type' is not a member of type `SGCloudLayer' environment_mgr.cxx:277: parse error before `;' environment_mgr.cxx:279: `type' undeclared (first use this function) environment_mgr.cxx:279: (Each undeclared identifier is reported only once environment_mgr.cxx:279: for each function it appears in.) environment_mgr.cxx:279: `SG_CLOUD_OVERCAST' is not a member of type `SGCloudLayer' environment_mgr.cxx:281: `SG_CLOUD_MOSTLY_CLOUDY' is not a member of type `SGCloudLayer' environment_mgr.cxx:283: `SG_CLOUD_MOSTLY_SUNNY' is not a member of type `SGCloudLayer' environment_mgr.cxx:285: `SG_CLOUD_CIRRUS' is not a member of type `SGCloudLayer' environment_mgr.cxx:287: `SG_CLOUD_CLEAR' is not a member of type `SGCloudLayer' environment_mgr.cxx:290: `SG_CLOUD_CLEAR' is not a member of type `SGCloudLayer' make[2]: *** [environment_mgr.o] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear/src/Environment' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear/src' make: *** [all-recursive] Error 1 Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy. -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
When you cvs update FlightGear, do you also cvs update SimGear ? Cheers, -Fred - Original Message - From: Keith Wiley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 18, 2002 7:28 PM Subject: Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong As a last resort, maybe. But you still didn't investigate the bug that you originally reported: remember do ble? /usr/local/src/FlightGear/src/Main/fg_init.cxx:628: undefined reference to `FGNullFDM::FGNullFDM(do ble)' Have you ever looked into fg_init.cxx, line 628? (Things have changed meanwhile, so if you are using CVS HEAD, this won't be in line 628 any more.) Is there really a do ble instead of double? I think it was just a weird text-grab problem. That typo wasn't in the code. Like I said, the flavor of many of the errors is that a function call can't be linked to a function definition. Here's the most recent build output (from a more recent cvs update, which consequently has errors that are different from those I crashed into a week ago: environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_span_m(int) const': environment_mgr.cxx:206: no matching function for call to `SGCloudLayer::getSpan_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_span_m(int, double)': environment_mgr.cxx:212: no matching function for call to `SGCloudLayer::setSpan_m (double )' environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_elevation_ft(int) const': environment_mgr.cxx:218: no matching function for call to `SGCloudLayer::getElevation_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_elevation_ft(int, double)': environment_mgr.cxx:225: no matching function for call to `SGCloudLayer::setElevation_m (double)' environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_thickness_ft(int) const': environment_mgr.cxx:231: no matching function for call to `SGCloudLayer::getThickness_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_thickness_ft(int, double)': environment_mgr.cxx:238: no matching function for call to `SGCloudLayer::setThickness_m (double)' environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_transition_ft(int) const': environment_mgr.cxx:244: no matching function for call to `SGCloudLayer::getTransition_m ()' environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_transition_ft(int, double)': environment_mgr.cxx:252: no matching function for call to `SGCloudLayer::setTransition_m (double)' environment_mgr.cxx: In method `const char * FGEnvironmentMgr::get_cloud_layer_type(int) const': environment_mgr.cxx:258: no matching function for call to `SGCloudLayer::getType ()' environment_mgr.cxx:259: `SG_CLOUD_OVERCAST' is not a member of type `SGCloudLayer' environment_mgr.cxx:261: `SG_CLOUD_MOSTLY_CLOUDY' is not a member of type `SGCloudLayer' environment_mgr.cxx:263: `SG_CLOUD_MOSTLY_SUNNY' is not a member of type `SGCloudLayer' environment_mgr.cxx:265: `SG_CLOUD_CIRRUS' is not a member of type `SGCloudLayer' environment_mgr.cxx:267: `SG_CLOUD_CLEAR' is not a member of type `SGCloudLayer' environment_mgr.cxx:260: warning: unreachable code at beginning of switch statement environment_mgr.cxx: In method `void FGEnvironmentMgr::set_cloud_layer_type(int, const char *)': environment_mgr.cxx:277: `Type' is not a member of type `SGCloudLayer' environment_mgr.cxx:277: parse error before `;' environment_mgr.cxx:279: `type' undeclared (first use this function) environment_mgr.cxx:279: (Each undeclared identifier is reported only once environment_mgr.cxx:279: for each function it appears in.) environment_mgr.cxx:279: `SG_CLOUD_OVERCAST' is not a member of type `SGCloudLayer' environment_mgr.cxx:281: `SG_CLOUD_MOSTLY_CLOUDY' is not a member of type `SGCloudLayer' environment_mgr.cxx:283: `SG_CLOUD_MOSTLY_SUNNY' is not a member of type `SGCloudLayer' environment_mgr.cxx:285: `SG_CLOUD_CIRRUS' is not a member of type `SGCloudLayer' environment_mgr.cxx:287: `SG_CLOUD_CLEAR' is not a member of type `SGCloudLayer' environment_mgr.cxx:290: `SG_CLOUD_CLEAR' is not a member of type `SGCloudLayer' make[2]: *** [environment_mgr.o] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear/src/Environment' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear/src' make: *** [all-recursive] Error 1 Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy. -- Edwin A. Abbott, Flatland
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
When you cvs update FlightGear, do you also cvs update SimGear ? Ugh! Usually I start with plib, move to SimGear, then move to FlightGear. But when FlightGear starts causing trouble for me, I suppose I just revert to trying to cvs update FlightGear. I guess that won't work though. That can't be the original source of my problems though, for the reasons stated. Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy. -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
Do you retry now with plib, SimGear and FlightGear in sync. What are your actual error messages ? -Fred - Original Message - From: Keith Wiley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 18, 2002 8:00 PM Subject: Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong When you cvs update FlightGear, do you also cvs update SimGear ? Ugh! Usually I start with plib, move to SimGear, then move to FlightGear. But when FlightGear starts causing trouble for me, I suppose I just revert to trying to cvs update FlightGear. I guess that won't work though. That can't be the original source of my problems though, for the reasons stated. Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy. -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
Do you retry now with plib, SimGear and FlightGear in sync. What are your actual error messages ? Further on that topic, I've got a script redoing that I need about once every couple of months. It does CVS with explicit -APd against the six trees, builds simgear from clean with reinstall, then builds FGFS, Atlas and TG from clean. It has solved many oddities. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
Another idea: you might have old versions of SimGear, plib or other libraries
installed somewhere. This should find exactly one copy of libsgsky:
$ find /usr -name 'libsg*' -exec grep -l getSpan_m {} \;
/usr/local/lib/libsgsky.a
If it finds none or more than one, there's a problem with the SimGear build/install.
- Julian
Keith Wiley wrote:
environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_span_m(int)
const':
environment_mgr.cxx:206: no matching function for call to `SGCloudLayer::getSpan_m
()'
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bad line endings when running on windows
The telnet interface produce wrong line ending when I run both FlightGear and the telnet client on Win2k. I've just sent a patch to Curt that produce line ending based on the platform where fgfs is running ( something between #ifdef and #endif ). For the moment, this patch only address the issue when fgfs and the telnet client run on the same platform. Thinking of it now, it would be better to generate proper line endings based on the capabilities of the client. Do the telnet interface support telnet commands DO, DONT, WILL and WONT ? or perhaps line ending can be deduced from the incoming command. Ideas ? Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: The telnet interface produce wrong line ending when I run both FlightGear and the telnet client on Win2k. I've just sent a patch to Curt that produce line ending based on the platform where fgfs is running ( something between #ifdef and #endif ). For the moment, this patch only address the issue when fgfs and the telnet client run on the same platform. Thinking of it now, it would be better to generate proper line endings based on the capabilities of the client. Do the telnet interface support telnet commands DO, DONT, WILL and WONT ? or perhaps line ending can be deduced from the incoming command. Ideas ? Idea: the receiver should accept any of these four line endings: CR LF CR,LF LF,CR In fact, I strongly believe that all text parsers, viewers, and readers of any kind should accept these. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
I (Julian Foad) wrote: Idea: the receiver should accept any of these four line endings: Sorry, I misunderstood. I was thinking of a peer-to-peer type connection. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: Perhaps I didn't made me clear. The problem is when FlightGear send text to the telnet client. Each line begins where the previous ends because Win2k telnet client needs a cariage return (\r) with the line feed (\n). OK. The Telnet protocol (RFC854) requires that line ends are sent as CR-LF, so I think FlightGear is faulty. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: The telnet interface produce wrong line ending when I run both FlightGear and the telnet client on Win2k. I've just sent a patch to Curt that produce line ending based on the platform where fgfs is running ( something between #ifdef and #endif ). For the moment, this patch only address the issue when fgfs and the telnet client run on the same platform. Thinking of it now, it would be better to generate proper line endings based on the capabilities of the client. Do the telnet interface support telnet commands DO, DONT, WILL and WONT ? or perhaps line ending can be deduced from the incoming command. Just a word of warning: there are currently two telnet servers in FlightGear. The original --props server and the new --telnet server. I haven't had time to combine them into a single server yet. Neither server implements telnet's option negotiation. The fact that you can connect to them with a telnet client doesn't make them telnet servers. You can connect to nntp, ftp, smtp and pop3 servers with a telnet client too. As for line endings I think its simpler if we just use CRLF for both client and server. I will check that the new server always sends CRLF. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
