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

177 lines
6.2 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
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
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, 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
#ifndef _FG_AIFLIGHTPLAN_HXX
#define _FG_AIFLIGHTPLAN_HXX
#include <simgear/compiler.h>
#include <vector>
#include <string>
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
Development for two new features: * Some support for geometry information provided by the custom scenery project. Current support is for AI groundnets and runway use files only since this is a switch that involves a lot of data verification and updating, during the transistion the actual path where the data can be read from is user configurable. setting the property /sim/traffic-manager/use-custom-scenery-data to true will cause flightgear to read the ground networks from the scenery directory (--{fg-scenery}/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml to be precise). Setting this property to false will retain the original behvior. * For departing aircraft, runway takeoff calculations will be done on the basis of the performance database. For testing purposes, a performance estimate for a heavy jet has been added.
2009-01-30 18:48:44 +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
#include <Airports/simple.hxx>
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
#include <Navaids/awynet.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
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
#include "AIBase.hxx"
Development for two new features: * Some support for geometry information provided by the custom scenery project. Current support is for AI groundnets and runway use files only since this is a switch that involves a lot of data verification and updating, during the transistion the actual path where the data can be read from is user configurable. setting the property /sim/traffic-manager/use-custom-scenery-data to true will cause flightgear to read the ground networks from the scenery directory (--{fg-scenery}/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml to be precise). Setting this property to false will retain the original behvior. * For departing aircraft, runway takeoff calculations will be done on the basis of the performance database. For testing purposes, a performance estimate for a heavy jet has been added.
2009-01-30 18:48:44 +00:00
- remove the SG_GLxxxx_H #defines, since OSG provides its own versions - this exposed a bizarre issue on Mac where dragging in <AGL/agl.h> in extensions.hxx was pulling in all of Carbon to the global namespace - very scary. As a result, I now need to explicitly include CoreFoundation in fg_init.cxx. - change SG_USING_STD(x) to using std::x
2008-07-27 16:25:13 +00:00
using std::vector;
using std::string;
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
James Turner: Improved runway management code: - Runways are now part of an airport, instead of a separate list - Runways are no longer represented as a boring struct, but as a class of their own. -Improved runway access to unify various runway access methods.
2008-08-14 18:13:39 +00:00
class FGTaxiRoute;
James Turner: Convert FGRunway to be heap-based, and inherit FGPositioned. This is a large, ugly change, since FGRunway was essentially a plain struct, with no accessors or abstraction. This change adds various helpers and accessors to FGRunway, but doesn't change many places to use them - that will be a follow up series of patches. It's still a large patch, but outside of FGAirport and FGRunway, mostly mechanical search-and-replace. An interesting part of this change is that reciprocal runways now exist as independent objects, rather than being created on the fly by the search methods. This simplifies some pieces of code that search for and iterate runways. For users who only want one 'end' of a runway, the new 'isReciprocal' predicate allows them to ignore the 'other' end. Current the only user of this is the 'ground-radar' ATC feature. If we had data on which runways are truly 'single-ended', it would now be trivial to use this in the airport loader to *not* create the reciprocal.
2008-09-11 08:38:09 +00:00
class FGRunway;
Development for two new features: * Some support for geometry information provided by the custom scenery project. Current support is for AI groundnets and runway use files only since this is a switch that involves a lot of data verification and updating, during the transistion the actual path where the data can be read from is user configurable. setting the property /sim/traffic-manager/use-custom-scenery-data to true will cause flightgear to read the ground networks from the scenery directory (--{fg-scenery}/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml to be precise). Setting this property to false will retain the original behvior. * For departing aircraft, runway takeoff calculations will be done on the basis of the performance database. For testing purposes, a performance estimate for a heavy jet has been added.
2009-01-30 18:48:44 +00:00
class FGAIAircraft;
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
class FGAIFlightPlan {
public:
typedef struct {
string name;
double latitude;
double longitude;
double altitude;
double speed;
double crossat;
Some small updates that hopefully solve the segmentation fault at the end of the flightplan.
2004-05-18 09:09:08 +00:00
bool finished;
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
bool gear_down;
bool flaps_down;
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
bool on_ground;
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
int routeIndex; // For AI/ATC purposes;
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
double time_sec;
string time;
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
} waypoint;
A set of additions related to allow the use of SID and STAR procedures. The current code still has some rough edges, in particular memory still needs to be deallocated where possible, and the actual use of the code needs more testing. This code has been running without noticable problems, so I think it's ready for some wider exposure. Detailed changes include: - Finetuning of the SID/STAR data concept. - Preloading of all SIDs, from one xml file. - ATC determines which SID should be used and echoes this over the com1 or com2 radio.
2009-03-08 17:14:05 +00:00
FGAIFlightPlan();
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
FGAIFlightPlan(const string& filename);
Development for two new features: * Some support for geometry information provided by the custom scenery project. Current support is for AI groundnets and runway use files only since this is a switch that involves a lot of data verification and updating, during the transistion the actual path where the data can be read from is user configurable. setting the property /sim/traffic-manager/use-custom-scenery-data to true will cause flightgear to read the ground networks from the scenery directory (--{fg-scenery}/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml to be precise). Setting this property to false will retain the original behvior. * For departing aircraft, runway takeoff calculations will be done on the basis of the performance database. For testing purposes, a performance estimate for a heavy jet has been added.
2009-01-30 18:48:44 +00:00
FGAIFlightPlan(FGAIAircraft *,
const std::string& p,
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
double course,
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
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);
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();
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
waypoint* const getPreviousWaypoint( void ) const;
waypoint* const getCurrentWaypoint( void ) const;
waypoint* const getNextWaypoint( void ) 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
void IncrementWaypoint( bool erase );
AIGroundVehicle from Vivian Meazza
2009-08-25 09:54:49 +00:00
void DecrementWaypoint( bool erase );
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
double getDistanceToGo(double lat, double lon, waypoint* wp) const;
int getLeg () const { return leg;};
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 setLeadDistance(double speed, double bearing, waypoint* current, waypoint* next);
void setLeadDistance(double distance_ft);
double getLeadDistance( void ) const {return lead_distance;}
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 getBearing(waypoint* previous, waypoint* next) const;
double getBearing(double lat, double lon, waypoint* next) const;
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
time_t getStartTime() const { return start_time; }
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
Development for two new features: * Some support for geometry information provided by the custom scenery project. Current support is for AI groundnets and runway use files only since this is a switch that involves a lot of data verification and updating, during the transistion the actual path where the data can be read from is user configurable. setting the property /sim/traffic-manager/use-custom-scenery-data to true will cause flightgear to read the ground networks from the scenery directory (--{fg-scenery}/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml to be precise). Setting this property to false will retain the original behvior. * For departing aircraft, runway takeoff calculations will be done on the basis of the performance database. For testing purposes, a performance estimate for a heavy jet has been added.
2009-01-30 18:48:44 +00:00
void create(FGAIAircraft *, FGAirport *dep, FGAirport *arr, int leg, double alt, double speed, double lat, double lon,
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
bool firstLeg, double radius, const string& fltType, const string& aircraftType, const string& airline);
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
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
void setLeg(int val) { leg = val;}
void setTime(time_t st) { start_time = st; }
int getGate() const { return gateId; }
double getLeadInAngle() const { return leadInAngle; }
James Turner: Convert FGRunway to be heap-based, and inherit FGPositioned. This is a large, ugly change, since FGRunway was essentially a plain struct, with no accessors or abstraction. This change adds various helpers and accessors to FGRunway, but doesn't change many places to use them - that will be a follow up series of patches. It's still a large patch, but outside of FGAirport and FGRunway, mostly mechanical search-and-replace. An interesting part of this change is that reciprocal runways now exist as independent objects, rather than being created on the fly by the search methods. This simplifies some pieces of code that search for and iterate runways. For users who only want one 'end' of a runway, the new 'isReciprocal' predicate allows them to ignore the 'other' end. Current the only user of this is the 'ground-radar' ATC feature. If we had data on which runways are truly 'single-ended', it would now be trivial to use this in the airport loader to *not* create the reciprocal.
2008-09-11 08:38:09 +00:00
const string& getRunway() const;
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
void setRepeat(bool r) { repeat = r; }
bool getRepeat(void) const { return repeat; }
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
void restart(void);
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
int getNrOfWayPoints() { return waypoints.size(); }
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
int getRouteIndex(int i); // returns the AI related index of this current routes.
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
FGTaxiRoute *getTaxiRoute() { return 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
void deleteTaxiRoute();
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
string getRunway() { return activeRunway; }
bool isActive(time_t time) {return time >= this->getStartTime();}
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
One step further toward better integration of AI and ATC systems. * Changed the runway XX. ATC message to actually report the real designated departure runway * In case of multiple active runways, select the one with a heading that is closest to the direction of the ultimate departure destination / lines up with the arrival path.
2009-02-15 15:29:56 +00:00
void setRunway(string rwy) { activeRunway = rwy; };
string getRunwayClassFromTrafficType(string fltType);
A set of additions related to allow the use of SID and STAR procedures. The current code still has some rough edges, in particular memory still needs to be deallocated where possible, and the actual use of the code needs more testing. This code has been running without noticable problems, so I think it's ready for some wider exposure. Detailed changes include: - Finetuning of the SID/STAR data concept. - Preloading of all SIDs, from one xml file. - ATC determines which SID should be used and echoes this over the com1 or com2 radio.
2009-03-08 17:14:05 +00:00
void addWaypoint(waypoint* wpt) { waypoints.push_back(wpt); };
void setName(string n) { name = n; };
string getName() { return name; };
void setSID(FGAIFlightPlan* fp) { sid = fp;};
FGAIFlightPlan* getSID() { return sid; };
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
private:
James Turner: Convert FGRunway to be heap-based, and inherit FGPositioned. This is a large, ugly change, since FGRunway was essentially a plain struct, with no accessors or abstraction. This change adds various helpers and accessors to FGRunway, but doesn't change many places to use them - that will be a follow up series of patches. It's still a large patch, but outside of FGAirport and FGRunway, mostly mechanical search-and-replace. An interesting part of this change is that reciprocal runways now exist as independent objects, rather than being created on the fly by the search methods. This simplifies some pieces of code that search for and iterate runways. For users who only want one 'end' of a runway, the new 'isReciprocal' predicate allows them to ignore the 'other' end. Current the only user of this is the 'ground-radar' ATC feature. If we had data on which runways are truly 'single-ended', it would now be trivial to use this in the airport loader to *not* create the reciprocal.
2008-09-11 08:38:09 +00:00
FGRunway* rwy;
A set of additions related to allow the use of SID and STAR procedures. The current code still has some rough edges, in particular memory still needs to be deallocated where possible, and the actual use of the code needs more testing. This code has been running without noticable problems, so I think it's ready for some wider exposure. Detailed changes include: - Finetuning of the SID/STAR data concept. - Preloading of all SIDs, from one xml file. - ATC determines which SID should be used and echoes this over the com1 or com2 radio.
2009-03-08 17:14:05 +00:00
FGAIFlightPlan *sid;
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
typedef vector <waypoint*> wpt_vector_type;
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
typedef wpt_vector_type::const_iterator wpt_vector_iterator;
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
David Culp: 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
wpt_vector_type waypoints;
wpt_vector_iterator wpt_iterator;
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
David Culp: 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
bool repeat;
double distance_to_go;
double lead_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
double leadInAngle;
Modified Files: src/AIModel/AIFlightPlan.hxx src/AIModel/AIFlightPlanCreateCruise.cxx src/AIModel/AITanker.cxx src/Traffic/Schedule.cxx: Move member variables that should better be in function local scope into the functions. Make more use of SGMath functions.
2007-07-08 08:46:29 +00:00
time_t start_time;
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
int leg;
- Ground network XML parsing code reads the new attributes "holdPointType" and "isOnRunway". - Added initial support for AI controlled pushback operations, making use of the current editing capabilities of TaxiDraw CVS / New_GUI_CODE. The current implementation is slightly more computationally intensive than strictly required, due to the currently inability of taxidraw to link one specific pushBack point to to a particular startup location. FlightGear now determines this dynamically, and once we have that functionality in TaxiDraw, the initialization part of createPushBack() can be further simplified. - Smoother transition from pushback to taxi. No more skipping of waypoints, and aircraft wait for two minutes at pushback point. - The classes FGTaxiNode, FGTaxiSegment, and FGParking, now have copy constructors, and assignment operators. - Removed declaration of undefined constructor FGTaxiNode(double, double, int) - Array boundry checks and cleanup. - Modified Dijkstra path search algoritm to solve partial problems. Currently limited to include pushback points and routes only, but can probably be extended to a more general approach. - Added initial support for giving certain routes in the network a penalty, in order to discourage the use of certain routes over others.
2007-08-08 06:09:58 +00:00
int gateId, lastNodeVisited;
Durk Talsma: Auf Niederlandisch: Bij deze de patch voor de taxiway code. Deze code is nog gebaseerd op de bestaaande architectuur, gebaseerd op de FGAirport class in simple.[ch]xx Ik heb me voornamelijk gericht op nieuwe functionaliteit; de volgende submissie zal waarschijnlijk bestaan uit opschoning, opsplitsing en een implementatie van de nieuwe airport architectuur, zoals voorgesteld door David Luff. En Anglais: Here is the patch for the taxiway code. This code is still based on the exsisting architecture, which is based on the FGAirport class in simple.[ch]xx I've aimed mostly at new functionality; The next batch will probably contain code cleanups, splitups and the implementation fo the new airport architecture, as proposed by David Luff.
2005-10-18 18:44:37 +00:00
string activeRunway;
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
FGAirRoute airRoute;
FGTaxiRoute *taxiRoute;
A set of additions related to allow the use of SID and STAR procedures. The current code still has some rough edges, in particular memory still needs to be deallocated where possible, and the actual use of the code needs more testing. This code has been running without noticable problems, so I think it's ready for some wider exposure. Detailed changes include: - Finetuning of the SID/STAR data concept. - Preloading of all SIDs, from one xml file. - ATC determines which SID should be used and echoes this over the com1 or com2 radio.
2009-03-08 17:14:05 +00:00
string name;
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
One step further toward better integration of AI and ATC systems. * Changed the runway XX. ATC message to actually report the real designated departure runway * In case of multiple active runways, select the one with a heading that is closest to the direction of the ultimate departure destination / lines up with the arrival path.
2009-02-15 15:29:56 +00:00
void createPushBack(FGAIAircraft *, bool, FGAirport*, double, double, double, const string&, const string&, const string&);
void createPushBackFallBack(FGAIAircraft *, bool, FGAirport*, double, double, double, const string&, const string&, const string&);
Development for two new features: * Some support for geometry information provided by the custom scenery project. Current support is for AI groundnets and runway use files only since this is a switch that involves a lot of data verification and updating, during the transistion the actual path where the data can be read from is user configurable. setting the property /sim/traffic-manager/use-custom-scenery-data to true will cause flightgear to read the ground networks from the scenery directory (--{fg-scenery}/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml to be precise). Setting this property to false will retain the original behvior. * For departing aircraft, runway takeoff calculations will be done on the basis of the performance database. For testing purposes, a performance estimate for a heavy jet has been added.
2009-01-30 18:48:44 +00:00
void createTakeOff(FGAIAircraft *, bool, FGAirport *, double, const string&);
One step further toward better integration of AI and ATC systems. * Changed the runway XX. ATC message to actually report the real designated departure runway * In case of multiple active runways, select the one with a heading that is closest to the direction of the ultimate departure destination / lines up with the arrival path.
2009-02-15 15:29:56 +00:00
void createClimb(FGAIAircraft *, bool, FGAirport *, double, double, const string&);
void createCruise(FGAIAircraft *, bool, FGAirport*, FGAirport*, double, double, double, double, const string&);
void createDecent(FGAIAircraft *, FGAirport *, const string&);
void createLanding(FGAIAircraft *, FGAirport *);
void createParking(FGAIAircraft *, FGAirport *, double radius);
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 deleteWaypoints();
void resetWaypoints();
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
One step further toward better integration of AI and ATC systems. * Changed the runway XX. ATC message to actually report the real designated departure runway * In case of multiple active runways, select the one with a heading that is closest to the direction of the ultimate departure destination / lines up with the arrival path.
2009-02-15 15:29:56 +00:00
void createLandingTaxi(FGAIAircraft *, FGAirport *apt, double radius, const string& fltType, const string& acType, const string& airline);
void createDefaultLandingTaxi(FGAIAircraft *, FGAirport* aAirport);
void createDefaultTakeoffTaxi(FGAIAircraft *, FGAirport* aAirport, FGRunway* aRunway);
void createTakeoffTaxi(FGAIAircraft *, bool firstFlight, FGAirport *apt, double radius, const string& fltType, const string& acType, const string& airline);
James Turner: Cleanup of AI traffic route generation code.
2008-12-30 07:41:15 +00:00
One step further toward better integration of AI and ATC systems. * Changed the runway XX. ATC message to actually report the real designated departure runway * In case of multiple active runways, select the one with a heading that is closest to the direction of the ultimate departure destination / lines up with the arrival path.
2009-02-15 15:29:56 +00:00
waypoint* createOnGround(FGAIAircraft *, const std::string& aName, const SGGeod& aPos, double aElev, double aSpeed);
waypoint* createInAir(FGAIAircraft *, const std::string& aName, const SGGeod& aPos, double aElev, double aSpeed);
waypoint* cloneWithPos(FGAIAircraft *, waypoint* aWpt, const std::string& aName, const SGGeod& aPos);
A set of additions related to allow the use of SID and STAR procedures. The current code still has some rough edges, in particular memory still needs to be deallocated where possible, and the actual use of the code needs more testing. This code has been running without noticable problems, so I think it's ready for some wider exposure. Detailed changes include: - Finetuning of the SID/STAR data concept. - Preloading of all SIDs, from one xml file. - ATC determines which SID should be used and echoes this over the com1 or com2 radio.
2009-03-08 17:14:05 +00:00
waypoint* clone(waypoint* aWpt);
James Turner: Cleanup of AI traffic route generation code.
2008-12-30 07:41:15 +00:00
AI traffic now honors separate runway assignments for different types of traffic (i.e. commercial airliners will use a differnt part of the airport than general avation, ultralight and/or military traffic.
2007-06-28 18:30:35 +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
//void createCruiseFallback(bool, FGAirport*, FGAirport*, double, double, double, double);
void evaluateRoutePart(double deplat, double deplon, double arrlat, double arrlon);
A set of additions related to allow the use of SID and STAR procedures. The current code still has some rough edges, in particular memory still needs to be deallocated where possible, and the actual use of the code needs more testing. This code has been running without noticable problems, so I think it's ready for some wider exposure. Detailed changes include: - Finetuning of the SID/STAR data concept. - Preloading of all SIDs, from one xml file. - ATC determines which SID should be used and echoes this over the com1 or com2 radio.
2009-03-08 17:14:05 +00:00
public:
wpt_vector_iterator getFirstWayPoint() { return waypoints.begin(); };
wpt_vector_iterator getLastWayPoint() { return waypoints.end(); };
Some initial code for AI Aircraft making use of SIDs. Current code is a bit experimental: Only one SID per runway is supported, and the waypoints are read from file at every request, which is not very efficient. The current code is only executed when FlightGear is configured to use airport dynamics data from the scenery repository, instead of the base package. Since the latter is still the default, I believe that this will provide enough safe- guarding to commit SID/STAR support in small, incremental steps. Next step will be buffering and support for multiple departure routes per runway.
2009-03-01 09:58:12 +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
};
#endif // _FG_AIFLIGHTPLAN_HXX
Copy permalink