"Preparations for an upgrade to Air-to-Air Refuelling to allow more than one
tanker in the environment at a time. This will only work with YASim models.
JSBSim models are unaffected by this change."
"Add Air to Air TACAN. With this facility TACAN equipped aircraft can
measure the range and bearing of TACAN equipped AI Aircraft. ATM there is
only one assigned - callsign ESSO1 on TACAN channel 039X, but this can be
easily expanded to include other c/s channel # pairs - just ask me if you
want more."
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 ...
- Feet to meter conversion mistake (in AI getGround elev)
- Improved ground following code (not yet perfect, but for now no one will
notice it within the marginal altitiude differences at the taxitrack or
runway)
- Exclusion of the "AI" directory witihin data/Aircraft in
main/init/fgSearchAircraft, to prevent AI aircraft to be picked up by the
aircraft search function
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.
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.
Here's some additions to AI that allow refueling from an AI tanker (the actual
onload of fuel must be handled by the user's FDM of course, this just lets
the FDM know that the user is in position to refuel).
I've added a new class of AIAircraft called "tanker". It uses the same
performance struct as a jet transport. An AI tanker is just like an AI jet
transport, except it uses the already-existing radar data to control the
boolean property systems/refuel/contact. The code change was minimal.
An AI tanker can be created like this:
<entry>
<callsign>Esso 1</callsign>
<type>aircraft</type>
<class>tanker</class>
<model>Aircraft/737/Models/boeing733.xml</model>
<latitude>37.61633</latitude>
<longitude>-122.38334</longitude>
<altitude>3000</altitude>
<heading>020</heading>
<speed>280</speed>
<roll>-15</roll>
</entry>
This puts a tanker over KSFO at 3000 feet, in a left-hand orbit. When the
user gets within refueling range (contact position) then the property
systems/refuel/contact will be true. Otherwise it is false.
The dimensions of the refueling envelope are pretty rough right now, but still
usable. The user must be behind the tanker (ie. radar y_offset > 0). The
user must be at or below the tanker's altitude (ie. radar elevation > 0).
The user's lat/lon must be within 250 feet of the tanker's lat/lon (ie. radar
range_ft < 250). This last requirement is loose because the radar data is
only updated every 100 ms, which is accurate enough for radar use, but
which is sloppy for air refueling. This could be tightened up by increasing
the radar update rate to once every sim cycle.
I'm going to add a light to the T-38 instrument panel that will monitor the
property systems/refuel/contact. This will make it easier to explore the
boundaries of the refueling envelope.
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>
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>.
Here's a new batch of AI code which includes a working radar instrument.
I put the radar calculations into the existing AIAircraft class. It was
easier that way, and it can always be migrated out later if we have to.
Every tenth sim cycle the AIManager makes a copy of the current user state
information. When the AIAircraft updates it uses this information to
calculate the radar numbers. It calculates:
1) bearing from user to target
2) range to target in nautical miles
3) "horizontal offset" to target. This is the angle from the nose to the
target, in degrees, from -180 to 180. This will be useful later for a HUD.
4) elevation, in degrees (vertical angle from user's position to target
position)
5) vertical offset, in degrees (this is elevation corrected for user's pitch)
6) rdot (range rate in knots, note: not working yet, so I commented it out)
and three items used by the radar instrument to place the "blip"
7) y_shift, in nautical miles
8) x_shift, in nautical miles
9) rotation, in degrees
The radar instrument uses the above three items, and applies a scale factor to
the x-shift and y-shift in order to match the instrument's scale. Changing
the display scale can be done entirely in the XML code for the instrument.
Right now it's set up only to display a 40 mile scale.
The radar is an AWACS view, which is not very realistic, but it is useful and
demonstrates the technology. With just a little more work I can get a HUD
marker. All I need to do there is make a bank angle adjustment to the
current values.
