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

128 lines
4 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
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#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
#include <Airports/simple.hxx>
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
#include <Airports/runways.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"
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
SG_USING_STD(vector);
SG_USING_STD(string);
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;
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;
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(const string& filename);
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(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 );
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;
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
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 create(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
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 setLeg(int val) { leg = val;};
void setTime(time_t st) { start_time = st; };
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
int getGate() const { return gateId; };
double getLeadInAngle() const { return leadInAngle; };
const string& getRunway() const { return rwy._rwy_no; };
const string& getRunwayId() const { return rwy._id; };
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 setRepeat(bool r) { repeat = r; };
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
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);
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:
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
FGRunway rwy;
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;
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
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;
int gateId;
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;
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
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
void createPushBack(bool, FGAirport*, double, double, double, const string&, const string&, const string&);
void createTaxi(bool, int, FGAirport *, double, double, double, const string&, const string&, const string&);
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 createTakeOff(bool, FGAirport *, double);
void createClimb(bool, FGAirport *, double, double);
void createCruise(bool, FGAirport*, FGAirport*, double, double, double, double);
void createDecent(FGAirport *);
void createLanding(FGAirport *);
void createParking(FGAirport *);
void deleteWaypoints();
void resetWaypoints();
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