- 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
I've got some updates for the soaring scenario that will make for a more
realistic (and fun) experience. They are:
1) A cap cloud, which will sit atop each thermal
2) A thermal scenario with wide coverage around KSFO, and using cap clouds
3) A one-line change to AIThermal.cxx to position cap cloud properly
4) Schweizer 2-33 set file change to match cloud coverage with thermal
heights.
files:
1) data/Models/Geometry/thermalcap.ac
2) data/Models/Geometry/thermalcap.xml
3) data/Models/Geometry/thermal_cap.rgb
4) data/AI/thermal_demo.xml
5) data/Aircraft/sgs233/sgs233-set.xml
6) source/src/AIModel/AIThermal.cxx
*** or, if you prefer diffs ***
7) aimodel.diff
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 ...
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 added some things to the AI stuff to improve the AIThermal processing.
Before, all the thermals were processed in order, and the last one overwrote
the prior one. Now, only the data from the nearest thermal is kept. This
way a tile can be populated with many thermals, and (as long as they have the
same diameter) the one nearest the airplane correctly takes effect. This
will make us ready for the next step, "auto-thermaling", where FlightGear's
tile manager can cover a tile with thermals, and set the thermal strength
based on land-use type.
I moved the enumerated object_type to the base class. When an AI object is
created it now sets the _otype variable in the base class. This lets the AI
manager find out what kind of AI object it is dealing with, using the base
pointer. I also added a function isa() to the base class, so the manager can
process objects differently based on their type.
The AI manager now sends AIThermal processing to a different function, where
only the data from the nearest thermal is kept. After the manager processes
all the AI objects, then the results from the nearest thermal are applied to
wind-from-down.
