Re: [Flightgear-devel] Bug: missing the runway
I did a little research this afternoon dont know if it is of any use. Using the old airport file with Fredric's MSVC 9.2 version of 11 June I tried KSFO rwy 28L10R,KOAK rwy 27L2911 and YSSY(Sydney Australia) rwy 16R 34L in all cases the A/C lined up smack down the middle of the runway. I then used Fredric's MSVC 9.2 version of 30 August and the new airport file.This time KSFO still smack down the middle of the runway.At KOAK the A/C was about 15 ft left of centre on all runways.And at YSSY rwy16R it was back of the threshold by 200ft and to the left by 200ft. On rwy34L the A/C was about 300ft forward of the threshold and 200ft to the right. When this first happened I tried two other Australian airports with the A/C facing in all cases roughly south and all lined up about 200ft short and 200 ft to the left of centre.I did try an ILS approach to one airport and the A/C seemed to line up correctly with the runway. Dont know if this is of any help but there it is.Maybe others have some input. Cheers Innis Curtis L. Olson writes David Megginson writes: Curtis L. Olson writes: Can you list a specific example? CYRP. Sorry, I probably wasn't clear in my question. What about CYRP is not correct? The plane starts far before the threshold and to the right of the centreline. Ok, when I get that area regenerated with the tools/data in their most recent state I will take a closer look. I saw one hint of a problem elsewhere that could be a similar issue. It's probably a mistake on my part I'm guessing. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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 _ E-mail just got a whole lot better. New ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Indeed, I esp like the super impostor i.e the 'distant' clouds are clumped together into a mosaic of clouds as an impostor where each cloud used to make the mosaic is an impostor itself :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: missing the runway
On Wed, 3 Sep 2003, David Megginson wrote: Curtis L. Olson writes: Can you list a specific example? CYRP. Sorry, I probably wasn't clear in my question. What about CYRP is not correct? The plane starts far before the threshold and to the right of the centreline. I also see this on the default runway (ie. no commandline params at all). The plane is to the right, just off the runway and pointed about 45 degrees to the left. I assumed this was somehow deliberate... CVS checkout of everything as of about last Sunday. Love the buildings and the bridge btw, but I can't pull the b52 off the ground... Lawrence ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Framerate drop
Norman Vine writes: Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Indeed, I esp like the super impostor i.e the 'distant' clouds are clumped together into a mosaic of clouds as an impostor where each cloud used to make the mosaic is an impostor itself :-) I wonder how well that would map into a hierarchical scene graph structure where a particular node could be rendered as an imposter of all it's children. (Not my original idea) :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Framerate drop
Curtis L. Olson writes: Norman Vine writes: Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Indeed, I esp like the super impostor i.e the 'distant' clouds are clumped together into a mosaic of clouds as an impostor where each cloud used to make the mosaic is an impostor itself :-) I wonder how well that would map into a hierarchical scene graph structure where a particular node could be rendered as an imposter of all it's children. (Not my original idea) :-) If you have an Impostor Node type, It should 'just' work, even to the point of updating itself if an when needed due to lighting and or positional change :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3D Clouds (was RE: Framerate drop)
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: This came from Siggraph 2003 as did this cloud paper from MS http://ofb.net/~eggplant/clouds/CloudsInGames_NinianeWang.pdf Hmmm...some interesting hints in there. Indeed, I esp like the super impostor i.e the 'distant' clouds are clumped together into a mosaic of clouds as an impostor where each cloud used to make the mosaic is an impostor itself :-) Of course there's no sample code :-) :-) I wonder at what distance they start doing that... Probably no need to draw anything a greater distance then 3 or four cloud cell size and if there is a significant benefit over say using a more numerous set of textures to enhance what we already have for distant overcast Yes there is a BIG win with this technique as there is no need to draw the cloud textures each frame except for the very closest clouds as they are 'burned into' a 'new' background sky texture which could be a direct replacement for what we are doing now. i.e the clouds would in essence be drawn for free in that they are only periodically updated and the background fill time is the ~same whether using color or texture :-)) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
David Megginson [EMAIL PROTECTED] wrote: Further to Curt's last post about flattening rivers, how would everyone feel about flattening airports? When you look at large airports, say with runways over 3 km, you'll find quite a few where the runways follow the terrain at least over a difference in the elevation of several meters. Still that's not hundreds of feet :-) 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: [Terragear-devel] Flattening Stuff
Martin Spott writes: David Megginson [EMAIL PROTECTED] wrote: Further to Curt's last post about flattening rivers, how would everyone feel about flattening airports? When you look at large airports, say with runways over 3 km, you'll find quite a few where the runways follow the terrain at least over a difference in the elevation of several meters. Still that's not hundreds of feet :-) For what it's worth, when I was looking into this, I found some examples of runways with their ends literally at least 100' different in elevation. Most aren't nearly that far off, but there are a few. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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: [Terragear-devel] Flattening Stuff
Don't recall the specific change in height of the two runway ends, but KMRY has quite a downslope change toward the West as one real world example. jj For what it's worth, when I was looking into this, I found some examples of runways with their ends literally at least 100' different in elevation. Most aren't nearly that far off, but there are a few. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
Some good examples of un-flat runways: KATL ( especially 8R, concave ) San Jose, Costa Rica ( steep slope, strong visual illusion ) Guatemala City, Guatemala ( very concave runway ) On a related note, here are some airports that the FAA considers special, as of 1990, and why: APPENDIX 1. SPECIAL AIRPORTS ALASKAN REGION AIRPORT COMMENTS Dutch Harbor, AKMountainous terrain. Juneau, AK Mountainous terrain. Ketchikan, AK Mountainous terrain on both sides of final approach. Kodiak, AK Airport is surrounded by mountainous terrain. Any go-around beyond ILS or GCA MAP will not provide obstruction clearance. Petersburg, AK Mountainous terrain in immediate vicinity of airport, all quandrants. Sandpoint, AK Mountainous terrain. Seward, AK Mountainous terrain in the immediate vicinity of airport. Sitka, AK Obstruction in missed approach, all quadrants. Valdez, AK Mountainous terrain in immediate vicinity of airport. Wrangell, AKMountainous terrain in immediate vicinity of airport all quadrants. U.S. MILITARY AIRPORTS AIRPORT COMMENTS Adak, AKSpecial conditions due to precipitous terrain. Cape Lisburne AFS, AK Mountainous terrain in approach zones; nonstandard instrument approach. Cape Newenham AFS, AK Runway located on mountain slope with high gradient factor; nonstandard instrument approach. Cape Romanzof, AK Runway located on side of mountain; mountainous terrain both sides and north end of runway. Indian Mountain AFS, AK Mountainous terrain. Sparrevohn AFS, AK Mountainous terrain. Tatlina AFS, AK Unique approach; mountainous terrain. + Tin City AFS, AKMountainous terrain. EASTERN REGION AIRPORT COMMENTS Beckley, WV Mountainous terrain. Bluefield, WV Mountainous terrain. Charleston (Kanawha), WVMountainous terrain. + Cumberland, MD Mountainous terrain. Elmira (Chemung), NYMountainous terrain. + Elkins, WV Mountainous terrain. Harrisburg Int'l., PA Mountainous terrain. Hot Springs, VA Mountainous terrain. Roanoke, VA Mountainous terrain. Huntington, WV Mountainous terrain. Washington, DC (National) Special arrival/departure procedures. Wilkes-Barre, PAMountainous terrain. Binghamton, NY Mountainous terrain. + Saranac Lake, NYMountainous terrain. Shenandoah Valley, VA Mountainous terrain. (Stanton-Waynesboro-Harrisonburg) EUROPEAN REGION AIRPORT COMMENTS Berlin, Germany Political sensitivity of corridor adherence. Stuttgart, Germany Complex ATC procedures; limited approach
[Flightgear-devel] new scenery samples
I have been fiddling around with the scenery building tools to incorporate 30m SRTM data for N/S america, updated/current airport/runway data based on the latest DAFIF cycle, updated taxiways, lighting, and approach data, etc. Also included is vmap0 roads, railroads, rivers, lakes, landc over/land use data. This is a big improvement for VFR flying and makes the world a lot more interesting to explore. This scenery data isn't final, but it represents what I've done so far. There are a few more things I'd like to tweak before I kick off a full world rebuild. Anyway, what I have can be found here: ftp://ftp.flightgear.org/pub/fgfs/Scenery-0.9.2/ This scenery should work just fine with the latest official release (0.9.2) but for those of you running the latest cvs, you will have slightly better looking taxiway centerline lights, otherwise there shouldn't be any difference. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Bug: missing the runway
David Megginson writes: Curtis L. Olson writes: Can you list a specific example? CYRP. Sorry, I probably wasn't clear in my question. What about CYRP is not correct? The plane starts far before the threshold and to the right of the centreline. David, I lined up fine in the yf23-yasim with the scenery I generated last night. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Fatal: cannot compile
Hello, I have following Software installed: - Debian Unstable (latest packages) - g++ -v does return: Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.2/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.2 20030831 (Debian prerelease) - ranlib -v does return: GNU ranlib 2.14.90.0.5 20030722 Debian GNU/Linux Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. - ld -v return: GNU ld version 2.14.90.0.5 20030722 Debian GNU/Linux I got latest SimGear, metagear and FlighGear. In all packages I do a ./configure [--with-jpeg-factory] make clean and a: make all install But on FlightGear I got this fatal messages: ../../src/Network/libNetwork.a(jpg-httpd.o)(.text+0x348): In function `HttpdImageChannel::foundTerminator()': /root/Test/Extract/FlightGear/src/Network/jpg-httpd.cxx:96: undefined reference to `trJpgFactory::render()' ../../src/Network/libNetwork.a(jpg-httpd.o)(.gnu.linkonce.t._ZN17HttpdImageChannelD1Ev+0x24): In function `HttpdImageChannel::~HttpdImageChannel [in-charge]()': /usr/local/include/plib/netChannel.h:101: undefined reference to `trJpgFactory::destroy(int)' ../../src/Network/libNetwork.a(jpg-httpd.o)(.gnu.linkonce.t._ZN17HttpdImageChannelD1Ev+0x94): In function `HttpdImageChannel::~HttpdImageChannel [in-charge]()': /usr/local/include/plib/netBuffer.h:119: undefined reference to `trJpgFactory::~trJpgFactory [in-charge]()' ../../src/Network/libNetwork.a(jpg-httpd.o)(.gnu.linkonce.t._ZN17HttpdImageChannelD0Ev+0x24): In function `HttpdImageChannel::~HttpdImageChannel [in-charge deleting]()': /usr/local/include/plib/netChannel.h:101: undefined reference to `trJpgFactory::destroy(int)' ../../src/Network/libNetwork.a(jpg-httpd.o)(.gnu.linkonce.t._ZN17HttpdImageChannelD0Ev+0x94): In function `HttpdImageChannel::~HttpdImageChannel [in-charge deleting]()': /usr/local/include/plib/netBuffer.h:119: undefined reference to `trJpgFactory::~trJpgFactory [in-charge]()' ../../src/Network/libNetwork.a(jpg-httpd.o)(.gnu.linkonce.t._ZN16HttpdImageServer12handleAcceptEv+0x103): In function `HttpdImageServer::handleAccept()': /root/Test/Extract/FlightGear/src/Network/jpg-httpd.hxx:67: undefined reference to `trJpgFactory::trJpgFactory[in-charge]()' ../../src/Network/libNetwork.a(jpg-httpd.o)(.gnu.linkonce.t._ZN16HttpdImageServer12handleAcceptEv+0x124): In function `HttpdImageServer::handleAccept()': /root/Test/Extract/FlightGear/src/Network/jpg-httpd.cxx:61: undefined reference to `trJpgFactory::init(int, int)'collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 But in fact I configure SimGear / FlightGear with JPEG factory support. Any ideas? Roland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Out of Office AutoReply: [Flightgear-devel] Fatal: cannot compile
Is this possible to stop? This could start a lavine (mass mailing)... :-( On Thursday 04 September 2003 09:37 pm, you wrote: Hi. I'm currently on leave and won't be available till the 15'th of September. Please refer any urgent matters to Mark Petrusma, or Rob Anderson. Regards, Themie Gouthas -- Roland Hder [-- MyAutoInstaller-Community --] http://www.autoinstaller.de ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Old problem returns?
A left click will automagically return you to the 'forward view' In Falcon, we always had face turned forward in inside view when coming back from the outside one. When switching from inside to outside one, the outside was left alone though. I think this is very reasonable because in 99% you use the outside view to take a look at something and an inside view for the real flying. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
Curtis L. Olson writes: For what it's worth, when I was looking into this, I found some examples of runways with their ends literally at least 100' different in elevation. Most aren't nearly that far off, but there are a few. For a 10,000 ft runway, that would require less than a 1% continuous grade, so it's not all that surprising. It will be a very good thing when we can take threshold elevations from FAA and DAFIF data. The SRTM/DEM data, however, is just too coarse -- that's why I'm suggesting flattening for now. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
Martin Spott writes: Further to Curt's last post about flattening rivers, how would everyone feel about flattening airports? When you look at large airports, say with runways over 3 km, you'll find quite a few where the runways follow the terrain at least over a difference in the elevation of several meters. Absolutely -- at my home airport, for example, runway 14/32 (10,000 ft) has a significant hump in the middle. We have one old 727 that flies up north to Baffin Island every day, loaded so that it can barely climb. You can tell it's starting its takeoff roll because you see a cloud of smoke over the horizon -- a few moments later, the plane itself comes into view, struggling its way off the runway with the nose hanging high in the air. With all the drag, we give that one at least three minutes (instead of the normal two) when it takes off across our runway. The problem is that we're not generally getting that right now anyway -- we're just getting incorrect elevations. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: missing the runway
Curtis L. Olson writes: David, I lined up fine in the yf23-yasim with the scenery I generated last night. I'll try rebuilding the airports with the latest CVS, then. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] new scenery samples
Curtis L. Olson writes: I have been fiddling around with the scenery building tools to incorporate 30m SRTM data for N/S america, updated/current airport/runway data based on the latest DAFIF cycle, updated taxiways, lighting, and approach data, etc. Also included is vmap0 roads, railroads, rivers, lakes, landc over/land use data. This is a big improvement for VFR flying and makes the world a lot more interesting to explore. Sounds great. Are you using all of the available SRTM-3 (including Canada)? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
David Megginson writes: Curtis L. Olson writes: For what it's worth, when I was looking into this, I found some examples of runways with their ends literally at least 100' different in elevation. Most aren't nearly that far off, but there are a few. For a 10,000 ft runway, that would require less than a 1% continuous grade, so it's not all that surprising. It will be a very good thing when we can take threshold elevations from FAA and DAFIF data. The SRTM/DEM data, however, is just too coarse -- that's why I'm suggesting flattening for now. Have you tried preinserting some of the the higher res srtm1 data to terra innide of and on the edges of the airport polygons ? This shoud be quite accurate. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
Norman Vine writes: Have you tried preinserting some of the the higher res srtm1 data to terra innide of and on the edges of the airport polygons ? This shoud be quite accurate. Maybe *too* accurate -- at the resolution, a 747 parked on the field will start to show up in the elevations, not to mention large hangars and the terminal buildings. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
David Megginson writes: Norman Vine writes: Have you tried preinserting some of the the higher res srtm1 data to terra innide of and on the edges of the airport polygons ? This shoud be quite accurate. Maybe *too* accurate -- at the resolution, a 747 parked on the field will start to show up in the elevations, not to mention large hangars and the terminal buildings. Whatever, the point is try preinserting some points for the airports I think you will be pleasantly surprised :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] new scenery samples
David Megginson writes: Curtis L. Olson writes: I have been fiddling around with the scenery building tools to incorporate 30m SRTM data for N/S america, updated/current airport/runway data based on the latest DAFIF cycle, updated taxiways, lighting, and approach data, etc. Also included is vmap0 roads, railroads, rivers, lakes, landc over/land use data. This is a big improvement for VFR flying and makes the world a lot more interesting to explore. Sounds great. Are you using all of the available SRTM-3 (including Canada)? Yes. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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: [Terragear-devel] Flattening Stuff
Curtis L. Olson writes: Norman Vine writes: David Megginson writes: Norman Vine writes: Have you tried preinserting some of the the higher res srtm1 data to terra innide of and on the edges of the airport polygons ? This shoud be quite accurate. Maybe *too* accurate -- at the resolution, a 747 parked on the field will start to show up in the elevations, not to mention large hangars and the terminal buildings. Whatever, the point is try preinserting some points for the airports I think you will be pleasantly surprised :-) I would worry that preinserting points would yield spikes whenever the FAA surveyed elevation differs from the SRTM data ... in otherwords imagine the SRTM surface with spikes whereever we place our pre-inserted points. Agreed this is why I suggested using the higher res SRTM data in the vicinity of the airports Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new scenery samples
On Thu, 4 Sep 2003 16:15:48 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Yes. Curt. Is it worth a new screen shot? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] *awk
Which is better: awk gawk nawk ?? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
Jon S Berndt writes: Which is better: awk gawk nawk Those are for the old geezers :-) and the occasional quick command line hack (like extracting a particular set of fields from each line of an input stream.) I'd recommend learning perl or python or both as replacements. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] *awk
Jon S Berndt writes: Which is better: awk gawk nawk perl All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
On Thu, 4 Sep 2003 18:31:11 -0400 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt writes: Which is better: awk gawk nawk perl David I'm going to take a wild guess here: I'll bet you and Curt didn't do to well in multiple choice tests in school? ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
On Thu, 2003-09-04 at 15:17, Curtis L. Olson wrote: Jon S Berndt writes: Which is better: awk gawk nawk Those are for the old geezers :-) and the occasional quick command line hack (like extracting a particular set of fields from each line of an input stream.) I'd recommend learning perl or python or both as replacements. :-) I concur. Use python if you want someone else to be able to read it. Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
Tony Peden writes: On Thu, 2003-09-04 at 15:17, Curtis L. Olson wrote: Jon S Berndt writes: Which is better: awk gawk nawk Those are for the old geezers :-) and the occasional quick command line hack (like extracting a particular set of fields from each line of an input stream.) I'd recommend learning perl or python or both as replacements. :-) I concur. Use python if you want someone else to be able to read it. And use perl if you want to be able to read it yourself. :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] *awk
Jon S Berndt [EMAIL PROTECTED] said: Which is better: awk gawk nawk ?? Well I'm going to throw in the old it depends on what you are doing. Since I've been around longer than perl, I still use awk for a lot of one line stuff. For example it often works better than xargs (piped out to sh). But it has been a while since I've written an awk script file for anything. So I agree with the others...perl or python. If you are interested in doing little utility scripts and once in a while a slick one liner at the shell prompt then learn perl. If you are going to be doing bigger scripts and potentially sophistcated applications (e.g. database, gui), then python would probably be better. IMO perl is easier to learn if you are a C programmer. IOO python is easier to learn period (I haven't tried yet). Oh and as far as your original question: nawk is something I'm not familiar with, but gawk is just the gnu version and in fact awk is just a simlink to gawk on linux boxes. I would guess that gawk covers all the nawk functionality and then some. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Height of buildings
Recently I experimented a little with AC3D, PPE and Blender and I was wondering how big one has to make a model to have it at the appropriate height when rendered by FG. If I want it to be 380 feet (the Rembrandttower in Amsterdam), how many grid-squares is 380 feet? Or can I rescale a model afterwards or specify the height of the model somewhere in the scenery file(s)? My favorite editor is AC3D, but examples for any editor will do. I'm planning to use the freeware textures of the Dutch Scenery for MSFS2K to create some buildings around Schiphol Airport and in the city of Amsterdam, but I'm stuck here. Before I start creating them, I would like to know how I can get them scaled right. Thanks in advance for the replies! --Ivo ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
David Megginson writes: Curtis L. Olson writes: For what it's worth, when I was looking into this, I found some examples of runways with their ends literally at least 100' different in elevation. Most aren't nearly that far off, but there are a few. For a 10,000 ft runway, that would require less than a 1% continuous grade, so it's not all that surprising. It will be a very good thing when we can take threshold elevations from FAA and DAFIF data. The SRTM/DEM data, however, is just too coarse -- that's why I'm suggesting flattening for now. David, one thing I could point out is that there is code in the apt_surface.cxx to limit the amount of total elevation change over the surface of the airport. If nothing else you play around with the clamping bounds and see if you can find a value that works better for you. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] *awk
On Thursday 04 September 2003 23:39, Jon S Berndt wrote: On Thu, 4 Sep 2003 18:31:11 -0400 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt writes: Which is better: awk gawk nawk perl David I'm going to take a wild guess here: I'll bet you and Curt didn't do to well in multiple choice tests in school? ;-) Jon LOL LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
Lee Elliott writes: On Thursday 04 September 2003 23:39, Jon S Berndt wrote: On Thu, 4 Sep 2003 18:31:11 -0400 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt writes: Which is better: awk gawk nawk perl David I'm going to take a wild guess here: I'll bet you and Curt didn't do to well in multiple choice tests in school? See, that would require answering the question you asked. It's much more fun to answer different questions that allow us to advance our own political adjenda. :-) BTW, I just flew KEMT to KTVL in the yf23 and there is some really nice terrain along that stretch. My scenery build should be done some time in the wee hours so I'll try to post new tiles first thing in the morning or there abouts. The roads/rivers are looking much nicer in the latest stuff. The roads do a much better job at following the lay of the land. I think I have added enough constraints so you don't see wierd 89 degree tilts to the road surface, but not so much that you get a road dug out with a sharp V through the middle of all the terrain. With rivers I might want to increase the smoothing just a bit. Right now they are doing a bit more climbing up and down the terrain than I'd like. The problem is the river data doesn't necessarily exactly match the SRTM data so if they are offset a bit, they aren't always running down the middle of the valleys ... so some compromises have to be made. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] glHorizon
Did I mention this link yet? http://www.web-discovery.net/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] glHorizon
On Thu, 2003-09-04 at 22:06, Jon Berndt wrote: Did I mention this link yet? http://www.web-discovery.net/ Very cool! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
On Thu, 2003-09-04 at 17:06, Curtis L. Olson wrote: Tony Peden writes: On Thu, 2003-09-04 at 15:17, Curtis L. Olson wrote: Jon S Berndt writes: Which is better: awk gawk nawk Those are for the old geezers :-) and the occasional quick command line hack (like extracting a particular set of fields from each line of an input stream.) I'd recommend learning perl or python or both as replacements. :-) I concur. Use python if you want someone else to be able to read it. And use perl if you want to be able to read it yourself. :-) I don't know, maybe it's just me but I've written a lot of perl I couldn't read a month later ... Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
