|This article is a stub. You can help the wiki by|
See Resource Tracking for FlightGear for the main article about this subject.
Some basic property-debugging support to FlightGear and SimGear. In FlightGear, the
--trace-read option causes all read access for a property to be traced, and the --trace-write option causes all write access for a property to be traced, both through SG_LOG messages.
Tracing a popular property like /position/altitude will cause a lot of output and will slow down FlightGear, but presumably, you're debugging anyway so you won't mind.
The neatest part of all this is that it allows you to debug properties and C++ code together in a regular debugger. The
--trace-read property causes SGPropertyNode::trace_read to be invoked, and the
--trace-write property causes SGPropertyNode::trace_write to be
Let's say that you wanted to find out what parts of the C++ code are setting the
/foo/bar property. You would load FlightGear into a
debugger, set a breakpoint on SGPropertyNode::trace_write (in simgear/simgear/props/props.cxx in the SimGear distro), then run the program with the following option:
Every time any code sets a new value for
/foo/bar, you'll hit your breakpoint, and you can look at the backtrace to find out where it is being set.
You need the trace feature for debugging user configuration, not just C++ code. Again, think of FlightGear as analogous to a word processor or spreadsheet: users will always be loading new kinds of data -- designing new panels and flight models, scripting events, creating scenarios, etc. etc. The trace feature gives some (pretty minimal) support for design, testing, and debugging their work.
|I hacked my copy of FlightGear to loop through property accesses multiple times and watched the framerate. Here's what I got, using the lower value whenever the framerate fluctuated:
— David Megginson (Tue, 26 Feb 2002). re: [Flightgear-devel] Property Access.