etc.
Improved the weather system to interpolate between different
elevations and deal with boundary-layer conditions. The configuration
properties are now different (see $FG_ROOT/preferences.xml).
Normally for smoothest frame rates you would configure to sync
to your monitor's vertical refresh signal. This is card/platform
dependent ... for instance with Linux/Nvidia there is
an environment variable you can set to enable this feature.
However, if your monitor is refreshing at 60hz and you can't quite sustain
that with flightgear, you can get smoother frame rates by artificially
throttling yourself to 30hz. Note that once you are about about 24fps, it
is *change* or inconsistancy in frame rate that leads to percieved jerkiness.
You want to do whole divisors of your monitor refresh rate, so if your
display is syncing at 75 hz, you might want to try throttling to 25 hz.
Melchior FRANZ:
The reason: these models are to be added to the scenery, but the
scenery isn't yet set up at this point. The correct order is:
- set up model_lib (needed by the scenery)
- set up scenery (needed by the model manager)
- set up model manager
What is actually happening is the camera is pointing to the right place (try zooming in), but the camera is also travelling up and down with the nose and it should be staying more steady (in sync with the CG altitude).
Attached is a fix for this. There is still something a little funky going on with the camera, but this solves the biggest problem. You will note that I deleted an unecessary reference to scenery.hxx in the patch.
I split the FGModelPlacement code out into it's own set of source files.
I created two versions of the fgLoad3DModel() routine. One that is
unecumbered by a panelnode dependency and one that is. acmodel.cxx is
the only place that needs to load an aircraft with instrument panels.
model.[ch]xx are now pretty much free to move over into simgear.
loader.[ch]xx should be able to follow closely behind.
This will be a big step towards being able to move the material management
code over into simgear.
the ascii scenery file format has actually worked in quite some time, and the
ADA runway light code has been supersceded by a slightly different mechanism.
requested parameters to determine if this should be an on-ground vs. in-air
start. The problem was that we never defaulted the value to anything so
if we didn't match an in-air condition, we simply inherited whatever value
was there from before.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
Set a random value for a numeric property
Params:
<property> - the name of the property to randomize
<min> - the minimum allowed value
<max> - the maximum allowed value
The one to fg_init.cxx initialises the AI subsystem regardless of whether it's enabled or not so that later enabling by the user doesn't crash it, and the one to main.cxx avoids running the ATC manager and ATC display system unless enabled.
