![]() ![]() Using native protocols, implemented in C++ (see $FG_SRC/src/Network).This is the way most aircraft are implemented. Nasal scripts - this is javascript-like scripting with read/write to the property tree.internal compiled code within FG - the c/c++ code.startup arguments via -prop:/sim/foo=bar.The property tree is read, written, accessed and manipulated in a variety of ways, such as If you wish to use a custom-written subsystem, such as your own terrain following and avoidance subsystem, for example, and perhaps implemented in Nasal, adding new property tree branches and nodes to handle your unique data presents no problems. The aircraft model has an xml file of properties that will be used within the property tree.Ĭustomizing and manipulating the property tree through NasalĪn important feature of the property tree interface is that it can be tailored and new entries added as required through Nasal scripts, without requiring C++ changes. What makes FlightGear powerful is that a new aircraft can easily be designed with its unique set of properties that somehow affect the simulation. Some of these variables are "calculated" within the sim (for example updated regularly, in essence at frame rate), whilst others can be manipulated. Naming a property is very much like naming a file in a file system, with levels of hierarchy. ![]() There are several subsystems that implement a full API by extending the property tree, such as the AI traffic system, the multiplayer mode, but also Canvas - basically, setting certain properties (for example via Nasal's setprop()), triggering 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). The output from the external FDM can then be fed back to FlightGear by writing its data back to the property tree, once again, via the FlightGear I/O subsystem. The FDM subsystem then in turn outputs an aileron deflection back to the property tree where it is then read by the FG animation subsystem to animate the aileron deflection in the 3D model.Īlternatively the joystick input, once exposed in the property tree, can be read and modified by an external application via the FlightGear I/O subsystem, such as an external FDM. 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.įor example, a left banking joystick input is exposed in the property tree where it is read by the FlightGear FDM sub-system. There is some basic property-debugging support to FlightGear and SimGear. Data that is required by one FG sub-system can be exposed in the property tree, where it can then be read or modified, either by other internal FG sub-systems, or by and for external input/output. Thus, the property system acts as a routing interface, both between different high-level FG sub-systems and the outside world. In addition, callbacks can be registered to invoke code upon read/write access of properties, which serves as the backbone for a very simple, but powerful, signalling mechanism in FlightGear. One might think of the property system as a global, normalized communication platform, where subsystems may publish variables and access other subsystem's variables. A system may present its current state to other systems and let them change its current state by allowing to write to its own properties. The content of these internal state variables are presented in a hierarchically manner and can easily be accessed through a well known API. The property system - or property tree - represents most of the internal state of all systems within FlightGear, like for example the flight dynamics models, or the weather simulation. 7 Reference documentation to the property tree.6 Dumping the Property Tree to an XML File.5 Network Protocols to access the property tree.3 Customizing and manipulating the property tree through Nasal.2 The organization of the property tree. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |