I was going through the Ai scenarios and see that some of them are not
necessary.
Also, I've added some documentation to the other scenarios. And I moved the
thunderstorm over San Francisco, so you don't have to take off to see it.
The files are attached.
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
I attach the long-promised improved version of the USS Nimitz.
It includes an improved version of the FLOLS, which requires the attached
diff to be applied to AICarrier.cxx and AICArrier.hxx.
I've made lots of eye-candy in the form or the flightdeck crew.
Unfortunately, it about doubles the size of the tarball. I'll send it to you
later; when I've figured out some way of only loading on request (any advice
would be very welcome).
I could provide a \u2018bare\u2019 version to cut down on the vertex count for
less capable systems however, the count isn\u2019t huge in the first place.
I've cut the textures down as far as I can without losing definition.
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.
I have now the FDM side of an aircraft carrier set up.
The implementation uses a local cache of the scene graph to do intersection
tests. This can then be done per gear/hook/lauchbar.
Also the required aircraft carrier hardware will show up in this cache and can
provide the required information.
The cache itself is ATM integrated into the FGInterface class.
New are functions to query a ground contact point below a given location in
the earth. Together with that contact point the surface normal and the
velocity of that contact surface are returned. The locations, normals and
velovities are cartesian vectors given in the wgs84 coordinate system (origin
in the earths center, x axis towards lat=lon=0, y axis towards lat=0, lon=90,
z axis towards the north pole).
A function to test catching a wire. The test is done by intersection of the
quad where the hook moved during the past timestep with the lines
representing the wires. When this test was sucessfull, we can query for the
locations/velocities of the wires mount points. When the wire is no longer
needed it should be released.
Catapults are also stored as special lines in the scenegraph. There is a
function which returns the nearest catapult line and its current
locations/velocities.
To build up the cache you need to call a function to let the cache know where
and how big the cache must be.
I have also a preliminary implementation to make use of that stuff from within
JSBSim together with an aircraft which I have used for development.
To play with that, you have to install the patches/new files described above.
The hook can be extended with the H key, retracted with h. Start flightgear
with
fgfs --lat=37.688 --lon=-122.683 --heading=180 --altitude=71
and you will be placed on the carriers deck rolling backwards wrt the carrier.
Then apply the breaks and wait until the aircraft settled down past being not
trimmed. Now taxi on the deck to one of the catapults. When the nose wheel is
above the first few meters of the catapult (please taxi exactly there). Apply
the breaks and leave them applied. lower the flaps to half and give full
throttle. Pull a little at your stick and release the breaks. As the breaks
are released the aircraft is launched.
Then you can cruise a bit, and again try to land on the nimitz. When you land,
do not forget to extend the hook with 'H'.
If you like it, you can then taxi to the catapult ... :)
The physical model is not yet ready, but the api between the FDM and
flightgear has prooven to be sufficient for that task.
I attach the latest version of Nimitz. The textures have been improved. A glide-path has been added, it is on by default, but can be switched off by means of the properties browser: /ai/models/ship/controls/glide-path. The origin has been adjusted to the turning pivot and approximate roll center.
Modified AiShip files are also attached. These allow the radius of the turning circle of a ship to be input. The turning circle is adjusted for speed and rudder angle. Roll has been corrected so that a ship leans out of a turn, not inwards like an aircraft. The roll angle is adjusted for speed and rudder angle (yes, application of more rudder reduces roll angle - rudders act as stabilizers).
TODO
Add a relative wind calculation so that a carrier can be turned to the appropriate launch and recovery courses.
Add a 'flight plan' so that the carrier can carry out a racetrack for flight ops.
Add a projector landing sight.
Add auto-land facilities.
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.
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.
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.
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>.
