Es/FlightGear Newsletter December 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
Integración con osgEarth
Este video muestra un vuelo corto desde Raron (LSTA) hasta Sion (LSGS) en Suiza, en un Robin DR400 mediante FlightGear. La escena del terreno es generada desde la librería de C++ osgEarth, que genera en tiempo real toda la Tierra. El terreno generado por osgEarth puede ser activado o desactivado mientras se vuela.
En este ejemplo, las imágenes del terreno son enviadas desde ArcGis WMS (Web Mapping Service, o Servicio Web de Mapas). osgEarth soporta una amplia variedad de fuentes desde donde obtener las imágenes del terreno.
Actualmente, osgEarth está integrado en una rama de desarrollo para la versión 2.99 de FlightGear. Los cambios de integración, actualmente están siendo enviados para aprobación para la próxima mayor versión de FlightGear.
Gijs, ha comenzado a extender el framework NavDisplay para soportar modos de pantalla adicionales, que comúnmente se pueden encontrar en aeronaves modernas de Boeing:
Modo MAP
Modo MAP centrado
Modo PLAN
Cuando se llega al desarrollo de una aeronave, una de las áreas que la gente considera frustrante es que las características usadas por los desarrolladores de aeronaves serán documentadas en la Wiki, pero los detalles son tan mínimos que puede ser difícil o casi imposible conseguir que algo funcione porque a los ejemplos publicados les faltan detalles o no muestran importantes variaciones sobre cómo programar cierta característica.
Hemos llegado a la conclusión de que, el mejor paso hacia la solución de estos problemas, es tener un conjunto de plantillas para configuraciones comunes de aeronaves (mono propulsor, multi propursor, mono reactor, multi reactor con copiloto, etc). Estas plantillas tendrían todos los componentes mínimos para armar una aeronave para "producción" (de acuerdo a la guía de calificación).
Hemos estado considerando esa idea por un tiempo, por ejemplo, mantener un proyecto de "plantillas" para cosas como aeronaves, para así asegurar que la gente tenga alguna forma de guiarse sin apoyarse excesivamente en el copiar/pegar - en realidad sólo necesitamos alguien que comience con una aeronave "de prueba", con muchos comentarios y opciones (Nasal, sonidos, canvas, ayudas, checklists, tutoriales). De hecho, sería incluso posible proporcionar asistentes (wizards) para ayudar a personalizar esas plantillas, por ejemplo, para cambiar nombre/autor/status, modelos 3D, nombres de archivo (sonidos, texturas).
La idea es que podríamos tener un conjunto de plantillas estándar para aeronaves, o algún medio más sofisticado para generar skeletons de aeronaves basadas en datos ingresados por el usuario. Estas plantillas tendrían todos los archivos necesarios y el código para implementar una simple pero completa aeronave de una configuración determinada (mono motor, multi reactor, etc), y posiblemente los stubs para mejoras comunes. Mejoras estándar (checklists, pilotos automáticos, etc) podrían ser incluidas como comentarios, indicando dónde el código necesita ser añadido. Esto haría que las aeronaves de FG fueran más consistentes, pero también ayuda a los desarrolladores de aeronaves primerizos a superar el obstáculo inicial de entender cómo unir todo. Pienso que esto nos ayudaría a salvar el problema de tener tantos aviones en varios estados de pre-producción.
Durante la discusión en el foro, llegamos a la idea de poder tener una plantilla de aeronave y parametrizarla dinámicamente al interior de FlightGear - después de todo, el 95% está programado como un XML PropertyList, por ejemplo, puede ser leído/manipulado y escrito por medios estándar de FlightGear/Nasal - en otras palabras, podrías tomar una ventana PUI existente y convertirla en un "asistente para aeronaves", donde el usuario podría especificar cosas como 1) nombre del archivo, 2) descripción, 3) tipo de FDM, 4) status, 5) miniatura (thumbnail) y así sucesivamente - todo esto es sencillo de hacer, simplemente implica usar setprop() después de haber volcado el template en el property tree mediante io.read_properties(), en cuyo punto podría mostrarse una simple interfaz de usuario para agilizar el proceso de desarrollo de aeronaves en un estilo "paso a paso" (como un wizard). La mayoría del código ya existe, incluyendo una ventana para seleccionar el archivo - lo que falte puede ser implementado mediante extensiones de Canvas.
Idealmente, este asistente no debería ser implementado como un diálogo XML "hardcodeado", sino más bien como un sub módulo de Nasal que dinámicamente crea "páginas" para cada paso en el asistente. Nada de esto es difícil, en realidad sólo involucra 1) el árbol de propiedades, 2) leer/escribir las propiedades mediante io.nas y 3) Nasal básico (setprop/props.nas) para modificar el template de la aeronave. Además, el asistente podría fácilmente programarse para reconocer las versiones de FG, y los usuarios ingresarían este dato en el asistente para, por ejemplo, omitir ciertas características como soporte para Canvas, o efectos, etc.
Un primer prototipo, muy básico, está disponible y esperando a ser adoptado por algún colaborador de la comunidad para ayudar a hacer crecer este "asistente", por ejemplo, añadiendo funciones, pero también agregando nuevos templates, para diferentes características de las aeronaves, tales como checklists, tutoriales, vistas, etc.
Dado que la mayoría de nosotros ya parecemos malabaristas con tantos proyectos, estamos buscando gente a los que les gustaría unirse a este de alguna forma.
Referente al código, actualmente son sólo cerca de 150 líneas de código Nasal muy simple, copiado de varios otros diálogos y tutoriales de la wiki. Por lo tanto, saber Nasal sería un plus, pero si tienes cualquier otra experiencia en programación/scripting, eso también servirá. Entonces, si estás interesado en programar para Flightgear y simplificar el desarrollo de aeronaves para los principiantes, por favor contáctanos mediante el foro o la wiki.
Continúa leyendo en Aircraft Generation Wizard...
Implementando VNAV - Una lluvia de ideas
Recientemente, hemos tenido otra discusión en el foro acerca de implementar VNAV (Vertical Navigation) en FlightGear. En comparación con otros simuladores de vuelo, desde el primer día a FlightGear le ha faltado soporte para simular funciones VNAV comunes en muchos aviones modernos.
Hasta ahora, el consenso general ha sido que simplemente no es posible implementar adecuadamente VNAV en FlightGear porque VNAV depende de datos de rendimiento específicos de la aeronave para proporcionar los cambios de cabeceo/empuje adecuados para cumplir los límites de altitud/velocidad/tiempo calculados por VNAV, lo que en realidad se reduce a una falta de apoyo de los FDMs (JSBsim/YaSim).
Como proyecto abierto, no tenemos acceso a los correspondientes datos de vuelo o tales datos de performance, e incluso si los tuvieramos, probablemente no podríamos hacer uso fácil de tales datos debido a su naturaleza propietaria.
Además, una base de datos de performance real probablemente no nos serviría de mucho, porque nuestras configuraciones de FDM también son a la medida - por ejemplo, los datos de rendimiento necesitarían coincidir con los de la aeronave simulada.
Así, una base de datos de performance idealmente sería proporcionada por el propio FDM. Ya sea en una forma pre-creada, por ejemplo compilada durante una "prueba de vuelo" offline, o de preferencia durante la ejecución corriendo una simulación del FDM al interior del FDM real.
Hemos comenzado a recopilar toda la información de discusiones anteriores acerca de VNAV para llegar a una tormenta de ideas y determinar cómo implementar los componentes que se requieren para soportar VNAV en FlightGear (YaSim/JSBSim). Cualquier aporte será muy agradecido.
Continúa leyendo en Implementing VNAV support in FlightGear...
Alternativa para el control de la cámara
Marius_A, usuario de la comunidad de FlightGear, ha creado una cámara virtual para FlightGear que está escrita en Nasal, la cual añade funciones similares al addon para FSX: la cámara EZdok.
Continúa leyendo en el foro...
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.
Compilando los fuentes
Gracias al trabajo de Seatbutler, el artículo Cómo Compilar FlightGear con NetBeans usando CMake ha sido actualizado y se verificó que aún funciona.
Desarrollo de Hardware
Proyecto computer2cockpit
Siguiendo los cambios de diseño sugeridos por los usuarios de FlightGear, el diseño del mando del computer2cockpit se ha ampliado con:
- Un soporte para mapas
- Un interruptor de palanca (rocker switch) adicional y botones en el lado derecho del mando
- Un interruptor adicional para comunicaciones
Actividades actuales:
- Preparación del prototipo de fabricación - configurando la máquina de corte (router CNC)
- En conversación con los proveedores para bajar los costos iniciales y precio de producción
Panel DIY (Hágalo Usted Mismo) para FlightGear
Existen al menos 5 proyectos en donde los usuarios de FlightGear construyen sus propios paneles con interruptores y perillas reales para interactuar con FlightGear y mejorar la experiencia de vuelo. Sigue el progreso de construcción de los paneles de ludomotico y pommesschranke en este hilo del foro.
En el hangar
Junkers JU-288, y el biplano Caudron Type 'C', de Lester Boffo
Humildemente, dos nuevos aviones de mi 'Hangar'. El primero es un Junkers JU-288 Bombardero/Bombardero-Interceptor presentado a la Luftwaffe en 1942 como resguardo en contra de la esperada campaña de bombardeo de EEUU y el nuevo Boeing B29. Así como con todos los bombarderos medianos en la guerra aérea alemana de la 2GM, los políticos, de quienes la compañía obtuvo los fondos y continuaron la producción, también condenaron a esta aeronave a sólo unos pocos prototipos y variantes. Se apoyó en el prometedor motor Jumo 222 radial/en línea enfriado por agua, pero la fábrica de motores fue destruida por un bombardeo aliado en 1944. Fue un poco difícil encontrar literatura sobre este aparato, pero con algo de ayuda de FMG, fui capaz de encontrar algunos dibujos y especificaciones. No estoy seguro cuándo estará terminado el avión, pero el modelo 3D básico está listo y también un cockpit rudimentario.
Desarrollo del Junkers Ju-288A en MetasequoiaLE
Otro ángulo del Junkers Ju-288A durante el desarrollo
El segundo es pequeño, anterior a la 1GM y de las primeras aeronaves de Rene Caudron y su hermano, el biplano Type 'C'. El primero de sus diseños de 'Dominio Público' que lanzó a la naciente comunidad aérea. Esta aeronave estaba para un mayor desarrollo, como los entrenadores de la serie G y bombarderos/observadores de la 1GM. Este peculiar avión también fue conocido como 'el Caudron de 10 metros', era interesante notar que empleaba un control mejorado del alabeo a partir del elevador dividido. Fue alabado por su gran razón de ascenso, ligereza y maniobrabilidad en un modesto Anzani de 6 cilindros radial de 45 h.p. La aeronave se distribuye bajo licencia GPL.
Caudron Type "C" volando sobre París en una nublada mañana de otoño
Caudron Type "C" en las laderas de un campo de Ródano-Alpes
North American P-51D Mustang
El JSBSim P-51D está experimentando varias mejoras significativas. La más interesante de estas es la mira calculada K-14A completamente funcional. El pantallazo inferior muestra la mira del cañón en acción con el avión girado y tirando a 5g's. Puedes ver que hay dos retículos. La pequeña cruz en el centro superior del vidrio reflector es la cruz central del retículo fijo y su línea de mira corresponde con el lugar en que los proyectiles impactarían en vuelo recto y nivelado (por ejemplo, ligeramente bajo la plomada de los cañones). El retículo fijo ha sido enmascarado de tal forma que sólo la cruz central es visible. EL punto central y seis diamantes circundantes es el retículo controlado mediante un giróscopo, el cual le da a esta mira la funcionalidad de mira calculada. En el pantallazo de la izquierda, el retículo giroscópico es desplazado una distancia significativa del retículo fijo, y esta distancia es conocida como deflexión. Notar también que las trazadoras del cañón convergen cerca del retículo giroscópico, dando una indicación de cuán efectiva es la nueva mira cuando se hacen disparos durante los giros.
La imagen de la derecha es de una misión de ataque al suelo usando cohetes HVAR. En este caso, el retículo giroscópico está apagado y el retículo fijo está descubierto. Ahora puedes ver la cruz central junto con el círculo exterior de 70 miliradianes y la llamada 'escalera de los cohetes' en la parte inferior central del círculo externo. Este ataque erró el objetivo arriba y a la derecha principalmente porque estaba distraído tomando el pantallazo. Pero puedes ver que la ruta de vuelo trazada por el humo de los cohetes es la misma que la indicada por la escalera.
Imagen del K-14A en acción mostrando el retículo giroscópico con el avión volteado y girando a altas G's. Nota que las trazas convergen cerca del centro del retículo giroscópico. Además, el retículo fijo está oculto y sólo se ve la cruz central. La cruz central del retículo fijo es la línea de puntería de los cañones.
Imagen de un ataque con cohetes a un bote pesquero. El retículo usado es el fijo con un círculo de 70 miliradianes y la escalera de cohetes visible.
La siguiente imagen de la izquierda is una vista en tierra del avión con nuevos estanques lanzables, soporte para bombas y hélice. Además, puedes ver la parte trasera de la mira del cañon en la carlinga. El área rosada en la parte trasera de la mira es el paquete de gel de sílice que mantiene seco el interior del K-14A.
Imagen que muestra nuevos estanques lanzables, soporte de bombas, hélice y parte de la mira K-14A
Los nuevos cohetes HVAR y sus bastidores.
Los soportes para bombas y y cohetes fueron modelados usando los planos de fabricación reales y tienen un error de tal vez 0.1mm. La hélice y los estanques lanzables fueron modelados basándose en medidas publicadas y tienen niveles similares de precisión. Los modelos 3D de la mira están basados en los dibujos y dimensiones del manual de mantención del K-14A de la USAAF.
Hay otras mejoras al FDM y otras áreas que han sido incluidas en el fgdata. Para probar las nuevas características necesitarás las carpetas Aircraft/p51d y Aircraft/Instruments-3d/computing-gun-sights. He probado estas actualizaciones con FG 2.12.1 pero deberían funcionar bien con cualquier versión superior o igual a la 2.4.
fgdata también tiene el nuevo checklist que fue configurado por Stuart Buchanan. He agregado algunas cosas al checklist para reflejar los cambios en el FDM que efectó el procedimiento de encendido del motor. De esa experiencia sé que Stuart invirtió mucho tiempo para tener esto ordenado. Gracias Stuart.
El plan a seguir es continuar mejorando el modelo 3D externo basado en los planos de fábrica. Por lo tanto, puedes esperar a que en los próximos meses las cosas mejoren aún más.
Por favor, siéntete libre de probarlo y de aportar críticas constructivas en el foro de FlightGear
Actualizaciones de la Wiki
Páginas de ayuda de la wiki con los mayores cambios
Durante noviembre y diciembre muchas de las páginas de ayuda han estado activas y extendidas, y se han creado algunas otras nuevas, Help:Tables and Help:Glossary.
Estos cambios fueron hechos para mejorar la ayuda a los usuarios nuevos, pero probablemente será útil también para los editores habituales. Las páginas reescritas ahora tienen enlaces a páginas de áyuda más avanzada principalmente en MediaWiki Wiki, la wiki de los desarrolladores del software wiki usado por FlightGear Wiki.
En resumen, se han hecho los siguientes cambios:
| → Help:Templates | – Reescrita y extendida | |
| → Help:Formatting | – Reescrita y extendida | |
| → Help:Tutorial | ||
| – Reescrita y extendida |
El trabajo aún no está completo. La mayoría de las traducciones de estas páginas necesitan ser movidas y/o traducidas, y un par de págnas, Help:Categories and Help:Tutorial, todavía podrían necesitar una reescritura (aunque en una escala mucho menor).
Y finalmente, una guía de estilo (como guía, no como manual) es algo que cada vez se hace más necesaria. Cualquier sugerencia y opiniones son bienvenidas en Help talk:Style guide, además de aportes al Help:Style guide, que actualmente está (muy) incompleta.
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.
YASim busca nuevo mantenedor
|
Hay algunas peticiones de merge pendientes para agregar algunas funcionalidades a YASim, pero tenemos un problema y es que ninguno de los actuales programadores C++ son expertos en YASim, y somos reacios a ser nosotros quienes realicen el merge de los cambios, y eventualemente introducir sutiles regresiones.
Obviamente esto es como el huevo y la gallina, ya que así nadie podrá hacerse experto en el código como para convertirse en mantenedor :) Por lo tanto, estoy más que feliz de aplicar parches *siempre y cuando* pueda convencerme de que son razonables+sensatos únicamente desde la perspectiva del código (feliz de ayudar con eso también, si hay personas que son nuevas en C++), y siempre que tengamos alguna seguridad de que una muestra representativa de aeronaves YASim no han cambiado o mejorado producto del parche. En la práctica eso significa que las sugerencias son más que bienvenidas. De lo contrario me temo, dada la naturaleza del solucionador, seguiremos optimizando el solucionador para algunas aeronaves, y haciéndolo peor para otras ya existentes - hasta que alguien las pruebe, y avise que ya no funcionan..[1]— James Turner
|
|
|
|
Sigo estando muy dispuesto a responder preguntas (mientras recuerde lo suficiente como para dar una respuesta útil). Just cc: me if you do, porque mi lantencia aquí es medida en semanas.
Los errores siempre pueden ser corregidos. Lo que YASim necesita es un mantenedor, y no experiencia por sí misma. Lo último llega con lo primero.[2] — Andy Ross
|
|
- ↑ James Turner (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.
- ↑ Andy Ross (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.