User:Callahanp: Difference between revisions

The problem with FlightGear is its size, complexity, and the lack of a detailed guide to exploring that complexity.  Several factors contribute to that complexity. Understanding FlightGear requires knowledge of many applicaiton domains, C++, an internal  scripting language, a global data store, application features driven by XML or scripts, network protocols and data formats, some custom, some obscure and from the era of mainframe computers.

I'll examine each of these complexity realms with a view to providing a guideline for new FlightGear developers, me for instance, with path to follow leading to regular contributions to the FlightGear C++, Nasal and XML codebases.

  First, the application uses C++.  Second, Flight Simulation involves numerous application domains. Among them are aerodynamics, graphics, geography, geodesy, environment, navigation, networks, audio, video, and human languages. FlightGear addresses all of them and more.  Next, in addition to the complexity introduced by C++ and the application domains, there's Nasal. Finally to tie it all togehter, loosely, the property tree. a global object, with individual data items of a key-value store actually stored in a tree because they are conceptually related.  The property tree introduced compexity because items in it are not "owned", they're simply created at some point, in either C++, XML processing or Nasal and used wherever the data item is "needed".  Connecting the dots through all the code based on identifying individual properties is not all that easy.

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 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. 

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.