980
edits
User:Callahanp: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Getting it together) |
No edit summary |
||
| Line 7: | Line 7: | ||
It's not clear from existing documentation the central role of Nasal scripting in the simulation. It's not just C++, Nasal, and the interface between them, understood as computer languages. Knowing the languages and interfaces themselves is vital, but even more important is understanding how scripting is used in FlightGear to create the simulation. If you are struggling as a newcomer to understand FlightGear's C++ code, understanding Nasal's role in driving parts of the simulation and the way it interacts with C++ code is probably one of the first things to do. It's what I'll be doing next. | It's not clear from existing documentation the central role of Nasal scripting in the simulation. It's not just C++, Nasal, and the interface between them, understood as computer languages. Knowing the languages and interfaces themselves is vital, but even more important is understanding how scripting is used in FlightGear to create the simulation. If you are struggling as a newcomer to understand FlightGear's C++ code, understanding Nasal's role in driving parts of the simulation and the way it interacts with C++ code is probably one of the first things to do. It's what I'll be doing next. | ||
Part of understanding any body of code is to be able to identify how data flows through the application. Dataflows are usually represented as arrows | Part of understanding any body of code is to be able to identify how data flows through the application. Dataflows are usually represented as arrows of various widths. The arrows are messages flowing between parts of an application. The larger the arrow, the more data items in that data flow. | ||
In FlightGear's C++ code, there are, of course, classes and objects that represent some dataflows. There's a problem, though. Many of the classes are about processing data into ad-hoc structures within the property tree. | |||
There is no C++ class for an Altimeter or a Heading Indicator. Instead, these are represented by a set of properties, with a path indicating that the properties underneath a node are for the altimeter or the heading indicator. The actual paths in this case are /instrumentation/altimeter and /instrumentation/heading-indicator. Each node in the tree can have properties as child nodes, as well as child nodes that contain additional properties, such as /instrumentation/heading-indicator/gyro. | |||
Properties are created on the fly, once the property tree's root node is instantiated. Properties are specified in XML data, created by a Nasal script, or by C++ code. The actual property mechanism is implemented in a C++ class. | |||
After they are created, properties are used as needed from Nasal scripts and C++ code, and finally destroyed by a destructor in C++. However, none of that is traceable as a data flow. IDEs are great at connecting elements of code to their definitions and usage, but when we use a data store like the property tree, the connection can't be found by the IDE. These data flows through the property tree mechanisms are a real part of the FlightGear Application, but we have no easy way to visualise them. Any visualization is mentally constructed over time by developers' experiences, as they examine and step through code. | |||
[http://wiki.flightgear.org/User:Callahanp/goals What's up with Pat] | [http://wiki.flightgear.org/User:Callahanp/goals What's up with Pat] | ||