The general idea is to help clean up some aspects of the FDM init and be
able to provide startup conditions in a less ambiguous manner.
Previously, things like positions, orientations, and velocites were set on
"the bus". These had to be read by the FDMs which then were supposed to
initialized themselves to those values and turn write around and start
modifying those values. It was messy and cumbersome.
Now, all the initial fdm conditions are written to a sub-[property-]tree
under /sim/presets/
The values in /sim/presets/ always stay set to what the user has specified.
The user can change these at his/her liesure, and then request a "reset"
which will reset to the new conditions. I don't even want to say how this
worked before. :-)
Now, an script, or gui interface can stage a set of initial conditions while
the sim is running (without disrupting it), and then call "reset" to commit
the change.
People who should worry about all this are FDM writters, and a small few
others who care about over all program structure and flow.
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
separate header file. This change will help integrate properties into
JSBSim.
Also, I (David Megginson) removed most of the SimGear include
statements from globals.hxx, reducing the amount of recompilation
every time SimGear changes. This required making minor changes to a
lot of files that were depending on the side-effects of the inclusions
in globals.hxx.
- implement the standard FGSubsystem interface, for consistency
- eliminate current_autopilot and add get/set_autopilot to FGGlobals,
for consistency
- use private methods rather than static functions for tying
properties
There should be no change in functionality.
These changes add to the "Add Waypoint" dialog so that you can see the entire
list in the pui dialog that you are adding to. Also made some minor changes
so that the autopilot is now activated (toward first waypoint target heading)
when a waypoint is added.
the panel controls for the autopilot. The heading dialog would only show the
last setting you did through it, even if it was later tweaked with the bug on
the hsi. The altitude dialog did a similar thing. Now the values default to
the same that show on the panel displays.
FGOptions is history, and the modules are (starting) to use the property
manager directly. Let me know if I left any files out.
Inevitably, there will be some problems with broken options, etc.,
that I haven't found in my tests, but I'll try to fix them quickly.
We also need to stress that the property names currently in use are
not stable -- we need to reorganize them a bit for clarity.
