arrays of insufficient size are allocated in prop_picker.cxx ( size()
don't count the null char ) and strcpy is writing outside the allocated
array. A patch follow.
Here's a change to the GUI property picker I did a few weeks back.
It makes the values in the property pick 'live' (and also re-factors
the picker code to use less arrays, this should be obvious from the
diffs). A good demo is to open up the engine node and observe the rpm,
cylinder head temp, oil pressure and so on while playing with the
throttle and airspeed. It's pretty rough (some rounding of digits would
help) but useful for testing (at least I think so). I'm not sure about
the performance implications either, but it seems fine for me.
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
Fix memory leaks (PUI doesn't make copies of lists, so we have to make
our own copies and keep pointers to them).
Adjust for new method names in NewGUI.
Move the GUIInfo struct into the cxx file so that it's not part of the
public interface.
menubar. This one allows regular command bindings, with the
(temporary) condition that every menu item must have a unique text
label. The new menubar is disabled by default; to enable it,
configure --with-new-menubar.
Some more cmall changes to the SimGear header files and removed the
SG_HAVE_NATIVE_SGI_COMPILERS dependancies from FlightGear.
I've added a seperate JSBSim patch for the JSBSim source tree.
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.
