1. Nodes cache previous relative paths so that they do not have to
parse the paths each time.
2. There are new getNode() methods that include indices, so that users
do not have to sprintf to a buffer to iterate through indexed nodes.
developer will need to build and install these separately if they
don't have packages already installed by their system. See
README.metakit and README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source
code trees are included with the simgear distribution (and cvs.)
developer will need to build and install these separately if they don't
have packages already installed by their system. See README.metakit and
README.zlib for more details.
As a convenience, pristine tarballs of the metakit and zlib source code
trees are included with the simgear distribution (and cvs.)
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
TRACE_READ - log a message whenever the property is read.
TRACE_WRITE - log a message whenever the property is written.
The second one works only when the property value is changed through
the property manager; tied variables and accessors are not polled for
value changes because of the performance hit.
These methods end up invoking private methods
SGPropertyNode::trace_read and SGPropertyNode::trace_write. By
setting breakpoints on these methods inside a debugger, it is possible
to debug property access and find what parts of a program are reading
or writing specific property values by doing a backtrace.
In the XML property files, users can use the attributes 'trace-read'
and 'trace-write' to control tracing; the value should be 'y' to
enable tracing or 'n' to disable it (the default).
model math blows up, the lat/lon could be nan. Thus updateLocal() could
potentially called with nan arguments if FlightGear is reiniting from a
blown up state. This is a bug in FlightGear, but I've added a simple
check to catch this so updateLocal() is robust if called under these
circumstances.
I can't find anything that addresses this in Stroustrup, but I also don't
see them doing this in any of their examples. So I have rewritten this
instance to use default arguments to accomplish the same thing. I imagine
there are other instances of this same sort of thing in other classes to
be fixed at a later date.
