FlightGear Newsletter March 2014: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎Random Buildings: http://forum.flightgear.org/viewtopic.php?f=47&t=22273&hilit=)
m (Switch to the {{forum link}} template for all forum links.)
 
(28 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{newsletter}}
{{newsletter}}
{{TOC_right|limit=2}}
{{TOC_right|limit=2}}


{{Newsletter being written}}
== Development news ==
== Development news ==
Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: [[Next Changelog]].
 
=== TerraGear developers looking for your help ===
The [[TerraGear]] maintainers are looking for volunteers to help with development on the next world scenery project.  If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance.  See the plan at [[World Scenery 3.0 roadmap]]. In addition, as part of working on an experimental [[TerraGear scenery build server]], we're currently looking for people able to offer hosting for testing purposes.
 
=== FGPlot goes OOP ===
[[File:FGplot2NG.jpg|thumb]]
 
kuifje09 has finished porting his original [[FGPlot]] work (originally using PUI/XML dialogs) to use just [[Canvas]] now. In addition, the FGPlot code base has now been heavily refactored and modularized, introducing additional classes and separate files for each modules. In addition, FGPlot has now been sufficiently generalised to be also usable from other Nasal scripts. We are currently in the process of reviewing everything to hopefully ensure that this can be committed in time for the upcoming 3.2 release.
 
To learn more, continue reading at {{forum link|t=22422|text=the forum topic}}
 
=== Installing TerraGear in 10 seconds on Linux ===
 
[[File:TerraGear-hgtchop-VM.png|thumb|TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages]]
 
As part of working on a long-standing feature request, namely having a central shared [[TerraGear scenery build server]], saiarcot895 has created Linux packages for Debian/Ubuntu (deb/ppa) to install precompiled TerraGear binaries. This now greatly simplifies installing TerraGear, because people no longer need to manually set up a complete Linux build environment and all [[SimGear]]/TerraGear dependencies. Everything is now done in an automated fashion.
 
Next, we're hoping to use this to install TerraGear on a public server for which people can ask for remote shell access (SSH). People interested in exploring this, should be  getting in touch via the forum or the wiki.
 
Obviously, users will still need to be familiar with TerraGear, but they may benefit from reduced bandwidth restrictions and/or more horsepower in comparison to running TerraGear locally (e.g. one user offered to contribute hosting on a 32gb RAM and 8-core server). So this could be a great opportunity for people to run scripted/unattended jobs, without having to go through the hassle of downloading/building/installing and configuring TerraGear.
But so far, being familiar with TerraGear and Linux is going to be a prerequisite still.
 
Once that is working, we'll investigate making the setup reproducible by using TurnKeyLinux. Once we have a working TKL distro, we can install a full TG setup in just a few minutes by downloading an ISO file and installing it in a VM (VMWare/VirtualBox). This would basically allow people to easily download/install TerraGear locally, either installed next to their OS, or as a virtual machine.
 
The long term idea is to hook up [[TerraGear GUI]] to it, so that the GUI front-end talks to TerraGear across SSH.
 
This is currently still a use-case for which TG wasn't designed for, and the TG developers mentioned already on the forums that there may be some roadblocks ahead, so everything here is still highly experimental. But ultimately we hope to provide a front-end to a Linux-based TerraGear VM, either by reusing TerraGear GUI or by coming up with a custom web-based front-end (please get in touch if  you can help with this!).
 
If you're interested in helping or learning more, please get in touch via the forum or via [[TerraGear scenery build server]].
 
===Modified JSBSim search paths ===
AndersG has changed the search paths for [[JSBSim]] engines, propellers and systems in FlightGear to make it possible to have engines, propeller and system files shared by several aircraft stored in one place instead of keeping copies below each aircraft directory.
 
The change adds <tt>[[$FG_ROOT]]/Aircraft/Generic/JSBSim/{Engines,Systems}</tt> to the JSBSim engine, propeller and system search paths.
 
JSBSim searches <aircraft_dir>/Engines and <aircraft_dir>/Systems for the requested files before looking in the shared directories. This is consistent with how JSBSim works as a standalone program and should not cause any existing aircraft to load a different file than before.


=== Reset & Reinit ===
=== Reset & Reinit ===
Over the next few days James is going to start switching over the reset system to use the new code. The following changes will happen, in order:
James started switching over the reset system to use the new code. The following changes will happen, in order:


* places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally.  
* places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally.  
 
* the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let James know)
* the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let me know)
* the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used
* the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used
* Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)
* Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)


James is not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file.  
James is not expecting any build failures since the code is already in Git, but he would ask that any bug-reports are only made /after/ wiping your autosave XML file.  


Continue reading at [[Reset & re-init]]...
Continue reading at [[Reset & re-init]]...


=== built-in httpd updated ===
=== Built-in httpd updated ===
While working on the new radio/atis implementation, Torsten rediscovered the internal httpd (aka webserver) to browse the property tree.
While working on the new radio/ATIS implementation, Torsten rediscovered the internal httpd (aka webserver) to browse the [[property tree]]. It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal property browser and navigate to the locations after each sim restart.  
It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal  
property browser and navigate to the locations after each sim restart.  


After a while, Torsten got disappointed by the functionality and the look&feel of the http property-browser, so he had a look at the code to see if it  
After a while, Torsten got disappointed by the functionality and the look&feel of the http property-browser, so he had a look at the code to see if it could be improved, he quickly realized, that the implementation was simple but not scalable, so he looked for something allready available on the GPL market.
could be improved, he quickly realized, that the implementation was simple but not scalable, so he looked for something allready available on  
the GPL market.


And he found Mongoose as a well maintained, feature rich and yet simple  implementation of a web server and started to embedd that into FlightGear.
And he found Mongoose as a well maintained, feature rich and yet simple  implementation of a web server and started to embed that into FlightGear.


What is ready so far and pushed to next is:
What is ready so far and pushed to next is:
* A single threaded httpd running in the main loop (should probably get its own thread soon)
* A single threaded httpd running in the main loop (should probably get its own thread soon)
* Running as a replacement for the old httpd
* Running as a replacement for the old httpd
* Serving FGDATA/Docs as the document root
* Serving <tt>[[$FG_ROOT]]/Docs</tt> as the document root
* Serving the uri /props/ as a replacement for the old property browser  (improved functionality, improved l&f, styling via css)
* Serving the uri /props/ as a replacement for the old property browser  (improved functionality, improved l&f, styling via css)
* Serving the uri /run.cgi as a replacement for the old interface to run fg_commands
* Serving the uri /run.cgi as a replacement for the old interface to run fg_commands
Line 43: Line 71:


If you want to test the new functions, go to:
If you want to test the new functions, go to:
* http://localhost:<httpd-port>/  for FGDATA/Docs
* <nowiki>http://localhost:<httpd-port>/</nowiki>   for <tt>[[$FG_ROOT]]/Docs</tt>
* http://localhost:<httpd-port>/props/  for the internal property browser
* <nowiki>http://localhost:<httpd-port>/props/</nowiki>   for the internal property browser
* http://localhost:<httpd-port>/json/some/property/name/or/path  for the internal property browser
* <nowiki>http://localhost:<httpd-port>/json/some/property/name/or/path</nowiki>   for the internal property browser
* http://localhost:<httpd-port>/run.cgi?value=pause  to pause/unpause the simulation
* <nowiki>http://localhost:<httpd-port>/run.cgi?value=pause</nowiki>   to pause/unpause the simulation


Please mind the trailing slash for /props/ and /json/ (no, it's not  bug-free yet.)
Please mind the trailing slash for /props/ and /json/ (no, it's not  bug-free yet.)


Torsten has just pushed a litte quick-and-dirty example to fgdata. If you have a recent build from git/next, start fgfs with --httpd=8080 and  
Torsten has pushed a litte quick-and-dirty example to fgdata. If you have a recent build from git/next, start FlightGear with --httpd=8080 and point your browser at http://localhost:8080/gui/radio.html You need to be online to see the goodies as the jQuery js is loaded from code.jquery.com and not (yet) pushed to fgdata. The updates every five seconds and does not write back to FlightGear yet.
point your browser at http://localhost:8080/gui/radio.html
 
You need to be online to see the goodies as the jQuery js is loaded from code.jquery.com and not (yet) pushed to fgdata.
If you can't run the latest codebase, check [https://www.dropbox.com/s/98ejva4n4m38po1/HTMLRadioSettings.jpg this screenshot]
The updates every five seconds and does not write back to fg yet.
 
=== New built-in moving map ===
[[File:Browsermap-2.jpg|300px|right|Central Europe with Navdata and Weather Layers]]
When starting FlightGear with the internal web server enabled (--httpd=8080), a new moving map application is accessible for those with a working internet connection and state-of-the-art web browser. http://localhost:8080/gui/map opens an interactive map covering the entire world, enriched with FlightGear navigation data and live weather information. An aircraft symbol is showing the current position of the simulated FlightGear aircraft, also indicating its heading and altitude. The position information is sent through a websocket in real-time without the need for polling the FlightGear web server. The update rate of the map is currently throttled to 1Hz but refresh frequencies up to 20Hz have been successfully tested. The map can follow the aircraft's position or may be panned freely around the world, still tracking the planes position on the map.
 
[[File:Browsermap-3.jpg|300px|right|Around Hamburg (EDDH) with LOC courses]]
 
Three base layers currently exist: [[OpenStreetMap]], Mapquest road and Mapquest satellite. Overlays for the FlightGear navdata, precipitation and sea level pressure isobares from openweather.org may be added in any combination. The level of detail for the navigation data varies with the zoom level. To keep the load on the FlightGear instance low, Navigation data will only be displayed up to a radius of 250NM around the maps center. In detailed zoom levels, all airports (including runways), navigation aids, localizer courses of the displayed area will show up after a short delay. A click on a marker brings up a popup with detailed information about the item like name, frequency, runway length etc.
 
[[File:Browsermap-4.jpg|300px|right|At GA Parking EDDH with popup for ALSTER DME]]
 
Several modern web techniques power all this: There is [http://http://leafletjs.com/ Leaflet], "Open-Source JavaScript Library for Mobile-Friendly Interactive Maps". There is [http://jquery.com/ jQuery], "a fast, small, and feature-rich JavaScript library". On the server side lives [http://cesanta.com/mongoose.shtml mongoose], "The easiest to use web server on the planet". Data flows as [http://www.json.org/fatfree.html JSON], "The Fat-Free Alternative to XML". A lot of HTML5 and CSS3 is also involved.
The map has been tested on Safari on OSX and iOS. Chrome on Android, OSX and Linux. Firefox on OSX and Linux. It runs on workstations with huge screens, laptop computers with small screens, tablets, smartphones and even an old iPod with iOS 6.
 
=== Cloud Shadows (by Thorsten) ===
 
Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows:
 
{{cquote|In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.
 
For those interested, here's some details to the technique and why it's implemented the way it is:


If you can't run the latest codebase, here is a screenshot:
I've read up a bit on shadow generation techniques in the literature, and clouds appear to be tricky. Shadow volume techniques are out because they don't work for semi-transparent texture stacks, so it's got to be shadow maps.  
https://www.dropbox.com/s/98ejva4n4m38po1/HTMLRadioSettings.jpg.


=== Cloud Shadows ===
Generating a shadow map on the fly requires a shadow camera pass over clouds. I know from prior experience optimizing cloud rendering performance by means of a z-buffer filling first pass that any second pass over clouds is prohibitively expensive - any attempt to pass over clouds a second time drove me below 10 fps for even moderately clouded scenes. If I were to speculate, I'd say that this is the reason clouds in Rembrandt don't cast any shadows in spite of Rembrandt being easily able to include clouds in the shadow camera pass. There are other disadvantages to this approach, for instance a cloud texture could be fairly opaque (i.e. zero alpha) but we still might not want to render a shadow since the cloud is too high and diffraction would erase it, or because the cloud is translucent white and does in fact not cast a shadow, we may want to draw different depth of shadow etc.


Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows... In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.
So I believe a cloud shadow map needs to be generated procedurally from meta-information supplied by the weather system rather than in the rendering pipeline, since only the weather system knows what a cloud is and whether we want to draw a shadow or not.


There are still two different ways this could be done:


* the CPU gets the meta-info and assembles a shadow map as texture and passes that texture to the rendering pipeline
* the GPU gets the meta-info and assembles the shadow map inside the rendering pipeline


In the event, I've chosen the second approach, since evaluating 'simple' functions on the GPU is in my experience (a lot) faster than looking up a large texture (my rule of thumb is that a texture lookup is worth about 10 exp() functions or ~100 simple functions such as smoothstep()). Moreover, texture units are limited to 8, and the model ubershader already uses all available texture units, so there's some merit to not passing a texture.


The current code then passes 40 uniform position data points of clouds with shadow strength and depth encoded in the position information, allowing to draw 20 distinct cloud shadows. The weather system registers a shadow candidate every time a cloud which would cast a shadow is generated (currently that's Cu and Congestus type clouds) and a subroutine of the weather system selects which of these candidates should be drawn by the shader based on the current view position (and fov if the flag is on). The shadows are projected in a rudimentary way, but not exactly, i.e. the projection does not account for season and for terrain elevation - that's the price of framerate-friendliness, but one really has to go look hard to see the projection errors.


=== Random Buildings ===
So, I believe this technique has pros and cons over an on the fly generation by a camera pass, but framerate friendliness certainly is a big pro here. As indicated above, I will gradually deal with proper shadows in all special-purpose shadows and also register different types of clouds for shadow candidates in the weather system.


=== Project Rembrandt ===
I'm not sure whether this can easily be generalized to the way Basic Weather handles clouds, and one point of discussion may be down to which quality level this feature should be supported, so there's plenty to be discussed.|Thorsten}}
A number of Mac users have been reporting issues related to running [[Project Rembrandt]] (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: [[Project Rembrandt#Mac Issues]].


=== Canvas System ===
[[File:Cloud shadow01.jpg|400px|Clouds cast shadow on the terrain]]
[[File:Cloud shadow02.jpg|400px|Clouds cast shadow on the terrain and aircraft]]


=== High Level Architecture ===
=== Aerotowing Support ===
Since a few days we have a Nasal-script (<tt>Nasal/towing/hitch.nas</tt>) that provides two features:
* winch and aerotowing support for JSBSim-aircraft (glider and towplane)
* visible tow and winch ropes for YASim- and JSBSim-planes


=== Usability Improvements ===
The functions in hitch.nas are very similar to the YASim-routine "/FDM/YASim/Hitch.cpp" and hence aerotowing is fully compatible with the
YASim functionality. This means that YASim-gliders could be towed by JSBSim-aircraft and vice versa.
Setup instructions with copy and paste examples are given in the first paragraph in hitch.nas and at [[User:D-NXKT]].
This routine is only active for gliders/towplanes and doesn't influence other aircrafts. Visible ropes for YASim-aircraft will work out of the box without any modification in the aircraft-files.
The SGS233 is an example for a JSBSim-glider, Bocian is one for a YASim-plane. In case you want to test other YASim-gliders: If you don't
see the towrope at the expected position ... this is rather a wrong hook-setting in the aircraft-file than a bug in my routine. Btw. this
explains, why some gliders are very hard to tow ... the hook is mounted far behind the c.g. !
Special thanks go to the developer of YASim/Hitch.cpp and Klaus Kerner, who was the first providing a visible rope and towing capability for a JSBSim-glider (DG101g). A lot of their work is incorporated in this new routine.


=== Getting involved as a programmer ===
=== Getting involved as a programmer ===
Line 86: Line 152:
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.
Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.


== Release ChangeLog ==
=== YASim looking for a new maintainer ===
This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.
{{cquote|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.


== Interview with a contributor (NAME) ==
Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)
''In each edition we have an interview with a contributor. Suggestions for possible questions are available on [[interview questions]], you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the [[list of interview volunteers]]! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.''


* How long have you been involved in FlightGear?
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,
* What are your major interests in FlightGear?
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.
* What project are you working on right now?
Suggestions for that means in practice, are most welcome!
* What do you plan on doing in the future?
* Are you happy with the way the FlightGear project is going?
* What do you enjoy most about developing for FlightGear?
* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?


More questions are being collected here: [[Interview questions]].
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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}


Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}
 
== New software tools and projects ==
 
=== Bash Completion ===
A new [[Bash completion]] script is now available for the fgfs-command. You just have to install the completion script as explained [[Bash completion#Installation|here]].


== Nasal for newbies ==
New feature??? Yes, you are right! Bash completion has existed for Flightgear since 2005 (a time where this feature has been really rare!), but not been updated since 2008.


== New software tools and projects ==
The new release now supports auto-completion for all options from "fgfs --help --verbose", as well as airport codes, aircraft names, parking positions, runways, carrier names, scenarios, navaids, and some more.


== FlightGear addons and mods ==
If you have questions or comments regarding that script, please post them to this {{forum link|t=22349|text=forum thread}}.


== In the hangar ==
== In the hangar ==


=== New aircraft ===
=== New aircraft ===
==== Airbus A310 ====
[[File:A310-300 Hapag-Lloyd front.png|thumb|A310-300 (version 0.10) with Hapag-Lloyd livery in flight.]]
The Airbus A310 is a medium- to long-range twin-engined wide-body jet airliner that was developed and manufactured by Airbus. Released in 1983, it was the second aircraft to enter production by Airbus Industries.<ref>{{cite web |url=http://de.wikipedia.org/wiki/Airbus_A310 |title=Airbus A310 |publisher=Wikipedia |lang=de}}</ref>
This new package contains models of the A310-204, A310-222, A310-308 and A310-324 in alpha phase:
* The models are quite detailed with working, retractable gears, working flaps/slats/... (4 points)
* The FDM is a basic aeromatic approach with accurate input data (1 point)
* The systems are in "engines always on” state right now (0 points)
* The cockpit is a modified version of Pierre Duvals A300-600ST flightdeck. It was fitted to the A310 but some of the instruments need to be adopted to the A310. (3 points)
[[File:A310-300 gears.png|300px|A310-300 retracting gears]]
[[File:A310-300 flaps.png|x214px|A310-300 deploying flaps]]
The aircraft comes with a detailed paintkit in .svg/inkscape file format and is shipped with 13 shared (=usable with all 4 models) liveries.
[[File:A300-Cockpit.png|300px|Cockpit of the A300-600ST(Beluga), fitted to the A310]]
[[File:A310 paintkit.png|x225px|Zoom view of the paintkit for the A310.]]
If interested, you can find a link to the download and some status updates in the {{forum link|t=21869|text=forum}}. Any contribution or help, especially for the systems and FDM is highly welcome!


== Vespa Scooter for FlightGear ==
== Vespa Scooter for FlightGear ==
'''By LesterBoffo'''


::Really not a new aircraft per se, but it's flight model borrows from YAsim prop drive aircraft.  Some years back I had made a scooter model for Flying Model Simulator, the RC model training simulator.  This is the 3D model with some improvements of the basic 3D and additional animations.  In use it operates much like a modern 'Twist and Go' CVT transmissioned scooter.  You apply throttle and it accelerates, apply brakes, ( both wheels are braked.) using the joystick button 0 or trigger button..) or the period key, (.) for rear and comma (,) for front brakes.  Using the rear brake is handy because it applies less braking force and can be used as a 'trailing brake' through corners.  My future plans include re-editing the FDM and adding some nasal so this bike has a 4 speed gearbox.
Really not a new aircraft per se, but its flight model borrows from YAsim prop drive aircraft.  Some years back I had made a scooter model for Flying Model Simulator, the RC model training simulator.  This is the 3D model with some improvements of the basic 3D and additional animations.  In use it operates much like a modern 'Twist and Go' CVT transmissioned scooter.  You apply throttle and it accelerates, apply brakes, ( both wheels are braked.) using the joystick button 0 or trigger button..) or the period key, (.) for rear and comma (,) for front brakes.  Using the rear brake is handy because it applies less braking force and can be used as a 'trailing brake' through corners.  My future plans include re-editing the FDM and adding some nasal so this bike has a 4 speed gearbox.


:::I'm presenting this model for a Multiplayer Event of a Scooter tour of the Isle of Man's famous motorcycle Time Trial Race Course. I'm preparing some 3D scenery files to add to the existing scenery used in the new 2.0 FG scenery for the UK/Europe areas, with it's improved roads.
I've presented this model for a multiplayer event of a Scooter tour of the Isle of Man's famous motorcycle Time Trial Race Course. I prepared some 3D scenery files to be used in the new 2.0 scenery for the UK/Europe areas, with it's improved roads.


[http://forum.flightgear.org/viewtopic.php?f=10&t=22114]
{{forum link|t=22114}}


:::There will be a couple other bikes made for the FG, although I don't think they will be done in time for the MP event.   
There will be a couple other bikes made for FlightGear, although I don't think they will be done in time for the MP event.   


:::I've been approached by Detlef Faber, who offer to adapt his walker figure to use with this scooter.   So the user/pilot will have the ability do first person excursions from the bike after parking it. It will also have improved rider animations.  I'm also providing the aero-winch tow functions from the FG YAsim glider FDM's on this bike, because it tends to get stuck fast in rough terrain, much like the conifer forest terrain tiles.  This is a 'feature' of the YAsim wheel modeling that I like, because it models rough ground and you can make trips off the pavement on some kinds of terrain without having it get stuck.
I've been approached by Detlef Faber, who offer to adapt his walker figure to use with this scooter. So the user/pilot will have the ability do first person excursions from the bike after parking it. It will also have improved rider animations.  I'm also providing the aero-winch tow functions from the FlightGear YAsim glider FDM's on this bike, because it tends to get stuck fast in rough terrain, much like the conifer forest terrain tiles.  This is a 'feature' of the YAsim wheel modeling that I like, because it models rough ground and you can make trips off the pavement on some kinds of terrain without having it get stuck.


[[File:Start finish of the Isle of Man TT course.jpg|thumb|Start finish of the Isle of Man TT course from the MPMap view]]
[[File:Start finish of the Isle of Man TT course.jpg|thumb|Start finish of the Isle of Man TT course from the MPMap view]]
Line 131: Line 224:
[[File:Small displacement TT road racer.jpg|thumb|Small displacement TT road racer in development]]
[[File:Small displacement TT road racer.jpg|thumb|Small displacement TT road racer in development]]


{{#ev:youtube|fwdnYUCNmGw}}


{{#ev:youtube|fwdnYUCNmGw}}
== Scenery corner ==
=== Airports ===
Flyingfisch has been working on several of the airports in northeast Ohio. See {{forum link|p=203927|text=this forum post}} for more details.


=== Updated aircraft ===
[[File:KCAK Terminal 1.png|300px|Akron canton terminal]]
[[File:KCAK Terminal 2.png|300px|AirTran 717 at Akron canton terminal]]
[[File:Airdock thumbnail.jpg|x169px|Goodyear airdock at KAKR]]


=== Liveries ===
=== New tree textures ===
With the new world scenery and procedural terrain texturing techniques, FlightGear's visuals have progressed to a point that trees were the least realistic element in the scene. This of course can be fixed. Thanks to work by forum user Zbyszek (deciduous trees) and ThorstenR (coniferous trees), we now have new hires tree textures for the regional texturing scheme (for legacy support, global texturing still uses the old trees), making the visual quality of the trees now on par with the rest of the scene:


== Scenery corner ==
[[File:Trees04.jpg|300px|Hires deciduous trees]] [[File:Trees06.jpg|300px|Hires coniferous trees]] [[File:Trees05.jpg|300px|Hires coniferous trees wit snow]]
=== Airports ===


== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==
== Screenshot of the month ==
Flying by Denali, Alaska, in tricky weather
Flying by Denali, Alaska, in tricky weather


[[File:Denali2.jpg|600px|Near Denali, Alaska]]
[[File:Denali2.jpg|600px|Near Denali, Alaska]]


== Suggested flights ==
== Aircraft reviews ==
== Aircraft reviews ==
=== Piper PA-22 ===
{{review}}
[[File:pa22-3.jpg|thumb|270px|Flying over northeast Ohio]]
[[File:Pa22-2.png|thumb|270px|A look out the left side]]
[[File:Pa22cockpit-2.png|thumb|270px|The cockpit]]
The [[Piper PA-22]] is a classic post-World War II aircraft. Produced from 1950-1964, it competed with other light GA aircraft of the day, including the Cessna 150. Its popular appeal lay in its ruggedness, spacious cabin, and, for the time, impressive speed.
Let's see how the FlightGear version compares.
The FlightGear version of the plane includes an autostart option as well as a tutorial to step you through the process. The takeoff is smooth and steady, only minimal rudder is needed to keep the aircraft lined up with the runway. We rotate at about 55 MPH, accelerate to about 85 MPH, and climb. The climb rate is decent, and pretty soon we reach our cruising altitude of 1000 feet.
After leaning out the mixture a bit, pulling the throttle back to three quarters, I decide to turn on autopilot. There is a tutorial to step you through the use of the autopilot, which is quite simple. Since the autopilot only takes care of roll, we reach up to the ceiling to adjust the vertical trim. Clicking it will cause it to rotate in one direction, middle clicking will rotate it in the other direction.
Now that the plane is flying in a hands-off configuration, we can look around. Since the day I took off on was pretty warm, I decided to open the window for a little breeze. This is easily done by clicking on it. The vents on all four windows also open and close when clicked. If it's dark out you can click the dome light behind you to light up the cockpit. Red-tinted instrument lights are also available.
A little experimentation will show you that it is pretty hard to stall this aircraft. What happens instead is the aircraft mushes with full elevator, and the plane just falls from the sky. You still have control and dipping the nose down a bit and increasing power should get you flying normally again.
We head back to the airport at about 110 MPH to test out the landing characteristics. As we approach the airport, we slow down to about 90 MPH and lower the flaps fully. Our over-the-fence speed is about 85 MPH, and raising the nose slightly and cutting power over the runway sets us gently on the ground.
The flight isn't over yet though. A little judicial movement on the rudder pedals makes sure we don't turn off the runway. In this regard, a stitch in time saves nine, and small movements as soon as you see a little lateral movement saves having to make large embarrassing ones a second later. Be careful with the brakes, as this plane has a tendency to dip a wing if applied too roughly.
The flight dynamics seem pretty realistic, the model is excellent (it even has four liveries and a paintkit), and the 3D cockpit is superb. One thing I would suggest is having it remember your preference whether to show or hide the wheel pants, but apart from that I don't see anything lacking.
-- [[User:Flyingfisch|Flyingfisch]] ([[User talk:Flyingfisch|talk]]) 20:54, 13 March 2014 (UTC)


== Wiki updates ==
== Wiki updates ==
Line 169: Line 288:


== Community news ==
== Community news ==
=== FlightGear on YouTube ===
=== Virtual airlines ===
In the heart of Europe formed a group of four states that publicly act like one. This group is called Visegrad four. As the community FlightGear still a few pilots from the four countries, we decided to establish a virtual airline called Visegrad 4 Airlines. Although we are still in the beginning, already operates some routes, both domestic and international. The backbone of our fleet should consist of a Boeing 707, both for passenger transport and freight transport. Our callsign starts at V4A, according to which we can safely make out, as well as under its own livery ...
 
More information can be found on [https://plus.google.com/u/0/b/105722964830992112556/105722964830992112556/about our Google+ page]


=== New tutorials and screencasts ===
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===
=== FlightGear events ===
==== Hang gliding simulator ====
==== Hang gliding simulator ====
[[File:Hang gliding simulator using FlightGear.jpg|thumb|Hang gliding simulator using FlightGear]]
FlightGear was used to power a hang gliding simulator, presented on March 8th/9th in Bremen at the [http://www.rad-outdoor.de/ro/Home Rad+Outdoor / Passion 2014 convention], hall 4B, booth 60.


[[File:Hang gliding simulator using FlightGear.jpg|thumb|Hang gliding simulator using FlightGear]] FlightGear is being used to power a hang gliding simulator to be presented on March 8th/9th in Bremen at the [http://www.rad-outdoor.de/ro/Home Rad+Outdoor / Passion 2014 convention], hall 4B, booth 60.
The pilot sees the simulation through an [http://www.oculusvr.com/ Oculus Rift] head mounted display. Input is controlled by a joystick that is [http://cognium.de/misc/hgsim2.jpg mounted upside down] to catch user input. The whole simulator runs out of the box with proper command line/config options in FlightGear.
 
The pilot sees the simulation through an Oculus Rift head mounted display ([http://www.oculusvr.com/]). Input is controlled by a joystick that is [http://cognium.de/misc/hgsim2.jpg mounted upside down] to catch user input. The whole simulator runs out of the box with proper command line/config options in FlightGear.


See the [http://forum.flightgear.org/viewtopic.php?f=25&t=19772&start=15 Forum thread] for some details.
See the {{forum link|t=19772|text=forum thread}} for some details.


== Useful links ==
== And finally ... ==
== And finally ... ==
=== Contributing ===
=== Contributing ===
Line 192: Line 308:
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].
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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].
To learn more about how the project works, please see {{forum link|p=149971|text=this short essay}} written by Thorsten, for a more detailed article see [[How the FlightGear project works]].
 
=== YASim looking for a new maintainer ===
 
 
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}
 
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}
 
<references/>
 
 
=== Call for volunteers ===
* The [[Target4Today]] team is looking for volunteers to help improving FlightGear's combat support
 
=== Did you know ===


[[Category:FlightGear Newsletter]]
{{Appendix}}
<!-- this needs to be changed after each release, so that newsletters show up in the proper category -->


[[Category:Changes after 3.00]]
[[Category:FlightGear Newsletter|2014 03]]
[[Category:Changes after 3.0]]

Latest revision as of 20:00, 9 June 2019

Magagazine.png
Welcome to the FlightGear Newsletter!
Please help us write the next edition!
Enjoy reading the latest edition!


Development news

TerraGear developers looking for your help

The TerraGear maintainers are looking for volunteers to help with development on the next world scenery project. If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance. See the plan at World Scenery 3.0 roadmap. In addition, as part of working on an experimental TerraGear scenery build server, we're currently looking for people able to offer hosting for testing purposes.

FGPlot goes OOP

FGplot2NG.jpg

kuifje09 has finished porting his original FGPlot work (originally using PUI/XML dialogs) to use just Canvas now. In addition, the FGPlot code base has now been heavily refactored and modularized, introducing additional classes and separate files for each modules. In addition, FGPlot has now been sufficiently generalised to be also usable from other Nasal scripts. We are currently in the process of reviewing everything to hopefully ensure that this can be committed in time for the upcoming 3.2 release.

To learn more, continue reading at the forum topic This is a link to the FlightGear forum.

Installing TerraGear in 10 seconds on Linux

TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages

As part of working on a long-standing feature request, namely having a central shared TerraGear scenery build server, saiarcot895 has created Linux packages for Debian/Ubuntu (deb/ppa) to install precompiled TerraGear binaries. This now greatly simplifies installing TerraGear, because people no longer need to manually set up a complete Linux build environment and all SimGear/TerraGear dependencies. Everything is now done in an automated fashion.

Next, we're hoping to use this to install TerraGear on a public server for which people can ask for remote shell access (SSH). People interested in exploring this, should be getting in touch via the forum or the wiki.

Obviously, users will still need to be familiar with TerraGear, but they may benefit from reduced bandwidth restrictions and/or more horsepower in comparison to running TerraGear locally (e.g. one user offered to contribute hosting on a 32gb RAM and 8-core server). So this could be a great opportunity for people to run scripted/unattended jobs, without having to go through the hassle of downloading/building/installing and configuring TerraGear. But so far, being familiar with TerraGear and Linux is going to be a prerequisite still.

Once that is working, we'll investigate making the setup reproducible by using TurnKeyLinux. Once we have a working TKL distro, we can install a full TG setup in just a few minutes by downloading an ISO file and installing it in a VM (VMWare/VirtualBox). This would basically allow people to easily download/install TerraGear locally, either installed next to their OS, or as a virtual machine.

The long term idea is to hook up TerraGear GUI to it, so that the GUI front-end talks to TerraGear across SSH.

This is currently still a use-case for which TG wasn't designed for, and the TG developers mentioned already on the forums that there may be some roadblocks ahead, so everything here is still highly experimental. But ultimately we hope to provide a front-end to a Linux-based TerraGear VM, either by reusing TerraGear GUI or by coming up with a custom web-based front-end (please get in touch if you can help with this!).

If you're interested in helping or learning more, please get in touch via the forum or via TerraGear scenery build server.

Modified JSBSim search paths

AndersG has changed the search paths for JSBSim engines, propellers and systems in FlightGear to make it possible to have engines, propeller and system files shared by several aircraft stored in one place instead of keeping copies below each aircraft directory.

The change adds $FG_ROOT/Aircraft/Generic/JSBSim/{Engines,Systems} to the JSBSim engine, propeller and system search paths.

JSBSim searches <aircraft_dir>/Engines and <aircraft_dir>/Systems for the requested files before looking in the shared directories. This is consistent with how JSBSim works as a standalone program and should not cause any existing aircraft to load a different file than before.

Reset & Reinit

James started switching over the reset system to use the new code. The following changes will happen, in order:

  • places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally.
  • the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let James know)
  • the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used
  • Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)

James is not expecting any build failures since the code is already in Git, but he would ask that any bug-reports are only made /after/ wiping your autosave XML file.

Continue reading at Reset & re-init...

Built-in httpd updated

While working on the new radio/ATIS implementation, Torsten rediscovered the internal httpd (aka webserver) to browse the property tree. It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal property browser and navigate to the locations after each sim restart.

After a while, Torsten got disappointed by the functionality and the look&feel of the http property-browser, so he had a look at the code to see if it could be improved, he quickly realized, that the implementation was simple but not scalable, so he looked for something allready available on the GPL market.

And he found Mongoose as a well maintained, feature rich and yet simple implementation of a web server and started to embed that into FlightGear.

What is ready so far and pushed to next is:

  • A single threaded httpd running in the main loop (should probably get its own thread soon)
  • Running as a replacement for the old httpd
  • Serving $FG_ROOT/Docs as the document root
  • Serving the uri /props/ as a replacement for the old property browser (improved functionality, improved l&f, styling via css)
  • Serving the uri /run.cgi as a replacement for the old interface to run fg_commands
  • Serving the uri /json/ to return selected properties as JSON (read-only so far)

All this has a lot of potential. With the JSON interface extended to being able to write properties, the CGI interface of Mongoose turned on, the webserver running stable in it's own thread, It should be possible to run e.g. PHP with jQuery or dojo.

If you want to test the new functions, go to:

  • http://localhost:<httpd-port>/ for $FG_ROOT/Docs
  • http://localhost:<httpd-port>/props/ for the internal property browser
  • http://localhost:<httpd-port>/json/some/property/name/or/path for the internal property browser
  • http://localhost:<httpd-port>/run.cgi?value=pause to pause/unpause the simulation

Please mind the trailing slash for /props/ and /json/ (no, it's not bug-free yet.)

Torsten has pushed a litte quick-and-dirty example to fgdata. If you have a recent build from git/next, start FlightGear with --httpd=8080 and point your browser at http://localhost:8080/gui/radio.html You need to be online to see the goodies as the jQuery js is loaded from code.jquery.com and not (yet) pushed to fgdata. The updates every five seconds and does not write back to FlightGear yet.

If you can't run the latest codebase, check this screenshot

New built-in moving map

Central Europe with Navdata and Weather Layers

When starting FlightGear with the internal web server enabled (--httpd=8080), a new moving map application is accessible for those with a working internet connection and state-of-the-art web browser. http://localhost:8080/gui/map opens an interactive map covering the entire world, enriched with FlightGear navigation data and live weather information. An aircraft symbol is showing the current position of the simulated FlightGear aircraft, also indicating its heading and altitude. The position information is sent through a websocket in real-time without the need for polling the FlightGear web server. The update rate of the map is currently throttled to 1Hz but refresh frequencies up to 20Hz have been successfully tested. The map can follow the aircraft's position or may be panned freely around the world, still tracking the planes position on the map.

Around Hamburg (EDDH) with LOC courses

Three base layers currently exist: OpenStreetMap, Mapquest road and Mapquest satellite. Overlays for the FlightGear navdata, precipitation and sea level pressure isobares from openweather.org may be added in any combination. The level of detail for the navigation data varies with the zoom level. To keep the load on the FlightGear instance low, Navigation data will only be displayed up to a radius of 250NM around the maps center. In detailed zoom levels, all airports (including runways), navigation aids, localizer courses of the displayed area will show up after a short delay. A click on a marker brings up a popup with detailed information about the item like name, frequency, runway length etc.

At GA Parking EDDH with popup for ALSTER DME

Several modern web techniques power all this: There is Leaflet, "Open-Source JavaScript Library for Mobile-Friendly Interactive Maps". There is jQuery, "a fast, small, and feature-rich JavaScript library". On the server side lives mongoose, "The easiest to use web server on the planet". Data flows as JSON, "The Fat-Free Alternative to XML". A lot of HTML5 and CSS3 is also involved. The map has been tested on Safari on OSX and iOS. Chrome on Android, OSX and Linux. Firefox on OSX and Linux. It runs on workstations with huge screens, laptop computers with small screens, tablets, smartphones and even an old iPod with iOS 6.

Cloud Shadows (by Thorsten)

Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows:

Cquote1.png In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.

For those interested, here's some details to the technique and why it's implemented the way it is:

I've read up a bit on shadow generation techniques in the literature, and clouds appear to be tricky. Shadow volume techniques are out because they don't work for semi-transparent texture stacks, so it's got to be shadow maps.

Generating a shadow map on the fly requires a shadow camera pass over clouds. I know from prior experience optimizing cloud rendering performance by means of a z-buffer filling first pass that any second pass over clouds is prohibitively expensive - any attempt to pass over clouds a second time drove me below 10 fps for even moderately clouded scenes. If I were to speculate, I'd say that this is the reason clouds in Rembrandt don't cast any shadows in spite of Rembrandt being easily able to include clouds in the shadow camera pass. There are other disadvantages to this approach, for instance a cloud texture could be fairly opaque (i.e. zero alpha) but we still might not want to render a shadow since the cloud is too high and diffraction would erase it, or because the cloud is translucent white and does in fact not cast a shadow, we may want to draw different depth of shadow etc.

So I believe a cloud shadow map needs to be generated procedurally from meta-information supplied by the weather system rather than in the rendering pipeline, since only the weather system knows what a cloud is and whether we want to draw a shadow or not.

There are still two different ways this could be done:

  • the CPU gets the meta-info and assembles a shadow map as texture and passes that texture to the rendering pipeline
  • the GPU gets the meta-info and assembles the shadow map inside the rendering pipeline

In the event, I've chosen the second approach, since evaluating 'simple' functions on the GPU is in my experience (a lot) faster than looking up a large texture (my rule of thumb is that a texture lookup is worth about 10 exp() functions or ~100 simple functions such as smoothstep()). Moreover, texture units are limited to 8, and the model ubershader already uses all available texture units, so there's some merit to not passing a texture.

The current code then passes 40 uniform position data points of clouds with shadow strength and depth encoded in the position information, allowing to draw 20 distinct cloud shadows. The weather system registers a shadow candidate every time a cloud which would cast a shadow is generated (currently that's Cu and Congestus type clouds) and a subroutine of the weather system selects which of these candidates should be drawn by the shader based on the current view position (and fov if the flag is on). The shadows are projected in a rudimentary way, but not exactly, i.e. the projection does not account for season and for terrain elevation - that's the price of framerate-friendliness, but one really has to go look hard to see the projection errors.

So, I believe this technique has pros and cons over an on the fly generation by a camera pass, but framerate friendliness certainly is a big pro here. As indicated above, I will gradually deal with proper shadows in all special-purpose shadows and also register different types of clouds for shadow candidates in the weather system.

I'm not sure whether this can easily be generalized to the way Basic Weather handles clouds, and one point of discussion may be down to which quality level this feature should be supported, so there's plenty to be discussed.
— Thorsten
Cquote2.png

Clouds cast shadow on the terrain Clouds cast shadow on the terrain and aircraft

Aerotowing Support

Since a few days we have a Nasal-script (Nasal/towing/hitch.nas) that provides two features:

  • winch and aerotowing support for JSBSim-aircraft (glider and towplane)
  • visible tow and winch ropes for YASim- and JSBSim-planes

The functions in hitch.nas are very similar to the YASim-routine "/FDM/YASim/Hitch.cpp" and hence aerotowing is fully compatible with the YASim functionality. This means that YASim-gliders could be towed by JSBSim-aircraft and vice versa.

Setup instructions with copy and paste examples are given in the first paragraph in hitch.nas and at User:D-NXKT.

This routine is only active for gliders/towplanes and doesn't influence other aircrafts. Visible ropes for YASim-aircraft will work out of the box without any modification in the aircraft-files.

The SGS233 is an example for a JSBSim-glider, Bocian is one for a YASim-plane. In case you want to test other YASim-gliders: If you don't see the towrope at the expected position ... this is rather a wrong hook-setting in the aircraft-file than a bug in my routine. Btw. this explains, why some gliders are very hard to tow ... the hook is mounted far behind the c.g. !

Special thanks go to the developer of YASim/Hitch.cpp and Klaus Kerner, who was the first providing a visible rope and towing capability for a JSBSim-glider (DG101g). A lot of their work is incorporated in this new routine.

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.

If you interested in other developing, i.e. not C++ but Nasal scripting and/or XML, there are some articles listed at Category:Popular Community Requests that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from you -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at Nasal, so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

YASim looking for a new maintainer

Cquote1.png 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
Cquote2.png
Cquote1.png 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
Cquote2.png

New software tools and projects

Bash Completion

A new Bash completion script is now available for the fgfs-command. You just have to install the completion script as explained here.

New feature??? Yes, you are right! Bash completion has existed for Flightgear since 2005 (a time where this feature has been really rare!), but not been updated since 2008.

The new release now supports auto-completion for all options from "fgfs --help --verbose", as well as airport codes, aircraft names, parking positions, runways, carrier names, scenarios, navaids, and some more.

If you have questions or comments regarding that script, please post them to this forum thread This is a link to the FlightGear forum..

In the hangar

New aircraft

Airbus A310

A310-300 (version 0.10) with Hapag-Lloyd livery in flight.

The Airbus A310 is a medium- to long-range twin-engined wide-body jet airliner that was developed and manufactured by Airbus. Released in 1983, it was the second aircraft to enter production by Airbus Industries.[3]

This new package contains models of the A310-204, A310-222, A310-308 and A310-324 in alpha phase:

  • The models are quite detailed with working, retractable gears, working flaps/slats/... (4 points)
  • The FDM is a basic aeromatic approach with accurate input data (1 point)
  • The systems are in "engines always on” state right now (0 points)
  • The cockpit is a modified version of Pierre Duvals A300-600ST flightdeck. It was fitted to the A310 but some of the instruments need to be adopted to the A310. (3 points)

A310-300 retracting gears A310-300 deploying flaps

The aircraft comes with a detailed paintkit in .svg/inkscape file format and is shipped with 13 shared (=usable with all 4 models) liveries.

Cockpit of the A300-600ST(Beluga), fitted to the A310 Zoom view of the paintkit for the A310.

If interested, you can find a link to the download and some status updates in the forum This is a link to the FlightGear forum.. Any contribution or help, especially for the systems and FDM is highly welcome!

Vespa Scooter for FlightGear

By LesterBoffo

Really not a new aircraft per se, but its flight model borrows from YAsim prop drive aircraft. Some years back I had made a scooter model for Flying Model Simulator, the RC model training simulator. This is the 3D model with some improvements of the basic 3D and additional animations. In use it operates much like a modern 'Twist and Go' CVT transmissioned scooter. You apply throttle and it accelerates, apply brakes, ( both wheels are braked.) using the joystick button 0 or trigger button..) or the period key, (.) for rear and comma (,) for front brakes. Using the rear brake is handy because it applies less braking force and can be used as a 'trailing brake' through corners. My future plans include re-editing the FDM and adding some nasal so this bike has a 4 speed gearbox.

I've presented this model for a multiplayer event of a Scooter tour of the Isle of Man's famous motorcycle Time Trial Race Course. I prepared some 3D scenery files to be used in the new 2.0 scenery for the UK/Europe areas, with it's improved roads.

[1] This is a link to the FlightGear forum.

There will be a couple other bikes made for FlightGear, although I don't think they will be done in time for the MP event.

I've been approached by Detlef Faber, who offer to adapt his walker figure to use with this scooter. So the user/pilot will have the ability do first person excursions from the bike after parking it. It will also have improved rider animations. I'm also providing the aero-winch tow functions from the FlightGear YAsim glider FDM's on this bike, because it tends to get stuck fast in rough terrain, much like the conifer forest terrain tiles. This is a 'feature' of the YAsim wheel modeling that I like, because it models rough ground and you can make trips off the pavement on some kinds of terrain without having it get stuck.

Start finish of the Isle of Man TT course from the MPMap view
Small displacement TT road racer in development

Scenery corner

Airports

Flyingfisch has been working on several of the airports in northeast Ohio. See this forum post This is a link to the FlightGear forum. for more details.

Akron canton terminal AirTran 717 at Akron canton terminal Goodyear airdock at KAKR

New tree textures

With the new world scenery and procedural terrain texturing techniques, FlightGear's visuals have progressed to a point that trees were the least realistic element in the scene. This of course can be fixed. Thanks to work by forum user Zbyszek (deciduous trees) and ThorstenR (coniferous trees), we now have new hires tree textures for the regional texturing scheme (for legacy support, global texturing still uses the old trees), making the visual quality of the trees now on par with the rest of the scene:

Hires deciduous trees Hires coniferous trees Hires coniferous trees wit snow

Screenshot of the month

Flying by Denali, Alaska, in tricky weather

Near Denali, Alaska

Aircraft reviews

Piper PA-22

This section contains a review.   Please note that statements made here are (mostly based on) a single person's opinion.
Flying over northeast Ohio
A look out the left side
The cockpit

The Piper PA-22 is a classic post-World War II aircraft. Produced from 1950-1964, it competed with other light GA aircraft of the day, including the Cessna 150. Its popular appeal lay in its ruggedness, spacious cabin, and, for the time, impressive speed.

Let's see how the FlightGear version compares.

The FlightGear version of the plane includes an autostart option as well as a tutorial to step you through the process. The takeoff is smooth and steady, only minimal rudder is needed to keep the aircraft lined up with the runway. We rotate at about 55 MPH, accelerate to about 85 MPH, and climb. The climb rate is decent, and pretty soon we reach our cruising altitude of 1000 feet.

After leaning out the mixture a bit, pulling the throttle back to three quarters, I decide to turn on autopilot. There is a tutorial to step you through the use of the autopilot, which is quite simple. Since the autopilot only takes care of roll, we reach up to the ceiling to adjust the vertical trim. Clicking it will cause it to rotate in one direction, middle clicking will rotate it in the other direction.

Now that the plane is flying in a hands-off configuration, we can look around. Since the day I took off on was pretty warm, I decided to open the window for a little breeze. This is easily done by clicking on it. The vents on all four windows also open and close when clicked. If it's dark out you can click the dome light behind you to light up the cockpit. Red-tinted instrument lights are also available.

A little experimentation will show you that it is pretty hard to stall this aircraft. What happens instead is the aircraft mushes with full elevator, and the plane just falls from the sky. You still have control and dipping the nose down a bit and increasing power should get you flying normally again.

We head back to the airport at about 110 MPH to test out the landing characteristics. As we approach the airport, we slow down to about 90 MPH and lower the flaps fully. Our over-the-fence speed is about 85 MPH, and raising the nose slightly and cutting power over the runway sets us gently on the ground.

The flight isn't over yet though. A little judicial movement on the rudder pedals makes sure we don't turn off the runway. In this regard, a stitch in time saves nine, and small movements as soon as you see a little lateral movement saves having to make large embarrassing ones a second later. Be careful with the brakes, as this plane has a tendency to dip a wing if applied too roughly.

The flight dynamics seem pretty realistic, the model is excellent (it even has four liveries and a paintkit), and the 3D cockpit is superb. One thing I would suggest is having it remember your preference whether to show or hide the wheel pants, but apart from that I don't see anything lacking.

-- Flyingfisch (talk) 20:54, 13 March 2014 (UTC)

Wiki updates

Translators required

En.gif 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.
De.gif 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.
Nl.gif 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.
Es.gif 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.

Community news

Virtual airlines

In the heart of Europe formed a group of four states that publicly act like one. This group is called Visegrad four. As the community FlightGear still a few pilots from the four countries, we decided to establish a virtual airline called Visegrad 4 Airlines. Although we are still in the beginning, already operates some routes, both domestic and international. The backbone of our fleet should consist of a Boeing 707, both for passenger transport and freight transport. Our callsign starts at V4A, according to which we can safely make out, as well as under its own livery ...

More information can be found on our Google+ page

FlightGear events

Hang gliding simulator

Hang gliding simulator using FlightGear

FlightGear was used to power a hang gliding simulator, presented on March 8th/9th in Bremen at the Rad+Outdoor / Passion 2014 convention, hall 4B, booth 60.

The pilot sees the simulation through an Oculus Rift head mounted display. Input is controlled by a joystick that is mounted upside down to catch user input. The whole simulator runs out of the box with proper command line/config options in FlightGear.

See the forum thread This is a link to the FlightGear forum. for some details.

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 This is a link to the FlightGear forum. written by Thorsten, for a more detailed article see How the FlightGear project works.

References
  1. James Turner (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.
  2. Andy Ross (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.
  3. Airbus A310. Published by Wikipedia.