ehofman [Sun, 7 Mar 2004 12:08:46 +0000 (12:08 +0000)]
David Culp:
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.
daveluff [Sat, 6 Mar 2004 14:44:38 +0000 (14:44 +0000)]
Start making the AI traffic robust to not getting a tower pointer from ATC. Eventually this should also lead to being able to generate AI traffic at uncontrolled airports
daveluff [Fri, 5 Mar 2004 16:24:04 +0000 (16:24 +0000)]
Use the airport elevation instead of the actual ground elevation when out of visible range of the user. This should reduce thrashing / pollution of the tile cache.
daveluff [Tue, 2 Mar 2004 10:43:16 +0000 (10:43 +0000)]
Move the mechanics of turning out of the derived classes into AIPlane. The user-visible effect is that AI planes no longer suddenly change direction without turning properly.
daveluff [Tue, 2 Mar 2004 10:37:38 +0000 (10:37 +0000)]
Don't cast string to c_str before passing to functions that take string, and remove an inadvertant push onto the airport_atc_map of data that already exists on it
curt [Sat, 28 Feb 2004 19:52:17 +0000 (19:52 +0000)]
Investigating some wierd behavior where the threaded metar fetcher would
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.
david [Fri, 27 Feb 2004 15:16:23 +0000 (15:16 +0000)]
Add the aircraft model, model manager, view manager, and scenery
manager to the standard subsystem collection manager, rather than
using extra code to initialize and update them.
ehofman [Fri, 27 Feb 2004 10:20:17 +0000 (10:20 +0000)]
David Culp:
Here's a new batch of AI code which includes a working radar instrument.
I put the radar calculations into the existing AIAircraft class. It was
easier that way, and it can always be migrated out later if we have to.
Every tenth sim cycle the AIManager makes a copy of the current user state
information. When the AIAircraft updates it uses this information to
calculate the radar numbers. It calculates:
1) bearing from user to target
2) range to target in nautical miles
3) "horizontal offset" to target. This is the angle from the nose to the
target, in degrees, from -180 to 180. This will be useful later for a HUD.
4) elevation, in degrees (vertical angle from user's position to target
position)
5) vertical offset, in degrees (this is elevation corrected for user's pitch)
6) rdot (range rate in knots, note: not working yet, so I commented it out)
and three items used by the radar instrument to place the "blip"
7) y_shift, in nautical miles
8) x_shift, in nautical miles
9) rotation, in degrees
The radar instrument uses the above three items, and applies a scale factor to
the x-shift and y-shift in order to match the instrument's scale. Changing
the display scale can be done entirely in the XML code for the instrument.
Right now it's set up only to display a 40 mile scale.
The radar is an AWACS view, which is not very realistic, but it is useful and
demonstrates the technology. With just a little more work I can get a HUD
marker. All I need to do there is make a bank angle adjustment to the
current values.
ehofman [Mon, 23 Feb 2004 20:55:07 +0000 (20:55 +0000)]
David Culp:
I went through the AI code to put the "bank" node back into the config file,
so the models can fly circles. While I was in there I made some other
changes.
*) Moved the initialization of roll, tgt-roll, pitch ... etc, from init()
into the constructor, so it wouldn't over-write the config settings.
*) Changed the altitude getter to remove the meters-to-feet conversion. The
altitude is kept internally in feet. Only the scenery code needs meters.
*) Added "bank" item for config file (for type=aircraft). Left bank is
negative.
*) Added "rudder" item for config file (for type=ship). Left rudder is
negative. Internally this is stored in the "roll" variable, but the ship
model doesn't roll. It uses the "roll" variable for turning though.
The following puts a tanker at 3000 feet, 6 nm northwest of KSFO. On takeoff,
the tanker is visible over the hanger building at one-o'clock.
curt [Mon, 23 Feb 2004 18:25:29 +0000 (18:25 +0000)]
A first stab at limiting the noaa.gov query to only valid stations. There
are many recognized limitations and inefficiencies with this entire approach,
however, it's a quick and dirty way to get something working, where before
we didn't.
ehofman [Mon, 23 Feb 2004 09:48:10 +0000 (09:48 +0000)]
Frederic Bouvier:
The last change from Curt to Airports/simple.[ch]xx made
GUI/AirportList.cxx not compilable because of the loss of
a '*' in getAirport.
Also : fabs is not defined under MSVC unless <math.h> is
included.
curt [Mon, 23 Feb 2004 01:39:12 +0000 (01:39 +0000)]
Enhance the FGMetarEnvironmentCtrl class to also do on the fly weather
updates based on the "closest" airport with metar data available. Note that
the web based query is in the main loop and causes brief sim pauses. Update
rate (once per minute) needs to be tweaked with, but is a good value for
testing.
curt [Mon, 23 Feb 2004 01:37:26 +0000 (01:37 +0000)]
Various mods to allow querying for nearest airport (with optional ability to
only query those stations with metar weather available.) Metar availability
is determined on the fly for now.
ehofman [Fri, 13 Feb 2004 12:54:38 +0000 (12:54 +0000)]
Make sure the friction forces are positive, otherwise they will push the aircraft rather than holding it into place. The ground reaction code still needs some attention.
curt [Thu, 5 Feb 2004 17:11:47 +0000 (17:11 +0000)]
Add my old ultra-simplistic PI controller. The fancy PID controller doesn't
seem to be fully deterministic in P-only mode. This old simple controller
does what I expect, so it's good for calulating stage #1's of multi-stage
controllers.
curt [Wed, 4 Feb 2004 17:10:32 +0000 (17:10 +0000)]
Cleaned up some left over stuff. Working towards infrastructure to support
adding additional PID type algorithms to the code.
Add support for calculating heading bug error relative to magnetic heading
for slaved DG's.
daveluff [Wed, 4 Feb 2004 17:00:19 +0000 (17:00 +0000)]
Make sure at least one Transform() is performed to set the model position *before* first calling DoGroundElev() in order to avoid polluting the tilemgr with bogus tiles
ehofman [Mon, 26 Jan 2004 20:33:30 +0000 (20:33 +0000)]
Alexander Nedotsukov:
I just met a couple of warnings about depricated headers beeng used.
Please take a look at patch (against today cvs) attached wich
does strstream -> stringstream migration. I hope you found it usefull.