2003-11-28 15:48:05 +00:00
|
|
|
// AIManager.cxx Based on David Luff's AIMgr:
|
2004-09-07 09:53:23 +00:00
|
|
|
// - a global management type for AI objects
|
2003-11-28 15:48:05 +00:00
|
|
|
//
|
|
|
|
|
// Written by David Culp, started October 2003.
|
|
|
|
|
// - davidculp2@comcast.net
|
|
|
|
|
//
|
|
|
|
|
// 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.
|
|
|
|
|
|
|
|
|
|
#include <simgear/misc/sg_path.hxx>
|
|
|
|
|
#include <Main/fg_props.hxx>
|
|
|
|
|
#include <Main/globals.hxx>
|
|
|
|
|
|
2004-11-29 09:41:43 +00:00
|
|
|
#include <Airports/simple.hxx>
|
|
|
|
|
#include <Traffic/SchedFlight.hxx>
|
|
|
|
|
#include <Traffic/Schedule.hxx>
|
|
|
|
|
#include <Traffic/TrafficMgr.hxx>
|
|
|
|
|
|
2003-11-28 15:48:05 +00:00
|
|
|
#include <list>
|
|
|
|
|
|
|
|
|
|
#include "AIManager.hxx"
|
|
|
|
|
#include "AIAircraft.hxx"
|
|
|
|
|
#include "AIShip.hxx"
|
|
|
|
|
#include "AIBallistic.hxx"
|
2004-03-03 20:33:08 +00:00
|
|
|
#include "AIStorm.hxx"
|
|
|
|
|
#include "AIThermal.hxx"
|
2004-10-28 08:33:55 +00:00
|
|
|
#include "AICarrier.hxx"
|
2005-06-04 09:38:52 +00:00
|
|
|
#include "AIStatic.hxx"
|
2003-11-28 15:48:05 +00:00
|
|
|
|
|
|
|
|
SG_USING_STD(list);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FGAIManager::FGAIManager() {
|
|
|
|
|
initDone = false;
|
2004-09-07 19:56:22 +00:00
|
|
|
for (int i=0; i < FGAIBase::MAX_OBJECTS; i++)
|
|
|
|
|
numObjects[i] = 0;
|
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
|
|
|
_dt = 0.0;
|
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
|
|
|
dt_count = 9;
|
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
|
|
|
scenario_filename = "";
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_list.clear();
|
2003-11-28 15:48:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FGAIManager::~FGAIManager() {
|
2005-03-19 09:57:18 +00:00
|
|
|
ai_list_iterator ai_list_itr = ai_list.begin();
|
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
|
|
|
while(ai_list_itr != ai_list.end()) {
|
2004-09-23 08:57:46 +00:00
|
|
|
(*ai_list_itr)->unbind();
|
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
|
|
|
delete (*ai_list_itr);
|
|
|
|
|
++ai_list_itr;
|
|
|
|
|
}
|
2003-11-28 20:05:32 +00:00
|
|
|
ai_list.clear();
|
2004-11-29 09:41:43 +00:00
|
|
|
ModelVecIterator i = loadedModels.begin();
|
|
|
|
|
while (i != loadedModels.end())
|
|
|
|
|
{
|
|
|
|
|
i->getModelId()->deRef();
|
|
|
|
|
}
|
2003-11-28 15:48:05 +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
|
|
|
|
2003-11-28 15:48:05 +00:00
|
|
|
void FGAIManager::init() {
|
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
|
|
|
root = fgGetNode("sim/ai", true);
|
2004-05-19 13:55:49 +00:00
|
|
|
|
2004-05-19 14:10:31 +00:00
|
|
|
enabled = root->getNode("enabled", true)->getBoolValue();
|
2004-05-19 13:55:49 +00:00
|
|
|
if (!enabled)
|
|
|
|
|
return;
|
|
|
|
|
|
2004-09-07 09:53:23 +00:00
|
|
|
wind_from_down_node = fgGetNode("/environment/wind-from-down-fps", true);
|
2005-04-19 12:52:26 +00:00
|
|
|
user_latitude_node = fgGetNode("/position/latitude-deg", true);
|
|
|
|
|
user_longitude_node = fgGetNode("/position/longitude-deg", true);
|
|
|
|
|
user_altitude_node = fgGetNode("/position/altitude-ft", true);
|
|
|
|
|
user_heading_node = fgGetNode("/orientation/heading-deg", true);
|
|
|
|
|
user_pitch_node = fgGetNode("/orientation/pitch-deg", true);
|
|
|
|
|
user_yaw_node = fgGetNode("/orientation/side-slip-deg", true);
|
|
|
|
|
user_speed_node = fgGetNode("/velocities/uBody-fps", true);
|
2004-09-22 11:24:45 +00:00
|
|
|
|
2005-07-24 14:05:28 +00:00
|
|
|
for(int i = 0 ; i < root->nChildren() ; i++) {
|
|
|
|
|
SGPropertyNode *aiEntry = root->getChild( i );
|
|
|
|
|
if( !strcmp( aiEntry->getName(), "scenario" ) ) {
|
|
|
|
|
scenario_filename = aiEntry->getStringValue();
|
|
|
|
|
if (scenario_filename != "") processScenario( scenario_filename );
|
|
|
|
|
}
|
|
|
|
|
}
|
2003-11-28 15:48:05 +00:00
|
|
|
initDone = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2005-07-13 12:25:16 +00:00
|
|
|
void FGAIManager::reinit() {
|
|
|
|
|
update(0.0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2003-11-28 15:48:05 +00:00
|
|
|
void FGAIManager::bind() {
|
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
|
|
|
root = globals->get_props()->getNode("ai/models", true);
|
2004-09-07 19:56:22 +00:00
|
|
|
root->tie("count", SGRawValuePointer<int>(&numObjects[0]));
|
2003-11-28 15:48:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void FGAIManager::unbind() {
|
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
|
|
|
root->untie("count");
|
2003-11-28 15:48:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void FGAIManager::update(double dt) {
|
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
|
|
|
|
|
|
|
|
// initialize these for finding nearest thermals
|
|
|
|
|
range_nearest = 10000.0;
|
|
|
|
|
strength = 0.0;
|
2004-11-29 09:41:43 +00:00
|
|
|
FGTrafficManager *tmgr = (FGTrafficManager*) globals->get_subsystem("Traffic Manager");
|
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
|
|
|
|
2004-05-19 13:55:49 +00:00
|
|
|
if (!enabled)
|
|
|
|
|
return;
|
|
|
|
|
|
2004-09-22 19:11:36 +00:00
|
|
|
_dt = dt;
|
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
|
|
|
|
2005-03-19 09:57:18 +00:00
|
|
|
ai_list_iterator ai_list_itr = ai_list.begin();
|
2003-11-28 20:05:32 +00:00
|
|
|
while(ai_list_itr != ai_list.end()) {
|
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
|
|
|
if ((*ai_list_itr)->getDie()) {
|
2004-11-29 09:41:43 +00:00
|
|
|
tmgr->release((*ai_list_itr)->getID());
|
2004-09-07 19:56:22 +00:00
|
|
|
--numObjects[(*ai_list_itr)->getType()];
|
|
|
|
|
--numObjects[0];
|
2004-09-23 08:57:46 +00:00
|
|
|
(*ai_list_itr)->unbind();
|
2004-09-08 14:02:25 +00:00
|
|
|
delete (*ai_list_itr);
|
2004-05-19 08:01:02 +00:00
|
|
|
if ( ai_list_itr == ai_list.begin() ) {
|
|
|
|
|
ai_list.erase(ai_list_itr);
|
|
|
|
|
ai_list_itr = ai_list.begin();
|
|
|
|
|
continue;
|
|
|
|
|
} else {
|
|
|
|
|
ai_list.erase(ai_list_itr--);
|
|
|
|
|
}
|
2003-11-28 15:48:05 +00:00
|
|
|
} else {
|
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
|
|
|
fetchUserState();
|
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
|
|
|
if ((*ai_list_itr)->isa(FGAIBase::otThermal)) {
|
|
|
|
|
processThermal((FGAIThermal*)*ai_list_itr);
|
|
|
|
|
} else {
|
|
|
|
|
(*ai_list_itr)->update(_dt);
|
|
|
|
|
}
|
2003-11-28 20:05:32 +00:00
|
|
|
}
|
2003-11-28 15:48:05 +00:00
|
|
|
++ai_list_itr;
|
2003-11-28 20:05:32 +00:00
|
|
|
}
|
2005-05-16 09:48:00 +00:00
|
|
|
wind_from_down_node->setDoubleValue( strength ); // for thermals
|
2004-06-06 08:50:17 +00:00
|
|
|
|
2003-11-28 15:48:05 +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
|
|
|
|
|
|
|
|
|
2004-09-08 13:21:40 +00:00
|
|
|
void*
|
2004-11-29 09:41:43 +00:00
|
|
|
FGAIManager::createAircraft( FGAIModelEntity *entity, FGAISchedule *ref) {
|
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
|
|
|
|
2004-11-29 09:41:43 +00:00
|
|
|
FGAIAircraft* ai_plane = new FGAIAircraft(this, ref);
|
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
|
|
|
ai_list.push_back(ai_plane);
|
2004-09-07 19:56:22 +00:00
|
|
|
++numObjects[0];
|
|
|
|
|
++numObjects[FGAIBase::otAircraft];
|
2004-09-07 09:53:23 +00:00
|
|
|
if (entity->m_class == "light") {
|
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
|
|
|
ai_plane->SetPerformance(&FGAIAircraft::settings[FGAIAircraft::LIGHT]);
|
2004-09-07 09:53:23 +00:00
|
|
|
} else if (entity->m_class == "ww2_fighter") {
|
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
|
|
|
ai_plane->SetPerformance(&FGAIAircraft::settings[FGAIAircraft::WW2_FIGHTER]);
|
2004-09-07 09:53:23 +00:00
|
|
|
} else if (entity->m_class == "jet_transport") {
|
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
|
|
|
ai_plane->SetPerformance(&FGAIAircraft::settings[FGAIAircraft::JET_TRANSPORT]);
|
2004-09-07 09:53:23 +00:00
|
|
|
} else if (entity->m_class == "jet_fighter") {
|
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
|
|
|
ai_plane->SetPerformance(&FGAIAircraft::settings[FGAIAircraft::JET_FIGHTER]);
|
2004-09-07 09:53:23 +00:00
|
|
|
} else if (entity->m_class == "tanker") {
|
2004-06-06 08:50:17 +00:00
|
|
|
ai_plane->SetPerformance(&FGAIAircraft::settings[FGAIAircraft::JET_TRANSPORT]);
|
|
|
|
|
ai_plane->SetTanker(true);
|
2004-05-15 09:07:55 +00:00
|
|
|
} else {
|
|
|
|
|
ai_plane->SetPerformance(&FGAIAircraft::settings[FGAIAircraft::JET_TRANSPORT]);
|
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
|
|
|
}
|
2005-07-24 14:05:28 +00:00
|
|
|
ai_plane->setAcType(entity->acType);
|
|
|
|
|
ai_plane->setCompany(entity->company);
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_plane->setHeading(entity->heading);
|
|
|
|
|
ai_plane->setSpeed(entity->speed);
|
2004-10-14 09:49:46 +00:00
|
|
|
ai_plane->setPath(entity->path.c_str());
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_plane->setAltitude(entity->altitude);
|
|
|
|
|
ai_plane->setLongitude(entity->longitude);
|
|
|
|
|
ai_plane->setLatitude(entity->latitude);
|
|
|
|
|
ai_plane->setBank(entity->roll);
|
|
|
|
|
|
|
|
|
|
if ( entity->fp ) {
|
|
|
|
|
ai_plane->SetFlightPlan(entity->fp);
|
2004-05-15 09:07:55 +00:00
|
|
|
}
|
2005-06-04 09:38:52 +00:00
|
|
|
if (entity->repeat) {
|
|
|
|
|
ai_plane->GetFlightPlan()->setRepeat(true);
|
|
|
|
|
}
|
2004-05-15 09:07:55 +00:00
|
|
|
ai_plane->init();
|
|
|
|
|
ai_plane->bind();
|
2004-09-08 13:21:40 +00:00
|
|
|
return ai_plane;
|
2004-05-15 09:07:55 +00:00
|
|
|
}
|
|
|
|
|
|
2004-09-08 13:21:40 +00:00
|
|
|
void*
|
|
|
|
|
FGAIManager::createShip( FGAIModelEntity *entity ) {
|
2004-11-16 09:33:21 +00:00
|
|
|
|
2004-11-30 12:34:11 +00:00
|
|
|
// cout << "creating ship" << endl;
|
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
|
|
|
|
|
|
|
|
FGAIShip* ai_ship = new FGAIShip(this);
|
|
|
|
|
ai_list.push_back(ai_ship);
|
2004-09-07 19:56:22 +00:00
|
|
|
++numObjects[0];
|
|
|
|
|
++numObjects[FGAIBase::otShip];
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_ship->setHeading(entity->heading);
|
|
|
|
|
ai_ship->setSpeed(entity->speed);
|
2004-10-14 09:49:46 +00:00
|
|
|
ai_ship->setPath(entity->path.c_str());
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_ship->setAltitude(entity->altitude);
|
|
|
|
|
ai_ship->setLongitude(entity->longitude);
|
|
|
|
|
ai_ship->setLatitude(entity->latitude);
|
|
|
|
|
ai_ship->setBank(entity->rudder);
|
2005-03-19 09:57:18 +00:00
|
|
|
ai_ship->setName(entity->name);
|
2004-09-07 09:53:23 +00:00
|
|
|
|
|
|
|
|
if ( entity->fp ) {
|
|
|
|
|
ai_ship->setFlightPlan(entity->fp);
|
|
|
|
|
}
|
2004-05-29 11:39:10 +00:00
|
|
|
|
|
|
|
|
ai_ship->init();
|
|
|
|
|
ai_ship->bind();
|
2004-09-08 13:21:40 +00:00
|
|
|
return ai_ship;
|
2004-05-29 11:39:10 +00:00
|
|
|
}
|
|
|
|
|
|
2004-10-28 08:33:55 +00:00
|
|
|
void*
|
|
|
|
|
FGAIManager::createCarrier( FGAIModelEntity *entity ) {
|
2004-11-16 09:33:21 +00:00
|
|
|
|
2004-11-30 12:34:11 +00:00
|
|
|
// cout << "creating carrier" << endl;
|
2004-10-28 08:33:55 +00:00
|
|
|
|
2004-11-26 10:24:48 +00:00
|
|
|
FGAICarrier* ai_carrier = new FGAICarrier(this);
|
2004-10-28 08:33:55 +00:00
|
|
|
ai_list.push_back(ai_carrier);
|
|
|
|
|
++numObjects[0];
|
2005-03-19 09:57:18 +00:00
|
|
|
++numObjects[FGAIBase::otCarrier];
|
2004-10-28 08:33:55 +00:00
|
|
|
ai_carrier->setHeading(entity->heading);
|
|
|
|
|
ai_carrier->setSpeed(entity->speed);
|
|
|
|
|
ai_carrier->setPath(entity->path.c_str());
|
|
|
|
|
ai_carrier->setAltitude(entity->altitude);
|
|
|
|
|
ai_carrier->setLongitude(entity->longitude);
|
|
|
|
|
ai_carrier->setLatitude(entity->latitude);
|
|
|
|
|
ai_carrier->setBank(entity->rudder);
|
2004-11-26 10:24:48 +00:00
|
|
|
ai_carrier->setSolidObjects(entity->solid_objects);
|
|
|
|
|
ai_carrier->setWireObjects(entity->wire_objects);
|
|
|
|
|
ai_carrier->setCatapultObjects(entity->catapult_objects);
|
2005-03-19 09:57:18 +00:00
|
|
|
ai_carrier->setParkingPositions(entity->ppositions);
|
2004-11-16 09:33:21 +00:00
|
|
|
ai_carrier->setRadius(entity->radius);
|
2005-03-19 09:57:18 +00:00
|
|
|
ai_carrier->setSign(entity->pennant_number);
|
|
|
|
|
ai_carrier->setName(entity->name);
|
|
|
|
|
ai_carrier->setFlolsOffset(entity->flols_offset);
|
2004-10-28 08:33:55 +00:00
|
|
|
|
|
|
|
|
if ( entity->fp ) {
|
|
|
|
|
ai_carrier->setFlightPlan(entity->fp);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ai_carrier->init();
|
|
|
|
|
ai_carrier->bind();
|
|
|
|
|
return ai_carrier;
|
|
|
|
|
}
|
|
|
|
|
|
2004-09-08 13:21:40 +00:00
|
|
|
void*
|
|
|
|
|
FGAIManager::createBallistic( FGAIModelEntity *entity ) {
|
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
|
|
|
|
|
|
|
|
FGAIBallistic* ai_ballistic = new FGAIBallistic(this);
|
|
|
|
|
ai_list.push_back(ai_ballistic);
|
2004-09-07 19:56:22 +00:00
|
|
|
++numObjects[0];
|
|
|
|
|
++numObjects[FGAIBase::otBallistic];
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_ballistic->setAzimuth(entity->azimuth);
|
|
|
|
|
ai_ballistic->setElevation(entity->elevation);
|
|
|
|
|
ai_ballistic->setSpeed(entity->speed);
|
2004-10-14 09:49:46 +00:00
|
|
|
ai_ballistic->setPath(entity->path.c_str());
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_ballistic->setAltitude(entity->altitude);
|
|
|
|
|
ai_ballistic->setLongitude(entity->longitude);
|
|
|
|
|
ai_ballistic->setLatitude(entity->latitude);
|
|
|
|
|
ai_ballistic->setDragArea(entity->eda);
|
|
|
|
|
ai_ballistic->setLife(entity->life);
|
|
|
|
|
ai_ballistic->setBuoyancy(entity->buoyancy);
|
2004-09-20 19:29:16 +00:00
|
|
|
ai_ballistic->setWind_from_east(entity->wind_from_east);
|
|
|
|
|
ai_ballistic->setWind_from_north(entity->wind_from_north);
|
|
|
|
|
ai_ballistic->setWind(entity->wind);
|
|
|
|
|
ai_ballistic->setRoll(entity->roll);
|
2004-09-22 19:11:36 +00:00
|
|
|
ai_ballistic->setCd(entity->cd);
|
2004-09-27 14:24:20 +00:00
|
|
|
ai_ballistic->setMass(entity->mass);
|
2004-10-28 08:29:15 +00:00
|
|
|
ai_ballistic->setStabilisation(entity->aero_stabilised);
|
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
|
|
|
ai_ballistic->init();
|
|
|
|
|
ai_ballistic->bind();
|
2004-09-08 13:21:40 +00:00
|
|
|
return ai_ballistic;
|
2004-03-03 20:33:08 +00:00
|
|
|
}
|
|
|
|
|
|
2004-09-08 13:21:40 +00:00
|
|
|
void*
|
|
|
|
|
FGAIManager::createStorm( FGAIModelEntity *entity ) {
|
2004-03-03 20:33:08 +00:00
|
|
|
|
|
|
|
|
FGAIStorm* ai_storm = new FGAIStorm(this);
|
2004-09-07 19:56:22 +00:00
|
|
|
++numObjects[0];
|
|
|
|
|
++numObjects[FGAIBase::otStorm];
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_storm->setHeading(entity->heading);
|
|
|
|
|
ai_storm->setSpeed(entity->speed);
|
2004-10-14 09:49:46 +00:00
|
|
|
ai_storm->setPath(entity->path.c_str());
|
2005-05-16 09:48:00 +00:00
|
|
|
ai_storm->setAltitude(entity->altitude);
|
|
|
|
|
ai_storm->setDiameter(entity->diameter / 6076.11549);
|
|
|
|
|
ai_storm->setHeight(entity->height_msl);
|
|
|
|
|
ai_storm->setStrengthNorm(entity->strength);
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_storm->setLongitude(entity->longitude);
|
|
|
|
|
ai_storm->setLatitude(entity->latitude);
|
2004-03-03 20:33:08 +00:00
|
|
|
ai_storm->init();
|
|
|
|
|
ai_storm->bind();
|
2004-09-22 19:11:36 +00:00
|
|
|
ai_list.push_back(ai_storm);
|
2004-09-08 13:21:40 +00:00
|
|
|
return ai_storm;
|
2004-03-03 20:33:08 +00:00
|
|
|
}
|
|
|
|
|
|
2004-09-08 13:21:40 +00:00
|
|
|
void*
|
|
|
|
|
FGAIManager::createThermal( FGAIModelEntity *entity ) {
|
2004-03-03 20:33:08 +00:00
|
|
|
|
|
|
|
|
FGAIThermal* ai_thermal = new FGAIThermal(this);
|
2004-09-07 19:56:22 +00:00
|
|
|
++numObjects[0];
|
|
|
|
|
++numObjects[FGAIBase::otThermal];
|
2004-09-07 09:53:23 +00:00
|
|
|
ai_thermal->setLongitude(entity->longitude);
|
|
|
|
|
ai_thermal->setLatitude(entity->latitude);
|
|
|
|
|
ai_thermal->setMaxStrength(entity->strength);
|
|
|
|
|
ai_thermal->setDiameter(entity->diameter / 6076.11549);
|
2005-04-19 12:52:26 +00:00
|
|
|
ai_thermal->setHeight(entity->height_msl);
|
2004-03-03 20:33:08 +00:00
|
|
|
ai_thermal->init();
|
|
|
|
|
ai_thermal->bind();
|
2004-09-22 19:11:36 +00:00
|
|
|
ai_list.push_back(ai_thermal);
|
2004-09-08 13:21:40 +00:00
|
|
|
return ai_thermal;
|
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
|
|
|
}
|
|
|
|
|
|
2005-06-04 09:38:52 +00:00
|
|
|
void*
|
|
|
|
|
FGAIManager::createStatic( FGAIModelEntity *entity ) {
|
|
|
|
|
|
|
|
|
|
// cout << "creating static object" << endl;
|
|
|
|
|
|
|
|
|
|
FGAIStatic* ai_static = new FGAIStatic(this);
|
|
|
|
|
ai_list.push_back(ai_static);
|
|
|
|
|
++numObjects[0];
|
|
|
|
|
++numObjects[FGAIBase::otStatic];
|
|
|
|
|
ai_static->setHeading(entity->heading);
|
|
|
|
|
ai_static->setPath(entity->path.c_str());
|
|
|
|
|
ai_static->setAltitude(entity->altitude);
|
|
|
|
|
ai_static->setLongitude(entity->longitude);
|
|
|
|
|
ai_static->setLatitude(entity->latitude);
|
|
|
|
|
ai_static->init();
|
|
|
|
|
ai_static->bind();
|
|
|
|
|
return ai_static;
|
|
|
|
|
}
|
|
|
|
|
|
2004-09-08 13:21:40 +00:00
|
|
|
void FGAIManager::destroyObject( void* ID ) {
|
2005-03-19 09:57:18 +00:00
|
|
|
ai_list_iterator ai_list_itr = ai_list.begin();
|
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
|
|
|
while(ai_list_itr != ai_list.end()) {
|
|
|
|
|
if ((*ai_list_itr)->getID() == ID) {
|
2004-09-07 19:56:22 +00:00
|
|
|
--numObjects[0];
|
|
|
|
|
--numObjects[(*ai_list_itr)->getType()];
|
2004-09-23 08:57:46 +00:00
|
|
|
(*ai_list_itr)->unbind();
|
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
|
|
|
delete (*ai_list_itr);
|
|
|
|
|
ai_list.erase(ai_list_itr);
|
2004-09-08 13:21:40 +00:00
|
|
|
|
|
|
|
|
break;
|
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
|
|
|
}
|
|
|
|
|
++ai_list_itr;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2005-04-19 12:52:26 +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 FGAIManager::fetchUserState( void ) {
|
2005-04-19 12:52:26 +00:00
|
|
|
user_latitude = user_latitude_node->getDoubleValue();
|
|
|
|
|
user_longitude = user_longitude_node->getDoubleValue();
|
|
|
|
|
user_altitude = user_altitude_node->getDoubleValue();
|
|
|
|
|
user_heading = user_heading_node->getDoubleValue();
|
|
|
|
|
user_pitch = user_pitch_node->getDoubleValue();
|
|
|
|
|
user_yaw = user_yaw_node->getDoubleValue();
|
|
|
|
|
user_speed = user_speed_node->getDoubleValue() * 0.592484;
|
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:
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
|
|
|
|
|
|
|
|
|
|
|
|
|
// only keep the results from the nearest thermal
|
|
|
|
|
void FGAIManager::processThermal( FGAIThermal* thermal ) {
|
|
|
|
|
thermal->update(_dt);
|
|
|
|
|
if ( thermal->_getRange() < range_nearest ) {
|
|
|
|
|
range_nearest = thermal->_getRange();
|
|
|
|
|
strength = thermal->getStrength();
|
|
|
|
|
}
|
|
|
|
|
}
|
2004-05-15 09:07:55 +00:00
|
|
|
|
|
|
|
|
|
Mathias Fröhlich:
I have introduced the posibility to start directly on the carrier.
With that patch you will have a --carrrier=id argument where id can either be
the pennant number configured in the nimitz scenario or the carriers name
also configured in the carriers scenario.
Additionaly you can use --parkpos=id to select different positions on the
carrier. They are also configured in the scenario file.
That includes the switch of the whole FGInterface class to make use of the
groundcache.
That means that an aircraft no longer uses the current elevation value from
the scenery class. It rather has its own local cache of the aircrafts
environment which is setup in the common_init method of FGInterface and
updated either manually by calling
FGInterface::get_groundlevel_m(lat, lon, alt_m);
or implicitly by calling the above method in the
FGInterface::_updateGeo*Position(lat, lon, alt);
methods.
A call get_groundlevel_m rebuilds the groundcache if the request is outside
the range of the cache.
Note that for the real usage of the groundcache including the correct
information about the movement of objects and the velocity information, you
still need to set up the groundcache in the usual way like YASim and JSBSim
currently does.
If you use the native interface, you will get only static objects correctly.
But for FDM's only using one single ground level for a whole step this is IMO
sufficient.
The AIManager gets a way to return the location of a object which is placed
wrt an AI Object. At the moment it only honours AICarriers for that.
That method is a static one, which loads the scenario file for that reason and
throws it away afterwards. This looked like the aprioriate way, because the
AIManager is initialized much later in flightgears bootstrap, and I did not
find an easy way to reorder that for my needs. Since this additional load is
very small and does only happen if such a relative location is required, I
think that this is ok.
Note that moving on the carrier will only work correctly for JSBSim and YASim,
but you should now be able to start and move on every not itself moving
object with any FDM.
2005-07-03 09:39:14 +00:00
|
|
|
void FGAIManager::processScenario( const string &filename ) {
|
2004-05-15 09:07:55 +00:00
|
|
|
FGAIScenario* s = new FGAIScenario( filename );
|
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
|
|
|
for (int i=0;i<s->nEntries();i++) {
|
2004-09-07 09:53:23 +00:00
|
|
|
FGAIModelEntity* en = s->getNextEntry();
|
|
|
|
|
|
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
|
|
|
if (en) {
|
2004-10-14 09:49:46 +00:00
|
|
|
if ( en->m_type == "aircraft") {
|
|
|
|
|
createAircraft( en );
|
2004-09-07 09:53:23 +00:00
|
|
|
|
2004-10-14 09:49:46 +00:00
|
|
|
} else if ( en->m_type == "ship") {
|
|
|
|
|
createShip( en );
|
2004-09-07 09:53:23 +00:00
|
|
|
|
2004-10-28 08:33:55 +00:00
|
|
|
} else if ( en->m_type == "carrier") {
|
|
|
|
|
createCarrier( en );
|
|
|
|
|
|
2004-10-14 09:49:46 +00:00
|
|
|
} else if ( en->m_type == "thunderstorm") {
|
2004-09-07 09:53:23 +00:00
|
|
|
createStorm( en );
|
|
|
|
|
|
2004-10-14 09:49:46 +00:00
|
|
|
} else if ( en->m_type == "thermal") {
|
2004-09-07 09:53:23 +00:00
|
|
|
createThermal( en );
|
|
|
|
|
|
2004-10-14 09:49:46 +00:00
|
|
|
} else if ( en->m_type == "ballistic") {
|
2004-09-07 09:53:23 +00:00
|
|
|
createBallistic( en );
|
2005-06-04 09:38:52 +00:00
|
|
|
|
|
|
|
|
} else if ( en->m_type == "static") {
|
|
|
|
|
createStatic( en );
|
|
|
|
|
}
|
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
|
|
|
}
|
2004-05-15 09:07:55 +00:00
|
|
|
}
|
2004-05-29 11:39:10 +00:00
|
|
|
|
2004-05-15 09:07:55 +00:00
|
|
|
delete s;
|
|
|
|
|
}
|
|
|
|
|
|
2004-11-29 09:41:43 +00:00
|
|
|
// This code keeps track of models that have already been loaded
|
|
|
|
|
// Eventually we'd prbably need to find a way to keep track of models
|
|
|
|
|
// that are unloaded again
|
|
|
|
|
ssgBranch * FGAIManager::getModel(const string& path)
|
|
|
|
|
{
|
|
|
|
|
ModelVecIterator i = loadedModels.begin();
|
|
|
|
|
while (i != loadedModels.end())
|
|
|
|
|
{
|
|
|
|
|
if (i->getPath() == path)
|
|
|
|
|
return i->getModelId();
|
|
|
|
|
i++;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void FGAIManager::setModel(const string& path, ssgBranch *model)
|
|
|
|
|
{
|
|
|
|
|
loadedModels.push_back(FGModelID(path,model));
|
|
|
|
|
}
|
|
|
|
|
|
Mathias Fröhlich:
I have introduced the posibility to start directly on the carrier.
With that patch you will have a --carrrier=id argument where id can either be
the pennant number configured in the nimitz scenario or the carriers name
also configured in the carriers scenario.
Additionaly you can use --parkpos=id to select different positions on the
carrier. They are also configured in the scenario file.
That includes the switch of the whole FGInterface class to make use of the
groundcache.
That means that an aircraft no longer uses the current elevation value from
the scenery class. It rather has its own local cache of the aircrafts
environment which is setup in the common_init method of FGInterface and
updated either manually by calling
FGInterface::get_groundlevel_m(lat, lon, alt_m);
or implicitly by calling the above method in the
FGInterface::_updateGeo*Position(lat, lon, alt);
methods.
A call get_groundlevel_m rebuilds the groundcache if the request is outside
the range of the cache.
Note that for the real usage of the groundcache including the correct
information about the movement of objects and the velocity information, you
still need to set up the groundcache in the usual way like YASim and JSBSim
currently does.
If you use the native interface, you will get only static objects correctly.
But for FDM's only using one single ground level for a whole step this is IMO
sufficient.
The AIManager gets a way to return the location of a object which is placed
wrt an AI Object. At the moment it only honours AICarriers for that.
That method is a static one, which loads the scenario file for that reason and
throws it away afterwards. This looked like the aprioriate way, because the
AIManager is initialized much later in flightgears bootstrap, and I did not
find an easy way to reorder that for my needs. Since this additional load is
very small and does only happen if such a relative location is required, I
think that this is ok.
Note that moving on the carrier will only work correctly for JSBSim and YASim,
but you should now be able to start and move on every not itself moving
object with any FDM.
2005-07-03 09:39:14 +00:00
|
|
|
bool FGAIManager::getStartPosition(const string& id, const string& pid,
|
|
|
|
|
Point3D& geodPos, double& heading,
|
|
|
|
|
sgdVec3 uvw)
|
|
|
|
|
{
|
|
|
|
|
SGPropertyNode* root = fgGetNode("sim/ai", true);
|
|
|
|
|
if (!root->getNode("enabled", true)->getBoolValue())
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
bool found = false;
|
2005-07-24 14:05:28 +00:00
|
|
|
for(int i = 0 ; (!found) && i < root->nChildren() ; i++) {
|
|
|
|
|
SGPropertyNode *aiEntry = root->getChild( i );
|
|
|
|
|
if( !strcmp( aiEntry->getName(), "scenario" ) ) {
|
|
|
|
|
string filename = aiEntry->getStringValue();
|
|
|
|
|
FGAIScenario* s = new FGAIScenario( filename );
|
|
|
|
|
for (int i=0; i<s->nEntries(); i++) {
|
|
|
|
|
FGAIModelEntity* en = s->getNextEntry();
|
|
|
|
|
if (en && en->m_type == "carrier" &&
|
|
|
|
|
(en->pennant_number == id || en->name == id)) {
|
|
|
|
|
FGAICarrier* ai_carrier = new FGAICarrier(0);
|
|
|
|
|
ai_carrier->setHeading(en->heading);
|
|
|
|
|
ai_carrier->setSpeed(en->speed);
|
|
|
|
|
ai_carrier->setAltitude(en->altitude);
|
|
|
|
|
ai_carrier->setLongitude(en->longitude);
|
|
|
|
|
ai_carrier->setLatitude(en->latitude);
|
|
|
|
|
ai_carrier->setBank(en->rudder);
|
|
|
|
|
ai_carrier->setParkingPositions(en->ppositions);
|
|
|
|
|
|
|
|
|
|
if (ai_carrier->getParkPosition(pid, geodPos, heading, uvw)) {
|
|
|
|
|
delete ai_carrier;
|
|
|
|
|
found = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
Mathias Fröhlich:
I have introduced the posibility to start directly on the carrier.
With that patch you will have a --carrrier=id argument where id can either be
the pennant number configured in the nimitz scenario or the carriers name
also configured in the carriers scenario.
Additionaly you can use --parkpos=id to select different positions on the
carrier. They are also configured in the scenario file.
That includes the switch of the whole FGInterface class to make use of the
groundcache.
That means that an aircraft no longer uses the current elevation value from
the scenery class. It rather has its own local cache of the aircrafts
environment which is setup in the common_init method of FGInterface and
updated either manually by calling
FGInterface::get_groundlevel_m(lat, lon, alt_m);
or implicitly by calling the above method in the
FGInterface::_updateGeo*Position(lat, lon, alt);
methods.
A call get_groundlevel_m rebuilds the groundcache if the request is outside
the range of the cache.
Note that for the real usage of the groundcache including the correct
information about the movement of objects and the velocity information, you
still need to set up the groundcache in the usual way like YASim and JSBSim
currently does.
If you use the native interface, you will get only static objects correctly.
But for FDM's only using one single ground level for a whole step this is IMO
sufficient.
The AIManager gets a way to return the location of a object which is placed
wrt an AI Object. At the moment it only honours AICarriers for that.
That method is a static one, which loads the scenario file for that reason and
throws it away afterwards. This looked like the aprioriate way, because the
AIManager is initialized much later in flightgears bootstrap, and I did not
find an easy way to reorder that for my needs. Since this additional load is
very small and does only happen if such a relative location is required, I
think that this is ok.
Note that moving on the carrier will only work correctly for JSBSim and YASim,
but you should now be able to start and move on every not itself moving
object with any FDM.
2005-07-03 09:39:14 +00:00
|
|
|
|
2005-07-24 14:05:28 +00:00
|
|
|
delete ai_carrier;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
delete s;
|
Mathias Fröhlich:
I have introduced the posibility to start directly on the carrier.
With that patch you will have a --carrrier=id argument where id can either be
the pennant number configured in the nimitz scenario or the carriers name
also configured in the carriers scenario.
Additionaly you can use --parkpos=id to select different positions on the
carrier. They are also configured in the scenario file.
That includes the switch of the whole FGInterface class to make use of the
groundcache.
That means that an aircraft no longer uses the current elevation value from
the scenery class. It rather has its own local cache of the aircrafts
environment which is setup in the common_init method of FGInterface and
updated either manually by calling
FGInterface::get_groundlevel_m(lat, lon, alt_m);
or implicitly by calling the above method in the
FGInterface::_updateGeo*Position(lat, lon, alt);
methods.
A call get_groundlevel_m rebuilds the groundcache if the request is outside
the range of the cache.
Note that for the real usage of the groundcache including the correct
information about the movement of objects and the velocity information, you
still need to set up the groundcache in the usual way like YASim and JSBSim
currently does.
If you use the native interface, you will get only static objects correctly.
But for FDM's only using one single ground level for a whole step this is IMO
sufficient.
The AIManager gets a way to return the location of a object which is placed
wrt an AI Object. At the moment it only honours AICarriers for that.
That method is a static one, which loads the scenario file for that reason and
throws it away afterwards. This looked like the aprioriate way, because the
AIManager is initialized much later in flightgears bootstrap, and I did not
find an easy way to reorder that for my needs. Since this additional load is
very small and does only happen if such a relative location is required, I
think that this is ok.
Note that moving on the carrier will only work correctly for JSBSim and YASim,
but you should now be able to start and move on every not itself moving
object with any FDM.
2005-07-03 09:39:14 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return found;
|
|
|
|
|
}
|
2004-11-29 09:41:43 +00:00
|
|
|
|
2004-09-22 08:47:05 +00:00
|
|
|
//end AIManager.cxx
|