Board index FlightGear Development

Getting to grips with source tree?

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Getting to grips with source tree?

Postby CWood » Mon Jan 02, 2012 1:52 pm

Please allow me to introduce myself. I am a coder, by trade. I know C, Python, PHP, and assembly language, and used to know C++ and Win32 (until I moved to Linux, of course).

I have many, many ideas for FlightGear, some of which are simple improvements (inertia seems to be a bit of a problem, from what I've seen, and is most noticeable in larger aircraft, eg B777), and some are full blown features. However, I haven't a clue where to start coding, and how to start. I know C, and used to know C++, so refreshing myself in C++ shouldn't take too long, but I'm not used to implementing things in other's code. I'm used to developing from scratch, because then I know the source tree. What paths have other people taken, to get to know the FG source, and how can I follow a similar path. Please note, I'm not asking anyone to hold my hand, I do know development, just not so much open source :oops: .

My ideas, for features, are (in no particular order):
  • Better inertial emulation
  • Finishing the FMC (only certain buttons work)
  • A few improvements here and there on various aircraft, particularly G-109, and G-115 (question: is the Grob G-109 the A model, or B model, because I can't speak for the A, but the speeds, if it is B model, for take-off, climb out, and various other bits and pieces, are all over the place. Speaking from real life experience.)
  • Increased graphics and realism (quite low on priorities, get the actual simulation sorted before the graphics)
  • Ability to transmit sound, specifically for ATC and Approach radios.
  • AI ATC, Approach, etc (has this already been done? Not too sure, need to research), including a text-to-speech system, and speech recognition system (?)
  • Placing of AI radio controllers in all airports, on multiplayer, when nobody already manning said airport frequencies
  • Better tutorials on aircraft, including references for speeds, engine settings, procedures, etc
  • Integrated route planner
CWood
 
Posts: 8
Joined: Fri Dec 30, 2011 5:22 pm

Re: Getting to grips with source tree?

Postby Hooray » Mon Jan 02, 2012 3:58 pm

Hi & welcome

Many of the things you mentioned don't necessarily require C++ knowledge, FlightGear has become so flexible and powerful that it is increasingly configurable even without the C++ source code.

This isn't to say that C++ wouldn't be useful though. And if that's where your interests are, you are certainly invited to contribute to the C++ code, too. Gitorious is the entry point here: http://gitorious.org/fg/

You said, you have many ideas - ideas (feature requests actually) and bug reports are ideally reported using the issue tracker here: http://flightgear-bugs.googlecode.com/

Most core development related discussions are handled using the developers mailing list: http://www.flightgear.org/mail.html

There's a fully searchable archive available here: http://www.mail-archive.com/flightgear- ... forge.net/

Improving the flight dynamics often doesn't require any C++ changes, FlightGear provides a powerful FDM interface and different FDM engines (namely JSBSim and YaSim), both of which are entirely configurable by using XML files.

For JSBSim, please see: http://jsbsim.sourceforge.net/

There's a wealth of documentation to get you started available in $FG_ROOT/Docs

Even more documentation can be found in our wiki, here: http://wiki.flightgear.org/
The wiki is partioned into different "portals", you'll probably be interested in the developers portal here: http://wiki.flightgear.org/Portal:Developer

FlightGear itself consists of a number of different projects and dependencies (libraries), please refer to gitorious for details.

In many parts, the FlightGear code base is still rather archaic, so you won't find too many occurrences of really advanced C++ concepts, in many places you'll just find simple "C with classes", some STL and inheritance. But complex C++ features (such as advanced templates or meta-programming are not too common actually).

The wiki has plenty of stuff to get you started though: http://wiki.flightgear.org/Resources

The SimGear code base is somewhat less archaic and more modern actually. And if you are interested in contributing to the OpenGL/SceneGraph department, you'll inevitably need to look into OpenSceneGraph (OSG), too.

If you'd just like to get started quickly, there are also certain FG components that are strictly (largely) pure C, the Nasal interpreter is just one example (Nasal is FlightGear's built in scripting language): http://wiki.flightgear.org/Nasal_scripting_language

Once you have found something you are interested in, you can search the archives (mailing list and forums) or the issue tracker to find suitable projects to work on, for example: http://code.google.com/p/flightgear-bug ... ells=tiles

For Nasal in particular, we have also a page detailing it's most annoying issues here: http://wiki.flightgear.org/Improving_Nasal

If you are interested in fiddling with Nasal itself, i.e. by adding a handful of new commands to the scripting engine, this is documented here: http://wiki.flightgear.org/Howto:Extending_Nasal

None of this requires any C++ knowledge!

If you are interested in adding new subsystems to FG, you may want to check out this: http://wiki.flightgear.org/Howto:Creati ... Subsystems

The FlightGear property tree is documented here: http://wiki.flightgear.org/Howto:Workin ... y_Tree_API

Regarding patches, please see: http://wiki.flightgear.org/Submitting_Patches
Note that this is somewhat depreciated and these days using gitorious (and filing merge requests) is pretty much encouraged.

FlightGear itself uses the decentralized source code management system "git": http://wiki.flightgear.org/Git

If you know for sure that you'd like to fiddle with the core source code, you'll inevitably need to be able build FG from source, this is also documented in our wiki, a more recent article is to be found here: http://wiki.flightgear.org/Howto:_Build ... sing_CMake

You can find tutorials for different platforms/OS at the end of the article.

I'm used to developing from scratch, because then I know the source tree. What paths have other people taken, to get to know the FG source, and how can I follow a similar path. Please note, I'm not asking anyone to hold my hand, I do know development, just not so much open source :oops: .


My advice would be: Start small, start simple.
  • start making tiny modifications to existing stuff (aircraft, scenery, source code)
  • read the documentation (wiki, $FG_ROOT/Docs)
  • if you know you want to contribute to the source code, make sure that you are actually able to build FG from source
  • try to get to grips with how git works
  • register an account at gitorious
  • browse the issue tracker for bug reports/feature requests, help triage problems, maybe provide patches too?
  • subscribe to the developers mailing list, ask for advice/projects there
  • check out the wiki for ideas to get started
  • coordinate your effort with others, i.e. communicate your intentions and ask for advice
  • release early and often
  • don't get frustrated :-)


Regarding your list of ideas: Like I said, many of them won't require any modifications to the C++ source code at all.
You could probably get started and implement many of them without touching an IDE or compiler.

That might actually be the easiest route for you to proceed.
Your programming knowledge would obviously still be useful.
The "Nasal" programming language built into FG is syntactically very close to C and C++ - so you could run your own code inside FG without having to build FG from source.

If you are looking for immediate results, Nasal is probably the most promising route - simply because you don't need to look into all the tedious, non-coding related issues.

The tutorial system built into FG is entirely implemented in scripting space, and fully XML-configurable: http://wiki.flightgear.org/Tutorials

This means that you can create/modify and improve tutorials just by editing plain text files.

There are many more things possible using Nasal, just see the wiki.
And if you find something not being possible in scripting space, you could either fire up your IDE and extend the interpreter or ask another contributor to provide a corresponding patch.

For non coding-related ideas on how to to start contributing, there's a dedicated article here: http://wiki.flightgear.org/Volunteer

Finally, please don't get discouraged if you don't get too much feedback at the moment, many contributors are busy preparing the next release: http://wiki.flightgear.org/Release_plan
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12089
Joined: Tue Mar 25, 2008 8:40 am

Re: Getting to grips with source tree?

Postby CWood » Tue Jan 03, 2012 3:07 pm

Wow! Thanks for that, Hooray, incredibly in depth post. Actually, forgive me if I'm wrong, still new to the community and all, but could we not include all that info on the wiki, for all the new people who are still starting out, like myself?
CWood
 
Posts: 8
Joined: Fri Dec 30, 2011 5:22 pm

Re: Getting to grips with source tree?

Postby Hooray » Tue Jan 03, 2012 3:24 pm

yes, exactly my thinking too. The truth is, we have a bunch of "volunteer" and "contributing" articles - but so far, we didn't have anything specifically targeted at C++ developers, i.e. people wanting to tinker with the C++ code. So that's why I went ahead and copied my posting over to the wiki already: http://wiki.flightgear.org/Howto:_Start ... evelopment

I hope others to contribute to this eventually. Obviously, it will be helpful if you could let us know if there's anything else unclear or missing, so that we can incrementally improve this article and hopefully make it easier for newcomers to get started.

Also, you might want to register a wiki account, so that you can help me review/edit and improve the article. You can use the article's talk page to ask new questions. I guess that will be better than using the forum.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12089
Joined: Tue Mar 25, 2008 8:40 am

Re: Getting to grips with source tree?

Postby Hooray » Tue Jan 03, 2012 4:43 pm

Regarding the ideas you have posted:

CWood wrote in Mon Jan 02, 2012 1:52 pm:My ideas, for features, are (in no particular order):
Finishing the FMC (only certain buttons work)


what FMC are you referring to? The FMC itself is probably implemented using Nasal scripting, so no C++ needed.


A few improvements here and there on various aircraft, particularly G-109, and G-115 (question: is the Grob G-109 the A model, or B model, because I can't speak for the A, but the speeds, if it is B model, for take-off, climb out, and various other bits and pieces, are all over the place. Speaking from real life experience.)


None of these will require changes to the C++ source code, this is all about FDM tweaking.

Increased graphics and realism (quite low on priorities, get the actual simulation sorted before the graphics)

Graphics can also be improved without touching the C++ source code, i.e. by making use of the effects framework and shader programming.


CWood wrote in Mon Jan 02, 2012 1:52 pm:Ability to transmit sound, specifically for ATC and Approach radios.

This is already possible using a separate tool, called "FGCom", this works with FG by using a socket connection (UDP actually), interfacing with its property tree.

CWood wrote in Mon Jan 02, 2012 1:52 pm:AI ATC, Approach, etc (has this already been done? Not too sure, need to research), including a text-to-speech system, and speech recognition system (?)

TTS integration is already available, in the form of festival support.
AI ATC/approach can be implemented using Nasal scripting:

viewtopic.php?f=23&t=6807&p=66463#p66463
viewtopic.php?f=23&t=12849&p=134970&#p134933

Basically, just do a search for "tanker.nas" which is an example for a fully scripted AI aircraft. The same technique could be used to make it respond to ATC instructions (climb/descend, turn to etc). Also, you could obviously create a scripted AI ATC controller, too. So you would end up with two different scripts: one controlling an AI plane and waiting for instructions, another one sending instructions to the AI plane (i.e. the ATC).

CWood wrote in Mon Jan 02, 2012 1:52 pm:Placing of AI radio controllers in all airports, on multiplayer, when nobody already manning said airport frequencies

This would be also possible by using Nasal scripting, no C++ required.

Better tutorials on aircraft, including references for speeds, engine settings, procedures, etc

This doesn't require any programming at all. Like I said already, the tutorial system itself is XML driven and references for aircraft can be added as XML dialogs, as is already done for many aircraft (v speeds). This would be just a matter of copying such a GUI dialog file and customizing it for different v speeds.

Integrated route planner

The route planner is currently work in progress, the developer behind it is "zakalawe", just do a forum search. There are many changes planned already. Eventually, it is supposed to be integrated with the Map dialog and become fully property-driven, so that aircraft can implement and customize different types of "glass cockpits" by instantiating some generic instruments.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12089
Joined: Tue Mar 25, 2008 8:40 am

Re: Getting to grips with source tree?

Postby CWood » Tue Jan 03, 2012 5:32 pm

With regards to my route planner, I was intending on having the sectional charts included directly, or downloaded on the fly from somewhere. I don't know if the one already in development already does this? Can anyone provide me with a link to any info/development discussions for this? Thanks :)
CWood
 
Posts: 8
Joined: Fri Dec 30, 2011 5:22 pm

Re: Getting to grips with source tree?

Postby Hooray » Tue Jan 03, 2012 5:48 pm

For this, we have the atlas tool: http://atlas.sourceforge.net/
This is an external tool, that talks to FG via a socket connection.
The program is being developed by fellow FG user bschack, and has its own sub forum here: viewforum.php?f=31
Feature requests are kept here: http://sourceforge.net/tracker/?atid=35 ... unc=browse
There are also a number of related feature requests: http://sourceforge.net/tracker/?func=de ... tid=359456

Image

Built into FlightGear, we have the "Map dialog": http://wiki.flightgear.org/Map
Image
This is based on a custom PLIB/PUI (The cross platform OpenGL GUI library used by FG) dialog.
The details of which can be found in $FG_SRC/GUI/MapWidget* http://gitorious.org/fg/flightgear/blob ... Widget.cxx
All of this was also developed by zakalawe.

So there are two somewhat competing solutions here. If you are interested in hacking the FG side, you'll probably want to look into OpenSceneGraph (OSG), too. Because it already comes with support for "on the fly" downloading and rendering of PDF files using different plugins.

For Atlas though, the right person to talk to is the atlas developer (brian). There are obviously several advantages and disadvantages to either approach. But overall, there's a certain tendency to move more and more stuff out of the core FG source tree into SimGear or even dedicated tools. This isn't necessarily always ideal (think launcher), but makes some things easier.

So the map dialog was originally just meant to be a prototype for a related new instrument type in FG: viewtopic.php?f=14&t=12499
While atlas has always been intended to be a dedicated charting application.

Also, atlas is certainly easier to get started developing for than FG is (i.e. because the code base isn't as complex or huge). But I don't know if there's any developers documentation to get you started. You better talk to brian (posting to the atlas sub forum will do).

For FG/SG, there's the possibility to automatically create doxygen documentation: http://simgear.sourceforge.net/doxygen/

Thinking some more about it, you'd actually only need 2-3 new "main" features to implement this directly within FG:
1) an ability to download images via some background thread (i.e. using Nasal)
2) aligning and rendering textures as overlays on top of PUI dialogs

We've previously talked about both ideas for a number of different purposes, so it's definitely possible and useful.

viewtopic.php?f=6&t=14683&p=145035&#p145035
viewtopic.php?f=6&t=7383&p=70239
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12089
Joined: Tue Mar 25, 2008 8:40 am


Return to Development

Who is online

Users browsing this forum: No registered users and 0 guests