Es/FlightGear Newsletter January 2014

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

Nos gustaría enfatizar que el boletín de noticias mensual no podría ser posible sin los aportes de los usuarios de FlightGear y los desarrolladores. Cualquiera con una cuenta wiki (con libertad para registrarse) puede editar el boletín y toda contribución es bienvenida. Si conoces acerca de alguna noticia o proyecto relacionado a FlightGear tales como por ejemplo una actualización del escenario o avión, porfavor siéntete invitado a añadir esas noticias al boletín. Se anima a los desarrolladores del núcleo a enviar noticias acerca de sus últimos trabajos a la sección desarrollo del boletín y al control de cambios de la próxima versión. Al final de cada mes, generalmente es una buena idea estar en contacto con otros colaboradores para pedirles que agreguen noticias al boletín acerca de sus aportes.

Noticias del proyecto

Versiones candidatas de FlightGear 3.0

El 17 de febrero es nuestra fecha programada para la versión 3.0! Si alguno de ustedes tiene algo de arriesgado y quiere probar las "versiones candidatas", pueden encontrar el último instalador de FlightGear-3.0 en http://fgfs.goneabitbursar.com/releases/ Por favor, ten en cuenta que esta no es aún la versión 3.0 oficial y que la fecha de lanzamiento está sujeta a cambio a medida que nos acercamos a la fecha de lanzamiento oficial. Cualquier observación es bienvenida en nuestro foro dedicado http://forum.flightgear.org/viewforum.php?f=68

SDK para instrumentos de planeadores

Galvedro ha comenzado a documentar el nuevo "Paquete de Desarrollo de Software" (SDK, de Software Development Kit). Este SDK es una pequeña librería de objetos Nasal que puedes usar para añadir instrumentos especializados para tu planeador. La librería está compuesta de varios bloques que puedes conectar juntos de diferentes formas para obtener la funcionalidad deseada.

Para usar la librería, necesitarás escribir un script Nasal que será cargado junto con tu aeronave. Esto se realiza referenciando el script en la sección <Nasal> del XML que define tu avión. No temas, los scripts serán muy simples. Veamos algunos ejemplos:

io.include("Aircraft/Generic/soaring-instrumentation-sdk.nas");

var probe = TotalEnergyProbe.new();

var vario_needle = Dampener.new(
	input: probe,
	dampening: 2.7,
	on_update: update_prop("instrumentation/vario/te_reading"));

var vario_instrument = Instrument.new(
	components: [probe, vario_needle],
	enable: 1);

Este código implementa un variómetro compensado de energía total básico, relacionando la aguja de lectura a la propiedad "instrumentation/vario/te_reading".

Continúa leyendo en Soaring instrumentation sdk...

Creando una Layer ATC/RADAR personalizado en 10 minutos

Philosopher y Hooray han añadido un nuevo tutorial que demuestra cómo crear nuevas pantallas MapStructure basadas en Canvas. Las personas que ya tienen algo de experiencia con Nasal (árbol de propiedades, POO), deberían ser capaces de completar esto en menos de 15 a 20 minutos. Por lo tanto, para aprender a crear una simple pantalla ATC/RADAR, continúa leyendo en Canvas Radar...

Tras bambalinas: Loops de Nasal

Nasal tiene varias formas de implementar una iteración, incluyendo eventos repetidos como listeners o timers. Un polling loop, que corre mediante un timer, es posible imaginarlo como alguien que está permanentemente corriendo a una habitación para confirmar si las luces están encendidas, mientras que un listener es como alguien que está durmiendo al interior de la habitación y sólo se despierta cuando las luces se encienden. La API setlistener está pensada para capturar eventos poco frecuentes, mientras que los timers son usados cuando generalmente cuando los eventos externos no son lo importate. Ambos son gatillados mediante un "callback", el cual es sólo una función que sirve como manejador de evento, es decir, esta función especificaría qué acciones deben realizarse cuando se gatille el evento.

En general, los timers no son malos ni costosos, porque realmente depende de qué haces al interior del callback (la función) que es invocado, pero en otros casos son mejores los listeners.

Cualquier callback será ejecutado normalmente en un único frame, tal que un timer de larga duración will add up to the frame spacing (latencia), como lo hará un listener gatillado con la misma frecuencia o incluso múltiples veces por frame.

No importa si el código/callback es ejecutado al interior de un timer o listener, lo importante es la complejidad del código que se ejecuta. Básicamente, aunque algunos códigos deben ejecutarse en ciertos lugares para lograr el efecto deseado, en la mayoría de los casos ese código puede ser más simple que complejo. Se prefieren los listeners por sobre los timers sólo cuando es necesario comprobar alguna condición, porque los polling basados en timer-loop son llamados como de "espera activa", por lo tanto más costosos, como en la analogía en la que alguien realiza una acción repetidas veces para realizar una comprobación.

Por otra parte, un listener no es un consumidor de recursos mientras está "esperando", puesto que ni siguiera está "activo", no hace nada sino hasta que es gatillado (semejante a las Interrupt Service Routines, como un detector de humo que gatilla una alarma cuando detecta humo). Sin embargo, hay muchas veces en que los loops tienen mucho más sentido, principalmente cuando muchos valores de propiedades necesitan ser usadas para manejar o evaluar un subsistema o una ecuación.

Continúa leyendo en Nasal Loops...

Dispersión de Luz Atmosférica (ALS)

Debido a que el mapeo uv de pistas sucias en el Escenario Mundial 2.0 is sound, ALS está recibiendo un efecto de texturas de alta resolución de pistas sucias. Este efecto permite dibujar charcos y delgadas capas de nieve sobre la pista, así como permitir parches de otro material (en la imagen, parches de pasto). Finalmente, esto hará que la apariencia de las pistas sucias también sea configurable regionalmente, con diferentes texturas de arena, piedras y pasto.

Usando datos de OpenStreetMap en FlightGear

En 2013, hemos visto bastante progreso en la generación procedural de escenario usando OpenStreetMap (OSM) data, incluyendo edificios y ciudades (radi, Soitanen/osm2fg), caminos, ríos, incluso líneas férreas (vivian) y generación procedural de puentes (radi), y también procedimientos para líneas de alta tensión (vanosten).

En otras palabras, ahora existe un grupo humano serio y sin precedentes, incluyendo mucha gente que son capaces de programar en C++ y compilar los fuentes. Por lo tanto, esto necesita ser coordinado entre todas las partes interesadas. Y tiene sentido no exponerlo al sistema Canvas, sino que disponer las correspondientes APIs tal que otros subsistemas y usuarios puedan acceder a estos y usarlos para los propósitos señalados arriba.

Es por eso que hemos creado un resumen de los principales esfuerzos relacionados con OSM de los últimos 18 meses. Sigue leyendo en Using OSM Vector Data in FlightGear...

FlightGear addons and mods

Bombable add-on updated to Version 4.5b

FlightGear add-on Bombable, which turns FlightGear into a full-featured combat flight simulator, was updated to version 4.5b on January 9th.

Highlights of the new version:

A-10 Warthogs in an AI Scenario running with the Bombable add-on.

• Improvements that help with FG 2.12 compatibility (particularly FG 2.12's new/improved way of handling AI scenarios)
• Improved version of the historically accurate Sopwith Camel (choose the JSBSim version of the Camel that is included in the package)
• Respawn scenario aircraft, vehicles, and ships either a single clump OR retaining their relative positions and altitudes
• Together with FG's new more flexible scenario system, this means you can load Bombable's scenarios instantly and move them to wherever you are in the world instantly--making it a lot quicker and more fun to run the Bombable AI scenarios. You're not stuck with doing scenarios in the one place they were originally set up--you can easily move them to anywhere in the world, while retaining the original scenario's general setup (bombers in a formation, fighter flying cover, tanks scattered around hillsides, etc)
• Improvements to AI aircraft realism, bug fixes.

Read more about Bombable or download the add-on from the forum topic

This very well explained video made by Jetman shows how to do a short flight mission from San Francisco (KSFO) intercepting an A-10 Warthog air patrol near Sausalito in a F-14 Tomcat running in FlightGear Bombable.

In the hangar

Updated aircraft

DC-10-30 Getting a Flightdeck Refit

David Waggoner, “DrDavid”

DC-10-30ER over Mt. Everest

A New Front Office for a Great Widebody Airliner

The DC-10-30 (by Ryan Miller) is getting an updated flightdeck with state of the art glass cockpit avionics. The purpose of the project is to create a theoretical refit of the aircraft as if Boeing/McDonnell-Douglas had continued to produce the airplane. The original instrument panel is historically accurate, but as FlightGear has evolved, the advances in avionics technologies have opened up a whole new universe for giving the pilot real-time situational awareness. It proved too good of a prospect to pass by.

The DC-10-30 makes a great platform for this kind of revision because of its sophisticated flight dynamics, autopilot and it is Rembrandt enabled. Rembrandt provides superior lighting capabilities both outside and inside the aircraft, but not all FG instruments are Rembrandt-compatible. Therefore, a new avionics package had to be functional in that environment.

State of the Project

Fortunately, the CRJ-700 Family Series (also by Ryan Miller) has a glass cockpit set up for Rembrandt. The PFD, MFD, EICAS, CDU, Radio Stack, Upper Light Switch Panel, and Side Panels were transferred from the CRJ700 to the DC-10-30. After much tweaking and trial and error, many, but not all of the CRJ’s screens are functional. In addition, a set of standby instruments have been added to support the three glass screens. Note there is cleanup work to be done on the panel—this is a work in development. The choice of instruments and layout are designed to meet my preferences, but that is expected to continue to progress. The two screenshots below illustrate the great effectiveness of having Rembrandt.

Rembrandt and Now the Canvas-Ready NavDisplay

A brilliant opportunity has popped up, in the mean time. The release of the new Canvas-ready NavDisplay screens, which will be developed by FlightGear over time to match specific aircraft, is now available. I am in the process of installing the ND in the DC-10’s MFD. Once a stable MFD is achieved, the aircraft will be uploaded into Git for the FlightGear Community to take a look at. I have a long TODO list for other improvements to the model, and will welcome other collaborators—I suspect you might have some ideas I haven’t even thought of that would be great to include. There is also the opportunity to create more liveries for the airplane.

• 
• 

McDonnell Douglas MD 902 Explorer

The McDonnell Douglas MD 902 Explorer had an significant improvement. Heiko Schulz made a brand new FDM for the MD 902. The helicopter has also a new cockpit with working instruments (most instruments are taken from the EC135). This helicopter has a role as light twin helicopter and makes use of a NOTAR system. So this is a helicopter without a tailrotor.

• 

  Screen shot showing the MD 902 in Polizei livery near EDMA.

• 

  The cockpit of the MD 902.

Updated JSBSim FDM for Sopwith Camel with historical features

A new JSBSim Flight Dynamics Model for the Sopwith Camel was Aircraft of the Month in May 2013. The FDM attempts to incorporate all known performance characteristics of the Camel documented in various historical accounts by pilots as well as published technical documents. Many of these documents and interesting historical accounts of the Camel can by found in the Docs directory of the release.

Now version 1.8 of the JSBSim FDM for the Camel has been released, taking into consideration feedback from users and making various improvements.

Find out more or download the Sopwith Camel from the forum topic

• 

  Sopwith Camels in an AI Scenario running with the Bombable add-on.

• 

  Sopwith Camels in an AI Scenario running with the Bombable add-on.

Scenery corner

Airports

Václav Havel Airport Prague

Works have been added to Václav Havel Airport Prague (LKPR) with a lot of hangars, terminals and other buildings. More information can be found on the dedicated wiki page: Václav Havel Airport Prague.

TerraSync has it all! You don't need to download a custom scenery.

• 

  The north apron of LKPR

• 

  The east apron of LKPR

Regional textures

Regional texture definitions for Iceland have been updated on GIT to match the newly available CORINE based version of Iceland in our World Scenery 2.0. Check it out - the place looks gorgeous now!

In addition, new regional texture definitions are also available for South Africa - view the famous table mountain near Cape Town and explore grasslands and lush vinyards between rugged hills!

Screenshot of the month

FlightGear goes back to space!

Arc top of a ballistic trajectory with the X-15 - 330.000 ft above Iceland, 600 km visibility range!

And falling down to Earth again:

And finally ...

Contributing

One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.

To learn more about how the project works, please see this short essay written by Thorsten, for a more detailed article see How the FlightGear project works.

YASim looking for a new maintainer

There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions. Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :) So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. Suggestions for that means in practice, are most welcome! Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working. — James Turner

I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my latencies here are measured in weeks. Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former. — Andy Ross