Re: [Flightgear-devel] outerra news
On Sun, Jun 6, 2010 at 7:35 AM, Martin Spott martin.sp...@mgras.net wrote: Maybe we should consider moving to a different OpenSource scenery package. I'd be happy to read a more elaborate statement of what you're having in mind. What is the term scenery package supposed to mean ? An Open-Source package including scenery-generation tools and a scenery-rendering library. Our biggest challenge, I think, would be finding one that supported atmospheric rendering (weather, etc.) as well as terrain. All the best, David -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] outerra news
Maybe we should consider moving to a different OpenSource scenery package. Nothing met our needs in the late 1990s, but I'm sure they've progressed since then. David On Fri, Jun 4, 2010 at 8:59 PM, Peter Morgan p...@freeflightsim.org wrote: Is there a begginers guide ? I've been down this path before got stuck with terra and some sgrequirement.. never worked.. pete On Fri, Jun 4, 2010 at 10:20 PM, Martin Spott martin.sp...@mgras.net wrote: Gene Buckle wrote: That is just amazing. TerraGear should do that. :) Everyone's invited to contribute ;-) http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is something amiss with altimeter settings?
It's been a long time, but in addition to any issues with your altimeter setting I *think* I might have added code ~8 years ago to simulate the effect of temperature on altimeter readings. In real life, even if you have exactly the correct altimeter setting for the ground below you, and the altimeter is perfectly calibrated, your altitude can be off by hundreds or thousands of feet from what you see on the altimeter. Generally speaking, you'll be lower than you think if the temperature is below ISA, and higher than you think if the temperature is above ISA, because temperature affects how much the air pressure changes with altitude. The altimeter is calibrated to assume 15 degC at sea level and a perfect consistent temperature gradient above that. All the best, David In Canada, we're required to increase minimum altitudes for approaches, etc., when temperatures are cold. We also have designated mountainous regions where you have to fly higher in the winter. On Sat, May 29, 2010 at 1:02 PM, Rob Shearman, Jr. rmsj...@yahoo.com wrote: Hi there -- Recently while flying with the MD-81 at cruise levels of FL330 or so, I noticed there were some significant discrepancies between the displayed altitude and the altitude found in the property tree at /position/altitude-ft. I was able to observe the same problem in the 777-200ER -- I flew a flight at 33000 and the Flight Tracker reported my altitude at close to 35000. So the discrepancy at cruise is as much as 1000-2000 feet sometimes, even when using the altimeter setting reported in the METAR (which, of course, you're not supposed to do above 18,000 in the U.S., but for testing purposes I did so to see if it accounted for the error). However, today loading up my custom ATC scope I observed a discrepancy in altimeter readings which may account for the problem. http://i289.photobucket.com/albums/ll209/rmsjr1974/altimeter-discrep.jpg Notice in the shot that the METAR is reporting 29.94, but the property tree and the scope panel are arriving at 29.90. I presume at high altitude this discrepancy would account for differences in the gauge reading. This is with the 25 April CVS build, so if altimeter code has changed since the migration to git, I apologize in advance. Thanks, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear's Best Features
On Fri, Apr 23, 2010 at 3:11 AM, syd adams adams@gmail.com wrote: This is news to me. Which instrument models the drift ? I thought none did , so I created a nasal gyro that drifts at 3 degrees/15 minutes for my own use. Apparently I haven't looked close enough at the instrument code . After I got my PPL and bought my plane in 2002, I put a huge amount of work into making all of the instruments realistically inaccurate to reflect my actual flying experience -- they have lags, drift, etc. just like the real steam gauges. Other coders have contributed and improved since then. Try flying north of 45 deg latitude, for example, and watch how the magnetic compass behaves in turns, climbs, etc., and also watch how the VSI lags by as much as a couple of seconds in a climb or descent. David -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear's Best Features
We actually try to emulate the aircraft's systems (vacuum, pitot, static, electrical, etc.), so failure modes are much more realistic. Instruments update more realistically, with suitable lags and other errors. MSFS X has improved its flight models, but in general, I still find that both JSBSim and YASim models often feel more realistic (JSBSim is better in regular flight, but YASim sometimes does a better job around stall, spin, etc.). Easy to set up for the command line, so you can launch straight into a practice approach without clicking through a bunch of screens (and can randomize things like wind). All the best, David On Thu, Apr 22, 2010 at 3:30 PM, Durk Talsma d.tal...@xs4all.nl wrote: Hi All, Today at work I ran into somebody who writes a column on flight simulation for the Dutch aviation magazine Piloot Vliegtuig (Pilot and Aircraft), a magazine for real life pilots. Although he knew about FlightGear, he wasn't very aware of the details of the program. He seemed to be interested in the possibility of writing a column about FlightGear though, so I promised to send him a brief list of unique features of FlightGear that are predominantly of interest of real-life GA pilots, and which can't be found in Microsoft's FSX. In addition, I'll probably give him a tour of our lab's setup, once that one's fully up and running again. Although I have a fair idea what those unique features might be, this might be an excellent opportunity to incorporate some input from real-life pilots. Any suggestions are welcome though. Cheers, Durk -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear's Best Features
I think FSX uses a round earth model and non-flat runways as well. David On Apr 22, 2010 9:29 PM, Curtis Olson curtol...@gmail.com wrote: Here are a couple things off the top of my head ... - FlightGear is currently powering several FAA certified pilot training devices (www.atcflightsim.com) - Flightgear uses a wgs-84 round earth model so you can fly from your real aviation charts and hit all the intersections and radials and headings right where they should be. - FlightGear has all the stars in the correct place in the sky for the current time and location as well as the sun and the moon and the planets, and the moon with proper phase ... you probably didn't know that Durk. :-) - FlightGear's runways are not exactly flat ... just like in the real world they follow the lay of the land and there can be substantial differences in altitude from one end of the runway to the other. - FlightGear's autopilot code has been used to fly real UAV's autonomously in the real world ... - FlightGear has some of the most realistic and complete helicopter flight dynamics available in PC sims. - FlightGear has an awsome V22 Osprey model that is a total blast to fly once you get the hang of it. - FlightGear supports multiple monitors on a single PC. We've demonstrated a system with 8 displays all connected to a single (quad-core) PC. One box driving 8 displays (4 pci-express video cards) ... limited not by FlightGear, but how many displays you can plug into your machine. - FlightGear has been around for 14 years of active development! Regards, Curt. On Thu, Apr 22, 2010 at 7:39 PM, James Sleeman wrote: On 23/04/10 08:44, David Megginson wrote: Easy to set up for the command line, so you can l... -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Excellent new J3 Cub model
On Tue, Apr 13, 2010 at 2:45 AM, Erik Hofman e...@ehofman.com wrote: It is already removed from CVS. It's just a matter of running cvs up -Pd to also remove it from your local repository. I always do cvs -z3 update -d -P, but when I replied, I hadn't checked to see if it was still on my machine (it's not). Should we also set up j3cub as an alias, to provide a smooth transition for anyone who had the old Cub as his/her default aircraft, or is that just being overly solicitous? :) Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Normal map shader example - c172p
All the Cessna 172's I've seen have had protruding rivets, but the heads don't stick out much, and the paint smooths out the edges to the point that they're just gentle bumps -- a 172's wing doesn't look like a steam boiler. IIRC, the Mooney has countersunk rivets, which is why it can go so fast. All the best, David On Tue, Apr 13, 2010 at 5:18 PM, Bertrand Coconnier bcoco...@gmail.com wrote: 2010/4/13 Stuart Buchanan stuar...@gmail.com: Bertrand wrote: This is some nice artistic/graphical work indeed, however, I am afraid this is not very realistic. If you want Cessna aerodynamicists to die from an heart attack, just show them this picture ^_^ :) I was basing the work on some photos I found on the Cessna website. This one in particular seemed to show raised rivets on the wing: http://www.cessna.com/MungoBlobs/832/502/sin_haw_flt18_hires.jpg Perhaps what I'm seeing there isn't actually protruding rivets at all. Is there any height change there at all, or are the surfaces completely smooth? I could obviously tone down the effect significantly to make them protrude less if that is more realistic. BTW - we're modeling a P model, if that makes any difference. -Stuart Well spotted Stuart. They look very much like protruding rivets. May be what I reported above is limited to some specific class of aircrafts ? A Cessna C172 is a relatively cheap aircraft flying at low speeds, may be this is why Cessna are using protruding rivets (which are cheaper than countersunk rivets). May be it only makes a difference at higher speeds ? It seems I have extrapolated my experience to an area where it does not apply ^_^ As you may have guessed I am not an aerodynamicist myself, moreover my own experience is limited to airliners where, I think, the criteria are more stringent than for small aircrafts... Or may be in Cessna the design office have won the battle against aerodynamics ? ^_^ Anyway my contribution was not much worth it... Next time I will check closer ^_^ Cheers, Bertrand. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yoke mounted PDA
Cool, but wouldn't it make sense to support common portable aviation GPS's first? As far as smartphone-type-things go, it's hard to get any wireless coverage in the air (they started blocking upward transmission about 3-4 years ago), and the iPad is so big it would block most of the primary instruments anyway, but you'll find one of the units from this page attached to the yoke of most privately-owned planes: https://buy.garmin.com/shop/shop.do?cID=156 (I use an old GPSMap 196 myself, and it serves me very well). David On Mon, Apr 12, 2010 at 4:59 AM, Victhor victhor.fos...@gmail.com wrote: I made an iPad that looks pretty OK, but it used images from the Apple website as textures, so not completely GPL :) Has anyone made a 3D model of a PDA that attaches nicely to the existing yoke XML files? I'm thinking of portrait orientation with the form factor of an iPhone, android phone, etc, etc. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Excellent new J3 Cub model
On Mon, Apr 12, 2010 at 3:20 PM, Heiko Schulz aeitsch...@yahoo.de wrote: What I wonder- if David Megginson gave permission- why we have now the same aircraft with two different models in CVS? One named j3cub and one named Cub. No, pull the old one. It was a lot of fun to build, and was (I think) our second taildragger, when we were still figuring out how to model gear, but there's no reason to keep it around now. I'd love to make this new model our default aircraft, as the real J3 has been for so many tens of thousands of new student pilots historically, but the taildragger thing might scare away users. A couple of queries about the (most excellent) new model: 1. Shouldn't there be some kind of an inclinometer (slip-skid ball) on the panel? I think I've seen one in most J3 panel photos, and it's pretty useful. 2. Where's the black lightning bolt on the side? (That's just a joke -- I actually think it's cool that we're not following the cliché here). All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: landmass effects cause system crash in today's CVS FlightGear
On Wed, Apr 7, 2010 at 9:10 AM, Frederic Bouvier fredfgf...@free.fr wrote: Your card or driver advertise support of geometry shader but doesn't behave correctly with them. If the extension wasn't supported, the effect would have fallbacked to technique number 9 that doesn't use them. I think there is an OSG environment variable (OSG_GL_EXTENSION_DISABLE iirc) to disable buggy extension, and fgrun allows to set environment variable before starting fgfs. set OSG_GL_EXTENSION_DISABLE=GL_EXT_geometry_shader4 should work That did the trick -- thanks, Fred. We should probably add this to a FAQ somewhere, if it's not already there. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown smoothwater...@adelphia.net wrote: Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment (as verified in taxidraw). This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. I'm not familiar with mpmap, but that's not a problem for FlightGear itself - the localizer directions are all specified in Navaids/nav.dat.gz in degrees true, independently of any runways they might be associated with (not all localizers are attached to a runway, and even when they are, the direction might be 10 degrees off from the runway). Here's the example for BTV (where I've flown the localizer in real life as well as in FlightGear): 12 44.4652 -073.14009400342 11030 18 0.000 IVOE KBTV 33 DME-ILS But then, the vast majority of runways don't have localizers. Perhaps the map is just trying to show an extended runway centreline, and the person who designed the app mixed up magentic and true heading. The Airports/apt.dat.gz file does give runway headings in degrees true, not degrees magentic, so there's no need to mess around with magnetic deviation. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown smoothwater...@adelphia.net wrote: David, yes, as I have as well. The localizer for 33 as you listed above is on a 326 heading per the approach plate, but the mpmap shows ILS data as the runway heading in degrees - as if for users to use as the ILS data. I'm not sure what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) The plates give the heading in degrees magnetic; the data file gives it in degrees true. That's still a degree off (BTV is 15W, IIRC), but it's pretty close, and nav.data.gz may be based on old data. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown smoothwater...@adelphia.net wrote: I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Again, I haven't used mpmap, but are you certain it is trying to display an ILS localizer, and not just an extended runway centreline? You're right, of course, that it might have messed up true vs. magnetic (especially if the developer was working somewhere with very little magvar, and wouldn't have noticed during testing). Our files list actual runway headings in degrees true as well, so the only thing I can think is that the developer just took the runway *number* and converted it to a heading. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: landmass effects cause system crash in today's CVS FlightGear
On Tue, Apr 6, 2010 at 4:19 AM, Frederic Bouvier fredfgf...@free.fr wrote: I presume it's the geometry shader support that is causing this. Try to disable technique number 8 in landmass.eff regards, That was it -- no crash after commenting it out. Is it likely a problem with my graphics card driver, or the FlightGear code? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI-Balloons
On Wed, Apr 7, 2010 at 10:39 AM, Torsten Dreyer tors...@t3r.de wrote: I have just commited the add-on from the forum user gooneybird to the CVS- data. If you enable the balloon_demo scenario in your preferences.xml, you should see some balloons ahead of you aircraft after starting FlightGear. They get takeoff clearance before you will within the next minute and they will leave the ground soon. The will climb to approx. 2000ft above ground and drift away with the wind. Sounds great! And a quick reminder: balloons have right of way over powered aircraft and gliders, just like sail over steam on the water. :) David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Tue, Apr 6, 2010 at 7:06 PM, James Turner zakal...@mac.com wrote: My concern is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems. OK, here's my suggestion: *all* aircraft start with the runway threshold with the engine idling, unless the user has overridden that. Engine on/off is a decision that it doesn't make sense leaving to individual aircraft designers, since it's a cross-cutting user experience question. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Tue, Apr 6, 2010 at 7:34 PM, Peter Brown smoothwater...@adelphia.net wrote: In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. I realize I'm flogging a dead horse (and won't be offended if people tune out), but I just want to mention planes will very rarely be parked close to the runway, to avoid accidents if someone gets blown off the runway, ground-loops, etc. A plane parked near the runway with fuel in its tanks could make a deadly fireball out of what would otherwise be a bit of gear damage, a few broken runway lights, or (at worse) a bent wing. I have seen exceptions, mainly at private and uncertified airports (e.g. farm strips), but normally planes are parked with their noses against a taxiway, not the runway (or otherwise, a safe distance away on a field or apron). All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Kids Training Manual
On Mon, Apr 5, 2010 at 6:05 AM, Pete Morgan ac...@daffodil.uk.com wrote: I've packed it up in a slide show. Here's the results. http://flightgear.daffodil.uk.com/slide_shows/ Excellent! Thanks. David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Issue with default starting scenario
I temporarily moved my .fgfsrc file and .fgfs/ directory to see what a new user sees on first startup, and I think what's there is not the best idea (unless there's still some local configuration that I'm missing): 1. it's normal to have a plane sitting on the runway threshold with the engine idling 2. it's normal to have a plane sitting in a parking spot on the apron with the engine off 3. it's *not* normal to have a plane sitting on the runway threshold with the engine off Except in the case of an accident or mechanical failure, you would *never* be sitting on the threshold with your engine off, especially at a big airport like KSFO (unless you wanted to give your plane and yourself a 747-sized colon exam). I think that option #1 is ideal for new users, but option #2 would be OK if we want to distinguish ourselves from MSFS by making things more difficult. So, in brief, we have to make a choice: either move the default starting position off the runway, or (preferably) start on the runway threshold with the C-172 engine already idling. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug: landmass effects cause system crash in today's CVS FlightGear
When I enable landmass effects in a FlightGear binary built from today's CVS (and using today's base package), my entire computer freezes and I can reboot only by cutting power. Urban effects still work, however. With a binary built from the March 13 CVS, I can enable landmass effects -- still using today's base package -- with no bad effects. I'm using Ubuntu Lucid, with this card info from the X log: (--) PCI:*(0:1:5:0) 1002:9612:103c:3045 ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics] rev 0, Mem @ 0xc000/268435456, 0xd230/65536, 0xd220/1048576, I/O @ 0x5000/256 and (II) Module glx: vendor=FireGL - ATI Technologies Inc. compiled for 7.5.0, module version = 1.0.0 All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cherokee flap steps
I noticed this TODO issue on the Piper Warrior wiki page (http://wiki.flightgear.org/index.php/Piper_Cherokee_Warrior_II): flaps are moving in steps, they are not fluxional animated This is true, but might also be a bit confusing. Flap movements do appear almost instantaneous on a PA-28 compared to, say, a C172, because the flaps are mechanically connected to a long metal bar which the pilot yanks from one step to another. It's hard to estimate, but on my own Warrior, I'd say that the flaps spend something like 0.2 seconds in transit between steps, and it would be even less if I chose to move my arm faster. To the normal observer, they *will* almost appear to jump instantly from step to step. On a C172, on the other hand, the flaps are electric, and have slow, gradual movement from one stop to another. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Kids Training Manual
On Wed, Mar 31, 2010 at 1:23 AM, Pete Morgan ac...@daffodil.uk.com wrote: Fanstastic.. had a wuick look and its cool. Can I please lift the page and format it as a slideshow ? All yours -- consider it public domain. It might be worth capturing screenshots with newer 3D models and scenery, though. I wrote that tutorial just after finishing my initial flight training in 2002, and it's based on the standard pitch+power=performance model of teaching. It works nicely for FlightGear and for real-life flying lessons, but can run into trouble in less controlled environments: http://www.megginson.com/blogs/lahso/2005/04/04/power-pitch-stall/ All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Kids Training Manual
Here's one that I wrote back in 2002: http://www.flightgear.org/Docs/Tutorials/circuit/index.html All the best, David On Tue, Mar 30, 2010 at 8:02 PM, Pete Morgan ac...@daffodil.uk.com wrote: Problem I got with newbies.. Is there a simple set of instruction we can create (and laminate) of :: how to take off, make and ewe drop and come back and miss the first landing then go around another way and come back to land? no wind etc.. just for kids? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reflection Shader
Wow -- looks amazing! I wonder what that would do to my framerate with my laptop's poor little ATI HD 3200 card? All the best, David On Mon, Mar 29, 2010 at 5:50 AM, Vivian Meazza vivian.mea...@lineone.net wrote: Hi, Lauri Peltonen and I have been working on a reflection effect: ftp://ftp.abbeytheatre2.org.uk/fgfs/Shader/LightningF1-1.png ftp://ftp.abbeytheatre2.org.uk/fgfs/Shader/LightningF1.png This uses a generic fair-weather environment map, currently 6 images. We are working on using a cube-cross, which should be simpler for the user to apply. Other maps are possible in due course. The amount of reflection, fringing colour, and Fresnel effect are all adjustable, and you can tweek the ambient light to get the effect you want. We await the inclusion of the required patch in SimGear, meanwhile for anyone feeling brave: ftp://ftp.abbeytheatre2.org.uk/fgfs/Shader/Reflect/cube-map.patch We expected that it will be included soon. Vivian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] High priority: fixing the Great Lakes in FlightGear default scenery
When I originally added ground-use support to TerraGear many years ago, the Canada/US Great Lakes worked fine: we simply treated the water as a special ground use, used the DEM to get the elevation, clipped it against the VMAP0 coastlines, and for good measure, Curt had written code to average out the elevation of water areas to remove bumps, etc. The surface of Lake Superior or Lake Ontario might be a few feet high or low, but it was pretty hard to notice. Then, just before I left the project, something got badly broken in TerraGear and/or its input datasets: it changed so that any water connected to the ocean was forced down to sea level, although the real-life surfaces are as high as 600 ft MSL. Now, Chicago sits perched atop cliffs hundreds of feet high overlooking Lake Michigan, and rivers run through (non-existant) fjords. I think someone originally had a grandiose plan to build a water network, and wanted eventually to model locks, rapids, waterfalls, etc. to account for changes in water surface elevation, but that never happened, and to be honest, we should never have let the code into production until it worked. Now, quite a few years later, the Great Lakes are still broken in our default scenery, and as a result, FlightGear looks ridiculous to any new user who comes and tries flying in near cities such as Toronto, Rochester, Buffalo, Cleveland, Detroit, Chicago, or Milwaukee. Is there any reason that we can't restore the old code, and treat inland water like a (specially flattened) land use, at least until someone fixes the newer water-network code? Is there anything else we can do to address this problem? Were we forced into this because of different GIS datasets? Thanks, and all the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High priority: fixing the Great Lakes in
On Sun, Mar 28, 2010 at 1:58 PM, Martin Spott martin.sp...@mgras.net wrote: In the meantime we've made a polygon set to seamlessly fill The Great Lakes Void - which is likely going to address the issue you've mentioned. But there are still a few other places which are presumably affected by the same cause (Caspian Sea, I guess, and probably the Dead sea as well mmmh, maybe we've already fixed these as well). That's great news -- thanks, Martin! I'll look forward to the new scenery. Right now, I can't bring myself to practice approaches at waterfront airports, with the giant cliffs all around them. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High Priority: fixing the Great Lakes...
Quite a few years ago we had a debate, because we had to choose between two sets of shoreline data: 1. GSHSS was very nicely detailed (every little cove and point), but about 1 mile off for the Great Lakes, leaving shoreline airports either far inland or floating in the middle of a lake. 2. Vmap0 was much lower resolution (only big bays and points), but actually had the Great Lakes shorelines in roughly the right place. Since I was doing most of the TerraGear coding that year, I forced through vmap0, but a lot of people objected -- I thought it was OK for the Toronto harbourfront, but I don't remember for certain, and I don't know what FlightGear is using now. All the best, David On Sun, Mar 28, 2010 at 5:18 PM, David Slocombe sloco...@vex.net wrote: On Sunday 2010-03-28 David Megginson wrote: Now, quite a few years later, the Great Lakes are still broken in our default scenery, and as a result, FlightGear looks ridiculous to any new user who comes and tries flying in near cities such as Toronto, Rochester, Buffalo, Cleveland, Detroit, Chicago, or Milwaukee. Sometimes pictures really *are* worth a thousand words. I think this is one of those times. I've put up on the Web (temporarily: they won't be there forever) three screen snaps: Please go to http://www.vex.net/~slocombe/fgfs-pics-of-CYTZ/ for pictures illustrating the problems of CYTZ (Toronto/City Centre), which is on an island in Lake Ontario just offshore from Toronto's downtown area. 1. cytz-from-08-apprch.png : CYTZ from the approach viewpoint of Runway 08 (08/26 is the principal runway of this extremely busy airport: Bombardier Dash8-Q400's take off or land about every 20 minutes, and in between that traffic Cessna 150's and 172's practise circuits or transit to/from Toronto's practice area to the East. I'm one of the student pilots these days. The fact that, in fgfs, the water is 240 feet below its real-world level is only a small part of the problem (in fact if that were the only problem one could just pretend one is practising landings on aircraft carriers). The terrain data, intersected by the water at its current level, makes the shoreline wildly wrong... 2. cytz-overhead-at-40Kft.png : This is taken with the UFO tool at 40,000 ft., looking straight down. 3. google-image-cytz.png : a snap of what Google has for a satellite shot, to compare with the previous shot. I'm not convinced that the terrain data that fgfs uses is sufficiently detailed to capture even the approximate shape of the Toronto Islands (what CYTZ is on the Western end of), let alone the Leslie Spit and docklands to the East. So I'm not sure how different this is going to look if the water-level were correct. But surely it would make a difference, and there are 700 miles of shoreline for Lake Ontario, and another 800 miles for Lake Erie: all of this would be affected by a fix. I presume the shoreline in the St. Lawrence River near Montreal must be seriously wrong too. BTW, Just For Kicks, I can fly *under* CYTZ. It doesn't seem to do me damage, and fgfs doesn't even crash! :-) Thanks everyone for the great achievement that fgfs is. It was fgfs that got me sufficiently enthused about flying to decide to get my PPL. David Slocombe Toronto Canada. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] High Priority: fixing the Great Lakes...
Very nice work! I remember when all land cover in FlightGear (other than runways) was desert -- not sure why Curt picked a desert texture (I think it had something to do with Prescott, AZ). Next, we were able to separate land (always forest) from water. It's come a long way since then. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)
Looks fantastic! David On Tue, Mar 23, 2010 at 4:22 AM, Erik Hofman e...@ehofman.com wrote: Frederic Bouvier wrote: visible. Now I think I managed to get it right with 3d objects. See : http://frbouvi.free.fr/flightsim/fgfs-city-relief-4.jpg Even more impressive! Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 9:41 PM, John Denker j...@av8n.com wrote: There was a bug reported under the Subject: [Flightgear-devel] Setting OBS on command line/.fgfsrc a couple of weeks ago ... but it only affected nav1 IIRC. And it had nothing to do with magnetic variation IIRC. Perhaps not, but try this: fgfs --ndb=YRR --altitude=3000 --vc=100 --nav1=340:114.6 When it starts, the radial on the nav1 indicator will be set not to 340 but to the true equivalent (around 326). When you start at an airport, the radial will be aligned with the runway no matter what you put on the command line -- that's probably the GPS bug. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Messy properties for nav radios
I'd like to encourage everyone to put properties where they would belong in real life -- I took a look at the properties for the nav radio, and they gave me a bit of a headache. Think of what a nav radio and indicator do and don't know in real life: Does know: - what frequency is tuned in on the radio (and the alternate) - what radial the pilot has selected on the indicator - whether it's receiving a VOR/localizer - whether it's receiving a GS - whether the TO or FROM flag is showing - whether the ident volume is turned up - the GS and CDI deviation etc. Doesn't know: - the true heading/bearing of the VOR radial - the time to intercept the VOR or radial - the VOR's error - distance to the VOR etc. I understand that these properties are convenient for other systems, but they should go somewhere they would be in real life, like a DME, GPS database or FMS, not in the (relatively dumb) nav radio itself under /instrumentation/nav/. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug: nav[12] selected radial
There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
It's actually even more confusing than that: the initial value seems to depend on whether the --vor option is selected, what the heading is, etc. All the best, David On Sat, Mar 20, 2010 at 6:09 PM, David Megginson david.meggin...@gmail.com wrote: There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 6:19 PM, Curtis Olson curtol...@gmail.com wrote: Hmmm, the nav database had the actual radial alignment of the station relative to true north and I remember sorting that out so that when you fly off a chart, everything would be in chart-agreement when you flew to radial intersection points. Bummer if that got broke along the way ... I haven't checked it recently. It would take hours to sort out the code to see what's actually happening. The new init functions make things even more confusing, by including strange side effects (for example, setting the heading now sets the azimuth to a VOR or airport, and may also set the selected radial on a VOR). I used to help a lot with this stuff, but I don't think I have the energy now. All the best, David Curt. On Sat, Mar 20, 2010 at 5:09 PM, David Megginson wrote: There's a bug in the /instrumentation/nav/radials/selected-deg property: the code mistakenly assumes that the selected radial is in true degrees, but isn't a bearing -- it's just a number. You could design a VOR where radial 180 was north of the VOR, if you wanted to (though usually it's close to a bearing in *magnetic* degrees). The bug affects the --nav1 and --nav2 option in particular, since --nav1=340:114.6 will no longer start FlightGear with the Nav1 indicator dialed to the 340 radial, unless the local magnetic variation happens to be 0. At CYRO, for example, the actual radial ends up being closer to 326, which is counterintuitive. Nav radios and indicators know nothing about magnetic variation. We used to have this right in FlightGear, but it's gotten messed up over the last 3-4 years. I'd like to fix it, but I'm worried about how many places we've hardcoded this assumption. How hard will it be to correct this? How many of you have designed radios, autopilots, etc. counting on this bug? Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On Sat, Mar 20, 2010 at 7:22 PM, James Turner zakal...@mac.com wrote: There's another bug (in 2.0.0) to do with the GPS interaction with the nav[0] selected radial - I must say I've assumed all problems with --nav1 options misbehaving are ultimately caused by this bug, but it sounds as if you think there's worse things going on. Actually, I think that might be it. It's hard to experiment right now, because I'm in Lucid with the slow open source driver until the ATI proprietary drivers come out, so start-up time takes forever. (I tend to test around my home airport, EGPH, where the magnetic variation is not very noticeable compared to many other parts of the world) We're around 14W here -- just enough to notice. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)
On Thu, Mar 18, 2010 at 8:43 AM, Torsten Dreyer tors...@t3r.de wrote: First of all: That's a really cool eye candy, good work! Seconded. This is the coolest addition I've seen to FlightGear in a long time. What I noticed from a close up is, that it seems that the floor of the buildings is below elevation zero and the roof is at elevation zero. It looks somewhat as if the cities were carved out of the landscape instead of been built uppon it. This is especially irritating when a waterway is crossing an urban area and the water surface is several meters above the ground. I noticed the same problem with roads and 3d buildings -- they're floating above the city. Is it possible to make the bump maps go up instead of down? All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Make relief map go up instead of down? (was Re: Shaders experiments)
On Thu, Mar 18, 2010 at 5:56 PM, Frederic Bouvier fredfgf...@free.fr wrote: I noticed the same problem with roads and 3d buildings -- they're floating above the city. Is it possible to make the bump maps go up instead of down? In Shaders/urban.frag, change line 57 : vec2 dp = gl_TexCoord[0].st; into : vec2 dp = gl_TexCoord[0].st - ds; Tell me what do you think. Try to land in the city. I didn't seem to make any difference -- 3D buildings, trees, etc. were still floating above the roofs of the bump-map buildings. I also tried vec2 dp = gl_TexCoord[0].st + ds; and vec2 dp = gl_TexCoord[0].st - 2 * ds; Thanks, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] News from FlightProSim!
This kind of thing happens sometimes -- not much we can do unless we want to spend tens of thousands of $$ going to court, so there's no point getting stressed. I did go to Google Sidewiki and leave a comment on the page, so that anyone using the Google toolbar or a sidewiki add-on in their browser will see this as the first (and so far, only) comment: Just a repackaged free flight sim Although this site doesn't admit it, Flight Pro Sim appears to be just a repackaging of the open source FlightGear flight simulator, available at http://www.flightgear.org/ Maybe other people would like to add similar comments. I like SideWiki because it prevents sites from censoring open commenting on any web page (though I'd be happier if a single company didn't control it). All the best, David On Mon, Mar 15, 2010 at 3:27 PM, kyle keevill kyle...@gmail.com wrote: Has anyone tried putting their own watermarks on their models and liveries? I usually put my watermark on the engine, then again, we could put a flightgear watermark on the inside of a model (image mapping the inside of a model so he can't see it) Also, has anyone checked to see if he's a part of this mailing list? (and for forum wise, block his IP so he can't post anymore). I'm actually thinking about posting a screen shot of his webpage where is shows that FPS is based on FG. In other news, there's no wiki on FPS, but there is one on FG, should we post a warning on the FG one or make an FPS page and leave a note that redirects to the FREE version of fps? sorry if i start an argument, just trying to help. On Mar 15, 2010, at 2:15 PM, Jon Stockill wrote: Curtis Olson wrote: On Mon, Mar 15, 2010 at 12:56 PM, Frederic Bouvier fredfgf...@free.fr mailto:fredfgf...@free.fr wrote: What will happen if this guy creates a flightgear.flightprosim.com http://flightgear.flightprosim.com page ? We could only hope ... !!! Can we get in trouble ourselves for using his name? Possibly - he claims it's a trademark. One from the screenshots page that contains yet more non-gpl content. If he's including that scenery then that could be a problem. Jon -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Kyle Keevill kyle...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery appearance depends on camera tilt angle
On Thu, Mar 11, 2010 at 4:47 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Wel,, I would see this as a bug, if the frontside with the letter can't be read then anymore. But your pics shows it can bes till, it is just the backside which changes the color. Not a serious bug or showstopper for FWIW, when I'm flying, I see the shading on the scenery change drastically during the flight as the plane turns and pitches. I think what's happened is instead of just changing the shading on the panel, we're changing the shading on the scenery too. FGFS didn't used to do that, so it's a relatively recent introduction. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modeling idea/request: Piper Super Cub
On Wed, Mar 3, 2010 at 3:22 PM, syd adams adams@gmail.com wrote: I could probably get a decent yasim FDM built , but someone else would have to do a JSB fdm , I still dont know what Im doing when it comes to jsbsim . JSBSim works best when you already have aircraft data (derivatives, etc.) and want to stick the numbers into a flight model, though you can also start with an existing one and try to tweak it for a slightly different aircraft. YASim works best when you have only the (easily-obtainable) performance numbers and want to work backwards from them. So unless you have PA-18 testing data, YASim is probably the way to go anyway. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modeling idea/request: Piper Super Cub
On Tue, Mar 2, 2010 at 11:18 AM, Curtis Olson curtol...@gmail.com wrote: From time to time people mention that our j3cub model in FlightGear is rather simplistic and dated by today's standards. It was a nice model for the time when it was built, and it still flies great, but visually it hasn't been updated to match the level of detail and quality we have with many of the current FlightGear aircraft being developed. Thanks for the kind words, Curt. I put a lot of love into that model in the early 2000s, but with the speed of average (not high-end) video cards at the time, I had to keep the poly count very low. It would be great to see a more detailed J3 and Super Cub model. BTW, is really is fun to fly a little tail dragger like the J3, and it still does great wheel landings -- just make sure you're fast on the rudder. All the best, David I recently discovered that I know someone who is pretty good friends with the owner of Cub Crafters in Yakima, WA. Cub Crafters makes a modern kit and a production version of the classic Super Cub design. They have a Carbon Cub which is much lighter and stronger than the original steel tube design. They even have an over powered super cub variant than can top out at 180 mph +++ ! They are a cool company doing some really cool work. Because of this personal connection with the owner of Cub Crafters, I think I could get some more detailed specs and dimensions if someone in our community was interested in building a modern super cub version of this classic design. Here is the Cub Crafter web site. Find your way to their calendar pages too, they have some really great pictures on their web site. http://cubcrafters.com/ The Piper Cub is one of the best known and best loved aircraft ever built so it would be great to have a really nicely detailed version in FlightGear. Aside from that, I have a personal selfish motivation. Recently my friend and the ower of Cub Crafters got together, and because they both have engineering brains, they started brain storming several cool projects that they could combine forces on. A couple of these ideas are actually pretty exciting and they are interested in seeing if they could pursue funding to develop one or more of them. A nice 3d model of a Super Cub could be used to prototype and visualize these ideas and demonstrate them to potential funding organizations. So if anyone out there is interested in tackling a super cub project for FlightGear, let me know what kind of information you would need and I will do my best to secure it for you. The super cub design has been around for a long time so there is probably a ton of information on the web as well. It might even be possible to do some simple instrumentation of a real carbon cub to collect some actual flight test data (that would be a longer term project ... but the owner of Cub Crafters is friendly towards that sort of thing and I am currently developing some hardware and software that could be used for that purpose.) Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders experiments
Wow! David On Sun, Feb 28, 2010 at 5:41 PM, Frederic Bouvier fredfgf...@free.fr wrote: What do you think of this effect : http://www.youtube.com/watch?v=kUyH-4c0-qM http://www.youtube.com/watch?v=wYb1Vy-uTS0 and a screenshot : http://frbouvi.free.fr/flightsim/fgfs-shader-test.jpg Regards, -Fred -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Citation Bravo ADF
On Sun, Feb 28, 2010 at 5:15 PM, syd adams adams@gmail.com wrote: Actually I think it might be a problem with kr-87.cxx , but I havent quite sorted that out yet ... as far as the ADF needle goes . Even with power , it doesnt appear to come alive until you toggle the ADF button on the radio . If you put this in your .fgfsrc, the ADF is alive at the start: --prop:/instrumentation/adf/adf-btn=true The property seems a bit broken, though, because it's really a toggle among ADF and ANT modes (and others?), so something like --prop:/instrumentation/adf/mode=adf would make much more sense. I also notice that /radios or /avionics (I don't remember which) got moved to /instrumentation. Most pilots would never refer to avionics as instruments or instrumentation, but I do understand how the lines are blurring with glass panels, etc. All the best, Davids I dont see the nasal errors your reporting . I'll keep digging . On Sat, Feb 27, 2010 at 2:22 PM, bitwPolly po...@bitwisetech.com wrote: This, as far as I can tell, is the cause of the problems with Bravo's ADF needle: In Aircraft/Instruments-3d/primus-1000/P100.nas line 323: maghdg -=getprop(environment/magnetic-variation-deg); maghdg can return 'nil' at startup so the following addition fixes a thrown error: if (maghdg == nil ) maghdg=0; Also, a nasal error is reported at startup from the following line 363: me.NavTime.setValue(ttg); where ttg has apparently been formatted some lines earlier. I'm not sure what problem nasal has with the resulting format but commenting out line 363 stops that error being flagged. The result of either of the two errors is to stop the ADF/NAV needles being updated, _only_ after the 'NAV' panel button has been clicked. ( On startup the needles work fine but freeze once that panel button is clicked). The nasal error messages would be a lot easier to spot if the console messages relating to multiplayer status and more particularly so many AI models being missing could be suppressed. Thanks, (blucher) -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
On Fri, Feb 26, 2010 at 10:21 PM, Ron Jensen w...@jentronics.com wrote: I still support the idea common shared directories idea for such things as instruments This is a nice, happy thought. But in the real world it hasn't worked out so well. Since we model such a huge variety of aircraft, and different FDMs and systems provide different outputs, our common instrument folders would need to be huge to cover all the different kinds of instruments, plus variations and modifications to fit each individual aircraft's structure. It makes more sense to me to house each instrument with its aircraft. In real life, very, very few instruments are customized for each plane (the airspeed indicator, with its speed markings, is the obvious example). Most are manufactured by independent companies and are TSO'd, so that they can be used in hundreds of different aircraft models. Ditto for most avionics, aside from some glass panels, etc. A Sigma-Tek attitude gyro, for example, looks and works pretty-much the same as a primary instrument for a Cessna 150 or as a backup instrument on a 747 -- the differences (such as different voltage for the backlighting) are pretty trivial. I'd hate to see 100 copies of the same Sigma-Tek attitude gyro in the base package. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
Something I'd love to see, in the long term, is a GUI that allows users to customize their panels, just like real aircraft owners do. I could decide to install a different brand of TC (the default late 1970s Cessna 172P now has a vintage 1950s needle and ball instead of a TC -- cool, but what's up with that?), upgrade or downgrade the GPS, swap out radios, etc. That would be especially attractive for flight schools and students, since they could match the panels of their actual aircraft pretty closely. All the best, David On Sat, Feb 27, 2010 at 8:53 AM, Torsten Dreyer tors...@t3r.de wrote: A Sigma-Tek attitude gyro, for example, looks and works pretty-much the same as a primary instrument for a Cessna 150 or as a backup instrument on a 747 -- the differences (such as different voltage for the backlighting) are pretty trivial. I'd hate to see 100 copies of the same Sigma-Tek attitude gyro in the base package. What we probably need for shared instruments is a well defined set of properties for each instrument. Currently most of our instruments animations are tied directly to the output properties of the signal source. In vor.xml the TO-flag is animated from /instrumentation/nav[0]/to-flag. It's only usable for nav1 and a second set of animation xml is needed for nav2. What we need are unique properties for each instrument that are responsible for the animation of the instrument on on side and unique properties that reflect some state (like a TO-flag signal) on the other side. What's left for the A/C designer is the linkage between these two side. When you buy the Sigma-Tek attitude gyro at you local avionics dealer (the base package), you get your device with a well known interface connector and your avionics technician (A/C designer) needs to do the wiring. Almost everything needed for that three-tier-design is already in fg. Probably we need some kind of relative mount point, so a single vor.xml can be loaded (mounted) into /instrumentation/vor-indicator[0] and /instrumentation/vor-indicator[1]. Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3-Dimensional forests.
On 19/12/2007, gerard robin [EMAIL PROTECTED] wrote: On mer 19 décembre 2007, Pavel T wrote: Hello Flightgear Developer(s), I was thinking of this idea and I thought you might like it. You might have guessed already by the subject of the e-mail. I was thinking of maybe someone could make different versions of trees and make someking of a tool that puts a number a number of trees in a a space automatically. Looking forward to your reply! Pavel. Isn't it the case with FG now ? The last I checked, it worked with the plib version, but not with the OSG version. All the best, David - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On 02/12/2007, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I mentioned the 5 key only as an example. I am not proposing to put a filter on that command. In general, then, as others have mentioned, this belongs in the flight models rather than the input layer. The input layer *requests* a position -- it's up to the flight model to decide if or how fast to provide it. Putting the joystick to full right ailerons is just asking full right ailerons, please. I do like the idea of a filter on '5', though. All the best, David - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Microsoft ESP
On 28/11/2007, Stuart Buchanan [EMAIL PROTECTED] wrote: Given this, we don't need to worry any more about MS patents than we did before the announcement, i.e. hardly at all. All the I/O stuff they've announced is already present in FG. Software patents have no force in Canada in any case, and I think the same applies to most of the rest of the world -- they're a U.S.-specific mistake that a couple of other countries have been strong-armed into following. All the best, David - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
On 14/11/2007, Melchior FRANZ [EMAIL PROTECTED] wrote: Here's a more sophisticated and useful toy: http://members.aon.at/mfranz/keyboard.nas [5.0 kB] It is started with the '/'-key and then waits for the input of a property path, optionally followed by =value or ?: Gott im Himmel! I think you've just made FlightGear into Emacs. (Actually, that might not be so bad ...) All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
On 14/11/2007, Melchior FRANZ [EMAIL PROTECTED] wrote: * David Megginson -- Wednesday 14 November 2007: I think you've just made FlightGear into Emacs. I detest emacs. The script is inspired by vi! :-P Now you're making me nervous. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
On 12/11/2007, gerard robin [EMAIL PROTECTED] wrote: probably i misunderstood the rule, didn't you modify cvs before getting decision about *what* functions need keybindings. I promised to put it back if there were objections -- there were, and I plan to put it back, but I can't connect to the CVS right now (time out). My suggestion about discussing keybindings was also a response to those objections (we used to just check in changes and revert them if people didn't like them, but I can see that the project culture has changed a bit). Given the (apparent) anger and sarcasm, I'm guessing you've had a very bad experience on some other open source project. I'm sorry that's happened (I've worked on projects like that too), but please try to approach FlightGear with an open mind and not start by assuming the worst of everyone -- unless it's changed a lot in the couple of years that I was away, it's a group of very nice and talented people, and I hope they've made you feel welcome. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
Thanks to everyone for the suggestions so far. Just to get back on track, we have to start by seeing if we can come up with a short, priority list of stuff that's (a) applicable to most aircraft, and (b) important enough to have a key assignment. We can decide exactly what those key assignments will be (and what language[s] we'll use) after I've started my own list here: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Keyboard_function_priority_list Please go to the page and edit it with your own suggestions. Collectively, I think we can come up with a priority list that's at least 80% good enough, though obviously we'll never hit 100%. All the best, David . - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki keyboard page (was Re: Keyboard reorg)
On 12/11/2007, gerard robin [EMAIL PROTECTED] wrote: Do you mean wait and see ? No, just that it makes sense to decide *what* functions need keybindings before we decide *where* to bind them. Have you had a chance to edit the wiki page yet? All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Keyboard reorg
This is a good discussion that we've started. Way back when, we didn't have menus (or scripting), so every function had to be accessible from the keyboard (and all the assignments were hard-coded in C++ to boot). I think that we need to take a few steps: 1. Come up with a prioritized list of functions that should have global keyboard assignments (e.g. switch view, lower flaps, raise gear, etc.). 2. Decide on a block of keys to be set aside for per-aircraft key assignment. 3. Agree on a useful set of core bindings for the remainder, which no model should touch. This will be not be easy, but it will be very beneficial. There should be some logic to it, e.g. function keys used for one kind of thing, alphabetic for another, etc. As people have noted, a lot of stuff currently assigned to keys should move to menus and dialogs. 4. Provide a GUI for a user to change keyboard assignments while the sim is running and to save the changes. The user's local changes should override everything else, including per-model assignments. (If we're really sophisticated, we could let the user make his/her own per-model assignments.) Anyone game to start? Does someone already have a first draft of a prioritized function list? All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml, 1.99, 1.100
On 10/11/2007, gerard robin [EMAIL PROTECTED] wrote: I can notice the update has been done , before we could give any opinion on the topic. Does it mean , that there is not any other alternative, and the CHOICE is that way nothing else :) :) :) From my original message: quote I just moved tailwheel-lock from lowercase 'l' to uppercase 'L', and reassigned lowercase 'l' to toggle lighting (for easy night starts without searching for switches). I assigned lighting to the lowercase 'l' because I think it would be much more commonly used than tailwheel lock, but if there are general objections (from DC-3 users?) I can swap the two around so that tailwheel lock goes back to 'l'. Let me know what you think. /quote I or anyone else with access can change it again once there's a consensus -- remember that CVS is the experimentation branch, not the release branch. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor keyboard reassignment
On 10/11/2007, dave perry [EMAIL PROTECTED] wrote: I just looked at the changes in cvs. There is a significant problem with at least this implementation of one key to turn on all the lights for all AC. There is no standard followed for how to implement nasal electrical systems. The patches you made to cvs will accomplish your stated goal for the pa24 and pa28, but not for the SenecaII or the dhc2. This is because when I wrote electrical.nas for the pa28, I started from the eleictrical.nas for the pa24. Some of the nasal electrical systems bypass switches all together and toggle properties such as /electrical/landinglights. Others include functional circuit breakers that would need to be verified. This sounds like a pretty big problem beyond just my patch. Nasal has been great for letting people add functionality to FlightGear, but it causes a lot of problems for the property system, especially when people use different property names, override stuff, etc. It might be time for a refactoring pass through some of the models. A second observation is that I virtually never turn on the white cabin light or the map light because I don't want to ruin my night vision. So even for the pa24, I would not want to have all the light on for most flights. I know -- I don't turn them on either -- but I put them in just for completeness for now. I have no problem pulling them out, once we agree on a common subset (and fix some of the property inconsistencies). All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Minor keyboard reassignment
I just moved tailwheel-lock from lowercase 'l' to uppercase 'L', and reassigned lowercase 'l' to toggle lighting (for easy night starts without searching for switches). I assigned lighting to the lowercase 'l' because I think it would be much more commonly used than tailwheel lock, but if there are general objections (from DC-3 users?) I can swap the two around so that tailwheel lock goes back to 'l'. Let me know what you think. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
On 03/11/2007, Melchior FRANZ [EMAIL PROTECTED] wrote: Not sure if you are talking about dynamic view, but this *isn't* supposed to change the view based on physical forces. The first three lines in $FG_ROOT/Nasal/dynamic_view.nas are: # Dynamic Cockpit View manager. Tries to simulate the pilot's most likely # deliberate view direction. Doesn't consider forced view changes due to # acceleration. I had been looking at dampEyeData in src/Main/viewer.cxx, assuming that was causing the problem. I wasn't looking at any NASAL code. Is the NASAL code enabled by default? And that's how I wanted it to be. I'm not a RL pilot, but I consider it quite unlikely that a pilot flies a left turn and doesn't look left, or strongly pitches up and doesn't look up. Usually we want to know in which objects we are about to crash. :-) I can't speak for every pilot, but that doesn't jibe at all with my real-life experience. I hadn't noticed the problem so much in VFR flights, but flying FlightGear for an IFR approach, I actually lost control of the Warrior twice before I figured out what was going on. When you're flying IFR in actual IMC, you try to keep your head as still as possible no matter which way you move the controls. Even flying VFR in good day VMC, it's common (for me, at least) to look *before* I start a maneuver then return my head to the straight-forward position while I actually fly it, so that I can use outside references properly. Finally, the position you move the controls isn't necessarily the direction the plane will move. For example, on approach you'll be pitching the nose up but the plane's moving down. Forces give a more realistic head movement, I think, because the head moves only if something unusual is happening, like an uncoordinated turn or high/low G forces. It's OK to disrupt the pilot in that case. There are some implementations of forced head changes used in various aircraft (head shaking), but those are IMHO too unrealistic, as they treat the head only as a mass on a spring, and completely disregard the physiology of the eye/equilibrium organ/brain system. If we could agree on one that *feels* realistic, then I would be willing to integrate it in dynamic view. But so far we didn't. A spring's not quite right. I think any movement should be very slight (max 2 cm), and could track the forces on the pilot (maybe using a squared function so that minor forces have virtually no effect and major forces are obvious). The head should be perfectly centred when the pilot feels 1G in the (plane-referenced) vertical axis and 0G in the forward and side axes. No matter what, though, the head should not swivel unless the user decides to swivel it. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
On 03/11/2007, SydSandy [EMAIL PROTECTED] wrote: Looking at videos taken by passengers , you can certainly see these forces ... and as a passenger , I have definately sunk in my seat ( no head springs involved ), so I still use it myself ... Yes, that's much more realistic, and in fact, it's something we study during flight training -- in a coordinated 60-degree steep, level turn, you pull 2Gs and will feel yourself press very heavily down into your seat (though it's unlikely that you sink more than 1-2 cm). Note, however, that there's *no* sideways force at all if the turn is coordinated -- it's all straight down (plane referenced). If you put a spirit level on the top of the panel in a coordinated turn, the bubble would stay exactly centred. When I descend quickly, say, approaching a runway for landing when I had to clear some trees, I'll feel the opposite effect -- my head will move up maybe .5 cm, and my shoulder will press hard against the shoulder strap for a sec, then I return to normal Gs. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
On 03/11/2007, Vivian Meazza [EMAIL PROTECTED] wrote: As Melchior said, the head-shake mechanism does indeed regard the head as a mass and a (damped) spring, but it's a bit more sophisticated than that - the resistance of the neck muscles are modelled as well. Which is enabled by default -- head-shake or dynamic views -- and how do we change the default? Thanks, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
On 03/11/2007, Melchior FRANZ [EMAIL PROTECTED] wrote: * David Megginson -- Saturday 03 November 2007: I wasn't looking at any NASAL code. Is the NASAL code enabled by default? While you were away, we got support for automatically saving GUI settings to an ~/.fgfs/autosave.xml file, and you might have enabled dynamic view at some fgfs run, and now you get it until you turn it off again. You wouldn't be the first to interpret that as an unwelcome default setting. :-) That was it. I was also mislead by seeing dynamic-view type=booltrue/dynamic-view In $FG_ROOT/preferences.xml, without noticing dynamic enabled type=bool userarchive=yfalse/enabled /dynamic just below it. I have no problem with having it as a feature -- it's a neat and original idea -- but it might be worth reconsidering the up/down movement. While pulling back on the yoke/stick may make a jet fighter shoot upwards, with a regular plane it's just as likely intended to slow the plane down. One of the first points made in the classic book Stick and Rudder (worth reading for any real or sim pilot) is that the yoke/stick is *not* an up/down control. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
On 03/11/2007, Vivian Meazza [EMAIL PROTECTED] wrote: As I said before, but perhaps you didn't notice, we already have a force based system working on the input of pilot g. It moves the pilot's eye position according to this input. And as Melchior pointed out, we probably need to stabilise the point at which the pilot looks to make this totally realistic. Is there a way to enable it in general, without tying to a specific aircraft model? Thanks, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fixing head lag
I think it's great that FlightGear added head lag to the sim -- it's a good alternative when the pilot can't feel forces -- but I think we'd do better to model it based on perceived forces, not on roll/yaw/pitch damping. For example, simply entering a coordinated bank gently shouldn't cause any head movement at all, but flying straight in a forward slip should, because there's a yaw force pulling the head slightly sideways. Likewise, while the pilot is perceiving 1G the head should move up a bit, and while the pilot is perceiving 1G, the head should move down a bit. Would anyone object to my checking in some changes over the next week or two to change this? We can always roll them back if they don't work. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Demeter (was Re: FlightGear terrain engine)
On 01/11/2007, Tim Moore [EMAIL PROTECTED] wrote: ... we should concentrate on aircraft models and flight dynamics, and try to interface with an existing engine. That depends on where your interests lie, I suppose. By we, I meant the Flightgear project, not the individuals in it. I would also be very interested in contributing to a terrain engine, but I think it probably would need its own maintainer and team of core developers who were focusing primarily on it, rather than building it as a sideshow to FlightGear, especially since it would have to come with a suite of editing tools to help people manipulate GIS data and manually tweak scenery. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Demeter (was Re: FlightGear terrain engine)
On 01/11/2007, Sergey [EMAIL PROTECTED] wrote: as FlightGear moves to osg there is a nice virtual terrain project which is integrates with osg. The site for the project is http://www.vterrain.org/ and some papers are here http://www.vterrain.org/LOD/Papers/. Excellent. It looks like a good start, but there is a strange culture around the site -- for example, you have to request a download instead of simply downloading the source, even though it seems to have a BSD-style license. I wonder if most of the developers are coming from the Windows world, and don't quite get the norms of open source yet. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Demeter (was Re: FlightGear terrain engine)
On 31/10/2007, Christian Buchner [EMAIL PROTECTED] wrote: I would like to get a few pointers where to look for information about the terrain engine that is currently used by Flight Gear. In particular about the irregular terrain mesh - how is it created (at runtime or offline) and how does photo texture currently get mapped onto terrain - how are roads and other terrain features added? (is it all vector or is it texture maps) Our current terrain engine was great in the late 1990s (when MSFS still had a flat world), but it's pretty stale now, mainly from a lack of interest and the difficulty of understanding the code. It's actually deteriorated in some ways -- note that all the Great Lakes have been forced to sea level now, so that Lakes Huron, Michigan, and Superior are in deep gorges, and all the cities beside them are perched on cliff faces (that wasn't happening a couple of years ago). I'm not sure that we should really be maintaining our own terrain engine any more, though -- we should concentrate on aircraft models and flight dynamics, and try to interface with an existing engine. One promising prospect is Demeter, which works with OpenSceneGraph (already supported by FGFS): http://www.tbgsoftware.com/index.html Unfortunately, Demeter itself seems to have gone a bit stale -- some of the links from the site don't work any more, and it won't compile with the latest version of OSG. It does, however, support LOD and lots of other nice stuff (check out the screen shots!). Maybe someone should take it over if the maintainer has abandoned it, or fork it if the maintainer hasn't but is stalling on new releases. The best thing we could do in FGFS, in the meantime, would be to isolate scenery-engine dependencies so that it's easy to switch to a new engine when it's ready. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] J3 Cub Back Seat Driver
On 25/10/2007, Hans Fugal [EMAIL PROTECTED] wrote: I wonder if it is really that hard to see the compass in the real plane. Maybe so, but combined with the small size and the various reasons why it's hard to make out the magnetic compass in FG even at regular size I have to think maybe it's extra-difficult. I can make it out at 1280x800, but I agree that it is hard to read. Then again, in real life, I can barely read the mag compass in my Warrior sitting in the front seat -- it's a tiny, dim sort of thing. Generally, I lean over and stick my face right in front of it when I need to calibrate my heading indicator. For flying a Cub, you shouldn't look at the compass very often -- it's a look-out-the-window plane, not a look-at-the-panel plane. Use 'x' to zoom in on the compass to check your heading once in a while (ctrl-X will snap back to regular zoom), then pick a point outside the window as your heading reference and look at it instead of the compass. That's probably the best equivalent of the Cub pilot leaning forward to take a glance. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] J3 Cub rerigged (was Re: J3 Cub Back Seat Driver)
Since I came back to FlightGear a few weeks ago, I've flown the J3 Cub mainly with the mouse (for short breaks from work), so I hadn't noticed how badly out of trim the plane has been flying. I've just checked in changes to fix the (non-adjustable) rudder and aileron trim to get rid of the strong roll+skid tendency in level cruise. Note that the plane will still pull to the left at a high angle of attack (e.g. takeoff or steep climb), as it should. For those of you who like this model, it should be a bit less annoying to fly with a joystick or yoke now. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] J3 Cub rerigged (was Re: J3 Cub Back Seat Driver)
On 25/10/2007, Hans Fugal [EMAIL PROTECTED] wrote: Thanks! You mention the nonadjustable rudder and aileron trim - is that nonadjustable in theory only or does flightgear also enforce this? If not, can it be made to? It wasn't clear from the j3cub.xml file. You can adjust it in flight if you bind some keys to the trim properties, but it would be pretty unrealistic -- I doubt that any J3 Cub has ever had rudder or aileron trim. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] J3 Cub rerigged (was Re: J3 Cub Back Seat Driver)
On 25/10/2007, Hans Fugal [EMAIL PROTECTED] wrote: You can adjust it in flight if you bind some keys to the trim properties, but it would be pretty unrealistic -- I doubt that any J3 Cub has ever had rudder or aileron trim. Or have a joystick. Actually, the J3 does use a stick instead of a yoke -- you can see it in the 3D model (it's mounted on the floor, between where your feet would be). All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
On 12/10/2007, drew [EMAIL PROTECTED] wrote: I have my .fgfsrc file set up so I start on the run-up area just off the main runway at KSFO: --lat=37.612451 --lon=-122.357858 --heading=026 so I have the time to do pre-flight checks (and explore the cockpit and README's of new and unfamiliar a/c) without clogging up the threshold. If you want to be even more realistic, you can start on the GA apron off taxiway C north of firehall #2. From the following diagram, it looks like longitude 122 23.0 W (-122.38) and latitude 37 37.7 N (37.638333) should do the trick, with a heading of around 150 deg T so that you're parked sideways to the FBO: http://flightaware.com/resources/airport/SFO/APD/AIRPORT+DIAGRAM/pdf You can read about the actual Signature FBO here: http://www.airnav.com/airport/KSFO/SIGNATURE All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Consistent aircraft states
On 12/10/2007, dave perry [EMAIL PROTECTED] wrote: Welcome back. I am the one that made all the changes to the Warrior. Starting directions and keyboard switch equivalents are under the help menu-Aircraft help, just like with the pa24-250. It was after you had commented on how you liked what I had done on the pa24 that you sent me your pictures and asked if I wanted to continue developing the Warrior, so I used the pa24 nasal work as a starting point for implementing the Warrior electrical system and switches. You did a great job on it -- I'm very impressed. I still consider the Warrior your aircraft and had communicated to you off list in mid August that I had made updates and changes. I asked for feedback in that note. I assume that you did not disable or bypass the nasal implemented switches with the above change. No, but I did migrate some of the property settings out of the Nasal script and into the XML settings file. I am clearly one that prefers to start with the brakes set and all switches off as that is the way every real flight starts. (An aside: In my experience, it's rare that the parking brake is on when a real light plane is parked, because line staff wouldn't be able to move it around without gaining inside access -- in fact, when I get out of the plane at a remote airport, the first question from line staff is usually not do you need fuel? but is the brake off?. Normally, a plane on an apron is chocked, while a plane in longer-term parking is tied down.) But I also see the advantage of having an easy option to start in the air with switches and fuel valve set for an approach. Perhaps with a little more effort, there is a way to accomplish both. Here are a few usability guidelines that might help: 1. Consistency - all aircraft should start in same default state as far as possible (obviously, a glider doesn't have an engine), so that a user isn't surprised when switching aircraft types. 2. Configurability - it should be not only possible but very easy for a user to override the default state without editing XML or Nasal files. 3. Simplicity - the default state should be the easiest one for new users. Experienced users will have an easier time changing the default. I suggest that we introduce a new global property, such as /sim/start-state, which can be set to (say) parked, in-air, or idling. The configuration files for every aircraft could respect that property, so that if you set it to parked, *every* aircraft (even the default 172) would start parked, etc. (we could even put it on the apron instead of the runway if we add parking coordinates to the airports file). I think idling should be the default the first time someone runs FlightGear, since it's standard with all flight sims and by far the easiest for new users, but one menu selection should be able to switch to parked for people (like you) who prefer to go through the startup and taxiing routine every time. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
On 12/10/2007, gerard robin [EMAIL PROTECTED] wrote: Only one generic property switch is necessary. We must only, all together decide which name and where (/sim/ ??) [snip] For instance looking at one of my model to have the right flying conditions, i need: Canopy = Down Wing-folds = Off Wing-incidence = Down Electric-power = On Cut-off = Off Engine= running Throttle = 0.6 Landing-gear = Up All these property could be switched according to that Cold/Hot property The sim can also decide where/how to place the aircraft (if not otherwise specified) based on the value. For example, by default, we could place the aircraft 1,000 ft above the airport at cruise speed if the value were in-air, on the runway threshold (as now) if the value were idling, and on the apron (assuming we have coordinates) if the value were parked. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Hangar start
On 12/10/2007, AnMaster [EMAIL PROTECTED] wrote: I prefer starting with engine off (and not at threshold) so why not add support for starting somewhere else than end of runway? Starting at the gate for example (makes sense for 787 but not for the warrior) or in a hangar (if such exist at that airport). You probably wouldn't want to start in a hangar unless you wanted to animate a little pilot with a sore back pulling the plane out onto the apron -- it's extremely rare to start the prop when the plane is indoors. In front of a hangar might make sense, but with the nose angled away so that the prop blast doesn't blow back into the hangar. Seriously, I think we should make it easy to start the way you want, but there's a lot of work involved. The original aircraft config system was designed to make it easy for users to override default settings at runtime, but I notice now that lots of people use Nasal scripts (etc.) to forcibly override default properties, so you're pretty-much stuck with whatever the designer decided until we have time to clean up all the config files. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Warrior changes
On 11/10/2007, Hans Fugal [EMAIL PROTECTED] wrote: This isn't the only plane that starts in cold configuration. I think it would be best to be consistent - either leave it up to the plane designer in every case (I believe in this case at least it was a conscious decision on the part of the designer), or decide on a policy that every aircraft should start hot and try to make that consistent throughout. I was the aircraft designer, though others have done a lot of excellent work on the Warrior since. One problem with starting in cold configuration by default is that in-air starts won't work. For example, if you use FlightGear to practice IFR approaches (like I do), you want to start in the air about 10 miles from the runway, not in the tie-down area. There was no way to do that using command-line options with the previous version of the config files. I recommend that we start all aircraft running and ready to roll, but provide an easy way for advanced users to start cold if they want to. I know that aircraft designers work hard on the switches and systems and want to show them off, but forcing people to use them every time might not be the best choice, especially for new users (and when the default start is on a runway threshold, where the engine should be running). All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hangar start
On 12/10/2007, AnMaster [EMAIL PROTECTED] wrote: Maybe add tow truck to flightgear? I wouldn't want to pull an English Electric Lightning for example (would it even be possible?) It's fun to see the variety of tow vehicles at airports. For airliners, of course, there are the white tugs that we all recognize, but for smaller planes, I've seen old pickup trucks, converted riding mowers, and even a little dune buggy -- the only thing they have in common is that they're usually even noisier and harder to start than the airplanes. Some pilots also use powered towbars for smaller aircraft. Basically, anything up to the size of a Navajo or Cessna Caravan can (and will) get pushed around by hand, and it's a sort-of unwritten rule that you run over to help whenever you see someone starting to move a plane around; in fact, I do know a commercial Navajo pilot who can push her plane back into a spot with no assistance, though I sometimes have trouble even with my Warrior when the tires are soft and there's snow on the ground. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Warrior changes
As I mentioned earlier, the Warrior model is looking great. However, because it was starting with the engine and fuel off and the brakes on, it took a while to get started (and wasn't realistic sitting on the threshold with the engine off), and I don't think it was possible to do an in-air start, e.g. fgfs --aircraft=pa28-161 --altitude=5000 --vc=100 There were some places that the Nasal scripts were overriding startup preferences. I started cleaning those up and made a few more changes, so that the Warrior now starts up just like the Cessna 172 or J3 Cub, ready to take off. Please let me know if you find any problems. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions
On 08/10/2007, Jon S. Berndt [EMAIL PROTECTED] wrote: There are two gains that come into play. One is from FlightGear (0.0 to 1.0, as Dave M. pointed out), and the one eventually sent to JSBSim, which is in ft/sec. It looks like the one set in JSBSim can vary from 0.0 to 100.0 ft/sec. That is the maximum value expected. That seems high to me. The maximum value should be high enough to destroy an airframe. It would be worth investigating research into cumulonimbus clouds, downbursts, etc., but I don't think 100 ft/sec is out of line. Unless you want to make the 0-1 turbulence value non-linear, anything about about .1 should be very unpleasant to fly in. I did stumble into a small, developing storm cloud once in my Warrior. Fortunately, the up- and downdrafts had smooth enough transitions not to cause damage, but they pegged my VSI in both directions, threw me back and forth into uncommanded 60-degree banks, and we gained and lost a couple of thousand feet in seconds. It's almost impossible to believe the power stored in even a small storm cloud until you've seen it. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions
On 07/10/2007, Jon S. Berndt [EMAIL PROTECTED] wrote: I looked at the configuration file for the Seneca II in flightgear cvs. It appears to me (at least given the quick glance I took) that adverse aileron yaw (Cnda) is turned off - the data is all zeros. I'm not sure about the exact derivatives, but the real PA-28 and the 172 experience negligible adverse yaw in level cruise at bank angles under 20-30 degrees -- you can fly them with your feet flat on the floor and the slip-skid ball barely moves. In both, I think, it's the use of differential aileron deflections that does the trick. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilots, adverse aileron yaw and jsbsim questions
On 08/10/2007, Jon S. Berndt [EMAIL PROTECTED] wrote: Does anyone know what typical values are for these two properties: /environment/turbulence/magnitude-norm /environment/turbulence/rate-hz The fact that the first property is named magnitude-norm (emphasis on the *norm*) makes me suspect that the turbulence goes from _1 to +1. But, that wouldn't do much for turbulence. And, is that 1 ft/sec? Or is it the value of the turbulence in ft/sec? I helped implement this with Tony a few years ago. As I recall, the value was from 0 to 1, where 0 represents no turbulence, and 1 represents the most severe turbulence that we model. You couldn't represent turbulence simply in feet/second, because it consists of both movements and rotations. Note also that the current system has problems for multiplayer mode. For example, if the turbulence were set to .5 (which should be pretty bad), a J3-cub and a Boeing 747 flying into the same airport will experience the same turbulence, while in reality turbulence that would tear a wing off a J3 cub might not do much more than jiggle the drinks in the 747. As soon as you consider a world with more than one plane flying at once, we have to think about modelling the turbulence not by its effects on the plane, but by its source air motion. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] piston aircraft pre-flight engine runup
On 05/10/2007, drew [EMAIL PROTECTED] wrote: Yes. I've actually had the pleasure of pushing a crate with a shonky donk back to the hanger. There is an alternative, sometimes. If the plug isn't completely dead but just misfiring a lot, you can often clear the lead by doing a high-power, lean ground run for about 5 minutes. Rental planes are especially prone to lead fouling, because a lot of people taxi them around with the mixture set to full rich. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modeling VOR/DME stations
On 05/10/2007, Bohnert Paul [EMAIL PROTECTED] wrote: Doe any body have a picture of the VOR at KSFO? I have not been able to find one. Here it is from the top: http://maps.google.com/?q=37.619,-122.375ie=UTF8ll=37.619494,-122.373772spn=0.000935,0.002103t=kz=19om=1 All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Looks great
I have a new notebook (an HP TX1220, which is a stunningly beautiful machine), and decided to try compiling the latest CVS osg FlightGear instead of using the old precompiled plib version from the Ubuntu distro. Here are some comments: 1. Wow! The program is looking great. It was a very nice surprise to start up the Warrior and see so much detail from my own plane (including the ugly 1979 upholstery). 2. I see that there are still some issues with OSG, particularly with random objects and visibility. Right now, fgfs isn't usuable for IFR practice -- my main use -- because of the strange artifacts flying through low ceilings and vis, so I have to keep the old plib version on my HD as well. 3. Still no version 1.0, Curt? I don't have a lot of time to contribute, but I might try to help with #2, if anyone can point me to archived messages or other resources discussing the problem. All the best, David - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Looks great
On 19/09/2007, Durk Talsma [EMAIL PROTECTED] wrote: Welcome back and thanks for the compliments! As for versions: No, there isn't a 1.0 in sight yet, but I'm currently trying to help Curt in getting ready for a new release soon. This will be a plib based release, called 0.9.1[1]. I didn't realize that the plib version was still being developed in parallel with the OSG one. Would I be just as up-to-date if I checked out a plib branch, or is the focus for the future still OSG? All the best, David - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG vs. trees and buildings
On 19/09/2007, Heiko Schulz [EMAIL PROTECTED] wrote: Sebastian Bechthold is working on that- he is working about a implemention of an object placer which automatic places buildings to right textures/ materials. If there is a town, so there are buildings depending of it is industrial or normal life or anything else Excellent. Is he modifying the existing plib-based code for doing that, or implementing entirely new code? Thanks, David - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSG vs. trees and buildings
What are the issues with OSG around dynamic scenery (trees, non-static randomly-placed buildings, 3D clouds, etc.)? Is it just a matter of spending a few hours coding, or is there something in the OSG APIs that makes dynamically-generated scenery difficult? All the best, David - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] World Scenery
On 07/04/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: And a little cubical shed and a radio mast close the start of runway 06 (I think) of Orly. Localizer. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision detection.
On 03/04/06, Andy Ross [EMAIL PROTECTED] wrote: I think the original report might have been that you can bury a fast moving aircraft under the ground. The 100 Hz granularity of the FDM computations isn't able to detect the exact moment of collision. That's a much harder issue to solve; you'd have to extrapolate backwards to make it work. I have to add that this never seems like a problem to me. My goal in flying, either in real life or in FlightGear, is to keep the dirty side down and avoid hitting anything. The idea of a crushed plane makes me a bit nauseous, and the fact that the plane unrealistically buries itself in the ground doesn't seem like a big problem -- in real life, hitting the ground at that speed, I wouldn't be alive to see anything anyway. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision detection.
On 03/04/06, Justin Smithies [EMAIL PROTECTED] wrote: Any possiblity of collision detection in the near future ? I.e. instead of the aircraft falling through the ground it just stop dies explodes whatever. Collision detection and explosion animation are two different things. With JSBSim, better collision detection is, if I remember correctly, simply a matter of defining more contact points around the aircraft body (e.g. in the nose, the end of the empennage, the wingtips, etc.). I don't remember how it works in YASim. An explosion animation is cute, but usually inaccurate. It doesn't hurt to have some way to show that the plane is damaged, though. Also would it be a big job to stop the aircraft going through 3d models as if they were ghosts ? I think it would be a big job, but we'll have to do it sooner or later. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Few 3d Modeling questions
On 29/03/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Now the questions is it oke if I solve some of the outstanding issues with plane textures and 3d models? Yes, please. If the plane has a current maintainer, send your changes to him or her if possible (if you don't hear back in a while, or cannot get an e-mail address, skip ahead) -- otherwise, the best way to distributed them is to put the changes in a tar or zip file somewhere online and send a URL to this list, so that people can try them out. If that doesn't work, you can send a private e-mail to someone with CVS access with your changes attached. I do not recommend sending attachments to this list, though, since they might clog up a lot of inboxes. As for what you update, concentrate on what you're most interested in -- you'll get more done and have fun doing it. Welcome. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa24-250/Models pa24-250.ac,1.6,1.7
On 27/03/06, Martin Spott [EMAIL PROTECTED] wrote: My compliment to David P. for the fading prop disc - compared to everything I've seen before this is close to perfect. Even details like the tips of the prop blades look pretty much realistic, Ditto -- Dave's done a great job. I think it's fair to say that the pa24-250 Comanche is now our best-looking and most accurate interior 3D model of a general-aviation piston plane, single or twin. The flight model still needs work, but it's also coming along well. I wish I had time to fix up the c172 Skyhawk or pa28-160 Warrior to the same level of detail so that we could have a nicer default starting plane (the Comanche is too fast and complex for a beginner). I'd vote for the Cherokee/Warrior over the Skyhawk, not only because I own one, but because everyone else seems to use a Skyhawk by default in their sims. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/pa24-250/Models pa24-250.ac,1.6,1.7
On 27/03/06, Martin Spott [EMAIL PROTECTED] wrote: I noticed a red knob left to the throttle. In the (real) aircraft I know the carb heating is usually located there, the levers are different but the location is always the same. As FlightGear doesn't model carb heating I'm curious that this knob is for. My Warrior's carb heat is a lever to the right of the throttle and mixture -- I wonder if the red knob on the Comanche is for alternate static air or something similar. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: new contribution
On 27/03/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am pretty sure this Great Lake as Ocean bug is also the reason behind that ugly floating airport on Toronto Island (CYTZ). That's exactly it. I fly to CYTZ frequently in real life, and I can attest that the runways are only a few feet above lake level (I actually flare over the water sometimes before touching down on runway 26, so that I can land short and make the taxiway C turnoff into the Esso). All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airports list
On 26/03/06, Paul Surgeon [EMAIL PROTECTED] wrote: I did do some work on that a long time ago using the ICAO codes to break up the data by country but ran into a couple of problems. 1. There is no state/province field in the airports db and it can't be deduced from ICAO codes. 2. There are a couple of areas in the world that share the same ICAO code even though they belong to different countries so using the ICAO code isn't a 100% accurate method. 3. Smaller airports sometimes don't use ICAO codes (though most of those are in the U.S.). All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: airports list
On 26/03/06, Melchior FRANZ [EMAIL PROTECTED] wrote: (K ... almost all US airports Except P for Hawaii (PH), Alaska (PA), and former and current U.S. territories. Additionally, individual states use three- or four-letter designators for very large number of airports that do not have ICAO codes. For example, from our current database, NY17, NY28, NY55, NY82, NY87, etc. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: airports list
On 26/03/06, Melchior FRANZ [EMAIL PROTECTED] wrote: Yeah, whatever. I'm fixing an absolutely crappy and useless implementation, and the fix is already infinitely better. I never said it's perfect already. Thank you very much for that, Melchior. None of this is intended as a criticism of your work, only of the bizarre complexity of airport codes in the first place. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Battery simulation
On 26/03/06, Erik Hofman [EMAIL PROTECTED] wrote: For those of you who feel the desire to model the lead-acid aircraft battery up to a bizarre level you could visit the Gill site: http://www.gillbatteries.com/manual.cfm I'll be buying a new GIll battery in a couple of weeks. For FlightGear, I think it's probably sufficient simply to model the fact that the battery discharges (very rapidly, during cranking), that the alternator or generator recharges it, that the alternator will not work with a completely flat battery (though a generator will), and that the battery cannot hold as large a charge when it's cold. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Battery simulation
On 26/03/06, Erik Hofman [EMAIL PROTECTED] wrote: I already thought that simulating shelve discharging would be pretty bizarre :-) In extremely cold temperatures in northern Canada and Alaska, pilots sometimes remove the batteries from their planes and bring them inside with them; sometimes they even drain all their oil and keep it indoors. All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Free inverse geocoding service (was Re: [Flightgear-devel] Re: airports list)
On 26/03/06, Melchior FRANZ [EMAIL PROTECTED] wrote: I have such a file, too (country.nas), but it can't hurt to compare that with your version and the Wikipedia page. Yes, please send it to me. Thanks. I found a free inverse geocoding service here: http://dma.jrc.it/services/querymap/querymap.asp?x=-75y=45featuretype=countrybuffer=1output=xml It uses fairly coarse rectangles, so it won't always get the country and region right, but it would make a good start. It's a fairly slow process, though, so I'd talk to the site owner before hitting it with 20,000+ queries for our airport database. (You can also get cities with featuretype=city, and you can play with the buffer parameter to limit the size of the area searched for intersecting rectangles). All the best, David -- http://www.megginson.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
