A preview of new features in the Honolulu release

Discover Hawaii

The first FG release in 2018 will move to the tropical island of Oahu, using Honolulu as the default airport. In preparation, the islands of the Hawaii chain have received a makeover – textures for the typical shrub vegetation has been added, the terrain texturing has been improved and the airport layouts have been re-generated.

There’s now a lot of new things to discover – fly to the ‘garden island’ of Kauai and look for waterfalls, search for the new highly detailed aircraft carrier ‘Harry S. Truman’ cruising close to Oahu, watch a sunrise from the summit of mighty Haleakala on Maui or discover an active lava fountain on the ‘big island’.

Active volcanoes

Have you ever seen a volcano eruption in a flightsim? This is your chance – in the upcoming release, you won’t only be able to see lava pools and volcanic smoke of Puu’Oo on Hawaii, but also see lava fountains of the Italian volcano Stromboli and even the mighty ash plumes blown high into the air by an eruption of Etna on Sicily. The activity of all these volcanoes can be adjusted from the Environment GUI.

The current implementation is still limited, but in the future, volcanic ash might actually interfere with the weather and aircraft operations – just like in reality.

Unprecedented vegetation detail

Using geometry shaders, the Atmospheric Light Scattering rendering framework now offers the option to see dense volumetric grass layers on the airport greenspaces, as well as rendering additional 3d layers of vegetation underneath the regular random trees and shrubs in regions where this is configured. This offers the eye a pleasantly high level of detail even at close range and adds much to the visuals. While this technique might be heavy for older graphics cards, the performance on a modern high-performance graphics card is excellent.

A helpful co-pilot

Have you ever wanted to fly a helicopter, but didn’t manage to get it off the ground? The Alouette-III now comes with a helper (or flight instructor) for you – Amelia.

Amelia (named after aviation pioneer Amelia Earhart) is an animated co-pilot capable of taking off, landing and hovering the helicoper for you, according to your instructions. You can simply ask her to get the craft off the ground for you, then fly it a bit forward and then take over from her. Or, if you’re interested in operating the winch and doing rescue operations, she can hover over a spot and move slowly to the right spot according to your directions.

New and updated aircraft

A lot of development has happened for various aircraft – for instance the Robinson R44 helicopter has received a stunning new 3d model and many systems are now simulated in detail.

Another great addition, both in terms of visuals and systems, is the new Cessna C-182. If you like single prop aircraft and want to see something more modern than the default C-172p, try it out – it makes for a great plane to do sightseeing in Hawaii!

The carrier handling of the F-14b is now much more realistic, with arrestor wire effectivity dependent on speed at touchdown, more realistic low speed aerodynamics during the approach and correct ‘kneeling’ of aircraft when on the catapult – take the F-14 to the ‘Harry S. Truman’, and you won’t be disappointed!

Lots of details have also been added to the Citation-II business jet and bugfixes, gear damage, a correct autopilot and an improved radar to the F-15.

…and much more

Much more work going on behind the scenes:

* improved usability and integration of the Flightgear launcher
* fixes for AMD graphics cards rendering issues
* many other small bugfixes
* improvements to the YaSim flight dynamics engine for better realism

Stay tuned as we launch the next release!

FGMEMBERS Statement

FlightGear FGMEMBERS Statement (v2.2):

Preface

What you see today as FlightGear is the result of 20 years of collaborative development effort by hundreds of talented people all working together to provide a freely available GPL flight simulator that anyone can contribute to.  The core FlightGear team feel that it is important to make a clear statement of their position concerning the FGMEMBERS organization, explaining why it is important to continue working in a way that will ensure that FlightGear continues to prosper for the next 20 years as well as to clear up any confusion and FUD that has been disseminated by members of the FGMEMBERS organization.

The FGMEMBERS infrastructure offers little benefit to contributors.  From experience, the core team knows that the lack of appropriate controls on contributions may, after a long period of time, lead to a divergence that may result in contributions being lost.  This includes the divergence of models as well as scenery enhancements that are not contributed to the scene models database.

TOC

Background

During five years of in-depth discussions on the development mailing list (where decisions are made[1]) a consensus of opinion was reached which defined the future direction for the core assets of the FlightGear project.  This required the removal of the aircraft models from the old fgdata repository[2], leaving the core assets and the default aircraft.  Unfortunately this necessary change resulted in a fundamental disagreement with a couple of FlightGear users who demanded that the decision making process be restarted[3].  Clearly with five years of discussions already undertaken it was not a viable path forwards to restart discussing the splitting of the assets and which revision control systems were most suited for the FlightGear project.

One of the objectives of the project is longevity and ensuring that the path taken is, with the best available knowledge, as future proof as possible, allowing authors to make their contributions with the minimum amount of disruption whilst maintaining quality and licencing standards.

As a result of the disagreement, one contributor started what is generally considered to be a hostile fork of the core asset repositories into what is known as FGMEMBERS.  This was expanded to include all the other models and assets from all non-official repositories from all corners of the internet, to form a single source for all contributed assets (core assets, aircraft, scenery, 3rd party hangars, etc.).  At a first glance this appears to be a good idea, as there is a single place where everything can be found.  However the disparate nature of contributions means that FGMEMBERS is a divergence of most of the original content.  Whilst certain repositories may be up to date within FGMEMBERS, it is not necessarily true that this will remain the case.  Taken together, this negates the key benefit of a single location for all content.  The other key point is that any changes contributed to the FGMEMBERS infrastructure may never make it into the original repositories.  This affects the availability and quality of models for the wider community of the FlightGear project, such as the aircraft that are available for download on the FlightGear website and launcher[4].  Any contributor spending considerable time making changes to aircraft or scenery may be unaware that their changes may be lost in the future, especially in the case of scenery as the FGMEMBERS scenery workflow is to modify what is considered to be an automatically generated set of temporary files from base data sources.

Since its inception, the FGMEMBERS organization has continually made very emotive statements and accusations regarding the core development team and the way the FlightGear project is run.  The core FlightGear team consider those baseless and has refuted them.

Official FlightGear Position

The core FlightGear team considers the FGMEMBERS data asset forks to be hostile and the infrastructure bad for the FlightGear project for a number of reasons:

  1. Historically, forks of Open Source projects are unsustainable because developers choose one or the other.  Over time, the vast majority of forks die.  In a small minority of cases they become prevalent and the original dies.  In either case, a huge amount of effort is wasted on the fork that eventually loses.  We feel that effort is better spent on improving the simulator.
  2. It is inevitable that the fork will diverge, as changes are made to one repository but not the other.  Attempting to keep the repositories in sync requires huge amounts of effort and is likely to fail due to incompatible changes being made to the same file by multiple developers.
  3. The FGAddon repository is actively supported by the core development team, with processes in place to ensure the long term health of the repository, and compatibility with any changes to the FlightGear core.  The core FlightGear team have been working on this project for 20 years and has a long track record of ensure the long-term health of the aircraft.
  4. We are concerned that FGMEMBERS deliberately does not have controls over commit access to the repository and as a result license violations have occurred.
  5. Different versions of the same aircraft existing in both FGAddon and FGMEMBERS causes confusion and adds to the burden of support from volunteers who may not have the same version.  This makes tracking down bugs much more difficult.
  6. We object most strongly to the way that FGMEMBERS proponents have evangelized against FGAddon and TerraSync and the accusations that they have made against the core team.  We consider this unacceptable.
  7. The constant and active recruitment of potential developers away from the core infrastructure has caused and is causing a lot of long term harm to the FlightGear project.

The FlightGear development team encourages users and developers to use the official repositories and infrastructure (FGData, FGAddon, TerraSync) and continues to support 3rd party hangars.

FAQ

Why is this important?

Question: What is the point of this document?

Answer:
It is important that we all work together to ensure the continued growth and development of FlightGear.  The core team does not want to see valuable contributions being lost because these contributions were made to something outside of the FlightGear project.  What you see today exists due to the time and effort of developers.  Unfortunately in recent years FGMEMBERS has proved to be a considerable waste of developer time that could have better been spent on improving things rather than dealing with and refuting allegations, answering questions from confused users and declining attempts to reopen discussions that have no relevance for the already decided future path of the project.

Why is FGMEMBERS considered as a legal liability?

Question: Why is the core design of the FGMEMBERS system considered as a legal liability?

Answer:
The official FlightGear infrastructure operates on a basis of trust and experience, in which a committer must be prepared to accept the trust of everyone else and show an understanding of copyright issues.  This is in stark contrast with the FGMEMBERS principle that everyone and anyone can obtain commit access for improving the system.  The FlightGear way has been proven to work over many years as it results in collaborators who can be trusted not to cause damage to the FlightGear project or to cause legal jeopardy by a lack of understanding.  Without this there is an elevated risk that an inexperienced content developer may deliberately or inadvertently obtain material (3D artwork, photographs, sound bites, etc.) found somewhere on the web and include it within their own GPLv2+ licensed content without due consideration of the licencing implications.  The official FlightGear infrastructure has the *-commitlogs mailing lists[5], allowing individual commits to be reviewed; whereas FGMEMBERS has no such system and as such can be considered as a more anarchic system where illegal content will inevitably be added under the radar.  This is unacceptable in a large open source project such as FlightGear as it puts the contributor and the project at legal risk.

Why use the “hostile fork” terminology?

Question: Why is the FGMEMBERS infrastructure referred to as a “hostile fork”?

Answer:
This is standard software development terminology for the FGMEMBERS situation.  Here is one definition:

  • “A HostileFork happens when someone isn’t happy about the way a collaborative effort is being run, so they start their own competing project.  They take the work of the group in a different direction…rather than working on achieving a consensus.  Often they lobby for developers to assist their effort, rather than the original project from which they are derived.”[6]

And another:

  • “A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project.  It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split.Compare to forking to solve a very specific or specialized problem that doesn’t make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case.  In such a case, it’s common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don’t diverge too much.”[7]

The core group consider the current situation to be an exact match to the “hostile fork” definition.

Why not consider the FGMEMBERS proposal?

Question: Why is the design and operation of the FGMEMBERS system considered as unsuitable for use as the official FlightGear infrastructure?

Answer:
Firstly, the proposal was made years after a consensus had been made and a decision reached.[8].

Secondly, the design is considered to be incompatible with how the FlightGear community operates.  The FlightGear community is bound together by mutual respect and basic courtesy; there may be disagreements but it is expected that disagreements be handled in a respectful way without personal attacks.  The wishes of all contributors wherever possible are respected.  There are some models in FGMEMBERS in which the original authors have directly stated a wish to not have their aircraft be distributed as part of this system.  Instead of respecting that wish, these aircraft remain bundled as part of the FGMEMBERS.

Another concern, and in many ways for the community a large concern, is the encouragement to make contributions outside of the official or original author’s distribution channels.  This is a key aspect of the FGMEMBERS system used to advertise to new users that the FGMEMBERS system is superior to the original upstream sources.  Hence the FGMEMBERS system strongly competes against those wishing to be independent of the system, using an “improved” version of their own work.  To avoid this, a number of content creators have used specific licensing to legally block FGMEMBERS redistribution.  But in the process these authors have lost part of their freedom that the GPL licence offers — the same freedom that has allowed FlightGear to become what it is today.  This is causing long-term damage to the FlightGear project and the GPL ecosystem built around it.

We consider that redistribution for solely aggregation and deliberate divergence of GPL-licensed content is permissible legally but morally questionable.  Particularly when it is against the wishes of the original author, and implicitly competing against that author for the aim of selling the FGMEMBERS system.  This is considered unacceptable as a model of operation for the FlightGear project.

Why not peacefully coexist?

Question: Why is FGMEMBERS different from all of the other 3rd party infrastructure and peaceful coexistance not possible?

Answer:
The aim of the FGMEMBERS organization is to attract as many FlightGear users and content developers as possible to become the de-facto FlightGear content infrastructure.  To achieve this, FGMEMBERS deliberately aims to minimise or completely cut off contributions upstream to the core FlightGear infrastructure for the sole purpose of rendering it irrelevant.  However as the same design is used for both the core infrastructure and the 3rd party infrastructure, this affects the whole of the FlightGear community equally.  FGMEMBERS hoards absolute all of the content from all content creators, but then applies fixes and improvements that are not submitted back upstream to the original authors, using the excuse that upstream should find and backport the fixes themselves.  This is specifically to use as a selling point against the official and 3rd party FlightGear content infrastructure.  Because of this positioning, the FGMEMBERS organization is unlike any other 3rd party infrastructure — it is not complementary to the FlightGear ecosystem but is rather competitive to it.

Why is syncing not possible?

Question: FGMEMBERS intends to sync all changes from FGAddon, why can’t FGAddon simply merge all the changes from FGMEMBERS so the repositories remain identical?

Answer:
There are three reasons for this.  Firstly, over time the repositories will diverge in a way that is impossible to reconcile (e.g. two different developers with different end goals modify the same aircraft model at the same time).  Secondly, such a merge would require a large, continuous amount of effort just to maintain a position that would exist without FGMEMBERS.  Thirdly, we have concerns over the attitude of FGMEMBERS to licensing and accepting almost all content, and are not prepared to legally risk the GPL “health” of FGAddon.

For many years it has always been that FGAddon and its predecessor infrastructure is the definitive place for the FlightGear models.  As part the FlightGear contribution workflow, the responsibility is on the content author to contribute to FGAddon when their work is ready for release.  Once the work is present in FGAddon, the author is then expected to maintain the aircraft in FGAddon.  This is how development has always been performed and it works well and everyone understands it.
To change this now so that it becomes the responsibility of someone else, other than the contributor making the changes is clearly an unworkable solution.  However the published procedure for adding or modifying FGAddon does not preclude contributions from anyone who is prepared to follow the submission rules and content guidelines.  So FGMEMBERS could, if they so wished, follow these procedures to ensure that FGAddon remains the core asset that is definitive and up-to-date.

Why not switch the core infrastructure to FGMEMBERS?

Question: Why can you not work with the FGMEMBERS team to create a single repository?

Answer:
Primarily this is not possible as it would require reopening a discussion that was ongoing for 5 years — and this approach is merely a different way of doing things that does not provide any real benefits to the long term goals of the project.

Why Subversion?

Question: Why do you use Subversion instead of my preferred version control system?

Answer:
Subversion was agreed upon during the discussions on the development mailing list as it provided most of the required facilities in a way that worked for the wider community.

Why have gatekeepers?

Question: Why does FGAddon have gatekeepers?

Answer:
The official policy[9] is designed to allow for easy access to FGAddon for contributors whilst maintaining quality and legal standards.  As the official FlightGear repository has obligations and legal liabilities, the gatekeepers are there to ensure these quality guidelines are met.  The gatekeepers are friendly and helpful — their role is to promote the development of aircraft while respecting the community rules and to guide new contributors; who themselves may gain, or already have, the experience to be a gatekeeper.

How do I contribute?

Question: How can I send improvements to FGAddon for inclusion into the official repository of aircraft?

Answer:
As detailed on the FGAddon wiki article, there are a number of steps.  Firstly the original aircraft authors should be contacted.  If this is not possible, then send an email stating your intentions to the FlightGear development mailing list or post a message on the forum.

Why should I contribute upstream?

Question: Why would I want to contribute to FGAddon when I could just hack away and publish my changes in a forked repository?

Answer:
Contribution to FGAddon guarantees the widest distribution of your work by including your work into the FlightGear project (your improvements will be available on the official download page and inside the launcher).  You are also contributing back and collaborating with the FlightGear project.  This is a proven method to ensure continued and long term availability of your improvements for years to come.  If an original aircraft developer is still active it is normally considered respectful to work with that author as it will often benefit everyone involved, rather than taking their work and competing against them.  Otherwise this will result in two versions that have different improvements, when the goal should be to all work together to provide the best models that collaboration can build.

Can I obtain commit access?

Question: Is it possible for me to obtain commit access to the FGAddon repository?

Answer:
You are encouraged to apply for commit privileges as soon as you feel that you meet the criteria and are ready to take on the responsibility[10].  If in doubt, send an email to the FlightGear development mailing list.

Is FGMEMBERS a 3rd party hangar?

Question: Are the FGMEMBERS aircraft repositories considered as a 3rd party hangar?

Answer: No.
As FGMEMBERS has aggregated all of the FlightGear assets, including FGData, FGAddon, TerraScenery, 3rd party hangars, and all other sources, the aircraft component of this system is not considered as a 3rd party hangar.  As it is a hostile fork, unlike the 3rd party hangars, it competes directly against the official FlightGear data assets and infrastructure as well as the 3rd party hangars.  It also competes for developer resources against the FlightGear project and 3rd party hangars.

Conclusion

We believe that the best path forwards for FlightGear is for the community to work together.  We recognise the importance of contributors and collaboration and positively encourage everyone to work together with the common goal of improving FlightGear in a positive way, and to be respectful, honest, trustworthy and fair.  Let’s get the word out and make sure that FGMEMBERS has to communicate with a well informed audience.

 

Helicopters in Flightgear

The Art of Hover Flight

While most Flightgear users seem to mainly use GA aircraft or airliners, the simulation of helicopters is not only possible but comes with a nice degree of realism. This makes learning to fly a helciopter quite a challenge, but also very educational.

Why not try it out?

Piloting a helicopter is also a nice opportunity to see the terrain in a different way, because usually the view downward is much less restricted than in aircraft cockpits – here a good graphics card to support all the hires terrain texturing and the various vegetation and building overlays that can be enabled really pays off. And of course you can land pretty much anywhere you like, airports are no longer a must, any flat patch of terrain will do. But there are also hundreds of helipads in the FG scenery, located on places like hospital rooftops or oil rigs.

Ready for takeoff? Let’s take a quick look at some helicopters FG has to offer.

Helicopter flight

If you’ve mastered flying normal aircraft and have the idea that helicopters can’t be so different, you’re likely wrong – helicopters are very different.

Normal aircraft are usually dynamically stable – if they feel a perturbation, they return to a stable attitude. Helicopters reach this condition only when they accelerate, but just after takeoff and before landing they move through the air slowly, and they’re in fact dynamically unstable – any perturbation needs to be countered quickly with the controls, or it will grow and the pilot will lose control.

Another thing that takes some time getting used to is that the body of a helicopter swings like a pendulum underneath the rotor. The pilot always needs to recognize when a motion is part of this oscillation and will dampen out on its own and when it is actually part of the flight dynamics.

Yet perhaps the hardest thing to master for beginners is the torque of the rotor. The rotating blades try to yank the helicopter around against their own motion, and only the action of the tail rotor prevents this – so pedals need to be used carefully to counter this effect.

So how is a helicopter controlled?

Unlike in an aircraft, the turbine RPM is usually not throttled. Rather, the angle of the main rotor blades is changed by the collective control- this provides upward/downward motion. The main rotor can be tilted by moving the stick, this provides a combination of forward and sideward motion. It is actually quite feasible to fly a helicopter sideward, or even backward if it is done slowly, only once the airstream becomes fast, the fuselage tries to align with the wind like for an aircraft. Finally, the pedals control the tail rotor action – they can be used both to stabilize the craft against the main rotor torque as well as swing the nose around into a new direction in hover flight.

The final important ingredient to understanding helicopter flight is the ground effect. If the air displaced by the main rotor can’t go anywhere quickly because there is terrain underneath, it forms a ‘cushion’ of air that keeps the helicopter afloat. The effectivity of this cushion decreases quickly with altitude, thus close to the ground the collective actually controls altitude rather than vertical speed. Setting the rotor to displace more air pushes the helicopter upward, but then the ground effect decreases, so the craft settles at a new altitude.

A helicopter is then taken off by hovering into the ground effect, then using the stick to induce a forward motion (which gradually causes more lift on the rotor blades), and only when it is faster than some minimum speed flown out of the ground effect region. Similarly, one can expect and anticipate the ground effect for a landing.

While all these effects are there for any helicopter, the degree to which they make themselves felt differ quite a lot, and so every craft has to be learned separately.

The Robinson R22

If you were to attend real helicopter flight training, the Robinson R22 is the type of helicopter you would most likely encounter – it’s a low cost craft, popular throughout the world as a trainer or utility helicopter. The R22 has a low inertia rotor system, and the control inputs are transmitted directly by rods without hydraulic assistance. This means that the controls have to be moved very gently to avoid overcorrecting, and overall the helicopter reacts rather finnicky. This does seem to make it a bad choice for a trainer, except the idea seems to be that if a flight student masters the R22, she won’t have any problems with a heavier helicopter.

The instrumentation is generally simple, giving the pilot an almost unhindered view through the windshield.

In Flightgear, the R22 definitely exhibits the characteristics of the original counterpart. There’s lots of torque which is difficult to compensate, and you need to work a lot for even a halfway decent hover flight. Also, bringing the R22 into level flight with a good trim is far from trivial.

The Alouette III

The Alouette III is an aging light utility helicopter, in service since 1960, mainly used by military forces around the world, used for tasks ranging from passenger transport to aerial ambulance and SAR. Compared with the R22, it is a much heavier machine and hence considerably less skittish on the controls.

In the Flightgear version, the startup and shutdown sequences are implemented and the instrument panel is largely functional. What takes a bit to get used to is that this helicopter has wheels rather than skids, which makes sometimes for a surprise when landing in sloped terrain.

The Sikorsky S-76C

As a medium-sized utility helicopter, the Sikorsky S-76 dating to the 1980s comes with quite a bit of modern avionics aboard. Two turbines pack a lot of power, and the craft also features a retractable gear for better cruise performance.

Unfortunately, the avionics of this helicopter is not fully implemented in FG, but it nevertheless is a nice classy craft to fly.

The Chinook CH-47

The mighty Chinook CH-47 is a heavy lifter used by the US Army since the 1960s, both for transport as well as for aerial assault purposes, inserting troops behind enemy lines.

Unlike any of the helicopters above, the craft features counter-rotating twin rotors which removes the need for a tail rotor. This (and the large mass) make the flight fairly stable and the helicopter feels a bit sluggish at the controls.

Unfortunately, many instruments are modeled in the panel but not actually working, which limits the experience somewhat.

The Eurocopter EC 130

A truly modern light utility helicopter, the Eurocopter EC 130 was introduced in 2001 and is in strong demand around the world. It comes with a modern avionics set and (for its weight) a fairly powerful engine.

In the simulation, the EC 130 is, hands down, one of the most stunning models with a photorealistic exterior utilizing pretty much every rendering effect available. Once in the cockpit, there is a detailed startup and shutdown procedure available that’s supported by the checklist system. In addition, many different configurations and pieces of equipment (such as external baskets or a serchlight) can be chosen. Once you try it, you’ll love it.

The Eurocopter EC 135

Introduced in 1996, the EC-135 is another modern light utility helicopter used for multiple purposes ranging from medical transport and SAR to sightseeing. Powered by two turbines, it packs even more horsepowers than the EC-130.

Both the interior and the exterior of this helicopter show in FG at photorealistic quality. The EC-135 is a truly remarkable piece of work, both in the flight characteristics and visually.

Curious?

Eager to try out helicopter flight now? While the R22 is what real flight students learn with, the craft is very hard to master without the helping hand of an instructor. Since you’re not paying for simulated damage or flight hours, you might as well start with a heavy machine such as the Chinook to get a feeling for the basics of helicopter flight without the complication of rotor torque, and then move on to a ‘nice’ machine like the Alouette III before tackling the really hard craft.

Don’t be discouraged by failures – you’ll probably crash the first dozen times before getting the ride off the ground properly, and it really takes a while to get the correct ‘feel’ for the controls such that good hover flight and precision landings are feasible. This is much harder than flying an airplane.

For a good introduction to the techniques of helicopter flight in FG, see the Flightgear Wiki.

Discover Alaska

Outback flying with the Twin Otter

If you’re looking for a challenge away from busy airports, IFR flight and traffic controllers try flying up in the North for a while. Remote dirt airstrips, spectacular scenery, challenging mountain flights, tricky navigation in rough weather – Alaska offers all of this and more.

In such a sparsely populated region, you need a special kind of plane – easy to maintain, with a short takeoff or landing distance and capable of taking a lot of punishment. Such as the Twin Otter.

Meet the plane

The de Havilland Canada DHC-6 Twin Otter is STOL-capable small passenger turboprop aircraft, ready to carry up to 19 people. The sturdy, non-retractable undercarriage, the short takeoff and the high rate of climb make the aircraft very suitable to serve small airstrips in remote and mountainous areas. In addition, Twin Otters can be fitted with wheels, floats or skies, allowing them to operate even off reinforced runways.

With a cruise speed of 150 kt, a service ceiling of 25.000 ft and a range of about 800 miles, the aircraft does not have the abilities of commercial jets, but its handling qualities more than make up for it.

The Flightgear version of the Twin Otter has a lot to offer – starting from a spectacular 3d cockpit over lots of simulated systems to detailed procedures. When starting in the plane, you find it in secured position, with external power connected.

Every flight starts with the pre-flight inspection, the tiedowns and pitot tube covers have to be removed, the wheels unblocked. Using Flightgear’s walker feature, you can literally get out of the plane and walk around, doing your pre-flight checklist.

Once you climb into the cockpit, you can then start the engines and switch to internal power. The plane makes excellent use of the checklist feature, with the ability to highlight every control that needs to be operated next, so you won’t get lost easily.

The cockpit artwork is simply great, close to photo-realistic, and there are lots of details to discover, from the way the windshield heater has a real function to ‘No Smoking’ signs for the passengers.

The flight dynamics is modeled using YaSim, which doesn’t make it overly realistic at the corners of the operational envelope, but the basics are all there and the simulation nicely captures the STOL and high climb rate of the plane. There’s no simulation of damage due to overstressing the plane done, but callouts of limit violations can be activated (and of course you can crash and destroy the plane).

If you’re in for a real challenge, start with a variant that has either floats or skies – if you have floats, you can actually select starting sites on the water (or get the option to re-position to a nearby site).

Mount Logan

A very nice bit of scenery is East of Valdez (PAVD) following the Bagley Ice Field towards the Seward Glacier at the foot of Mt. Logan, which towers a full 19,501 ft above sea level.

The Twin Otter will be able to take off from almost any small airfield, so we can explore this from Cape Yakataga (PACY). It’s going to be a cold flight, so remember to activate Pitot tube and propeller heaters, otherwise there’ll be nasty surprises later.

Fly north and start climbing over the first mountain ranges at about 10.000 ft – behind the peaks you’ll get your first visual of the Bagley ice field stretching in east-west direction.

Follow the glacier east until you see towering Mount Logan to your left, reaching up to almost 20.000 ft and opposite to it, slightly lower, Mount St. Elias. Then turn towards Mount Logan.

If you have skies equipped and dare to, you can try landing on the Bagley field or on one of Logan’s glaciers – it’s quite a challenge.

The Twin Otter reaches high enough to make the summit of Mount Logan, so start climbing again. If the visibility is good, you can see several other towering peaks over in Canada.

Turn back west and follow the glacier valleys branching north of Bagley field, forming the Logan glacier.

You’ll be rewarded by stunning views deep into ice-carved valleys.

Follow the Logan glacier valley till the ice disappears and mighty watercourses carry the meltwaters of the ice fields. We’re going to end the flight at Jakes Bar, which is a small dirt airstrip in the middle of nowhere. Like many small field in Alaska, it doesn’t come with a radio beacon, so you’ll have to find it by eye – it’s where a meltwater stream coming from the south merges with the water from Logan glacier.

There’s not much space here – but nothing the Twin Otter couldn’t handle.

Juneau and surroundings

Quite different but equally stunning scenery is found in the vicinity of Juneau airport (PAJN). Here the sea meets steep mountains and glaciers and fjords and islands dominate the scene. Equip your Twin Otter with floats to enjoy this best – you can start right in the water, for instance at Tenakee.

Admittedly starting the engines in the water is a bit ticky (expect to spin around while only one engine is running…), but water takeoffs and landings are really great fun (if the winds are not too strong – high surf can definitely ruin your day).

Once in the air, you can expect the flight dynamics to be somewhat different (the floats after all have different drag), but the Twin Otter has very high engine power, so it’s never a problem.

You can fly across forst-covered hills, majestic straits and explore remote bays, or fly over the Taku glacier north of Juneau – there’s plenty to see.

And the best part is – with floats you can land pretty much anywhere you like!

Again, maneuvering on the water can be a bit tricky, differential throttle on both engines, or even putting one engine into reverse thrust works best. And if you want to land on solid ground again, there’s still an operational gear attached to the floats – just don’t forget to extend it!

Save flying!

More reading

The Saab ‘Viggen’

Swedish Air Power

Background

The Saab JA-37 ‘Viggen’ (the name goes back to an old Swedish word and means ‘thunderbolt’) is a Swedish single seat all-weather interceptor aircraft variant. With it’s delta wings and the canard surfaces, it is a most iconic sight, and when the first prototype of the design was rolled out in 1967, it was considered one of the most advanced aircraft at the time.

The main design requirements were based on the notion that the aircraft would have to be operated from improvised airstrips, thus both the ability to utilize short (and, given Sweden’s climate, possibly frozen or snowy) runways and easy maintenance were considered very important. In fact, the ‘Viggen’ was constructed to cope with just 500 m of runway, yet to reach Mach 1 at sea level and Mach 2 at high altitude.

This is made possible by a powerful Volvo RM8 turbofan engine augmented with both an afterburner and a thrust reverser – the latter being fairly unique among fighter aircraft (only the Panavia Tornado is similarly equipped).

The aircraft simulated in Flightgear includes the JA-37 as well as the AJ-37 and the AJS-37 variants.

First impressions

While the 3d cockpit is not the kind of photorealistic work to create an immediate ‘Wow!’, there’s also nothing jarring or severely amiss. Faithful to the original, all gauges on the main panel show metric units and many labels are in Swedish, but if Flightgear’s tooltip function is activated, just hovering with the mouse over a gauge explains in English what it is and provides the value in imperial units. The HUD can likewise be switched from metric to imperial units.

Away from the front panel, switches and warning lights are typically labeled in English to help the international user, and also the various audi-warnings produced by the aircraft are in English.

From the outside, the 3d model is rather compelling, and the plane comes with nice effects implemented – such as Mach shockwave and afterburner flame light illuminating the fuselage – in addition to lots of livery options.

The aircraft starts up with engines off, but if you want to get into the air quickly, there’s a quickstart function provided.

The ‘Viggen’ in flight

Once in the air, you can enjoy highly detailed flight dynamics. There’s tons of windtunnel and engine performance data worked into the FDM, including the behavior at very high alpha, so there’s realistic departure from controlled flight, including stalls and spins modeled.

The attention to detail shows, it’s one of the planes which just feel real. For instance, when approaching the transonic region or a high alpha regime, the plane starts to shake slightly.

Generally the ‘Viggen’ is easy to handle and one can quickly get the hang of flying the approach and landing. Faithful to the original, the plane can be brought onto the runway at fairly low alpha without a pronounced flare, and using the thrust reverser after touchdown is great fun.

Beware though – damage is modeled, and pulling too high g or smashing onto the runway will break the plane!

Avionics

Most interaction of the pilot with the avionics is probably through the HUD. Generally, the plane tries to be helpful and allows the pilot to focus on flying. There are four main HUD modes (takeoff, flight, tactical and landing) and with the exception of the last, they switch automatically as needed.

The plane also automatically tries to tune into nearby ILS frequencies, so when you approach a runway equipped with ILS, not only the airport designation but also ILS symbology will magically appear.

There’s lots of other small details to discover in the way the HUD works and interfaces with other systems aboard.

Procedures

With close to a hundred working switches in the cockpit, the pilot can go through fairly realistic startup and shutdown procedures. The ‘Viggen’ makes good use of the Flightgear checklist functionality, with the option to highlight the control that should be operated next, or to automatically complete an item.

As an added surprise, the state the airplane is in when starting up is somewhat randomized in that sometimes a switch may already be flicked, sometimes not – a good way to keep the user’s attention on the checklist!

Systems

You probably won’t find too many planes on the Flightgear repository which have the systems modeled down to a working air-condition unit – but there it is. If you allow the cabin air to get too cold or too warm, not only will you see on-screen messages that you’re getting uncomfortable, but also the canopy will frost or fog, impairing your view.

There’s lots of other things modeled, among them a well-tuned autopilot, automatic control of flaps, an electrical system in which you can drain the battery and will see lights dim in response and last but not least a full range of working weapons systems, ranging from the cannon to un-guided air-ground missiles.

Summary

If your definition of ‘realism’ in a flight simulator goes beyond photo-realistic 3d modeling and you can get excited about very detailed flight dynamics and systems modeling, the ‘Viggen’ is a plane for you, and you can well spend a few hours exploring all the little details that are lovingly worked into the simulation, from a large range of sounds via the simulation of different damage modes to the way the radar interacts with MP or AI planes and can get blocked by the terrain.

Well-implemented checklists and tooltips as well as the quickstart and shutdown functions make it easy to get used to operating the plane – give it a try!

A preview of features for the ‘Barcelona’ release

Join us for a short overview of what the next Flightgear release within the new automated three-month release cycle will bring!

FG goes to Spain

The most visible change to first-time users will be the change of the default airport. For the future, we plan to name every release after the default airport, and thus while the last release has been ‘San Francisco’ (or 2016.1), the next release (2016.2) will go to the beautiful city of Barcelona. Look forward to some impressive scenery and all-new VRF tutorials and suggested flights in the region!

Improvements to scenery

Improvements to scenery rendering are being added on all fronts. Supported by shader developments within the Atmospheric Light Scattering (ALS) framework, runways and airport keep can now be rendered in multiple ways in high resolution, and this has been implemented for different regions all across the world – including the new default airport of Barcelona ‘El Prat’.

Places across the world continue to be populated with 3d models, for instance check out the progress on London Heathrow!

See the FG world through an infrared camera

ALS now includes a whole suite of filtering techniques, which allow to select brightness and gamma-correction in-sim (i.e. affecting screen pixel color values visible in screenshots, not only the appearance on the monitor). Part of this filter suite is also a night vision mode and, possibly most exciting, and infrared camera mode. The IR vision shows contrasts based on relative temperatures, with the daily temperature cycles of the environment modeled by the weather system.

New and improved aircraft

The Piper J3 Cub, a long-time resident of the aircraft repository, has now been fitted with a brand-new JSBSim FDM as well as support for high-end effects, including interior shadow mapping. Water takeoff and landing by selecting floats rather than wheels is also being developerd.

The Boeing 757 has been updated with new versions and winglets dependent on selected airline livery. The Extra 500 received multiple upgrades and now includes a simulation of icing effects and a sophisticated failure system.

Behind the scenes changes

Multiple less visible changes have also been introduced:

* the handling of shared scenery models has now been much streamlined – shared models now reside in a single location and are most easily obtained and updated via the in-sim terrasync option. Alternatively a (daily updated) collection can be obtained here.

* FG now supports the generation and application of GPU specific rendering setting profiles. The idea is to make the experience for first-time users more pleasant by pre-setting the rendering quality level to something which leads to a good experience for the selected graphics card.

* Currently, support for pre-defining aircraft states (such as ‘cold and dark’ or ‘in air’ or ‘cruise’) is formalized and introduced, with the aim of routinely allowing in-air initialization of complex aircraft with all systems set correctly.

Stay tuned as we fly towards our next release!

FlightGear 2016.1 Released

The FlightGear development team is delighted to announce the v2016.1 “San Francisco” release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include an integrated launcher that includes the ability to download aircraft, a reduction in the installation package size, performance improvements and many rendering improvements.
Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

Qt_launcher_for_FlightGear_3.5_on_Windows_7

FlightGear features more than 500 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky and weather modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

Download FlightGear v2016.1 for free from FlightGear.org/download

FlightGear – Fly Free!

Please continue to our wiki article for all the specific details and new features in the release.

An experience like no other…

The Space Shuttle in Flightgear

After Vostok-1 and the X-15, Flightgear now adds the third craft capable of reaching space – the Space Shuttle.

Thanks to the fact that virtually all material NASA has on the Shuttle is in public domain, the simulated flight dynamics and the resulting capabilities of the Shuttle are based on a large body of NASA wind-tunnel and actual mission data and hence highly realistic. For instance, the response to aerosurfaces is not only simulates as a function of surface deflection and dynamical pressure, but also as function of Mach number, AoA and the deflection of other surfaces, giving full account of the changing dynamics during entry, cross couplings between controls and non-linearities in the control response.

The Shuttle is under heavy development – the systems and avionics simulation is not quite on the same level of sophistication as the aerodynamics, but even in its present state, the full profile of a mission can be flown, including realistic entry guidance and support for abort modes such as RTLS (return to launch site).

Even under rather off-nominal conditions such as an RTLS, the simulated Shuttle behaves as described in the crew operations manual, i.e. procedures can literally be flown ‘by the book’.

Launch

“The launch looks kind of slow to an observer, but when you’re inside, there ain’t nothing slow about it. I mean, you feel all seven million pounds of that thrust. It’s like this giant hand grabs the orbiter and throws it into space.”

“It’s like being strapped to the front of a freight train going down the track at a hundred mph. You feel all that mass and force behind you.”

“Right before the main engines cut off, you feel like you have a bear sitting on you. It’s three g’s. Then, at the moment of engine cut-off, you go from three to zero g’s instantaneously. The bear jumps off your chest, and you see the seat belts floating upward, which is kind of cool. Then, a couple of seconds later, you hear this big clang and the fuel tank comes off.”

For a bit more than eight minutes, the Space Shuttle is a true rocket ship, capable of a maximal acceleration above three g and highly maneuverable by thrust vectoring. During that time, it needs to reach a stable orbit.

What’s little known is that aerodynamical stress is in fact much stronger during ascent than during entry – the dynamical pressure peaks at almost twice the value reached during entry about thirty seconds into the flight. This makes launch a busy phase – after liftoff from the pad, the Shuttle needs to be rolled to a launch course, than steered safely on a steep ascent path through the lower atmosphere before it finally levels off and races to orbital speed outside the atmosphere.

The simulation takes a lot of the structural limits of the Shuttle into account, so it’s quite important to steer the ascent trajectory through a safe region in order to avoid a catastrophic failure followed by an explosion of the external tank.

Arrival in orbit

“As a commander, you try to figure out how much extra time you need to add to the schedule, based on how many rookies you’ve got, how they’re doing and so on. But when you stick your head down in the mid-deck for the first time, you never know how your crew will be doing Sometimes guys are semi-Velcro’ed to the wall, throwing up, while the folks you least expected to be heroes are just chugging along, executing the plan.”

We can’t really simulate the effect of weightlessness for the user in FG, but there’s a lot that can be simulated in space.

Once the main engines cut off, the flight characteristics of the Shuttle change drastically – it becomes a sluggish object which can just be nudged into slightly different attitudes or somewhat different orbits. The Shuttle doesn’t need to be flown any more – once in orbit, it will stay there for a while even if you do nothing. Instead, it needs to be operated – its systems need to be activated for the space environment.

The simulation includes ready-for-orbit procedures like the propellant dump, umbilical door and start tracker door operation, payload bay door operation, Ku-band antenna deployment and pointing and thermal management. Also, the propellant flow of the orbital engines can be fully controlled, allowing procedures such as RCS to RCS, OMS to RCS or OMS to OMS crossfeed.

There is in fact a complete simulation of the thermal environment running, including radiation fluxes from Sun and Earth, heat radiated into space, heat conduction between different parts of the Shuttle, equipment as sources of additional heat and flash evaporators, spray boilers and radiator as heat sinks connected to the freon cooling loop. In order to keep the Shuttle operational, you need to do heat management by operating the radiator and bringing the Shuttle into a good attitude relative to the Sun. Also, heating elements need to be used to keep thrusters from freezing up.

Orbital operations

“For a pilot, the response of the Shuttle is totally different from that of an airplane. You pulse the jets, then you wait for a response. It takes a while for the input to take effect. Say you want to move directly above the Space Station. You’d do some ‘up’ pulses with your hand controller, as well as some pitch change pulses to rotate the vehicle as you move up. You do a set number of pulses, predicting what the response will be. Then you wait 45 seconds or so to see what happens. Then you correct it. It’s not agressive control, it’s patient, timely inputs.”

The flight characteristics of the Shuttle changes drastically from mission phase to mission phase. Over the course of a mission, controls change from thrust vectoring of main engines and boosters via the reaction control system (RCS) thrusters and thrust vectoring of the orbital maneuvering system (OMS) engines to airfoils for the final glide through the atmosphere.

A host of digital autopilots (DAPs) connects the control inputs with the various ways to control the Shuttle. In orbit, they are augmented by extra functions – there’s inertial and local horizon attitude holding modes, rate controlled moves, pulsed modes, the low thrust Vernier engines for fine attitude control – and practically all aspects of the DAPs are configurable during the mission.

The need to support all these different modes makes the flight control system of the Shuttle easily the most complex of all Flightgear aircraft.

“If you position your body to face away from the windows, and put your arms out as if you were flying with the Earth above your head, you feel like you’re swimming underneath the Earth.”

Often the question comes up whether Flightgear as a flight simulation is any good in simulating spaceflight. It turns out that the flight dynamics solver underlying the Space Shuttle, JSBSim, is quite capable of orbital dynamics, in fact it has been benchmarked against several test cases in a 6-DoF simulation code comparison by NASA.

JSBSim simulates Earth not as a point mass but as a true realistic mass distribution, and there’s even a simulation of differential gravity – the distance from Earth to the upper edge of the Shuttle is slightly larger than the distance to the lower edge, and that corresponds to a tiny residual force which acts like a torque on the Shuttle.

So never believe for a moment that the dynamics of the Shuttle in orbit is simplified or arcade-like because FG is a flightsim – it is not – it is in fact realistic down to effects you never really thought of. JSBSim is not a game engine, it is a professional simulation code that just happens to be OpenSource.

The Shuttle includes a detailed simulation of the remote manipulator system (RMS) arm operation – the arm can be driven in various modes, grab a payload from the bay and release it into space after it has been unlatched.

In addition, there is a simple spacewalk view which allows to step out of the Shuttle and float around, using small thrusters, in essence simulating the operation of a manned maneuvering unit.

Earth from Space

“Make a memory somewhere during the mission, put your nose up a window and look out and make a memory. And don’t take a picture of it, because you would be disappointed when you get home. Plant it in your brain and don’t ever let it go, and you’ll have it with you always, and nobody can take it from you.”

The default Flightgear terrain rendering engine is not optimal for views from high altitude – in fact, it will be hard-pressed to show anything from a 300 mile orbit. Instead, FG comes with the Earthview orbital rendering engine which can be used from some 80.000 ft and above and displays the planet as a textured sphere. Earthview is fairly sophisticated and renders even correctly placed cloud shadows if a cloud sphere is used.

However, in a default FG installation, only relatively low resolution textures are shipped (which can be procedurally enhanced) – not really enough for photorealistic impressions. More detailed textures can be obtained from the NASA visible Earth page – for the visuals used here, the maximum resolution available has been used – individual texture sheets are 16384×16384 pixels large. At this resolution and converted to dds to allow fast loading, the Earth textures are about 2 GB – which would triple the size of the FG repository – which is the reason they’re not available as default option.

Also the atmosphere contributes much to the view from orbit. Currently only one of the three rendering schemes available in Flightgear (Atmospheric Light Scattering) generates compelling visuals of the upper atmosphere, the other two (Rembrandt and default) do no.

Due to the lack of an atmosphere, lighting in space is fairly hard – there is little light on surfaces not facing the sun. Dedicated GLSL shaders specifically written for space flight manage this transition from the lower to the upper atmosphere.

The cockpit

There’s (literally) hundreds of switches and gauges in the cockpit of the Space Shuttle. At present, only a small fraction of them is fully functional and animated, although many are already part of the internal systems simulation. The following screenshots are intended to provide an impression of what final result we’re aiming at.

The data processing system (DPS) of the Shuttle is controlled via keypads on the central console. Extra switches are used to select which screen a given keypad is currently talking to.

With all screens in the cockpit used, the Space Shuttle can show an unbelievable amount of information at the same time.

At night, the simulation includes the backlighting of instruments, casting a diffuse glow onto the cockpit interior.

Avionics

The data processing system (DPS) of the Space Shuttle was groundbreaking when it was introduced, but looks definitely odd when compared with modern computers. The memory of the computers actually is not large enough to hold the programs for all mission phases at once, hence there is the need to transit between different operational sequences during a mission.

Interaction with the spacecraft is simulated as in reality. It requires to type short instructions sequences such as OPS 201 PRO or ITEM 7 + 4.1 EXEC on a keypad which triggers the appropriate functions.

Since the avionics is fairly complex, some learning curve is required to operate it properly, but there are multiple rewards for the patient user. The Flightgear Space Shuttle is capable of numerous automatically controlled operations – it is possible to do an automatic orbital insertion or deorbit burn by entering PEG-7 targets, there are inertial pointing routines, tracking routines to keep the Shuttle pointed towards a certain celestial body or towards Earth or automatic thermal management routines.

Using the systems management software, one can in detail follow the operations of APUs, the RCS and OMS engines or the payload bay doors, override failed hardware switches, initiate emergency fuel dumps, re-configure the digital autopilots or control the antenna.

Finally, the avionics provides the original guidance and navigation tools for atmospheric entry, in particular the ranging during the aerobraking phase and the final TAEM phase.

Entry

“When you hit the top of the atmosphere, you begin to really slow down, and that’s when the heat rises and you ionize the atmosphere. It’s like being inside a neon light bulb, with a pinkish-purplish pulsing light.”

“What you see out of the overhead window seems like disorganized fire, but it’s not when you look at the way the shockwaves organize the flame. There’s so much flame you cannot believe you are not consumed instantly.”

From a piloting point of view, the entry phase is by far the most interesting. Here, the transition from a spacecraft on a ballistic trajectory in vacuum to an aircraft that glides through the lower atmosphere towards the runway takes place. While at the beginning of the entry, the Shuttle is completely controlled by RCS thrusters, in the end it is fully flown by airfoils like a plane. In-between is a hypersonic phase in which the Shuttle has aerodynamical lift and flies, but is controlled very differently from an aircraft.

As in reality, the simulation provides automatic helpers for trajectory management. In particular, an AoA auto-hold can be activated to help keeping the Shuttle in a thermally safe regime, and the rate-controlled DAP makes the Shuttle respond crisply and controlled to each input, regardless of whether in near-vacuum, in hypersonic descent at Mach 16 or in the lower atmosphere at Mach 2. In fact, while the Shuttle is yaw unstable and needs to be constantly nudged back to zero sideslip, you’d be hard-pressed to observe any trace of this.

In fact, the controls feel almost arcade-like. However, if you’re up for a challenge, you can use a different DAP (for purely educational purpose) which lets you control airfoils directly – and then you’ll feel directly just how much the conditions change from Mach 24 down to Mach 2.

Coming home

“I’m sitting in a chair, my forearms on my knees, and I reached down to take my shoes off. But before I did, I released my cup without giving it a thought, because I expected it to float. And of course, as soon as I did, it fell right to the floor.”

Landing the Shuttle is quite different from landing an airliner. With its hypersonic outline, the Shuttle has the aerodynamics of a brick. It plummets down with 10.000 ft/min, has a glidepath on final of 15-17 degrees and aims for a touchdown at 214 kt – quite a bit higher than for most aircraft.

Yet, for these final few minutes, it is possible to exploit Flightgear’s strength to the full – try any weather or visibility and see whether you can still make the approach. But always remember – there’s just one chance.

And one thing is certain – you’ll never forget your first descebt from orbit right down onto a runway.

Getting the Shuttle

In order to run the Shuttle, you’ll need at least the 3.6 release candidate or a higher version of FG. There are two options to download the Space Shuttle:

A flight-tested version is kept on the FGAddon repository. For this version, someone has made sure that all mission phases can in fact be flown without triggering a bug. This version typically lags behind the current development.

The current development version is kept in its own repository. It contains all the most recent features but is not flight-tested, i.e. simply may not work as expected.

The Shuttle will also be part of the next FG stable release – currently forseen in late winter/early spring 2016.

Get involved

If you’re interested in contributing to one of the most fascinating spacecraft, you’re more than welcome. Ranging from texture art to 3d modeling of payloads and site-specific buildings (think Kennedy Space Center), from data-gathering to refining the aerodynamics and avionics, there’s lots of things that can be done.

You can always get in touch via the Shuttle’s forum thread – or via the devel repository.

Final words

All quotes describing the Space Shuttle experience are from the astronauts, taken from the book Space Shuttle: The First 20 Years (DK Publishing).

More information on the Flightgear Space Shuttle:

* FG Wiki page for the Shuttle
* FG Space Shuttle project overview including a gallery and more technical information
* Development repository on SourceForge
* The crew operations manual – read this to get most of the experience

The new Cessna 172p

by Gilberto Agostinho

FlightGear’s default aircraft, the Cessna 172P, went through a major makeover. This post will show some of these improvements.

The aircraft exterior is now much more detailed, with new higher resolution liveries (as well as several cockpit and interior themes).

The cockpit is now fully textured and fully functional. All switches, buttons and levers are operable (try pulling out some circuit breakers!). When using ALS, the new interior shadow effect is very immersive.

There are six variants avilable now (default, two bush tire variants, amphibian, pontoon and skis) as well as two types of engine (160 HP and 180 HP). Below, the amphibian variant at San Francisco bay.

The cockpit has now a glass effect, making the windows reflective. The instruments can also be illuminated if the sunlight is getting weak.

If the conditions are just right, the cockpit glass will get foggy or display some frost, as in the image below. To control that, use the air vent and air heat levers (as well as cracking the windows!).

Pre-flight inspection has now been implemented. It’s possible now to add and remove tie-downs, wheel chocks and the pitot tube cover. On top of that, one has to keep an eye for the oil level and possible fuel contamination. The plane has a tutorial explaining how all these new features work.

The aircraft can now get damaged. Land too hard and the front wheel will collapse; dive and pull the yoke at once and the wings will break. But there is no need to worry if your plane gets damaged: a repair button has been added to the aircraft menu.

Regarding sounds, some major improvements have been done: these include not only new cockpit sounds (switches, levers) but also environment sounds: water sounds for the amphibian and pontoon variants, new wind, rain and thunder sounds for all of them.

The aircraft comes with two flashlights (one white, one red) for night flights, allowing one to start the plane from cold and dark regardless of the amount of sunlight.

Among other improvements, we have now a better flight dynamics model, with better stall and spin behaviour, and new hydrodynamics for the float variations.

If you run the FG development version and want to track the latest developments for this plane, you can find the development repository here. There is also a forum thread for discussion and feedback.

What’s the Flightgear news?

Changes of various kinds affect FG – it seems this year more than in others. Please read here an overview.

Whatever happened to the 3.6 release?

The simple truth is – it didn’t work out. In the end, the release team had personal constraints, got as far as producing a release candidate but then the efforts stalled. Flightgear is developed by human beings, and sometimes things don’t go the way we’d like them to.

Ideally this should have been communicated earlier – we’re sorry for this, the final decision not to have a 3.6 release was made not so long ago.

At this point, let me take the opportunity to point out the links to the automated builds where you can find the (as we now know rather stable) 3.6 release candidate and an automated nightly build of the FG development version.

The matching aircraft collection can be obtained from the repository following these instructions.

What’s the future?

At this point, we’re not sure whether there will be a regular 3.8 release. Rather, the idea which will be tried is a series of more automated stable releases – about four per year. We hope that this will stretch bug reporting by the general audience from the current one-week period between release candidate and stable (which makes it very hard to act in time) over a wider period, giving us the opportunity to respond better. At the same time, it will decrease the waiting period for the next stable. Time will tell whether this works better.

In addition, there are multiple changes behind the scenes having to do with the server infrastructure for the FG scenery. Ideally these would not affect the end user, but they take time and effort nevertheless.

Development on the other side did not stop – we keep making FG more interesting.

More impressive weather

The weather system has received an update to simulate lightning strikes during thunderstorms. Each lightning strike will not only trigger a visible bolt, but also (in the Atmospheric Light Scattering (ALS) framework) at night illuminate the clouds in the vicinity for a split second. In addition, the position is registered in FG, allowing aircraft modelers to include ambient thunder sounds with the correct delay – this has for instance been done for the C-172p. Encountering a T-storm at night will be memorable now!

Improvements to aircraft interior rendering

The ALS framework offers a host of new options for aircraft developers, for instance a quick option to render panel backlighting using the so-called implicit lightmap technique, irradiance mappings giving a more faithful impression from where indirect light can fall into the cabin and the option to show reflections of the lit cockpit panels in the windows at night.

A fire-breathing dragon (and other impressive aircraft)

Among the most interesting aircraft to be added to the repository is the dragon. Demonstrating the versatility of FG, this reptile doesn’t fly on magic (like the Santa and his reindeer do, if you know the model…), instead it uses the aerodynamical data from attempts to reconstruct the flight dynamics of a Pterosaur. Let it slowly climb with mighty wingbeats, soar thermals to rise to high altitudes or swoop down in a steep dive – the dragon sure is fun to fly and at the same time instructive.

Substantial updates also have been done for other aircraft which have been under heavy development: Sounds and pre-flight inspection simulation of the C-172p have been improved. The F-14A variant has been added, making use of all recent rendering improvements and including a simulation of compressor stall. Lots of work have also gone into making the F-15 yet better – it now offers C and D variant, operational weapons and radar, detailed sound and simulation of hydraulical, electrical and ECS pressurization system. The Space Shuttle is now well on the way towards a photorealistic 3d cockpit. Substantial work has been done on the avionics, implementing automatic tracking and pointing routines and a realistic procedure to command OMS orbital insertion and de-orbit burns, as well as one of the most sophisticated failure meanagement simulations in FG.

Improvements to scenery rendering

The ALS rendering framework has added effects for improved rendering of runways. Paved runways are now shown with skid-marks whereas unpaved runways can be rendered with a multitude of materials, smoothly blending the runway into the surrounding airport green.

New terrain textures

The regional scenery texture project is progressing substantially – we have new runway textures, dedicated industrial and port textures as well as detailed customized definitions for South America, Africa, the Middle East and South Asia).

Behind the scenes work

Less visually, there is ongoing development on various fronts. The out of window GUI Phi continues to be expanded, providing support e.g. for an instructor station. Using Qt5, a common launcher for all OS is being developed which is expected to ultimately grow into a new in-window GUI option. Finally, the HLA effort aims at utilizing multiple CPUs better by running various subsystems in dedicated threads outside the FG main loop. Currently, only a very limited AI scenario can be run in this mode, but ultimately it is expected to provide improved framerate where poor CPU utilization is the bottleneck.

We hope to be back soon with details on the new release process.