Talk:Common aircraft properties
You'll probably want to check out some related discussions, such as these:
Pay particular attention to postings made by David Megginson, the original designer/developer of the property tree code in FlightGear/SimGear. Reading up on what's been said and suggested back then, may save you a fair amount of time. Personally, I belong to the camp of people who believe that we should be using scripting and XML attributes to make the property tree self-documenting, otherwise, info will get out of date too quickly - especially because aircraft developers are free to make up their own properties.
Short comment time: some of these you are mentioning are created/initialized/tied in C++ code, so making sure they are there is not an issue (or did I misinterpret what you said?). —Philosopher (talk) 03:35, 31 July 2013 (UTC)
|e.g. Speedbrakes and thrust reversers are found in different location in the property tree, even across official FlightGear planes! Without standard locations, joystick code tends to be aircraft specific.
How does that justify moving/copying all of the other properties that do have the same path for all aircraft? The properties I changed are hardcoded and thus they exist for all aircraft. They are independent of the aircraft configuration and/or FDM used.
I like the idea of unifying properties among aircraft, but I don't see why we need to move existing defaults that have been around for years and are used all over the place (joystick configs, animations, custom protocols etc).
- P.S. The plural of gear is gear anyways  (just like deer and deer), so no need to rewrite the rules of grammar as well :P —Philosopher (talk) 17:34, 18 August 2013 (UTC)
So the general apathetic support for actually forming a standard is quite frustrating. A user even said having aircraft specific joystick code was no reason to create a standard as he had already hard coded it. Such an attitude of 'I'll do whatever I want and walk my own path' will not lend itself to any open standard. The original intention of this was to create a more definitive standard as opposed to the loosely enforced guidelines from the original as noted by the email, while still maintaining the best compatibility (read as: least amount of work) with existing aircraft and/or existing code.