FlightGear Newsletter March 2013
|
We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release. At the end of each month, it's generally a good idea to get in touch with other contributors to ask them to add news about their contributions to the newsletter.
Development news
Usability Improvements: Tooltips
Work has started on adding support for tooltips to FlightGear, Tooltips are a work-in-progress usability enhancement. They provide a way for a cockpit to be partially self-documenting, when a user explores, and can also provide a positive confirmation of state or action, which is often lacking in 3D cockpit interactions due to absence of audio or haptic feedback. (Which is a fancy way of saying, switches don't click or feel to move).
A tooltip is specified via a set-tooltip command in a pick (or slider or knob) animation's <hovered> bindings group. The tooltip is configured at this time, especially content and an ID. The mouse-handling system then displays the tooltip at the correct time. This design allows us to show tooltips at configurable points, either the standard method - after the mouse is stationary for a period of time - or in response to other actions, such as mouse clicks/drags.
Continue reading at Tooltips...
Project Rembrandt
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
Tom has started working on adding scenery-placement support to the canvas system, so that canvas textures can be also used as part of the scenery, not just the aircraft/HUD or GUI. This also means that the pose of the scenery models is now exposed to Nasal load/unload scripts.
This allows Nasal code attached to scenery models access their world position and orientation by calling _model.getPose().
Also ensure models are attached to the scenegraph before Nasal load scripts are called. This ensures that the world position and orientation are available upon executing the load script.
For details, please see Canvas scenery placement and the corresponding commits:
- https://sourceforge.net/p/flightgear/flightgear/ci/eba03b5e469824ee8f1494723fcddbbc56155a08/
- https://sourceforge.net/p/flightgear/flightgear/ci/913727239d6776c0508d206f395e16c265413ec3/
Shaders and effects
After posting some really impressive screen shots showing procedural snow and drift ice in Iceland in February 
, Thorsten has now started working on Perlin noise modulation of water color and surface ripples. Which he still considers a cheat - because it does not know about real depth distribution of the water. For details, see the forum .
Adding your own C++ Subsystems to FlightGear
We have started improving the Howto:Create new subsystems article to provide a step-by-step section on adding your own code to the FlightGear main loop, The article is meant to document the necessary steps involved in setting up a new C++ subsystem in FlightGear. This is usually required in order to implement completely new components or features, but also in order to create new instrument implementations that are hardcoded in C++. Also, implementing new subsystems in C++ is usually the preferred way of implementing computationally intense features or code that needs to be run at very high frequency, possibly even outside the main loop, code that may otherwise cause too much CPU load if for example implemented in scripting space. Feedback appreciated!.
Understanding $FG_HOME
We only just noticed that we somehow missed to document the purpose of $FG_HOME, that's now fixed: $FG_HOME is a placeholder variable representing the path to where user-specific FlightGear data is stored (not application data). Unlike $FG_ROOT, $FG_HOME is NOT an environment variable that needs to be specifically configured for FlightGear to work. $FG_HOME is the only place were FlightGear data is written to, $FG_ROOT is generally read-only. $FG_HOME is only used to refer to the OS-specific location for some settings/folders. The actual location of $FG_HOME will be determined by the fgfs binary during startup, it is a name for a directory that varies with the various operating systems supported by FG (Windows, OSX and Linux) and it stores information between sessions, such as: configuration/preferences, properties marked with the "user-archive" attribute and aircraft-specific settings (using the data helper class in aircraft.nas). $FG_HOME is also the location for the SQLite-based NavDB cache.
Continue reading at $FG_HOME...
Advanced Nasal MetaProgramming
Philosopher created a pretty sophisticated Nasal script with lots of neat meta-programming tricks, and ended up turning it into a tutorial - so this is something for our more advanced Nasal programmers.
Continue reading at Nasal Meta-Programming...
FlightGear Interfacing via Telnet
FlightGear comes with an internal command server. This so called "telnet" server provides a "remote shell" (like a command prompt) into the running FlightGear process that can be used to inspect and modify runtime state, but also to run commands.
FlightGear can be configured to act like a telnet or even an http "server". It can watch a port for incoming connections and respond appropriately, these built-in daemons (servers) support multiple concurrent connections.
FG has a low bandwidth "command" (aka telnet/props) interface where you can interactively (or automatically via an external program) examine and modify just about any internal variable in the sim. This gives you a great capability to do external scripting, external operater gui's, etc. For instance, if you have your own GUI for operating the sim and want to use it to set weather conditions, you can leverage the FG telnet interface to have your own program remotely configure the environmental settings in all your FG based visual channels.
Many things (view parameters, weather, time of day, etc.) are configurable via the property system. For things like weather and view selection which don't change rapidly, you can send over new property values using the "telnet" interface. For things that could change rapidly (like view position/orientation) you probably want to blast over udp packets at 60hz or whatever your screen refresh rate.
The telnet server can be activated with the --telnet=port command line option, where port is the number of the listening port that will be opened locally by the FlightGear fgfs process (note that the --props parameter is equivalent).
The --telnet= option can be used to accept property configuration changes (things like weather effects and time of day.) You can use this interface to read/write individual properties. You could set up a separate gui configured to know the ip addresses of all the slaves so it could update them appropriately to make a change. For the time of day, this presupposes that all the computer clocks are pretty closely in sync ... then you can send the same time offset to them (in seconds) so they all can display the same time of day effects.
A connection to the running server can be established using a conventional telnet client or by opening a simple TCP socket from a custom program. Using a telnet client (such as Putty for Windows) it is possible to connect to a running FlightGear process and issue commands that FlightGear then runs internally. The telnet client can be running on the same machine as FlightGear itself, or on other machines that are in some way connected to the same network (LAN, WAN/internet).
This can for example be used to read and set values within the Property Tree structure, but it can also be used for running fgcommands. A list of available fgcommands is available in $FG_ROOT/Docs/README.commands.
This makes it possible to "remote control" FlightGear by using the telnet protocol. This can for example be used to change environment settings (weather, time, visibility etc).
But a telnet connection can also be used for inserting scenery objects or AI aircraft models dynamically. It is also possible to trigger arbitrary Nasal code by writing to a property with a registered Nasal listener. In fact, it is even possible to insert and run Nasal code via telnet, by writing the code to a property and call()'ing it then [1][2].
Multiple connections are possible at the same time. For an example in Java please refer to $FG_SRC/scripts/FGClient.
For shell scripting purposes, netcat also works well.
The routines already support network byte order, however there are cases (i.e. interfacing to an external perl script using pack/unpack, where network byte order is not desirable).
In comparison to the binary native protocol, the props/telnet protocol is a lower bandwidth, high reliablity channel. You are guaranteed that every message gets to the receiver once (and only once.) This is great for setting up weather conditions, time of day, camera parameters, and anything else that might have an impact on the visuals. We have a convenient "telnet" interface to all the internal properties and built in commands. Anything you can set from the keyboard, or mouse, or gui, you can do from a remote program or script. It's much lower bandwidth, but very convenient.
The telnet mechanism is not designed to be high bandwidth. I believe it runs at 5hz? and only processes one line/command per iteration. You could try upping the frequency via the command line, "--props=socket,bi,20,,5500,tcp" (we could change PropsChannel::foundTerminator() to handle several commands per line. Commands could be separated with semicolons. Or perhaps some commands could take more than one argument, eg "get /foo/bar /foo/baz"). For higher bandwidth needs, it would work better to send over an FGNetFDM structure (src/Network/net_fdm.hxx) via UDP or some other custom structure.
Continue reading at Telnet usage...
Interview with a contributor (James Turner)
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!
- How long have you been involved in FlightGear?
Since 2008 as an active developer, but for years before as a casual user.
- What are your major interests in FlightGear?
Quite a few, is one answer. Most especially realistic flight of the larger, modern jets with glass-cockpits. This ended up touching many different areas I never expected, from the navigation data loading through XML animations and instrument simulation, besides lots of work on the autopilot and route-management code. Since I purchased some GoFlight input hardware after seeing it at FSWeekend last year, I need to get that working too, which will bring in whole new things to learn.
Aside from that, improving usability and deployment is important to me, since if people can't run or use the program, they aren't going to do much else except complain. Increasing the options that can be configured without a restart, making better GUIs possible, and reducing startup times are all part of that. Another has been making FlightGear behave like a regular application on OS-X and Windows, which is an on-going process, but already much better than the past - we put files in the correct place, use native menus (and soon file dialogs) on the Mac, and don't behave in ways which make the operating-system thing the program has died.
- What project are you working on right now?
A few things - improving usability with smarter cockpit animations and tooltips, bringing the 737-NG systems up to a better standard (especially with a fully working CDU), and improving our scenery download engine to use less disk-space. The new cockpit animations and tooltips that you can read about elsewhere in this newsletter, is likely to be the most visible change, but needs aircraft authors to use the new animations and add tooltips to their cockpits, so will take some time to really be noticed I guess. I'm excited about it because while I originally wrote it as a feature for new users, personally I find it makes my own flying experience much more positive.
- What do you plan on doing in the future?
I've got a page on the wiki that lists some ideas (Plan-zakalawe), but the big one is going to be working with some of the other developers to improve the modularity of the sim, which is needed to improve a long list of issues. This will mean adding and overhauling the internal data abstractions, and taking full advantage of Mathias Froehlich's high-level architecture (HLA) work.
- Are you happy with the way the FlightGear project is going?
Generally - compared to when I joined, we have a sane build system, a bug tracker, a release process, continuous build integration, and largely automated releases. The rendering (drawing) performance of the sim is a bit below where I'd like, but the HLA work mentioned above should be the key to experimenting with different rendering technologies in a manageable way.
- What do you enjoy most about developing for FlightGear?
Lots of things, partly working on end-user software where changes can have an immediate impact. Also improving my own flying experience - when I could finally fly the 777 with a fully planned flight, and view it on the navigation display (ND) instrument with all the EFIS features working, it was a nice achievement. Getting the CDU working in the 737NG has been similarly fun, though there's a lot of work before that is finished.
- Are there any "hidden features" you have worked on in FlightGear that new users may miss?
The flight-path recorder which was added in 2.10 is fun - switch it on in the map dialog and see where you went. You can zoom in and see how far off the ILS centre-line you were, or the shape of your circuits. If you install the (unfortunately no longer free to download) Navigraph procedures data , you can fly real SIDs and STARs, and route between them along airways.
Translators required
|
The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate. |
|
Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an. |
|
De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen. |
|
La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir. |
Nasal for newbies
Learning more about Nasal namespaces
In Nasal, a namespace is a "context", i.e. an environment where a certain symbol (variable) is valid. Imagine, three identical houses with rooms: Even otherwise identical rooms are kept in separate "environments", i.e. you have to refer to a certain "environment" (namespace) to uniquely identify a certain room, even though the design/architecture of each house is 100% identical, because they are all based on the sampe template (plan). For example, imagine three bath rooms in these three houses: house1, house2, house3. Now, imagine the users of the houses wanting to refer to each bath room using just the word (symbol/variable) "bath". To be able to resolve this properly, they will also need to qualify what house they are referring to, i.e. if it's house1, house2, house3.
house1.bath house2.bath house3.bath
Here, houseX is the enclosing namespace/context, i.e. "bath" is a member or "field" of the namespace. Basically, namespaces make it possible to have identically named variables/symbols without them possibly "clashing" or "polluting" the global namespace. Imagine a namespace to be a container with its own variables and scope. So certain variables are only valid within that particular namespace.
Continue reading at Howto:Understand Namespaces and Methods...
A GPX flight logger in Nasal
AndersM has contributed a new tutorial on developing a GPX flight logger using Nasal.
GPX is a XML format used by GPS devices to save tracks and other data for exchange with map viewers and other applications. There are web sites where its possible to view and share your tracks. This tutorial describes how to:
- Write a Nasal script that logs your flight track as a GPX file
- Make a dialog accessible from the menu to set logging options
- Bind a keyboard key to start and end the logging.
Continue reading at A GPX flight logger in Nasal...
Simple Crash Detection using Nasal
Most people are not aware of it, but FlightGear has an integrated warning system to warn if the pilot execute certain actions above the maximum speed. These speed limits are controlled by a piece of code in the -set.xml file of the aircraft. When a pilot performs an action above the maximum speed a message will be shown on the screen.
Continue reading at Howto:Define limits...
FlightGear addons and mods
Flug's Bombable addon and Sopwith Camel FDM updated!
Flug just uploaded a new version of the Bombable addon that is compatible with FlightGear 2.10 --in fact, it should work with all 2.X versions of FlightGear: http://brenthugh.com/flightgear/bombable4-5.zip
Thanks to Voudoun da Vinci for helping track down some of the problems and the fixes.
Bombable is still pretty new to FG 2.10, so please let flug know if you find any problems. Message in this thread is the best way .
FYI:part of the package is a new, greatly improved, historically accurate (to the degree I could make it so!) JSBSim FDM for the Sopwith Camel.
The idea was to make the Camel fly like a real Camel--not just when flying safely well within the envelope like a commercial pilot, but when taking it to the edge and beyond, as real combat pilots did in WWI.
Not easy to fly--but a lot of fun to try. It's SopwithCamel-Bombable (JSBSim), included in the Bombable distribution.
The ew JSBSim FDM for the Sopwith Camel that is as historically realistic as flug could make it. Download here: http://brenthugh.com/flightgear/sopwith ... Sim-10.zip
In flying the existing Sopwith Camel flight models in Flightgear with Bombable in simulated combat situations, the shortcomings of these flight models became apparent to flug. Flightgear flight models are typically designed and optimized for flying aircraft well within their design envelopes, as a commercial airline pilot does (and for good reason!). The FDMs work very well in those situations.
However, combat aircraft are often operated near the limits--or even over the limits--of their documented capabilities. Particularly for an aircraft like the Camel, working with and against the quirks of its design was an integral part of operating the aircraft in both everyday operations and in combat. These operational quirks were openly exploited by combat pilots.
In flying the Camel in FlightGear/Bombable, I became curious about the real historical experience of flying a Camel. What about the famous strong gyroscopic effect that causes the nose to rise in a LH and drop in a RH turn? It's commented on by most every pilot who writes about flying the Camel, but (it turns out) impossible to implement in YASim. What about the famous sensitivity to the controls, the quick turns (especially to the right), and propensity to fall into spins, and all the rest?
I set out to create a flight model of the Camel that would incorporate as many of the documented combat flight characteristics of the Camel as possible, and in as realistic a way as possible.
The new JSBSim FDM is my first try at accomplishing this--any feedback appreciated. It is included as part of the Bombable FG add-on package, but it also works as a free-standing aircraft (and installs alongside the existing Sopwith Camel, so it doesn't over-write anything.)
If this new FDM works for people, I'd like to see it included in the next FG release. I think it would be a simple drop-in addition to the existing FG 2.10 Sopwith Camel.
In the hangar
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen at the download page. If you're an aircraft developer and your aircraft is/are not on the rated list, please consider adding their status indications. All you'll need to know/do is described at Formalizing Aircraft Status. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.
Dave's Hangar back online
Dave has put his hangar back online at: http://dl.dropbox.com/u/12562954/hangar/hangar.html These models may not be the newest ones he made, and he's not sure they'll load or run, but it's all he could find off of his old hard drive. He does not have FlightGear running on his computer now (a zBox) so can't test these models. Note that the DavePack included may not be the right one for any of these models. Have fun with them. If you find bugs that I can fix with a text editor, let him know. Also, if you have any newer versions of these models (and DavePack), get in touch at the forum .
New aircraft
Piper Dakota
kaleblex has been working on a new PA28-236 Piper Dakota aircraft. The aircraft is still very much in development but has a working FDM and Model. Any help and contributions are welcome by using pull requests in the github repository. The Blender files are also included in the github repository so model away.
This aircraft is based on the PA28-161 but it's not simply an update. the PA28-236 has a different body and a different cockpit layout and it's a little faster too. The outer model is fully functional including animated flaps, ailerons, rudder, etc. It's missing the windows (they are included in the Blender file) because they aren't rembrandt capable at this point.
kaleblex is currently working on the cockpit and wiring it up. connect and bravo are working on texture/uv mapping the interior and exterior.
If anyone wants to begin working on fuel, electrical system, and/or lighting system please contact kaleblex in the forums.
As soon as the cockpit, texture mapping, and the ability to create liveries are complete we'll release an official development version to the community. Until then, feel free to download the github version to test and use but be aware there is no official support for this.
You can view more information at the Piper Dakota wiki page.
Scenery corner
The 3000th model has been submitted to the scenery database this month, two years after reaching 2000 models in January 2011! Positioned as 1.1 million individual objects all over the world, there's still room for many more. Help us to make the 4000th model a reality! Learn how you can contribute by visiting Howto:Place 3D objects with the UFO.
More statistics can be found at this page.
Iceland Scenery
Statto has created new scenery for Iceland and is looking for testers. You can find all the required details and download link at this forum topic .
Airports
Works have been added to Le Havre - Octeville Airport (LFOH) airport with many hangars and building, and same for Hong Kong International Airport (VHHH).
Aircraft of the month
Community news
FlightGear on YouTube
Dave's F-4N musing in finland's sunset:
Multiplayer
Hollywood at the EDDF-Triangle
The regular ATC-events at the "EDDF Triangle" (Frankfurt, Germany) have been enriched by taking "movies" during each session, showing all ongoing actions from different points of views:
The First- and Main-View shows the “actors” on the newly designed OpenRadar. In the example you see the following “acts” in parallel:
This picture shows already the now upcoming version II of OpenRadar. In that one you can define (yourself!) any "additional markings" you consider needed for (your) ATC-job. In this example are added:
For a complete guide to OpenRadar see the OpenRadarGuide | |
The Second View shows the actions within the whole “Triangle Area”. Here you see as an example:
For this view we use the general MPmap Utility. It is just for keeping an eye on the overall situation for estimating the upcoming workload. | |
| And last but not least the Third View shows CloseUp's onto the most impressive scenes of the leading actors, e.g. at TouchDown, TakeOff, Taxiing etc.
|
With these movies (see http://www.emmerich-j.de/EDDF/Films/Films.html) we try to initiate a little more understanding between pilots to pilots and ATC's - and thus improve all our performances. We especially hope to increase the sensibility for
- it makes sense (and is even fun!) to “fly controlled” when in an Multiplayer environment
- everybody notices “nobody is perfect” (at least not always!)
- we do not need to laugh about or insult others when (is “bullshit happens” allowed?) things go wrong – we always may “smile” about the others – and about ourselves!
- and most important: Although we do not just “play” but try to “simulate” → we should have fun together!
A word to all pilots, captains, and trainees:
- Please don't be afraid to try it – there are no major prerequisites needed, BUT:
- You should be able to control your model in regards to altitude, direction, speed, landing, starting. ATC will charge all mistakes against you – ATC will not accept excuses like “the autopilot did...” (nor will your (dead?) passengers accept such excuses)!)
- You must communicate with ATC and follow his advise (you may request a deviation from the advise – but you must follow the advise until the deviation is granted)
- We urge you to use FGCOM – but also accept communication by MPchat. You always should have an eye on the MPchat-messages, in case a FGCOM communication cannot be established!
- You should have a layout of the airport(s) – especially one for the more complex EDDF (see http://www.emmerich-j.de/EDDF/EDDF-Layout.png)
Some technicalities:
- You will notice that the films are not in "Best of Quality" - but they are in full HDTV (1920*1072 px), so that you can read all text-informations! Considering that such a format in good HDTV-Quality would need a size from more than 5GB and above → we assume that such a high Quality is not needed - it is just for us to judge and improve ourselves (pilots and ATC) - not to win an Oscar! Also we will not edit - because that would add a huge amount of daily workload – which is not really required for a “working tool”.
The movies
- are recorded on Linux/Ubuntu with RecordMyDesktop (Video/Sound Quality ~50, FpS=4, “Encode on the Fly”)
- are tested on Linux/Ubuntu with Firefox ver.18 and on Windows XP with InternetExplorer 8
- show the following Colors for the targets:
- blue = under EDDF-ATC control
- yellow = must be watched closely
- green = no concern
- white = selected
- gray/invisible = neglected or MP-timed out
You achieve a “Best Quality Viewing” if you use the "Full Screen" option of your browser (or VLC or MoviePlayer, etc.)!
Virtual Air Traffc Organization
The newly founded Virtual Air Traffic Organization promises to create a different dimension to the way FlightGear multiplayer events were organized so far and to also provide more realism within ATC and pilot operations.
vATO is a complete overhaul and re-brand of Air H5. Air H5 was an organization in FlightGear which consisted of two main event-based virtual airlines, Eurfly which operates in Europe and Fremont which operates in North America. Air H5 was originally founded by Rick Ace in July 2010 and its activity had to end after a few months of success. Air H5 was then reorganized in May 2012 but due to the low standards and lack of pilots and ATCs, it ended its operations in January 2013.
vATO's new goal is to increase the standards even more and create the best and most realistic multiplayer event experience FlightGear has to offer.
The new organization is currently seeking for ATCs, pilots and staff members. If you are interested, fill out the registration form on our website.
And finally ...
Contributing
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.
For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.
To learn more about how the project works, please see this short essay written by Thorsten, for a more detailed article see How the FlightGear project works.
Call for volunteers
- The Flightgear On Android team is looking for testers
- The Target4Today team is looking for volunteers to help improving FlightGear's combat support
- The FGFSPM (FlightGear Package Manager) is looking for a new maintainer.