different locations, and hitched it into FGGlobals. FGEnvironmentMgr
has taken over as the subsystem, while FGEnvironment is simple the
information that it returns. I've removed current_environment
completely -- everything now uses properties or goes through
FGGlobals. FGGlobals itself has a couple of useful methods:
const FGEnvironment * get_environment ();
const FGEnvironment * get_environment (double lat, double lon, double alt);
The first one returns the environment data for the plane's current
position, while the second returns the environment data for any
arbitrary location. Currently, they both return the same information,
but that will change soon.
properties have been renamed from wind-(north|east|down)-fps to
wind-from-(north|east|down)-fps, and the FDMs modified appropriately.
No other changes should be visible unless FG_OLD_WEATHER is defined.
are being driven from an external data source.)
Akso found and fixed a bug in the simgear that caused the time to go goofy
temporarily while scenery was being loaded.
/sim/freeze/master (implimented)
/sim/freeze/fuel (implimented)
/sim/freeze/position (not implimented)
/sim/freeze/time-of-day (not implimented)
/sim/freeze/master is bound to the 'p' key via keyboard.xml, however,
/sim/freeze/fuel is not bound to anything at the moment so you must
change it via the external property interface, or specify an initial
value on the command line.
function to allow property files as non-option parameters after the
options have finished (and added "--" to terminate options). It's now
possible to do something like
fgfs denver-am.fgd
or even
fgfs at-lax.fgd in-c310.fgd around-sunset.fgd
This works the same way as the --config option, but will be friendlier
for GUIs, where start-up situation files can now be associated easily
with FlightGear.
material-specific logic is now removed from the material library and
encapsulated in the material class itself, and materials are loaded
from $FG_ROOT/materials.xml rather than $FG_ROOT/materials. This also
removes a nasty bug in the old material-loading code that caused a
floating-point exception.
works like this:
1. Parse preferences.xml, which will usually specify a default
aircraft using the /sim/aircraft property.
2. If /sim/aircraft is specified and not empty, parse the properties
in $FG_ROOT/Aircraft/{/sim/aircraft}-set.xml to set up a default
aircraft.
3. During command-line parsing, whenever the --aircraft option appears
set /sim/aircraft appropriately and parse the properties in
$FG_ROOT/Aircraft/{/sim/aircraft}-set.xml. Any --config, --prop, or
--aircraft options afterwards will take precedence.
more intuitive. We switch to an include in the preferences.xml to include
the default model, and then if the user specifies --aircraft=, that is
expanded immediately so portions can be overwritten by subsequent command
line options.
a top level aircraft def file (c172-set.xml)
preferences.xml or --aircraft= or any other property setting mechanism can
be used to set the property "/sim/aircraft". After all options and config
files are parsed, the contents of /sim/aircraft is expanded into a *-set.xml
file and loaded.
fix startup sequence problems where we initialize the FDM before we know
the desired starting altitude.
These changes delay fdm initialization until the local tile has been loaded
and we can do a real intersection and find the true ground elevation.
In order to do this, I depend more on the property manager as glue, rather
than the FGInterface.
There are some glitches still when switching to a new airport or reseting
the sim. I will work on addressing these, but I need to commit the changes
so far to keep in sync with other developers.
meaning of "win_ratio". I've removed win_ratio and added fov_ratio and
aspect_ratio, as it seems both are needed.
n.b. The multi-line changes in fgReshape comprise:
extracting common code,
removing an apparently arbitrary "+1" on the view height,
changing "set_win_ratio" to "set_aspect_ratio".
I've updated the WeatherDatabase to be able to use only the n closest
stations. This can speed up the initalization dramatically.
To take a benefit from that you need:
- http://129.13.102.67/out/flight/current.txt.gz in
FG_ROOT/weather/current.txt.gz
- --prop:/environment/weather/working-type=internet
- --prop:/environment/weather/max-stations=what_ever_you_want
The WeatherCM stuff now publishes its data in the property system.
/environment/weather/wind-north-mps
/environment/weather/wind-east-mps
/environment/weather/wind-up-mps
/environment/weather/temperature-K
/environment/weather/air-pressure-Pa
/environment/weather/vapor-pressure-Pa
/environment/weather/air-density
are the new properties.
(src/Input). So far, FGInput replaces most of src/Main/keyboard.cxx
(I've left a tiny stub); in the very near future, it will also take
over control of the joystick, mouse (Norm permitting), and panel
instrument interactions, so that there is a single mechanism for
configuring all input devices.
The new format should be (close to) self-explanatory by looking at the
new base-package file keyboard.xml, which is now included by
preferences.xml (I'll do the same thing for the joystick when I have a
chance). I have not managed to move all keybindings into this file
yet, but I've made a good start. I'm including Tony in the recipient
list so that he can see how bindings can use an external XML file.
This patch also adds support for multiple bindings for a single key,
special keys (i.e. keypad and function keys), and key modifiers
(shift/alt/ctrl); special keys use the PUI convention of adding 256 to
the Glut key code.
Unfortunately, everything comes with a price; in this case, I have not
yet found a general mechanism for the old (hard-coded) modal bindings,
which behaved differently depending on the autopilot state (i.e. left
rudder or move AP heading left); with my patches, this functionality
disappears, but you can still adjust the autopilot using the panel or
the GUI input dialogs.
The files in the attached tarball make the following changes to
FlightGear:
- rename the existing FGInterface::init() method to
FGInterface::_setup to get it out of the way
- move *all* FDM initialization code out of src/Main/fg_init.cxx and
into FGInterface::init(), and clean up fg_init.cxx a little
(especially by removing the zillions of attempts to place the plane on
the ground at various locations in the code)
- modify FGInterface::bind() so that no values are picked up
automatically at bind time (they are set previously by init() instead)
- modify the init() methods of the classes derived from FGInterface
(i.e. larcsim, jsbsim, balloon, magic, and ada) to invoke
FGInterface::init() explicitly before doing their own setup
I don't claim that the code in FGInterface::init() is optimal (or even
correct), but it seems to work for on-ground starts with both LaRCSim
and JSBSim on runways pointing various directions from near sea level
to about 700' ASL (the range I happened to test). I expect that Jon
and Tony will want to look at the code and refactor and correct it now
that they can see what's going on in one place.
Here's a quick outline of what is invoked:
cur_fdm_state = new <whatever>(dt);
cur_fdm_state->init();
cur_fdm_state->bind();
The constructor allocates memory and sets default values only (with
the help of the FGInterface::_setup() method). The init() method pull
any required properties out of the property tree and sets up the
initial state of the FDM. The bind() method takes ownership of
FDM-related properties so that the FDM can publish them to the rest of
the sim.
Note that bind() and init() are virtual, so any implementation in a
subclass will hide the implementation in FGInterface; that's why
subclass implementations of init() and bind() have to invoke
FGInterface::init() and FGInterface::bind() explicitly, probably at
the start, so that they get the basic initialization.
