Difference between revisions of "User:Callahanp"

From FlightGear wiki
Jump to navigation Jump to search
m
 
(45 intermediate revisions by the same user not shown)
Line 1: Line 1:
I am a flight simulation hobbyist currently working on building instruments, gauges, radios and controls for a C172.
 
 
 
== What I'm doing: ==
 
== What I'm doing: ==
+
While I participate very marginally in flightgear-devel, I'm ramping up my C++11 skills, learning more about git, getting to know a few editors, IDEs, Build and Debugging tools.  I hope to eventually be able 24-7 to build and effectively debug flightgear on any operating system, and to be able to support anyone else wishing to do so.
I'll be working on the interface between Flightgear and low level hardware in a panel or cockpit.  It is my understanding that others, including core Flightgear developers are also working on this and my efforts will  follow, derive from, depend on and I hope contribute in some small way to their work.
 
 
 
Recently I began the effort to fully understand the skills needed to contribute to the Flightgear project's codebase.  I know c++ from a course in the early 90's.  I'm looking at Kdevelop and QTquick as development tools.
 
 
 
=== Flightgear Codebase ===
 
  
My area of interest is in Flightgear's code includes:
+
At the same time, I'm trying to form a coherent view of Flightgear's structure as an application.  Not as a user, but as a developer.  This involves gaining knowledge of the various subsystems that make up flightgear, the underlying technologies each subsystem uses and the flow of control and data  between these subsystems.
  
* telnet
+
The techniques are the same as any other developer faced with a new 'job' with unfamiliar tools, a new programming language, and a new social environment.  Select some tools from among those used by others on the project. Learn the ins and outs of those tools.  Get a look at every menu item, configuration item, dialog or other interface and get a good sense of how that fits with the tasks of a developer. Find a small problem to examine and perhaps solve, get some advice, try different approaches, ask about the approaches used by others.  Learn or deepen your knowledge of the prevailing coding language or languages. Study the way people on the project behave.  Find out what's important, Find out what's not.  Try to understand where the group is headed and how they think they'll get there.
* phi
 
* reset & re-initialize
 
* any method to set or get a property
 
* the property tree itself
 
* configuration files
 
* command line parameters
 
  
I'm beginning to look through various parts of the Flightgear code-base to understand how the parts fit together and how supporting libraries are used in the projectI'd like to learn how aircraft data and graphics are integrated into the working program, and how, why and where Nasal scripting is usedTo this end, I have
+
Technically, dig in to the code to learn how it is built, debugged and run.  Know about all the configuration itemsFind all the big pieces in its hierarchy of objectsSome of them are important to know well. Others it is important to know of their existence. Some you can just be marginally aware of. Any that deal with subsystems, creating visual elements, communication between subsystems or keeping things running correctly from cycle to cycle are importantFine details can wait till later.
  * Built a full debug version of the next branch
 
  * Installed
 
  ** [https://gdbgui.com/ gdbgui]
 
  ** [https://atom.io/ atom] for basic code exploration.
 
  
Later I'll try QtCreator
+
[http://wiki.flightgear.org/User:Callahanp/git-workflow Git Workflow]
  
Here's my directory structure for building
+
[http://wiki.flightgear.org/User:Callahanp/fg-from-scratch  Callahanp - Flightgear From Scratch]
  
*$HOME
+
[http://wiki.flightgear.org/User:Callahanp/Flightgear_Technical_Manual Callahanp - Flightgear Technical Manual]
** A separate disk to make it easy to reinstall linux.  $HOME is the same as /home/$USER
 
*$HOME/fg
 
** Scripts I need to build and flightgear such as download_and_compile.sh, and /run/debug script
 
** This is actually a symlink to a folder on a separate disk from /home. 
 
** I do this so I can build the software I want without continually expanding my home disk's size.
 
** The fg directory contains a folder for each different build of Flightgear.
 
*** next for running next
 
*** nextrti for running next with OpenRTI
 
*** nextd for debugging next
 
*** stable
 
*** stabled
 
** Each of these directories contains clones for flightgear, simgear and other projects like OSG and OpenRTI as needed.
 
  
Rather than use excessive bandwidth, when I need a fresh copy, I just run download_and_compile.sh in a folder that already has a copy of the sources. Then I copy the folder over to the one I want to refresh and remove the build folder within the new one.  Then run the script again to produce the executable version I want. As currently structured, download_and_compile.sh requires a separate set of sources for each different version built.
+
[http://wiki.flightgear.org/User:Callahanp/Flightgear_and_Simgear_Code Flightgear and Simgear Code]
  
Here's the atom/run/debug script I use for debugging
+
[http://wiki.flightgear.org/User:Callahanp/FlightgearWorkingGroups  Callahanp - Flightgear Working Groups]
cd $HOME/fg/
 
  
#!/bin/bash
+
[[https://github.com/c172p-team/c172p C172P Team on Github ]]
# ~/fg/debug
 
  
$cmd = "$HOME/fg/nextd/install/flightgear/bin/fgfs \
+
=== Development Operations ===
  --fg-root=$HOME/fg/nextd/install/flightgear/bin/../fgdata/ \
 
  --log-level=2 \
 
  --fg-scenery=$HOME/fg/nextd/install/flightgear/bin/../fgdata/Scenery \
 
  --fg-aircraft=$HOME/fg/nextd/install/flightgear/bin/../fgdata/Aircraft \
 
  --fg-aircraft=$HOME/.fgfs/Aircraft/org.flightgear.fgaddon/Aircraft \
 
  --httpd=5401 --telnet=5400 --airport=KSFO"
 
  
  $gdbgui "$cmd"
+
I am making an effort to define and give detailed examples of development file and repository operations for various parts of Flightgear Code and Data including all SourceForge Git repositories, Scenery, Aircraft, Aircraft Hangars, Airport Data. Add-Ons and anything else that can be used with Flightgear.  This will include items that fall under the FlightGear SourceForge project, and other projects that do not.
  
When the source window appears, press the "r" key to start debugging.
+
This Page will be organized not around specific kinds of development, but around the development operations common to all of them.  Operations include obtaining source materials, preparatory steps, ongoing operational readiness tasks, building, modifying, debugging, testing, and submitting changes.  I'll explain further and give examples of the individual operations needed to accomplish these tasks for all types of FlightGear material, whether source code or data, regardless of the type of file or where it's upstream repository resides.
  
I start by stepping through bootstrap and other modules until flightgear is up and running.
+
When finished, this guide is intended to be comprehensive up to a point.  If you participate in the development of anything used with or within flightgear, with few exceptions, you'll be able to find information on specific commands and procedures needed to complete the listed operational tasks. We'll leave to other pages, specifics of the internals of working on files of different types, and the kinds of edits and additions that should be made within a file. and focus on the environments that support the actual work to be done and on the resulting files, giving their types, and generally describing contents, without going into details.   
I'm making some notesThere are three sections:
 
  
* '''Path''' will trace the path through modules that provide significant functionality to the Simulator until the aircraft is shown holding short or parked somewhere. only the module's source path and a brief explanation or list of why it's on the "path".
+
The page is currently under rapid development, with attention focused currently on correctly obtaining source materials for C & C++ programming of the main application. Where expansion is needed to cover other types of materials, we'll add a note soliciting your input on what should be said.
* '''Modules''' lists all the classes and methods or functions executed on the "path" as well as those that are not executed in the path.
 
* '''Utility Calls''' will contain notes on various library calls, noting what the call looks like, where the library comes from, what the call does and where else it might be used. These will be functions with a purpose that is not limited to flight simulation.
 
  
====The Path to "Holding Short"====
+
Here are a few examples of the Operations of each type:
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Module
+
! Operation Category !! Examples
! colspan="3" | Description & Steps
+
|-
 +
| Preparatory Steps || <li>installing pre-requisite software libraries needed for building flightgear, simgear and possibly plib or OpenSceneGraph</li>
 +
<li> Collecting information about the exact current location for upstream source code and data </li> <li> Establishing a SourceForge Account</li>
 +
<li> Creating an SSH Key and readying it for use with Sourceforge </li>
 +
<li>Understand where and to what extent each pre-requisite library is used withing flightgear and simgear</li>
 +
<li>Understand all the basic steps needed to build a working flightgear installation using distribution versions of Plib and OpenSceneGraph<li>
 +
<li>Understand the additional steps needed to build a working flightgear installation using locally built  versions of Plib and OpenSceneGraph<li>
 +
<li>Installing and Configuring IDE or Editing Software and extensions for use with CMake and for debugging</li>
 +
<li>Establishing a build script that can be used with multiple branches or commits and which can build Release, RelWithDebInfo and Debug versions of executables</li>
 +
<li> Ensuring that Ongoing Operational Readiness Tasks are well documented, understood and used as appropriate</li>
 +
|-
 +
| Obtaining Source Materials || <li>Cloning Flightgear Git Repositories Locally </li> <li>Creating Personal Forks of Flightgear Repositories and cloning them locally </li>
 +
|-
 +
| Ongoing Operational Readiness Tasks || <li>Ensuring that when switching branches, that changes on the previously current branch are not lost</li> <li>Ensuring that local clones used in a build are on the correct branch for the desired build</li> <li>Establishing working branches for specific enhancements</li> <li>Ensuring that sufficient testing has been performed before pushing changes upstream</li>
 
|-
 
|-
| src/Main/bootstrap Main
+
| Building || Executing a script containing a series of CMake commands to build specific parts of flightgear </li><li>Executing a script or program that processes data in raw form to produce a different form of data directly usable by FlightGear (OSM data for example) </li>
| Bootstrap provides the top level of the stack for executing either fgviewerMain or fgMainInit.
 
* Enable Floating Point features with InitFPE
 
* Set locale settings specific to using C or C++
 
* Uninstall if requested
 
|
 
* Initialize logging
 
* Initialize some static objects in OSG to prevent crashes on exit
 
* set the std:: terminate function
 
|
 
* set the atexit function
 
* pass control to the viewer with fgViewerMain or initialize using '''fgMainInit'''
 
* catch throwables and other fatal error conditions, providing appropriate error messages
 
 
|-
 
|-
| src/Main/Main || fgMainInit( int argc, char **argv )
+
| Modifying || <li>Using an Editor or IDE to modify or add C++ Code </li><li> Using Blender, GIMP, or other graphical editing tool to do something for an aircraft </li><li>Adding a building to scenery</li>
* set logging level and enable logging
 
* setup globals as an instance of FGGlobals.  
 
** see  src/Main/globals.cxx constructor FGGlobals::FGGlobals()
 
* make sure there's a valid FG_HOME directory and set up logging there
 
* set the version & log the version, build type and Jenkins or Hudson build id
 
* seed the random number generator
 
* set up a few things in globals
 
* decide if we're using a launcher
 
** see below src/Main/Main.cxx Launcher for details
 
* set read-only mode when more than one flightgear instance is found
 
* load configuration data
 
** see src/Main/Main.cxx'''fgInitConfig'''
 
* initalize aircraft paths
 
** see: src/Main/fg_init.cxx fgInitAircraftPaths and fgInitAircraft
 
|
 
* create an instance of the addon manager
 
** see below src/Add-ons/AddonManager.cxx
 
* check that the paths are allowed when they come from an untrusted source
 
* create an instance of an embedded resource manager
 
** see below simgear::EmbeddedResourceManager createInstance
 
** and initFlightGearEmbeddedResources
 
* get the preferred language and set the locale
 
* initialize the windows/graphics environment
 
** see viewer/fg_os_osgviewer.cxx fgosinit(int* argc, char** argv)
 
* register fgIdleFunction
 
** see fgRegisterIdleHandler in Main/fg_os_common.cxx and fgIdleFUnction in Main/main.cxx
 
* Initialize sockets
 
** simgear::Socket::initSockets()
 
* setup alpha channel for Clouds3D
 
** fgOSOpenWindow(true /* request stencil buffer */);
 
** fgOSResetProperties();
 
|
 
* fntInit();
 
* globals->get_renderer()->preinit();
 
* ATIScreenSizeHack
 
* fgOutputSettings();
 
* disable the screensaver
 
* pass control off to the master event handler
 
** See viewer/fg_os_osgviewer.cxx fgOSMainLoop() (next)
 
* cleanup
 
** frame_signal.clear();
 
** fgOSCloseWindow();
 
** simgear::clearEffectCache();
 
** delete globals;
 
** globals = NULL;
 
* delete the NavCache here. This will cause the destruction of many cached objects (eg, airports, navaids, runways).
 
** delete flightgear::NavDataCache::instance();
 
* return to bootstrap.cxx Main  return result;
 
 
|-
 
|-
| viewer/fg_os_osgviewer.cxx || fgOSMainLoop()
+
| Debugging || <li>Using the GDB debugger in command line mode </li><li>Using the GDB debugger in an IDE</li><li>Observing position and details of an aircraft, building or other object from multiple points of view in the Flightgear Application </li>
* Release the viewer's context at end of frame hint
 
** viewer->setReleaseContextAtEndOfFrameHint(false)
 
* If the viewer is not realized yet, realize it. We still see nothing in the window
 
** viewer->realize()
 
|colspan="2"| here's the loop:
 
* get the idle handler
 
** fgIdleHandler idleFunc = globals->get_renderer()->getEventHandler()->getIdleHandler();
 
* run the idle handler  It's not clear what this is. It's either fgMainLoop or fgIdleFunction
 
** (*idleFunc)()
 
* update the screen
 
** globals->get_renderer()->update();
 
* timestamp the frame
 
** viewer->frame( globals->get_sim_time_sec() );
 
 
|-
 
|-
| Main/main.cxx || fgIdleFunc
+
| Automated Testing || <li> Writing, Executing or Debugging CPPUnit tests</li>
* normal startup has states 0, 2, 3, 4, 5, 7, 8, 9, 10, 900 1000
 
* reset startup has 2000, 2005, 2007, 8, 9, 10, 900, 1000
 
* state 1000 sets  fgMainLoop as the idle function. a reset sets it back to fgIdleFunc
 
 
 
* state 0 checks the openGL version and sets video options
 
** see checkOpenGLVersion() and  fgSetVideoOptions()
 
 
 
* state 2 sets /sim/rendering/initialized true and initializes terrasync with initTerrasync()
 
 
 
* state 3 loads nav data
 
** fgInitNav()
 
 
 
* state 4 initalizes scenery, but there's not call here
 
 
 
* state 5
 
** initializes some general items with fgInitGeneral()
 
** adds the TimeManager
 
*** globals->add_new_subsystem<TimeManager>(SGSubsystemMgr::INIT)
 
** initializes property based commands
 
*** fgInitCommands(); and fgInitSceneCommands();
 
** registers Subsystem Commands
 
*** flightgear::registerSubsystemCommands(globals->get_commands());
 
** initializes the material manager
 
*** globals->set_matlib( new SGMaterialLib )
 
*** simgear::SGModelLib::setPanelFunc(FGPanelNode::load)
 
|
 
* state 7
 
** Initializes Position
 
*** flightgear::initPosition(); and flightgear::initTowerLocationListener();
 
** Initializes somethingin SGModelLib
 
*** simgear::SGModelLib::init(globals->get_fg_root().local8BitStr(), globals->get_props());
 
** initializes the time manager instantiated in state 5
 
***auto timeManager = globals->get_subsystem<TimeManager>(); timeManager->init();
 
* state 8
 
* Create subsystems
 
** fgCreateSubsystems(isReset)
 
* log the time spent creating subsystems
 
* state 9
 
** bind subsystems
 
** globals->get_subsystem_mgr()->bind();
 
***
 
* state 10
 
** initialize subsystems
 
*** SGSubsystem::InitStatus status = globals->get_subsystem_mgr()->incrementalInit();
 
** remains in state 10 until  SGSubsystem::INIT_DONE
 
* state 900
 
** do what needs doing after systems are initialized
 
*** fgPostInitSubsystems(); 
 
|
 
* state 1000
 
** setup OpenGl view Parameters
 
*** globals->get_renderer()->setupView();
 
** resize the window to startup size
 
***  globals->get_renderer()->resize(x,y)
 
** unsure what this does
 
*** WindowSystemAdapter::getWSA()->windows[0]->gc->add(new simgear::canvas::VGInitOperation() )
 
* increment /sim/session
 
* State 1000 takes a break and continues with the next call
 
** sglog().setStartupLoggingEnabled(false)
 
* turns off logging for startup
 
* sets sim/scenery loaded to false
 
* changes the idle function
 
** registerMainLoop();
 
* state 2000
 
** Reset the application
 
*** fgStartNewReset();
 
* state 2005 same as state 5
 
* state 2007 same as state 7
 
 
 
Note fgResetIdleState() sets the state to 2000 and re-registers fgIdleFunction as the idle handler.
 
 
|-
 
|-
| Main/main.cxx || fgMainLoop( void )| We seem to have arrived.  We're at the hold short point.
+
| Submitting changes || <li>Doing a git push to a personal fork for a branch created for a specific set of changes </li>Creating a merge request for changes present on a personal fork.<li></li>
 +
|}
  
|}
+
=== Development Operation Targets ===
'''Minor functions on the Path to Holding Short'''
+
Each of the operation categories listed above applies to a number of separate parts of the Flightgear Puzzle.  A few of these parts together make up the basic application and are treated together.  Others can be treated as if they were optional add-ons to the development process, even if the item itself is vital to the operation of the basic application.
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Module !! Description !! Steps
+
! Target Executable !! Description !! Source Materials
 
|-
 
|-
| src/Main/globals || Provides a global object to contain references to objects and data needed in initializing, running and terminating flightgear
+
| FlightGear  || This executable is the simulator.  It can be built in several ways, Release, RelWithDebInfo and Debug possibly including optional features such as Compositor and OpenRTI. || Three Sourceforge FlightGear Git Repositories:
|
+
* [https://sourceforge.net/p/flightgear/fgdata/ fgdata]
* Provides global access to
+
* [https://sourceforge.net/p/flightgear/simgear/ simgear]
** the property tree
+
* [https://sourceforge.net/p/flightgear/flightgear/ flightgear]
** subsystem, event, command and resource manager objects and methods
 
** position, current view and aircraft orientation data
 
** FG_ROOT and FG_HOME directory paths
 
** time, comm channel, waypoint, and user settings data
 
* uses foreach from the boost library
 
 
|-
 
|-
| <boost/foreach.h> || Example ||  
+
| FlightGear CPPUnit Tests  || This executable is build separately and can be executed to run all of the CPPUnit based tests at once || Two Sourceforge FlightGear Git Repositories.  They're the same as are used for the main executable above.
 +
* [https://sourceforge.net/p/flightgear/fgdata/ fgdata]
 +
* [https://sourceforge.net/p/flightgear/simgear/ simgear]
 
|-
 
|-
| <algorithm> || Example || Example
+
| Resource Compiler
 
|-
 
|-
| std::string version(FLIGHTGEAR_VERSION) || ||
+
| Utilities ||There are several utility programs that are part of the flightgear build process ||
 +
* flightgear/FDM/JSBSim JSBsim_bin
 +
* flightgear/FDM/YASim yasim
 +
* flightgear/FDM/YASim yasim-proptest
 +
* flightgear/Input fgjs
 +
* flightgear/Input js_demo
 +
* flightgear/main metar
 +
* flightgear/utils/fgcom fgcom
 +
* flightgear/utils/fgelev fgelev
 +
* flightgear/utils/fgpanel fgpanel
 +
* flightgear/utils/fgtraffic fgtraffic
 +
* flightgear/utils/fgviewer fgviewer
 +
* flightgear/utils/GPSSmooth GPSSmooth MIDGsmooth & UGsmooth
 +
 
 
|-
 
|-
| sg_srandom_time(); || ||
+
| Build Systems || There are several ways to build executable programs including but not limited building within an IDE, fg_from_scratch, download_and_compile.sh, Jenkins servers and custom build scripts ||  
 +
* [https://sourceforge.net/p/flightgear/pipeline/ SourceForge Flightgear git pipeline] A Jenkins Build Script
 +
* [https://sourceforge.net/p/flightgear/fgmeta/ SourceForge Flightgear git fgmeta]
 +
* [https://sourceforge.net/p/flightgear/windows-3rd-party/ SourceForge Flightgear git windows-3rd-party] This special purpose repository is used when building flightgear on Windows by users who prefer to use pre-built pre-requisite packages.
 
|-
 
|-
| src/Main/Main.cxx'''fgInitConfig''' || ||
+
| OpenRadar || Example ||  
 +
* [https://sourceforge.net/p/flightgear/openradar/ SourceForge Flightgear git openradar]
 
|-
 
|-
| src/Main/Main.cxx Launcher || ||
+
| Flight Gear's Flight Manual || It's called Get Start || * [https://sourceforge.net/p/flightgear/getstart/ getstart]
 
|-
 
|-
| src/Add-ons/AddonManager.cxx  ||  addons::AddonManager::createInstance() ||
+
| Scenery || Example ||
 +
* [https://sourceforge.net/p/flightgear/terragear/ SourceForge Flightgear git terragear]
 +
* [https://sourceforge.net/p/flightgear/terrafs/ SourceForge Flightgear git terrafs]
 
|-
 
|-
| initFlightGearEmbeddedResources || || see  file build/flightgear/src/EmbeddedResources/FlightGear-resources.cxx,automatically generated by fgrcc
+
| Multiplayer Map || Example ||  
 +
* [https://sourceforge.net/p/flightgear/mpmap.js/ SourceForge Flightgear git mpmap]
 
|-
 
|-
| viewer/fg_os_osgviewer.cxx fgosinit(int* argc, char** argv) || ||
+
| Navigation Data || Example || Example
 +
* [https://sourceforge.net/p/flightgear/navdata/ SourceForge Flightgear git navdata]
 
|-
 
|-
| Main/fg_os_common.cxx  || fgRegisterIdleHandler( & fgIdleFunction ||
+
| Airport Data || Example || Example
 +
*
 
|-
 
|-
| detectSIMD() || bootstrap.cxx || returns true if the cpu supports sse2.
+
| Mac Launcher || Example ||  
|-
+
* [https://sourceforge.net/p/flightgear/maclauncher/ SourceForge Flightgear git maclauncher]
| gethostname(_hostname, 256) || unistd.h glibc || returns the hostname of your computer
+
 
|-
 
| signal(SIGPIPE, SIG_IGN) || signal.h || directs SIGPIPE to the SIG_IGN signal handler - Portability: use sigaction() instead
 
|-
 
|  signal(SIGSEGV, segfault_handler) || signal.h  || Flightgear formats the message with a backtrace and exits with std:abort()
 
|-
 
|  segfault_handler (int signo) || bootstrap.cxx  ||
 
|-
 
|  '''initFPE'''(flightgear::Options::checkForArg(argc, argv, "enable-fpe")) || main/options.cxx<br>  bootstrap.cxx || checks the command line arguments for the enable-fpe option. Calls InitFPE with the result. <br> see bootstrap.cxx for more details
 
|-
 
|  signal(SIGFPE, handleFPE) || signal.h<br/> bootstrap.cxx || We handle Floating Point Exceptions
 
|-
 
| setlocale(LC_ALL, "") <br/> setlocale(LC_NUMERIC, "C") <br/> setlocale(LC_COLLATE, "C") ||  ||
 
|-
 
| return fgUninstall() || fg_init.cxx || Command line options are checked to determine if uninstall should be called.
 
|-
 
| sglog() || /simgear/debug/logstream.cxx || This initializes the log. see logstream.cxx for details
 
 
|-
 
|-
| std::set_terminate(fg_terminate); || <exception> <br> bootstrap.cxx || sets the standard template library terminate routine<br>
+
| Open Street Maps (OSM) || Example || Example
 
|-
 
|-
| atexit(fgExitCleanup) || stdlib.h<br> bootstrap.cxx || registers the given function to be called at normal process termination, either via exit(3) or via return from the program's main().  Functions so registered are called in the reverse order of their registration; no arguments are passed
+
| Open Scene Graph (OSG)|| Example || Example
 
|-
 
|-
| fgviewerMain(argc, argv) || flightgear/Viewer/fgviewer.cxx  || see viewer topics for details.  This is called in bootstrap.cxx if the command line arguments include --viewer
+
| Open Scene Graph - Earth (OSG-Earth)|| Example || Example
 
|-
 
|-
| '''fgMainInit(argc, argv)''' || '''Main/main.cxx''' || Starts to initialize flightgear. This is called in bootstrap.cxx if command line arguments do ''not'' contain --viewer
+
| C172P Skyhawk || The C172P-Team produces the C172P used in Flightgear as the default Aircraft. A copy of the Aircraft's files is included by the Flightgear project in the SourceForge FlightGear FGData repository||See [https://github.com/c172p-team/c172p C172P-team Github Repository]
 
|-
 
|-
| catch block || various || termination for most or all errors. Read the end of bootstrap.cxx for more information
+
| Add-On 1 || Example || Example
 
|-
 
|-
| flightgear::shutdownQtApp() || bootstrap<br/> Qt || Done separately from atexit. see bootstrap.cxx for more information
+
| Add-On 2 || Example || Example
 
|-
 
|-
| crInstall(&info)<br>crUninstall() || [http://crashrpt.sourceforge.net CrashRpt.h] || #if defined(HAVE_CRASHRPT). This only happens on windows.
+
| Add-On 3 || Example || Example
 
|-
 
|-
sglog().setLogLevels( SG_ALL, SG_INFO )<br>sglog().setStartupLoggingEnabled(true); || /simgear/debug/logstream.cxx || Pretty obvious what this does. || '''What does sglog() actually return?'''
+
| Plib || Example || Example
 
|}
 
|}
  
=== Progress on Cockpit Building ===
+
==== Obtaining Source Materials ====
 +
 
 +
FlightGear related Source Materials may be hosted in a number of different services.  Depending on the exact material, you may be working with files from the FlightGear Project on SourceForge, other SourceForge projects, projects from GitHub, GitLab or other SCM repository service.  You may be dealing with data that originates in other Simulation Projects, or with code from supporting libraries such as Open Scene Graph.
 +
 
 +
Quite a lot of the source materials for the flightgear application are maintained as repositories on SourceForge.  [https://sourceforge.net/p/flightgear/_list/git Complete FlightGear SourceForge Repository List].  Two of these Repositories are no longer used: FGCom and FGRun.  These repositories are obsolete because their functional parts have been included within FlightGear.
 +
 
 +
The rest are documented in the section above.
 +
 
 +
==== Part 1 - Creating a Sourceforge Fork ====
 +
 
 +
===== Part 1A - Create a Sourceforge Account, SSH Key and Verify that it works =====
 +
** Requires one personal sourceforge account
 +
** Requires an ssh login be setup
 +
*** Create an SSH Key for use with Sourceforge
 +
*** Update Sourceforge SSH Keys
 +
*** Login to the shell with your key to make sure things are working right.
 +
*** Logout from the shell - You won't be working there.
 +
*** Login to Sourceforge on the web.  You will be working with the web interface to sourceforge to create Forks.
 +
 
 +
===== Part 1B - Create Sourceforge Forks for each Flightgear git repository you need to work in =====
  
As of Feb 1, 2018:
+
If you are not going to make changes to a particular repository, but only wish to do builds tracking next, you only need a clone of the official Flightgear on your local machine.  You don't need to bother with creating a SourceForge Fork.  You can have a mixture of local gits, some with multiple remote connections origin, upstream and possibly others, others only connected once to flightgear as origin.
  
* I've done only a few prototype circuits
+
In order not to strain SourceForge resources, it's a good Idea to get rid of any forks that are not used for a while, certainly any that are not used at all for changes and experimental branches.  This is especially true of resources that are large. 
* have been working to develop skills I'll need to produce a realistic cockpit. 
 
* Developing skills in Fusion 360 to support 3d Printing and 3d machine tools.
 
* Working on tests for a cluster based on Raspberry Pi Zeros
 
* Beginning to use a 3d Router
 
* Milling into thin prisms and hand polishing disks of plexiglass for illuminating dials in Sim Instruments
 
  
As part of my Cockpit Building efforts, I'm also working on
+
Note that if you later decide to contribute to a new area, or to resume contributing, you will be able to create a fork and attach it to the local clone you previously created using the steps below.
* [[User:Callahanp/Two Way Communication between a Raspberry Pi and Arduinos]]  
+
 
* [https://github.com/callahanp/raspberrypi-zero-usb-ssh-internet/wiki  Connecting to a Raspberry Pi Zero via USB Ethernet Including the use of SSH and connection of the zero to the internet ]
+
* Open https://sourceforge.net/projects/flightgear/
* [https://www.raspberrypi.org/forums/viewtopic.php?f=49&t=199994 Creating a cluster with Raspberry Pi Zeros ]
+
* Log in to your sourceforge account by clicking the login button if you're logged out.
* [[User:Callahanp/Snippets |Snippets]] of text that may or may not be used somewhere
+
* Hover over Me and select Profile with a right click and select open link in new window.
 +
 
 +
If you don't see Git under personal tools in your profile page, it's because you've not set up any SourceForge Forks yet.
 +
 
 +
Creating a Sourceforge fork is easy, Just go to the FlightGear Repo you wish to fork and click the fork button on the Left.  It takes a few minutes and is pretty easy to figure out.  You'll get to see the clone statement for the repo after refreshing the page after the fork is created.
 +
 
 +
 
 +
===== Part 2 -  Create a local clone for each Sourceforge Fork  =====
 +
 
 +
If you already have clones of Flightgear git repos from Sourceforge, there's no need to re-do them as clones of your SourceForge Forks, they can easily be converted using the same steps you would use on a fresh clone of a personal fork.
 +
 
 +
** create origin remote
 +
** create upstream remote
 +
** set upstream fetch to main flightgear repositories
 +
** create a branch for working on changes
 +
** checkout next
 +
** checkout a change branch
 +
** stash changes on a branch
 +
** push a change branch to your SourceForge fork
 +
** pull changes from next
 +
** got fetch
 +
 
 +
==== Tools ====
 +
 
 +
[[User:Callahanp/Flightgear_and_Simgear_Code/Tools_for_a_Flightgear_Developer|Tools for a Flightgear Developer]] (see also [[Tools of the Trade]])
 +
 
 +
==== From Command Line to Holding Short ====
 +
 
 +
[[User:Callahanp/Flightgear_and_Simgear_Code/From_Command_Line_to_Holding_Short|From Command Line to Holding Short]]. A look at what gets called when you start Flightgear from the command line until you are on the runway.  This is a work in progress, somewhat stalled after Eduard Auvergne's initial work on subsystems.  It needs a re-vamp to make it current and publishable.
 +
 
 +
===== RTFM =====
 +
* http://wiki.flightgear.org/FlightGear_Manual
 +
* fgdata/doc/img Look at each image in, noting the name of the image and what the image is trying to say
 +
* fgdata/doc/keyboard/map.pdf  Note that key bindings can be specific to an aircraft. Note that the pdf was produced from a .tex file.
 +
* fgdata/Docs/model-combined.eff/README.model-combined.eff  Read and not What's "rembrandt" - Key terms can be pulled from this document
 +
* fgdata/Serial/nmeafaq.txt  Garmin -    Key terms can be pulled from this document. This document describes a data protocol
 +
* AI_doc.html 
 +
* FGShortRef.html
 +
* http://flightgear.org/Docs/FlightGear-FAQ.html
 +
* fgdata/Docs/fschool_0.0.3.pdf
 +
* fgdata/Docs/index.html
 +
* fgdata/Docs/model-howto.html
 +
* and lots of others  - point is you have to read them all
 +
 
 +
Once they're read, is there a way to organize them so the result is an overview?
 +
 
 +
Sure there is. Just write a book:
  
===== Contact =====
+
=== IDEs ===
  
Maybe our projects overlap and maybe I can be of help you in some small way.  I love bouncing ideas back and forth in personal or public e-mails.  Feel free to contact me about your non-commercial simulation projects. <br> '''[[Special:EmailUser/Callahanp | Email Callahanp through the wiki]]'''
+
Working on Configurations for Visual Studio, Visual Studio Code, Atom, Eclipse and QTCreator IDEs and other tools for working with FlightGear Data.
  
I show up occasionally on #flightgear on irc.flightgear.org and am a member of several public forums related to cockpit building.
+
The day to day work of a FlightGear Developer will include the use of a variety of software to work on various kinds of FlightGear material.
 +
The material includes Source Code written in C and C++, Scripts written in Nasal, Build procedures using CMake and in scripting languages of 3 operating Systems, Data Files representing Airports, Runways, Taxiways, Airport Markings, Navigation Beacons, Instrument Landing System Transmitters, Taxiway and Runway Lighting, Buildings, Roadways,
  
[[User:Callahanp|Callahanp]] ([[User talk:Callahanp|talk]]) 09:45, 11 November 2017 (EST)
+
The workflow for all of these has a few basic steps.
  
=== My Skills ===
+
* Get copies of the original source material
* Programming in whatever language is available
+
* Establish a fork repository for your changes to the materials
* Databases
+
* Make a local copy of the materials
* Making the following list of chips do what they do:
+
* Change the materials
* MCP23XXX Multiplexer
+
* Check the Validity of Changes
* MAX7219 Serially Interfaced, 8-Digit LED Display Driver
+
* Deliver changed materials to your fork
* Designing a few types of circuits that work on a breadboard (see electronics below)
+
* Request that the changes be accepted and merged with the original source materials.
  
===== My Developing Skills -- Beginner =====
+
The workflows differ based on the true owners of the originating material and the materials format.
* Grokking Flightgear's code base.
 
* Very basic machining on a lathe or mill - no significant experience
 
* Electronics - Basics - DC, High & Low speed digital circuits, motor control, emi suppression and mitigation
 
* Soldering - Learn to deal with small components
 
* Designing circuits that make it from breadboard to cockpit.
 
* Getting a cokpit project off the ground
 
  
* C++ - Updating coding skills from an early version of C++
+
These are the basic tasks that a developer will need to complete
  
* Avoiding Writing Howtos
+
* Setting up forks of FlightGear Git Archives
 +
* Identifying non-git Open Source Resources for use with Flightgear and establishing forks for them
 +
* Downloading appropriate tools for working on the kind of files that make up the FlightGear application and it's data
 +
* Configuring these tools and FlightGear itself to operate in one or more modes
 +
* Learning the steps to use inside and outside the tools
  
===== My Developing Skills -- Making Good Progress =====
 
  
* Fusion 360 3dCad
+
=== Figuring out how to contribute to FlightGear ===
* 3d Router
 
  
=== The Howtos -- Oh yeah... those...===
+
[[Getting things done in Flightgear]]
I'm working on these along side building my cockpit.  Some of the early attempts were not that useful.  My current approach is to build and document actual hardware.  I hope this will be more helpful.
 
  
Current Projects:
 
* [[Howto:C172P Panel Project]]
 
* [[Howto:Build your own Panel or Cockpit]]
 
  
See below for the my personal rules about these howtos going forwardI had to write these because it was becoming a morass and time waster.
+
As part of my Cockpit Building efforts, I'm also working on
 +
* [[User:Callahanp/Two Way Communication between a Raspberry Pi and Arduinos]]
 +
* [https://github.com/callahanp/raspberrypi-zero-usb-ssh-internet/wiki Connecting to a Raspberry Pi Zero via USB Ethernet Including the use of SSH and connection of the zero to the internet ]
 +
* [https://www.raspberrypi.org/forums/viewtopic.php?f=49&t=199994 Creating a cluster with Raspberry Pi Zeros ]
 +
* [[User:Callahanp/Snippets |Snippets]] of text that may or may not be used somewhere
  
'''The following is yet another work in progress'''
+
=== Contact ===
  
  Writing Advice to Callahanp from Callahanp or How to write a Howto.
+
  '''[[Special:EmailUser/Callahanp | Email Callahanp through the wiki]]'''
  
Rule 1. Brevity.
+
I show up occasionally on discord, #flightgear on irc.flightgear.org and am a member of several public forums related to cockpit building.
  
Rule 2. Real Hardware.  If I haven't done it yet I'll talk about it on my personal wiki page.  That's where stuff like that belongs. 
+
[[User:Callahanp|Callahanp]] ([[User talk:Callahanp|talk]]) 09:45, 11 November 2017 (EST)
  
Rule 3. Project Planning, Building Teams, and anything else about developing a hobby project belong elsewhere.  If you want to write about these things, go ahead, but don't do it in a Howto on building something specific like a cockpit.  If you haven't done the project yet you'll get it wrong. Plus, you'll sound like a...
+
=== The Howtos ===
  
Rule 4. Grand visions, Vaporware, Abstract thinking, Advice and other nonsense  don't belong anywhere. 
+
'''-- Oh yeah... those...'''
  
Rule 5. Get rid of your darlings.  Those witty turns of phrase, that elegant prose, the puns, jokes and asidesFun to write maybe but not so fun to readThey're distractions. These are things a skillful writer can weave into an uninterrupted smooth train of thought but you're not that good a writer. Don't even try,
+
I'm working on these along side building my cockpit.   Some of the early attempts were not that usefulMy current approach is to build and document actual hardwareI hope this will be more helpful.
  
'nuff said.
+
Current Projects:
 +
* [[Howto:C172P Panel Project]]
 +
* [[Howto:Build your own Panel or Cockpit]]

Latest revision as of 04:26, 15 October 2020

What I'm doing:

While I participate very marginally in flightgear-devel, I'm ramping up my C++11 skills, learning more about git, getting to know a few editors, IDEs, Build and Debugging tools.  I hope to eventually be able 24-7 to build and effectively debug flightgear on any operating system, and to be able to support anyone else wishing to do so.

At the same time, I'm trying to form a coherent view of Flightgear's structure as an application.  Not as a user, but as a developer.  This involves gaining knowledge of the various subsystems that make up flightgear, the underlying technologies each subsystem uses and the flow of control and data  between these subsystems.

The techniques are the same as any other developer faced with a new 'job' with unfamiliar tools, a new programming language, and a new social environment. Select some tools from among those used by others on the project. Learn the ins and outs of those tools. Get a look at every menu item, configuration item, dialog or other interface and get a good sense of how that fits with the tasks of a developer. Find a small problem to examine and perhaps solve, get some advice, try different approaches, ask about the approaches used by others. Learn or deepen your knowledge of the prevailing coding language or languages. Study the way people on the project behave. Find out what's important, Find out what's not. Try to understand where the group is headed and how they think they'll get there.

Technically, dig in to the code to learn how it is built, debugged and run. Know about all the configuration items. Find all the big pieces in its hierarchy of objects. Some of them are important to know well. Others it is important to know of their existence. Some you can just be marginally aware of. Any that deal with subsystems, creating visual elements, communication between subsystems or keeping things running correctly from cycle to cycle are important. Fine details can wait till later.

Git Workflow

Callahanp - Flightgear From Scratch

Callahanp - Flightgear Technical Manual

Flightgear and Simgear Code

Callahanp - Flightgear Working Groups

[C172P Team on Github ]

Development Operations

I am making an effort to define and give detailed examples of development file and repository operations for various parts of Flightgear Code and Data including all SourceForge Git repositories, Scenery, Aircraft, Aircraft Hangars, Airport Data. Add-Ons and anything else that can be used with Flightgear. This will include items that fall under the FlightGear SourceForge project, and other projects that do not.

This Page will be organized not around specific kinds of development, but around the development operations common to all of them. Operations include obtaining source materials, preparatory steps, ongoing operational readiness tasks, building, modifying, debugging, testing, and submitting changes. I'll explain further and give examples of the individual operations needed to accomplish these tasks for all types of FlightGear material, whether source code or data, regardless of the type of file or where it's upstream repository resides.

When finished, this guide is intended to be comprehensive up to a point. If you participate in the development of anything used with or within flightgear, with few exceptions, you'll be able to find information on specific commands and procedures needed to complete the listed operational tasks. We'll leave to other pages, specifics of the internals of working on files of different types, and the kinds of edits and additions that should be made within a file. and focus on the environments that support the actual work to be done and on the resulting files, giving their types, and generally describing contents, without going into details.

The page is currently under rapid development, with attention focused currently on correctly obtaining source materials for C & C++ programming of the main application. Where expansion is needed to cover other types of materials, we'll add a note soliciting your input on what should be said.

Here are a few examples of the Operations of each type:

Operation Category Examples
Preparatory Steps
  • installing pre-requisite software libraries needed for building flightgear, simgear and possibly plib or OpenSceneGraph
  • Collecting information about the exact current location for upstream source code and data
  • Establishing a SourceForge Account
  • Creating an SSH Key and readying it for use with Sourceforge
  • Understand where and to what extent each pre-requisite library is used withing flightgear and simgear
  • Understand all the basic steps needed to build a working flightgear installation using distribution versions of Plib and OpenSceneGraph
  • Understand the additional steps needed to build a working flightgear installation using locally built versions of Plib and OpenSceneGraph
  • Installing and Configuring IDE or Editing Software and extensions for use with CMake and for debugging
  • Establishing a build script that can be used with multiple branches or commits and which can build Release, RelWithDebInfo and Debug versions of executables
  • Ensuring that Ongoing Operational Readiness Tasks are well documented, understood and used as appropriate
  • Obtaining Source Materials
  • Cloning Flightgear Git Repositories Locally
  • Creating Personal Forks of Flightgear Repositories and cloning them locally
  • Ongoing Operational Readiness Tasks
  • Ensuring that when switching branches, that changes on the previously current branch are not lost
  • Ensuring that local clones used in a build are on the correct branch for the desired build
  • Establishing working branches for specific enhancements
  • Ensuring that sufficient testing has been performed before pushing changes upstream
  • Building Executing a script containing a series of CMake commands to build specific parts of flightgear
  • Executing a script or program that processes data in raw form to produce a different form of data directly usable by FlightGear (OSM data for example)
  • Modifying
  • Using an Editor or IDE to modify or add C++ Code
  • Using Blender, GIMP, or other graphical editing tool to do something for an aircraft
  • Adding a building to scenery
  • Debugging
  • Using the GDB debugger in command line mode
  • Using the GDB debugger in an IDE
  • Observing position and details of an aircraft, building or other object from multiple points of view in the Flightgear Application
  • Automated Testing
  • Writing, Executing or Debugging CPPUnit tests
  • Submitting changes
  • Doing a git push to a personal fork for a branch created for a specific set of changes
  • Creating a merge request for changes present on a personal fork.
  • Development Operation Targets

    Each of the operation categories listed above applies to a number of separate parts of the Flightgear Puzzle. A few of these parts together make up the basic application and are treated together. Others can be treated as if they were optional add-ons to the development process, even if the item itself is vital to the operation of the basic application.

    Target Executable Description Source Materials
    FlightGear This executable is the simulator. It can be built in several ways, Release, RelWithDebInfo and Debug possibly including optional features such as Compositor and OpenRTI. Three Sourceforge FlightGear Git Repositories:
    FlightGear CPPUnit Tests This executable is build separately and can be executed to run all of the CPPUnit based tests at once Two Sourceforge FlightGear Git Repositories. They're the same as are used for the main executable above.
    Resource Compiler
    Utilities There are several utility programs that are part of the flightgear build process
    • flightgear/FDM/JSBSim JSBsim_bin
    • flightgear/FDM/YASim yasim
    • flightgear/FDM/YASim yasim-proptest
    • flightgear/Input fgjs
    • flightgear/Input js_demo
    • flightgear/main metar
    • flightgear/utils/fgcom fgcom
    • flightgear/utils/fgelev fgelev
    • flightgear/utils/fgpanel fgpanel
    • flightgear/utils/fgtraffic fgtraffic
    • flightgear/utils/fgviewer fgviewer
    • flightgear/utils/GPSSmooth GPSSmooth MIDGsmooth & UGsmooth
    Build Systems There are several ways to build executable programs including but not limited building within an IDE, fg_from_scratch, download_and_compile.sh, Jenkins servers and custom build scripts
    OpenRadar Example
    Flight Gear's Flight Manual It's called Get Start * getstart
    Scenery Example
    Multiplayer Map Example
    Navigation Data Example Example
    Airport Data Example Example
    Mac Launcher Example
    Open Street Maps (OSM) Example Example
    Open Scene Graph (OSG) Example Example
    Open Scene Graph - Earth (OSG-Earth) Example Example
    C172P Skyhawk The C172P-Team produces the C172P used in Flightgear as the default Aircraft. A copy of the Aircraft's files is included by the Flightgear project in the SourceForge FlightGear FGData repository See C172P-team Github Repository
    Add-On 1 Example Example
    Add-On 2 Example Example
    Add-On 3 Example Example
    Plib Example Example

    Obtaining Source Materials

    FlightGear related Source Materials may be hosted in a number of different services. Depending on the exact material, you may be working with files from the FlightGear Project on SourceForge, other SourceForge projects, projects from GitHub, GitLab or other SCM repository service. You may be dealing with data that originates in other Simulation Projects, or with code from supporting libraries such as Open Scene Graph.

    Quite a lot of the source materials for the flightgear application are maintained as repositories on SourceForge. Complete FlightGear SourceForge Repository List. Two of these Repositories are no longer used: FGCom and FGRun. These repositories are obsolete because their functional parts have been included within FlightGear.

    The rest are documented in the section above.

    Part 1 - Creating a Sourceforge Fork

    Part 1A - Create a Sourceforge Account, SSH Key and Verify that it works
      • Requires one personal sourceforge account
      • Requires an ssh login be setup
        • Create an SSH Key for use with Sourceforge
        • Update Sourceforge SSH Keys
        • Login to the shell with your key to make sure things are working right.
        • Logout from the shell - You won't be working there.
        • Login to Sourceforge on the web. You will be working with the web interface to sourceforge to create Forks.
    Part 1B - Create Sourceforge Forks for each Flightgear git repository you need to work in

    If you are not going to make changes to a particular repository, but only wish to do builds tracking next, you only need a clone of the official Flightgear on your local machine. You don't need to bother with creating a SourceForge Fork. You can have a mixture of local gits, some with multiple remote connections origin, upstream and possibly others, others only connected once to flightgear as origin.

    In order not to strain SourceForge resources, it's a good Idea to get rid of any forks that are not used for a while, certainly any that are not used at all for changes and experimental branches. This is especially true of resources that are large.

    Note that if you later decide to contribute to a new area, or to resume contributing, you will be able to create a fork and attach it to the local clone you previously created using the steps below.

    • Open https://sourceforge.net/projects/flightgear/
    • Log in to your sourceforge account by clicking the login button if you're logged out.
    • Hover over Me and select Profile with a right click and select open link in new window.

    If you don't see Git under personal tools in your profile page, it's because you've not set up any SourceForge Forks yet.

    Creating a Sourceforge fork is easy, Just go to the FlightGear Repo you wish to fork and click the fork button on the Left. It takes a few minutes and is pretty easy to figure out. You'll get to see the clone statement for the repo after refreshing the page after the fork is created.


    Part 2 - Create a local clone for each Sourceforge Fork

    If you already have clones of Flightgear git repos from Sourceforge, there's no need to re-do them as clones of your SourceForge Forks, they can easily be converted using the same steps you would use on a fresh clone of a personal fork.

      • create origin remote
      • create upstream remote
      • set upstream fetch to main flightgear repositories
      • create a branch for working on changes
      • checkout next
      • checkout a change branch
      • stash changes on a branch
      • push a change branch to your SourceForge fork
      • pull changes from next
      • got fetch

    Tools

    Tools for a Flightgear Developer (see also Tools of the Trade)

    From Command Line to Holding Short

    From Command Line to Holding Short. A look at what gets called when you start Flightgear from the command line until you are on the runway. This is a work in progress, somewhat stalled after Eduard Auvergne's initial work on subsystems. It needs a re-vamp to make it current and publishable.

    RTFM
    • http://wiki.flightgear.org/FlightGear_Manual
    • fgdata/doc/img Look at each image in, noting the name of the image and what the image is trying to say
    • fgdata/doc/keyboard/map.pdf Note that key bindings can be specific to an aircraft. Note that the pdf was produced from a .tex file.
    • fgdata/Docs/model-combined.eff/README.model-combined.eff Read and not What's "rembrandt" - Key terms can be pulled from this document
    • fgdata/Serial/nmeafaq.txt Garmin - Key terms can be pulled from this document. This document describes a data protocol
    • AI_doc.html
    • FGShortRef.html
    • http://flightgear.org/Docs/FlightGear-FAQ.html
    • fgdata/Docs/fschool_0.0.3.pdf
    • fgdata/Docs/index.html
    • fgdata/Docs/model-howto.html
    • and lots of others - point is you have to read them all

    Once they're read, is there a way to organize them so the result is an overview?

    Sure there is. Just write a book:

    IDEs

    Working on Configurations for Visual Studio, Visual Studio Code, Atom, Eclipse and QTCreator IDEs and other tools for working with FlightGear Data.

    The day to day work of a FlightGear Developer will include the use of a variety of software to work on various kinds of FlightGear material. The material includes Source Code written in C and C++, Scripts written in Nasal, Build procedures using CMake and in scripting languages of 3 operating Systems, Data Files representing Airports, Runways, Taxiways, Airport Markings, Navigation Beacons, Instrument Landing System Transmitters, Taxiway and Runway Lighting, Buildings, Roadways,

    The workflow for all of these has a few basic steps.

    • Get copies of the original source material
    • Establish a fork repository for your changes to the materials
    • Make a local copy of the materials
    • Change the materials
    • Check the Validity of Changes
    • Deliver changed materials to your fork
    • Request that the changes be accepted and merged with the original source materials.

    The workflows differ based on the true owners of the originating material and the materials format.

    These are the basic tasks that a developer will need to complete

    • Setting up forks of FlightGear Git Archives
    • Identifying non-git Open Source Resources for use with Flightgear and establishing forks for them
    • Downloading appropriate tools for working on the kind of files that make up the FlightGear application and it's data
    • Configuring these tools and FlightGear itself to operate in one or more modes
    • Learning the steps to use inside and outside the tools


    Figuring out how to contribute to FlightGear

    Getting things done in Flightgear


    As part of my Cockpit Building efforts, I'm also working on

    Contact

     Email Callahanp through the wiki
    

    I show up occasionally on discord, #flightgear on irc.flightgear.org and am a member of several public forums related to cockpit building.

    Callahanp (talk) 09:45, 11 November 2017 (EST)

    The Howtos

    -- Oh yeah... those...

    I'm working on these along side building my cockpit. Some of the early attempts were not that useful. My current approach is to build and document actual hardware. I hope this will be more helpful.

    Current Projects: