Difference between revisions of "User:Callahanp"

From FlightGear wiki
Jump to navigation Jump to search
m
Line 18: Line 18:
 
[[https://github.com/c172p-team/c172p C172P Team on Github ]]
 
[[https://github.com/c172p-team/c172p C172P Team on Github ]]
  
 +
I am making an effort to define and show examples of development 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.
 +
 +
FGData
 +
SimGear
 +
FlightGear
 +
FGMeta
 +
GetStart
 +
MacLauncher
 +
OpenRadar
 +
SceneryWeb
 +
TerraGear
 +
Windows 3rdPartyDeps
 +
tarrafs
 +
navdata
 +
pipline
 +
mpmap.js
 +
 +
I will be starting with the steps needed to create and maintain a personal Sourceforge Fork of the main repositories, with a local fork that can be used to work with the next branch or with feature branches on either one of the personal forks or on the personal fork of another contributor, or git bisect operations.
 +
 +
Then I'll be looking at the steps needed to do a build in Release, ReleaseWithDebInfo or Debug variants using the currently checked out branches or commits.  We'll also examine git stash operations to preserve work on a feature branch, while bringing next up to date.
 +
 +
Next I'll take a look at debug sessions including gdb at the command line, gdb in gdbgui, and possibly alternative editors like atom and visual studio code.
 +
 +
* Creating a SourceForge fork
 +
** Requires one personal sourceforge account
 +
** ssh login
 +
*** Create an SSH Key for use with Sourceforge
 +
*** Update Sourceforge SSH Keys
 +
*** Login to the shell with your key
 +
 +
* Create a local fork for each Sourceforge 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 ====
Line 26: Line 67:
  
 
[[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.
 
[[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 =====
 
===== RTFM =====

Revision as of 03:34, 26 April 2020

I am a flight simulation hobbyist currently working on developing skills needed for building instruments, gauges, radios and controls for a C172 and for contributing to flightgear's development.

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.

Callahanp - Flightgear From Scratch

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.

Callahanp - Flightgear Technical Manual

Flightgear and Simgear Code

I personally believe that the FlightGear's core developers need to take a close look at how the project is organized and led and make some serious efforts to recruit, train and retain new project participants.

Callahanp - Flightgear Working Groups

[C172P Team on Github ]

I am making an effort to define and show examples of development 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.

FGData SimGear FlightGear FGMeta GetStart MacLauncher OpenRadar SceneryWeb TerraGear Windows 3rdPartyDeps tarrafs navdata pipline mpmap.js

I will be starting with the steps needed to create and maintain a personal Sourceforge Fork of the main repositories, with a local fork that can be used to work with the next branch or with feature branches on either one of the personal forks or on the personal fork of another contributor, or git bisect operations.

Then I'll be looking at the steps needed to do a build in Release, ReleaseWithDebInfo or Debug variants using the currently checked out branches or commits. We'll also examine git stash operations to preserve work on a feature branch, while bringing next up to date.

Next I'll take a look at debug sessions including gdb at the command line, gdb in gdbgui, and possibly alternative editors like atom and visual studio code.

  • Creating a SourceForge fork
    • Requires one personal sourceforge account
    • ssh login
      • Create an SSH Key for use with Sourceforge
      • Update Sourceforge SSH Keys
      • Login to the shell with your key
  • Create a local fork for each Sourceforge 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: