20,741
edits
Property tree: Difference between revisions
Jump to navigation
Jump to search
m
http://forum.flightgear.org/viewtopic.php?f=6&t=23180&p=211094#p211094
m (cat sort: Showing the article first on the category page) |
m (http://forum.flightgear.org/viewtopic.php?f=6&t=23180&p=211094#p211094) |
||
| Line 14: | Line 14: | ||
For example, a left banking joystick input is exposed in the property tree where it is read by the FG FDM sub-system. The FG FDM sub-system then in turn outputs an aileron deflection back to the property tree where it is then read by the FG animation sub-system to animate the aileron deflection in the 3D model. | For example, a left banking joystick input is exposed in the property tree where it is read by the FG FDM sub-system. The FG FDM sub-system then in turn outputs an aileron deflection back to the property tree where it is then read by the FG animation sub-system to animate the aileron deflection in the 3D model. | ||
Alternatively data [the joystick input], once exposed in the property tree, can be read and modified by an external application | Alternatively data [the joystick input], once exposed in the property tree, can be read and modified by an external application via the FG IO sub-system, such as an external FDM. | ||
via the FG IO sub-system, such as an external FDM. | |||
The output from the external FDM can then be fed back in to FG by writing it's data back to the property tree, once again, via the FG | The output from the external FDM can then be fed back in to FG by writing it's data back to the property tree, once again, via the FG IO sub-system. | ||
IO sub-system. | |||
In addition to the protocols supported by the FG IO sub-system there are also telnet and http interfaces, which allow property tree data | In addition to the protocols supported by the FG IO sub-system there are also telnet and http interfaces, which allow property tree data | ||
| Line 29: | Line 27: | ||
Adding new property tree branches and nodes to handle your unique data presents no problems. | Adding new property tree branches and nodes to handle your unique data presents no problems. | ||
Naming a property is very much like naming a file in a file system, with levels of hierarchy. | Naming a property is very much like naming a file in a file system, with levels of hierarchy. | ||
| Line 36: | Line 33: | ||
Values in the tree are typed, but they can also be untyped strings which will be converted to a typed value when read. | Values in the tree are typed, but they can also be untyped strings which will be converted to a typed value when read. | ||
PropertyList-encoded XML files are mapped to a/the "property tree" data structure, which is what is commonly used to tie together different subsystems and features - typically, such XML files are not manually processed, they are "transparently" processed by FlightGear, loaded and mapped into a Property Tree, that can be manipulated/modified using either C/C++ code, or FlightGear scripting (through Nasal). There are several subsystems that implement a full API on top of the property tree, such as the AI traffic system, but also Canvas - basically, setting certain properties (e.g. via setprop), triggers certain code (through listener callbacks) - with arguments and return values passed through the property tree, which in turn allows arbitrary 3D models to be placed, but also AI traffic to be created / controlled, as well as OpenGL textures to be created and modified and run-time, which is what we use to implement HUDs, GUIs, instruments, MFD avionics, and even liveries or scenery textures (VGDS). | |||
== Protocol Options == | == Protocol Options == | ||