Re: [Flightgear-devel] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
From: Curtis L. Olson [EMAIL PROTECTED] Jonathan Polley writes: MSVC does not have fmin() defined, so complains in vacuum.cxx. gcc-2.95 is also complaining about it missing. Same for MSVC 7. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RE: Electrical system
To avoid things getting very complex very quickly it might be easier to take a very simplistic apporach and model the batteries chief characteristics such as terminal voltage, and ampere/hour capacity. Since there is no such thing as a perfect power source you could go to much more detail - modelling the internal resistance of the battery and it's own capacitive and inductive load characteristics for example. But for the beginning surely we just need to know how what voltage it will supply and how much current capacity is available don't we? I think this would make it easier for situations like alternator offline or (as happened almost every flight in a C206 I know of!) the fan belt coming off mid-flight. I'm sure in these situations one would want to turn off everything but the essential items like the radio etc. - as I'm not a pilot (yet!) I don't know. Furthermore, if we need more accurate battery discharge modelling to represent the inherent voltage drop when the load approaches or exceeds the maximum the battery can supply in it's current condition we can have generic functions in code to model the behaviour and supply the values for the specific case from XML. Just my 2p worth :-) What do people think? Regards, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Caravan model
I took it upon myself to email cessna last night in the hope that they might be able to supply me with some line drawings and a few useful bits of technical data for the caravan model. I did point out that the info would be used solely for this project and as such would be re-distributed under the terms of the project. I don't expext they will want to help given that the caravan was a major selling point in their relationship with M$ for FS2002, but if you don't ask you don't get ;-) If anyone here knows of any good line drawings to help with the model I'd be most grateful. Regards, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D panel
Hmmm...I can see clearly there that culling isn't the problem. Are you having any problems with other models? BTW the offets are from the 3D Model's origin (0,0,0) which in this case is about 3 meters behind the pilot on a line that crosses the leading edge of the wings about halfway down the sweep. Thanks for the explanation. Unfortunately, after pulling recent changes from CVS this morning, the panel display turned bad as known from the last months: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_05.png http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_06.png Please note: All screenshots were taken with these settings: --disable-clouds --enable-clouds3d Martin. P.S.: I had to remove the connections to the Vacuum subsystem to get FlightGear compiled and linked correctly. You already discussed this in another thread. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3D-clouds and HUD markers
Hello, did you recognize that some markers in the HUD display disappear when 3D-clouds come in sight ? Shortly after takeoff, when looking at the clouds, I see a HUD like this: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_07.png After taking down the nose a little bit the clouds disappear and the HUD gets reappears completely: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Clouds3D_08.png 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] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
On Tue, 24 Sep 2002 03:46:54 -0400 Norman Vine [EMAIL PROTECTED] wrote: Bernie Bright writes: On Mon, 23 Sep 2002 18:51:25 -0700 Jonathan Polley [EMAIL PROTECTED] wrote: MSVC does not have fmin() defined, so complains in vacuum.cxx. gcc 2.95.3 complains too. fmin() is only defined if _ISOC99_SOURCE is defined before including math.h. I wonder if we are going to need a sg_math.h if so here is a first stab at one [cut] Well, as far as I can tell, fmin() is C99 not Std C++. We could use std::min() but that causes a problem with MSVC where you have to use cpp_min() instead. And so it goes on... Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Caravan model
Matthew Law writes: I took it upon myself to email cessna last night in the hope that they might be able to supply me with some line drawings and a few useful bits of technical data for the caravan model. I did point out that the info would be used solely for this project and as such would be re-distributed under the terms of the project. I don't expext they will want to help given that the caravan was a major selling point in their relationship with M$ for FS2002, but if you don't ask you don't get ;-) If anyone here knows of any good line drawings to help with the model I'd be most grateful. If you call Cessna and ask to order the Information Manual for a specific model/year of Caravan, they'll be happy to sell it to you (probably under USD 50.00). It will include line drawings, performance tables, system descriptions, weight and balance, and a lot of other interesting stuff. 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] MSVC 6.0 Problem with systems/vacuum/vacuum.cxx
Bernie Bright writes: Well, as far as I can tell, fmin() is C99 not Std C++. We could use std::min() but that causes a problem with MSVC where you have to use cpp_min() instead. And so it goes on... My fault -- I didn't realize that fmin() was non-ANSI. I've fixed it in the CVS (in advance of integration of Alex's vacuum model from steam.cxx). 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] 3D-clouds and HUD markers
So to reiterate what Curt This isn't quite ready for general consumption but some of us are working on it Sorry, I didn't mean to hurt anyone. I just recognized this effect and I had the desire to point at it. It's beyond my scope to realize what people are aiming to deal with, so I thought it _might_ be useful to share my discovery, 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] 3D-clouds and HUD markers
Martin Spott So to reiterate what Curt This isn't quite ready for general consumption but some of us are working on it Sorry, I didn't mean to hurt anyone. No problem, just wanted to make sure everyone realizes this is still in development :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fw: [vtp] Elevationdata of the Alps?
A source for non-US 30 meter DEM's I believe that for those areas already processed and on line these are still free. We would have to build a new DEM reader to handle these but that should not be too dificult in that they are in a 'well known' format Norman - Original Message - From: Roger James [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 7:06 AM Subject: Re: [vtp] Elevationdata of the Alps? You can view the current coverage at http://edcsgs7.cr.usgs.gov/aster/dem_map.html If it is not on this then you have to order it yourself. Expect a 9 month lead time for relative DEMs but only a few days if you can provide GCPs and request an absolute DEM. To generate the GCPs you will need the L1A dataset, this will now cost you but not a lot. Roger - Original Message - From: Peter Guth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 24, 2002 5:06 AM Subject: Re: [vtp] Elevationdata of the Alps? I am looking for 10-30m elevation data of the Alps. You could also try the ASTER DEM from NASA/USGS: http://edcdaac.usgs.gov/aster/ast14dem.html They have data worldwide, but not complete. You also have to deal with holes To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: Flightgear-devel digest, Vol 1 #1016 - 15 msgs
Matthew Law writes: Maybe we just model the general characteristics of the given type of battery usually found in that aircraft. As you quite rightly pointed out the discharge curve for most batteries can be described with quite a basic exponential function. The atmospheric conditions surrounding the battery may change it's characteristics a little but I'm sure aviation batteries are made with that in mind too. It could be that extreme cold temperatures affect the battery as well as the oil. 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] Compile Error in vacuum.cxx
Tony Peden writes: I ran into compile errors with vacuum.cxx this morning. Adding _pressure_node to the header as a member variable solved the problem. The file is attached. Apologies -- I just forgot to commit the header. It's in now. 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] Compile Error in vacuum.cxx
On Tue, 2002-09-24 at 06:10, David Megginson wrote: Tony Peden writes: I ran into compile errors with vacuum.cxx this morning. Adding _pressure_node to the header as a member variable solved the problem. The file is attached. Apologies -- I just forgot to commit the header. It's in now. Both you and Curt did it and it looks like there may be two declarations of _pressure_node now. 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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] mpe progresss
We were in a good mood today and published a snapshot of our current code. We would like it if other developers could take a look at it and see if you can compile the code and run into platform problems. We have succesfully compiled on Cygwin, Solaris (version unkown), Red Hat 7.2 (gcc 2.96 sick) and Debian (version unknown) (gcc 2.95.5). (BTW, the Makefile is NOT reliable) We are still far away from a working program, but we like hints on possible problems. Despite it is not possible to use source code created by others because that would give problems with our gradiation (this is a graduation project for us). Published stuff: - Source-code - Source-code Documentation - minor stuff Not published yet: - Background research Have fun, Leon Otte Jeroen Boogaard = OK, I admit it: My girlfriend's just an object to me. Unfortunately, there is some information hiding, but thankfully, she's fairly encapsulated, nicely modular, and has a very well defined interface! __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] mpe progresss+URL
Oops, I forgot the link: http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ Leon Otte --- ace project [EMAIL PROTECTED] wrote: Date: Tue, 24 Sep 2002 06:48:14 -0700 (PDT) From: ace project [EMAIL PROTECTED] Subject: mpe progresss To: [EMAIL PROTECTED] We were in a good mood today and published a snapshot of our current code. We would like it if other developers could take a look at it and see if you can compile the code and run into platform problems. We have succesfully compiled on Cygwin, Solaris (version unkown), Red Hat 7.2 (gcc 2.96 sick) and Debian (version unknown) (gcc 2.95.5). (BTW, the Makefile is NOT reliable) We are still far away from a working program, but we like hints on possible problems. Despite it is not possible to use source code created by others because that would give problems with our gradiation (this is a graduation project for us). Published stuff: - Source-code - Source-code Documentation - minor stuff Not published yet: - Background research Have fun, Leon Otte Jeroen Boogaard __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Canadian Airspace
I guess it's not just the US that's touchy about its airspace. I've been having fun with the new Google news search, and came up with this story: http://www.zwire.com/site/news.cfm?newsid=5443180BRD=1467PAG=461dept_id=188527rfi=6 The explanation of the problem is a little confused, though: it had nothing to do with a flight plan. In Canada, all *controlled* airspace between 12,500ft ASL and FL180 is class B, but class G airspace can also extend up to FL180. (Above FL180 is class A -- IFR-only -- as in the US). With Victor airways, control-zone extensions, etc., there's not all that much class G airspace in Southern Canada: in class B airspace ATC provides positive separation to all VFR and IFR aircraft, so the pilot needed an ATC clearance (not necessarily a flight plan) and needed to be using an encoding transponder. Understandably, ATC was a little pissed-off to have an apparently NORDO aircraft flying through its space without clearance, though having the US dispatch F-16s was probably overkill. 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] Electrical systems
Here are some ideas about modeling electrical systems that are general enough to handle most airplanes. Nice list, but the only item that is relevant for light aircraft is the bus. 2) Battery, nominally 28 Volt, which will last about 30 minutes if it is the only power source available. It is normally supplied by the battery charger, so if the charger is powered the battery is transparent. Light aircraft batteries are different; they use a contactor relay and also operate the field coil of the alternator (not generator) without going through a bus. The battery charger is (in this case) a regulator that has its own circuit breakers and has permission to damage the interior of avionics when the alternator output increases from zero to normal operating voltage. From memory, the battery is 24 volts, but the electrical bus is 28 volts when alternator is running. 3) Ground Power, supplies 115 Volt, 400 cycle AC power to a Ground Power Bus. This is plugged into the side of the airplane, and is either there or it isn't. A light in the cockpit advises if its there. Ground power on a light aircraft is the same as alternator power. 9) Bus, a simple component which only keeps a list of suppliers and a list of users. AC or DC. The biggest problem with a bus is managing the list of circuit breakers, knowing how to trip them automatically and whether the pilot can manually trip them. Some cannot be tripped manually (inconvenient). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
David Megginson writes: The AI now runs off the vacuum pump, though in a relatively simplistic way. The instrument keeps track of its spin, and will slowly spin down when there is no (or insufficient) suction available or quickly spin up when suction becomes available. The movement isn't quite right (especially the spin-up), but it is sufficient for some IFR practice. To kill the AI, either disable the gauge itself by setting /instrumentation/attitude-indicator/serviceable to false, or kill the vacuum pump by setting /systems/vacuum/serviceable. When the engine is running at under 1500RPM, the gauge will also be unreliable. Hah! That's very nasty, the AI continues to operate just fine, and then [ever so] slowly starts to drift off center, but still reacts to overall aircraft motion. I bet killing the vacuum system in a sim would be a good way to recalibrate a *lot* of pilot's egos. Wow! Good work. 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] defaults
The preferences.xml file specifies the c172 as the default. It appears that even if you request a different aircraft as the default, the c172 config files get loaded first anyway, then the alternate config file is loaded with the correct aircraft. This means that if the c172 specifies any defaults such as aileron trim that isn't specified in the desired aircraft config, it will inherit the c172 settings (i.e. they won't get overwritten, unless done so explicitely.) Is this what we want the behavior to be? I'm guessing it got this way for a reason, but I'm not sure we want things to act this way. For instance, if the default c172 has an electrical system, then the j3cub will have the same one, unless it explicitely requests a different electrical system. 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] defaults
Curtis L. Olson wwrites:
David Megginson writes:
Curtis L. Olson writes:
The preferences.xml file specifies the c172 as the default. It
appears that even if you request a different aircraft as the default,
the c172 config files get loaded first anyway, then the alternate
config file is loaded with the correct aircraft. This means that if
the c172 specifies any defaults such as aileron trim that isn't
specified in the desired aircraft config, it will inherit the c172
settings (i.e. they won't get overwritten, unless done so
explicitely.)
Is this what we want the behavior to be?
No.
Ok, good to know.
I'm guessing it got this way for a reason, but I'm not sure we want
things to act this way.
It's almost certainly an initialization-order problem. We want the
aircraft settings to take precedence over preferences.xml and the
command-line options to take precedence over the aircraft settings.
Feel free to fix it, if you can think of a way to.
I haven't actually looked into it beyond observing that an addition to
the c172-set.xml file shows up no matter what aircraft I choose. So,
I haven't dug into the code at all to see what is actually going on.
Hmm... maybe this would help
untested - but it 'looks' like this will fix 'this' problem,
don't thin it will cause any new ones
// Read in configuration (file and command line)
bool fgInitConfig ( int argc, char **argv ) {
// First, set some sane default values
fgSetDefaults();
// Read global preferences from $FG_ROOT/preferences.xml
SGPath props_path(globals-get_fg_root());
props_path.append(preferences.xml);
SG_LOG(SG_INPUT, SG_INFO, Reading global preferences);
readProperties(props_path.str(), globals-get_props());
SG_LOG(SG_INPUT, SG_INFO, Finished Reading global preferences);
// Attempt to locate and parse the various config files in order
// from least precidence to greatest precidence
// Check for $fg_root/system.fgfsrc
SGPath config( globals-get_fg_root() );
config.append( system.fgfsrc );
fgParseOptions(config.str());
#if defined( unix ) || defined( __CYGWIN__ )
char name[256];
// Check for $fg_root/system.fgfsrc.hostname
gethostname( name, 256 );
config.concat( . );
config.concat( name );
fgParseOptions(config.str());
#endif
// Check for ~/.fgfsrc
char* envp = ::getenv( HOME );
if ( envp != NULL ) {
config.set( envp );
config.append( .fgfsrc );
fgParseOptions(config.str());
}
#if defined( unix ) || defined( __CYGWIN__ )
// Check for ~/.fgfsrc.hostname
gethostname( name, 256 );
config.concat( . );
config.concat( name );
fgParseOptions(config.str());
#endif
// Parse remaining command line options
// These will override anything specified in a config file
fgParseArgs(argc, argv);
// Read the default aircraft config file.
string aircraft = fgGetString(/sim/aircraft, );
if (aircraft.size() 0) {
SGPath aircraft_path(globals-get_fg_root());
aircraft_path.append(Aircraft);
aircraft_path.append(aircraft);
aircraft_path.concat(-set.xml);
SG_LOG(SG_INPUT, SG_INFO, Reading default aircraft: aircraft
from aircraft_path.str());
try {
readProperties(aircraft_path.str(), globals-get_props());
} catch (const sg_exception e) {
string message = Error reading default aircraft: ;
message += e.getFormattedMessage();
SG_LOG(SG_INPUT, SG_ALERT, message);
exit(2);
}
} else {
SG_LOG(SG_INPUT, SG_ALERT, No default aircraft specified);
}
return true;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
[1] The standard T instruments on the panel are the top 3 directly in front of you (airspeed, AI, altimeter), and the middle instrument of the bottom 3 (DG). Before non-pilots get confused, there are many different scan patterns and rules to define when you switch between them to maintain safety. They all work, but they're different even though they're equivalent. The only danger is to use one of the wrong patterns for a given situation. I was trained on the ^ * O V series of scans. The V is different yet equivalent to the T in terms of its operational purpose and use. It is usually used when in smooth air and straight and level cruise with nothing much going on ... your main concern is detecting a failure. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
Alex Perry writes: I was trained on the ^ * O V series of scans. The V is different yet equivalent to the T in terms of its operational purpose and use. It is usually used when in smooth air and straight and level cruise with nothing much going on ... your main concern is detecting a failure. For the PPL in Canada (and the US too, I assume) we have 5 hours of very basic instrument flight under the hood, together with an hour or so of ground briefing -- essentially, it's supposed to be enough to let us turn around and get back out of a cloud, though I don't know if the statistics show any benefit. In the ground briefing, my instructor emphasised thinking practically about what instruments matter in different situations: straight flight, a climb or descent, a turn, and a climbing or descending turn, and always then starting from the AI (or TC) and then moving out to those instruments, with less-frequent cross-checks on the others. Obviously, that would not be suitable for prolonged instrument flight, but it probably makes sense for VFR pilots who wouldn't have constant practice to help reinforce more formal scanning patterns. 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] AI vacuum failure
Very nice. The DG doesn't appear to slow down and stop, though. Can we please dump the code from Steam to eliminate duplication ? Thank you. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour
This is why I carry 2 instrument covers in my flight bag.. I tried out a 3 axis sim at the AOPA Single Pilot IFR seminar here in Chicago about a month ago. I was flying along just fine until in the dark in IMC the instructor took away my vacumm system. I noticed about 30 seconds after it happened and proceded to correct, but I had the hardest time not doing what the AI showed me. It was stuck in a 20 degree bank to the left and I continued to keep trying to correct that horizon.. now if this ever happens to me in IMC in real life, I will just cover up the instrument(s) and continue to work with what I have left. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Perry Sent: Tuesday, September 24, 2002 2:08 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New Attitude Indicator (Artificial Horizon) Behaviour Hah! That's very nasty, the AI continues to operate just fine, and then [ever so] slowly starts to drift off center, but still reacts to overall aircraft motion. There are many different failure modes, that is one of them. That's what happened when I had a bearing failure (VMC). On another VMC vacuum failure, the AI simply stopped moving and continued to show straight and level irrespective of what I did. Since I was in completely smooth air, there was no indication of the failure until I tried to turn intentionally to a new heading. I was using an external horizon while VMC; had I flown into a cloud on an IFR clearance after the failure, imagine my sudden surprise ... I bet killing the vacuum system in a sim would be a good way to recalibrate a *lot* of pilot's egos. The alternative is to recalibrate their bodily shape in a real aircraft. In real IFR it's deadly, because as you bank to keep the AI centred, you gradually put the plane into a spiral. If you happen to notice the increasing airspeed, decreasing altitude, or divergent TC reading Many pilots get lazy in cruise and stop doing a proper scan. In consequence, they don't notice the subtle symptoms in time. (or glance at the vacuum pump) before you pass Vne, you might recover in time. After that, though, you'll be dizzy, confused, and badly disoriented, but will now have to fly IFR using the TC until you get the plane on the ground, praying not to get an electrical failure before then. Recently, I had a simultaneous failure of the TC and the DG, thankfully in VMC but under a real IFR clearance. It is incredibly hard to maintain IFR tolerances under those conditions and the incorrect instrument indications wasted about a third of my concentration by the distraction. I could have covered them up, using my instructor safety pilot's plastic disks. This was practice for a solo cross country and I'd forgotten to bring my own along so we completed the flight the way I'd have had to do it for-real. Had that happened in IMC, I'd have declared the emergency and required vectors to the FAF of the closest ILS. I had no redundancy remaining. Now perhaps someone can remind me why I want to get an instrument rating ... Because, without that training, if the same thing happens in a night or on-top or between-layers flight, you're basically beyond help. I should also point out that, visibility 3SM in haze at 9500 ft is quite legal and occurs regularly in some places. However, you're two miles above terrain, so your horizon is almost directly below you with a tiny circle of visible ground. You may be navigating and separating visually, but the instruments are not optional. Thanks. I'm looking forward to input from Alex and other IFR pilots on how I can make the behaviour more realistic. I'll play with it this evening, time and compiler permitting. I noticed that FGFS refused to build, as of 8am pacific this morning. ___ 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
