FlightGear Newsletter December 2013
We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release. At the end of each month, it's generally a good idea to get in touch with other contributors to ask them to add news about their contributions to the newsletter.
This video shows a short flight from Raron (LSTA) to Sion (LSGS) Switzerland in a Robin DR400 running in FlightGear. Terrain scene is generated from osgEarth whole earth real-time terrain streaming C++ library. The osgEarth terrain scene can be switched on/off at runtime.
In this example, the imagery is streamed from ArcGis WMS (web mapping service). osgEarth supports a wide variety of streaming sources.
osgEarth is currently integrated into a development branch for FlightGear version 2.99. The integration changes are currently submitted for approval for the next major release of FlightGear.
Gijs has started extending the NavDisplay framework to support additional display modes typically found on modern Boeing aircraft:
Wizard-based Aircraft Creation
When it comes to aircraft development, one of the areas that people find frustrating is that features used by aircraft developers will be documented in the Wiki but the examples are so minimal that it can be difficult or nearly impossible to get something working because the published examples are lacking in detail or don't show important variations of how to code the feature.
We've come to the conclusion, the best step towards fixing these issues is to have a set of templates for common aircraft configurations (single engine prop, multi-engine prop, single engine jet, multi-engine jet with co-pilot etc). These templates would have all of the minimal components to compose a "production" aircraft (according to the rating guide).
We've been tossing around that idea for a while, i.e. coming up with project-maintained "templates" for things like aircraft, to ensure that people have some way to get guidance without overly relying on extensive copy/paste programming - we really only need someone to start with a "dummy" aircraft that, with lots of comments and options (Nasal, sound, canvas, help, checklists, tutorials). In fact, it would even be possible to provide wizards to help customize such templates, i.e. to change name/author/status, 3D models, file names (sound, textures).
The idea is that we should have a set of standard aircraft templates, or some fancy means of generating an aircraft skeleton based on some user input. These templates would contain all necessary files and code to implement a simple but complete aircraft of a given configuration (single engine prop, multi-engine jet etc), and possibly stubs for common enhancements. Standard enhancements (checklists, autopilots etc) could be included as comments indicating where code needs to be added, This would make FG aircraft more consistent, but also help newbie aircraft developers to get of the initial obstacle of understanding how it all comes together. I think this would help us overcome the issue of having so many aircraft in various pre-production states of development.
During the discussion on the forum, we came up with the ideas that we could have a template aircraft and parametrize it dynamically inside FlightGear - after all, it's 95% PropertyList-encoded XML, i.e. can be read/manipulated and written via standard FlightGear/Nasal means - in other words, you could take an existing PUI dialog and turn it into an "aircraft wizard", where the user could specify things like 1) filename, 2) description, 3) FDM type, 4) status, 5) thumbnail and so on - this is all straightforward to do, it just involves setprop() stuff after having read the template into the property tree via io.read_properties(), at which point a simple GUI dialog could be shown to streamline the aircraft development process in a step-by-step manner. Many building blocks exist already, including a file picker dialog - missing stuff can be implemented via Canvas extensions.
Such a wizard woud ideally not be implemented as a "hardcoded" XML dialog, but rather as a Nasal submodule that dynamically creates "pages" for each step in the wizard. None of this is difficult, it really just involves 1) property tree, 2) read/write properties via io.nas and 3) basic Nasal (setprop/props.nas) for modifying the template aircraft. Such a wizard could also be easily made aware of difference between FG versions, and users could be asked to target a certain version, i.e. to omit certain stuff, like for example Canvas support, or effects etc
A first, very basic, prototype of this is now available, and waiting to be adopted by fellow contributors to help grow this "wizard", i.e. by adding features to it, but also by adding new templates to it, for different aircraft features, such as Aircraft Checklists, Tutorials, Walk View etc.
Given that most of us are already juggling too many projects, we're also looking for people who would possibly like to get involved in this in some way.
Coding-wise, this is currently just about 150 lines of very simple Nasal code, copied together from various other dialogs and wiki tutorials. So knowing Nasal would be a plus, but if you have any other scripting/programming experience, that will do too. So if you are interested in FlightGear scripting and simplifying aircraft deveopment for newcomers, please get in touch via the forum or the wiki.
Continue reading at Aircraft Generation Wizard...
Implementing VNAV -a Brainstorming
We've recently had another discussion on the forums about implementing VNAV in FlightGear. In comparison with other flight simulators, FlightGear has been lacking support for simulating VNAV features found on many modern aircraft since day one.
So far, the general consensus has been that it simply isn't yet possible in FlightGear to properly implement VNAV because VNAV depends on having access to an aircraft-specific performance database to provide the proper pitch/thrust changes to make certain VNAV altitude/speed/time constraints, which boils down to a lack of support by the FDMs (JSBsim/YaSim) actually.
As an open source project, we do not have access to the corresponding flight data or such a performance database, and even if we did, we probably couldn't easily use said data due to its proprietary nature.
In addition, a real performance database would probably not serve us too well, because our FDM configurations are custom, too - i.e. the performance database would need to match the performance of the simulated aircraft.
Thus, a performance DB would ideally be provided by the FDM itself. Either in a pre-created fashion, i.e. compiled during an offline "test flight", or preferably at runtime by running a simulation of the FDM inside the actual FDM.
We've now started gathering all information from past VNAV discussions to come up with a brainstorming and determine how to implement the building blocks required for supporting VNAV (vertical navigation) in FlightGear (YaSim/JSBSim). Any feedback is greatly appreciated.
Continue reading at Implementing VNAV support in FlightGear...
Alternative camera control
Fellow FlightGear user Marius_A has created a virtual camera for FligthGear that's written in Nasal, it adds features similar to Ezdok Camera Addon for FSX.
Getting involved as a programmer
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.
If you are interested in contributing as a core developer, please see Howto:Start core development.
Building from Source
Thanks to work done by Seatbutler, the Howto:Build FlightGear with NetBeans using CMake article has recently been updated and verified to still work.
Following design changes suggested by FlightGear users, the computer2cockpit's flight yoke design has been extended with:
- Map holder
- Additional rocker switch and push button switches on right side of the yoke
- Additional push to talk switch
- Prototype manufacturing preparation - setting up the CNC router
- Talking with suppliers to lower the initial costs and production price
DIY hardware panel for FlightGear
At least five projects exist where FlightGear users build their own hardware panels with real switches and knobs to interface with the FlightGear software to improve the flying experience. Follow the build progress of ludomotico's and pommesschranke's panels on .
In the hangar
Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo
Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.
Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.
North American P-51D Mustang
The JSBSim P-51D is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.
The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.
The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.
The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.
There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.
fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.
The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.
Please feel free to give this a try and provide constructive feedback on the FlightGear forum.
Major changes in the wiki help pages
These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the, the wiki of the developers of the the wiki software used by the FlightGear Wiki.
In summary, the following changes have been made:
|→ Help:Templates||– Rewritten and extended|
|→ Help:Formatting||– Rewritten and extended|
|– Rewritten and extended|
The work is not complete yet though. Most of all the translations of these pages needs to be moved and/or translated, and a couple of pages, Help:Categories and Help:Tutorial, could still need a rewrite (though on a much smaller scale).
And finally, a style guide (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at Help talk:Style guide, as well as additions to Help:Style guide, which is currently (very) incomplete.
|The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate.|
|Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an.|
|De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen.|
|La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir.|
And finally ...
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.
For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.
To learn more about how the project works, please see written by Thorsten, for a more detailed article see How the FlightGear project works.
YASim looking for a new maintainer
|There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.
Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)
So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. Suggestions for that means in practice, are most welcome!Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.
— James Turner
|I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my
latencies here are measured in weeks.Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.
— Andy Ross