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

323 lines
9.8 KiB
C++
Raw Normal View History

Add David Culp's AI model manager code which is derived from David Luff's AI/ATC code.
2003-11-28 15:48:05 +00:00
// AIManager.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
new FSF address
2006-02-21 01:16:04 +00:00
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
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 <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/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 "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"
David Culp: I added an AIStatic object to my OV-10 sim for use in putting city signs, vehicles, or anything else that will be static, but that I don't want to put in the scenery files. It's inexpensive. Before, I was making such things from AIShip. I also added the ability to set flight plans to repeat, so that when an airplane reaches the end it just starts over at the beginning. This is useful for my OV-10 sim. I have C-141 and KC-135 traffic flying approaches to Ramstein, and I only have to define two AI objects to do this. Also, I found an inefficiency in AIBase, where every AI object was calculating Mach number at every dt. Now only AIBallistic objects do this.
2005-06-04 09:38:52 +00:00
#include "AIStatic.hxx"
Vivian Meazza: This patch is a combined effort by Gregor Richards, Oliver Schroeder, and Vivian Meazza (and code cleanups and improvements by Erik Hofman). It corrects the bug in which a Multiplayer model responds to local inputs, and the view number bug which caused certain aircraft to appear as cockpit only models. It passes remote properties over the net, and all major control surfaces and gear are now animated correctly, providing that the local ~model.xml file contains no leading "/" in the <property></property> data entries. MP objects are now extrapolated using 1st and 2nd derivatives to make their movement appear more smooth. The sim is now halted while a new client joins the net. Known problems with MP are non-display of the remote client under certain circumstances of starting/resetting, and a freeze on starting. These bugs are long standing, and are not addressed by this patch. Special thanks must go to AJ Macleod for his patient testing of this patch over many evenings. We have also moved part of multiplayer into AIModels as part of the ongoing development of MP.
2006-02-09 12:29:05 +00:00
#include "AIMultiplayer.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
FGAIManager::FGAIManager() {
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;
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
mNumAiModels = 0;
Mathias Fröhlich: Fix the AI-Radar code.
2006-03-04 12:49:30 +00:00
for (unsigned i = 0; i < FGAIBase::MAX_OBJECTS; ++i)
mNumAiTypeModels[i] = 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
}
FGAIManager::~FGAIManager() {
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
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()) {
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
++ai_list_itr;
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +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
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);
Vivian Meazza: Some quite extensive changes to the AIModel code: 1. Mathias has made major changes to the AICarrier code to provide better alignment of an aircraft on deck with the carrier - this feature is a major improvement on the existing, but has a bug which might cause it to fail when the computer carries out other tasks - changing window size is a known example. This bug is outwith this code. 2. I have made significant changes to the AIShip code to enable a ship the turn and roll smoothly. 3. I have added some simple AI which enables the carrier to remain within, or return to, an operating box. 4. An automated turn into wind for flying operations. 5. A simplistic implementation of TACAN within AICarrier. I am in the course of implementing this as a generic instrument, but this is some time off completion.
2005-08-16 09:37:23 +00:00
wind_from_east_node = fgGetNode("/environment/wind-from-east-fps",true);
wind_from_north_node = fgGetNode("/environment/wind-from-north-fps",true);
David Culp: I'm looking through the AI code, trying to find the bug that's killing the thermals. The following things don't look right: 1) AIManager::101 , the Traffic Manager pointer is searched for by name at every dt. I'll leave this for you to look at. 2) AIManager::295 , the thermal height is not being set. We need to restore the line: ai_thermal->setHeight(entity->height_msl); This fixes the thermal problem. 3) AIManager::328 , I changed the fetching of the user state to occur every sim cycle, and changed the fetching function from by-name lookup to a lookup by node pointer. It should be faster now, and more accurate too. This helps the air-refueling.
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);
allow AI models to contain <nasal><load> and <nasal><unload> blocks in their XML wrapper/animation file. They can access their /ai/models node via cmdarg() function. Example: <nasal> <load> print("Hi, I'm the Nimitz. My data are under ", cmdarg().getPath()); </load> <unload> ... </unload> </nasal> Note, however, that the <unload> block is only called on exit at the moment, not when the tile is unloaded.
2007-04-01 12:39:20 +00:00
}
Make the scenarios work again.
2004-09-22 11:24:45 +00:00
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
allow AI models to contain <nasal><load> and <nasal><unload> blocks in their XML wrapper/animation file. They can access their /ai/models node via cmdarg() function. Example: <nasal> <load> print("Hi, I'm the Nimitz. My data are under ", cmdarg().getPath()); </load> <unload> ... </unload> </nasal> Note, however, that the <unload> block is only called on exit at the moment, not when the tile is unloaded.
2007-04-01 12:39:20 +00:00
void FGAIManager::postinit() {
// postinit, so that it can access the Nasal subsystem
Harald JOHNSEN: - AIManager.cxx : - we can now have multiple <scenario> entries in the sim/ai entry in preferences.xml - AIBase.cxx : - added an exception handler around the loading of the 3D model to not exit FG if the model is not found - AIScenario.cxx : - removed a duplicated read of the xml file, this was also exiting FG is the xml file does not exist
2005-07-24 14:05:28 +00:00
for(int i = 0 ; i < root->nChildren() ; i++) {
SGPropertyNode *aiEntry = root->getChild( i );
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
if( !strcmp( aiEntry->getName(), "scenario" ) ) {
Harald JOHNSEN: - AIManager.cxx : - we can now have multiple <scenario> entries in the sim/ai entry in preferences.xml - AIBase.cxx : - added an exception handler around the loading of the 3D model to not exit FG if the model is not found - AIScenario.cxx : - removed a duplicated read of the xml file, this was also exiting FG is the xml file does not exist
2005-07-24 14:05:28 +00:00
scenario_filename = aiEntry->getStringValue();
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
if (!scenario_filename.empty())
processScenario( scenario_filename );
}
Harald JOHNSEN: - AIManager.cxx : - we can now have multiple <scenario> entries in the sim/ai entry in preferences.xml - AIBase.cxx : - added an exception handler around the loading of the 3D model to not exit FG if the model is not found - AIScenario.cxx : - removed a duplicated read of the xml file, this was also exiting FG is the xml file does not exist
2005-07-24 14:05:28 +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
}
Mathias Fröhlich: I have traced that reset on carrier problem down to several problems. One of them is the fact that on reset the carrier is updated while the aircraft is not. That made the aircraft drop down an elevator sometimes. Depending on the passed realtime while loading some parts of the scenery.
2005-07-13 12:25:16 +00:00
void FGAIManager::reinit() {
update(0.0);
Vivian MEAZZA: call AI models' ::reinit() methods on reinit
2007-02-26 11:47:04 +00:00
ai_list_iterator ai_list_itr = ai_list.begin();
while(ai_list_itr != ai_list.end()) {
(*ai_list_itr)->reinit();
++ai_list_itr;
}
Mathias Fröhlich: I have traced that reset on carrier problem down to several problems. One of them is the fact that on reset the carrier is updated while the aircraft is not. That made the aircraft drop down an elevator sometimes. Depending on the passed realtime while loading some parts of the scenery.
2005-07-13 12:25:16 +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::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);
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
root->tie("count", SGRawValueMethods<FGAIManager, int>(*this,
&FGAIManager::getNumAiObjects));
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) {
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
// initialize these for finding nearest thermals
range_nearest = 10000.0;
strength = 0.0;
if (!enabled)
return;
FGTrafficManager *tmgr = (FGTrafficManager*) globals->get_subsystem("Traffic Manager");
_dt = dt;
ai_list_iterator ai_list_itr = ai_list.begin();
while(ai_list_itr != ai_list.end()) {
if ((*ai_list_itr)->getDie()) {
tmgr->release((*ai_list_itr)->getID());
--mNumAiModels;
Mathias Fröhlich: Fix the AI-Radar code.
2006-03-04 12:49:30 +00:00
--(mNumAiTypeModels[(*ai_list_itr)->getType()]);
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
(*ai_list_itr)->unbind();
ai_list_itr = ai_list.erase(ai_list_itr);
} else {
fetchUserState();
if ((*ai_list_itr)->isa(FGAIBase::otThermal)) {
FGAIBase *base = *ai_list_itr;
processThermal((FGAIThermal*)base);
} else {
(*ai_list_itr)->update(_dt);
}
++ai_list_itr;
}
}
wind_from_down_node->setDoubleValue( strength ); // for thermals
Vivian Meazza: This patch is a combined effort by Gregor Richards, Oliver Schroeder, and Vivian Meazza (and code cleanups and improvements by Erik Hofman). It corrects the bug in which a Multiplayer model responds to local inputs, and the view number bug which caused certain aircraft to appear as cockpit only models. It passes remote properties over the net, and all major control surfaces and gear are now animated correctly, providing that the local ~model.xml file contains no leading "/" in the <property></property> data entries. MP objects are now extrapolated using 1st and 2nd derivatives to make their movement appear more smooth. The sim is now halted while a new client joins the net. Known problems with MP are non-display of the remote client under certain circumstances of starting/resetting, and a freeze on starting. These bugs are long standing, and are not addressed by this patch. Special thanks must go to AJ Macleod for his patient testing of this patch over many evenings. We have also moved part of multiplayer into AIModels as part of the ongoing development of MP.
2006-02-09 12:29:05 +00:00
}
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
void
FGAIManager::attach(SGSharedPtr<FGAIBase> model)
{
Mathias Fröhlich: Fix the AI-Radar code.
2006-03-04 12:49:30 +00:00
unsigned idx = mNumAiTypeModels[model->getType()];
const char* typeString = model->getTypeString();
SGPropertyNode* root = globals->get_props()->getNode("ai/models", true);
Maik Justus, Here is a patch for two bugs in the AI/multiplayer part: 1. Cannot find model file *.ac error message (was only a false message, anything worked correctly, the model was loaded from the correct path afterwards). 2. Often many multiplayer aircrafts are missing in the property-tree. (but I need them for aerotowing). There is still another bug: The property in some circumstances seems not to be cleaned up after logout of a multiplayer. I have added a workaround for this, but I don't now, if it 100% works (should have no side effects, just aerotow would not work sometimes). For testing I need more traffic on the mp-server.
2007-01-13 09:04:07 +00:00
SGPropertyNode* p;
int i;
for (i=0;i<10000;i++) //find free index in the property tree, if we have
//more than 10000 mp-aircrafts in the property tree we should optimize the mp-server
{
p = root->getNode(typeString, i, false);
if (!p) break;
if (p->getIntValue("id",-1)==model->getID())
{
p->setStringValue("callsign","***invalid node***"); //debug only, should never set!
}
}
p = root->getNode(typeString, i, true);
Mathias Fröhlich: Fix the AI-Radar code.
2006-03-04 12:49:30 +00:00
model->setManager(this, p);
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
ai_list.push_back(model);
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
++mNumAiModels;
Mathias Fröhlich: Fix the AI-Radar code.
2006-03-04 12:49:30 +00:00
++(mNumAiTypeModels[model->getType()]);
Maik Justus, Here is a patch for two bugs in the AI/multiplayer part: 1. Cannot find model file *.ac error message (was only a false message, anything worked correctly, the model was loaded from the correct path afterwards). 2. Often many multiplayer aircrafts are missing in the property-tree. (but I need them for aerotowing). There is still another bug: The property in some circumstances seems not to be cleaned up after logout of a multiplayer. I have added a workaround for this, but I don't now, if it 100% works (should have no side effects, just aerotow would not work sometimes). For testing I need more traffic on the mp-server.
2007-01-13 09:04:07 +00:00
model->init(model->getType()==FGAIBase::otAircraft
|| model->getType()==FGAIBase::otMultiplayer
|| model->getType()==FGAIBase::otStatic);
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
model->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
}
David Culp: I added an AIStatic object to my OV-10 sim for use in putting city signs, vehicles, or anything else that will be static, but that I don't want to put in the scenery files. It's inexpensive. Before, I was making such things from AIShip. I also added the ability to set flight plans to repeat, so that when an airplane reaches the end it just starts over at the beginning. This is useful for my OV-10 sim. I have C-141 and KC-135 traffic flying approaches to Ramstein, and I only have to define two AI objects to do this. Also, I found an inefficiency in AIBase, where every AI object was calculating Mach number at every dt. Now only AIBallistic objects do this.
2005-06-04 09:38:52 +00:00
Don't use the this pointer for referencing the AIModels anymore, this turns out to get problematic on 64-bit systems. Instead use a regular int based approach.
2005-10-15 14:55:51 +00:00
void FGAIManager::destroyObject( int ID ) {
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
ai_list_iterator ai_list_itr = ai_list.begin();
while(ai_list_itr != ai_list.end()) {
if ((*ai_list_itr)->getID() == ID) {
--mNumAiModels;
Mathias Fröhlich: Fix the AI-Radar code.
2006-03-04 12:49:30 +00:00
--(mNumAiTypeModels[(*ai_list_itr)->getType()]);
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
(*ai_list_itr)->unbind();
ai_list_itr = ai_list.erase(ai_list_itr);
} else
++ai_list_itr;
}
David Culp: Here's a new batch of AI code which includes a working radar instrument. I put the radar calculations into the existing AIAircraft class. It was easier that way, and it can always be migrated out later if we have to. Every tenth sim cycle the AIManager makes a copy of the current user state information. When the AIAircraft updates it uses this information to calculate the radar numbers. It calculates: 1) bearing from user to target 2) range to target in nautical miles 3) "horizontal offset" to target. This is the angle from the nose to the target, in degrees, from -180 to 180. This will be useful later for a HUD. 4) elevation, in degrees (vertical angle from user's position to target position) 5) vertical offset, in degrees (this is elevation corrected for user's pitch) 6) rdot (range rate in knots, note: not working yet, so I commented it out) and three items used by the radar instrument to place the "blip" 7) y_shift, in nautical miles 8) x_shift, in nautical miles 9) rotation, in degrees The radar instrument uses the above three items, and applies a scale factor to the x-shift and y-shift in order to match the instrument's scale. Changing the display scale can be done entirely in the XML code for the instrument. Right now it's set up only to display a 40 mile scale. The radar is an AWACS view, which is not very realistic, but it is useful and demonstrates the technology. With just a little more work I can get a HUD marker. All I need to do there is make a bank angle adjustment to the current values.
2004-02-27 10:20:17 +00:00
}
Mathias Fröhlich: The new multiplayer patch with an extension to transmit some properties with the base package. The properties are transmitted in a way that will not immediately brake the packet format if we need new ones. Even if the maxmimum number needs to be limited somehow, that format might work well until we have an improoved packet format which is even more compact and that does not require to retransmit redundant information with each packet. That part is relatively fresh and based on that what Oliver provides on his multiplayer server web page. The properties are transferred to the client and I have modified the seahawks rudder animation property to use a relative property path to verify that it works appart from the fact that you can see it changing in the property browser. The movement is still a bit jerky, but that can be fixed/tuned later without again braking the packet format.
2006-02-17 09:43:33 +00:00
int
FGAIManager::getNumAiObjects(void) const
{
return mNumAiModels;
}
David Culp: I'm looking through the AI code, trying to find the bug that's killing the thermals. The following things don't look right: 1) AIManager::101 , the Traffic Manager pointer is searched for by name at every dt. I'll leave this for you to look at. 2) AIManager::295 , the thermal height is not being set. We need to restore the line: ai_thermal->setHeight(entity->height_msl); This fixes the thermal problem. 3) AIManager::328 , I changed the fetching of the user state to occur every sim cycle, and changed the fetching function from by-name lookup to a lookup by node pointer. It should be faster now, and more accurate too. This helps the air-refueling.
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 ) {
David Culp: I'm looking through the AI code, trying to find the bug that's killing the thermals. The following things don't look right: 1) AIManager::101 , the Traffic Manager pointer is searched for by name at every dt. I'll leave this for you to look at. 2) AIManager::295 , the thermal height is not being set. We need to restore the line: ai_thermal->setHeight(entity->height_msl); This fixes the thermal problem. 3) AIManager::328 , I changed the fetching of the user state to occur every sim cycle, and changed the fetching function from by-name lookup to a lookup by node pointer. It should be faster now, and more accurate too. This helps the air-refueling.
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;
Vivian Meazza: Some quite extensive changes to the AIModel code: 1. Mathias has made major changes to the AICarrier code to provide better alignment of an aircraft on deck with the carrier - this feature is a major improvement on the existing, but has a bug which might cause it to fail when the computer carries out other tasks - changing window size is a known example. This bug is outwith this code. 2. I have made significant changes to the AIShip code to enable a ship the turn and roll smoothly. 3. I have added some simple AI which enables the carrier to remain within, or return to, an operating box. 4. An automated turn into wind for flying operations. 5. A simplistic implementation of TACAN within AICarrier. I am in the course of implementing this as a generic instrument, but this is some time off completion.
2005-08-16 09:37:23 +00:00
wind_from_east = wind_from_east_node->getDoubleValue();
wind_from_north = wind_from_north_node->getDoubleValue();
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();
}
}
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
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 ) {
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
SGPropertyNode_ptr scenarioTop = loadScenarioFile(filename);
if (!scenarioTop)
return;
SGPropertyNode* scenarios = scenarioTop->getChild("scenario");
if (!scenarios)
return;
for (int i = 0; i < scenarios->nChildren(); i++) {
SGPropertyNode* scEntry = scenarios->getChild(i);
Csaba HALASZ: don't treat every entry in a scenario file as model entry, especially those called <description>. This was responsible for the aircraft at --lon=0 --lat=0.
2007-04-02 12:47:26 +00:00
if (strcmp(scEntry->getName(), "entry"))
continue;
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
std::string type = scEntry->getStringValue("type", "aircraft");
if (type == "aircraft") {
FGAIAircraft* aircraft = new FGAIAircraft;
aircraft->readFromScenario(scEntry);
attach(aircraft);
} else if (type == "ship") {
FGAIShip* ship = new FGAIShip;
ship->readFromScenario(scEntry);
attach(ship);
} else if (type == "carrier") {
FGAICarrier* carrier = new FGAICarrier;
carrier->readFromScenario(scEntry);
attach(carrier);
} else if (type == "thunderstorm") {
FGAIStorm* storm = new FGAIStorm;
storm->readFromScenario(scEntry);
attach(storm);
} else if (type == "thermal") {
FGAIThermal* thermal = new FGAIThermal;
thermal->readFromScenario(scEntry);
attach(thermal);
} else if (type == "ballistic") {
FGAIBallistic* ballistic = new FGAIBallistic;
ballistic->readFromScenario(scEntry);
attach(ballistic);
} else if (type == "static") {
FGAIStatic* aistatic = new FGAIStatic;
aistatic->readFromScenario(scEntry);
attach(aistatic);
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
}
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +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
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
SGPropertyNode_ptr
FGAIManager::loadScenarioFile(const std::string& filename)
{
SGPath path(globals->get_fg_root());
path.append("AI/" + filename + ".xml");
try {
SGPropertyNode_ptr root = new SGPropertyNode;
readProperties(path.str(), root);
return root;
} catch (const sg_exception &e) {
SG_LOG(SG_GENERAL, SG_ALERT, "Incorrect path specified for AI "
"scenario: \"" << path.str() << "\"");
return 0;
}
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
}
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,
Mathias Fröhlich: This patch makes use of the vectors now available in simgear with that past patch. And using that it simplyfies the carrier code somehow. - Small additional factory's to the quaternion code are done in the simgear part. Also more explicit unit names in the factory functions. - The flightgear part makes use of them and simplyfies some computations especially in the carrier code. - The data part fixes the coordinate frames I used for the park positions in the carrier to match the usual ones. I believed that I had done so, but it was definitly different. Also there are more parking positions avaliable now.
2006-02-19 17:28:31 +00:00
SGGeod& geodPos, double& hdng, SGVec3d& uvw)
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
{
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
bool found = false;
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
SGPropertyNode* root = fgGetNode("sim/ai", true);
if (!root->getNode("enabled", true)->getBoolValue())
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
return found;
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
Harald JOHNSEN: - AIManager.cxx : - we can now have multiple <scenario> entries in the sim/ai entry in preferences.xml - AIBase.cxx : - added an exception handler around the loading of the 3D model to not exit FG if the model is not found - AIScenario.cxx : - removed a duplicated read of the xml file, this was also exiting FG is the xml file does not exist
2005-07-24 14:05:28 +00:00
for(int i = 0 ; (!found) && i < root->nChildren() ; i++) {
SGPropertyNode *aiEntry = root->getChild( i );
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
if( !strcmp( aiEntry->getName(), "scenario" ) ) {
string filename = aiEntry->getStringValue();
SGPropertyNode_ptr scenarioTop = loadScenarioFile(filename);
if (scenarioTop) {
SGPropertyNode* scenarios = scenarioTop->getChild("scenario");
if (scenarios) {
for (int i = 0; i < scenarios->nChildren(); i++) {
SGPropertyNode* scEntry = scenarios->getChild(i);
std::string type = scEntry->getStringValue("type");
std::string pnumber = scEntry->getStringValue("pennant-number");
std::string name = scEntry->getStringValue("name");
if (type == "carrier" && (pnumber == id || name == id)) {
SGSharedPtr<FGAICarrier> carrier = new FGAICarrier;
carrier->readFromScenario(scEntry);
Mathias Fröhlich: This patch makes use of the vectors now available in simgear with that past patch. And using that it simplyfies the carrier code somehow. - Small additional factory's to the quaternion code are done in the simgear part. Also more explicit unit names in the factory functions. - The flightgear part makes use of them and simplyfies some computations especially in the carrier code. - The data part fixes the coordinate frames I used for the park positions in the carrier to match the usual ones. I believed that I had done so, but it was definitly different. Also there are more parking positions avaliable now.
2006-02-19 17:28:31 +00:00
if (carrier->getParkPosition(pid, geodPos, hdng, uvw)) {
Harald JOHNSEN: - AIManager.cxx : - we can now have multiple <scenario> entries in the sim/ai entry in preferences.xml - AIBase.cxx : - added an exception handler around the loading of the 3D model to not exit FG if the model is not found - AIScenario.cxx : - removed a duplicated read of the xml file, this was also exiting FG is the xml file does not exist
2005-07-24 14:05:28 +00:00
found = true;
break;
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
}
Harald JOHNSEN: - AIManager.cxx : - we can now have multiple <scenario> entries in the sim/ai entry in preferences.xml - AIBase.cxx : - added an exception handler around the loading of the 3D model to not exit FG if the model is not found - AIScenario.cxx : - removed a duplicated read of the xml file, this was also exiting FG is the xml file does not exist
2005-07-24 14:05:28 +00:00
}
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
}
Harald JOHNSEN: - AIManager.cxx : - we can now have multiple <scenario> entries in the sim/ai entry in preferences.xml - AIBase.cxx : - added an exception handler around the loading of the 3D model to not exit FG if the model is not found - AIScenario.cxx : - removed a duplicated read of the xml file, this was also exiting FG is the xml file does not exist
2005-07-24 14:05:28 +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
}
}
return found;
}
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
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