[Flightgear-devel] Re: floorf in panel.cxx
* Martin Spott -- Sunday 22 February 2004 22:15: Absolutely the same revision and date here. I don't have any idea if 'truncf' and 'floorf' belong together but I can state that the latter is definitely present: Oh, I thought floorf was there forever and your problem could only be related to ftruncf. Should have read your subject more thoroughly. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: floorf in panel.cxx
Andy Ross wrote: Erik Hofman wrote: Does ffloor exists for Solaris? Why do we care? Just call floor(), which is in the ANSI C standard. The extra precision won't hurt anyone, and there is zero performance difference. Because I didn't know about floor() (the manpage of floorf didn't report it's existence). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
Curtis L. Olson wrote: If there aren't any major objections, I can commit these changes. The performance problems of doing a live www fetch only happen with the live weather updater is on, so there isn't any difference if you run in default mode. Sounds good, implement first, optimize later. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: floorf in panel.cxx
Jim Wilson wrote: Dang, those should have been floor not floorf. My bad. Can you fix that Erik? Done. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] namespaces
Jon Berndt wrote: Like I said, this all builds fine under gcc. Can anyone tell me what I need to do? Is this for JSBSim standalone, or for FlightGear/JSBSim? For the later, the entry for borland in SimGear/simgear/compiler.h might be outdated. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Live Weather!
* Erik Hofman -- Monday 23 February 2004 10:06: Sounds good, implement first, optimize later. Let's start *NOW*. :-) Index: simple.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Airports/simple.cxx,v retrieving revision 1.7 diff -u -p -r1.7 simple.cxx --- a/simple.cxx23 Feb 2004 01:37:26 - 1.7 +++ b/simple.cxx23 Feb 2004 09:29:38 - @@ -52,7 +52,9 @@ operator ( istream in, FGAirport a in.getline( name, 256 ); a.name = name; -a.has_metar = true; // assume true +// only airports with four-letter codes can have metar stations +a.has_metar = (isalpha(a.id[0]) isalpha(a.id[1]) isalpha(a.id[2]) + isalpha(a.id[3]) !a.id[4]); return in; } m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On Mon, 23 Feb 2004 01:04:05 +, Lee Elliott [EMAIL PROTECTED] wrote: I can see the gps entries in the tree but there're no values in them. Do I need a specific gps instrument to get some data? I think that currently the GPS does not get any power, I've modified the *electrical.xml file in order to give it some juice. Also I just mailed my diff files to Curt, so my changes probably hasn't been committed just yet. Some of the gps functions would be pretty useful when I'm working on an fdm. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Live Weather!
* Melchior FRANZ -- Monday 23 February 2004 10:31: +// only airports with four-letter codes can have metar stations but even of those not all have. I wonder if we shouldn't explicitly disable metar requests in the default scenery for all four-letter airports that don't have metar. That's where most people fly and we shouldn't flood noaa.gov with requests for KHAF etc. (and risk that they shut down their service). (OTOH, if we ask often enough, maybe KHAF will be donated its own Metar station, and will forever be grateful for our support. :-) Disadvantage: we'd have to track these airports and edit the blacklist accordingly. I'd volunteer. m. Index: simple.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Airports/simple.cxx,v retrieving revision 1.8 diff -u -p -r1.8 simple.cxx --- a/simple.cxx23 Feb 2004 09:48:10 - 1.8 +++ b/simple.cxx23 Feb 2004 10:42:14 - @@ -84,6 +84,8 @@ FGAirportList::FGAirportList( const stri airports_array.push_back( airports_by_id[a.id] ); size++; } + +no_metar(KHAF); } ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On Mon, 23 Feb 2004 02:10:47 -, Jim Wilson [EMAIL PROTECTED] wrote: I wonder if this could be incorporated (or interfaced) to the current waypoint management code. And, for the pilots on the list, do some GPS units also calculate elevations to plug in for VNAV operation, fuel estimation, etc? Yet another thought that seems to get mentioned here occasionally: a nearest airport function. Yes, the Garmin GPS III Pilot does have a nearest airport function. The algorithm for finding the nearest airport would be similar to the algorithm finding the nearest METAR station. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Live Weather!
* Melchior FRANZ -- Monday 23 February 2004 11:44: I wonder if we shouldn't explicitly disable metar requests in the default scenery for all four-letter airports that don't have metar. That's where most people fly and we That's all for the default scenery: m. Index: simple.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Airports/simple.cxx,v retrieving revision 1.8 diff -u -p -r1.8 simple.cxx --- a/simple.cxx23 Feb 2004 09:48:10 - 1.8 +++ b/simple.cxx23 Feb 2004 11:11:02 - @@ -84,6 +84,13 @@ FGAirportList::FGAirportList( const stri airports_array.push_back( airports_by_id[a.id] ); size++; } + +// airports in the default scenery that don't have metar stations +no_metar(KCSY); +no_metar(KHAF); +no_metar(KJMC); +no_metar(KNRC); +no_metar(KTCY); } ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] namespaces
Is this for JSBSim standalone, or for FlightGear/JSBSim? For the later, the entry for borland in SimGear/simgear/compiler.h might be outdated. I think that's probably true. My compiler.h is very sparse. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: [Flightgear-cvslogs] CVS: source/src/GUI AirportList.cxx, 1.5, 1.6]
Just in case anyone is scratching their heads over this nonsense commit, I
think I made a procedural mistake on my end ... missed one change in my
commit last night, then had to rechange the file to get it to work
correctly this morning.
Regards,
Curt.
--
Curtis Olson Intelligent Vehicles Lab FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
---BeginMessage---
Update of /var/cvs/FlightGear-0.9/source/src/GUI
In directory baron:/tmp/cvs-serv11598
Modified Files:
AirportList.cxx
Log Message:
Fix a type mismatch error introduced with the latest changes to
src/Airports/simple.[ch]xx
Index: AirportList.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/AirportList.cxx,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -r1.5 -r1.6
*** a/AirportList.cxx 28 Nov 2003 20:25:50 - 1.5
--- b/AirportList.cxx 23 Feb 2004 11:42:49 - 1.6
***
*** 17,21
_content = new char *[_nAirports+1];
for (int i = 0; i _nAirports; i++) {
! const FGAirport * airport = _airports-getAirport(i);
snprintf(buf, 1023, %s %s\0,
airport-id.c_str(),
--- 17,21
_content = new char *[_nAirports+1];
for (int i = 0; i _nAirports; i++) {
! const FGAirport *airport = _airports-getAirport(i);
snprintf(buf, 1023, %s %s\0,
airport-id.c_str(),
___
Flightgear-cvslogs mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-cvslogs
---End Message---
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Fwd: [Flightgear-cvslogs] CVS: source/src/GUI AirportList.cxx, 1.5, 1.6]
Curtis L. Olson wrote: Just in case anyone is scratching their heads over this nonsense commit, I think I made a procedural mistake on my end ... missed one change in my commit last night, then had to rechange the file to get it to work correctly this morning. :-) I had been searching for something non-obvious but in the end figured I had already committed the same patch with just one minor difference. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Linker command line for 'metar'
Hello, it might be useful to add '-lxnet' to the linker command line for 'metar' - at least on Solaris I get a lot of 'undefined symbols' it I omit that: g++ -mcpu=hypersparc -mtune=hypersparc -DPKGLIBDIR=\/usr/local/FlightGear/lib/FlightGear\ -O3 -D_REENTRANT -L/opt/gnu/lib -L/usr/local/lib -R/opt/gnu/lib:/usr/local/lib -s -L/usr/local/FlightGear/lib -o metar metar_main.o -lsgenvironment -lsgio -lsgbucket -lsgmisc -lsgstructure -lsgdebug -lplibnet -lplibul -lz -ldl -lm Undefined first referenced symbol in file __xnet_connect /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) __xnet_socket /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) setsockopt /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) __xnet_bind /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) gethostbyname /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) recvfrom/usr/local/FlightGear/lib/libplibnet.a(netSocket.o) accept /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) inet_addr /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) send/usr/local/FlightGear/lib/libplibnet.a(netSocket.o) __xnet_sendto /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) inet_ntoa /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) recv/usr/local/FlightGear/lib/libplibnet.a(netSocket.o) listen /usr/local/FlightGear/lib/libplibnet.a(netSocket.o) 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] GPS
Norman Vine wrote: This is because GPS positioning is *NOT* acurate with out a ground based signal to augment it ! It's much better than it used to be before they turned off selective availability. The big difference is that GPS accuracy remains roughly constant during any specific approach, while navaid accuracy increases as you approach the navaid and altimeter accuracy increases as you approach the station elevation. For example, a GPS without WAAS might have an error of 150 ft at any altitude; a pressure altimeter (with the proper altimeter setting) might have an error of over 1000 ft at 8000 ft AGL, diminishing to less than 25 ft at ground level. Ten miles back at 3000 ft AGL, even the non-WAAS GPS is probably going to be more accurate than the ILS and altimeter; a half mile back at 200 ft, the ILS and altimeter win hands-down. Obviously, the altimeter is the better choice for an ILS approach, but the GPS (even without WAAS) is a better choice for overflying a mountain range because of the altimeter's enormous errors at altitude. In practice, I have not noticed more than a 75 ft vertical vertical GPS error on the ground without WAAS (my current portable GPS does have WAAS support) -- that's not much worse than the 50 ft allowed altimeter error. Without WAAS and an approach-certified GPS, though, I wouldn't bet my life on it. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
Erik Hofman wrote: Sounds good, implement first, optimize later. The standard Unix developer's rules (from memory): 1. Make it work. 2. Make it right. 3. Make it efficient. I've worked as a consultant on too many projects where people have done these steps in reverse, never with a happy outcome. #3 usually produces code so obfuscated that #2 and #1 become difficult or impossible. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] GPS
David Megginson writes: Norman Vine wrote: This is because GPS positioning is *NOT* acurate with out a ground based signal to augment it ! It's much better than it used to be before they turned off selective availability. Yes this makes a difference but DGPS or WAAS is *MUCH* better :-) The big difference is that GPS accuracy remains roughly constant during any specific approach, while navaid accuracy increases as you approach the navaid and altimeter accuracy increases as you approach the station elevation. For example, a GPS without WAAS might have an error of 150 ft at any altitude; a pressure altimeter (with the proper altimeter setting) might have an error of over 1000 ft at 8000 ft AGL, diminishing to less than 25 ft at ground level. Ten miles back at 3000 ft AGL, even the non-WAAS GPS is probably going to be more accurate than the ILS and altimeter; a half mile back at 200 ft, the ILS and altimeter win hands-down. What I was pointing out is that elevation from GPS even DGPS is by it's physical nature mathematically not as accurate as the horizontal position. So if one is to use GPS elevations one should understand their inherent limitations AFAICT this is in essence what WAAS is all about in that it will provide the 'local' elevation correction as well as the DGPS horizontal correction in a verifiable way Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linker command line for 'metar'
Martin Spott wrote: Hello, it might be useful to add '-lxnet' to the linker command line for 'metar' - at least on Solaris I get a lot of 'undefined symbols' it I omit that: Done. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
David Megginson wrote: Erik Hofman wrote: Sounds good, implement first, optimize later. The standard Unix developer's rules (from memory): 1. Make it work. 2. Make it right. 3. Make it efficient. I've worked as a consultant on too many projects where people have done these steps in reverse, never with a happy outcome. #3 usually produces code so obfuscated that #2 and #1 become difficult or impossible. Yes, I can imagine making it efficient often produces hard to read code.. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linker command line for 'metar'
Martin Spott wrote: Hello, it might be useful to add '-lxnet' to the linker command line for 'metar' - at least on Solaris I get a lot of 'undefined symbols' it I omit that: the same with 'js_server', 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] Re: Live Weather!
Erik Hofman writes: David Megginson wrote: Erik Hofman wrote: Sounds good, implement first, optimize later. The standard Unix developer's rules (from memory): 1. Make it work. 2. Make it right. 3. Make it efficient. I've worked as a consultant on too many projects where people have done these steps in reverse, never with a happy outcome. #3 usually produces code so obfuscated that #2 and #1 become difficult or impossible. Yes, I can imagine making it efficient often produces hard to read code.. Or rethinking the problem so as to discover better algorithms leading to easier to understand code :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Live Weather! A suggestion
I'm very interested about the recent discussion regarding the new capabilities of FG with live weather data. Please don't stick only to getting the data from the Web. For me, it would be nice to let FG get the data also from files in the local hard disk as well (think of those of us that doesn't have a direct connect to the Internet. Yes, we are still a lot of them around!!. The NOAA allows for the downloading of a .zip file for a complete cycle (I guess a day) of conditions for any airport. I think that having the ability to choose between getting the weather data from Internet (in real time) or from files (stating the proper folder to search for files) would be a nice improvement (this capability will also make possible to fly with live data for past conditions: e.g. I can download data for last Friday for certain airport in order to fly with real Friday conditions Just my five cents... Pablo J. Rogina ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linker command line for 'metar'
Martin Spott wrote: Martin Spott wrote: Hello, it might be useful to add '-lxnet' to the linker command line for 'metar' - at least on Solaris I get a lot of 'undefined symbols' it I omit that: the same with 'js_server', Done, Any others? ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live Weather! A suggestion
Pablo J. Rogina wrote: I'm very interested about the recent discussion regarding the new capabilities of FG with live weather data. Please don't stick only to getting the data from the Web. For me, it would be nice to let FG get the data also from files in the local hard disk as well (think of those of us that doesn't have a direct connect to the Internet. Yes, we are still a lot of them around!!. The NOAA allows for the downloading of a .zip file for a complete cycle (I guess a day) of conditions for any airport. I think that having the ability to choose between getting the weather data from Internet (in real time) or from files (stating the proper folder to search for files) would be a nice improvement (this capability will also make possible to fly with live data for past conditions: e.g. I can download data for last Friday for certain airport in order to fly with real Friday conditions That's actually not a bad idea. I've been thinking of getting plausible data for airports and putting that in one big metar file to give a default weather which *could* be expected at a particular airport. Extending it even further would be to provide data for every week in a year. But that requires monitoring the weather and storing the metar strings weekly. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear 'benchmark'
Hello, I've assembled a 'small' (40 MByte) FlightGear package and included a README: This is a subset of the FlightGear Open Source flight simulator, packaged together with the purpose to serve as a specific benchmarking tool among different Unix platforms. The idea arose after realizing, that real world performance numbers for Unix workstations, especially for SGI and Sun machines, are rare because most potential users apparently don't like to share their experiences. The package would also serve as a FlightGear 'Getting Started' kit. I hope this package eases the collection of useful numbers. It is _always_ in development, so please include the package version into your feedback. The current 'release' (0.0.1) is based on CVS from 21th February 2004 and should run on IRIX/MIPS, Solaris/Sparc and Linux/x86. Please notice data/COPYING, run the 'benchmark' bin/FGBenchmark and return framerate numbers (lower right corner in the simulator window) to the person tho gave you notice of this package. To have a free flight you're invited to double click the right mouse button (you now should see crosshairs instead of your mouse pointer, this gets you mouse control over the aircraft), release the parking brake with Shift-b and control engine power wit PgUp/PgDown. ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/FGBenchmark-0.0.1.tar.bz2 I'll include the necessary shared libraries (libjpeg for IRIX and GCC runtime libraries for Solaris) in a new package unter the same version number this evening, 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] Linker command line for 'metar'
Erik Hofman wrote: Martin Spott wrote: the same with 'js_server', Done, Any others? No, 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] FlightGear 'benchmark'
Martin Spott wrote: I'll include the necessary shared libraries (libjpeg for IRIX and GCC runtime libraries for Solaris) in a new package unter the same version number this evening, IRIX users can also install ifl_eoe.sw.c++ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
Erik Hofman wrote: I've worked as a consultant on too many projects where people have done these steps in reverse, never with a happy outcome. #3 usually produces code so obfuscated that #2 and #1 become difficult or impossible. Yes, I can imagine making it efficient often produces hard to read code.. Which, ironically, makes it less efficient -- as the code becomes harder to understand, people are less likely (or less able) to work on it. That's why you should never optimize *anything* unless (a) the optimization is trivial and does not hurt code readability (i.e. it's just basic good software engineering), or (b) you've proven, through extensive profiling and real-world testing, that optimization of that specific code will bring a significant speed-up to the *entire* project. Sometimes the premature optimizations are just wrong -- lacking real testing and experience, people optimize for the wrong case and actually make the program slower. Other times, they make the code so hard to understand that they slow down development and kill the project. Still other times, the code that was originally optimized misses out on future optimizations (such as hardware acceleration) because it's too hard to fix, and ironically becomes the bottleneck after all. None of these outcomes is good. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airports metar.dat.gz, NONE, 1.1
Curtis L. Olson wrote: A simple list of id's of metar stations. We can use this list to mark which airports have corresponding metar data so we don't flood the noaa site with bogus queries. It might be a good idea actually to add lat/lon/elev of each station to the list, and to use it instead of the airport list. At least, I have a nagging feeling that there are METAR reporting stations somewhere in the world not colocated with an airport, though I don't have time to check right now. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airports metar.dat.gz, NONE, 1.1
David Megginson wrote: Curtis L. Olson wrote: A simple list of id's of metar stations. We can use this list to mark which airports have corresponding metar data so we don't flood the noaa site with bogus queries. It might be a good idea actually to add lat/lon/elev of each station to the list, and to use it instead of the airport list. At least, I have a nagging feeling that there are METAR reporting stations somewhere in the world not colocated with an airport, though I don't have time to check right now. That's definitely a good idea. There are definitely many weather stations not colocated with airports (or at least that don't have corresponding airports in our database.) Any one know where we can get current and definitive information? Thanks, Curt. -- Curtis Olson Intelligent Vehicles Lab 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: [Flightgear-cvslogs] CVS: data/Airportsmetar.dat.gz, NONE, 1.1
Curtis L. Olson writes: David Megginson wrote: Curtis L. Olson wrote: A simple list of id's of metar stations. We can use this list to mark which airports have corresponding metar data so we don't flood the noaa site with bogus queries. It might be a good idea actually to add lat/lon/elev of each station to the list, and to use it instead of the airport list. At least, I have a nagging feeling that there are METAR reporting stations somewhere in the world not colocated with an airport, though I don't have time to check right now. That's definitely a good idea. Might I suggest that you include X,Y,Z in the in memory representation There are definitely many weather stations not colocated with airports (or at least that don't have corresponding airports in our database.) Any one know where we can get current and definitive information? I think this is what you want http://weather.noaa.gov/data/nsd_bbsss.txt Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 'benchmark'
Martin Spott wrote: I'll include the necessary shared libraries (libjpeg for IRIX and GCC runtime libraries for Solaris) in a new package unter the same version number this evening, O.k., it's ready for wider use - the URL remains the same, 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airports metar.dat.gz, NONE, 1.1
* Curtis L. Olson -- Monday 23 February 2004 18:27: There are definitely many weather stations not colocated with airports (or at least that don't have corresponding airports in our database.) Ahh, yes. And my assumption that only four letter ids is apparently wrong. There are stations with digits in them, but apparently all 4 characters long. m. :-/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airports metar.dat.gz, NONE, 1.1
* Curtis L. Olson -- Monday 23 February 2004 18:27: Any one know where we can get current and definitive information? Here is a list of weather stations with ICAO ids. But it's not obvious if all of these do also provide metar reports: http://weather.noaa.gov/data/nsd_.gz m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 'benchmark'
On Monday 23 Feb 2004 3:34 pm, Martin Spott wrote: Hello, I've assembled a 'small' (40 MByte) FlightGear package and included a README: This is a subset of the FlightGear Open Source flight simulator, packaged together with the purpose to serve as a specific benchmarking tool among different Unix platforms. MIPS, Solaris/Sparc and Linux/x86. snip Please notice data/COPYING, run the 'benchmark' bin/FGBenchmark and return framerate numbers (lower right corner in the simulator window) to the person tho gave you notice of this package. further snippage Martin 33-34 frames per second on startup (falling as low as 20 on final approach to KSFO at the end of my free circuit :¬) System info, FWIW: ASUS A7N8X motherboard 512 MB RAM Athlon 2600 CPU clocked at 1913 MHz (*) Mandrake Linux 9.1 Kernel 2.4.21-0.13mdk XFree86 Version 4.3.0 NVidia drivers version 5336 KDE 3.1 (That's more or less vanilla Mandrake 9.1, really.) This is a great idea - with your permission, I'll volunteer to buy and burn a hundred or so business-card cd-rs e.g. http://www.cd-rmedia.co.uk/cgi-bin2/details.pl?id=saddle52 for passing out at the Linux User Expo? http://www.linux-expo.co.uk/ Obviously, I'll wait and see if there's a newer version before then. And if anyone knows a better source for the media, let me know. Regards Jonathan (*) Don't ask. I can't make the motherboard clock the Athlon any higher than this, but it's fast enough for me! Runs cool, too. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airportsmetar.dat.gz, NONE, 1.1
Melchior FRANZ writes: * Curtis L. Olson -- Monday 23 February 2004 18:27: Any one know where we can get current and definitive information? Here is a list of weather stations with ICAO ids. But it's not obvious if all of these do also provide metar reports: http://weather.noaa.gov/data/nsd_.gz AFAIK this is same as the link I posted earlier with a different sorting Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 'benchmark'
Jonathan Richards wrote: This is a great idea - with your permission, I'll volunteer to buy and burn a hundred or so business-card cd-rs e.g. Do everything with it as you like. The most actual version has 38791942 bytes. I'll change the version number next time. for passing out at the Linux User Expo? I've planned to go there myself but I don't have an idea where to stay over the night - no relatives. Obviously, I'll wait and see if there's a newer version before then. I'm currently doint my best to Plib into the right shape that it compiles on AIX 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
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airportsmetar.dat.gz, NONE, 1.1
* Norman Vine -- Monday 23 February 2004 20:55: Melchior FRANZ writes: http://weather.noaa.gov/data/nsd_.gz AFAIK this is same as the link I posted earlier with a different sorting Oh, yes. Missed that, sorry. Seems that 'mine' is sorted by ICAO codes, and 'yours' by ... umm ... by bbsss. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
PLIB on AIX; Was: [Flightgear-devel] FlightGear 'benchmark'
Martin Spott wrote:
I'm currently doint my best to Plib into the right shape that it
compiles on AIX
I created a patch that serves to compile current PLIB CVS on AIX. Most
of the needed changes are trivial, some defines for AIX (similar to
those Erik already made for IRIX and Solaris) some strange linefeed
and/or whitespace changes (that's why I compressed/uuencoded the patch
to make shure they don't get lost) and one annoying change in
ssgAux/ssgaBillboards.cxx:
'hz' is already in use on AIX - which does not surprise because it's an
SI unit This has to be redefined. I substituted 'hz' with
'heightz' - this appears to be the meaning of this variable. Would
anyone be so kind to look at the patch and give a suggestion how to
deal/proceed with these changes ?
Thanks,
Martin.
begin 644 plib.AIX-diff.gz
M'XL('-S.D``W!L:6(N04E8+61I9F8`M5?[^(V$/X9_HHMNY`;,`/3,!)
M;D);3HD=W.0M-/V)N,@7MJ;,:/8*=W_WM7DHW!A/2=`=92:MO5Y]V-^UV
MSK=*)QUEXF+WVO7HQ/JT5DA)U9FG:T)V[ON75?J0$?K!\T%10AJ:JFXH*
MFJ+TZI(DO6FB=AOX$V?0--!'9IZW]28N79;[EMAIL PROTECTED]'`XD)'[.ZE`'`,^-
MXLG((7V_#I:HROT`0;[EMAIL PROTECTED],Z?*VWZ^TU]B.GXY38BUV!`V4@:FJICJH
M8LW75,%I^G!Z4J_S]!Q6KPP'UB6OO0B#;$;L.7;@+GD'M@:J8BF:J1\RT
M7D5!7HN2;[EMAIL PROTECTED]'R0NRSCAVFGH6OX(QYXSS1\'$U3`933!LYD,
M'O5',N$_Y\(/=_7C,G\\W(KGMBH?:C1OK0QAL9/'\].'.WZ(-14GM.:
M)#R:!G,!?P?@0-;=G,!E?3CX^7EY=C^['4Y0/[EMAIL PROTECTED](#19P
MS[5!S?-^_'CS:;GUI_9H)$RT:MUNT21:+##J=3EW:L31BAJ2_;[EMAIL PROTECTED]
M/3I9M+Z=XY]__$\50.8V(MEA[=)M:XD-\=[`U(T=BF^OK3),,56C/!Q#
MTV4#)8$OP#LF1=$E%T\(K@$-(X7WT[''[EMAIL PROTECTED];I[=LX=1(!%;?#
MJWAD]K0=J,6JLB;NI')4AMH/?8?12P,15YQ:B/,2'BY!:,[EMAIL PROTECTED],[EMAIL PROTECTED]
M,3LD8-__=J*?]#RY\YVP)I0#P4N+`=8TT^CO05VNKJ(W36PDJT`4]U
M*`3VVE?\+D/$:3;WQ+P`X();D5#@L:SBGYYE_(:/[EMAIL PROTECTED],X
M'J;6TUZ:K#/A(\7YJ*%X9JDKIQ[EMAIL PROTECTED]),A'EO$`S8VK9IAE9S[1IDWT9
M1NPX#BQRSG!S*C*JQI(EE1MT7]HWE52:B;R5/AK.'R[2PS4=)RH1U
M[GK4V%)*K0`LG,RZ#DJAF[W7\+UN91.FQBJ-V=NHA)HJ'RUV:^X?_CW
M[H:8LM(QJ+2$1YV%;6+)9F9XUBB1?!;[EMAIL PROTECTED](EO*O#81?];6.6_V9
MEQ`*)PLK=CK.PQH6I4=G$:/$H6*_'D7$AHL2H6UA55ZB([EMAIL PROTECTED](?P8T@
M6)8O5VSO*897*L,ID%YXQ3FN2]4!ZLZ=N!AE=EIG`*\/%JI_VB?CYF
[EMAIL PROTECTED](IC,@0FH\!48^'*!1HY/`6E8]APN7(,1NOH48S_:-M_FX\X([
MFP,,U)I!OZ8C,[*')[EMAIL PROTECTED]/P44A2W['.;G+Z#$ZC*Y,A!\(5GN
MR)'.'.U*;U.:[EMAIL PROTECTED][EMAIL PROTECTED]/U`\TCFJV\T4)XD8Y*993,0?.T%
MI%.(TOGA2'?!?X!R='=2_M`.'.]0X7XX7.$[EMAIL PROTECTED]
MBVPPC79^'M0:;MOL[(.^3887!?#9X8PI`O_G$V7\F.OG.HAI!E29N?T
M7YNFKJ)[EMAIL PROTECTED]Y[S(%U3`)E2T[(?BK##'Z[A!*#F?]QK'-^B]#]F
M7Y?IT?G1Y[5TC5!4DZ!;/V'?^_A*2L:K,ODGLMW$ZV1QR*`U4!3
MUMU`F6W7JZK-I[570*KUJ*KJY\T6;EK3(NJ.%)I$O,6L6P21==8S)J
M75S1,*7+VM=E/BMRI[Y-Z#5RFMSXY'U0O%7/9Y([EMAIL PROTECTED]SA=3_8;AW'
M-W?8.V[NBLKSR655Q7OGBF[=O$K_H='1_N4AD\?'?.[)=C4Z([EMAIL PROTECTED]
-L=T?P!#.K.VM0X``'OG
`
end
--
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
[Flightgear-devel] Stepping and other inquisitions
Hello everyone, I'm working on a simulation project using a simulink model. Currently, I'm running an interface using the Aerosim blockset for matlab/simulink, but the program steps/chops, especially when the sun/moon position is updated (and when other info is output to the cmd window). I'm currently running both on a single computer, but this computer is a pretty high-end machine. So the question really is: can I stop those updates from occuring, or should I just try using a network with 2 computers? Another thing i've seen is the fact that after a minute of running my simulation, the simulation suddenly turns to night. Can anyone tell me why this is? and how can I stop it from occuring? One last thing: there is a command to do not advance time of day (--enable-clock-freeze) and if i've read the documentation correctly, this should keep the time of day constant while letting the simulation run, right? But when I go and set that - it pauses the simulation and i can not do anything. Do i have the wrong idea about this? Thanks Josh Joshua William Keane George Washington University Graduate Student Vehicle Dynamics Branch NASA Langley Research Center Hampton, VA 23681 Mail Stop 153 Phone: (757) 864-9636 Fax: (757) 864-7722 Email: [EMAIL PROTECTED] Office: Bldg 1192C, Room 159 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
On Monday 23 February 2004 14:16, Norman Vine wrote: David Megginson writes: Norman Vine wrote: This is because GPS positioning is *NOT* acurate with out a ground based signal to augment it ! It's much better than it used to be before they turned off selective availability. Yes this makes a difference but DGPS or WAAS is *MUCH* better :-) The big difference is that GPS accuracy remains roughly constant during any specific approach, while navaid accuracy increases as you approach the navaid and altimeter accuracy increases as you approach the station elevation. For example, a GPS without WAAS might have an error of 150 ft at any altitude; a pressure altimeter (with the proper altimeter setting) might have an error of over 1000 ft at 8000 ft AGL, diminishing to less than 25 ft at ground level. Ten miles back at 3000 ft AGL, even the non-WAAS GPS is probably going to be more accurate than the ILS and altimeter; a half mile back at 200 ft, the ILS and altimeter win hands-down. What I was pointing out is that elevation from GPS even DGPS is by it's physical nature mathematically not as accurate as the horizontal position. So if one is to use GPS elevations one should understand their inherent limitations AFAICT this is in essence what WAAS is all about in that it will provide the 'local' elevation correction as well as the DGPS horizontal correction in a verifiable way Cheers Norman One of the things about GPS units is that the accuracy depends on how many sats the unit's tracking, and their disposition around the sky. My hand-held unit needs to find a minimum of four sats to get an elevation but if they're all in the same region of the sky the accuracy is pretty poor. The unit can use up to twelve sats, which increases accuracy, but it can still be good with just four if say, one's at the zenith and the other three are distributed around the horizon. Dunno if we want to get into adding nav sats to the celestial stuff so we know if they're above the horizon or not:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS
Lee Elliott wrote: Dunno if we want to get into adding nav sats to the celestial stuff so we know if they're above the horizon or not:) If anyone wants to do that, the almanac data for the satellites is published and freely available (higher-end units and standalone software can predict satellite availability at a specific time and place). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] GPS
Lee Elliott writes: On Monday 23 February 2004 14:16, Norman Vine wrote: What I was pointing out is that elevation from GPS even DGPS is by it's physical nature mathematically not as accurate as the horizontal position. One of the things about GPS units is that the accuracy depends on how many sats the unit's tracking, and their disposition around the sky. Dunno if we want to get into adding nav sats to the celestial stuff so we know if they're above the horizon or not:) To be accurate there is more too it then 'above the horizon' :-) http://home.earthlink.net/~cwkelley/Software.htm Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Joshua W. Keane said: Hello everyone, I'm working on a simulation project using a simulink model. Currently, I'm running an interface using the Aerosim blockset for matlab/simulink, but the program steps/chops, especially when the sun/moon position is updated (and when other info is output to the cmd window). I'm currently running both on a single computer, but this computer is a pretty high-end machine. So the question really is: can I stop those updates from occuring, or should I just try using a network with 2 computers? Another thing i've seen is the fact that after a minute of running my simulation, the simulation suddenly turns to night. Can anyone tell me why this is? and how can I stop it from occuring? One last thing: there is a command to do not advance time of day (--enable-clock-freeze) and if i've read the documentation correctly, this should keep the time of day constant while letting the simulation run, right? But when I go and set that - it pauses the simulation and i can not do anything. Do i have the wrong idea about this? I would guess that the effect you are seeing is actually from loading scenery data. Have you built flightgear configured --with-threads? The turning to night sounds like an old bug that has been fixed in CVS. My guess is that the --enable-clock-freeze issue you describe is a bug. Same thing happens here. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
