fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/ATC/AIEntity.cxx

86 lines
2.7 KiB
C++
Raw Normal View History

Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
// FGAIEntity - abstract base class an artificial intelligence entity
//
// Written by David Luff, started March 2002.
//
// Copyright (C) 2002 David C. Luff - david.luff@nottingham.ac.uk
//
// 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.
/*****************************************************************
*
* WARNING - Curt has some ideas about AI traffic so anything in here
Fix my mailing address by replacing it with my web page.
2004-11-19 22:10:41 +00:00
* may get rewritten or scrapped. Contact Curt http://www.flightgear.org/~curt
Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
* before spending any time or effort on this code!!!
*
******************************************************************/
#include <config.h> where needed for cygwin/gcc-3.2.
2002-12-03 14:59:24 +00:00
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
#include <Main/globals.hxx>
#include <Scenery/scenery.hxx>
Minor API changes to support the new sg_geodesy implementation. A few places now use sgCartToGeod() instead of rolling their own approximation. And YASim is now using exactly the same 3D coordinate system as the rest of FlightGear is.
2003-12-19 02:42:32 +00:00
#include <simgear/constants.h>
Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
#include <simgear/math/point3d.hxx>
#include <simgear/math/sg_geodesy.hxx>
#include <simgear/misc/sg_path.hxx>
#include <string>
#include "AIEntity.hxx"
Lots of changes to the ATC/AI system for initial revision of random AI GA VFR traffic
2004-01-23 17:18:24 +00:00
FGAIEntity::FGAIEntity() {
}
Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
FGAIEntity::~FGAIEntity() {
Lots of changes to the ATC/AI system for initial revision of random AI GA VFR traffic
2004-01-23 17:18:24 +00:00
//cout << "FGAIEntity dtor called..." << endl;
Mathias Fröhlich: I had a quick view over the ssgBase::ref() calls in flightgear. I made them all symmetric and used ssgDeRefDelete to dereference them. This has the basic advantage that ssgDeRefDelete additionaly deletes the memory instead of just decrementing the reference cound without deletion ... This includes an incorrect deref instead of a ssgDeRefDelete in the placement transform registration I introduced earlier. I believe that this causes the problems with long flights (unverified, but with a big propability).
2005-10-15 14:51:52 +00:00
ssgDeRefDelete(_model); // Ought to check valid?
Lots of changes to the ATC/AI system for initial revision of random AI GA VFR traffic
2004-01-23 17:18:24 +00:00
//cout << "Removing model from scene graph..." << endl;
globals->get_scenery()->get_scene_graph()->removeKid(_aip.getSceneGraph());
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
// Unregister that one at the scenery manager
globals->get_scenery()->unregister_placement_transform(_aip.getTransform());
Lots of changes to the ATC/AI system for initial revision of random AI GA VFR traffic
2004-01-23 17:18:24 +00:00
//cout << "Done!" << endl;
}
void FGAIEntity::SetModel(ssgBranch* model) {
_model = model;
_model->ref();
_aip.init(_model);
_aip.setVisible(false);
globals->get_scenery()->get_scene_graph()->addKid(_aip.getSceneGraph());
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
// Register that one at the scenery manager
globals->get_scenery()->register_placement_transform(_aip.getTransform());
Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
}
Preliminary support for AI planes from Dave Luff. This works only at KEMT (w120n30 scenery), and you will have to set the property /sim/ai-traffic/enabled to 'true' to see the other plane (and tune comm1 to 121.2 to hear the other plane's radio calls).
2002-10-02 15:27:49 +00:00
void FGAIEntity::Update(double dt) {
}
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 &FGAIEntity::GetCallsign() {
static string s = "";
return(s);
Lots of changes to the ATC/AI system for initial revision of random AI GA VFR traffic
2004-01-23 17:18:24 +00:00
}
Add a function to allow transmission of messages to AI entities - the actual implementation is a bit of a temporary hack at the moment
2003-03-20 11:53:44 +00:00
void FGAIEntity::RegisterTransmission(int code) {
}
Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
// Run the internal calculations
Preliminary support for AI planes from Dave Luff. This works only at KEMT (w120n30 scenery), and you will have to set the property /sim/ai-traffic/enabled to 'true' to see the other plane (and tune comm1 to 121.2 to hear the other plane's radio calls).
2002-10-02 15:27:49 +00:00
//void FGAIEntity::Update() {
void FGAIEntity::Transform() {
Lots of changes to the ATC/AI system for initial revision of random AI GA VFR traffic
2004-01-23 17:18:24 +00:00
_aip.setPosition(_pos.lon(), _pos.lat(), _pos.elev() * SG_METER_TO_FEET);
_aip.setOrientation(_roll, _pitch, _hdg);
Mathias Fröhölöiööhlich: There was a patch from Manuel Masing a few months ago which cleaned up SGLocation's way depending on input values. That means that with that patch SGLocation does no longer have calls with unneeded input arguments. I took his patch and integrated that into flightgear and made maximum use of that changes. Erik Hofman: Remove some duplicate code that was moved to simgear/compiler.h
2005-09-05 13:25:09 +00:00
_aip.update();
Attached are a fairly extensive series of patches to the ATC system. A chap from Germany called Alexander Kappes (cc'd) got in touch with me a few weeks ago and has written the start of Approach control. At the moment tuning in to a valid approach frequency (Dortmund or East Midlands) should result in vectors to a spot about 3 miles from the active runway, and a telling off if you stray too far from the correct course, in the console window. He seems to know what he's doing so expect this to improve rapidly!! I've added a rudimentry AI manager and a hardwired Cessna at KEMT on the runway - I'll remove it before the next release if I don't have it flying by then. There seems to be an issue with framerate which drops alarmingly when looking at it - I've a feeling that I've possibly created several Cessnas on top of each other, but am not sure.
2002-04-03 23:54:44 +00:00
}
Copy permalink