* New features
- More realistic descent paths
- Separation during descent and approach
- ATC approach controller (still silent)
- inbound traffic flow will start immediately
* Bug fixes
- Properly handle vertical speed when on ground
- Departing aircraft now wait for taxiclerance before moving
- Traffic manager waits for proper weather initialization
- Fixed instabilities in the preferential runway usage code
- Fine tuning of waypoint following code.
The current code still has some rough edges, in particular memory still
needs to be deallocated where possible, and the actual use of the code
needs more testing. This code has been running without noticable problems,
so I think it's ready for some wider exposure. Detailed changes include:
- Finetuning of the SID/STAR data concept.
- Preloading of all SIDs, from one xml file.
- ATC determines which SID should be used and echoes this over the com1 or
com2 radio.
* Changed the runway XX. ATC message to actually report the real
designated departure runway
* In case of multiple active runways, select the one with a heading that is
closest to the direction of the ultimate departure destination / lines up
with the arrival path.
* Some support for geometry information provided by the custom scenery
project. Current support is for AI groundnets and runway use files only
since this is a switch that involves a lot of data verification and
updating, during the transistion the actual path where the data can be
read from is user configurable. setting the property
/sim/traffic-manager/use-custom-scenery-data to true
will cause flightgear to read the ground networks from the scenery
directory (--{fg-scenery}/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml to be
precise). Setting this property to false will retain the original
behvior.
* For departing aircraft, runway takeoff calculations will be done on the
basis of the performance database. For testing purposes, a performance
estimate for a heavy jet has been added.
- Runways are now part of an airport, instead of a separate list
- Runways are no longer represented as a boring struct, but as a class
of their own.
-Improved runway access to unify various runway access methods.
PLETE_FUNCTIONAL from SimGear and FlightGear.
As a result, SG_HAVE_STD_INCLUDES is now *always* set, so I will get the boring
fixes for that done, but separately. I'm still auditing the other things in comp
ilers.h - there's a lot that can die now BORLAND is gone.
and the pushback code:
- Traffic manager starts modelload requests immediately upon program
loading
- Only create legs 1 (push back) or five (cruise) of AI traffic.
- AIAircraft's rather obsessive behavior to circle around a waypoint is
largely resolved
- More realistic ground steering for AI aircraft.
- Airports Directory
Thomas Foerster: Pulls out the FGTaxiNode implementation into gnnode.cxx.
Melchior / Durk: Copy Constructor and assignment operator for FGTaxiRoute
- AIModels Directory
Durk / Melchior / Czaba Halasz: Ensure that all derived classes use AIBase
member 'callsign'. Adapted, moved and deleted getter/setter functions where
necessary
Czaba Halasz: Fix AIBase model path vs. submodel path consistency.
- Traffic Directory and AIModels CreateFlightPlanCruise
DT: Temporary revert parts of the position estimation code.
"""
"Flight plans" which can start at a given time (gmt)
WAITUNTIL tokens which pause the flight plans until a given time (gmt)
Submodels can now be attached to any AI objects (except submodels - it can
be done, but in my experimental code it's too expensive in frame rate atm)
"No-roll" attribute added to Ballistic objects - useful for wakes and the
like
"Random" attribute added to Ballistic objects (adds =- 5% to the Cd) -
useful for smoke, exhausts
If the <trigger> tag is not specified the Ballistic object/s will be
released at start-up (cannot be stopped)
Submodels are not released from AI Objects if the AI Object is more than 15
miles away.
"""
mf: minor code and formatting fixes; submodels.?xx were FUBAR and are thus
astyle formatted;
NOTE that <name> tags END, EOF, WAIT, WAITUNTIL are *depreciated*.
Don't get too used to them. This will have to be moved from the "name"
to regular engries.
"Implement 'flightplans' for AIShips. This patch also introduces the concept
of a 'WAIT' token for AIShips: when the flightplan reaches a 'WAIT', the
AIShip stops and pauses for the specified time (secs)."
maintain a resonable distance from each other while taxiing on the same
route. The current code does not yet take crossing routes or aircraft
taxiing into opposite directions into account.
work for ground based distance separation of AIAircraft.
Traffic manager initialization related changes:
- Schedules initialize "on the fly", instead of during initialization
- Invalid routes are no longer deleted, but marked as BOGUS and ignored
- Changed loading order from a distance based prioritization to a point-
score based prioritization, resulting in a much faster establisment of
AIAircraft near the user's plane.
Preparatory work for ground-based separation of Aircraft.
- The groundnetwork findShrortestRoute function not only returns a list
of waypoints, but also a list of taxi "segments" (a.k.a. taxiways).
- The taxiway list is stored in the Flightplan, and updated everytime
a new taxi leg is created.
using Curt's new speed adjustment code. 2) Separated the function
FlightPlanCreateCruise() into a new source file in preparation of a more
elaborate airway following scheme.
This patch removes some useless indirection when creating AIModels. It
obsolets AIScenario*.
AIEntities are just an intermediate copy of an other intermediate copy of an
xml file on the way from the ai scenario configuration file to the AIModels.
As such the AImodels can now be created directly from the property tree read
from the scenario file.
This reduces the amount of work needed to add an other AIModel and reduces the
amount of copy operations done during initialization.
It also moves internal knowledge of special AI models into these special AI
models class instead of spreading that into the whole AIModel subdirectory
which in turn enables to use carrier internal data structures for carrier
internal data ...
Also some unused variables are removed from the AIModel classes.
I believe that there are still more of them, but that is what I stumbled
accross ...
Tested, like the other splitouts these days in a seperate tree and using the
autopilot for some time, and in this case with a carrier start ...
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.
* 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.
I added an AIStatic object to my OV-10 sim for use in putting city signs,
vehicles, or anything else that will be static, but that I don't want to put
in the scenery files. It's inexpensive. Before, I was making such things
from AIShip.
I also added the ability to set flight plans to repeat, so that when an
airplane reaches the end it just starts over at the beginning. This is
useful for my OV-10 sim. I have C-141 and KC-135 traffic flying approaches
to Ramstein, and I only have to define two AI objects to do this.
Also, I found an inefficiency in AIBase, where every AI object was calculating
Mach number at every dt. Now only AIBallistic objects do this.
I just heard from John Wojnaroski that you and he are going to work on getting
a flightgear demo machine up for the linux expo thursday and Friday. John
indicated that he would very much like to get a CVS version with the new
traffic code up and running before the expo.
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
Okay, here's the latest update to the tarffic manager/AI Manager. AITraffic
can now fly multiple routes and be initialized while sitting statically at
airports.
I've included the latest fixes to the Traffic Manager/AI flightplan generation
code. Most of the code changes are in AIFllightplan.cxx. This is the code
that runs without depending on predefined FlightPlans in
#FG_ROOT/Data/AI/Flightplans.i
As suggested by Dave, I've also added a new property in
preferences.xml: /sim/traffic-manager/enabled, which is used to control
whether or not the traffic manager is active.
I'm still working on a few more 737 traffic patterns, those are going to take
a little longer, so I didn't want to wait sending in this code.
Finally, I haven't put much effort into ensuring "aeronautical correctness" in
this version yet. The code works on my system, but what the AI plane do may
actaully be quite rediculous. But I'd like to leave that for the next
version.
1. Removed aircraft roll on ground.
2. Decreased descent pitch angle.
3. Updated flightplans to include <on-ground>
4. Fixed property indexing, so all AI aircraft have their own property branch
The default value of <on-ground> is false, so you only need to specify it when
on the ground. For takeoff you need to specify <on-ground>true</on-ground>
for the first waypoint, and for the acceleration waypoint. For landing you
need to specify it for the touchdown point and any taxi points.
One problem. WARNING **** There is a bug in the way the property system
works, which causes a segfault, but I don't know if the problem is in the
property code, or in how I'm using it. After an AI object terminates, if you
access the property tree through the property browser the sim will segfault.
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>.
