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.
When AIFlightPlanCreateTaxi() function is called with the firstFlight
argument set to true, this is supposed to handle situations where the
the aircraft's timetable indicates it should have left between about 5 to
20 minutes earlier. In the previous version, all these aircraft started
taxiing from the first parking location available in the network, due
to the fact that the variable gateId was not assigned a value. In this
patch, route tracing starts from an assigned gate and the network node
following code is fast forwarded to a random location along the taxiways
to give a more realistic and natural distribution of taxiing aircraft
after startup.
This patch further addresses some weird ballet-dancing behavior that
aircraft were showing just prior to/right after parking and which was
related to a number of more or less duplicate waypoints in the transition
from createTaxi() to createParking() to createPushBack() to createTaxi().
Finally, a blatant typing error in the getParking() function was fixed.
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.
Auf Niederlandisch:
Bij deze de patch voor de taxiway code. Deze code is nog gebaseerd
op de bestaaande architectuur, gebaseerd op de FGAirport class in simple.[ch]xx
Ik heb me voornamelijk gericht op nieuwe functionaliteit; de volgende
submissie zal waarschijnlijk bestaan uit opschoning, opsplitsing en een
implementatie van de nieuwe airport architectuur, zoals voorgesteld door
David Luff.
En Anglais:
Here is the patch for the taxiway code. This code is still based on the
exsisting architecture, which is based on the FGAirport class in simple.[ch]xx
I've aimed mostly at new functionality; The next batch will probably contain
code cleanups, splitups and the implementation fo the new airport architecture,
as proposed by David Luff.
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.
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>.
