A few minutes ago, I explained how in environment.cxx,
the model of the atmosphere could be extended up above
100,000 feet.
Everything I said was true, but it was not the whole
story.
As I have pointed out previously, the model of the
atmosphere in environment.cxx is bogus. By that I
mean it contravenes the laws of physics.
The problems are *not* noticeable if you confine your
flying to
-- sea-level airports, and/or
-- ISA standard-day conditions of temperature and
barometric pressure.
Meanwhile, I continue to try to make FlightGear usable
as a procedures trainer. In particular, consider the
following small scenario:
-- You are approaching an airport situated thousands
of feet above sea level.
-- There is non-ISA barometric pressure, even at nearby
sea-level locations.
-- There is non-ISA temperature.
-- On approach, you tune up the AWOS (not ATIS)
to get the relevant QNH i.e. "altimeter setting".
-- Upon landing, you find that your altimeter
agrees with field elevation, because the model
of the air-column is correct, the altimeter is
correct, and the ATIS algorithm is correct.
Relative to the current CVS FG, this requires major
modifications to several modules, including (but
definitely not limited to) Environment/environment.cxx,
Airports/apt_loader.cxx, and ATC/*.cxx, especially
ATC/atis.cxx. (I fixed the altimeter months ago, and
this is reflected in the current CVS.)
If you want to have all these features, the easiest way is
to pull down a copy of the _Sport Model_ of FG. (For details
on this, see the "git" section, below. This is not meant to
be a fork, as explained below.)
Here is a partial list of the features current available
in the _Sport Model_.
1:: Gremlins cause instruments and systems to fail at random times.
The pilot gets to choose the MTBF.
2:: On the HSI, the heading card stops turning when "directional
gyro" is not serviceable. (This is the hsi as used in the c182
and many other light aircraft.)
3:: On the HSI, the GS needle goes to the top (not the middle) when not
serviceable. The previous behavior was a pilot-killer.
4:: On the HSI, the GS needle shows a flag (barber pole) when not
serviceable.
The previous behavior was a pilot-killer.
5:: On the HSI, the CDI needle shows a flag when not serviceable. The
previous
behavior was a pilot-killer.
6:: On the plain Nav head, the GS needle shows a flag when not
serviceable. The previous behavior was a pilot-killer.
7:: On the plain Nav, the head CDI needle shows a flag when not
serviceable. The previous behavior was a pilot-killer.
8:: AWOS is available at AWOS locations. (Previously only ATIS was
implemented.)
9:: ATIS phraseology now more nearly conforms to international standard METAR
pattern, and therefore to usual FAA practice.(*)
Items marked with a (*) are fully implemented in the /text/ of the
ATIS message, but the voiced version of the message is degraded by
limitations of the FGFS built-in text-to-speech system.
10:: ATIS now reports sky condition.(*)
11:: ATIS now reports multiple layers of clouds, not just the lowest
layer.(*)
12:: ATIS now takes field elevation into account when calculating sky
condition
and ceiling.
13:: ATIS now reports dewpoint.(*)
14:: ATIS now can handle negative quantities (temperature and dewpoint).(*)
15:: ATIS can now report report fractional-mile visibility.(*)
16:: ATIS now uses magnetic (not true) wind directions, as it should.
17:: ATIS generates correct runway number and suffix (nine right, one one
left).
18:: ATIS can be received on nav frequencies, not just comm.
19:: Nothing bad happens if the same ATIS is tuned up on more than
one receiver.
20:: ATIS can be updated at times other than at the top of the hour.
21:: ATIS listens for an "attention" signal, and responds changes in
the weather by issuing a new ATIS message (somewhat like a "special
observation").
22:: ATIS volume now responds to radio volume setting.
23:: Area-related services (i.e. approach radar) are handled more-nearly
consistently with radio-frequency related services.
24:: ATIS sequence-letter generation has been fixed.
25:: ATIS messages are now in the property tree, so they can be read
e.g. via the http interface.
26:: The "clock" in the panel (as used in the default C172 and many
other GA aircraft) can now be used as a resettable timer. Among
other uses, this is useful for timing approaches.
27:: In the ambient pressure profile (which is the basis of aircraft
altimetry), non-ISA temperature and pressure are supported, as
required by the laws of physics.
28:: The altimeter now works up to much higher altitudes.
29:: Many enhancements to the X52 joystick interface. See
Docs/README.X52
30:: The location-in-air popup can now be used without trashing your
settings. (Previously it trashed elevator trim, aileron trim,
elevator trim, rudder trim, view angles, PoV position, landing
gear, throttle setting, and who-knows-what-all else.) See
README.location-in-air
31:: Since navaid 3-letter IDs are not unique, the navaid finder
(used for initial positioning, as well as for location-in-air)
will take you to the /nearest/ one, not some random one.
32:: Navaid names may now be entered without regard to upper case
or lower case.
33:: The system implements more-realistic navaid service volumes,
including expanded localizer volumes at selected stations.
34:: The system implements false localizer courses abeam the
antenna, as there are in real life.
35:: There is a popup to show the position of flight controls and
trim. This is a workaround for use in the many aircraft that
still lack usable trim indicators.
=========================
The remaining items are more of interest to programmers than to
pilots:
36:: The --prop command-line option now defaults to giving things
UNSPECIFIED type, not string type, so that the type can later be
changed (once).
37:: Some ATIS-related memory leaks have been fixed.
38:: ATCmgr and the associated data structures have been reorganized
so that
-- we can have some number of radios other than 2
-- information needed by ATC objects is stored where it is needed
(in the objects) rather than in useless arrays in ATCmgr.
39:: The code in ATCmgr has been made much shorter and more regular.
40:: We use calculated (not guessed) length for some buffers. Use
automatic variables rather than "new" and "delete".
41:: Fix some thread-unsafe code.
#################################################################
Git-related suggestions:
For quite a while I've been using git to keep track of FlightGear
files. Using git instead of CVS is like having a sports car instead
of a skateboard.
Git is super-convenient for testing and for experimenting with
things. You can very cheaply start a new branch, play around on
that branch, compare files against the corresponding files on other
branches ... and then reset the branch (or throw it away entirely)
if you decide you don't like where it has gone.
Git implements a truly distributed development model. Everything,
including the "repository", is fully distributed; your copy of the
history is provably equivalent to my copy of the history.
This stands in contrast to CVS, which permits concurrent
development, but not really distributed development, because
distributors are at the mercy of the single centralized
repository.
Git also features the notion of committing a group of files all at
once, which is a much more logical way to think about things.
This is in contrast to the CVS notion of committing files one by
one.
If you want to go try this, the work required to get started will be
greatly lessened if you download the git repositories in their
already-packed form. The FlightGear "source" tree is available via
the commands
mkdir $top/fgs
cd $top/fgs
git-init
time git-pull http://www.av8n.com/repo/fgs/.git origin:origin
## less than a minute
time git-pull http://www.av8n.com/repo/fgs/.git sport:sport
## even less
git branch ## take a look
git checkout sport
git checkout -b myversion ## or whatever you want to call it
edit...as...desired
time ./autogen.sh
./configure
time make
What you have at this point in the "origin" branch is conceptually
equivalent to not just the current CVS version, but also every
previous version of every file, immediately available for your use
if/when you want them. This includes all log messages. Use
git checkout origin
git log
to see what I mean.
Meanwhile, in the "sport" branch, you have all the modifications
I've made, including the ATIS and AWOS features among others. Use
git checkout sport
git log
to see what is in that branch.
The same procedure used for the "source" tree works for the "data" tree:
mkdir $top/fgd
cd $top/fgd
time git-pull http://www.av8n.com/repo/fgd/.git origin:origin
## 600 megabytes of network traffic, expands to 1.5 gigs on disk
time git-pull http://www.av8n.com/repo/fgd/.git sport:sport
## incrementally almost nothing
git checkout sport
git checkout -b myversion ## or whatever you want to call it
For more info on how to use git, see
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
http://git.or.cz/gitwiki
http://git.or.cz/gitwiki/GitFaq
###################
Notes:
1) Every so often, I import changes so that the "origin" branch
exactly tracks the current CVS.
2) I then pull changes from the "origin" branch into the "sport"
branch, so that it gets the new features also. The idea is *not*
to have a fork, where each branch has some features that the other
lacks. The idea is for the Sport Model to be an extension (not a
fork) of the CVS version.
While sitting on the sport branch (or any other branch) you can
do "git diff origin --" to see exactly how this branch differs
From the origin. (More generally: I find git diff to be
wonderfully useful.)
3) A standard recommendation is that you not edit the origin branch
or the sport branch; leave them to be updated by git-pull and only
git-pull. Start your own branch, and do your editing there. (You
can easily pull in updates from other branches whenever you want.)
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
