Es/FlightGear Newsletter November 2013

From FlightGear wiki
Revision as of 07:34, 2 December 2013 by Wallkon (talk | contribs) (The Walker: traducido)
Jump to navigation Jump to search
Magagazine.png
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 alguna aeronave, porfavor siéntete invitado a añadir esas noticias al boletín.

Noticias del proyecto

Dispersión de Luz Atmosférica

El framework de renderizado de Dispersión de Luz Atmosférica (ALS, de Atmospheric Light Scattering), el cual adopta una técnica que recientemente ha sido introducida por defecto, y el framework de renderizado Rembrandt permiten utilizar un mapa global de la profundidad del océano. Esto posibilita el dibujar las aguas poco profundas alrededor de las islas de una forma realista. Combinado con la posibilidad de ALS de cambiar el color básico del agua basado en la ubicación y condición climática o apariencia del cielo, ahora es posible dibujar varias combinaciones de aguas poco profundas, contenido de lodo y condiciones climáticas mediante un mayor detalle del efecto de sombreado del agua.

Mapeo de la profundidad del agua en ALS

Integración inicial de OsgEarth

Gracias al reciente trabajo de un usuario del foro, poweroftwo, ahora tenemos una integración inicial de osgEarth mediante una opción seleccionable en tiempo de ejecución para la escena del terreno. Una vez activado, osgEarth dibuja el terreno construyendo las geometrías texturadas en tiempo de ejecución desde las imágenes en bruto y los datos de elevación. El tiempo de carga para un lugar no visitado es sorprendentemente rápido si se tiene una velocidad de bajada de Internet adecuada. Para ubicaciones previamente visitadas, se guarda un archivo optimizado de datos en caché para una carga rápida.

Los datos de entrada pueden venir de una variedad de fuentes incluyendo servicios web de mapeo o fuentes de datos locales (por ejemplo, geotiff) almacenados en disco. Una vez que el dibujado es activado, toda la escena del terreno de FlightGear es reemplazada, así como las consultas de elevación de la escena. Sin embargo, la implementación del terreno nativo permanece completamente intacto y puede ser restaurada deshabilitando osgEarth desde su ventana de configuración.

Los beneficios obtenidos de esta integración inicial de osgEarth incluyen el dibujado de imágenes geo-específicas en tiempo real desde una variedad de fuentes que están disponibles mundialmente; terreno en mosaico a demanda; y vistas a gran altitud desde cualquier lugar de la Tierra. Sin embargo, esta implementación con FlightGear incluye algunas limitaciones importantes listadas en la sección de acuerdos.

Aprende más en el tema del foro.

Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure

Demo de MapStructure
NavDisplay
Instancias independientes de NavDisplay en el 777-200ER de Hyde

En un esfuerzo conjunto, el código NavDisplay/Canvas original de Gijs del Boeing 747-400 (programado completamente con Nasal; mira el boletín de octubre) por ahora ha sido suficientemente generalizado para ser usable en otra aeronave sin tener que copiar/pegar un montón de código (normalmente, ahora serán alrededor de 30 líneas).

El Boeing 777-200ER de Hyde es el primero en adoptarlo por ahora, con la ventaja extra de que el 777-200ER ahora también soporta instancias independientes de ND, por ejemplo, pantallas e interruptores independientes para cada piloto. Hyde, también está planeando implementar características faltantes específicas del 777.

Por ahora, Philosopher y Hooray han comenzado a trabajar en un framework Nasal llamado MapStructure, para crear fácilmente pantallas de cartas como el NavDisplay, tal que se necesite muy poco código Nasal especializado. Cuando el framework MapStructure esté completo, trabajaremos en vista de portar nuestros viejos archivos *.layer/*.draw/*.model para hacer uso del nuevo framework MapStructure y adaptar el framework NavDisplay conjuntamente.

MapStructure va a ser la base común para todas las necesidades gráficas de FlightGear, no sólo en instrumentos (por ejemplo, pantallas multifunción MDF como el NavDisplay), sino también en ventanas (Map, consola del instructor, ATC, etc).

Actualmente, aún hay algunos problemas de rendimiento menores (especialmente en computadores menos potentes), los cuales esperamos resolver al mover algunas partes al espacio C++, con la esperanza de que esté para la versión 3.0 (nuestros chicos Canvas/C++, TheTom y Zakalawe, están trabajando para eso).

Por favor, contáctate si tienes alguna pregunta o si te gustaría unirte en alguna forma.

Comenzando con CppBind

Nasal, el lenguaje de scripting integrado en FlightGear, viene con un conjunto de librerías estándar y puede ser extendido usando las APIs específicas de FlightGear.

Hasta FlightGear 2.8, el motor de scripting de Nasal sólo entragaba una API C para exponer ciertos vínculos (hooks, bindings) al espacio de scripting o para exponer estructuras de datos del espacio de scripting de regreso a C/C++.

Exponer el aspecto interno del simulador a un espacio de scripting es un asunto útil y bastante común, porque permite a los desarrolladores del paquete base acceder a estas partes internas sin tener que compilar FlightGear desde los fuentes, tal que la barrera de entrada es significativamente menor y hemos visto un incremento en el número de características novedosas implementadas completamente en el espacio de scripting, gracias a las poderosas APIs disponibles para desarrolladores de aeronaves y del paquete base.

A diferencia del núcleo de Nasal, el cual está escrito en C, FlightGear está programado y siendo escrito principalmente en C++. Eso significa que, hace un tiempo, la API Nasal fue casi de "bajo nivel" y a veces también complicado de usar al crear funciones, estructuras de datos u objetos accesibles entre C++ y Nasal.

Gracias al sistema Canvas de Tom, ahora hay un nuevo framework de vínculos que se encuentran en simgear/nasal/cppbind. Es completamente orientado a objeto y soporta características modernas de C++.

Notarás que la mayoría del código "antiguo" en $FG_SRC/Scripting aún usa esas viejas APIs-C para interactuar con el motor Nasal. Sólo el nuevo código, #include'ing <simgear/nasal/cppbind>, usa las plantillas potenciadas que esconden los detalles de bajo nivel.

La mayoría del código en el subsistema Nasal (FGNasalSys) también aún usa las APIs de C antiguas - esto es sólo para explicar las dos soluciones, para evitar confusiones innecesarias. Las antiguas APIs de bajo nivel las encontrarás explicadas en Howto:Extend Nasal.

El framework CppBind es mucho más genérico y de alto nivel que las APIs C puras, cppbind incluye soporte para pruebas unitarias y hace uso de características modernas de C++ como templates y soporte STL, incluyendo tipos específicos de SimGear como SGPath/SGGeod, etc, su gasto es bastante pequeño (no sólo rendimiento, sino también líneas de código para crear nuevos vínculos). El framework cppbind ya es extensamente usado por el sistema Canvas y los vínculos NasalPositioned_cppbind, ambos muy buenos lugares para buscar ejemplos de código.

Continúa leyendo en Nasal/CppBind...

Trabajo de Validación del Modelo de Dinámica de Vuelo JSBSim

JSBSim (uno de los modelos de vuelo presentes en FlightGear) actualmente está siendo validado en función de un conjunto de simulaciones en varios centros de la NASA. Un conjunto de casos de verificación está bajo desarrollo y se espera que sean publicados el próximo año. Los casos de verificación son numerosos y rigurosos, y abarcan escenarios atmosféricos y orbitales. Las primeras comparaciones entre JSBSim y las otras simulaciones muestran una muy buena concordancia para las pruebas atmosféricas realizadas hasta ahora.

Nuevo Componente del Sistema de Control en JSBSim

Un nuevo componente del sistema de control ha sido añadido recientemente a JSBSim. Este es llamado el componente distribuidor. Este artículo es una introducción rápida al componente distribuidor, e incluye una descripción de una forma en la que ha sido usada. Sabemos que el componente switch posee un valor por defecto, tal que el switch toma ese valor por defecto si ninguna de las condiciones de prueba se cumple. Además, la primera condición de prueba que resulta verdadera determina el valor que toma el switch. Con el componente distribuidor, el componente no toma un valor por sí mismo (de hecho, el valor del componente - el cual todavía debe ser indentificado - es siempre cero).

La sintáxis exacta del componente distribuidor es la siguiente:

<distributor name="name/is/irrelevant" type="exclusive|inclusive">

  <case>
    [<test logic="{AND|OR}" value="{property|value}">
      {property} {conditional} {property|value}
      <test logic="{AND|OR}">
        {property} {conditional} {property|value}
        ...
      </test>
      ...
    </test>]
    <property value="number|property"> property_name </property>
    ...
  </case>

  ... <!-- Casos opcionales adicionales -->

</distributor>

Este es uno de los más potentes, pero complejos, componentes en el conjunto de componentes de control de JSBSim. El componente distribuidor posee uno o más elementos <case>. Cada <case> puede contener un elemento <test> (el cual puede contener sentencias de prueba condicional, o uno o más <test> anidados). Además, cada <case> tendrá una o más propiedades con un valor a ser establecido. Un elemento <case> sin <test>'s siempre será ejecutado (los valores de sus propiedades son según se estableció). Un componente distribuidor puede tener tener un tipo exclusivo o inclusivo. Un distribuidor exclusivo sólo ejecutará el primer elemento <case> que resulte verdadero. Un distribuidor inclusivo, ejecutará todos los elementos <case> para el cual la prueba resulte verdadera. En ambos casos, todos y cada uno de los elementos <case> que no tengan test siempre serán ejecutados en el orden en que son encontrados. Cada elemento <case> tendrá uno o más valores de propiedad a ser fijadas, y cada elemento <case> no necesita poseer el mismo conjunto de propiedades a ser establecido.

Este componente es muy útil in casos donde (por ejemplo) la guía, navegación y leyes de control están definidos, donde - para ciertos modos de operación - varias estrategias de sistemas de control y valores objetivo deben ser fijados simultáneamente. El componente distribuidor puede también servir como una suerte de relé, presentando un elemento <case> sin test, y varios elementos <property>. Acá hay un ejemplo donde se podría tener un conjunto de “modos” secuenciales que un vehículo de lanzamiento podría recorrer en orden ascendente:

<?xml version="1.0"?>
<!DOCTYPE system [
  <!ENTITY Off "0">
  <!ENTITY On  "1">
  <!ENTITY InitialRise  "1">
  <!ENTITY GravityTurn  "1">
  <!ENTITY EngineCutoff "2">
  <!ENTITY RateHold     "0">
]>
<system name="Demo Rocket Guidance Executive"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://jsbsim.sf.net/JSBSimSystem.xsd"
        xsi:noNamespaceSchemaLocation="http://jsbsim.sf.net/JSBSimSystem.xsd">

  <property value="0"> executive/mode </property>
  <property value="0"> executive/clock/advance-burn-clock </property>
  <property value="1"> executive/clock/advance-met-clock </property>
  <property value="0"> guidance/pitch/rate-target-rad_sec </property>
  <property value="0"> guidance/yaw/rate-target-rad_sec </property>
  <property value="0"> guidance/roll/rate-target-rad_sec </property>

  <channel name="Executive Mode Sequencer">

    <integrator name="executive/clock/mission-elapsed-time">
      <input> executive/clock/advance-met-clock </input>
      <c1> 1 </c1>
    </integrator>

    <integrator name="executive/clock/elapsed-burn-time">
      <input> executive/clock/advance-burn-clock </input>
      <c1> 1 </c1>
    </integrator>
    
    <distributor name="executive/sequencer" type="exclusive">

      <case>
        <test>
          executive/clock/mission-elapsed-time gt 0.1
          executive/mode eq &Off;
        </test>
        <property value="&InitialRise;"> executive/mode </property>
        <property value="&On;"> propulsion/engine[0]/throttle-cmd </property>
        <property value="&On;"> propulsion/engine[1]/throttle-cmd </property>
        <property value="&RateHold;"> control/pitch/mode </property>
        <property value="&RateHold;"> control/roll/mode </property>
        <property value="&RateHold;"> control/yaw/mode </property>
        <property value="&On"> executive/clock/advance-burn-clock </property>
      </case>

      <case>
        <test>
          executive/clock/mission-elapsed-time ge 10
          executive/mode eq &InitialRise;
        </test>
        <property value="&GravityTurn;"> executive/mode </property>
        <property value="-0.05"> guidance/pitch/rate-target-rad_sec </property>
      </case>

      <case>
        <test>
          executive/clock/mission-elapsed-time gt 122
          executive/mode eq &GravityTurn;
        </test>
        <property value="&EngineCutoff;"> executive/mode </property>
        <property value="&Off;"> propulsion/engine[0]/throttle-cmd </property>
        <property value="&Off;"> propulsion/engine[1]/throttle-cmd </property>
        <property value="&Off;"> executive/clock/advance-burn-clock </property>
      </case>

    </distributor>

  </channel>

Como puedes ver, cada modo ocurre secuencialmente y provoca que un número de propiedades sea fijada en cada elemento <case>. Nótese también las definiciones usadas en los elementos y atributos - estos pueden ser usados para hacer el código más legible y comprensible. Definiciones (similar a #defines en C/C++) son declarados al principio del archivo usando el constructor !ENTITY.

Cambios en el repositorio FGRun

El repositorio Git FGRun ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama next, mientras que las ramas release/X.X son creadas para cada versión. Además, el número de versión de FGRun ahora está sincronizado con FlightGear/SimGear, para poder ver más fácilmente si tus compilaciones de FGRun y FlightGear coinciden.

El Walker (transeúnte)

El Walker o transeúnte, actualmente está siendo portado para ser fácilmente incorporado en una aeronave arbitraria. Adicionalmente, está en desarrollo un modelo de piloto animado para la carlinga. El Walker y la tripulación soportarán diferentes poses de manos, tales como apuntar, puño, gesto de aprobación o signo de victoria.

La transeúnte femenina El transeúnte masculino

Un modelo de piloto, copiloto y tripulación están por llegar. Poses de manos que serán seleccionables en la ventana de animación

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.

Nasal Internals for hackers: Intern'ing symbols

Contributed by Philosopher

As some of you experienced Nasal/C-code hackers should recall, or even those familiar with scripting languages internals, namespaces are just hashes, with keys representing symbols - right? Well yes, mostly, but each of those symbols are unique in a way from all of the other strings out there: they're interned. (Interning is a process that takes strings and a dictionary and returns a matching string, adding one if needed. That means equal strings are substituted so they have the same pointer, i.e. one string represents all instances of "io", stored in a pool/hash of all used symbols.) Though these interned strings appear at runtime in the keys in namespaces, they get created during code generation (codegen), where the symbols (TOK_SYMBOL) get converted to Nasal strings, are interned to get the correct string (using the globals->symbols hash), and are stored in the naCode's constants' block. From there, the symbol-strings are used to set and get various lvalues (both local/global symbols and objects' members) in an optimized way (that's the whole point of the exercise). Looking at hash.c, there are some specialized functions that make use of the potential optimizations:

  • naiHash_sym (looks up an interned symbol)
  • naiHash_newsym (adds a symbol in the first empty slot for the hashcode)

(There's another that looks similar, naiHash_tryset, but it does not deal with interned symbols: it uses the findkey() method, which in turn uses the equals() method that checks for more general key equality instead of simple pointer equality.)

The first, naiHash_sym, is pretty neat and the prime example of the optimization: it runs through a hashcode's potential slots, checking only pointer equality (note that interned symbols' hashcodes are computed during interning, so that's another step that doesn't have to be done are runtime). naiHash_newsym is another nice optimization but a little problematic, due to its assumption that the key doesn't exist already. It's basically used for adding another argument as a local key, but it doesn't care about if it exists already, it just sees an occupied slot and keeps going. Consider the following example that illustrates calling with an argument into a hash that already has the argument's key in it:

var f_creates_arg = func(arg...) {
    foreach (var k; keys(caller(0)[0]))
        print(k);
    debug.dump(arg);
}
call(f_creates_arg, nil, nil, {arg:nil}); # call into namespace: arg=nil; with arguments of: arg=[]

This should print:

arg
arg
nil

This shows that the key is being set twice (which violates a normal precondition of hashes): once as an argument and once to create an existing key in the namespace. The one set first is the one being picked up (e.g. the arg in {arg:nil} versus the arg... that equals []). And this behavior persists even through resizing: hashset() (which is used to reinitialize a hash after reallocation) only keeps appending keys in empty slots, so the number of keys doesn't change (even if there are multiple of the same keys).

For this reason, I would suggest amending naiHash_newsym to check keys' pointer equality before continuing; that way symbols aren't "trodden" over like this. (Please note that if "arg" exists in the hash as non-interned, then it will be trodden over anyways; having to look for non-interned symbols would mainly violate the point of the optimization at this step, and doesn't actually matter in the long run.) I would argue that finding an existing key (a few simple pointer comparisons!) would be more efficient generally, because the hash would never need to be resized if an existing one is found, whereas the old version would append regardless. (I think I once counted well over a hundred "arg" symbols in the __js0 namespace from the continual firing of bindings, which obviously isn't good.)

Continue reading at [1].

FlightGear addons and mods

New textures and lightmaps for random buildings

Lightmap terrain at noon
Lightmap terrain at night

The urban lightmap works using a modified urban shader + modified urban effect, the modified files need to be improve to make work the original urban shader when the random building function is off and enable new shader when the random building function is on.

Installation:

  1. Download from here
  2. Unzip the file
  3. Copy, paste and replace
    • urban.eff at $FG_ROOT/Effects/
    • urban.frag , urban-gbuffer.frag and urban-lightfield.frag at $FG ROOT/Shaders/
    • buildings.png and buildings-lightmap at $FG ROOT/Textures/
  4. I suggest to change the random building density to the middle of your computer default settings, you can make this by edit at autosave.xml or autosave_2_12.xml (depend your version), at the line "<building-density type="double">1</building-density>"

If you want to go back to the default effects, please download this package and follow the installation instructions again.

In the hangar

Tupolev Tu-134

The "whistle" taking speed for take-off.
You can choose one of the 3 noses.

The Tupolev Tu-134 development team proudly announce a new soviet airliner for FlightGear! Some have already read a topic about it at the forum. The release of version 1.0 is available for download from here. This YAsim aircraft has a very good FDM, great exterior and a basic cockpit. To contribute (improve the cockpit for example) contact us at the forum

Many thanks to Helijah, Buckaroo, Cossack90.

New aircraft

Not an aircraft but a cruise ship, Oasis of the Seas has been released to the public and getting updates, it's sister ships and ferries are coming in from the ACJZA Hangar as well! If you have any skill with coding, it'll be thankful if you could help me. More information and download at the forum topic

Updated aircraft

Eurocopter EC130-B4 Ecostar

The EMS variant of EC130-B4, used by MedFlight, Ohio, USA
New Livery of Grand Canyon Helicopters
Closeup of EC130 Mainrotor, fully animated in all details
EC130 Helicopter using the SX-16 Nightsun searchlight
Even the pilot window can be opened now

The Eurocopter EC130 B4 helicopter is on short final for a new major upgrade. The existing model, which already had been of very high quality, has been refined in various aspects with lots of effort by mhab. The outside model has been enriched to a degree which should justify a 5* rating and the overall status of the aircraft improves to "production".

The Rotorhead has been brought to a new level of detail, a full detailed Fenestron was added and animations were introduced to all moving parts.

Cockpit was enriched for Pilot/Copilot controls, seats are textured now and a variable cabin configuration allows to set up an Emergency Medical Services (EMS) variant, which comes preconfigured with a new Livery of N130NE MedFlight (Ohio).

Fans of Grand Canyon Helicopters now find a livery of the N155GC and the colorful painting in red/gold.

A lot of equipment (most of which was there already but hidden) can now be used, including a full blown SX16-Nightsun searchlight.

All of this has been brought together in a fully integrated configuration dialog which allows to set-up livery, fuel, extra views, weights, cabin setup and equipment.

Extra gimmics include a fully animated pilot, glass reflection on windows and front shield and variable rotor wakes depending on the strength of the downwash.

If you can't wait for the next release check it out from the Git-Hangar

Some of the most interesting changes:

  • Mainrotor fully animated and adapted to original
  • Fenestron fully designed and animated, incl. control rod
  • Cockpit Controls added: Stick, Collective, Pedals, Co-Pilot Controls (optional)
  • Doors movable
  • Searchlight
  • Snowshoes
  • Hoist/Hook
  • Checklists implemented with conditional display
  • Pilot: fully animated
  • Autostart/Autoshutdown enabled after 15 flights
  • Rotor-Wakes off-low-medium-high cyclable
  • Sound improved (doors moving, low/high rotor rpm, overspeed warning, and noise inside depends on open doors/window)


Configuration Dialogs and Help Screens:

Things on stack for FG 3.0:

  • Rembrandt support
  • BUG fixing

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.

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 Target4Today team is looking for volunteers to help improving FlightGear's combat support