I quote from
http://www.av8n.com/fly/fgfs/htm/bug-list.htm
80:: As of mid-January 2008, there is a “new” version of
FGPiston.cpp floating around. It has not yet been committed to
FlightGear CVS. It gets rid of the specific problems mentioned in bug
79, replacing them with new and different unrealistic behaviors.
For one thing, it causes many FG aircraft – including the c172p – to
idle at very low revs, or stall completely.
It is not realistic at high throttle settings either. In the FG
"flagship" c172p for example, on the runway at KSFO, full throttle,
standard say, it develops 1205368 ft density altitude, standard day,
full throttle, it develops 104
Unlike the “old” version mentioned in bug 79, the “new” version
pretends to model the physics of the throttle. Alas, it is a very
thin pretense. It uses physicsy-sounding words like ThrottleAngle and
throttle_area, but these are only words. The code that computes them
bears no discernible relationship to real physics. This is
particularly odd, since the physics was worked out some time ago and
shows remarkably good agreement between the model and Real World
data. This is explained at ../../engine.htm.
Code to implement a reasonable physics-based throttle model exists.
It does not fix all the bugs in FGPiston.cpp, but it is a step in the
right direction.
81:: The FlightGear interface to the festival text-to-speech
server is documented in section 5.6.2 of the getstart manual. I
observe that it doesn’t work (even though the festival server itself
works fine when FG is not running). It hasn’t worked for years. I
have never heard of anyone actually using it.
The TTS idea would be a lot more useful if it were integrated via the
c++ API as documented at
http://www.speech.cs.cmu.edu/festival/manual-1.4.1/festival_28.html
82:: Choppy video and sound. I observe that things work fine when
the FlightGear window is the default size, 800x600. The frame rate is
in the range 45 to 50. However, if I enlarge the window even
slightly, e.g. 1000x750, things go to pot. The reported frame rate
(as given by the orange number in the lower-right corner) drops to
around 30, which wouldn’t be so bad except that the actual frame rate
drops to around 5. That is to say, the video becomes horribly choppy.
The sound also becomes horribly choppy, to the point where the ATIS
and IDENT features are unusable.
No error messages, no warnings, just choppy video and sound.
I observe that things work much better using the command-line option
–prop:/sim/frame-rate-throttle-hz=30.
This is observed using an ATI RV350 [Mobility Radeon 9600] and the
proprietary fglrx driver. (The last time I checked, the xorg radeon
driver was not an option, since it lacked some required
capabilities.)
83:: The Environment system is in need of some TLC.
For one thing, FlightGear appears to have several different models of
the atmosphere.
0) The FDM has its own model, but this is sometimes turned off and
the FDM is slaved to the FG model, so maybe this one shouldn’t even
count.
1) The popup GUI has its own model of the atmosphere. It is a very
complicated model with approximately seven layers just within the
troposphere. This GUI has been used, with some success, to specify
multiple layers of clouds. However, the GUI imparts the distinct
impression that users can independently set the temperature and
pressure in each layer, which is a wild violation of the laws of
physics.
The backend performs complex calculations based on the pressure and
temperature numbers provided by the GUI, but this is all in vain. The
results of almost all these calculations are ignored.
2) There also exists an inchoate "METAR" interface. The relationship
between this and the popup GUI is complex and buggy.
This holds out some hope of a future interface that makes sense, i.e.
multiple layers of clouds plus a two-parameter model of the
atmosphere.
3) The code that calculates the actual static pressure seen by the
airplane ignores almost all of the many numbers provided by the GUI.
I can’t decide whether this is one-parameter model or a two-parameter
model. It purports to be a two-parameter model, but it ignores one of
them. Specifically, it ignores the temperature when calculating the
pressure-versus-height profile, in defiance of the laws of physics.
This is a bug.
This model is tabulated, and ends abruptly at around 100,000 feet.
Some modelers find this limitation to be a problem.
What’s more, it takes the “zero AGL” number from the GUI and uses it
as if it were the “zero MSL” number. This is another bug.
4) The altimeter has its own model. This is a highly accurate
algebraic (not tabulated) model. It is currently valid to the top of
the stratosphere, but could easily be extended to the top of the
mesosphere. (A patch to do this exists.)
Code exists to provide FlightGear with a highly accurate
two-parameter model of the atmosphere, valid up to 262,467 feet, i.e.
80 kilometers, i.e. the top of the mesosphere. This gets rid of
several bugs in the current model. It uses the same code as the
current altimeter.
========================
For additional details and context, see
http://www.av8n.com/fly/fgfs/htm/bug-list.htm
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
