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

191 lines
6.8 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.
Mathias Fröhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
2004-11-26 10:24:48 +00:00
#include <cstdio>
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
#include <simgear/misc/sg_path.hxx>
#include <simgear/debug/logstream.hxx>
#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
Mathias Fröhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
2004-11-26 10:24:48 +00:00
static list<string>
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
getAllStringNodeVals(const char* name, SGPropertyNode * entry_node);
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
static list<ParkPosition>
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
getAllOffsetNodeVals(const char* name, SGPropertyNode * entry_node);
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
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
FGAIScenario::FGAIScenario(const string &filename)
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
{
int i;
SGPath path( globals->get_fg_root() );
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +00:00
Remove some stale cout commands.
2004-12-27 13:19:28 +00:00
// cout << "/Data/AI/" << filename << endl;
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +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
path.append( ("/Data/AI/" + filename + ".xml").c_str() );
SGPropertyNode root;
Vivian Meazza: Some quite extensive changes to the AIModel code: 1. Mathias has made major changes to the AICarrier code to provide better alignment of an aircraft on deck with the carrier - this feature is a major improvement on the existing, but has a bug which might cause it to fail when the computer carries out other tasks - changing window size is a known example. This bug is outwith this code. 2. I have made significant changes to the AIShip code to enable a ship the turn and roll smoothly. 3. I have added some simple AI which enables the carrier to remain within, or return to, an operating box. 4. An automated turn into wind for flying operations. 5. A simplistic implementation of TACAN within AICarrier. I am in the course of implementing this as a generic instrument, but this is some time off completion.
2005-08-16 09:37:23 +00:00
readProperties(path.str(), &root);
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +00:00
Remove some stale cout commands.
2004-12-27 13:19:28 +00:00
// cout <<"path " << path.str() << endl;
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +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
try {
readProperties(path.str(), &root);
} catch (const sg_exception &e) {
SG_LOG(SG_GENERAL, SG_ALERT,
"Incorrect path specified for AI scenario: ");
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +00:00
cout << path.str() << endl;
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
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++) {
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +00:00
Remove some stale cout commands.
2004-12-27 13:19:28 +00:00
// cout << "Reading entity data entry " << i << endl;
Vivian Meazza: This is a sub-system which can be added to any carrier. These files add a functioning Fresnel Lens Optical Landing System (FLOLS). The orange/red 'source' lights are illuminated according to the position of the pilot's eye above/below the 3.5 deg glide slope. The apparent position of the source light relative to the fixed green datum lights allow the pilot to 'fly the meatball'. The green 'cut' lights flash when the pilot's eye is below the coverage of the lowest (red) source light. TODO - add rules for the operation of the wave-off lights.
2004-11-30 12:34:11 +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
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", "");
Vivian MEAZZA: "Implement the repeat function for submodels. Default value is 'false' "
2006-01-30 22:08:53 +00:00
en->repeat = entry_node->getBoolValue("repeat", false);
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);
Vivian Meazza: Some quite extensive changes to the AIModel code: 1. Mathias has made major changes to the AICarrier code to provide better alignment of an aircraft on deck with the carrier - this feature is a major improvement on the existing, but has a bug which might cause it to fail when the computer carries out other tasks - changing window size is a known example. This bug is outwith this code. 2. I have made significant changes to the AIShip code to enable a ship the turn and roll smoothly. 3. I have added some simple AI which enables the carrier to remain within, or return to, an operating box. 4. An automated turn into wind for flying operations. 5. A simplistic implementation of TACAN within AICarrier. I am in the course of implementing this as a generic instrument, but this is some time off completion.
2005-08-16 09:37:23 +00:00
en->rudder = entry_node->getFloatValue("rudder", 0.0);
David Culp: 1) The AIStorm sets the properties: /environment/turbulence/magnitude-norm /environment/turbulence/rate-hz The actual turbulence effects are handled by the FDM. If the effects are deemed unrealistic, then that will have to be fixed in the FDM(s). 2) The zone of turbulence is cylindrical, and is centered at the AIStorm's lat/lon. The diameter is set with <diameter-ft>, the top with <height-msl>, the bottom is assumed to be at <altitude> minus 1000 feet. 3) Note that the zone of turbulence may not match well with the visual model of the storm. In this case I had to x-offset the storm model by 4700 meters to match the zone of turbulence. (i.e. the storm model is 4700m off center). 4) While I was in there I also increased the speed of the lightning flashes to look more realistic.
2005-05-16 09:48:00 +00:00
en->strength = entry_node->getDoubleValue("strength-fps", 8.0);
David Culp: Here's a fix for a bug I introduced when I updated the AIStorm with turbulence. The change I made to the FGAIEntity struct was overriding the thermal <strength-fps> data.
2005-11-16 15:23:18 +00:00
en->turb_strength = entry_node->getDoubleValue("strength-norm", 1.0);
Add the AIModel based air traffic subsystem from Durk Talsma.
2004-06-03 17:59:14 +00:00
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);
commit some pending updates from Vivian
2004-11-16 09:33:21 +00:00
en->wind = entry_node->getBoolValue ("wind", false);
en->cd = entry_node->getDoubleValue("cd", 0.029);
en->mass = entry_node->getDoubleValue("mass", 0.007);
en->radius = entry_node->getDoubleValue("turn-radius-ft", 2000);
Vivian Meazza: This adds a TACAN instrument to the inventory. Range and bearing are calculated to the TACAN or VORTAC beacon selected by means of the Channel Selector in the E quipment/Radio pull-down menu. A TACAN beacon has also been added to the aircraft carrier Nimitz (channel #029Y ).
2005-10-01 09:56:53 +00:00
en->TACAN_channel_ID= entry_node->getStringValue("TACAN-channel-ID", "029Y");
en->name = entry_node->getStringValue("name", "Nimitz");
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
en->pennant_number = entry_node->getStringValue("pennant-number", "");
en->wire_objects = getAllStringNodeVals("wire", entry_node);
en->catapult_objects = getAllStringNodeVals("catapult", entry_node);
en->solid_objects = getAllStringNodeVals("solid", entry_node);
en->ppositions = getAllOffsetNodeVals("parking-pos", entry_node);
Vivian Meazza: Some quite extensive changes to the AIModel code: 1. Mathias has made major changes to the AICarrier code to provide better alignment of an aircraft on deck with the carrier - this feature is a major improvement on the existing, but has a bug which might cause it to fail when the computer carries out other tasks - changing window size is a known example. This bug is outwith this code. 2. I have made significant changes to the AIShip code to enable a ship the turn and roll smoothly. 3. I have added some simple AI which enables the carrier to remain within, or return to, an operating box. 4. An automated turn into wind for flying operations. 5. A simplistic implementation of TACAN within AICarrier. I am in the course of implementing this as a generic instrument, but this is some time off completion.
2005-08-16 09:37:23 +00:00
en->max_lat = entry_node->getDoubleValue("max-lat", 0);
en->min_lat = entry_node->getDoubleValue("min-lat",0);
en->max_long = entry_node->getDoubleValue("max-long", 0);
en->min_long = entry_node->getDoubleValue("min-long", 0);
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
list<ParkPosition> flolspos = getAllOffsetNodeVals("flols-pos", entry_node);
en->flols_offset = flolspos.front().offset;
Mathias Fröhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
2004-11-26 10:24:48 +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();
}
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
FGAIModelEntity* const
David Culp: Here's the newest AI stuff. The AIManager at init() creates a new scenario. Right now the default_scenario is hard coded in, but eventually the AIManager should get the scenario filename from preferences.xml. The scenario defines which AI objects will be created. Right now it only creates AIAircraft, but this is easily extended. The scenario also defines which flightplan will be assigned to the airplane. Scenario config files go in data/Data/AI. The Airplane gets a pointer to a FlightPlan object. Each airplane should get its own flightplan object, even if two airplanes have the same flight plan. This is because the flightplan maintains the iterator pointing to the current waypoint, and two airplanes might be at different locations (for instance if they were created at different times). The flight plan files go in data/Data/AI/FlightPlans. When the airplane gets to the waypoint named "END" it vanishes. The AIAircraft destructor deletes its flight plan (if it has one). The last waypoint is a place holder only. I called mine <WPT><NAME>"EOF"</NAME></WPT>.
2004-05-15 09:07:55 +00:00
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();
}
Mathias Fröhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
2004-11-26 10:24:48 +00:00
static list<string>
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
getAllStringNodeVals(const char* name, SGPropertyNode * entry_node)
Mathias Fröhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
2004-11-26 10:24:48 +00:00
{
list<string> retval;
int i=0;
do {
char nodename[100];
snprintf(nodename, sizeof(nodename), "%s[%d]", name, i);
const char* objname = entry_node->getStringValue(nodename, 0);
if (objname == 0)
return retval;
retval.push_back(string(objname));
++i;
} while (1);
return retval;
}
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
static list<ParkPosition>
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
getAllOffsetNodeVals(const char* name, SGPropertyNode * entry_node)
{
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
list<ParkPosition> retval;
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +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
vector<SGPropertyNode_ptr>::const_iterator it;
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
vector<SGPropertyNode_ptr> children = entry_node->getChildren(name);
for (it = children.begin(); it != children.end(); ++it) {
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
string name = (*it)->getStringValue("name", "unnamed");
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
double offset_x = (*it)->getDoubleValue("x-offset-m", 0);
double offset_y = (*it)->getDoubleValue("y-offset-m", 0);
double offset_z = (*it)->getDoubleValue("z-offset-m", 0);
Mathias Fröhlich: I have introduced the posibility to start directly on the carrier. With that patch you will have a --carrrier=id argument where id can either be the pennant number configured in the nimitz scenario or the carriers name also configured in the carriers scenario. Additionaly you can use --parkpos=id to select different positions on the carrier. They are also configured in the scenario file. That includes the switch of the whole FGInterface class to make use of the groundcache. That means that an aircraft no longer uses the current elevation value from the scenery class. It rather has its own local cache of the aircrafts environment which is setup in the common_init method of FGInterface and updated either manually by calling FGInterface::get_groundlevel_m(lat, lon, alt_m); or implicitly by calling the above method in the FGInterface::_updateGeo*Position(lat, lon, alt); methods. A call get_groundlevel_m rebuilds the groundcache if the request is outside the range of the cache. Note that for the real usage of the groundcache including the correct information about the movement of objects and the velocity information, you still need to set up the groundcache in the usual way like YASim and JSBSim currently does. If you use the native interface, you will get only static objects correctly. But for FDM's only using one single ground level for a whole step this is IMO sufficient. The AIManager gets a way to return the location of a object which is placed wrt an AI Object. At the moment it only honours AICarriers for that. That method is a static one, which loads the scenario file for that reason and throws it away afterwards. This looked like the aprioriate way, because the AIManager is initialized much later in flightgears bootstrap, and I did not find an easy way to reorder that for my needs. Since this additional load is very small and does only happen if such a relative location is required, I think that this is ok. Note that moving on the carrier will only work correctly for JSBSim and YASim, but you should now be able to start and move on every not itself moving object with any FDM.
2005-07-03 09:39:14 +00:00
double hd = (*it)->getDoubleValue("heading-offset-deg", 0);
ParkPosition pp(name, Point3D(offset_x, offset_y, offset_z), hd);
retval.push_back(pp);
Mathias Fröhlich: I have done some cleanup where I moved some values out of classes where they do not belong and such stuff. Also the fols offsets are now named in the carrier xml file with a more verbose name (flols-pos/offset-*) than before (only offset-*). There is a little preparation for definitions of parking positions on the carrier which should later be used for starting flightgear directly on the carrier.
2005-03-19 09:57:18 +00:00
}
return retval;
}
Mathias Fröhlich: This patch makes the aircraft carrier's hardware appear in the scenegraph.
2004-11-26 10:24:48 +00:00
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