Some quite extensive changes to the AIModel code:
1. Mathias has made major changes to the AICarrier code to provide better
alignment of an aircraft on deck with the carrier - this feature is a major
improvement on the existing, but has a bug which might cause it to fail when
the computer carries out other tasks - changing window size is a known
example. This bug is outwith this code.
2. I have made significant changes to the AIShip code to enable a ship the
turn and roll smoothly.
3. I have added some simple AI which enables the carrier to remain within,
or return to, an operating box.
4. An automated turn into wind for flying operations.
5. A simplistic implementation of TACAN within AICarrier. I am in the course
of implementing this as a generic instrument, but this is some time off
completion.
I have introduced the posibility to start directly on the carrier.
With that patch you will have a --carrrier=id argument where id can either be
the pennant number configured in the nimitz scenario or the carriers name
also configured in the carriers scenario.
Additionaly you can use --parkpos=id to select different positions on the
carrier. They are also configured in the scenario file.
That includes the switch of the whole FGInterface class to make use of the
groundcache.
That means that an aircraft no longer uses the current elevation value from
the scenery class. It rather has its own local cache of the aircrafts
environment which is setup in the common_init method of FGInterface and
updated either manually by calling
FGInterface::get_groundlevel_m(lat, lon, alt_m);
or implicitly by calling the above method in the
FGInterface::_updateGeo*Position(lat, lon, alt);
methods.
A call get_groundlevel_m rebuilds the groundcache if the request is outside
the range of the cache.
Note that for the real usage of the groundcache including the correct
information about the movement of objects and the velocity information, you
still need to set up the groundcache in the usual way like YASim and JSBSim
currently does.
If you use the native interface, you will get only static objects correctly.
But for FDM's only using one single ground level for a whole step this is IMO
sufficient.
The AIManager gets a way to return the location of a object which is placed
wrt an AI Object. At the moment it only honours AICarriers for that.
That method is a static one, which loads the scenario file for that reason and
throws it away afterwards. This looked like the aprioriate way, because the
AIManager is initialized much later in flightgears bootstrap, and I did not
find an easy way to reorder that for my needs. Since this additional load is
very small and does only happen if such a relative location is required, I
think that this is ok.
Note that moving on the carrier will only work correctly for JSBSim and YASim,
but you should now be able to start and move on every not itself moving
object with any FDM.
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
carrier.
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.
We should now be able to find
wires or catapults when the ac3d model is loaded without the crease patch
(caused by the much more unstructured scene graph emitted by the old loader).
It should also emit more warnings if the carrier hardware configuration
includes conflicting definitions.
That code is the most intrusive one, it should not be used until you configure
an aircraft carrier as a aimodel. So I think it should be save to apply that
before the release too.
I have a small update which fixes the algorythm used for marking solid
surfaces for some cases where some branch nodes carry the object names I had
expected in the leaf nodes.
That will also introduce the possibility to mark whole subtrees from the
scenegraph solid.
This is a sub-system which can be added to any carrier.
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.
