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

124 lines
4.3 KiB
C++
Raw Normal View History

Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
// FGAIScenario.cxx - class for loading an AI scenario
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
// 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.
#include <simgear/misc/sg_path.hxx>
#include <simgear/debug/logstream.hxx>
#include <simgear/structure/exception.hxx>
#include <simgear/constants.h>
#ifdef __BORLANDC__
# define exception c_exception
#endif
#include <simgear/props/props.hxx>
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
#include <Main/globals.hxx>
#include <Main/fg_props.hxx>
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
#include "AIScenario.hxx"
fix a segmentation fault situation that is exposed at least on IRIX (but not Linux).
2004-09-22 10:03:26 +00:00
#include "AIFlightPlan.hxx"
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
Make the scenerio's work again (now for real) and a small number of updates.
2004-09-23 09:39:55 +00:00
FGAIScenario::FGAIScenario(string &filename)
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
{
int i;
SGPath path( globals->get_fg_root() );
path.append( ("/Data/AI/" + filename + ".xml").c_str() );
SGPropertyNode root;
try {
readProperties(path.str(), &root);
} catch (const sg_exception &e) {
SG_LOG(SG_GENERAL, SG_ALERT,
"Incorrect path specified for AI scenario: ");
cout << path.str() << endl;
return;
}
fix a segmentation fault situation that is exposed at least on IRIX (but not Linux).
2004-09-22 10:03:26 +00:00
entries.clear();
Use lower case letters instead.
2004-05-15 12:46:25 +00:00
SGPropertyNode * node = root.getNode("scenario");
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
for (i = 0; i < node->nChildren(); i++) {
//cout << "Reading entry " << i << endl;
SGPropertyNode * entry_node = node->getChild(i);
Make the scenarios work again.
2004-09-22 11:24:45 +00:00
FGAIModelEntity* en = new FGAIModelEntity;
Use lower case letters instead.
2004-05-15 12:46:25 +00:00
en->callsign = entry_node->getStringValue("callsign", "none");
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
en->m_type = entry_node->getStringValue("type", "aircraft");
en->m_class = entry_node->getStringValue("class", "jet_transport");
en->path = entry_node->getStringValue("model", "Models/Geometry/glider.ac");
Use lower case letters instead.
2004-05-15 12:46:25 +00:00
en->flightplan = entry_node->getStringValue("flightplan", "");
David Culp: First, preferences.xml will define the scenario filename. For now, the other way of defining ai objects still works, so the sailboat stays in preferences.xml. Later, I'll move the sailboat into the demo scenario. If no scenario filename is given, then no scenario will be processed. I changed the demo scenario to create two 737's, one takes off on runway 01L, and the other takes off on runway 01R. This will make a good demo for the ai system. One problem, if you takeoff on 28L/R right away, you might run into the taking-off 737's, or be scared.
2004-05-17 08:45:33 +00:00
en->repeat = entry_node->getDoubleValue("repeat", 0.0);
David Culp: Here's some new AI stuff. 1) AI objects must now be defined in a scenario file, not in preferences.xml or a *-set file. (Of course this doesn't prevent objects from being created dynamically, as with Durk's traffic manager). 2) A new demo_scenario file is attached. It creates 3 aircraft, a sailboat, and a thunderstorm. 3) Objects without flightplans live forever. 4) FGAIShip::ProcessFlightplan() is not yet implemented. 5) preferences.xml should now define only <enabled> and <scenario>
2004-05-29 11:39:10 +00:00
en->latitude = entry_node->getDoubleValue("latitude", 0.0);
en->longitude = entry_node->getDoubleValue("longitude", 0.0);
en->altitude = entry_node->getDoubleValue("altitude", 0.0);
en->speed = entry_node->getDoubleValue("speed", 0.0);
en->heading = entry_node->getDoubleValue("heading", 0.0);
en->roll = entry_node->getDoubleValue("roll", 0.0);
en->azimuth = entry_node->getDoubleValue("azimuth", 0.0);
en->elevation = entry_node->getDoubleValue("elevation", 0.0);
en->rudder = entry_node->getDoubleValue("rudder", 0.0);
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
en->strength = entry_node->getDoubleValue("strength-fps", 0.0);
en->diameter = entry_node->getDoubleValue("diameter-ft", 0.0);
David Culp: Here are files to get automated contrails working. I've set up contrails for the 737, using my simple, untextured contrail model. Vivian has made another contrail model, but I'm still trying to get his to work. I'm hoping others will try to make contrail models also. Here's some code that defines a top to thermals. When the top of a thermal is reached the strength is phased-out linearly over the next 100 feet of altitude. At first I tried just capping the thermal at the top, but the change in thermal strength was too fast for the FDM to handle well. Included is a new version of the thermal scenario that includes a top (height-msl) to the thermal. The default value is 5000 feet.
2004-11-07 14:46:21 +00:00
en->height_msl = entry_node->getDoubleValue("height-msl", 5000.0);
David Culp: Silly me. I was starting the timer at zero, so the first tracer didn't fly until 0.25 seconds after pulling the trigger. Now the timer starts at the same value as "delay", so the first round comes out immediately. Also, I've added an optional configuration attribute that allows you to change the ballistics of the submodel. This allows parachutes, or anything else that has ballistics different from a bullet. The attribute is called "eda", which is the equivalent drag area. Default value is 0.007, which gives the same ballistics as the current tracers. Increasing this value gives more drag. A value of 2.0 looks good for a parachute. math stuff ######################################################################## The deceleration of the ballictic object is now given by: [ (rho) (Cd) ] / [ (1/2) (m) ] * A * (V * V) where rho is sea-level air density, and Cd and m are fixed, bullet-like values. So the calculation is: 0.0116918 * A * (V * V) The value "A" is what I'm calling the "eda" (equivalent drag area). ######################################################################## A parachute model will have to be built so that the parachutist's feet are in the forward x-direction. Here is the submodel.xml config I use for "parachutes": <submodel> <name>flares</name> <model>Models/Geometry/flare.ac</model> <trigger>systems/submodels/submodel[0]/trigger</trigger> <speed>0.0</speed> <repeat>true</repeat> <delay>0.85</delay> <count>4</count> <x-offset>0.0</x-offset> <y-offset>0.0</y-offset> <z-offset>-4.0</z-offset> <yaw-offset>0.0</yaw-offset> <pitch-offset>0.0</pitch-offset> <eda>2.0</eda> </submodel>
2004-08-26 16:25:54 +00:00
en->eda = entry_node->getDoubleValue("eda", 0.007);
Vivian Meazza: Attached are the modified files to add buoyancy as a parameter for a ballistic object. It may be set by adding <buoyancy>x</buoyancy> to the submodel .xml file, where x is the appropriate value (ft per sec2): 32 neutral buoyancy - contrails >32 positive buoyancy - exhaust plumes (0 non-op - default value) If <buoyancy>x</buoyancy> is not used, then there is no effect on the current ballistic model
2004-09-01 08:32:54 +00:00
en->life = entry_node->getDoubleValue("life", 900.0);
Fix a small number of potential problems.
2004-09-20 19:29:16 +00:00
en->buoyancy = entry_node->getDoubleValue("buoyancy", 0);
en->wind_from_east = entry_node->getDoubleValue("wind_from_east", 0);
en->wind_from_north = entry_node->getDoubleValue("wind_from_north", 0);
en->wind = entry_node->getBoolValue("wind", false);
fix a segmentation fault situation that is exposed at least on IRIX (but not Linux).
2004-09-22 10:03:26 +00:00
en->cd = entry_node->getDoubleValue ("cd", 0.029);
Vivian Meazza: The calculation of submodel mass from weight has been moved from AIBallistic to Submodel so that it is calculated only once, rather than on every iteration as a present. The parameter <contents> has been added, primarily so that droptanks will have the proper mass. It is the path to an appropriate property containing a weight in lbs. Care has to be taken with the use of <contents> because after a reset there appears to be a delay in submodel instantiation (dt not properly reset???) and the weight property is not always picked up before it is set to zero in the key bindings. Slightly hard to explain. It works fine if FGFS has not been reset though. There is a partial solution which involves the rejigging of the fuel and gui nasal scripts, but there is still the visible delay in instantiation to be resolved. I've nearly done the nasal fixes, which will form part of an update to the Hunter only. I'll probably complete those later today.
2004-09-27 14:24:20 +00:00
en->mass = entry_node->getDoubleValue ("mass", 0.007);
fix a segmentation fault situation that is exposed at least on IRIX (but not Linux).
2004-09-22 10:03:26 +00:00
Fix a small number of potential problems.
2004-09-20 19:29:16 +00:00
en->fp = NULL;
fix a segmentation fault situation that is exposed at least on IRIX (but not Linux).
2004-09-22 10:03:26 +00:00
if (en->flightplan != ""){
en->fp = new FGAIFlightPlan( en->flightplan );
}
Make the scenarios work again.
2004-09-22 11:24:45 +00:00
entries.push_back( en );
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
}
entry_iterator = entries.begin();
//cout << entries.size() << " entries read." << endl;
}
FGAIScenario::~FGAIScenario()
{
entries.clear();
}
Make use of a pointer to a structure to pass multiple parameters around.
2004-09-07 09:53:23 +00:00
FGAIModelEntity*
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
FGAIScenario::getNextEntry( void )
{
David Culp: First, preferences.xml will define the scenario filename. For now, the other way of defining ai objects still works, so the sailboat stays in preferences.xml. Later, I'll move the sailboat into the demo scenario. If no scenario filename is given, then no scenario will be processed. I changed the demo scenario to create two 737's, one takes off on runway 01L, and the other takes off on runway 01R. This will make a good demo for the ai system. One problem, if you takeoff on 28L/R right away, you might run into the taking-off 737's, or be scared.
2004-05-17 08:45:33 +00:00
if (entries.size() == 0) return 0;
if (entry_iterator != entries.end()) {
return *entry_iterator++;
} else {
return 0;
}
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
}
int FGAIScenario::nEntries( void )
{
return entries.size();
}
Vivian Meazza: I have added <Cd> and <weight> to the input parameters in the submodels.xml script. Raw data may be used, thus avoiding the need to guestimate <eda>. Eda remains, but should now be used to enter the proper cross-sectional area.
2004-09-22 08:47:05 +00:00
// end scenario.cxx
Vivian Meazza: The calculation of submodel mass from weight has been moved from AIBallistic to Submodel so that it is calculated only once, rather than on every iteration as a present. The parameter <contents> has been added, primarily so that droptanks will have the proper mass. It is the path to an appropriate property containing a weight in lbs. Care has to be taken with the use of <contents> because after a reset there appears to be a delay in submodel instantiation (dt not properly reset???) and the weight property is not always picked up before it is set to zero in the key bindings. Slightly hard to explain. It works fine if FGFS has not been reset though. There is a partial solution which involves the rejigging of the fuel and gui nasal scripts, but there is still the visible delay in instantiation to be resolved. I've nearly done the nasal fixes, which will form part of an update to the Hunter only. I'll probably complete those later today.
2004-09-27 14:24:20 +00:00
Copy permalink