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

108 lines
3.8 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
// FGAIScenario - class for loading an AI scenario
// 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 "AIScenario.hxx"
#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>
#include <Main/globals.hxx>
#include <Main/fg_props.hxx>
FGAIScenario::FGAIScenario(string filename)
{
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;
}
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;
entry* en = new entry;
entries.push_back( en );
SGPropertyNode * entry_node = node->getChild(i);
Use lower case letters instead.
2004-05-15 12:46:25 +00:00
en->callsign = entry_node->getStringValue("callsign", "none");
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->aitype = entry_node->getStringValue("type", "aircraft");
Use lower case letters instead.
2004-05-15 12:46:25 +00:00
en->aircraft_class = entry_node->getStringValue("class", "jet_transport");
en->model_path = entry_node->getStringValue("model", "Models/Geometry/glider.ac");
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: 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);
Vivian Meazza: I've added another parameter to the submodel - wind. It's activated by the entry <wind>true</wind> in the ../submodel.xml file. If true, the submodel is affected by the local wind, otherwise not. The parameter defaults to false. This is useful for exhausts and smoke, and possibly all objects.
2004-09-05 09:45:34 +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);
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();
}
FGAIScenario::entry*
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();
}
Copy permalink