Menu
▾
▴
[Flightgear-devel] a few more bugs
|
From: John D. <js...@av...> - 2008-12-25 10:54:15
|
Remark: Not all of these bug reports are orignal with me. Some
were pointed out to me off-list.
47:: c172p, dhc2, and a tiny bit of SenecaII: As of 1.9.0, apparently
neither the c172p nor the dhc2 have have an outside air temperature
gauge. An OAT gauge is factory-standard equipment for these aircraft
in the Real World, although it is apparently not absolutely mandatory
in the US. In any case, trying to fly without an OAT gauge could be
mighty unpleasant, in a wide range of practical situations, including
hot weather or cold weather, especially at night and/or IFR,
especially in mountainous terrain.
As of 1.9.0, the SW SenecaII has a 3D OAT that looks great to viewers
inside the cockpit, but mysteriously disappears when the viewer is
outside looking in.
48:: dhc2: As of 1.9.0, the mixture cannot be controlled using a
joystick. A patch is available.
49:: dhc2: As of 1.9.0, there are multiple "fuel pressure" bugs.
Example 1: no contribution from the engine-driven fuel pump; in the
Real World this would be an obvious no-go condition. Example 2:
sometimes a low fuel pressure condition can force the mixture to be
/richer/ than it otherwise should have been. Example 3: the behavior
is improperly sensitive to the frame-rate of the sim. A patch is
available.
50:: YASIM engine, as installed on the dhc2 (but not on the pa24-250):
As of 1.9.0, while cranking the starter with less than full throttle,
the MAP exhibits dramatic, unrealistic fluctuations. MAP behavior
during shutdown is also a bit odd.
51:: Radio: navcom-kx155.xml as installed in the c172p and presumably
elsewhere: As of 1.9.0, the kHz digits unrealistically "carry" into
the MHz digits.
52:: Core feature: Nav: Reversible ILS: Consider the following
scenario. In the 1.9.0 Sim World, you are on the KJFK ILS RWY 31R
approach. You are at an altitude of 180 feet, centered on the
glideslope, about 1/2 mile from touchdown, i.e. just about to cross
over RWY 22L. All indications are stable. So far so good. Then
suddenly the localizer CDI needle switches from half a dot right of
center to full-scale left of center, through no fault of your own.
Evidently, the simulator has just switched the ILS transmitter from
31R to 13L, as you can confirm by listening to the ident. It does
this every time, as a function of aircraft position.
This means that in the 1.9.0 Sim World, the KJFK ILS RWY 31R is not
flyable under low-IFR conditions. I reckon the same problem arises
at every airport where there is a reversible ILS.
This is not good.
This is an old bug.
In the Real World, the active runway is determined based on wind
conditions (etc.) and the reversible ILS is set accordingly,
independent of aircraft position.
53:: In real life, there are many circumstances where airport lights,
including approach lights, are turned on during the day. At tower
airports, the lights are turned on during conditions of low
visibility and/or low ceiling, and also turned on if requested by the
pilot. For details, see FAA Order 7110.65p.
As of 1.9.0, runway and taxiway lights are turned on during the hours
of darkness, as determined by the angle of the sun. So far so good.
As of 1.9.0, runway lights and taxiway lights are turned on
automatically if visibility less than 5000 meters, day or night.
Apparently this is based on flight visibility (not on surface
visibility as they would be in the Real World). Consequently, as the
sim descends through a haze layer into improving visibility, you can
watch the Sim World lights turn themselves off, which is dramatically
unrealistic. Also: apparently the code treats a subset of approach
lights as part of the runway lights, so that subset has the same
dependence on time-of-day and visibility. The remaining approach
lights appear to be permanently off.
As of 1.9.0, there is apparently no dependence on ceiling. For
example, under a 150ft overcast ceiling, the lights are off during
the day. This is unrealistic i.e. inconsistent with FAA Order
7110.65p.
It is important to get the lighting right, because it affects both
the legality and the practicality of performing instrument approaches
in marginal conditions.
This bug has been known for a long time.
Suggestion: (DCL? Vivian?) -- As others have suggested, it sure would
be nice to have an "AI tower" that would correctly control the airport
lighting (including pilot-controlled lighting) and correctly determine
the runway in use (for ATIS, and for the reversible ILS, et cetera).
For some users -- not all, but some -- having a properly-behaved ILS
transmitter and properly-behaved lights is far more valuable than
having an AI wingman or having an AI Local Controller generating radio
traffic.
It would be especially nice for the AI tower to make these decisions
in a way that was consistent across all aircraft in the local
multiuser environment.
Lighting control and ILS control seem like policy decisions, the sort
of policy that ought to be implemented at fairly high level. It seems
odd -- especially in a multiuser situation -- to see such policy
implemented in low-level library functions such as
simgear/scene/tgdb/GroundLightManager.cxx. If we wanted to implement
features such as pilot-controlled lighting (for non-tower airports),
what would be the right place to do it?
54:: Core feature: When flying in the pattern at KJFK, I get "nan"
messages spewed on the console. The phenomenon is not hard to
reproduce, although I can't say exactly what conditions determine
the onset or rate of spew.
CullVisitor::apply(Geode&) detected NaN,
depth=nan, center=(-0.003005 -0.005005 5.00004e-07),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}
55:: In the Real World, at large airports, the white runway lights are
highly directional, aimed along the direction of the runway. When
viewed in a direction transverse to the runway, they should be much
less bright, verging on invisibility when viewed from any appreciable
distance. As of 1.9.0, the lights (at, say, KJFK) seem to be
unrealistically omnidirectional.
|