- this exposed a bizarre issue on Mac where dragging in <AGL/agl.h> in
extensions.hxx was pulling in all of Carbon to the global namespace
- very scary. As a result, I now need to explicitly include CoreFoundation
in fg_init.cxx.
- change SG_USING_STD(x) to using std::x
From Till:
i started the project at the end of february with a simple idea: move all
3d-model loading to the DatabasePager-thread. my first attempts looked
promising, though they were a little too optimistic (or naive?). the patch
has evolved a lot since.
currently it does the following things:
1. revive SGModelLib, move functions for xml-model-loading there
2. replace all calls to sgLoad3dModel with calls to either
SGModelLib::loadModel() or SGModelLib::loadPagedModel()
almost all models will be loaded by the DatabasePager. the few exceptions are:
your own plane, shared models in scenery, random objects, AIBallistic models.
3. simplify mode-loading functions (avoid passing around fg_root)
4. avoid supurious MatrixTransform nodes in loaded models
5. fix some memory leaks
This patch makes use of the vectors now available in simgear with that past
patch. And using that it simplyfies the carrier code somehow.
- Small additional factory's to the quaternion code are done in the simgear
part. Also more explicit unit names in the factory functions.
- The flightgear part makes use of them and simplyfies some computations
especially in the carrier code.
- The data part fixes the coordinate frames I used for the park positions in
the carrier to match the usual ones. I believed that I had done so, but it
was definitly different. Also there are more parking positions avaliable now.
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 ...
- fix indentation (there were 2, 3, 4, 7(!) space indents as well as tab
indents, all mixed together)
- no code changes, except one "if (foo) {}" changed to "if (!foo) return; ..."
* 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.
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.
