This patch is for windows only. It hides the console window
until there is a message to print. It only support SG_LOG,
that I think is the right way to display something in FG.
Add FGPredictor class to xmlauto. Add support for horizontal navigation based
on flight track as opposed to heading. Add crosstrack-error support to nav.
Simplify error adjust calculation for horizontal nav (better interception).
Fixed potential divide by zero that was producing nan issues in the xmlauto
code.
I made some changes to current CVS :
- the window is gently resizable, keeping the buttons' height
unchanged, with a minimun size,
- the current activity ( installation or removal ) is displayed
in the progress bar,
- the progress status is exact. For installation, I am
using the total bytes read vs the file size. I had to hack
untarka somehow and bzip2 and Z methods needs to be implemented.
For removal, I am counting files by in-depth traversal, in the
same way remove_dir is working. This seems very quick and
the overhead is unnoticable.
- the Quit button is the only way to quit the program, and it is
deactivated during work. Otherwise, we can get the window hidden
but the program still running in background.
- cleanup on start options that seemed to be copied from fgrun.
Valid options are now :
--silent
to write fgadmin.prefs and stop immediately
--install-source=<DIR>
--scenery-dest=<DIR>
I've done som more work on the gps instrument.
- You can now input airport-, nav- or fix-ID to select a waypoint.
- You have to specify either "airport", "nav" or "fix" in the waypoint-type
property (some fixes and navs have identical IDs).
- Formatted the time to waypoint output.
- Cleaned up and changed some propery names (wp-heading -> wp-bearing).
- I've also added a name member to the FGNav class so that the gps instrument
can get the name of the nav.
- Changed the airport name parsing in simple.cxx.
I've done some changes to xmlauto.cxx.
Only calculate the derivate filtering if derivate time Td is greater than
zero. This means that one can set Td=0.0 in the xml file to completely remove
the derivate action. (Setting Td to zero in the current version would lead to
a division by zero and crash.)
Setting the integrator time Ti to zero doesn't make sense, right! I've
modified so that setting Ti to zero results in the integral action being
completely removed.
null space without killing the engine (hardware specific problem.)
- NMEA output: I'm slightly confused but it appears that a real GPS outputs
traditional unix line endings on it's gps strings, we were outputing DOS
CR/LF which was causing some confusion. This changes the line ending
convention to match that of a real gps.
- Calculate true ground track and speed for NMEA.
explicitely. This value has always been feet, but there were a couple places
in the code that assumed this elevation was meters. The result was that you
could park directly over the top of the Black Forest VOR (112.50) NE of KCOS
and get a dme reading of 2.5 or so. This problem is now resolved.
I added some things to the AI stuff to improve the AIThermal processing.
Before, all the thermals were processed in order, and the last one overwrote
the prior one. Now, only the data from the nearest thermal is kept. This
way a tile can be populated with many thermals, and (as long as they have the
same diameter) the one nearest the airplane correctly takes effect. This
will make us ready for the next step, "auto-thermaling", where FlightGear's
tile manager can cover a tile with thermals, and set the thermal strength
based on land-use type.
I moved the enumerated object_type to the base class. When an AI object is
created it now sets the _otype variable in the base class. This lets the AI
manager find out what kind of AI object it is dealing with, using the base
pointer. I also added a function isa() to the base class, so the manager can
process objects differently based on their type.
The AI manager now sends AIThermal processing to a different function, where
only the data from the nearest thermal is kept. After the manager processes
all the AI objects, then the results from the nearest thermal are applied to
wind-from-down.
occasionally cause a large number of valid stations to be flagged as invalid.
This *seemed* like a "race condition" type problem because there were some
assumptions in the communication between the main process and the threaded
loader which if they broke down could lead to this problem.
In the process of removing this ambiguity, I restructured the threaded
(and non-threaded) metar fetching code a bit. Some of the top level logic
(which Erik politely left untouched) didn't make nearly as much sense in the
context of a threaded metar loader and could have contributed to some of the
wierdness I was seeing.
