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

506 lines
15 KiB
C++
Raw Normal View History

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
// FGAIFlightPlan - class for loading and storing AI flight plans
// Written by David Culp, started May 2004
// - 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.
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
Compile again on Win32 platforms
2006-06-16 10:17:06 +00:00
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +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
#include <simgear/misc/sg_path.hxx>
#include <simgear/debug/logstream.hxx>
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
#include <simgear/route/waypoint.hxx>
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
#include <simgear/math/sg_geodesy.hxx>
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
#include <simgear/structure/exception.hxx>
#include <simgear/constants.h>
#ifdef __BORLANDC__
# define exception c_exception
#endif
#include <simgear/props/props.hxx>
#include <Main/globals.hxx>
#include <Main/fg_props.hxx>
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
#include <Main/fg_init.hxx>
#include <Airports/simple.hxx>
#include <Airports/runways.hxx>
#include <Environment/environment_mgr.hxx>
#include <Environment/environment.hxx>
#include "AIFlightPlan.hxx"
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
Alex Romosan: * Use "const string&" rather than "string" in function calls when appropriate. * Use "const Point3D&" instead of "Pint3D" in function calls when appropriate. * Improved course calculation in calc_gc_course_dist() * Safer thread handling code. Vassilii Khachaturov: Dont use "const Point3D&" for return types unless you're absolutely sure. Erik Hofman: * Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than calculating it by hand every time.
2005-10-25 13:49:55 +00:00
FGAIFlightPlan::FGAIFlightPlan(const 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
{
int i;
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
start_time = 0;
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
leg = 10;
gateId = 0;
Spectacular improvement in traffic manager initialization and preparatory work for ground based distance separation of AIAircraft. Traffic manager initialization related changes: - Schedules initialize "on the fly", instead of during initialization - Invalid routes are no longer deleted, but marked as BOGUS and ignored - Changed loading order from a distance based prioritization to a point- score based prioritization, resulting in a much faster establisment of AIAircraft near the user's plane. Preparatory work for ground-based separation of Aircraft. - The groundnetwork findShrortestRoute function not only returns a list of waypoints, but also a list of taxi "segments" (a.k.a. taxiways). - The taxiway list is stored in the Flightplan, and updated everytime a new taxi leg is created.
2006-07-29 18:17:19 +00:00
taxiRoute = 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
SGPath path( globals->get_fg_root() );
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
path.append( ("/AI/FlightPlans/" + filename).c_str() );
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
SGPropertyNode root;
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
repeat = false;
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
try {
readProperties(path.str(), &root);
} catch (const sg_exception &e) {
SG_LOG(SG_GENERAL, SG_ALERT,
commit some pending updates from Vivian
2004-11-16 09:33:21 +00:00
"Error reading AI flight plan: " << path.str());
// cout << path.str() << endl;
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
return;
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
}
Use lower case letters instead.
2004-05-15 12:46:25 +00:00
SGPropertyNode * node = root.getNode("flightplan");
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
for (i = 0; i < node->nChildren(); i++) {
//cout << "Reading waypoint " << i << endl;
waypoint* wpt = new waypoint;
SGPropertyNode * wpt_node = node->getChild(i);
Use lower case letters instead.
2004-05-15 12:46:25 +00:00
wpt->name = wpt_node->getStringValue("name", "END");
wpt->latitude = wpt_node->getDoubleValue("lat", 0);
wpt->longitude = wpt_node->getDoubleValue("lon", 0);
wpt->altitude = wpt_node->getDoubleValue("alt", 0);
wpt->speed = wpt_node->getDoubleValue("ktas", 0);
wpt->crossat = wpt_node->getDoubleValue("crossat", -10000);
wpt->gear_down = wpt_node->getBoolValue("gear-down", false);
wpt->flaps_down= wpt_node->getBoolValue("flaps-down", false);
David Culp: 1. Removed aircraft roll on ground. 2. Decreased descent pitch angle. 3. Updated flightplans to include <on-ground> 4. Fixed property indexing, so all AI aircraft have their own property branch The default value of <on-ground> is false, so you only need to specify it when on the ground. For takeoff you need to specify <on-ground>true</on-ground> for the first waypoint, and for the acceleration waypoint. For landing you need to specify it for the touchdown point and any taxi points. One problem. WARNING **** There is a bug in the way the property system works, which causes a segfault, but I don't know if the problem is in the property code, or in how I'm using it. After an AI object terminates, if you access the property tree through the property browser the sim will segfault.
2004-05-21 16:50:19 +00:00
wpt->on_ground = wpt_node->getBoolValue("on-ground", false);
Vivian MEAZZA: """ "Flight plans" which can start at a given time (gmt) WAITUNTIL tokens which pause the flight plans until a given time (gmt) Submodels can now be attached to any AI objects (except submodels - it can be done, but in my experimental code it's too expensive in frame rate atm) "No-roll" attribute added to Ballistic objects - useful for wakes and the like "Random" attribute added to Ballistic objects (adds =- 5% to the Cd) - useful for smoke, exhausts If the <trigger> tag is not specified the Ballistic object/s will be released at start-up (cannot be stopped) Submodels are not released from AI Objects if the AI Object is more than 15 miles away. """ mf: minor code and formatting fixes; submodels.?xx were FUBAR and are thus astyle formatted; NOTE that <name> tags END, EOF, WAIT, WAITUNTIL are *depreciated*. Don't get too used to them. This will have to be moved from the "name" to regular engries.
2007-03-30 22:51:52 +00:00
wpt->time_sec = wpt_node->getDoubleValue("time-sec", 0);
wpt->time = wpt_node->getStringValue("time", "");
Some small updates that hopefully solve the segmentation fault at the end of the flightplan.
2004-05-18 09:09:08 +00:00
if (wpt->name == "END") wpt->finished = true;
else wpt->finished = false;
waypoints.push_back( wpt );
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
}
wpt_iterator = waypoints.begin();
//cout << waypoints.size() << " waypoints read." << endl;
}
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
// This is a modified version of the constructor,
// Which not only reads the waypoints from a
// Flight plan file, but also adds the current
// Position computed by the traffic manager, as well
// as setting speeds and altitude computed by the
// traffic manager.
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
FGAIFlightPlan::FGAIFlightPlan(const std::string& p,
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
double course,
time_t start,
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
FGAirport *dep,
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
FGAirport *arr,
bool firstLeg,
double radius,
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
double alt,
double lat,
double lon,
double speed,
Alex Romosan: * Use "const string&" rather than "string" in function calls when appropriate. * Use "const Point3D&" instead of "Pint3D" in function calls when appropriate. * Improved course calculation in calc_gc_course_dist() * Safer thread handling code. Vassilii Khachaturov: Dont use "const Point3D&" for return types unless you're absolutely sure. Erik Hofman: * Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than calculating it by hand every time.
2005-10-25 13:49:55 +00:00
const string& fltType,
const string& acType,
const string& airline)
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
{
AI Modifications: 1) Added a patch that takes ground speed into consideration using Curt's new speed adjustment code. 2) Separated the function FlightPlanCreateCruise() into a new source file in preparation of a more elaborate airway following scheme.
2006-07-27 14:42:15 +00:00
repeat = false;
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
leg = 10;
gateId=0;
Spectacular improvement in traffic manager initialization and preparatory work for ground based distance separation of AIAircraft. Traffic manager initialization related changes: - Schedules initialize "on the fly", instead of during initialization - Invalid routes are no longer deleted, but marked as BOGUS and ignored - Changed loading order from a distance based prioritization to a point- score based prioritization, resulting in a much faster establisment of AIAircraft near the user's plane. Preparatory work for ground-based separation of Aircraft. - The groundnetwork findShrortestRoute function not only returns a list of waypoints, but also a list of taxi "segments" (a.k.a. taxiways). - The taxiway list is stored in the Flightplan, and updated everytime a new taxi leg is created.
2006-07-29 18:17:19 +00:00
taxiRoute = 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
start_time = start;
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
bool useInitialWayPoint = true;
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
bool useCurrentWayPoint = false;
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
SGPath path( globals->get_fg_root() );
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
path.append( "/AI/FlightPlans" );
path.append( p );
AI Modifications: 1) Added a patch that takes ground speed into consideration using Curt's new speed adjustment code. 2) Separated the function FlightPlanCreateCruise() into a new source file in preparation of a more elaborate airway following scheme.
2006-07-27 14:42:15 +00:00
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
SGPropertyNode root;
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 is a bit of a hack:
// Normally the value of course will be used to evaluate whether
// or not a waypoint will be used for midair initialization of
// an AI aircraft. However, if a course value of 999 will be passed
// when an update request is received, which will by definition always be
// on the ground and should include all waypoints.
if (course == 999)
{
useInitialWayPoint = false;
useCurrentWayPoint = true;
}
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
if (path.exists())
{
try
{
readProperties(path.str(), &root);
SGPropertyNode * node = root.getNode("flightplan");
//waypoints.push_back( init_waypoint );
for (int i = 0; i < node->nChildren(); i++) {
//cout << "Reading waypoint " << i << endl;
waypoint* wpt = new waypoint;
SGPropertyNode * wpt_node = node->getChild(i);
wpt->name = wpt_node->getStringValue("name", "END");
wpt->latitude = wpt_node->getDoubleValue("lat", 0);
wpt->longitude = wpt_node->getDoubleValue("lon", 0);
wpt->altitude = wpt_node->getDoubleValue("alt", 0);
wpt->speed = wpt_node->getDoubleValue("ktas", 0);
//wpt->speed = speed;
wpt->crossat = wpt_node->getDoubleValue("crossat", -10000);
wpt->gear_down = wpt_node->getBoolValue("gear-down", false);
wpt->flaps_down= wpt_node->getBoolValue("flaps-down", false);
if (wpt->name == "END") wpt->finished = true;
else wpt->finished = false;
waypoints.push_back(wpt);
}
}
catch (const sg_exception &e) {
Fix for an AIFlightPlan initialization problem in the traffic manager.
2006-03-29 18:36:21 +00:00
SG_LOG(SG_GENERAL, SG_WARN,
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
"Error reading AI flight plan: ");
cerr << "Errno = " << errno << endl;
if (errno == ENOENT)
{
cerr << "Reason: No such file or directory" << endl;
}
}
}
else
{
// cout << path.str() << endl;
// cout << "Trying to create this plan dynamically" << endl;
// cout << "Route from " << dep->id << " to " << arr->id << endl;
time_t now = time(NULL) + fgGetLong("/sim/time/warp");
time_t timeDiff = now-start;
leg = 1;
if ((timeDiff > 300) && (timeDiff < 1200))
leg = 2;
else if ((timeDiff >= 1200) && (timeDiff < 1500))
leg = 3;
else if ((timeDiff >= 1500) && (timeDiff < 2000))
leg = 4;
else if (timeDiff >= 2000)
leg = 5;
Fixes and code clean-up: - Airports Directory Thomas Foerster: Pulls out the FGTaxiNode implementation into gnnode.cxx. Melchior / Durk: Copy Constructor and assignment operator for FGTaxiRoute - AIModels Directory Durk / Melchior / Czaba Halasz: Ensure that all derived classes use AIBase member 'callsign'. Adapted, moved and deleted getter/setter functions where necessary Czaba Halasz: Fix AIBase model path vs. submodel path consistency. - Traffic Directory and AIModels CreateFlightPlanCruise DT: Temporary revert parts of the position estimation code.
2007-07-15 14:08:31 +00:00
SG_LOG(SG_GENERAL, SG_INFO, "Route from " << dep->getId() << " to " << arr->getId() << ". Set leg to : " << leg);
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
wpt_iterator = waypoints.begin();
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
create(dep,arr, leg, alt, speed, lat, lon,
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
firstLeg, radius, fltType, acType, airline);
wpt_iterator = waypoints.begin();
//cerr << "after create: " << (*wpt_iterator)->name << endl;
//leg++;
// Now that we have dynamically created a flight plan,
// we need to add some code that pops any waypoints already past.
//return;
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
}
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
/*
waypoint* init_waypoint = new waypoint;
init_waypoint->name = string("initial position");
init_waypoint->latitude = entity->latitude;
init_waypoint->longitude = entity->longitude;
init_waypoint->altitude = entity->altitude;
init_waypoint->speed = entity->speed;
init_waypoint->crossat = - 10000;
init_waypoint->gear_down = false;
init_waypoint->flaps_down = false;
init_waypoint->finished = false;
wpt_vector_iterator i = waypoints.begin();
while (i != waypoints.end())
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
{
//cerr << "Checking status of each waypoint: " << (*i)->name << endl;
SGWayPoint first(init_waypoint->longitude,
init_waypoint->latitude,
init_waypoint->altitude);
SGWayPoint curr ((*i)->longitude,
(*i)->latitude,
(*i)->altitude);
double crse, crsDiff;
double dist;
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
curr.CourseAndDistance(first, &crse, &dist);
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
dist *= SG_METER_TO_NM;
// We're only interested in the absolute value of crsDiff
// wich should fall in the 0-180 deg range.
crsDiff = fabs(crse-course);
if (crsDiff > 180)
crsDiff = 360-crsDiff;
// These are the three conditions that we consider including
// in our flight plan:
// 1) current waypoint is less then 100 miles away OR
// 2) curren waypoint is ahead of us, at any distance
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
if ((dist > 20.0) && (crsDiff > 90.0) && ((*i)->name != string ("EOF")))
{
//useWpt = false;
// Once we start including waypoints, we have to continue, even though
// one of the following way point would suffice.
// so once is the useWpt flag is set to true, we cannot reset it to false.
//cerr << "Discarding waypoint: " << (*i)->name
// << ": Course difference = " << crsDiff
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
// << "Course = " << course
// << "crse = " << crse << endl;
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
}
else
useCurrentWayPoint = true;
if (useCurrentWayPoint)
{
if ((dist > 100.0) && (useInitialWayPoint))
{
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
//waypoints.push_back(init_waypoint);;
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
waypoints.insert(i, init_waypoint);
//cerr << "Using waypoint : " << init_waypoint->name << endl;
}
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
//if (useInitialWayPoint)
// {
// (*i)->speed = dist; // A hack
// }
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
//waypoints.push_back( wpt );
//cerr << "Using waypoint : " << (*i)->name
// << ": course diff : " << crsDiff
// << "Course = " << course
// << "crse = " << crse << endl
// << "distance : " << dist << endl;
useInitialWayPoint = false;
i++;
}
else
{
//delete wpt;
delete *(i);
i = waypoints.erase(i);
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
}
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
}
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
*/
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
//for (i = waypoints.begin(); i != waypoints.end(); i++)
// cerr << "Using waypoint : " << (*i)->name << endl;
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
//wpt_iterator = waypoints.begin();
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
//cout << waypoints.size() << " waypoints read." << endl;
}
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
FGAIFlightPlan::~FGAIFlightPlan()
{
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
deleteWaypoints();
remove redundant if check in cases of if (foo) delete foo; The C++ standard explicitly allows deleting a null pointer.
2007-07-20 14:46:45 +00:00
delete taxiRoute;
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
}
Alex Romosan: I tried to make sure accessor functions which return by reference act on const objects. also replaced some iterators with const_iterator and a few return/pass by reference that were missed the first time around.
2005-10-26 09:03:49 +00:00
FGAIFlightPlan::waypoint* const
FGAIFlightPlan::getPreviousWaypoint( void ) const
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
{
if (wpt_iterator == waypoints.begin()) {
return 0;
} else {
wpt_vector_iterator prev = wpt_iterator;
return *(--prev);
}
}
Alex Romosan: I tried to make sure accessor functions which return by reference act on const objects. also replaced some iterators with const_iterator and a few return/pass by reference that were missed the first time around.
2005-10-26 09:03:49 +00:00
FGAIFlightPlan::waypoint* const
FGAIFlightPlan::getCurrentWaypoint( void ) const
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
{
return *wpt_iterator;
}
Alex Romosan: I tried to make sure accessor functions which return by reference act on const objects. also replaced some iterators with const_iterator and a few return/pass by reference that were missed the first time around.
2005-10-26 09:03:49 +00:00
FGAIFlightPlan::waypoint* const
FGAIFlightPlan::getNextWaypoint( void ) const
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
{
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
wpt_vector_iterator i = waypoints.end();
i--; // end() points to one element after the last one.
if (wpt_iterator == i) {
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
return 0;
} else {
wpt_vector_iterator next = wpt_iterator;
return *(++next);
}
}
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
void FGAIFlightPlan::IncrementWaypoint(bool eraseWaypoints )
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
{
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
if (eraseWaypoints)
{
if (wpt_iterator == waypoints.begin())
wpt_iterator++;
else
{
delete *(waypoints.begin());
waypoints.erase(waypoints.begin());
wpt_iterator = waypoints.begin();
wpt_iterator++;
}
}
else
wpt_iterator++;
Code cleanup of AIModels (mainly AIAircraft), by Thomas Foerster
2007-06-09 11:49:16 +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
}
// gives distance in feet from a position to a waypoint
Alex Romosan: I tried to make sure accessor functions which return by reference act on const objects. also replaced some iterators with const_iterator and a few return/pass by reference that were missed the first time around.
2005-10-26 09:03:49 +00:00
double FGAIFlightPlan::getDistanceToGo(double lat, double lon, waypoint* wp) const{
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
// get size of a degree2 at the present latitude
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
// this won't work over large distances
double ft_per_deg_lat = 366468.96 - 3717.12 * cos(lat / SG_RADIANS_TO_DEGREES);
double ft_per_deg_lon = 365228.16 * cos(lat / SG_RADIANS_TO_DEGREES);
double lat_diff_ft = fabs(wp->latitude - lat) * ft_per_deg_lat;
double lon_diff_ft = fabs(wp->longitude - lon) * ft_per_deg_lon;
return sqrt((lat_diff_ft * lat_diff_ft) + (lon_diff_ft * lon_diff_ft));
}
// sets distance in feet from a lead point to the current waypoint
void FGAIFlightPlan::setLeadDistance(double speed, double bearing,
waypoint* current, waypoint* next){
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
double turn_radius;
if (fabs(speed) > 1)
turn_radius = 0.1911 * speed * speed; // an estimate for 25 degrees bank
else
turn_radius = 1.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
double inbound = bearing;
double outbound = getBearing(current, next);
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
leadInAngle = fabs(inbound - outbound);
if (leadInAngle > 180.0)
leadInAngle = 360.0 - leadInAngle;
if (leadInAngle < 1.0) // To prevent lead_dist from getting so small it is skipped
leadInAngle = 1.0;
lead_distance = turn_radius * sin(leadInAngle * SG_DEGREES_TO_RADIANS);
// if ((errno == EDOM) || (errno == ERANGE) || lead_distance < 1.0)
// {
// cerr << "Lead Distance = " << lead_distance
// << "Diff = " << diff
// << "Turn Radius = " << turn_radius
// << "Speed = " << speed << endl;
// }
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
}
void FGAIFlightPlan::setLeadDistance(double distance_ft){
lead_distance = distance_ft;
}
Alex Romosan: I tried to make sure accessor functions which return by reference act on const objects. also replaced some iterators with const_iterator and a few return/pass by reference that were missed the first time around.
2005-10-26 09:03:49 +00:00
double FGAIFlightPlan::getBearing(waypoint* first, waypoint* second) const{
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
return getBearing(first->latitude, first->longitude, second);
}
Alex Romosan: I tried to make sure accessor functions which return by reference act on const objects. also replaced some iterators with const_iterator and a few return/pass by reference that were missed the first time around.
2005-10-26 09:03:49 +00:00
double FGAIFlightPlan::getBearing(double lat, double lon, waypoint* wp) const{
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
double course, distance;
// double latd = lat;
// double lond = lon;
// double latt = wp->latitude;
// double lont = wp->longitude;
// double ft_per_deg_lat = 366468.96 - 3717.12 * cos(lat/SG_RADIANS_TO_DEGREES);
// double ft_per_deg_lon = 365228.16 * cos(lat/SG_RADIANS_TO_DEGREES);
// if (lond < 0.0) {
// lond+=360.0;
// lont+=360;
// }
// if (lont < 0.0) {
// lond+=360.0;
// lont+=360.0;
// }
// latd+=90.0;
// latt+=90.0;
// double lat_diff = (latt - latd) * ft_per_deg_lat;
// double lon_diff = (lont - lond) * ft_per_deg_lon;
// double angle = atan(fabs(lat_diff / lon_diff)) * SG_RADIANS_TO_DEGREES;
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
// bool southerly = true;
// if (latt > latd) southerly = false;
// bool easterly = false;
// if (lont > lond) easterly = true;
// if (southerly && easterly) return 90.0 + angle;
// if (!southerly && easterly) return 90.0 - angle;
// if (southerly && !easterly) return 270.0 - angle;
// if (!southerly && !easterly) return 270.0 + angle;
SGWayPoint sgWp(wp->longitude,wp->latitude, wp->altitude, SGWayPoint::WGS84, string("temp"));
sgWp.CourseAndDistance(lon, lat, wp->altitude, &course, &distance);
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
return course;
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
// Omit a compiler warning.
//if ((errno == EDOM) || (errno == ERANGE))
// {
// cerr << "Lon: " << wp->longitude
// << "Lat = " << wp->latitude
// << "Tgt Lon = " <<
// << "TgT Lat = " << speed << endl;
// }
Some small updates that hopefully solve the segmentation fault at the end of the flightplan.
2004-05-18 09:09:08 +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
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
void FGAIFlightPlan::deleteWaypoints()
{
for (wpt_vector_iterator i = waypoints.begin(); i != waypoints.end();i++)
delete (*i);
waypoints.clear();
}
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
// Delete all waypoints except the last,
// which we will recycle as the first waypoint in the next leg;
void FGAIFlightPlan::resetWaypoints()
{
if (waypoints.begin() == waypoints.end())
return;
else
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +00:00
{
Durk Talsma: I just heard from John Wojnaroski that you and he are going to work on getting a flightgear demo machine up for the linux expo thursday and Friday. John indicated that he would very much like to get a CVS version with the new traffic code up and running before the expo.
2005-02-10 09:01:51 +00:00
waypoint *wpt = new waypoint;
wpt_vector_iterator i = waypoints.end();
i--;
wpt->name = (*i)->name;
wpt->latitude = (*i)->latitude;
wpt->longitude = (*i)->longitude;
wpt->altitude = (*i)->altitude;
wpt->speed = (*i)->speed;
wpt->crossat = (*i)->crossat;
wpt->gear_down = (*i)->gear_down;
wpt->flaps_down= (*i)->flaps_down;
wpt->finished = false;
wpt->on_ground = (*i)->on_ground;
//cerr << "Recycling waypoint " << wpt->name << endl;
deleteWaypoints();
waypoints.push_back(wpt);
Durk Talsma: I've included the latest fixes to the Traffic Manager/AI flightplan generation code. Most of the code changes are in AIFllightplan.cxx. This is the code that runs without depending on predefined FlightPlans in #FG_ROOT/Data/AI/Flightplans.i As suggested by Dave, I've also added a new property in preferences.xml: /sim/traffic-manager/enabled, which is used to control whether or not the traffic manager is active. I'm still working on a few more 737 traffic patterns, those are going to take a little longer, so I didn't want to wait sending in this code. Finally, I haven't put much effort into ensuring "aeronautical correctness" in this version yet. The code works on my system, but what the AI plane do may actaully be quite rediculous. But I'd like to leave that for the next version.
2004-07-22 18:50:29 +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
// Start flightplan over from the beginning
void FGAIFlightPlan::restart()
{
wpt_iterator = waypoints.begin();
}
Ground network distance tracking code. AIAircraft taxiing at airports maintain a resonable distance from each other while taxiing on the same route. The current code does not yet take crossing routes or aircraft taxiing into opposite directions into account.
2006-08-26 07:22:20 +00:00
void FGAIFlightPlan::deleteTaxiRoute()
{
remove redundant if check in cases of if (foo) delete foo; The C++ standard explicitly allows deleting a null pointer.
2007-07-20 14:46:45 +00:00
delete taxiRoute;
Ground network distance tracking code. AIAircraft taxiing at airports maintain a resonable distance from each other while taxiing on the same route. The current code does not yet take crossing routes or aircraft taxiing into opposite directions into account.
2006-08-26 07:22:20 +00:00
taxiRoute = 0;
}
int FGAIFlightPlan::getRouteIndex(int i) {
if ((i > 0) && (i < waypoints.size())) {
return waypoints[i]->routeIndex;
}
else
return 0;
}
Copy permalink