FlightGear Newsletter January 2014
|
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.
Development news
FlightGear 3.0 release candidates
February 17 is our scheduled v3.0 release date! If any of you are a bit adventurous and want to test out the "release candidates", you can find the latest FlightGear-3.0 builds here: http://fgfs.goneabitbursar.com/releases/ Please double check the dates, these are not official 3.0 releases yet and are subject to change as we close in on the official release date.
Feedback is welcomed in our dedicated forum https://forum.flightgear.org/viewforum.php?f=68
Soaring instrumentation SDK
Galvedro has started documenting the new soaring instrumentation Software Development Kit (SDK). The soaring instrumentation toolkit is a small library of Nasal objects that you can use for adding specialised soaring gauges to your glider. The library is comprised of several building blocks that you can connect together in different ways in order to get the desired functionality.
In order to use the library, you will need to write a Nasal script that will be loaded together with your aircraft. You do so by referencing this script in the <Nasal> section of your aircraft definition XML file. But don´t be scared, the scripts will be very simple. Lets see some examples.
io.include("Aircraft/Generic/soaring-instrumentation-sdk.nas");
var probe = TotalEnergyProbe.new();
var vario_needle = Dampener.new(
input: probe,
dampening: 2.7,
on_update: update_prop("instrumentation/vario/te_reading"));
var vario_instrument = Instrument.new(
components: [probe, vario_needle],
enable: 1);This code implements a basic total energy compensated variometer, writing the needle reading to the property "instrumentation/vario/te_reading".
Continue reading at Soaring instrumentation sdk...
Creating a custom ATC/RADAR Layer in 10 minutes
Philosopher and Hooray have added a new tutorial that demonstrates how to create new MapStructure-based Canvas displays. People already having some Nasal experience (property tree, OOP), should be able to complete this in less than 15-20 minutes. So, to learn how to create a simple ATC/RADAR display, continue reading at Canvas Radar...
Behind the Scenes of: Nasal Loops
Nasal has several ways to implement an iteration, including repeated events run from listeners or timers. A polling loop, run via a timer, is akin to somebody permanently running to a room to check if the lights are on - a listener is like somebody being INSIDE the room SLEEPING and only WAKING up once the lights are turned on. The setlistener API is intended to catch rare events, whereas timers are run often, pretty much regardless of external events. Both are triggered by calling a so-called "callback" - which is just a provided function to be called as the event-handler, i.e. the function specifies what is to be done once the event is triggered.
In general, timers are not bad or expensive, because it really depends on what you're doing inside the callback (function) that is called, but some constructs benefit from listeners.
Any callback will be executed within a single frame normally - so a long-running timer will add up to the frame spacing (latency), as will a listener triggered just as often or even multiple times per frame.
It doesn't matter if the code/callback is run inside a timer or a listener - what matters is the complexity of the code that runs. Ultimately, though, some code has to be executed somewhere to get the desired result, but in most cases that code can be simple rather than complex. Listeners are only really preferable over timers when it comes to checking for some condition, because timer-loop-based polling is called "busy-waiting", i.e. more expensive, see the previous analogy of somebody having to do something regularly in order to perform a check.
A listener on the other hand, is not resource-hungry while it is "waiting", it's not even "busy" - it's just not doing anything until it is "fired" (analogous to Interrupt Service Routines, i.e. a smoke detector firing an alarm once it detects smoke). However, there are often times where loops make a lot of sense, mainly when lots of values of properties need to be used to drive or evaluate a subsystem or equation.
Continue reading at Nasal Loops...
Atmospheric Light Scattering
Since the uv-mapping of dirt runways in the World Scenery 2.0 is sound, Atmospheric Light Scattering is receiving a hires procedural texturing effect of dirt runways. This effect allows to render puddles and thin snowcover on the runway, as well as allowing patches of another material intruding (here patches of grass). Ultimately, this will make the appearance of dirt runways also regionally configurable, with different mixtures of sand, rocks and grass.
Using OpenStreetMap Data in FlightGear
In 2013, we've seen quite a bit of progress on procedural scenery generation using OpenStreetMap (OSM) data, including buildings & cities (radi, Soitanen/osm2fg), roads, rivers - even railways (vivian) and procedural bridge generation (radi), but also procedural power lines (vanosten).
In other words, there's now some serious -and unprecedented manpower, including quite a few folks who are able to build from source and able to write C++ code. So this deserves being coordinated among all interested parties. And it would clearly make sense not to just expose things to the Canvas system, but to expose the corresponding APIs so that other subsystems and users can access these and use these for the purposes outlined above.
Which is why we have created a summary of the main OSM related efforts we've seen in the last 18 months, continue reading at Using OSM Vector Data in FlightGear...
FlightGear addons and mods
Bombable add-on updated to Version 4.5b
FlightGear add-on Bombable, which turns FlightGear into a full-featured combat flight simulator, was updated to version 4.5b on January 9th.
Highlights of the new version:
- Improvements that help with FG 2.12 compatibility (particularly FG 2.12's new/improved way of handling AI scenarios)
- Improved version of the historically accurate Sopwith Camel (choose the JSBSim version of the Camel that is included in the package)
- Respawn scenario aircraft, vehicles, and ships either a single clump OR retaining their relative positions and altitudes
- Together with FG's new more flexible scenario system, this means you can load Bombable's scenarios instantly and move them to wherever you are in the world instantly--making it a lot quicker and more fun to run the Bombable AI scenarios. You're not stuck with doing scenarios in the one place they were originally set up--you can easily move them to anywhere in the world, while retaining the original scenario's general setup (bombers in a formation, fighter flying cover, tanks scattered around hillsides, etc)
- Improvements to AI aircraft realism, bug fixes.
Read more about Bombable or download the add-on from the forum topic 
This very well explained video made by Jetman shows how to do a short flight mission from San Francisco (KSFO) intercepting an A-10 Warthog air patrol near Sausalito in a F-14 Tomcat running in FlightGear Bombable.
In the hangar
Updated aircraft
DC-10-30 Getting a Flightdeck Refit
David Waggoner, “DrDavid”
A New Front Office for a Great Widebody Airliner
The DC-10-30 (by Ryan Miller) is getting an updated flightdeck with state of the art glass cockpit avionics. The purpose of the project is to create a theoretical refit of the aircraft as if Boeing/McDonnell-Douglas had continued to produce the airplane. The original instrument panel is historically accurate, but as FlightGear has evolved, the advances in avionics technologies have opened up a whole new universe for giving the pilot real-time situational awareness. It proved too good of a prospect to pass by.
The DC-10-30 makes a great platform for this kind of revision because of its sophisticated flight dynamics, autopilot and it is Rembrandt enabled. Rembrandt provides superior lighting capabilities both outside and inside the aircraft, but not all FG instruments are Rembrandt-compatible. Therefore, a new avionics package had to be functional in that environment.
State of the Project
Fortunately, the CRJ-700 Family Series (also by Ryan Miller) has a glass cockpit set up for Rembrandt. The PFD, MFD, EICAS, CDU, Radio Stack, Upper Light Switch Panel, and Side Panels were transferred from the CRJ700 to the DC-10-30. After much tweaking and trial and error, many, but not all of the CRJ’s screens are functional. In addition, a set of standby instruments have been added to support the three glass screens. Note there is cleanup work to be done on the panel—this is a work in development. The choice of instruments and layout are designed to meet my preferences, but that is expected to continue to progress. The two screenshots below illustrate the great effectiveness of having Rembrandt.
Rembrandt and Now the Canvas-Ready NavDisplay
A brilliant opportunity has popped up, in the mean time. The release of the new Canvas-ready NavDisplay screens, which will be developed by FlightGear over time to match specific aircraft, is now available. I am in the process of installing the ND in the DC-10’s MFD. Once a stable MFD is achieved, the aircraft will be uploaded into Git for the FlightGear Community to take a look at. I have a long TODO list for other improvements to the model, and will welcome other collaborators—I suspect you might have some ideas I haven’t even thought of that would be great to include. There is also the opportunity to create more liveries for the airplane.
McDonnell Douglas MD 902 Explorer
The McDonnell Douglas MD 902 Explorer had an significant improvement. Heiko Schulz made a brand new FDM for the MD 902. The helicopter has also a new cockpit with working instruments (most instruments are taken from the EC135). This helicopter has a role as light twin helicopter and makes use of a NOTAR system. So this is a helicopter without a tailrotor.
Screen shot showing the MD 902 in Polizei livery near EDMA.
The cockpit of the MD 902.
Updated JSBSim FDM for Sopwith Camel with historical features
A new JSBSim Flight Dynamics Model for the Sopwith Camel was Aircraft of the Month in May 2013. The FDM attempts to incorporate all known performance characteristics of the Camel documented in various historical accounts by pilots as well as published technical documents. Many of these documents and interesting historical accounts of the Camel can by found in the Docs directory of the release.
Now version 1.8 of the JSBSim FDM for the Camel has been released, taking into consideration feedback from users and making various improvements.
Find out more or download the Sopwith Camel from the forum topic
Sopwith Camels in an AI Scenario running with the Bombable add-on.
Sopwith Camels in an AI Scenario running with the Bombable add-on.
Scenery corner
Airports
Václav Havel Airport Prague
Works have been added to Václav Havel Airport Prague (LKPR) with a lot of hangars, terminals and other buildings. More information can be found on the dedicated wiki page: Václav Havel Airport Prague.
TerraSync has it all! You don't need to download a custom scenery.
The north apron of LKPR
The east apron of LKPR
Regional textures
Regional texture definitions for Iceland have been updated on GIT to match the newly available CORINE based version of Iceland in our World Scenery 2.0. Check it out - the place looks gorgeous now!
In addition, new regional texture definitions are also available for South Africa - view the famous table mountain near Cape Town and explore grasslands and lush vinyards between rugged hills!
Screenshot of the month
FlightGear goes back to space!
Arc top of a ballistic trajectory with the X-15 - 330.000 ft above Iceland, 600 km visibility range!
And falling down to Earth again:
And finally ...
Contributing
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 this short essay 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.[1]— 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.[2]— Andy Ross
|
|
- ↑ James Turner (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.
- ↑ Andy Ross (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.