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

392 lines
12 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.cxx Based on David Luff's AIMgr:
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
// - a global management type for AI objects
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
//
// 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>
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
#include <Airports/simple.hxx>
#include <Traffic/SchedFlight.hxx>
#include <Traffic/Schedule.hxx>
#include <Traffic/TrafficMgr.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
#include <list>
#include "AIManager.hxx"
#include "AIAircraft.hxx"
#include "AIShip.hxx"
#include "AIBallistic.hxx"
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
#include "AIStorm.hxx"
#include "AIThermal.hxx"
David Culp: Here's code to support a new AICarrier class, which I think will be sufficiently different from a basic AIShip that it should have its own class.
2004-10-28 08:33:55 +00:00
#include "AICarrier.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);
FGAIManager::FGAIManager() {
initDone = false;
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
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 = "";
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
ai_list.clear();
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
}
FGAIManager::~FGAIManager() {
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 = ai_list.begin();
while(ai_list_itr != ai_list.end()) {
Don't forget to unbind() before deleting the class.
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;
}
Some small updates
2003-11-28 20:05:32 +00:00
ai_list.clear();
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
ModelVecIterator i = loadedModels.begin();
while (i != loadedModels.end())
{
i->getModelId()->deRef();
}
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 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
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
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);
Add AI models enableing/disableing command line option and support code.
2004-05-19 13:55:49 +00:00
Oops, change type.
2004-05-19 14:10:31 +00:00
enabled = root->getNode("enabled", true)->getBoolValue();
Add AI models enableing/disableing command line option and support code.
2004-05-19 13:55:49 +00:00
if (!enabled)
return;
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
wind_from_down_node = fgGetNode("/environment/wind-from-down-fps", 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
scenario_filename = root->getNode("scenario", true)->getStringValue();
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 (scenario_filename != "") processScenario( scenario_filename );
Make the scenarios work again.
2004-09-22 11:24:45 +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
initDone = true;
}
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);
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
root->tie("count", SGRawValuePointer<int>(&numObjects[0]));
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
}
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");
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
}
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;
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
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
Add AI models enableing/disableing command line option and support code.
2004-05-19 13:55:49 +00:00
if (!enabled)
return;
Vivian Meazza: The value of rho (air density) varies with height. (Including the upper stratosphere, ust in case someone wants to model ICBMs.) The standard atmosphere is used (based on a sea-level temperature of 15 deg C.). Erik Hofman: I moved this code over the AIBase::update() so all AIModels can make use of rho, temperature, pressure, etc.
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
Some small updates
2003-11-28 20:05:32 +00:00
ai_list_itr = ai_list.begin();
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()) {
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
2004-11-29 09:41:43 +00:00
tmgr->release((*ai_list_itr)->getID());
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
--numObjects[(*ai_list_itr)->getType()];
--numObjects[0];
Don't forget to unbind() before deleting the class.
2004-09-23 08:57:46 +00:00
(*ai_list_itr)->unbind();
Make sure the pointer is not being used after deletion, and tie the elapsed time to the particular class instance.
2004-09-08 14:02:25 +00:00
delete (*ai_list_itr);
Fred found some iterated related problems. With a bit of luck this solves the segmentation fault problem.
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--);
}
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
} 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);
}
Some small updates
2003-11-28 20:05:32 +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
++ai_list_itr;
Some small updates
2003-11-28 20:05:32 +00:00
}
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
wind_from_down_node->setDoubleValue( strength );
David Culp: Here's some additions to AI that allow refueling from an AI tanker (the actual onload of fuel must be handled by the user's FDM of course, this just lets the FDM know that the user is in position to refuel). I've added a new class of AIAircraft called "tanker". It uses the same performance struct as a jet transport. An AI tanker is just like an AI jet transport, except it uses the already-existing radar data to control the boolean property systems/refuel/contact. The code change was minimal. An AI tanker can be created like this: <entry> <callsign>Esso 1</callsign> <type>aircraft</type> <class>tanker</class> <model>Aircraft/737/Models/boeing733.xml</model> <latitude>37.61633</latitude> <longitude>-122.38334</longitude> <altitude>3000</altitude> <heading>020</heading> <speed>280</speed> <roll>-15</roll> </entry> This puts a tanker over KSFO at 3000 feet, in a left-hand orbit. When the user gets within refueling range (contact position) then the property systems/refuel/contact will be true. Otherwise it is false. The dimensions of the refueling envelope are pretty rough right now, but still usable. The user must be behind the tanker (ie. radar y_offset > 0). The user must be at or below the tanker's altitude (ie. radar elevation > 0). The user's lat/lon must be within 250 feet of the tanker's lat/lon (ie. radar range_ft < 250). This last requirement is loose because the radar data is only updated every 100 ms, which is accurate enough for radar use, but which is sloppy for air refueling. This could be tightened up by increasing the radar update rate to once every sim cycle. I'm going to add a light to the T-38 instrument panel that will monitor the property systems/refuel/contact. This will make it easier to explore the boundaries of the refueling envelope.
2004-06-06 08:50:17 +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
}
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
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void*
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
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
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
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);
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
++numObjects[0];
++numObjects[FGAIBase::otAircraft];
Make use of a pointer to a structure to pass multiple parameters around.
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]);
Make use of a pointer to a structure to pass multiple parameters around.
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]);
Make use of a pointer to a structure to pass multiple parameters around.
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]);
Make use of a pointer to a structure to pass multiple parameters around.
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]);
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
} else if (entity->m_class == "tanker") {
David Culp: Here's some additions to AI that allow refueling from an AI tanker (the actual onload of fuel must be handled by the user's FDM of course, this just lets the FDM know that the user is in position to refuel). I've added a new class of AIAircraft called "tanker". It uses the same performance struct as a jet transport. An AI tanker is just like an AI jet transport, except it uses the already-existing radar data to control the boolean property systems/refuel/contact. The code change was minimal. An AI tanker can be created like this: <entry> <callsign>Esso 1</callsign> <type>aircraft</type> <class>tanker</class> <model>Aircraft/737/Models/boeing733.xml</model> <latitude>37.61633</latitude> <longitude>-122.38334</longitude> <altitude>3000</altitude> <heading>020</heading> <speed>280</speed> <roll>-15</roll> </entry> This puts a tanker over KSFO at 3000 feet, in a left-hand orbit. When the user gets within refueling range (contact position) then the property systems/refuel/contact will be true. Otherwise it is false. The dimensions of the refueling envelope are pretty rough right now, but still usable. The user must be behind the tanker (ie. radar y_offset > 0). The user must be at or below the tanker's altitude (ie. radar elevation > 0). The user's lat/lon must be within 250 feet of the tanker's lat/lon (ie. radar range_ft < 250). This last requirement is loose because the radar data is only updated every 100 ms, which is accurate enough for radar use, but which is sloppy for air refueling. This could be tightened up by increasing the radar update rate to once every sim cycle. I'm going to add a light to the T-38 instrument panel that will monitor the property systems/refuel/contact. This will make it easier to explore the boundaries of the refueling envelope.
2004-06-06 08:50:17 +00:00
ai_plane->SetPerformance(&FGAIAircraft::settings[FGAIAircraft::JET_TRANSPORT]);
ai_plane->SetTanker(true);
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
} 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
}
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
ai_plane->setHeading(entity->heading);
ai_plane->setSpeed(entity->speed);
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
ai_plane->setPath(entity->path.c_str());
Make use of a pointer to a structure to pass multiple parameters around.
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);
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
}
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +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
ai_plane->init();
ai_plane->bind();
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
return ai_plane;
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
}
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void*
FGAIManager::createShip( FGAIModelEntity *entity ) {
commit some pending updates from Vivian
2004-11-16 09:33:21 +00:00
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
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);
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
++numObjects[0];
++numObjects[FGAIBase::otShip];
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
ai_ship->setHeading(entity->heading);
ai_ship->setSpeed(entity->speed);
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
ai_ship->setPath(entity->path.c_str());
Make use of a pointer to a structure to pass multiple parameters around.
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);
if ( entity->fp ) {
ai_ship->setFlightPlan(entity->fp);
}
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
ai_ship->init();
ai_ship->bind();
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
return ai_ship;
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
}
David Culp: Here's code to support a new AICarrier class, which I think will be sufficiently different from a basic AIShip that it should have its own class.
2004-10-28 08:33:55 +00:00
void*
FGAIManager::createCarrier( FGAIModelEntity *entity ) {
commit some pending updates from Vivian
2004-11-16 09:33:21 +00:00
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +00:00
// cout << "creating carrier" << endl;
David Culp: Here's code to support a new AICarrier class, which I think will be sufficiently different from a basic AIShip that it should have its own class.
2004-10-28 08:33:55 +00:00
Mathias Frhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
2004-11-26 10:24:48 +00:00
FGAICarrier* ai_carrier = new FGAICarrier(this);
David Culp: Here's code to support a new AICarrier class, which I think will be sufficiently different from a basic AIShip that it should have its own class.
2004-10-28 08:33:55 +00:00
ai_list.push_back(ai_carrier);
++numObjects[0];
++numObjects[FGAIBase::otShip];
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);
Mathias Frhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
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);
commit some pending updates from Vivian
2004-11-16 09:33:21 +00:00
ai_carrier->setRadius(entity->radius);
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +00:00
ai_carrier->setXoffset(entity->x_offset);
ai_carrier->setYoffset(entity->y_offset);
ai_carrier->setZoffset(entity->z_offset);
David Culp: Here's code to support a new AICarrier class, which I think will be sufficiently different from a basic AIShip that it should have its own class.
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;
}
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
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);
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
++numObjects[0];
++numObjects[FGAIBase::otBallistic];
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
ai_ballistic->setAzimuth(entity->azimuth);
ai_ballistic->setElevation(entity->elevation);
ai_ballistic->setSpeed(entity->speed);
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
ai_ballistic->setPath(entity->path.c_str());
Make use of a pointer to a structure to pass multiple parameters around.
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);
Fix a small number of potential problems.
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);
Vivian Meazza: The value of rho (air density) varies with height. (Including the upper stratosphere, ust in case someone wants to model ICBMs.) The standard atmosphere is used (based on a sea-level temperature of 15 deg C.). Erik Hofman: I moved this code over the AIBase::update() so all AIModels can make use of rho, temperature, pressure, etc.
2004-09-22 19:11:36 +00:00
ai_ballistic->setCd(entity->cd);
Vivian Meazza: The calculation of submodel mass from weight has been moved from AIBallistic to Submodel so that it is calculated only once, rather than on every iteration as a present. The parameter <contents> has been added, primarily so that droptanks will have the proper mass. It is the path to an appropriate property containing a weight in lbs. Care has to be taken with the use of <contents> because after a reset there appears to be a delay in submodel instantiation (dt not properly reset???) and the weight property is not always picked up before it is set to zero in the key bindings. Slightly hard to explain. It works fine if FGFS has not been reset though. There is a partial solution which involves the rejigging of the fuel and gui nasal scripts, but there is still the visible delay in instantiation to be resolved. I've nearly done the nasal fixes, which will form part of an update to the Hunter only. I'll probably complete those later today.
2004-09-27 14:24:20 +00:00
ai_ballistic->setMass(entity->mass);
Vivian Meazza: As a result of recent requests, I've implemented the ability to switch off aerodynamic stabilisation: This has to be added to the submodel.xml files: <aero-stabilised>false</aero-stabilised> When false the submodel retains the pitch given at instantiation. It defaults to true.
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();
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
return ai_ballistic;
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
}
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void*
FGAIManager::createStorm( FGAIModelEntity *entity ) {
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
FGAIStorm* ai_storm = new FGAIStorm(this);
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
++numObjects[0];
++numObjects[FGAIBase::otStorm];
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
ai_storm->setHeading(entity->heading);
ai_storm->setSpeed(entity->speed);
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
ai_storm->setPath(entity->path.c_str());
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
ai_storm->setAltitude(entity->altitude);
ai_storm->setLongitude(entity->longitude);
ai_storm->setLatitude(entity->latitude);
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
ai_storm->init();
ai_storm->bind();
Vivian Meazza: The value of rho (air density) varies with height. (Including the upper stratosphere, ust in case someone wants to model ICBMs.) The standard atmosphere is used (based on a sea-level temperature of 15 deg C.). Erik Hofman: I moved this code over the AIBase::update() so all AIModels can make use of rho, temperature, pressure, etc.
2004-09-22 19:11:36 +00:00
ai_list.push_back(ai_storm);
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
return ai_storm;
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
}
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void*
FGAIManager::createThermal( FGAIModelEntity *entity ) {
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
FGAIThermal* ai_thermal = new FGAIThermal(this);
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
++numObjects[0];
++numObjects[FGAIBase::otThermal];
Make use of a pointer to a structure to pass multiple parameters around.
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);
Put the Thermal and Storm support code back in
2004-03-03 20:33:08 +00:00
ai_thermal->init();
ai_thermal->bind();
Vivian Meazza: The value of rho (air density) varies with height. (Including the upper stratosphere, ust in case someone wants to model ICBMs.) The standard atmosphere is used (based on a sea-level temperature of 15 deg C.). Erik Hofman: I moved this code over the AIBase::update() so all AIModels can make use of rho, temperature, pressure, etc.
2004-09-22 19:11:36 +00:00
ai_list.push_back(ai_thermal);
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
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
}
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
2004-09-08 13:21:40 +00:00
void FGAIManager::destroyObject( void* ID ) {
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 = ai_list.begin();
while(ai_list_itr != ai_list.end()) {
if ((*ai_list_itr)->getID() == ID) {
Internally keep track of the number of models per type. This really speeds up searching for the number of submodels of one type.
2004-09-07 19:56:22 +00:00
--numObjects[0];
--numObjects[(*ai_list_itr)->getType()];
Don't forget to unbind() before deleting the class.
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);
Rearrange ID related code. The (this) pointer is now the unique ID of the AIModel which fixes a number of problems along the way.
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;
}
}
// fetch the user's state every 10 sim cycles
void FGAIManager::fetchUserState( void ) {
++dt_count;
if (dt_count == 10) {
user_latitude = fgGetDouble("/position/latitude-deg");
user_longitude = fgGetDouble("/position/longitude-deg");
user_altitude = fgGetDouble("/position/altitude-ft");
user_heading = fgGetDouble("/orientation/heading-deg");
user_pitch = fgGetDouble("/orientation/pitch-deg");
user_yaw = fgGetDouble("/orientation/side-slip-deg");
user_speed = fgGetDouble("/velocities/uBody-fps") * 0.592484;
dt_count = 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
// 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();
}
}
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
Make the scenerio's work again (now for real) and a small number of updates.
2004-09-23 09:39:55 +00:00
void FGAIManager::processScenario( string &filename ) {
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
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++) {
Make use of a pointer to a structure to pass multiple parameters around.
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) {
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
if ( en->m_type == "aircraft") {
createAircraft( en );
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
} else if ( en->m_type == "ship") {
createShip( en );
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
David Culp: Here's code to support a new AICarrier class, which I think will be sufficiently different from a basic AIShip that it should have its own class.
2004-10-28 08:33:55 +00:00
} else if ( en->m_type == "carrier") {
createCarrier( en );
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
} else if ( en->m_type == "thunderstorm") {
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
createStorm( en );
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
} else if ( en->m_type == "thermal") {
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
createThermal( en );
It's usually not a good idea to assign a const char* to a node of a temporary property tree, use string instead.
2004-10-14 09:49:46 +00:00
} else if ( en->m_type == "ballistic") {
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
createBallistic( en );
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
}
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
}
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
}
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
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
delete s;
}
Durk Talsma: Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic can now fly multiple routes and be initialized while sitting statically at airports.
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));
}
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
//end AIManager.cxx
Copy permalink