fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/AIModel/AIManager.hxx

160 lines
5.8 KiB
C++
Raw Normal View History

Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
// AIManager.hxx - experimental! - David Culp - based on:
// AIMgr.hxx - definition of FGAIMgr
// - a global management class for FlightGear generated AI traffic
//
// Written by David Luff, started March 2002.
//
// Copyright (C) 2002 David C Luff - david.luff@nottingham.ac.uk
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#ifndef _FG_AIMANAGER_HXX
#define _FG_AIMANAGER_HXX
#include <simgear/structure/subsystem_mgr.hxx>
#include <Main/fg_props.hxx>
#include <list>
#include "AIBase.hxx"
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
#include "AIScenario.hxx"
#include "AIFlightPlan.hxx"
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
SG_USING_STD(list);
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.
2004-03-07 12:08:46 +00:00
class FGAIThermal;
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
class FGAIManager : public SGSubsystem
{
private:
// A list of pointers to AI objects
typedef list <FGAIBase*> ai_list_type;
typedef ai_list_type::iterator ai_list_iterator;
typedef ai_list_type::const_iterator ai_list_const_iterator;
// Everything put in this list should be created dynamically
// on the heap and ***DELETED WHEN REMOVED!!!!!***
ai_list_type ai_list;
ai_list_iterator ai_list_itr;
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.
2004-02-27 10:20:17 +00:00
// array of already-assigned ID's
typedef vector <int> id_vector_type;
id_vector_type ids;
id_vector_type::iterator id_itr;
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
public:
FGAIManager();
~FGAIManager();
void init();
void bind();
void unbind();
void update(double dt);
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.
2004-02-27 10:20:17 +00:00
int assignID();
void freeID(int ID);
int createAircraft( string model_class, // see FGAIAircraft.hxx for possible classes
string path, // path to exterior model
double latitude, // in degrees -90 to 90
double longitude, // in degrees -180 to 180
double altitude, // in feet
double heading, // true heading in degrees
double speed, // in knots true airspeed (KTAS)
double roll = 0 ); // in degrees
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
int createAircraft( string model_class, // see FGAIAircraft.hxx for possible classes
string path, // path to exterior model
FGAIFlightPlan *flightplan );
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.
2004-02-27 10:20:17 +00:00
int createShip( string path, // path to exterior model
double latitude, // in degrees -90 to 90
double longitude, // in degrees -180 to 180
double altitude, // in feet (ex. for a lake!)
double heading, // true heading in degrees
double speed, // in knots true
David Culp: Here's some new AI stuff. 1) AI objects must now be defined in a scenario file, not in preferences.xml or a *-set file. (Of course this doesn't prevent objects from being created dynamically, as with Durk's traffic manager). 2) A new demo_scenario file is attached. It creates 3 aircraft, a sailboat, and a thunderstorm. 3) Objects without flightplans live forever. 4) FGAIShip::ProcessFlightplan() is not yet implemented. 5) preferences.xml should now define only <enabled> and <scenario>
2004-05-29 11:39:10 +00:00
double rudder ); // in degrees (right is positive)(0 to 5 works best)
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.
2004-02-27 10:20:17 +00:00
David Culp: Here's some new AI stuff. 1) AI objects must now be defined in a scenario file, not in preferences.xml or a *-set file. (Of course this doesn't prevent objects from being created dynamically, as with Durk's traffic manager). 2) A new demo_scenario file is attached. It creates 3 aircraft, a sailboat, and a thunderstorm. 3) Objects without flightplans live forever. 4) FGAIShip::ProcessFlightplan() is not yet implemented. 5) preferences.xml should now define only <enabled> and <scenario>
2004-05-29 11:39:10 +00:00
int createShip( string path, // path to exterior model
FGAIFlightPlan *flightplan );
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.
2004-02-27 10:20:17 +00:00
int createBallistic( string path, // path to exterior model
double latitude, // in degrees -90 to 90
double longitude, // in degrees -180 to 180
double altitude, // in feet
double azimuth, // in degrees (same as heading)
double elevation, // in degrees (same as pitch)
David Culp: Silly me. I was starting the timer at zero, so the first tracer didn't fly until 0.25 seconds after pulling the trigger. Now the timer starts at the same value as "delay", so the first round comes out immediately. Also, I've added an optional configuration attribute that allows you to change the ballistics of the submodel. This allows parachutes, or anything else that has ballistics different from a bullet. The attribute is called "eda", which is the equivalent drag area. Default value is 0.007, which gives the same ballistics as the current tracers. Increasing this value gives more drag. A value of 2.0 looks good for a parachute. math stuff ######################################################################## The deceleration of the ballictic object is now given by: [ (rho) (Cd) ] / [ (1/2) (m) ] * A * (V * V) where rho is sea-level air density, and Cd and m are fixed, bullet-like values. So the calculation is: 0.0116918 * A * (V * V) The value "A" is what I'm calling the "eda" (equivalent drag area). ######################################################################## A parachute model will have to be built so that the parachutist's feet are in the forward x-direction. Here is the submodel.xml config I use for "parachutes": <submodel> <name>flares</name> <model>Models/Geometry/flare.ac</model> <trigger>systems/submodels/submodel[0]/trigger</trigger> <speed>0.0</speed> <repeat>true</repeat> <delay>0.85</delay> <count>4</count> <x-offset>0.0</x-offset> <y-offset>0.0</y-offset> <z-offset>-4.0</z-offset> <yaw-offset>0.0</yaw-offset> <pitch-offset>0.0</pitch-offset> <eda>2.0</eda> </submodel>
2004-08-26 16:25:54 +00:00
double speed, // in feet per second
David Culp: Here are small changes that allow one to set a life-span for submodels.
2004-08-30 09:11:59 +00:00
double eda, // equivalent drag area, ft2
Vivian Meazza: Attached are the modified files to add buoyancy as a parameter for a ballistic object. It may be set by adding <buoyancy>x</buoyancy> to the submodel .xml file, where x is the appropriate value (ft per sec2): 32 neutral buoyancy - contrails >32 positive buoyancy - exhaust plumes (0 non-op - default value) If <buoyancy>x</buoyancy> is not used, then there is no effect on the current ballistic model
2004-09-01 08:32:54 +00:00
double life, // life span in seconds
double buoyancy // acceleration in ft per second2
);
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
int createStorm( string path, // path to exterior model
double latitude, // in degrees -90 to 90
double longitude, // in degrees -180 to 180
double altitude, // in feet
double heading, // true heading in degrees
double speed ); // in knots true airspeed (KTAS)
int createThermal( double latitude, // in degrees -90 to 90
double longitude, // in degrees -180 to 180
double strength, // in feet per second
double diameter ); // in feet
Vivian Meazza: Attached are the modified files to add buoyancy as a parameter for a ballistic object. It may be set by adding <buoyancy>x</buoyancy> to the submodel .xml file, where x is the appropriate value (ft per sec2): 32 neutral buoyancy - contrails >32 positive buoyancy - exhaust plumes (0 non-op - default value) If <buoyancy>x</buoyancy> is not used, then there is no effect on the current ballistic model
2004-09-01 08:32:54 +00:00
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.
2004-02-27 10:20:17 +00:00
void destroyObject( int ID );
inline double get_user_latitude() { return user_latitude; }
inline double get_user_longitude() { return user_longitude; }
inline double get_user_altitude() { return user_altitude; }
inline double get_user_heading() { return user_heading; }
inline double get_user_pitch() { return user_pitch; }
inline double get_user_yaw() { return user_yaw; }
inline double get_user_speed() {return user_speed; }
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
void processScenario( string filename );
David Culp: 1. Removed aircraft roll on ground. 2. Decreased descent pitch angle. 3. Updated flightplans to include <on-ground> 4. Fixed property indexing, so all AI aircraft have their own property branch The default value of <on-ground> is false, so you only need to specify it when on the ground. For takeoff you need to specify <on-ground>true</on-ground> for the first waypoint, and for the acceleration waypoint. For landing you need to specify it for the touchdown point and any taxi points. One problem. WARNING **** There is a bug in the way the property system works, which causes a segfault, but I don't know if the problem is in the property code, or in how I'm using it. After an AI object terminates, if you access the property tree through the property browser the sim will segfault.
2004-05-21 16:50:19 +00:00
int getNum( FGAIBase::object_type ot);
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
private:
bool initDone;
Add AI models enableing/disableing command line option and support code.
2004-05-19 13:55:49 +00:00
bool enabled;
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.
2004-02-27 10:20:17 +00:00
int numObjects;
SGPropertyNode* root;
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.
2004-03-07 12:08:46 +00:00
SGPropertyNode* wind_from_down;
David Culp: First, preferences.xml will define the scenario filename. For now, the other way of defining ai objects still works, so the sailboat stays in preferences.xml. Later, I'll move the sailboat into the demo scenario. If no scenario filename is given, then no scenario will be processed. I changed the demo scenario to create two 737's, one takes off on runway 01L, and the other takes off on runway 01R. This will make a good demo for the ai system. One problem, if you takeoff on 28L/R right away, you might run into the taking-off 737's, or be scared.
2004-05-17 08:45:33 +00:00
string scenario_filename;
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.
2004-02-27 10:20:17 +00:00
double user_latitude;
double user_longitude;
double user_altitude;
double user_heading;
double user_pitch;
double user_yaw;
double user_speed;
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.
2004-03-07 12:08:46 +00:00
double _dt;
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.
2004-02-27 10:20:17 +00:00
int dt_count;
void fetchUserState( void );
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
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.
2004-03-07 12:08:46 +00:00
// used by thermals
double range_nearest;
double strength;
void processThermal( FGAIThermal* thermal );
Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
};
#endif // _FG_AIMANAGER_HXX
Copy permalink