[Flightgear-devel] Bad link on Downloads page
Oops - the link to Bleeding-edge CVS snapshot on the Flight Gear Downloads web page points to repository version 0.7! - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] data logging
Boslough, Mark B writes: Is there documentation on the current data logging feature? I have been logging and playing back flights using JSBSim, but it looks like there is a general FlightGear feature that records CSV files now. I just can't quite figure out how to use it. docs-mini/README.logging All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: Looks good, does this tie into the electrical system model at all, or does it just respond to switch position ? So far, just the switch; I'll work on integrating it more fully later. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
David Megginson writes: Curtis L. Olson writes: Looks good, does this tie into the electrical system model at all, or does it just respond to switch position ? So far, just the switch; I'll work on integrating it more fully later. Should just be a matter of which property you point at (the switch value or the electrical system output ...) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] data logging
Thanks David. I'll try that out! I wrote my own little playback routine (so I can replay flights from a .csv file). Do you all have plans to incorporate such a thing in FlightGear? I can run forward or backward using the joystick to control the speed. Mark -Original Message- From: David Megginson [mailto:david;megginson.com] Sent: Thursday, November 07, 2002 4:27 AM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] data logging Boslough, Mark B writes: Is there documentation on the current data logging feature? I have been logging and playing back flights using JSBSim, but it looks like there is a general FlightGear feature that records CSV files now. I just can't quite figure out how to use it. docs-mini/README.logging All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: ExternalNet FDM
So the only command line change would be to go from --native=socket,in,30,,5500,udp --fdm=external to --native=socket,in,30,,5500,udp --fdm=null btw, do we have an 'official' port number assignment ? Over the time I read several suggestions by several members over the use of port 5500: --props=socket,bi,5,localhost,5500,tcp --nmea=socket,out,2,localhost,5500,udp --httpd=5500 --native=socket,in,30,,5500,udp --fdm=null [... maybe some more ...] It would be useful at least to postulate a FlightGear assignment - it does not have to meet RFC1340 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] data logging
Boslough, Mark B writes: I wrote my own little playback routine (so I can replay flights from a .csv file). Do you all have plans to incorporate such a thing in FlightGear? I can run forward or backward using the joystick to control the speed. That sounds great -- we'd probably want to add it as an FDM. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
David Megginson writes: Curtis L. Olson writes: Looks good, does this tie into the electrical system model at all, or does it just respond to switch position ? So far, just the switch; I'll work on integrating it more fully later. Should just be a matter of which property you point at (the switch value or the electrical system output ...) Let me know where I should point it. Let's see, from the c172-electrical.xml I have: /systems/electrical/outputs/landing-light /systems/electrical/outputs/beacon /systems/electrical/outputs/strobe-lights /systems/electrical/outputs/taxi-lights I believe these all default to on, unless there is a switch some place that is explicitely turned off. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: starting the XML GUI; early implementors needed
I've committed CVS changes to begin an XML-configurable GUI. It's far from ready for end-users, but I need early implementors to start playing with what's there so far and to try making their own, simple dialogs using XML markup. To see an XML-configured dialog for a fancy FlightGear hello world, type Ctrl-D. The XML configuration is in $FG_ROOT/gui.xml. There is a new subsystem named gui, and a new command gui which takes the argument name for the name of the dialog to run, like this: key n=4 nameCtrl-D/name descDummy dialog/desc binding commandgui/command namehello/name /binding /key So you can already bind a dialog to any keystroke, mouse action, panel action, joystick button, etc. etc. Only a few components are present so far: group An invisible container holding a group of child components. dialog A group that will appear centred on the screen, with a visible background. The 'modal' subproperty controls whether the dialog is modal (puDialogBox) or non-modal (puPopup). input A text input field that can display the value of a property specified in the 'default-value-prop' subproperty (current read-only, but soon it will allow you to change the property value). text An uneditable text field. The text appears in the 'label' subproperty. button A push-button widget, with its text in the 'legend' subproperty. Currently, pushing any button simply closes the dialog, but soon other types of actions will be available. The 'default' subproperty controls whether the button is the default when the user presses Return, and the 'one-shot' subproperty controls whether the button pops back up on its own. Here is a rough outline of my future plans: 1. Allow users to modify property values and to add user-assigned actions to buttons. 2. Add more widgets, including at least sliders and check boxes, linked to property values. 3. Integrate the XML-configurable menu system into the new system. 4. Completely replace the existing GUI code with the new GUI subsystem and delete the old GUI code. 5. Allow dialogs to invoke other dialogs recursively. 6. Integrate Steve Baker's new PSL (PLIB Scripting Language) into the dialogs to allow complex, scripted behaviour. 7. Allow eye candy like icons and different fonts and colours. 8. Maybe introduce some simplistic layout managers to make it easier to design dialogs and place sub-components. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: Let's see, from the c172-electrical.xml I have: /systems/electrical/outputs/landing-light /systems/electrical/outputs/beacon /systems/electrical/outputs/strobe-lights /systems/electrical/outputs/taxi-lights You need to add the navigation lights (required by law at night), cabin lights, and (for some aircraft) panel lights, map light, and so on. There is a scary number of different permutations, even for a single C172 model -- for example, each separate gauge may or may not have its own internal light, depending on options chosen by the owner, replacements, etc. The VOR gauges seem the most likely to be separately lit. I believe these all default to on, unless there is a switch some place that is explicitely turned off. OK, then we need to wire these into the switches in the /controls/lights/* hierarchy. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ExternalNet FDM
Martin Spott wrote: So the only command line change would be to go from --native=socket,in,30,,5500,udp --fdm=external to --native=socket,in,30,,5500,udp --fdm=null btw, do we have an 'official' port number assignment ? Over the time I read several suggestions by several members over the use of port 5500: --props=socket,bi,5,localhost,5500,tcp --nmea=socket,out,2,localhost,5500,udp --httpd=5500 --native=socket,in,30,,5500,udp --fdm=null [... maybe some more ...] It would be useful at least to postulate a FlightGear assignment - it does not have to meet RFC1340 Martin. Actually I don't think 5500 is a good idea - it is already assigned to someone else: fcp-addr-srvr1 5500/tcp fcp-addr-srvr1 fcp-addr-srvr1 5500/udp fcp-addr-srvr1 # Mark Zeiss [EMAIL PROTECTED] (see http://www.iana.org/assignments/port-numbers). Unless and until we have an assigned number, we should use a number from the Dynamic and/or Private Ports range: 49152 through 65535. So 55000 would be OK! Of course you can use any number you like on a private network (not connected to the Internet, and where you know that the port you choose is not in use by any other protocol) or when you know that the machines sending and receiving are not going to use that other protocol. There is actually a reasonabe chance that an assigned port number would be granted if we requested one. My company recently got one, even though I was expecting we wouldn't be able to justify the need for it. However, I don't think it would be appropriate until the protocol has settled down and been used for a while. So may I suggest changing the suggested number to 55000 in the documents that mention it? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RFD: /controls/engine/ reorg
A while ago, Curt suggested moving from /controls/afterburner[0] /controls/afterburner[1] /controls/afterburner[2] /controls/afterburner[3] /controls/mixture[0] /controls/mixture[1] /controls/mixture[2] /controls/mixture[3] /controls/propeller-pitch[0] /controls/propeller-pitch[1] /controls/propeller-pitch[2] /controls/propeller-pitch[3] /controls/throttle[0] /controls/throttle[1] /controls/throttle[2] /controls/throttle[3] and so on, to something more sane: /controls/engine[0]/ /controls/engine[1]/ /controls/engine[2]/ /controls/engine[3]/ with 'afterburner', 'mixture', etc. as subproperties of each one. This change would certainly make life easier in the property browser, but it would require changing quite a few bindings. I'm willing to make the change myself throughout the FlightGear source code and base package, but it will break some local customizations. How does everyone feel about the change? We could even go to /controls/engines/engine[0/ and so on to simplify the /controls/ top level further. All the best, ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
On Thu, 7 Nov 2002 14:03:54 -0500 David Megginson [EMAIL PROTECTED] wrote: A while ago, Curt suggested moving from /controls/afterburner[0] This looks like a good idea, but one thing I'll throw out here and maybe Tony has any idea on how we can handle this. I am still planning in finishing up our multi-instance capability, which allows, for example, an F-104 to carry an array of guided and unguided, propelled and gravity bombs, and for each one to carry guidance routines. There may arise the possibility of having a missile dropped from an F-104 and igniting its engine, then flying out to a target. Of course, much or all of this would be automatic. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Parachute for C172
I found a Flight International around work today when I was waiting for someone. It has an article about an emergency parachute system on some plane (I forget which), and I think it said you could get them for C172's and another Cessna... So how long before I can land my fgfs C172 by parachute? Later, Chris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C172 Taxiing speed
Hi all, I'm working on getting the small plane to taxi back in after flying a circuit, so I'd appreciate some input from the pilots from the list on real-life taxiing. What sort of speeds are typical during taxiing on the runway, on a large taxiway, on a small taxiway between rows of parked planes, and when turning corners. What's a typical turn radius at a 90degree junction. Are major taxiways such as the one parallel to the rwy that normally seems to be called Alpha 2-way or is the traffic normally directed one-way on them by ATC depending on the rwy in use? Do most light plane parking spots have a designated direction when parked or is either way fine? Thanks in advance for any input, Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Parachute for C172
Christopher S Horler writes: I found a Flight International around work today when I was waiting for someone. It has an article about an emergency parachute system on some plane (I forget which), and I think it said you could get them for C172's and another Cessna... It's called the Ballistic Recovery System (BRS), and is still a little controversial. They're used mainly on ultralights (which have an unfortunate tendency to fall apart in flight), but also come standard with the Cirrus SR20 and SR22, and have been certified for use as an add-on with the C172. While the company claims hundreds of lives saved in its ads aimed at Cessna and Cirrus pilots, all of the saves were actually ultralights until a few weeks ago when a Cirrus pilot deployed the chute after losing an aileron. He lived; it's impossible to know how he would have managed without the chute, but it's worth noting that the plane was still under control when he deployed: http://www.avweb.com/newswire/news0241b.html So how long before I can land my fgfs C172 by parachute? That's what a lot of people are afraid of -- my engines running a little rough, better pull the chute. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] C172 Taxiing speed
David Luff writes: I'm working on getting the small plane to taxi back in after flying a circuit, so I'd appreciate some input from the pilots from the list on real-life taxiing. What sort of speeds are typical during taxiing on the runway, on a large taxiway, on a small taxiway between rows of parked planes, and when turning corners. The rule I learned is never taxi faster than you can jog comfortably (10 km/h or about 5kt for me), and usually more slowly, especially at night or in bad weather or gusty winds. The ASI isn't all that useful at low speeds on the ground, so we usually gauge it by power setting: I was told to taxi a 172 at about 1000 RPM, but I end up riding the brakes that way -- I find that 800-900 RPM is more suitable (and even then, I brake more than I'd like to). What's a typical turn radius at a 90degree junction. That's easy -- follow the yellow line. Seriously, rwy 4/22 at CYOW is 75 ft wide, and we usually backtrack on 04 from taxiway papa to get the full length for takeoff. When I go back right along the edge (say, 5 or 6 feet in), and turn very tightly with a lot of differential braking, I can just bring it onto the centreline without an s-curve and without stopping my forward roll. That's a minimum turning diameter of about 30 feet (15 foot radius) while actually rolling forward -- a 25 foot radius would likely be much more comfortable. You can turn much more tightly if you stop your forward motion and just pivot around one wheel, but that's not good for the plane. Are major taxiways such as the one parallel to the rwy that normally seems to be called Alpha 2-way or is the traffic normally directed one-way on them by ATC depending on the rwy in use? That would be very airport specific, but note that almost every case ends up being a special case. People are always requesting a different runway, a different taxiway, a different intersection takeoff, etc., and ATC is usually pretty obliging. When I taxi on taxiway alpha at CYOW, there is sometimes a big 767 or Airbus heading straight towards me -- I have an instruction to hold short at delta and the big plane will turn onto the main apron before there, so there's not conflict, but it would look quite frightening to a new passenger. So the short answer is to let your AI plane take the shortest route back to parking. Note that it should stop for a while before crossing any runways -- even when you're precleared to cross, you still stop and look. The C172 should also stop to do a runup just before it goes to the hold-short line runway -- that can take 3-5 minutes for a single and longer for a twin. Allow another minute or so for tower clearance before taxiing out for takeoff. Do most light plane parking spots have a designated direction when parked or is either way fine? Light planes are almost always parked facing into the prevailing wind, especially if they're out on the field. On the apron in front of our hanger, they're facing any which way. The easiest choice would be to have the AI plane just stop in front of the pumps. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: ANN: starting the XML GUI; early implementors needed
I've just added the ability to modify property values: we can now construct very simple dialog boxes that actually control FlightGear (the demo can control roll, pitch, and heading). More interesting stuff like pick lists, value constraints, etc. will follow. Again, I need feedback from early implementors -- try making a dialog for something you care about and let me know what you need the most. Enjoy, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
David Megginson wrote: A while ago, Curt suggested moving from ... and so on, to something more sane: /controls/engine[0]/ /controls/engine[1]/ /controls/engine[2]/ /controls/engine[3]/ Yes, lovely. Excellent. We could even go to /controls/engines/engine[0/ and so on to simplify the /controls/ top level further. No - we have that in some places, but I was thinking recently that it's not the right way to go. I think the only practical purpose is to reduce clutter in the browser; but the property browser could and should do this for us if we want it to. For example, it could display controls/ elevator engine[*] flaps ... and then, when the user clicks on it, expand it to controls/ elevator engine[0] engine[1] engine[2] engine[3] flaps ... or to controls/engine [0] [1] [2] [3] From an abstract point of view, engines/engine[n]/ could more succinctly be arranged as engines/n/ or engine[n]/ and this last seems to be the way the property manager was designed to handle it. Note that engines/engine[n]/ is identical to engines[0]/engine[n]/ which starts to look a bit silly again. Just my opinion. Also, could a similar thing be done with the engine output properties (mainly to drive the guages - RPM, temperature, etc.)? I can't think right now where they are at the moment. I have this vision of enabling the JSBSim piston engine and the Yasim piston engine models to be plug-in-compatible with one another. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Engine models: start-up and commonality between FDMs
I was having a look at the piston engine start-up code. I absolutely love the way it chugs away for a second or two and then coughs into life - the sound effects really make it - but I wanted to make the speeds and stuff more realistic. Looking at the JSBSim engine code, it uses lots of arbitrary speeds and time delays and abrupt transitions from one mode to another. I have some improvements to this. Much of this code in JSBSim is very similar to FDM/IO360.cxx which seems to be only used by LARCsim even though it is not in the LARCsim subdirectory; presumably one was derived from the other. I really don't like duplication; I feel that any work I do on one of them is half wasted if it isn't automatically shared by the other. And then there is Yasim's engine code. Three piston engine models, each specific to its own FDM. So I started thinking about deriving them all from a common PistonEngine interface with the aim of making the engine models interchangeable. Haven't gone anywhere down this road yet, though. Thoughts? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
Julian Foad writes: No - we have that in some places, but I was thinking recently that it's not the right way to go. I think the only practical purpose is to reduce clutter in the browser; but the property browser could and should do this for us if we want it to. It also makes life easier for programmers, since we can pass around one node containing engine settings and nothing else. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Engine models: start-up and commonality between FDMs
Julian Foad writes: Much of this code in JSBSim is very similar to FDM/IO360.cxx which seems to be only used by LARCsim even though it is not in the LARCsim subdirectory; presumably one was derived from the other. I really don't like duplication; I feel that any work I do on one of them is half wasted if it isn't automatically shared by the other. And then there is Yasim's engine code. Three piston engine models, each specific to its own FDM. So I started thinking about deriving them all from a common PistonEngine interface with the aim of making the engine models interchangeable. Haven't gone anywhere down this road yet, though. Thoughts? I like the idea as well: it would be nice if the engine were its own subsystem and we could mix-and-match engines and FDMs (let's try the J3 cub with 180HP). Unfortunately, the FDM people haven't been too enthusiastic: in particular, JSBSim is supposed to run standalone as well as inside FlightGear, so they need some kind of internal engine model. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: ANN: starting the XML GUI; early implementors needed
David Megginson writes: I've just added the ability to modify property values: we can now construct very simple dialog boxes that actually control FlightGear (the demo can control roll, pitch, and heading). More interesting stuff like pick lists, value constraints, etc. will follow. Cool you have seen $PLIB / demos / p-guide esp. LoadSave.cxx Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
David Megginson writes: Curtis L. Olson writes: Let's see, from the c172-electrical.xml I have: /systems/electrical/outputs/landing-light /systems/electrical/outputs/beacon /systems/electrical/outputs/strobe-lights /systems/electrical/outputs/taxi-lights You need to add the navigation lights (required by law at night), cabin lights, and (for some aircraft) panel lights, map light, and so on. We also have: /systems/electrical/outputs/cabin-lights /systems/electrical/outputs/map-lights /systems/electrical/outputs/instrument-lights I don't know where the navigation lights are powered from in real life. I'm guessing maybe this is the same thing as the beacon (?) I don't see a specific reference to navigation lights power in the C172 electrical diagram. There is a scary number of different permutations, even for a single C172 model -- for example, each separate gauge may or may not have its own internal light, depending on options chosen by the owner, replacements, etc. The VOR gauges seem the most likely to be separately lit. Yup, even a C172 can get fairly complex. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Parachute for C172
Christopher S Horler writes: I found a Flight International around work today when I was waiting for someone. It has an article about an emergency parachute system on some plane (I forget which), Could have been Cirrus ... they are located in Duluth (about 2 hours north of me.) and I think it said you could get them for C172's and another Cessna... So how long before I can land my fgfs C172 by parachute? That one probably won't go near the top of my personal priority list, but I have no objection to someone else working on it... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Parachute for C172
David Megginson writes: It's called the Ballistic Recovery System (BRS), and is still a little controversial. They're used mainly on ultralights (which have an unfortunate tendency to fall apart in flight), but also come standard with the Cirrus SR20 and SR22, and have been certified for use as an add-on with the C172. While the company claims hundreds of lives saved in its ads aimed at Cessna and Cirrus pilots, all of the saves were actually ultralights until a few weeks ago when a Cirrus pilot deployed the chute after losing an aileron. He lived; it's impossible to know how he would have managed without the chute, but it's worth noting that the plane was still under control when he deployed: http://www.avweb.com/newswire/news0241b.html So how long before I can land my fgfs C172 by parachute? That's what a lot of people are afraid of -- my engines running a little rough, better pull the chute. The opposite is also a problem ... pilots not pulling the chute because they think they can save the plane or successfully land it and then getting themselves hurt. I recall some time back a Cirrus pilot being critically injured and totalling his plane when he crash landed in a corn field. Made me wonder why he didn't pull the chute, but he probably thought he could save a few bucks (the parachutes are one shot only I believe) if he just glided it in. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
