system. A chap from Germany called Alexander Kappes (cc'd) got
in touch with me a few weeks ago and has written the start of
Approach control. At the moment tuning in to a valid approach
frequency (Dortmund or East Midlands) should result in vectors to
a spot about 3 miles from the active runway, and a telling off if you
stray too far from the correct course, in the console window. He
seems to know what he's doing so expect this to improve rapidly!!
I've added a rudimentry AI manager and a hardwired Cessna at
KEMT on the runway - I'll remove it before the next release if I don't
have it flying by then. There seems to be an issue with framerate
which drops alarmingly when looking at it - I've a feeling that I've
possibly created several Cessnas on top of each other, but am not
sure.
* src/ATC/atislist.cxx
Patch from Melchior Franz:
- merged the _MWERKS_ & generic #ifdef branch, only the loop head needs
different treatment
- commented out a "n >> skipeol" that is used in navlist.cxx to gobble
the starting C++-style comment from default.nav.gz; atis inherited
that, but there is no such comment in default.atis.gz, so the first
data entry got thrown away
- commented out min/max frequency exploration (-> only for debugging)
- enhanced the constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.atis.gz entry, so we would have
got a mixture of the broken one and the previous one;
- move the automatic FGATIS variable into the loop, so that it gets
cleanly constructed for every database entry.
- don't access a.type before it is initialized
- updated the commented out debug output statements; they were still
designed for the FGNav class ...
subsystem to Flightgear. No more functionality is implemented
than at present (apart from an ATIS bug-fix - station wouldn't
change if the radio was switched directly from one station to
another) but it is much neater than the current hack and should be
easily extendable.
Some cruft is still probably left over in radiostack.[ch]xx such as
the bindings to the comm frequencies but I'll leave removing those
until I'm sure they're not needed there.
properties have been renamed from wind-(north|east|down)-fps to
wind-from-(north|east|down)-fps, and the FDMs modified appropriately.
No other changes should be visible unless FG_OLD_WEATHER is defined.
are being driven from an external data source.)
Akso found and fixed a bug in the simgear that caused the time to go goofy
temporarily while scenery was being loaded.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
Here's an unusual patch for FlightGear -- I've created .cvsignore
files for every source directory, to make CVS output more informative.
This is especially nice when using cvs-examine from (X)Emacs to look
for changes.
(the global temperature property returns that at the aircrafts altitude) and
adding "information" to the airport name to avoid having to store it
in the default.atis file 1200 odd times.
Heres an update to the ATIS stuff. In brief:
The possible buffer overflow in the display with wind should
hopefully be fixed.
Temperature is taken from the global temperature property instead
of being hardwired.
The display class now includes an implementation of the member
function to change the repeating message.
The message callsign is no longer hardwired. The first message
from each station is generated with a random callsign.
Subsequent messages from the same station have the callsign
incremented every hour. A map of airport-id vs. last callsign and
transmission time is kept for each station that has transmitted for
the duration of the FlightGear session. The logic might be flaky if
FlightGear is run for more than 24 hours at a stretch between
visiting the same ATIS station though! (ie I don't check the day.)
This map is kept in the atislist class. This might not be the best
long-term place for it (in an ATC class of some sort might be
better), but it works for now.