This is a very good start and an important thing in the long run. But quite a number of these issues are directly related to changes in the property tree and it would be unnecessarily tedious for users to check back with the wiki in my opinion. My suggestion would be to consider introducing an intermediate "management layer" (i.e a C++ class) here that could optionally be "plugged" into the SGPropertyNode class and manage properties that are being renamed, phased out or completely replaced. The only thing required here would be an option to specify types of events and a callback to be invoked when the condition is triggered. This would make it possible to register the SG_LOG mechanism and issue warnings to the console (or even to the property tree, so that they can be processed and visualized using Nasal/GUI dialogs) whenever certain properties are being accessed. The neat thing about using the SG_LOG mechanism, is being able to use fstreams, too - so that users could possibly even redirect such "reports" to a separate text file. This might be really useful while preparing releases or generally while re-packaing aircraft. Ideally, one would end up with a separate header file that sets up depreciated properties and assigns corresponding callbacks. This would make it much easier for everybody to easily rename/change or phase out properties, while providing well-defined migration paths, as well as configurable "grace period" while doing so (backward compatibility).--Hooray 11:22, 10 December 2011 (EST)
The info about instant replay is insufficient for dev. I forgot where I got the info to add a signal else I would have included it.
- PH-JBO 16:03, 13 December 2011 (EST)
Could someone, who knows, add some info about the last section "Parking Positions"? What are the lines doing? I wonder especially what this