Es/FlightGear Newsletter November 2013
|
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.
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.
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.
Unirse como programador
Desafortunadamente, la mayoría de los desarrolladores activos de FG actualmente están muy agobiados con sus otras responsabilidades, lo cual afecta a cuanto realmente podemos hacer. Fundamentalmente, necesitamos más desarrolladores del núcleo.
Si estás interesado en aportar como un desarrollador del núcleo, por favor lee Comenzar como desarrollador del núcleo.
Internals de Nasal para hackers: internando símbolos
Aportado por Philosopher
Como algunos de ustedes, experimentados hackers de Nasal/C podrán recordar, o incluso aquellos familiarizados con los detalles de los lenguajes de script, los namespaces son sólo tablas de hashing con llaves que representan símbolos - correcto? Ok bien, practicamente, pero cada uno de esos símbolos son únicos en una forma distinta a todos los otros strings que hay ahí afuera: ellos son internos. (El interning es un proceso que toma strings y un diccionario y retorna una cadena coincidente, añadiendo uno si es necesario). Eso significa que las cadenas iguales son sustituidas tal que tienen el mismo puntero, por ejemplo, un string representa todas las instancias de "io", almacenado en un pool/hash de todos los símbolos usados.) Aunque estas cadenas internadas aparecen en tiempo de ejecución en las keys de los namespaces, ellas se crean durante la generación del código (codegen), donde los símbolos (TOK_SYMBOL) que son convertidos a cadenas Nasal, son internadas para obtener la cadena correcta (usando el globals->symbols hash), y son almacenadas en el bloque de constantes de naCode. Desde allí, los symbol-strings son usados para establecer y obtener varios lvalues (ambos simbolos locales/globales y miembros de objeto) en una forma optimizada (esa es la idea principal del ejercicio). Mirando el hash.c, hay varias funciones especializadas que hacen uso de potenciales optimizaciones:
- naiHash_sym (busca un símbolo internado)
- naiHash_newsym (añade un símbolo en el primer slot vacío del hashcode)
(Hay otro que se parece, naiHash_tryset, pero este no maneja símbolos internados: este usa el método findkey(), el cual a su vez usa el método equals() que comprueba una llave de igualdad más general en vez de simplemente la igualdad de punteros.)
Lo primero, naiHash_sym, es bastante claro y el supremo ejemplo de la optimización: este corre los slots del hashcode, comprobando sólo la igualdad de punteros (nótese que el hashcode de los símbolos internados son calculados durante la internación, por lo que es otro paso que no es necesario realizar en tiempo de ejecución). naiHash_newsym es otra buena optimización pero un poco problemática, debido a que asume que la llave ya no existe. Básicamente se utiliza para añadir otro argumento como una llave local, pero no le importa si ya existe, sólo ve un slot ocupado y continúa. Considera el siguiente ejemplo que ilustra la llamada con un argumento en un hash que ya tiene la llave del argumento en él:
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=[]Esto mostraría:
arg arg nil
Esto muestra que la llave está siendo establecida dos veces (lo cual viola la condición de las tablas de hashing): una vez como argumento y otra vez para crear una llave existente en el espacio de nombres. El primer set es el que está siendo recogido (por ejemplo, el arg en {arg:nil} versus el arg... que iguala []). Y este comportamiento persiste incluso a través del redimensionado: hashset() (el cual es usado para reiniciar un hash después de la redistribución) sólo sigue añadiendo llaves en slots vacíos, tal que el número de llaves no cambia (incluso si hay varias de la mismas llaves).
Por esta razón, sugeriría modificar el naiHash_newsym para comprobar la igualdad de punteros de las llaves antes de continuar; de esa forma los símbolos no son "pisados" como acá. (Por favor considera que si "arg" existe en el hash como un no-internado, entonces éste será pisado de todos modos; tener que buscar símbolos no internados principalmente violaría el punto de la optimización en este paso, y a la larga realmente no importa.) Yo sostendría que encontrar una llave existente (¡unas simples comparaciones de punteros!) generalmente sería más eficiente, porque el hash nunca necesitaría ser redimensionado si encuentra uno existente, mientras que la vieja versión añadiría de todas formas. (Creo que una vez conté más de cien símbolos "arg" in the namespace __js0 desde el continuo lanzamiento de vínculos, lo cual obviamente no es bueno.)
Continúa leyendo en [1].
Addons y mods para FlightGear
Nuevas texturas y luces para edificios aleatorios
Las luces urbanas trabajan usando un sombreado urbano modificado + efecto urbano modificado, los archivos modificados necesitan ser mejorados para hacer funcionar el sombreado urbano original cuando la función de edificios aletorios está desactivada y habilitar el nuevo sombreado cuando la función de edificios aleatorios está activada.
Instalación:
- Descargar desde acá
- Descomprimer el archivo
- Copia, pega y reemplaza
- urban.eff en $FG_ROOT/Effects/
- urban.frag , urban-gbuffer.frag y urban-lightfield.frag en $FG_ROOT/Shaders/
- buildings.png y buildings-lightmap en $FG_ROOT/Textures/
- Sugiero cambiar la densidad de los edificios aleatorios a la mitad de la configuración por defecto de tu equipo, puedes hacerlo editando el archivo autosave.xml o autosave_2_12.xml (dependiendo de tu versión), en la línea "<building-density type="double">1</building-density>"
Si quieres volver a los efectos por defecto, por favor descarga este paquete y sigue las instrucciones de instalación nuevamente.
En el hangar
Tupolev Tu-134
El equipo de desarrollo del Tupolev Tu-134 orgullosamente anuncia una nueva línea aérea soviética para FlightGear! Algunos ya han leído el topic acerca de él en el foro. El lanzamiento de la versión 1.0 está disponible para descargar desde acá. Esta aeronave YASim tiene un muy buen FDM, bello exterior y una carlinga básica. Para aportar (a mejorar la carlinga, por ejemplo) contactanos en el foro.
Muchas gracias a Helijah, Buckaroo y Cossack90.
No una aeronave sino un crucero, Oasis de los Mares ha sido lanzado al público, estas naves y ferries vienen del Hangar ACJZA también! Si tienes alguna habilidad para programar, estaré agradecido de que me puedas ayudar. La descarga y más información la encontrarán en el foro.
Eurocopter EC130-B4 Ecostar
El helicóptero Eurocopter EC130 B4 está a poco de una nueva gran actualización. El modelo existente, el cual ya tenía una muy alta calidad, ha sido refinado en varios aspectos con mucho esfuerzo de mhab. El modelo exterior ha sido enriquecido a un grado que justificaría una votación de 5* y un cambio del estatus de la aeronave a "production".
El Rotorhead ha sido llevado a un nuevo nivel de detalle, y un Fenestron completamente detallado fue añadido y las animaciones fueron introducidas a todas las partes móviles.
La carlinga fue enriquecida para los controles del piloto/copiloto, ahora los asientos son texturados y una configuración de cabina variable permite montar una variante Servicios Médicos de Emergencia (EMS), el cual viene preconfigurado con una nueva librea de N130NE MedFlight (Ohio).
Los fanáticos de Helicópteros Gran Cañón" ahora encontrarán una librea del N155GC y la colorida pintura rojo/dorado.
Un montón de equipo (la mayoría del cual estaba ahí pero escondido) ahora puede ser usado, incluyendo un verdadero foco SX16-Nightsun.
Todo esto ha sido realizado en una configuración completamente integrada para ser manipulado mediante una ventana que permite cambiar las libreas, combustible, vistas extras, pesos, configuración de cabina y equipamiento.
Los artilugios extras incluyen un piloto completamente animado, reflejos en las ventanas y parabrisas frontal, y el rotor variable dependen de la fuerza de la corriente descendente.
Si no puedes esperar hasta el lanzamiento, dale un vistazo al Git-Hangar
Un primer plano del Fenestron completamente detallado
EC130 equipado con patines para nieve y gancho
EC130 Cabina y controles del piloto del Grand Canyon Helicopters
EC130 Configuración de cabina EMS con camilla
EC130 puerta de equipaje
EC130 controles del piloto
Alguno de los cambios más interesantes:
- Rotor Principal completamente animado y adaptado al original
- Fenestron completamente diseñado y animado, incluyendo barra de control
- Controles de la carlinga añadidos: cíclico, colectivo, pedales, controles del co-piloto (opcional)
- Puertas móviles
- Reflector
- Patines para nieve
- Gancho/monta cargas
- Listas de comprobación implementado con pantallas condicionales
- Piloto: completamente animado
- Auto-arranque/Auto-parada habilitado después de 15 vuelos
- Flujo del rotor modificable entre apagado, bajo, medio y alto
- Sonido mejorado movimiento de puertas, rpm del motor altas y bajas, advertencia de sobre velocidad, y ruido en la carlinga que depende de si las puertas y ventanas están abiertas o cerradas.
Ventanas de configuración y pantallas de ayuda:
EC130 Ventana de configuración completamente integrada.
EC130 Ventana de ayuda con todos los atajos e información adicional
EC130 Configuración de la ayuda con explicación de dependencias
EC130 Opciones de simulación
Mejoras para FG 3.0:
- Soporte para Rembrandt
- Corrección de errores
Actualizaciones de la wiki
Se necesitan traductores
|
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. |
Y finalmente ...
Contribuir
Una de las ideas comunes expresadas en los foros de FlightGear es "Me gustaría aportar pero no sé programar, y no tengo tiempo". Desafortunadamente, hay una idea errónea generalizada respecto a que contribuir requiere programar y mucho tiempo libre. De hecho, hay De hecho, hay una gran variedad de formas de contribuir al proyecto sin necesidad de escribir código o gastar días trabajando en algo.
Para obtener ideas sobre cómo comenzar a contribuir con FlightGear, tal vez desees revisar esta sección: Voluntarios.
Para aprender más acerca de cómo trabaja el proyecto, por favor revisa este breve ensayo escrito por Thorsten, y para un artículo más detallado revisa Cómo funciona el proyecto FlightGear.
Llamado a voluntarios
- El equipo Target4Today está buscando voluntarios para ayudar a mejorar el soporte de combate de FlightGear.