FlightGear wiki - User contributions [en]

Es/FlightGear Newsletter

2014-03-07T03:10:30Z

Wallkon: Se agregó febrero 2014

[[File:magagazine.png|right]]
'''El Boletín de Noticias de FlightGear''' está destinado a proporcionar una colección de las últimas novedades de la comunidad mundial [[FlightGear]]. Con tantísimo desarrollo continuo, es casi imposible que alguien pueda mantenerse al día. El boletín se inició en Julio de 2009 y se presenta sobre una base mensual.

All editions are initialy written in English, this page only lists translated editions. For a complete overview, see [[FlightGear Newsletter]].

=== Archive ===
{| class="vatop" valign="top"
! align="left" | 2009
! align="left" | 2010
! align="left" | 2011
! align="left" | 2012
! align="left" | 2013
! align="left" | 2014
|-
|valign="bottom"|
* [[FlightGear Newsletter July 2009|Julio]]
* [[FlightGear Newsletter August 2009|Agosto]]
* [[FlightGear Newsletter September 2009|Septiembre]]
* [[FlightGear Newsletter October 2009|Octubre]]
* [[FlightGear Newsletter November 2009|Noviembre]]
* [[FlightGear Newsletter December 2009|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2010|Enero]]
* [[:es:FlightGear Newsletter February 2010|Febrero]]
* [[:es:FlightGear Newsletter March 2010|Marzo]]
* [[:es:FlightGear Newsletter April 2010|Abril]]
* [[:es:FlightGear Newsletter May 2010|Mayo]]
* [[:es:FlightGear Newsletter June 2010|Junio]]
* [[:es:FlightGear Newsletter July 2010|Julio]]
* [[:es:FlightGear Newsletter August 2010|Agosto]]
* [[:es:FlightGear Newsletter September 2010|Septiembre]]
* [[:es:FlightGear Newsletter October 2010|Octubre]]
* [[:es:FlightGear Newsletter November 2010|Noviembre]]
* [[:es:FlightGear Newsletter December 2010|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2011|Enero]]
* [[:es:FlightGear Newsletter February 2011|Febrero]]
* [[:es:FlightGear Newsletter March 2011|Marzo]]
* [[:es:FlightGear Newsletter April 2011|Abril]]
* [[:es:FlightGear Newsletter May 2011|Mayo]]
* [[:es:FlightGear Newsletter June 2011|Junio]]
* [[:es:FlightGear Newsletter July 2011|Julio]]
* [[:es:FlightGear Newsletter August 2011|Agosto]]
* [[:es:FlightGear Newsletter September 2011|Septiembre]]
* [[:es:FlightGear Newsletter October 2011|Octubre]]
* [[FlightGear Newsletter November 2011|Noviembre]] **
* [[FlightGear Newsletter December 2011|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2012|Enero]] **
* [[FlightGear Newsletter February 2012|Febrero]] **
* [[FlightGear Newsletter March 2012|Marzo]] **
* [[FlightGear Newsletter April 2012|Abril]] **
* [[FlightGear Newsletter May 2012|Mayo]] **
* [[FlightGear Newsletter June 2012|Junio]] **
* [[FlightGear Newsletter July 2012|Julio]] **
* [[FlightGear Newsletter August 2012|Agosto]] **
* [[FlightGear Newsletter September 2012|Septiembre]] **
* [[FlightGear Newsletter October 2012|Octubre]] **
* [[FlightGear Newsletter November 2012|Noviembre]] **
* [[FlightGear Newsletter December 2012|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2013|Enero]] **
* [[FlightGear Newsletter February 2013|Febrero]] **
* [[FlightGear Newsletter March 2013|Marzo]] **
* [[FlightGear Newsletter April 2013|Abril]] **
* [[FlightGear Newsletter May 2013|Mayo]] **
* [[FlightGear Newsletter June 2013|Junio]] **
* [[FlightGear Newsletter July 2013|Julio]] **
* [[:es:FlightGear Newsletter August 2013|Agosto]]
* [[:es:FlightGear Newsletter September 2013|Septiembre]]
* [[:es:FlightGear Newsletter October 2013|Octubre]]
* [[:es:FlightGear Newsletter November 2013|Noviembre]]
* [[:es:FlightGear Newsletter December 2013|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2014|Enero]]
* [[:es:FlightGear Newsletter February 2014|Febrero (parcialmente traducido)]]
|}

; ** Ediciones no traducidas aún.

=== Estás invitado a contribuir! ===
Nos gustaría destacar que el boletín mensual no puede vivir sin las contribuciones de los usuarios y desarrolladores de FlightGear. El boletín FlightGear es un boletín informativo impulsado por la comunidad, lo que significa que es creado y editado por personas como **tu** No es necesario ser un usuario de FlightGear desde hace mucho tiempo (o incluso desarrollador) para contribuir con el boletin de noticias.

De hecho, ayudar a escribir el boletín mensual de FlightGear es una manera excelente de empezar a contribuir con la comunidad FlightGear rápida y muy fácilmente.

Incluso si no tienes algo tuyo que añadir, son tambien muy apreciadas las revisiónes y mejoras de las aportaciones de otros, al igual que los esfuerzos para ayudar a traducir los boletines o incorporar imágenes de pantalla al boletín de noticias (por ejemplo, tomadas del foro o las listas de correo). Las capturas de pantalla se pueden cargar en [[Special:Upload]]

Todo el mundo con una cuenta wiki ([[Special:UserLogin|libre de registro]]) puede editar el boletín de noticias y toda contribución es bienvenida. Así que si sabes de algún proyecto relacionado con FlightGear, como por ejemplo un escenario actualizado o una aeronave, por favor, sientete invitado a añadir este tipo de noticias en el boletín.

Si necesitas ayuda usando el wiki, por favor no dudes en ponerte en contacto con nosotros a través de [http://forum.flightgear.org/viewforum.php?f=50 la sección del foro].

Se puede tomar y usar una plantilla simple que proporciona una estructura básica para el [[Talk:Next newsletter|próximo boletín]] Esta plantilla se puede copiar/pegar en cada nuevo boletín para ayudar a los usuarios a empezar a ofrecer contenidos.

El borrador para el próximo boletín siempre se puede encontrar en el [[Next newsletter|próximo boletín]].

Si el Inglés no es tu lengua materna, por favor, que no te preocupe ayudar en el boletín de noticias, siempre puedes fácilmente pedir a otros usuarios de FlightGear que revisen o corrijan tus cambios. Además, una de las maneras más fáciles de empezar es simplemente copiar/pegar texto del foro o de los debates en las listas de correo, tales como anuncios (nuevos aviones, nuevos escenarios, etc).

Otra opción clara para empezar es la aportación de enlaces a videos de YouTube relacionados con FlightGear. Para ello, tenemos una sección dedicada en cada boletín de noticias - mira en: "FlightGear en YouTube": [[Next newsletter#Community news]]

Para incrustar vídeos de YouTube directamente, sólo tienes que utilizar la siguiente sintaxis:
<nowiki>{{#ev:youtube|VBWZ6JZe_Mw|400| vídeo en invierno de planetacancun2 que muestra la nieve en FlightGear.}}</nowiki>

Si estás buscando otras maneras de participar, por favor mira en [[Es/Voluntarios|voluntarios]].

[[Category:FlightGear Newsletter]]
[[Category:Community|Newsletter]]
[[Category:List|Newsletter]]

[[en:FlightGear Newsletter]]
[[fr:FlightGear Newsletter]]

Es/FlightGear Newsletter February 2014

2014-03-06T00:59:33Z

Wallkon: Advanced Weather: traducido

{{newsletter}}
{{TOC_right|limit=2}}

== Noticias del proyecto ==
=== ¡Nueva versión! FlightGear 3.0 ===
El 17 de febrero, el equipo de desarrollo de FlightGear publicó la versión v3.0 de FlightGear, el simulador libre y de fuente abierta. Esta nueva versión contiene muchas características fascinantes, mejoras y correcciones. Destacan en esta versión la integración del simulador con el cliente de comunicaciones [[FGCom]], mejoras en el dibujado del terreno, una carga del escenario más rápida y mejoras en la usabilidad. Este lanzamiento también coincide con la liberación del FlightGear World Scenery 2.0 - la cual es una mejora enorme en los datos del escenario que cubre todo el planeta, e incorpora los caminos de [[OpenStreetMap]] y detallada información del terreno a partir de varias fuentes.

Una lista de los principales cambios pueden encontrarse en: [[Changelog 3.0]]. FlightGear 3.0 está disponible para varios sistemas operativos desde [http://www.flightgear.org/download/ FlightGear.org/download]

=== Tiempo Atmosférico Avanzado ===
El sistema de Tiempo Atmosférico Avanzado ha recibido una gran actualización, dándole la capacidad de dibujar nubes a cualquier distancia que sea necesaria hasta el horizonte visible (la mayor distancia probada fue de 750 km desde la órbita baja de la Tierra).

La técnica usada para esto utiliza los así llamados "impostores", simples texturas pre generadas mostrando desde arriba los contenidos de una capa de clima de 40x40 km en baja resolución. Basado en la situación climática actual, los impostores llenan el rango que va desde el borde de la región donde las nubes 3d son simuladas hasta el rango de visibilidad seleccionado o el rango de dibujado de nubes (el que sea más bajo). Debido a que los impostores son en sí mismos modelos muy simples, el impacto en la frecuencia de cuadros (frame rate) es mínimo e independiente del número de nubes aparentemente visibles. Un shader dedicado para el framework de Dispersión de Luz Atmosférica (Atmospheric Light Scattering) se encarga de la iluminación en condiciones de poco sol.

Esto mejora bastante la visión a grandes altitudes para aquellos sistemas que pueden dibujar nubes 3D hasta los 80 km y soportan una visibilidad mayor que eso.

[[File:Farclouds02.jpg|300px|Impostores en un cielo cubierto]]
[[File:Farclouds07.jpg|300px|Impostores para nubes dispersas]]
[[File:Farclouds10.jpg|300px|Impostores para Cúmulos]]

Actualmente, esta funcionalidad está en una etapa avanzada de la prueba de concepto - el modo METAR aún no está completamente soportado, y los algoritmos de ubicación aún deben refinarse.

=== Point Lights exposed to Effects ===
Stuart committed a change that (finally) brings surface lights, including VASI/PAPI/taxi/runway etc. into the xml-defined Effects
framework. Kudos to Tim Moore for his original Effects work - it made it very straightforward to enhance with support for point sprites and a custom texture generator required.

The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.

Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your build fails, please check you've got a recent OSG build installed.

Please let us know if you see any issues with either change. And while at it, Stuart also fixed one of the longest-standing scenery glitches in FlightGear history[http://forum.flightgear.org/viewtopic.php?f=47&t=22168&p=202063#p202060].
Stuart and Thorsten also fixed the black halo that could previously be seen around point lights [https://gitorious.org/fg/fgdata/commit/eaaf816b772649d5b0826a1d0bdd166dbc5b968f].

A suitable ALS version of the runway lights is now well under way which fogs runway lighting consistently with the rest of the scene. Having the lights inside the shader has additional benefits - it allows to make them more responsive to the environment, in particular the lights are rendered harder and with a sparkle effect, the distance out to which they are visible changes with the level of ambient lights, and in fog lights acquire a halo due to Mie forward scattering.

[[File:Lights_als05.jpg|300px|Runway lights for ALS]]
[[File:Lights_als06.jpg|300px|Runway lights for ALS]]

=== osg::Simplifier ===
Stuart has committed a new rendering option, which allow simplification of the terrain mesh at runtime using the osgUtil::Simplifier node
visitor. Many thanks to Clement for discovering this and providing the initial patch.

Driving by a new set of control properties under /sim/rendering/terrain/simplifier/ (some of which are exposed via the Rendering dialog), the Simplifier goes through the OSG terrain representation and simplifies the mesh. The idea is that frame-rates can be increased by reducing the terrain vertex count - Stuart has seen the total vertex count on startup at KRHV drop from 18M to 11M using the Simplifier.

You can configure the Simplifier to run on none, all, or far terrain (i.e. beyond /sim/rendering/static-log/rough).

As there's no such thing as a free lunch, you should be aware of the following quite significant limitations:
* Simplifying the mesh costs CPU. On Stuart's laptop it increases the load time for complex tiles around KSFO by up to 20 seconds per tile.
* If you enable it for all terrain, you may notice that the height of objects is incorrect, as they are based on the real tile mesh rather than the simplified one. Depending on the Simplifier configuration and the terrain mesh, this may or may not be obvious!
* If you enable it only for far terrain, the tile is reloaded when you get within /sim/rendering/static-lod/rough of the tile edge. This
shouldn't affect your frame-rate, as it's done by the same PagedLOD that loads random objects, lights and trees.

Stuart did npt see any frame-rate increase using this method, but it is known that some people are concerned about the memory-occupancy of the scene-graph with Scenery 2.0, and this may provide some benefit.

The option is not switched on by default - you should not see any impact unless you decide to switch it on in the Rendering dialog.

If this provides a significant frame-rate improvement for people, it might be worth looking into generating the simplified mesh offline or caching it to disk.

===ATIS updates and a new comm-radio subsystem ===
Torsten has replaced the current ATIS subsystem by something more configurable. Along with that comes a new comm-radio subsystem to provide some information about the received station.

* With the new ATIS system it is now possible to code region and even airport specific ATIS styles. These styles are defined in [[$FG_ROOT]]/ATC/atis.xml and [[$FG_ROOT]]/ATC/atis/*.xml.
* The phraseology is no longer hardcoded but stored as localized strings in [[$FG_ROOT]]/Translations/*/atc.xml (Currently, only english phraseology is implemented).
* The ATIS is no longer generated from the weather at the current aircraft position but encoded from the METAR data for the tuned ATIS
station. For that, real-weather (live data in the gui) has to be selected. As a fallback, if no live weather data is configured, the old behaviour applies.
* The comm-radio subsystem provides some geographic and station specific information about the nearest station for the given frequency. The property tree under /instrumentation/comm[x] now shows e.g. distance, station name, station type, bearing, and airport id.

To make use of the new features, a comm radio subsystem has been added to the generic instrumentation file at [[$FG_ROOT]]/Aircraft/Generic/generic-instrumentation.xml - however, if an aircraft has defined it's own instrumentation set, please add the following code for the first comm radio and eventually more with increasing numbers.
<syntaxhighlight lang="xml">
<comm-radio>
<name>comm</name>
<number>0</number>
</comm-radio>
</syntaxhighlight>

Please report, if there are any broken features.

Torsten is planning to merge the radio implementation of the comm radio, the navradio and the newnavradio code so they all use the same codebase wherever possible. Eventually, he'll also touch ATC/trafficcontrol.?xx to better integrate that into the radio code and remove the hardcoded phraseology. He also plans to use parts of the radio propagation code from Adrian to provide a better computation of the signal quality.

=== Revised Nasal APIs: getprop()/setprop() ===
As of FlightGear 3.1, getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index", "texture", 1, "name");
</syntaxhighlight>
: is now the same as:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request #54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])

== Canvas: two years later ==
[[File:Anniversary4.png|left|600px]]

According to [https://www.gitorious.org/fg/flightgear/merge_requests/26 Gitorious merge request #26], it's been two years now that [[Canvas]] (our property-driven 2D rendering API) made it into FlightGear, back in early 2012. Time to recap:

First of all, we'd like to use the opportunity to express our thanks to all the people involved in making it happen, first of all, obviously TheTom and Zakalawe the canvas core developers, who are going out of their way to ensure that base package developers can easily and efficiently use the Canvas, while also being extremely responsive on the forums whenever it comes to feature requests, or those -very rare- bug reports.

But then, let's also say thanks to all the early-adopters who are contributing to Canvas already, who are helping develop features that could previously only be developed by writing C++ code and rebuilding FlightGear from code, while still fully realizing that things may not yet be very stable, but very much evolving still.

As can be seen, Canvas is really boosting FlightGear development in many areas where FlightGear was previously lacking, no matter if it's GUI development or glass cockpit efforts like the recent ND and PFD efforts initiated by Gijs.

Back in early 2012, the Canvas prototype contained only support for osgText - meanwhile, it's been extended to support other rendering primitives, so called "Canvas Elements", such as OpenVG paths (vector graphics via ShivaVG), raster images and even a dedicated charting mode based on concepts borrowed from [[J661]]/ARINC 661, mithrandir3, as the J661 lead developer, and member of the ARINC 661 committee, is also to be thanked here, for going out of his way whenever we had questions about J661 and ARINC 661 and for being so responsive.

Since then, Canvas has been extended to cover additional use-cases, such as for example dedicated event handling support - which will come in handy once we modernize our integrated GUI to get finally rid of PUI and all its limitations.

So, it's been two pretty intense years actually, we've seen some fairly significant contributions to the base package with as many as half a dozen of contributors working towards the same goals, e.g. a generic [[NavDisplay]] framework initiated by Gijs and Hyde, but also the generic [[MapStructure]] framework created by Philosopher. All of which really started out with Stuart's original adaption of the airport selection dialog, that added support for taxiway/runway overlays using Canvas, and which has meanwhile been refactored and generalized to come up with a totally aircraft-agnostic framework for creating reusable mapping layers, which can now even be used in GUI dialogs easily, typically requiring only a few lines of Nasal code.

And while these efforts are still very much in progress, their results are pretty tangible already - in fact, we've seen a handful of aircraft already adopting these new frameworks, and "early-birds" providing regular feedback via various channels. And FlightGear's Canvas system is even getting promoted in other places, including even the [http://forum.outerra.com/index.php?topic=2154.0 Outerra forum].

And then there were several other amazing contributions that didn't yet make it into dedicated frameworks, but that were at least very interesting prototypes, such as for example kuifje09's 2D plotting tool [[FGPlot]], which also solves a long-standing problem and feature request, i.e. plotting inside FlightGear, without requiring any external tools - which should come in handy for anybody interested in doing AP/FDM tuning. We do hope to also generalize things there, so that we can provide a framework dedicated to 2D plotting. And more recently, Philosopher has created a fairly impressive Nasal/Canvas piece of work: a fully interactive Nasal console, with a "Read Evaluate Print-Loop" (REPL).

Taking a step back, it's becoming obvious pretty quickly that [[Canvas]] is having a massive impact and touching many areas that were previously only really accessible to people familiar with C++, the FlightGear code base, OpenGL/OSG programming and, last but not least, git. We've seen additions to legacy GUI/instrumentation features that haven't really been maintained in over half a decade, so this is very encouraging, because such features are suddenly accessible to middleware developers, so that core development is no longer the bottleneck when it comes to adding new GUI/instrumentation features.

[[File:Anniversary3.png|right|600px]]

After doing some research in the archives of the devel list, it seems that the original "canvas properties" idea dates back to early 2003/late 2004 (shortly after Nasal scripting had been added), it was originally brought up by Harald Johnsen who was working on a dedicated FMC/CDU back then, and who was looking for a way to implement such features without having to rebuild FlightGear from source [http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26123.html] [http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26124.html].

In the years to come, the idea kept being brought up, rediscovered and even re-invented by several people - which goes to show that good ideas seem to prevail ultimately. According to the devel list archives, for over a decade, glass cockpit support in FlightGear has been described as "lacking" by even the most senior contributors back then, like David Megginson or Jim Wilson, and our existing PLIB/PUI based GUI described as "archaic at best". All this has now changed thanks to Canvas.

And appropriately enough, even today, the back-end in Canvas used for creating and rendering to an offscreen texture, is still based on the very "ODGauge" code that Harald Johnsen originally came up with, 10 years ago, when he coined the term "Owner-Drawn Gauge".

Thus, it's only fair that this particular newsletter covers quite a few Canvas related additions - the original goals of Canvas (making hardware accelerated 2D drawing possible without recompilation) have been pretty much accomplished already, probably 80-90% of our 2D drawing needs for cockpit/gui/HUD purposes can be implemented without having to go through any C++ changes or recompilation, and Canvas can be considered pretty much "feature-complete" there.

And even the new GUI is well on its way, and once there are some examples and tutorials available, it is foreseeable -given the impressive rate of growth of the wiki's Canvas portal- that we'll have base package developers ready and willing to step in to help with the implementation of GUI widgets.

In fact, we have now even started exploring new interesting ideas, such as using shaders and effects via Canvas, which may eventually even make it possible to implement cloud shadows outside [[Rembrandt]] by using a Nasal/Canvas/Effects approach for example.

Likewise, having support for effects/shaders would also mean that night vision effects could be implemented, as well as quite a few other things that weren't previously possible easily.

[[File:CanvasOverview02-2014.png|thumb]]

Besides, we've also been discussing exposing camera views (e.g. scenery view manager) or even the underlying rendering stages to Canvas, which is based on ideas originally brought up by FredB and Zan on the devel list when they were talking about exposing the Rembrandt renderer to Tim Moore's effects framework[http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg36481.html], a feature which would make all kinds of fancy things possible via Canvas.

Another interesting idea that was recently raised on the forums was running Canvas on embedded hardware platforms like Raspberry PI by supporting OpenGL ES[http://forum.flightgear.org/viewtopic.php?f=71&t=21964], which could mean that all Canvas based systems (PFD, ND, HUDs, EICAS, dialogs) may eventually be supported on such devices (maybe in another 2 years from now ?).

Some of the things we'll be working on in the time to come include:

{{Canvas Frameworks}}

In addition, sooner or later, we'll need to look into writing a few parsers for our existing 2D panels code, HUDs and GUI dialogs, to turn those existing PropertyList XML files into Canvases. If you'd like to get involved in some way, please get in touch via the Canvas sub forum: {{forum|71|Canvas}}

However, even people interested in doing C++ development may want to check out Canvas, we've started a fairly comprehensive article on extending the Canvas system via custom C++ classes to add new features: [[Canvas Development]]

To sum it up, these are very exciting times for anybody interested in doing 2D graphics stuff with FlightGear, no matter if it's GUIs, MFDs or -soon- even effects and shaders. The last two years have brought immense novelties to FlightGear contributed by people who would not be able to contribute these features via C++ code.

We've probably seen more 2D rendering related novelties and future potential added via base package contributions in the last two years than in the previous decade of FlightGear development, all thanks to Canvas obviously. Due to the property-tree centric nature of Canvas, we also finally have a feasible approach towards supporting glass cockpits in multi-instance FlightGear setups such as those that are typically demonstrated during [[FSweekend]] or LinuxTag, possibly using a simple Property Tree/HLA wrapper, maybe even just using the generic protocol or telnet for starters.

And maybe two years from now, things won't be restricted to 2D rendering anymore, but we may even be able to use Camera views as Canvas elements ? Just some food for thought ... Don't forget: In FlightGear you can '''be''' the change you want to see. Thanks to everybody involved in making it happen, and special thanks to Michat for creating two awesome anniversary logos !

=== Philosopher's fully interactive Nasal Console REPL ===
Philosopher has created a very cool [[Canvas]]-based, fully-interactive, Nasal Console with a real [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL interpreter (Read-eval-print loop)]. See his Gitorious clone (branch "nasal-console") for the code: [https://gitorious.org/fg/philosophers-fgdata/source/nasal-console:Nasal/console] - it's currently one file (which can even be copied into the existing [[Nasal Console]]) with a menubar entry (under "Debug") for easy access. You can also uncomment the [https://gitorious.org/fg/philosophers-fgdata/source/022bef27f05d4837d720f63c6507b47466ff2a59:Nasal/console/repl.nas#L436 last line] of the file to open it immediately. The dialog accepts user input in lines, and if it detects the user has completed a snippet, it executes the last code it's seen and prints a result of the expression on the same area. The most common way to continue input onto another line is to have an unclothed pair of braces/brackets/parentheses, but this REPL is unique in allowing unfinished expressions: blocks (e.g. just plain "if" on one line -- no condition, no body -- or "foreach (var e; list)" -- no body of the loop) and binary/prefix operators (e.g. "1 >", since that doesn't have a right side of the ">"). This however needs some work and tweaking, so it's always a WIP. The other big issue is the text styling -- the latest optimization leads to overlapping if a line of input/output is more than one line when wrapped. The output of print()/printlog()/etc. still goes to the startup OS terminal instead of the dialog. However, it still is useful for experimenting quickly -- ''quam celerrime revera''.

[[File:Interactive-Nasal-Console-REPL.png|600px|Philosopher's interactive Nasal console REPL]]
[[File:Interactive-Nasal-Console-REPL-Transparent-KSFO.png|600px|Now at KSFO with transparency enabled (no title bar/styling).]]

=== Copy & Paste Programming: A Compass Widget using Nasal/Canvas ===
[[File:Canvas-Compass-Widget.png|thumb|A Nasal/Canvas based compass widget]]
Inspired by a a recent forum discussion, Hooray thought that creating a compass widget would be a neat little project for someone interested in learning a bit more about Nasal and Canvas coding, and it should be possible to accomplish with less than 50-80 lines of code actually - there's a ton of stuff that you could reuse (SVG compass rose or an existing 2D panel texture), we have quite a few tutorials on Nasal, Canvas and Image processing (check the wiki). Furthermore, there is the long-term plan to eventually phase out the old 2D panel code and used a modernized [[Canvas]]-based version to help with [[Unifying the 2D rendering backend via canvas]]. Continue reading at [[Howto:Parsing 2D Instruments using the Canvas]]...

Paste this into your [[Nasal Console]] and click Execute:
<syntaxhighlight lang="nasal">
var CanvasApplication = {
##
# constructor
new: func(x=300,y=200) {
var m = { parents: [CanvasApplication] };
m.dlg = canvas.Window.new([x,y],"dialog");
m.canvas = m.dlg.createCanvas().setColorBackground(1,1,1,0.5);
m.root = m.canvas.createGroup();
m.timer = maketimer(0.1, func m.update() );
m.init();
return m;
},

del: func me.timer.stop(),

update: func() {
var hdg=getprop("/orientation/heading-deg");
me.compass.setRotation(-hdg*D2R);
},

init: func() {
var filename = "/Aircraft/Instruments/gyro.xml";
var temp= io.read_properties(getprop("/sim/fg-root") ~ filename);
var layers = temp.getValues().layers.layer;

var z=100;
foreach(var layer; layers ) {
print("new layer:", layer.name);

# if it's not a texture, skip
if (!contains(layer, "texture")) continue;

# get a handle to the texture of the layer
var texture = layer.texture;

# create an image child for the texture
var child=me.root.createChild("image")
.setFile( texture.path )
.setSourceRect( texture.x1, texture.x2, texture.y1, texture.y2 )
.setSize(layer.w,layer.h)
.setTranslation(20,20)
.set("z-index", z +=1 )
.setScale(2.5);

if (layer.w != nil and layer.h != nil)
child.setCenter(layer.w/2, layer.h/2);

if (layer.name=="compass rose") {
print("Found compass layer");
# child.setCenter(55,55);
me.compass = child;
}
} # foreach

me.timer.start();
},
}; # end of CanvasApplication

var InstrumentWidget = {
new: func(x,y) {
var m = CanvasApplication.new(x:x,y:y);
},
};

var compass = InstrumentWidget.new(x:300, y:300);

print("Compass Loaded...!");
</syntaxhighlight>

=== Canvas & Shaders: A match made in Heaven ? ===

For quite a while, we've been thinking that at some point, the [[Canvas]] system could probably benefit from being also able to also use FlightGear's effects/shader framework, so that canvas textures can also be processed via effects and shaders optionally, before they get drawn. That should make all sorts of fancy effects possible, such as night vision cameras or thermal view, rendered to canvas textures/groups.

That would then disable the default rendering pipeline for those canvas textures and use shaders.

Basically, anything that's not directly possible via the core canvas system or via its Nasal wrappers, would then be handled via effects/shaders. So we would gain lots of flexibility, and performance benefits.

So if people really want to create really fancy textures or camera views, they could use effects/shaders then, which would keep the design truly generic, and it would ensure that there's no bloat introduced into the main canvas system.

We did have some discussions about supporting per-canvas (actually per canvas::Element) effects and shaders via properties recently, TheTom even mentioned a while ago that he is interested in supporting this at some point, especially given the number of projects that could be realized like that (FLIR, night vision, thermal imaging etc).

At the time of writing this (02/2014) the Canvas does not yet include any support for applying custom effects or [[shaders]] to canvas elements or the whole canvas itself - however, supporting this is something that's been repeatedly discussed over time, so we're probably going to look into supporting this eventually[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37210.html].

Some very basic prototyping has already taken place and looks pretty encouraging:

<gallery mode=packed widths=150px heights=150px>
Canvas-glsl-support.png|airport selection dialog with a greyscale fragment shader applied to the canvas
Canvas-Fragment-Shader-red.png|a trivial fragment shader applied to a canvas (the original colors used in the Nasal code were not changed!)
Canvas-Fragment-Shader-circles.png|unmodified airport selection canvas with fragment shader applied
Canvas-Fragment-Shader-experiments.png|more canvas fragment shading experiments
</gallery>

Continue reading at [[Canvas Development#Effects & Shaders|Canvas & Shaders]]

=== A MapStructure Debugger ===

[[File:MapStructure-ND-Profiling.png|thumb|MapStructure Debugger running a [[NavDisplay]] and profiling a few layers.]]

[[MapStructure]] is a [[Nasal]]-space framework (designed and maintained by Philosopher) for managing layers of symbols in Nasal/[[Canvas]]-based mapping displays, which can be used in both aircraft MFDs/instruments like the [[NavDisplay]] (ND) and GUI dialogs, like the airport selection or [[Map]] dialogs. MapStructure is all about separating the visualization of the map from the visualized data itself, and the way it is shown to, and controlled by, the user. MapStructure is designed as a Model/View/Controller (MVC) framework.

The MapStructure debugger is a simple GUI dialog intended to be used for debugging and benchmarking MapStructure-based charting layers. In its current form, it simply shows a NavDisplay inside the dialog with several layers enabled, including a 2D graph to benchmark each individual layer (such as APT, DME, FIX, TFC).
Currently, the dialog is fairly simple and pretty crude, the plotting code is entirely based on [[FGPlot]] and needs to be further generalized eventually (see Canvas Plotting Framework). However, so far it's actually working nicely and can help determine where time is spent, i.e. which layers are "expensive" compared to others.
In addition, the MapStructure debugger dialog can be used to easily test MapStructure-based maps/charts like Gijs' NavDisplay, without having to start up a complex aircraft like the 747-400 or 777-200ER. In other words, the ND can be easily tested by using the ufo or ogeL - which are usually up and running within ~10 seconds.

Continue reading at [[MapStructure Debugger]]...

=== Canvas System ===

The F-16CJ is being renovated to include the most realistic fighter HUDs yet. See the progress at [[F-16CJ HUD Project Newsletter]] and [[http://forum.flightgear.org/viewtopic.php?f=71&t=22014 this forum topic]].

=== JSBSim Ground Effects ===
This is a heads up for JSBSim aircraft maintainers that user their own ground detection and handling code. As of this month JSBSim, just like YASim, supports ground effects like bumpiness, solid-ground detection and adjusting of friction actors. Actually JSBSim supports an extra feature, BOGEY contact points sink in a non-solid ground surface but STRUCTURE contact point do not, making it easy to define floats using STRUCTURE contact points.

In order not to pollute /fdm/jsbim too much Erik added the following properties:

;/sim/fdm/surface/override-level
:A user defined property which if defined and set to a something higher than 0 will disable the JSBSim ground reactions code completely and the following properties are set to false:
:* /sim/fdm/surface/active
:* /sim/fdm/surface/valid
: Otherwise the following applies:
:* /sim/fdm/surface/active
:: is set to true
:* /sim/fdm/surface/valid
:: is set to true if there is a valid material available or set to false otherwise (the material defaults are set).
; /fdm/jsbsim/ground/solid
: flag which defines if the surface is solid not
; /fdm/jsbsim/ground/bumpiness
: defines the bumpiness factor
; /fdm/jsbsim/ground/maximum-force-lbs
: maximum allowed force for this surface
; /fdm/jsbsim/ground/rolling_friction-factor
: rolling friction factor - applies to rolling friction
; /fdm/jsbsim/ground/static-friction-factor
: static friction factor - applies to static friction and dynamic friction

These properties are also set for the appropriate gear and contact units.

If you want to keep the old behaviour just set sim/fdm/surface/override-level to 1 somewhere in the configuration files, for Nasal this becomes:
<syntaxhighlight lang="nasal">
setprop("sim/fdm/surface/override-level", 1);
</syntaxhighlight>

The Nasal code has been updated for base package aircraft that have a custom ground interaction system. Not that some of these might actually be YASim aircraft but YASim will just ignore the property.

=== Getting involved as a programmer ===
Unfortunately, most of the active FlightGear 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]].

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

== In the hangar ==

=== New aircraft ===
==== Junkers Ju 390 ====
'''Emmanuel Baranger, (helijah)'''

The Junkers Ju 390 was a German aircraft intended to be used as a heavy transport, maritime patrol aircraft, and long-range bomber, a long-range derivative of the Ju 290. It was one of the aircraft designs submitted for the abortive Amerika Bomber project, along with the Messerschmitt Me 264, the Focke-Wulf Ta 400, the Heinkel He 277.<ref>{{cite web |url=http://en.wikipedia.org/wiki/Junkers_Ju_390 |title=Junkers Ju 390 |publisher=Wikipedia }}</ref>

[[File:Ju390-17.png|200px|The tail gets up during the opening of the bay]]
[[File:Ju390-18.png|200px|above the sea]]
[[File:Ju390-19.png|200px|flying]]
[[File:Ju390-20.png|200px|flying 2]]

You can now find it in my hangar and on GIT hoping that you like as much as I enjoyed doing it.

==== Aichi M6A "Seiran" ====
'''Emmanuel Baranger, (helijah)'''

The Aichi M6A Seiran (晴嵐?, "Clear Sky Storm" or "Mist on a Fair Day") was a submarine-launched attack floatplane designed for the Imperial Japanese Navy during World War II. It was intended to operate from I-400 class submarines whose original mission was to conduct aerial attacks against the United States.<ref>{{cite web |url=http://en.wikipedia.org/wiki/Aichi_M6A |title=Aichi M6A |publisher=Wikipedia }}</ref>

[[File:Aichi M6A "Seiran".png|200px|On the water]]

You can now find it in my hangar and on GIT hoping that you like as much as I enjoyed doing it.

=== Updated aircraft ===
==== Sikorsky SH-60 Bravo Seahawk ====
'''James Cusick, (X7cusick8X)'''

The FlightGear Seahawk is an incredibly easy to fly helicopter designed for naval conditions, with its integrated FCS and FDM landing on carrier decks is a blast.

Recently i have take a break form FG but I am proud to announce the updated SH-60B Seahawk!
The updates include:
* Integrated Pushback
* Selectable payloads
* 95% complete folding animation for carrier deck transit
* New Liveries
* FDM Fixes
* and more

<gallery mode=packed widths=150px heights=150px>
SH-60 Bravo.png|SH-60B Taking off from the USS Carl Vinson
SH-60 Landing.png|SH-60 Landing
SH-60 Rotor Wash.png|Rotor Wash
</gallery>

== Scenery corner ==
A great work has been done this month for Spain, such as the city of Barcelona, with the addition of landmarks such as Sagrada Familia, Agbar tower and its airport. These updates are available using Terrasync.

List of updated airports (mostly in Spain, Brazil, and France):
{| class="vatop"
|width="300" |
* LEAB Albecete
* LEAT Alfes
* LEBG Burgos
* LEBL Barcelona - El Prat
* LECD La Cerdenya
* LECI Santa Cilia-Los Pirineos
* LECN Pinar de Castellon
* LEDA Lleida
* LEGE Girona
* LEHC Huescas/Pirineos
* LELL Sabadell
* LELN Leon
* LEPP Pamplona
* LERE Requena
* LESB Son Bonet
|width="300" |
* LESL San Luis
* LESO San Sebastian
* LESU Seo de Urgel
* LETL Teruel Plata
* LEVD Valladollid
* LFLG Le Versoud
* LFRB Brest Bretagne
* LFRN Rennes St Jacques
* PHNL Honolulu Intl
* SBNF Ministro Victor Konder
* SBPK Pelotas
* SBRJ Santos Dumont Airport
* SBUR Uberaba
* SPAF Camana
|}

=== Regional texturing ===

New regional texture definitions are now available on GIT for Ireland in the CORINE-landcover based WorldScenery 2.0. Enjoy the boglands of Connemara, or the hills and lakes of Kerry. With hires scenery and special textures, the Green Isle is now quite a nice place to explore.

The Ireland texture definitions have full support for procedural texturing and for the autumn coloring effect of ALS.

[[File:Eire02.jpg|300px| Connemara bog]]
[[File:Eire04.jpg|300px| Dingle peninsula]]
[[File:Eire05.jpg|300px| Kenmare bay]]

=== Models optimizations ===
Since a few months, works have been done on the scenery to clean existing models to make them lighter but keeping or even improving the overall quality. Among the tasks are deleting unseen faces, making face singled-sided, reducing texture size or removing unused alpha from texture.

== Community news ==
=== FlightGear &diams; Cross-Country Tutorial II &diams; a VFR guide ===
{|
| |
[[File:Coverwiki2.jpg|200px]]
| |
It's almost been a year since the first release of Cross-Country Tutorial II.<br />
Now with '''version three point zero''' the document is better than ever in many aspects.<br /> <br />
Go to the respective [http://forum.flightgear.org/viewtopic.php?f=72&t=19600 forum topic] where you can: <br />
*download this tutorial
*find out more about it
*'''post your comments and suggestions'''

coming up soon is the X-Country 2's own wiki page!
|}
== 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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

{{Appendix}}

[[Category:FlightGear Newsletter]]
[[Category:Changes after 3.00]]

Es/FlightGear Newsletter February 2014

2014-03-04T00:54:48Z

Wallkon: FlightGear 3.0 released: traducido

{{newsletter}}
{{TOC_right|limit=2}}

== Noticias del proyecto ==
=== ¡Nueva versión! FlightGear 3.0 ===
El 17 de febrero, el equipo de desarrollo de FlightGear publicó la versión v3.0 de FlightGear, el simulador libre y de fuente abierta. Esta nueva versión contiene muchas características fascinantes, mejoras y correcciones. Destacan en esta versión la integración del simulador con el cliente de comunicaciones [[FGCom]], mejoras en el dibujado del terreno, una carga del escenario más rápida y mejoras en la usabilidad. Este lanzamiento también coincide con la liberación del FlightGear World Scenery 2.0 - la cual es una mejora enorme en los datos del escenario que cubre todo el planeta, e incorpora los caminos de [[OpenStreetMap]] y detallada información del terreno a partir de varias fuentes.

Una lista de los principales cambios pueden encontrarse en: [[Changelog 3.0]]. FlightGear 3.0 está disponible para varios sistemas operativos desde [http://www.flightgear.org/download/ FlightGear.org/download]

=== Advanced Weather ===

The Advanced Weather system has received a major upgrade, giving it the capability to draw clouds to whatever range is needed to the visible horizon (largest distance tested was 750 km from low Earth orbit).

The technique used for this utilizes so-called impostors, simple pre-generated texture sheets showing the contents of a 40x40 km weather tile from above in low resolution. Based on the current weather situation, impostors fill the range from the edge of the region where 3d clouds are simulated to the currently selected visibility range / cloud drawing range (whatever is lower). Since the impostors themselves are very simple models, the frame rate impact is minimal and independent of the number of apparently visible clouds. A dedicated shader for Atmospheric Light Scattering takes care of matched lighting in low sun conditions.

On systems which can draw 3D clouds up to 80 km and support visibilities larger than that, this improves visuals at high altitude quite a bit.

[[File:Farclouds02.jpg|300px|[ Impostors for overcast clouds]]
[[File:Farclouds07.jpg|300px|[ Impostors for scattered clouds]]
[[File:Farclouds10.jpg|300px|[ Impostors for Cumulus clouds]]

The functionality is currently in an advanced proof of concept stage - METAR mode is not yet fully supported, and the placement algorithms may still be refined.

=== Point Lights exposed to Effects ===
Stuart committed a change that (finally) brings surface lights, including VASI/PAPI/taxi/runway etc. into the xml-defined Effects
framework. Kudos to Tim Moore for his original Effects work - it made it very straightforward to enhance with support for point sprites and a custom texture generator required.

The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.

Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your build fails, please check you've got a recent OSG build installed.

Please let us know if you see any issues with either change. And while at it, Stuart also fixed one of the longest-standing scenery glitches in FlightGear history[http://forum.flightgear.org/viewtopic.php?f=47&t=22168&p=202063#p202060].
Stuart and Thorsten also fixed the black halo that could previously be seen around point lights [https://gitorious.org/fg/fgdata/commit/eaaf816b772649d5b0826a1d0bdd166dbc5b968f].

A suitable ALS version of the runway lights is now well under way which fogs runway lighting consistently with the rest of the scene. Having the lights inside the shader has additional benefits - it allows to make them more responsive to the environment, in particular the lights are rendered harder and with a sparkle effect, the distance out to which they are visible changes with the level of ambient lights, and in fog lights acquire a halo due to Mie forward scattering.

[[File:Lights_als05.jpg|300px|Runway lights for ALS]]
[[File:Lights_als06.jpg|300px|Runway lights for ALS]]

=== osg::Simplifier ===
Stuart has committed a new rendering option, which allow simplification of the terrain mesh at runtime using the osgUtil::Simplifier node
visitor. Many thanks to Clement for discovering this and providing the initial patch.

Driving by a new set of control properties under /sim/rendering/terrain/simplifier/ (some of which are exposed via the Rendering dialog), the Simplifier goes through the OSG terrain representation and simplifies the mesh. The idea is that frame-rates can be increased by reducing the terrain vertex count - Stuart has seen the total vertex count on startup at KRHV drop from 18M to 11M using the Simplifier.

You can configure the Simplifier to run on none, all, or far terrain (i.e. beyond /sim/rendering/static-log/rough).

As there's no such thing as a free lunch, you should be aware of the following quite significant limitations:
* Simplifying the mesh costs CPU. On Stuart's laptop it increases the load time for complex tiles around KSFO by up to 20 seconds per tile.
* If you enable it for all terrain, you may notice that the height of objects is incorrect, as they are based on the real tile mesh rather than the simplified one. Depending on the Simplifier configuration and the terrain mesh, this may or may not be obvious!
* If you enable it only for far terrain, the tile is reloaded when you get within /sim/rendering/static-lod/rough of the tile edge. This
shouldn't affect your frame-rate, as it's done by the same PagedLOD that loads random objects, lights and trees.

Stuart did npt see any frame-rate increase using this method, but it is known that some people are concerned about the memory-occupancy of the scene-graph with Scenery 2.0, and this may provide some benefit.

The option is not switched on by default - you should not see any impact unless you decide to switch it on in the Rendering dialog.

If this provides a significant frame-rate improvement for people, it might be worth looking into generating the simplified mesh offline or caching it to disk.

===ATIS updates and a new comm-radio subsystem ===
Torsten has replaced the current ATIS subsystem by something more configurable. Along with that comes a new comm-radio subsystem to provide some information about the received station.

* With the new ATIS system it is now possible to code region and even airport specific ATIS styles. These styles are defined in [[$FG_ROOT]]/ATC/atis.xml and [[$FG_ROOT]]/ATC/atis/*.xml.
* The phraseology is no longer hardcoded but stored as localized strings in [[$FG_ROOT]]/Translations/*/atc.xml (Currently, only english phraseology is implemented).
* The ATIS is no longer generated from the weather at the current aircraft position but encoded from the METAR data for the tuned ATIS
station. For that, real-weather (live data in the gui) has to be selected. As a fallback, if no live weather data is configured, the old behaviour applies.
* The comm-radio subsystem provides some geographic and station specific information about the nearest station for the given frequency. The property tree under /instrumentation/comm[x] now shows e.g. distance, station name, station type, bearing, and airport id.

To make use of the new features, a comm radio subsystem has been added to the generic instrumentation file at [[$FG_ROOT]]/Aircraft/Generic/generic-instrumentation.xml - however, if an aircraft has defined it's own instrumentation set, please add the following code for the first comm radio and eventually more with increasing numbers.
<syntaxhighlight lang="xml">
<comm-radio>
<name>comm</name>
<number>0</number>
</comm-radio>
</syntaxhighlight>

Please report, if there are any broken features.

Torsten is planning to merge the radio implementation of the comm radio, the navradio and the newnavradio code so they all use the same codebase wherever possible. Eventually, he'll also touch ATC/trafficcontrol.?xx to better integrate that into the radio code and remove the hardcoded phraseology. He also plans to use parts of the radio propagation code from Adrian to provide a better computation of the signal quality.

=== Revised Nasal APIs: getprop()/setprop() ===
As of FlightGear 3.1, getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index", "texture", 1, "name");
</syntaxhighlight>
: is now the same as:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request #54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])

== Canvas: two years later ==
[[File:Anniversary4.png|left|600px]]

According to [https://www.gitorious.org/fg/flightgear/merge_requests/26 Gitorious merge request #26], it's been two years now that [[Canvas]] (our property-driven 2D rendering API) made it into FlightGear, back in early 2012. Time to recap:

First of all, we'd like to use the opportunity to express our thanks to all the people involved in making it happen, first of all, obviously TheTom and Zakalawe the canvas core developers, who are going out of their way to ensure that base package developers can easily and efficiently use the Canvas, while also being extremely responsive on the forums whenever it comes to feature requests, or those -very rare- bug reports.

But then, let's also say thanks to all the early-adopters who are contributing to Canvas already, who are helping develop features that could previously only be developed by writing C++ code and rebuilding FlightGear from code, while still fully realizing that things may not yet be very stable, but very much evolving still.

As can be seen, Canvas is really boosting FlightGear development in many areas where FlightGear was previously lacking, no matter if it's GUI development or glass cockpit efforts like the recent ND and PFD efforts initiated by Gijs.

Back in early 2012, the Canvas prototype contained only support for osgText - meanwhile, it's been extended to support other rendering primitives, so called "Canvas Elements", such as OpenVG paths (vector graphics via ShivaVG), raster images and even a dedicated charting mode based on concepts borrowed from [[J661]]/ARINC 661, mithrandir3, as the J661 lead developer, and member of the ARINC 661 committee, is also to be thanked here, for going out of his way whenever we had questions about J661 and ARINC 661 and for being so responsive.

Since then, Canvas has been extended to cover additional use-cases, such as for example dedicated event handling support - which will come in handy once we modernize our integrated GUI to get finally rid of PUI and all its limitations.

So, it's been two pretty intense years actually, we've seen some fairly significant contributions to the base package with as many as half a dozen of contributors working towards the same goals, e.g. a generic [[NavDisplay]] framework initiated by Gijs and Hyde, but also the generic [[MapStructure]] framework created by Philosopher. All of which really started out with Stuart's original adaption of the airport selection dialog, that added support for taxiway/runway overlays using Canvas, and which has meanwhile been refactored and generalized to come up with a totally aircraft-agnostic framework for creating reusable mapping layers, which can now even be used in GUI dialogs easily, typically requiring only a few lines of Nasal code.

And while these efforts are still very much in progress, their results are pretty tangible already - in fact, we've seen a handful of aircraft already adopting these new frameworks, and "early-birds" providing regular feedback via various channels. And FlightGear's Canvas system is even getting promoted in other places, including even the [http://forum.outerra.com/index.php?topic=2154.0 Outerra forum].

And then there were several other amazing contributions that didn't yet make it into dedicated frameworks, but that were at least very interesting prototypes, such as for example kuifje09's 2D plotting tool [[FGPlot]], which also solves a long-standing problem and feature request, i.e. plotting inside FlightGear, without requiring any external tools - which should come in handy for anybody interested in doing AP/FDM tuning. We do hope to also generalize things there, so that we can provide a framework dedicated to 2D plotting. And more recently, Philosopher has created a fairly impressive Nasal/Canvas piece of work: a fully interactive Nasal console, with a "Read Evaluate Print-Loop" (REPL).

Taking a step back, it's becoming obvious pretty quickly that [[Canvas]] is having a massive impact and touching many areas that were previously only really accessible to people familiar with C++, the FlightGear code base, OpenGL/OSG programming and, last but not least, git. We've seen additions to legacy GUI/instrumentation features that haven't really been maintained in over half a decade, so this is very encouraging, because such features are suddenly accessible to middleware developers, so that core development is no longer the bottleneck when it comes to adding new GUI/instrumentation features.

[[File:Anniversary3.png|right|600px]]

After doing some research in the archives of the devel list, it seems that the original "canvas properties" idea dates back to early 2003/late 2004 (shortly after Nasal scripting had been added), it was originally brought up by Harald Johnsen who was working on a dedicated FMC/CDU back then, and who was looking for a way to implement such features without having to rebuild FlightGear from source [http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26123.html] [http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26124.html].

In the years to come, the idea kept being brought up, rediscovered and even re-invented by several people - which goes to show that good ideas seem to prevail ultimately. According to the devel list archives, for over a decade, glass cockpit support in FlightGear has been described as "lacking" by even the most senior contributors back then, like David Megginson or Jim Wilson, and our existing PLIB/PUI based GUI described as "archaic at best". All this has now changed thanks to Canvas.

And appropriately enough, even today, the back-end in Canvas used for creating and rendering to an offscreen texture, is still based on the very "ODGauge" code that Harald Johnsen originally came up with, 10 years ago, when he coined the term "Owner-Drawn Gauge".

Thus, it's only fair that this particular newsletter covers quite a few Canvas related additions - the original goals of Canvas (making hardware accelerated 2D drawing possible without recompilation) have been pretty much accomplished already, probably 80-90% of our 2D drawing needs for cockpit/gui/HUD purposes can be implemented without having to go through any C++ changes or recompilation, and Canvas can be considered pretty much "feature-complete" there.

And even the new GUI is well on its way, and once there are some examples and tutorials available, it is foreseeable -given the impressive rate of growth of the wiki's Canvas portal- that we'll have base package developers ready and willing to step in to help with the implementation of GUI widgets.

In fact, we have now even started exploring new interesting ideas, such as using shaders and effects via Canvas, which may eventually even make it possible to implement cloud shadows outside [[Rembrandt]] by using a Nasal/Canvas/Effects approach for example.

Likewise, having support for effects/shaders would also mean that night vision effects could be implemented, as well as quite a few other things that weren't previously possible easily.

[[File:CanvasOverview02-2014.png|thumb]]

Besides, we've also been discussing exposing camera views (e.g. scenery view manager) or even the underlying rendering stages to Canvas, which is based on ideas originally brought up by FredB and Zan on the devel list when they were talking about exposing the Rembrandt renderer to Tim Moore's effects framework[http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg36481.html], a feature which would make all kinds of fancy things possible via Canvas.

Another interesting idea that was recently raised on the forums was running Canvas on embedded hardware platforms like Raspberry PI by supporting OpenGL ES[http://forum.flightgear.org/viewtopic.php?f=71&t=21964], which could mean that all Canvas based systems (PFD, ND, HUDs, EICAS, dialogs) may eventually be supported on such devices (maybe in another 2 years from now ?).

Some of the things we'll be working on in the time to come include:

{{Canvas Frameworks}}

In addition, sooner or later, we'll need to look into writing a few parsers for our existing 2D panels code, HUDs and GUI dialogs, to turn those existing PropertyList XML files into Canvases. If you'd like to get involved in some way, please get in touch via the Canvas sub forum: {{forum|71|Canvas}}

However, even people interested in doing C++ development may want to check out Canvas, we've started a fairly comprehensive article on extending the Canvas system via custom C++ classes to add new features: [[Canvas Development]]

To sum it up, these are very exciting times for anybody interested in doing 2D graphics stuff with FlightGear, no matter if it's GUIs, MFDs or -soon- even effects and shaders. The last two years have brought immense novelties to FlightGear contributed by people who would not be able to contribute these features via C++ code.

We've probably seen more 2D rendering related novelties and future potential added via base package contributions in the last two years than in the previous decade of FlightGear development, all thanks to Canvas obviously. Due to the property-tree centric nature of Canvas, we also finally have a feasible approach towards supporting glass cockpits in multi-instance FlightGear setups such as those that are typically demonstrated during [[FSweekend]] or LinuxTag, possibly using a simple Property Tree/HLA wrapper, maybe even just using the generic protocol or telnet for starters.

And maybe two years from now, things won't be restricted to 2D rendering anymore, but we may even be able to use Camera views as Canvas elements ? Just some food for thought ... Don't forget: In FlightGear you can '''be''' the change you want to see. Thanks to everybody involved in making it happen, and special thanks to Michat for creating two awesome anniversary logos !

=== Philosopher's fully interactive Nasal Console REPL ===
Philosopher has created a very cool [[Canvas]]-based, fully-interactive, Nasal Console with a real [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL interpreter (Read-eval-print loop)]. See his Gitorious clone (branch "nasal-console") for the code: [https://gitorious.org/fg/philosophers-fgdata/source/nasal-console:Nasal/console] - it's currently one file (which can even be copied into the existing [[Nasal Console]]) with a menubar entry (under "Debug") for easy access. You can also uncomment the [https://gitorious.org/fg/philosophers-fgdata/source/022bef27f05d4837d720f63c6507b47466ff2a59:Nasal/console/repl.nas#L436 last line] of the file to open it immediately. The dialog accepts user input in lines, and if it detects the user has completed a snippet, it executes the last code it's seen and prints a result of the expression on the same area. The most common way to continue input onto another line is to have an unclothed pair of braces/brackets/parentheses, but this REPL is unique in allowing unfinished expressions: blocks (e.g. just plain "if" on one line -- no condition, no body -- or "foreach (var e; list)" -- no body of the loop) and binary/prefix operators (e.g. "1 >", since that doesn't have a right side of the ">"). This however needs some work and tweaking, so it's always a WIP. The other big issue is the text styling -- the latest optimization leads to overlapping if a line of input/output is more than one line when wrapped. The output of print()/printlog()/etc. still goes to the startup OS terminal instead of the dialog. However, it still is useful for experimenting quickly -- ''quam celerrime revera''.

[[File:Interactive-Nasal-Console-REPL.png|600px|Philosopher's interactive Nasal console REPL]]
[[File:Interactive-Nasal-Console-REPL-Transparent-KSFO.png|600px|Now at KSFO with transparency enabled (no title bar/styling).]]

=== Copy & Paste Programming: A Compass Widget using Nasal/Canvas ===
[[File:Canvas-Compass-Widget.png|thumb|A Nasal/Canvas based compass widget]]
Inspired by a a recent forum discussion, Hooray thought that creating a compass widget would be a neat little project for someone interested in learning a bit more about Nasal and Canvas coding, and it should be possible to accomplish with less than 50-80 lines of code actually - there's a ton of stuff that you could reuse (SVG compass rose or an existing 2D panel texture), we have quite a few tutorials on Nasal, Canvas and Image processing (check the wiki). Furthermore, there is the long-term plan to eventually phase out the old 2D panel code and used a modernized [[Canvas]]-based version to help with [[Unifying the 2D rendering backend via canvas]]. Continue reading at [[Howto:Parsing 2D Instruments using the Canvas]]...

Paste this into your [[Nasal Console]] and click Execute:
<syntaxhighlight lang="nasal">
var CanvasApplication = {
##
# constructor
new: func(x=300,y=200) {
var m = { parents: [CanvasApplication] };
m.dlg = canvas.Window.new([x,y],"dialog");
m.canvas = m.dlg.createCanvas().setColorBackground(1,1,1,0.5);
m.root = m.canvas.createGroup();
m.timer = maketimer(0.1, func m.update() );
m.init();
return m;
},

del: func me.timer.stop(),

update: func() {
var hdg=getprop("/orientation/heading-deg");
me.compass.setRotation(-hdg*D2R);
},

init: func() {
var filename = "/Aircraft/Instruments/gyro.xml";
var temp= io.read_properties(getprop("/sim/fg-root") ~ filename);
var layers = temp.getValues().layers.layer;

var z=100;
foreach(var layer; layers ) {
print("new layer:", layer.name);

# if it's not a texture, skip
if (!contains(layer, "texture")) continue;

# get a handle to the texture of the layer
var texture = layer.texture;

# create an image child for the texture
var child=me.root.createChild("image")
.setFile( texture.path )
.setSourceRect( texture.x1, texture.x2, texture.y1, texture.y2 )
.setSize(layer.w,layer.h)
.setTranslation(20,20)
.set("z-index", z +=1 )
.setScale(2.5);

if (layer.w != nil and layer.h != nil)
child.setCenter(layer.w/2, layer.h/2);

if (layer.name=="compass rose") {
print("Found compass layer");
# child.setCenter(55,55);
me.compass = child;
}
} # foreach

me.timer.start();
},
}; # end of CanvasApplication

var InstrumentWidget = {
new: func(x,y) {
var m = CanvasApplication.new(x:x,y:y);
},
};

var compass = InstrumentWidget.new(x:300, y:300);

print("Compass Loaded...!");
</syntaxhighlight>

=== Canvas & Shaders: A match made in Heaven ? ===

For quite a while, we've been thinking that at some point, the [[Canvas]] system could probably benefit from being also able to also use FlightGear's effects/shader framework, so that canvas textures can also be processed via effects and shaders optionally, before they get drawn. That should make all sorts of fancy effects possible, such as night vision cameras or thermal view, rendered to canvas textures/groups.

That would then disable the default rendering pipeline for those canvas textures and use shaders.

Basically, anything that's not directly possible via the core canvas system or via its Nasal wrappers, would then be handled via effects/shaders. So we would gain lots of flexibility, and performance benefits.

So if people really want to create really fancy textures or camera views, they could use effects/shaders then, which would keep the design truly generic, and it would ensure that there's no bloat introduced into the main canvas system.

We did have some discussions about supporting per-canvas (actually per canvas::Element) effects and shaders via properties recently, TheTom even mentioned a while ago that he is interested in supporting this at some point, especially given the number of projects that could be realized like that (FLIR, night vision, thermal imaging etc).

At the time of writing this (02/2014) the Canvas does not yet include any support for applying custom effects or [[shaders]] to canvas elements or the whole canvas itself - however, supporting this is something that's been repeatedly discussed over time, so we're probably going to look into supporting this eventually[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37210.html].

Some very basic prototyping has already taken place and looks pretty encouraging:

<gallery mode=packed widths=150px heights=150px>
Canvas-glsl-support.png|airport selection dialog with a greyscale fragment shader applied to the canvas
Canvas-Fragment-Shader-red.png|a trivial fragment shader applied to a canvas (the original colors used in the Nasal code were not changed!)
Canvas-Fragment-Shader-circles.png|unmodified airport selection canvas with fragment shader applied
Canvas-Fragment-Shader-experiments.png|more canvas fragment shading experiments
</gallery>

Continue reading at [[Canvas Development#Effects & Shaders|Canvas & Shaders]]

=== A MapStructure Debugger ===

[[File:MapStructure-ND-Profiling.png|thumb|MapStructure Debugger running a [[NavDisplay]] and profiling a few layers.]]

[[MapStructure]] is a [[Nasal]]-space framework (designed and maintained by Philosopher) for managing layers of symbols in Nasal/[[Canvas]]-based mapping displays, which can be used in both aircraft MFDs/instruments like the [[NavDisplay]] (ND) and GUI dialogs, like the airport selection or [[Map]] dialogs. MapStructure is all about separating the visualization of the map from the visualized data itself, and the way it is shown to, and controlled by, the user. MapStructure is designed as a Model/View/Controller (MVC) framework.

The MapStructure debugger is a simple GUI dialog intended to be used for debugging and benchmarking MapStructure-based charting layers. In its current form, it simply shows a NavDisplay inside the dialog with several layers enabled, including a 2D graph to benchmark each individual layer (such as APT, DME, FIX, TFC).
Currently, the dialog is fairly simple and pretty crude, the plotting code is entirely based on [[FGPlot]] and needs to be further generalized eventually (see Canvas Plotting Framework). However, so far it's actually working nicely and can help determine where time is spent, i.e. which layers are "expensive" compared to others.
In addition, the MapStructure debugger dialog can be used to easily test MapStructure-based maps/charts like Gijs' NavDisplay, without having to start up a complex aircraft like the 747-400 or 777-200ER. In other words, the ND can be easily tested by using the ufo or ogeL - which are usually up and running within ~10 seconds.

Continue reading at [[MapStructure Debugger]]...

=== Canvas System ===

The F-16CJ is being renovated to include the most realistic fighter HUDs yet. See the progress at [[F-16CJ HUD Project Newsletter]] and [[http://forum.flightgear.org/viewtopic.php?f=71&t=22014 this forum topic]].

=== JSBSim Ground Effects ===
This is a heads up for JSBSim aircraft maintainers that user their own ground detection and handling code. As of this month JSBSim, just like YASim, supports ground effects like bumpiness, solid-ground detection and adjusting of friction actors. Actually JSBSim supports an extra feature, BOGEY contact points sink in a non-solid ground surface but STRUCTURE contact point do not, making it easy to define floats using STRUCTURE contact points.

In order not to pollute /fdm/jsbim too much Erik added the following properties:

;/sim/fdm/surface/override-level
:A user defined property which if defined and set to a something higher than 0 will disable the JSBSim ground reactions code completely and the following properties are set to false:
:* /sim/fdm/surface/active
:* /sim/fdm/surface/valid
: Otherwise the following applies:
:* /sim/fdm/surface/active
:: is set to true
:* /sim/fdm/surface/valid
:: is set to true if there is a valid material available or set to false otherwise (the material defaults are set).
; /fdm/jsbsim/ground/solid
: flag which defines if the surface is solid not
; /fdm/jsbsim/ground/bumpiness
: defines the bumpiness factor
; /fdm/jsbsim/ground/maximum-force-lbs
: maximum allowed force for this surface
; /fdm/jsbsim/ground/rolling_friction-factor
: rolling friction factor - applies to rolling friction
; /fdm/jsbsim/ground/static-friction-factor
: static friction factor - applies to static friction and dynamic friction

These properties are also set for the appropriate gear and contact units.

If you want to keep the old behaviour just set sim/fdm/surface/override-level to 1 somewhere in the configuration files, for Nasal this becomes:
<syntaxhighlight lang="nasal">
setprop("sim/fdm/surface/override-level", 1);
</syntaxhighlight>

The Nasal code has been updated for base package aircraft that have a custom ground interaction system. Not that some of these might actually be YASim aircraft but YASim will just ignore the property.

=== Getting involved as a programmer ===
Unfortunately, most of the active FlightGear 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]].

If you interested in other developing, i.e. not C++ but [[Nasal]] scripting and/or XML, there are some articles listed at [[:Category:Popular Community Requests]] that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from ''you'' -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at [[Nasal]], so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

== In the hangar ==

=== New aircraft ===
==== Junkers Ju 390 ====
'''Emmanuel Baranger, (helijah)'''

The Junkers Ju 390 was a German aircraft intended to be used as a heavy transport, maritime patrol aircraft, and long-range bomber, a long-range derivative of the Ju 290. It was one of the aircraft designs submitted for the abortive Amerika Bomber project, along with the Messerschmitt Me 264, the Focke-Wulf Ta 400, the Heinkel He 277.<ref>{{cite web |url=http://en.wikipedia.org/wiki/Junkers_Ju_390 |title=Junkers Ju 390 |publisher=Wikipedia }}</ref>

[[File:Ju390-17.png|200px|The tail gets up during the opening of the bay]]
[[File:Ju390-18.png|200px|above the sea]]
[[File:Ju390-19.png|200px|flying]]
[[File:Ju390-20.png|200px|flying 2]]

You can now find it in my hangar and on GIT hoping that you like as much as I enjoyed doing it.

==== Aichi M6A "Seiran" ====
'''Emmanuel Baranger, (helijah)'''

The Aichi M6A Seiran (晴嵐?, "Clear Sky Storm" or "Mist on a Fair Day") was a submarine-launched attack floatplane designed for the Imperial Japanese Navy during World War II. It was intended to operate from I-400 class submarines whose original mission was to conduct aerial attacks against the United States.<ref>{{cite web |url=http://en.wikipedia.org/wiki/Aichi_M6A |title=Aichi M6A |publisher=Wikipedia }}</ref>

[[File:Aichi M6A "Seiran".png|200px|On the water]]

You can now find it in my hangar and on GIT hoping that you like as much as I enjoyed doing it.

=== Updated aircraft ===
==== Sikorsky SH-60 Bravo Seahawk ====
'''James Cusick, (X7cusick8X)'''

The FlightGear Seahawk is an incredibly easy to fly helicopter designed for naval conditions, with its integrated FCS and FDM landing on carrier decks is a blast.

Recently i have take a break form FG but I am proud to announce the updated SH-60B Seahawk!
The updates include:
* Integrated Pushback
* Selectable payloads
* 95% complete folding animation for carrier deck transit
* New Liveries
* FDM Fixes
* and more

<gallery mode=packed widths=150px heights=150px>
SH-60 Bravo.png|SH-60B Taking off from the USS Carl Vinson
SH-60 Landing.png|SH-60 Landing
SH-60 Rotor Wash.png|Rotor Wash
</gallery>

== Scenery corner ==
A great work has been done this month for Spain, such as the city of Barcelona, with the addition of landmarks such as Sagrada Familia, Agbar tower and its airport. These updates are available using Terrasync.

List of updated airports (mostly in Spain, Brazil, and France):
{| class="vatop"
|width="300" |
* LEAB Albecete
* LEAT Alfes
* LEBG Burgos
* LEBL Barcelona - El Prat
* LECD La Cerdenya
* LECI Santa Cilia-Los Pirineos
* LECN Pinar de Castellon
* LEDA Lleida
* LEGE Girona
* LEHC Huescas/Pirineos
* LELL Sabadell
* LELN Leon
* LEPP Pamplona
* LERE Requena
* LESB Son Bonet
|width="300" |
* LESL San Luis
* LESO San Sebastian
* LESU Seo de Urgel
* LETL Teruel Plata
* LEVD Valladollid
* LFLG Le Versoud
* LFRB Brest Bretagne
* LFRN Rennes St Jacques
* PHNL Honolulu Intl
* SBNF Ministro Victor Konder
* SBPK Pelotas
* SBRJ Santos Dumont Airport
* SBUR Uberaba
* SPAF Camana
|}

=== Regional texturing ===

New regional texture definitions are now available on GIT for Ireland in the CORINE-landcover based WorldScenery 2.0. Enjoy the boglands of Connemara, or the hills and lakes of Kerry. With hires scenery and special textures, the Green Isle is now quite a nice place to explore.

The Ireland texture definitions have full support for procedural texturing and for the autumn coloring effect of ALS.

[[File:Eire02.jpg|300px| Connemara bog]]
[[File:Eire04.jpg|300px| Dingle peninsula]]
[[File:Eire05.jpg|300px| Kenmare bay]]

=== Models optimizations ===
Since a few months, works have been done on the scenery to clean existing models to make them lighter but keeping or even improving the overall quality. Among the tasks are deleting unseen faces, making face singled-sided, reducing texture size or removing unused alpha from texture.

== Community news ==
=== FlightGear &diams; Cross-Country Tutorial II &diams; a VFR guide ===
{|
| |
[[File:Coverwiki2.jpg|200px]]
| |
It's almost been a year since the first release of Cross-Country Tutorial II.<br />
Now with '''version three point zero''' the document is better than ever in many aspects.<br /> <br />
Go to the respective [http://forum.flightgear.org/viewtopic.php?f=72&t=19600 forum topic] where you can: <br />
*download this tutorial
*find out more about it
*'''post your comments and suggestions'''

coming up soon is the X-Country 2's own wiki page!
|}
== 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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

{{Appendix}}

[[Category:FlightGear Newsletter]]
[[Category:Changes after 3.00]]

Es/FlightGear Newsletter January 2014

2014-02-06T19:35:33Z

Wallkon: Se agregó llamado a traductores

Es/FlightGear Newsletter January 2014

2014-02-06T19:32:04Z

Wallkon: And finally: traducido

Es/FlightGear Newsletter

2014-02-06T19:26:55Z

Wallkon: Se quitó línea en blanco

[[File:magagazine.png|right]]
'''El Boletín de Noticias de FlightGear''' está destinado a proporcionar una colección de las últimas novedades de la comunidad mundial [[FlightGear]]. Con tantísimo desarrollo continuo, es casi imposible que alguien pueda mantenerse al día. El boletín se inició en Julio de 2009 y se presenta sobre una base mensual.

All editions are initialy written in English, this page only lists translated editions. For a complete overview, see [[FlightGear Newsletter]].

=== Archive ===
{| class="vatop" valign="top"
! align="left" | 2009
! align="left" | 2010
! align="left" | 2011
! align="left" | 2012
! align="left" | 2013
! align="left" | 2014
|-
|valign="bottom"|
* [[FlightGear Newsletter July 2009|Julio]]
* [[FlightGear Newsletter August 2009|Agosto]]
* [[FlightGear Newsletter September 2009|Septiembre]]
* [[FlightGear Newsletter October 2009|Octubre]]
* [[FlightGear Newsletter November 2009|Noviembre]]
* [[FlightGear Newsletter December 2009|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2010|Enero]]
* [[:es:FlightGear Newsletter February 2010|Febrero]]
* [[:es:FlightGear Newsletter March 2010|Marzo]]
* [[:es:FlightGear Newsletter April 2010|Abril]]
* [[:es:FlightGear Newsletter May 2010|Mayo]]
* [[:es:FlightGear Newsletter June 2010|Junio]]
* [[:es:FlightGear Newsletter July 2010|Julio]]
* [[:es:FlightGear Newsletter August 2010|Agosto]]
* [[:es:FlightGear Newsletter September 2010|Septiembre]]
* [[:es:FlightGear Newsletter October 2010|Octubre]]
* [[:es:FlightGear Newsletter November 2010|Noviembre]]
* [[:es:FlightGear Newsletter December 2010|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2011|Enero]]
* [[:es:FlightGear Newsletter February 2011|Febrero]]
* [[:es:FlightGear Newsletter March 2011|Marzo]]
* [[:es:FlightGear Newsletter April 2011|Abril]]
* [[:es:FlightGear Newsletter May 2011|Mayo]]
* [[:es:FlightGear Newsletter June 2011|Junio]]
* [[:es:FlightGear Newsletter July 2011|Julio]]
* [[:es:FlightGear Newsletter August 2011|Agosto]]
* [[:es:FlightGear Newsletter September 2011|Septiembre]]
* [[:es:FlightGear Newsletter October 2011|Octubre]]
* [[FlightGear Newsletter November 2011|Noviembre]] **
* [[FlightGear Newsletter December 2011|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2012|Enero]] **
* [[FlightGear Newsletter February 2012|Febrero]] **
* [[FlightGear Newsletter March 2012|Marzo]] **
* [[FlightGear Newsletter April 2012|Abril]] **
* [[FlightGear Newsletter May 2012|Mayo]] **
* [[FlightGear Newsletter June 2012|Junio]] **
* [[FlightGear Newsletter July 2012|Julio]] **
* [[FlightGear Newsletter August 2012|Agosto]] **
* [[FlightGear Newsletter September 2012|Septiembre]] **
* [[FlightGear Newsletter October 2012|Octubre]] **
* [[FlightGear Newsletter November 2012|Noviembre]] **
* [[FlightGear Newsletter December 2012|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2013|Enero]] **
* [[FlightGear Newsletter February 2013|Febrero]] **
* [[FlightGear Newsletter March 2013|Marzo]] **
* [[FlightGear Newsletter April 2013|Abril]] **
* [[FlightGear Newsletter May 2013|Mayo]] **
* [[FlightGear Newsletter June 2013|Junio]] **
* [[FlightGear Newsletter July 2013|Julio]] **
* [[:es:FlightGear Newsletter August 2013|Agosto]]
* [[:es:FlightGear Newsletter September 2013|Septiembre]]
* [[:es:FlightGear Newsletter October 2013|Octubre]]
* [[:es:FlightGear Newsletter November 2013|Noviembre]]
* [[:es:FlightGear Newsletter December 2013|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2014|Enero]]
|}

; ** Ediciones no traducidas aún.

=== Estás invitado a contribuir! ===
Nos gustaría destacar que el boletín mensual no puede vivir sin las contribuciones de los usuarios y desarrolladores de FlightGear. El boletín FlightGear es un boletín informativo impulsado por la comunidad, lo que significa que es creado y editado por personas como **tu** No es necesario ser un usuario de FlightGear desde hace mucho tiempo (o incluso desarrollador) para contribuir con el boletin de noticias.

De hecho, ayudar a escribir el boletín mensual de FlightGear es una manera excelente de empezar a contribuir con la comunidad FlightGear rápida y muy fácilmente.

Incluso si no tienes algo tuyo que añadir, son tambien muy apreciadas las revisiónes y mejoras de las aportaciones de otros, al igual que los esfuerzos para ayudar a traducir los boletines o incorporar imágenes de pantalla al boletín de noticias (por ejemplo, tomadas del foro o las listas de correo). Las capturas de pantalla se pueden cargar en [[Special:Upload]]

Todo el mundo con una cuenta wiki ([[Special:UserLogin|libre de registro]]) puede editar el boletín de noticias y toda contribución es bienvenida. Así que si sabes de algún proyecto relacionado con FlightGear, como por ejemplo un escenario actualizado o una aeronave, por favor, sientete invitado a añadir este tipo de noticias en el boletín.

Si necesitas ayuda usando el wiki, por favor no dudes en ponerte en contacto con nosotros a través de [http://forum.flightgear.org/viewforum.php?f=50 la sección del foro].

Se puede tomar y usar una plantilla simple que proporciona una estructura básica para el [[Talk:Next newsletter|próximo boletín]] Esta plantilla se puede copiar/pegar en cada nuevo boletín para ayudar a los usuarios a empezar a ofrecer contenidos.

El borrador para el próximo boletín siempre se puede encontrar en el [[Next newsletter|próximo boletín]].

Si el Inglés no es tu lengua materna, por favor, que no te preocupe ayudar en el boletín de noticias, siempre puedes fácilmente pedir a otros usuarios de FlightGear que revisen o corrijan tus cambios. Además, una de las maneras más fáciles de empezar es simplemente copiar/pegar texto del foro o de los debates en las listas de correo, tales como anuncios (nuevos aviones, nuevos escenarios, etc).

Otra opción clara para empezar es la aportación de enlaces a videos de YouTube relacionados con FlightGear. Para ello, tenemos una sección dedicada en cada boletín de noticias - mira en: "FlightGear en YouTube": [[Next newsletter#Community news]]

Para incrustar vídeos de YouTube directamente, sólo tienes que utilizar la siguiente sintaxis:
<nowiki>{{#ev:youtube|VBWZ6JZe_Mw|400| vídeo en invierno de planetacancun2 que muestra la nieve en FlightGear.}}</nowiki>

Si estás buscando otras maneras de participar, por favor mira en [[Es/Voluntarios|voluntarios]].

[[Category:FlightGear Newsletter]]
[[Category:Community|Newsletter]]
[[Category:List|Newsletter]]

[[en:FlightGear Newsletter]]
[[fr:FlightGear Newsletter]]

Es/FlightGear Newsletter

2014-02-06T19:26:13Z

Wallkon: Se agregó enero 2014

[[File:magagazine.png|right]]
'''El Boletín de Noticias de FlightGear''' está destinado a proporcionar una colección de las últimas novedades de la comunidad mundial [[FlightGear]]. Con tantísimo desarrollo continuo, es casi imposible que alguien pueda mantenerse al día. El boletín se inició en Julio de 2009 y se presenta sobre una base mensual.

All editions are initialy written in English, this page only lists translated editions. For a complete overview, see [[FlightGear Newsletter]].

=== Archive ===
{| class="vatop" valign="top"
! align="left" | 2009
! align="left" | 2010
! align="left" | 2011
! align="left" | 2012
! align="left" | 2013
! align="left" | 2014
|-
|valign="bottom"|
* [[FlightGear Newsletter July 2009|Julio]]
* [[FlightGear Newsletter August 2009|Agosto]]
* [[FlightGear Newsletter September 2009|Septiembre]]
* [[FlightGear Newsletter October 2009|Octubre]]
* [[FlightGear Newsletter November 2009|Noviembre]]
* [[FlightGear Newsletter December 2009|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2010|Enero]]
* [[:es:FlightGear Newsletter February 2010|Febrero]]
* [[:es:FlightGear Newsletter March 2010|Marzo]]
* [[:es:FlightGear Newsletter April 2010|Abril]]
* [[:es:FlightGear Newsletter May 2010|Mayo]]
* [[:es:FlightGear Newsletter June 2010|Junio]]
* [[:es:FlightGear Newsletter July 2010|Julio]]
* [[:es:FlightGear Newsletter August 2010|Agosto]]
* [[:es:FlightGear Newsletter September 2010|Septiembre]]
* [[:es:FlightGear Newsletter October 2010|Octubre]]
* [[:es:FlightGear Newsletter November 2010|Noviembre]]
* [[:es:FlightGear Newsletter December 2010|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2011|Enero]]
* [[:es:FlightGear Newsletter February 2011|Febrero]]
* [[:es:FlightGear Newsletter March 2011|Marzo]]
* [[:es:FlightGear Newsletter April 2011|Abril]]
* [[:es:FlightGear Newsletter May 2011|Mayo]]
* [[:es:FlightGear Newsletter June 2011|Junio]]
* [[:es:FlightGear Newsletter July 2011|Julio]]
* [[:es:FlightGear Newsletter August 2011|Agosto]]
* [[:es:FlightGear Newsletter September 2011|Septiembre]]
* [[:es:FlightGear Newsletter October 2011|Octubre]]
* [[FlightGear Newsletter November 2011|Noviembre]] **
* [[FlightGear Newsletter December 2011|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2012|Enero]] **
* [[FlightGear Newsletter February 2012|Febrero]] **
* [[FlightGear Newsletter March 2012|Marzo]] **
* [[FlightGear Newsletter April 2012|Abril]] **
* [[FlightGear Newsletter May 2012|Mayo]] **
* [[FlightGear Newsletter June 2012|Junio]] **
* [[FlightGear Newsletter July 2012|Julio]] **
* [[FlightGear Newsletter August 2012|Agosto]] **
* [[FlightGear Newsletter September 2012|Septiembre]] **
* [[FlightGear Newsletter October 2012|Octubre]] **
* [[FlightGear Newsletter November 2012|Noviembre]] **
* [[FlightGear Newsletter December 2012|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2013|Enero]] **
* [[FlightGear Newsletter February 2013|Febrero]] **
* [[FlightGear Newsletter March 2013|Marzo]] **
* [[FlightGear Newsletter April 2013|Abril]] **
* [[FlightGear Newsletter May 2013|Mayo]] **
* [[FlightGear Newsletter June 2013|Junio]] **
* [[FlightGear Newsletter July 2013|Julio]] **
* [[:es:FlightGear Newsletter August 2013|Agosto]]
* [[:es:FlightGear Newsletter September 2013|Septiembre]]
* [[:es:FlightGear Newsletter October 2013|Octubre]]
* [[:es:FlightGear Newsletter November 2013|Noviembre]]
* [[:es:FlightGear Newsletter December 2013|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2014|Enero]]
|}

; ** Ediciones no traducidas aún.

=== Estás invitado a contribuir! ===
Nos gustaría destacar que el boletín mensual no puede vivir sin las contribuciones de los usuarios y desarrolladores de FlightGear. El boletín FlightGear es un boletín informativo impulsado por la comunidad, lo que significa que es creado y editado por personas como **tu** No es necesario ser un usuario de FlightGear desde hace mucho tiempo (o incluso desarrollador) para contribuir con el boletin de noticias.

De hecho, ayudar a escribir el boletín mensual de FlightGear es una manera excelente de empezar a contribuir con la comunidad FlightGear rápida y muy fácilmente.

Incluso si no tienes algo tuyo que añadir, son tambien muy apreciadas las revisiónes y mejoras de las aportaciones de otros, al igual que los esfuerzos para ayudar a traducir los boletines o incorporar imágenes de pantalla al boletín de noticias (por ejemplo, tomadas del foro o las listas de correo). Las capturas de pantalla se pueden cargar en [[Special:Upload]]

Todo el mundo con una cuenta wiki ([[Special:UserLogin|libre de registro]]) puede editar el boletín de noticias y toda contribución es bienvenida. Así que si sabes de algún proyecto relacionado con FlightGear, como por ejemplo un escenario actualizado o una aeronave, por favor, sientete invitado a añadir este tipo de noticias en el boletín.

Si necesitas ayuda usando el wiki, por favor no dudes en ponerte en contacto con nosotros a través de [http://forum.flightgear.org/viewforum.php?f=50 la sección del foro].

Se puede tomar y usar una plantilla simple que proporciona una estructura básica para el [[Talk:Next newsletter|próximo boletín]] Esta plantilla se puede copiar/pegar en cada nuevo boletín para ayudar a los usuarios a empezar a ofrecer contenidos.

El borrador para el próximo boletín siempre se puede encontrar en el [[Next newsletter|próximo boletín]].

Si el Inglés no es tu lengua materna, por favor, que no te preocupe ayudar en el boletín de noticias, siempre puedes fácilmente pedir a otros usuarios de FlightGear que revisen o corrijan tus cambios. Además, una de las maneras más fáciles de empezar es simplemente copiar/pegar texto del foro o de los debates en las listas de correo, tales como anuncios (nuevos aviones, nuevos escenarios, etc).

Otra opción clara para empezar es la aportación de enlaces a videos de YouTube relacionados con FlightGear. Para ello, tenemos una sección dedicada en cada boletín de noticias - mira en: "FlightGear en YouTube": [[Next newsletter#Community news]]

Para incrustar vídeos de YouTube directamente, sólo tienes que utilizar la siguiente sintaxis:
<nowiki>{{#ev:youtube|VBWZ6JZe_Mw|400| vídeo en invierno de planetacancun2 que muestra la nieve en FlightGear.}}</nowiki>

Si estás buscando otras maneras de participar, por favor mira en [[Es/Voluntarios|voluntarios]].

[[Category:FlightGear Newsletter]]
[[Category:Community|Newsletter]]
[[Category:List|Newsletter]]

[[en:FlightGear Newsletter]]
[[fr:FlightGear Newsletter]]

Es/FlightGear Newsletter January 2014

2014-02-06T19:09:00Z

Wallkon: Screenshot of the month: traducido

Es/FlightGear Newsletter January 2014

2014-02-05T22:38:59Z

Wallkon: Scenery corner: traducido

Es/FlightGear Newsletter January 2014

2014-02-05T22:07:31Z

Wallkon: Updated JSBSim FDM for Sopwith Camel with historical features: traducido

Es/FlightGear Newsletter January 2014

2014-02-05T21:45:02Z

Wallkon: McDonnell Douglas MD 902 Explorer: traducido

Es/FlightGear Newsletter January 2014

2014-02-05T21:36:16Z

Wallkon: Rembrandt and Now the Canvas-Ready NavDisplay: traducido

Es/FlightGear Newsletter January 2014

2014-02-05T08:35:21Z

Wallkon: * Add-on Bombable actualizado a la versión 4.5b */: se agregó una letra eliminada por error

Es/FlightGear Newsletter January 2014

2014-02-05T08:33:18Z

Wallkon: Se agregó una nota para las traducciones faltantes

Es/FlightGear Newsletter January 2014

2014-02-05T08:30:43Z

Wallkon: DC-10-30 Getting a Flightdeck Refit: traducido parcialmente

Es/FlightGear Newsletter January 2014

2014-02-05T03:48:16Z

Wallkon: FlightGear addons and mods: traducido

Es/FlightGear Newsletter January 2014

2014-02-04T18:25:05Z

Wallkon: Using OpenStreetMap Data in FlightGear: traducido

Es/FlightGear Newsletter January 2014

2014-02-04T17:57:31Z

Wallkon: Atmospheric Light Scattering: traducido

Es/FlightGear Newsletter January 2014

2014-02-04T03:50:58Z

Wallkon: Creating a custom ATC/RADAR Layer in 10 minutes & Behind the Scenes of Nasal Loops: traducido (en rojo lo que no pude)

Es/FlightGear Newsletter January 2014

2014-02-04T02:30:27Z

Wallkon: Soaring instrumentation SDK: traducido

Es/FlightGear Newsletter January 2014

2014-02-04T02:01:26Z

Wallkon: FlightGear 3.0 release candidates: traducido

Es/FlightGear Newsletter December 2013

2014-01-08T22:52:10Z

Wallkon: /* Creación de Aeronaves Basado en Asistentes */ : se cambió el nivel del subtítulo

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

=== Creación de Aeronaves Basado en Asistentes ===
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [https://en.wikipedia.org/wiki/Skeleton_(computer_programming) 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Compilando los fuentes ===
Gracias al trabajo de '''Seatbutler''', el artículo [[Howto:Build FlightGear with NetBeans using CMake | 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 [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 este hilo del foro].

== En el hangar ==

=== Nueva Aeronave ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Desarrollo del Junkers Ju-288A en MetasequoiaLE
Junkers Ju-288.jpg|Otro ángulo del Junkers Ju-288A durante el desarrollo
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" volando sobre París en una nublada mañana de otoño
File:Caudron Type C.JPG|Caudron Type "C" en las laderas de un campo de Ródano-Alpes
</gallery>

=== Aeronave Actualizada ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|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.
rocketladder.png|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.
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Imagen que muestra nuevos estanques lanzables, soporte de bombas, hélice y parte de la mira K-14A
Rockets.png|Los nuevos cohetes HVAR y sus bastidores.
</gallery>

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, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 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 [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], la wiki de los desarrolladores del software wiki usado por FlightGear Wiki.

En resumen, se han hecho los siguientes cambios:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – 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 ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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: [[:es:Voluntarios|Voluntarios]].

Para aprender más acerca de cómo trabaja el proyecto, por favor revisa [http://forum.flightgear.org/viewtopic.php?f=42&t=15267#p149971 este breve ensayo] escrito por Thorsten, y para un artículo más detallado revisa [[How the FlightGear project works|Cómo funciona el proyecto FlightGear]].

=== YASim busca nuevo mantenedor ===
{{cquote|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..<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[en:FlightGear Newsletter December 2013]]
[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter

2014-01-06T19:32:03Z

Wallkon: Se agregó diciembre 2013

[[File:magagazine.png|right]]
'''El Boletín de Noticias de FlightGear''' está destinado a proporcionar una colección de las últimas novedades de la comunidad mundial [[FlightGear]]. Con tantísimo desarrollo continuo, es casi imposible que alguien pueda mantenerse al día. El boletín se inició en Julio de 2009 y se presenta sobre una base mensual.

All editions are initialy written in English, this page only lists translated editions. For a complete overview, see [[FlightGear Newsletter]].

=== Archive ===
{| class="vatop" valign="top"
! align="left" | 2009
! align="left" | 2010
! align="left" | 2011
! align="left" | 2012
! align="left" | 2013
|-
|valign="bottom"|
* [[FlightGear Newsletter July 2009|Julio]]
* [[FlightGear Newsletter August 2009|Agosto]]
* [[FlightGear Newsletter September 2009|Septiembre]]
* [[FlightGear Newsletter October 2009|Octubre]]
* [[FlightGear Newsletter November 2009|Noviembre]]
* [[FlightGear Newsletter December 2009|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2010|Enero]]
* [[:es:FlightGear Newsletter February 2010|Febrero]]
* [[:es:FlightGear Newsletter March 2010|Marzo]]
* [[:es:FlightGear Newsletter April 2010|Abril]]
* [[:es:FlightGear Newsletter May 2010|Mayo]]
* [[:es:FlightGear Newsletter June 2010|Junio]]
* [[:es:FlightGear Newsletter July 2010|Julio]]
* [[:es:FlightGear Newsletter August 2010|Agosto]]
* [[:es:FlightGear Newsletter September 2010|Septiembre]]
* [[:es:FlightGear Newsletter October 2010|Octubre]]
* [[:es:FlightGear Newsletter November 2010|Noviembre]]
* [[:es:FlightGear Newsletter December 2010|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2011|Enero]]
* [[:es:FlightGear Newsletter February 2011|Febrero]]
* [[:es:FlightGear Newsletter March 2011|Marzo]]
* [[:es:FlightGear Newsletter April 2011|Abril]]
* [[:es:FlightGear Newsletter May 2011|Mayo]]
* [[:es:FlightGear Newsletter June 2011|Junio]]
* [[:es:FlightGear Newsletter July 2011|Julio]]
* [[:es:FlightGear Newsletter August 2011|Agosto]]
* [[:es:FlightGear Newsletter September 2011|Septiembre]]
* [[:es:FlightGear Newsletter October 2011|Octubre]]
* [[FlightGear Newsletter November 2011|Noviembre]] **
* [[FlightGear Newsletter December 2011|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2012|Enero]] **
* [[FlightGear Newsletter February 2012|Febrero]] **
* [[FlightGear Newsletter March 2012|Marzo]] **
* [[FlightGear Newsletter April 2012|Abril]] **
* [[FlightGear Newsletter May 2012|Mayo]] **
* [[FlightGear Newsletter June 2012|Junio]] **
* [[FlightGear Newsletter July 2012|Julio]] **
* [[FlightGear Newsletter August 2012|Agosto]] **
* [[FlightGear Newsletter September 2012|Septiembre]] **
* [[FlightGear Newsletter October 2012|Octubre]] **
* [[FlightGear Newsletter November 2012|Noviembre]] **
* [[FlightGear Newsletter December 2012|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2013|Enero]] **
* [[FlightGear Newsletter February 2013|Febrero]] **
* [[FlightGear Newsletter March 2013|Marzo]] **
* [[FlightGear Newsletter April 2013|Abril]] **
* [[FlightGear Newsletter May 2013|Mayo]] **
* [[FlightGear Newsletter June 2013|Junio]] **
* [[FlightGear Newsletter July 2013|Julio]] **
* [[:es:FlightGear Newsletter August 2013|Agosto]]
* [[:es:FlightGear Newsletter September 2013|Septiembre]]
* [[:es:FlightGear Newsletter October 2013|Octubre]]
* [[:es:FlightGear Newsletter November 2013|Noviembre]]
* [[:es:FlightGear Newsletter December 2013|Diciembre]]
|}

; ** Las ultimas ediciones no están traducidas aun.

=== Estás invitado a contribuir! ===
Nos gustaría destacar que el boletín mensual no puede vivir sin las contribuciones de los usuarios y desarrolladores de FlightGear. El boletín FlightGear es un boletín informativo impulsado por la comunidad, lo que significa que es creado y editado por personas como **tu** No es necesario ser un usuario de FlightGear desde hace mucho tiempo (o incluso desarrollador) para contribuir con el boletin de noticias.

De hecho, ayudar a escribir el boletín mensual de FlightGear es una manera excelente de empezar a contribuir con la comunidad FlightGear rápida y muy fácilmente.

Incluso si no tienes algo tuyo que añadir, son tambien muy apreciadas las revisiónes y mejoras de las aportaciones de otros, al igual que los esfuerzos para ayudar a traducir los boletines o incorporar imágenes de pantalla al boletín de noticias (por ejemplo, tomadas del foro o las listas de correo). Las capturas de pantalla se pueden cargar en [[Special:Upload]]

Todo el mundo con una cuenta wiki ([[Special:UserLogin|libre de registro]]) puede editar el boletín de noticias y toda contribución es bienvenida. Así que si sabes de algún proyecto relacionado con FlightGear, como por ejemplo un escenario actualizado o una aeronave, por favor, sientete invitado a añadir este tipo de noticias en el boletín.

Si necesitas ayuda usando el wiki, por favor no dudes en ponerte en contacto con nosotros a través de [http://forum.flightgear.org/viewforum.php?f=50 la sección del foro].

Se puede tomar y usar una plantilla simple que proporciona una estructura básica para el [[Talk:Next newsletter|próximo boletín]] Esta plantilla se puede copiar/pegar en cada nuevo boletín para ayudar a los usuarios a empezar a ofrecer contenidos.

El borrador para el próximo boletín siempre se puede encontrar en el [[Next newsletter|próximo boletín]].

Si el Inglés no es tu lengua materna, por favor, que no te preocupe ayudar en el boletín de noticias, siempre puedes fácilmente pedir a otros usuarios de FlightGear que revisen o corrijan tus cambios. Además, una de las maneras más fáciles de empezar es simplemente copiar/pegar texto del foro o de los debates en las listas de correo, tales como anuncios (nuevos aviones, nuevos escenarios, etc).

Otra opción clara para empezar es la aportación de enlaces a videos de YouTube relacionados con FlightGear. Para ello, tenemos una sección dedicada en cada boletín de noticias - mira en: "FlightGear en YouTube": [[Next newsletter#Community news]]

Para incrustar vídeos de YouTube directamente, sólo tienes que utilizar la siguiente sintaxis:
<nowiki>{{#ev:youtube|VBWZ6JZe_Mw|400| vídeo en invierno de planetacancun2 que muestra la nieve en FlightGear.}}</nowiki>

Si estás buscando otras maneras de participar, por favor mira en [[Es/Voluntarios|voluntarios]].

[[Category:FlightGear Newsletter]]
[[Category:Community|Newsletter]]
[[Category:List|Newsletter]]

[[en:FlightGear Newsletter]]
[[fr:FlightGear Newsletter]]

Es/FlightGear Newsletter December 2013

2014-01-06T19:30:26Z

Wallkon: Creación de Aeronaves Basado en Asistentes: se agregó link a wikipedia

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [https://en.wikipedia.org/wiki/Skeleton_(computer_programming) 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Compilando los fuentes ===
Gracias al trabajo de '''Seatbutler''', el artículo [[Howto:Build FlightGear with NetBeans using CMake | 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 [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 este hilo del foro].

== En el hangar ==

=== Nueva Aeronave ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Desarrollo del Junkers Ju-288A en MetasequoiaLE
Junkers Ju-288.jpg|Otro ángulo del Junkers Ju-288A durante el desarrollo
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" volando sobre París en una nublada mañana de otoño
File:Caudron Type C.JPG|Caudron Type "C" en las laderas de un campo de Ródano-Alpes
</gallery>

=== Aeronave Actualizada ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|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.
rocketladder.png|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.
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Imagen que muestra nuevos estanques lanzables, soporte de bombas, hélice y parte de la mira K-14A
Rockets.png|Los nuevos cohetes HVAR y sus bastidores.
</gallery>

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, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 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 [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], la wiki de los desarrolladores del software wiki usado por FlightGear Wiki.

En resumen, se han hecho los siguientes cambios:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – 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 ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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: [[:es:Voluntarios|Voluntarios]].

Para aprender más acerca de cómo trabaja el proyecto, por favor revisa [http://forum.flightgear.org/viewtopic.php?f=42&t=15267#p149971 este breve ensayo] escrito por Thorsten, y para un artículo más detallado revisa [[How the FlightGear project works|Cómo funciona el proyecto FlightGear]].

=== YASim busca nuevo mantenedor ===
{{cquote|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..<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[en:FlightGear Newsletter December 2013]]
[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter December 2013

2014-01-06T18:57:41Z

Wallkon: And finally ...: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Compilando los fuentes ===
Gracias al trabajo de '''Seatbutler''', el artículo [[Howto:Build FlightGear with NetBeans using CMake | 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 [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 este hilo del foro].

== En el hangar ==

=== Nueva Aeronave ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Desarrollo del Junkers Ju-288A en MetasequoiaLE
Junkers Ju-288.jpg|Otro ángulo del Junkers Ju-288A durante el desarrollo
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" volando sobre París en una nublada mañana de otoño
File:Caudron Type C.JPG|Caudron Type "C" en las laderas de un campo de Ródano-Alpes
</gallery>

=== Aeronave Actualizada ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|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.
rocketladder.png|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.
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Imagen que muestra nuevos estanques lanzables, soporte de bombas, hélice y parte de la mira K-14A
Rockets.png|Los nuevos cohetes HVAR y sus bastidores.
</gallery>

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, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 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 [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], la wiki de los desarrolladores del software wiki usado por FlightGear Wiki.

En resumen, se han hecho los siguientes cambios:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – 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 ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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: [[:es:Voluntarios|Voluntarios]].

Para aprender más acerca de cómo trabaja el proyecto, por favor revisa [http://forum.flightgear.org/viewtopic.php?f=42&t=15267#p149971 este breve ensayo] escrito por Thorsten, y para un artículo más detallado revisa [[How the FlightGear project works|Cómo funciona el proyecto FlightGear]].

=== YASim busca nuevo mantenedor ===
{{cquote|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..<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[en:FlightGear Newsletter December 2013]]
[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Talk:FlightGear Newsletter December 2013

2014-01-06T18:45:17Z

Wallkon: Another question

Hello, I'm translating the newsletter and I have a doubt with the concepts "stub" and "skeleton" used in "Wizard-based Aircraft Creation" section, are these used as C++ concepts?. Thanks.

Mmmm, I think "Usability Improvements" subtitle must be deleted or this is not in the right place.

{{unsigned|07:03, 5 January 2014‎|Wallkon}}

: Hi,
: you were correct about "Usability Improvements". I've removed that heading.
: I don't know about the concepts, best to ask Hooray, the author of that section. In general, "stub" refers to a (short) example/draft that needs to be further extended before it can be used. "Skeleton" probably refers to a simple (file/folder) structure, consisting of the essential parts to make an aircraft fly in FlightGear.
: Cheers, [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 13:47, 5 January 2014 (UTC)
: PS: Please sign messages on wiki talk pages with <nowiki>~~~~</nowiki>

::: Hi Wallkon, first of thank you -once again- for doing this, translating the newsletter is really appreciated, and we really need more contributors like you !
::: Regarding the terms you mentioned, Gijs is actually right. A [https://en.wikipedia.org/wiki/Skeleton_(computer_programming) skeleton] is basically a "template" that can be filled in and parameterized, a [https://en.wikipedia.org/wiki/Method_stub stub] is a placeholder that waits to be adopted and extended by others. So this is not really about C++ or Nasal, these are just words to indicate that something only just got started and needs to be extended to be useful (stubs) or that something is just a generic template that is not specific to a particular use-case, i.e. needs to be customized. HTH & Thanks again for all your contributions here! --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:42, 5 January 2014 (UTC)

Hello, could you tell me what is the meaning of cc: in the following sentence "Just cc: me if you do". I guess this is related to "carbon copy" used in e-mails, but I am not sure.

Thanks in advance. [[User:Wallkon|Wallkon]] ([[User talk:Wallkon|talk]]) 18:45, 6 January 2014 (UTC)

Es/FlightGear Newsletter December 2013

2014-01-06T17:13:20Z

Wallkon: Wiki updates: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Compilando los fuentes ===
Gracias al trabajo de '''Seatbutler''', el artículo [[Howto:Build FlightGear with NetBeans using CMake | 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 [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 este hilo del foro].

== En el hangar ==

=== Nueva Aeronave ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Desarrollo del Junkers Ju-288A en MetasequoiaLE
Junkers Ju-288.jpg|Otro ángulo del Junkers Ju-288A durante el desarrollo
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" volando sobre París en una nublada mañana de otoño
File:Caudron Type C.JPG|Caudron Type "C" en las laderas de un campo de Ródano-Alpes
</gallery>

=== Aeronave Actualizada ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|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.
rocketladder.png|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.
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Imagen que muestra nuevos estanques lanzables, soporte de bombas, hélice y parte de la mira K-14A
Rockets.png|Los nuevos cohetes HVAR y sus bastidores.
</gallery>

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, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 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 [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], la wiki de los desarrolladores del software wiki usado por FlightGear Wiki.

En resumen, se han hecho los siguientes cambios:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Reescrita y extendida
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – 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 ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter December 2013

2014-01-06T04:55:56Z

Wallkon: /* Updated aircraft */: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Compilando los fuentes ===
Gracias al trabajo de '''Seatbutler''', el artículo [[Howto:Build FlightGear with NetBeans using CMake | 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 [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 este hilo del foro].

== En el hangar ==

=== Nueva Aeronave ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Desarrollo del Junkers Ju-288A en MetasequoiaLE
Junkers Ju-288.jpg|Otro ángulo del Junkers Ju-288A durante el desarrollo
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" volando sobre París en una nublada mañana de otoño
File:Caudron Type C.JPG|Caudron Type "C" en las laderas de un campo de Ródano-Alpes
</gallery>

=== Aeronave Actualizada ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|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.
rocketladder.png|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.
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Imagen que muestra nuevos estanques lanzables, soporte de bombas, hélice y parte de la mira K-14A
Rockets.png|Los nuevos cohetes HVAR y sus bastidores.
</gallery>

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

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter December 2013

2014-01-06T00:19:41Z

Wallkon: New Aircraft: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Compilando los fuentes ===
Gracias al trabajo de '''Seatbutler''', el artículo [[Howto:Build FlightGear with NetBeans using CMake | 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 [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 este hilo del foro].

== En el hangar ==

=== Nueva Aeronave ===
==== 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.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Desarrollo del Junkers Ju-288A en MetasequoiaLE
Junkers Ju-288.jpg|Otro ángulo del Junkers Ju-288A durante el desarrollo
</gallery>

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.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" volando sobre París en una nublada mañana de otoño
File:Caudron Type C.JPG|Caudron Type "C" en las laderas de un campo de Ródano-Alpes
</gallery>

=== Updated aircraft ===
==== North American P-51D Mustang ====
The JSBSim [[P-51D]] is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|Screen shot of the K-14A in action showing the gyroscopic reticle rolled over pulling G. Note how the tracers are converging near the center of the gyro reticle. In addition, the fixed reticle is masked and only the center cross is visible. The fixed reticle center cross is the bore sight line.
rocketladder.png|Screen of a rocket attack on a fishing boat. The reticle being used is the fixed reticle with the 70 mil circle and the rocket ladder unmasked.
</gallery>

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Screen shot showing new droop tanks, bomb racks, propeller and part of the K-14A gun sight.
Rockets.png|The new HVAR rockets and the new rocket mounts.
</gallery>

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter December 2013

2014-01-05T20:28:09Z

Wallkon: "Building from Source" & "Hardware development": traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Compilando los fuentes ===
Gracias al trabajo de '''Seatbutler''', el artículo [[Howto:Build FlightGear with NetBeans using CMake | 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 [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 este hilo del foro].

== In the hangar ==

=== New Aircraft ===
==== Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo ====
Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Junkers Ju-288A in development in MetasequoiaLE
Junkers Ju-288.jpg|Another angle of the in-development Junkers Ju-288A
</gallery>

Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" flying over Paris in a morning late fall fog.
File:Caudron Type C.JPG|Caudron Type "C" on the slopes of a Rhone Alp's meadow.
</gallery>

=== Updated aircraft ===
==== North American P-51D Mustang ====
The JSBSim [[P-51D]] is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|Screen shot of the K-14A in action showing the gyroscopic reticle rolled over pulling G. Note how the tracers are converging near the center of the gyro reticle. In addition, the fixed reticle is masked and only the center cross is visible. The fixed reticle center cross is the bore sight line.
rocketladder.png|Screen of a rocket attack on a fishing boat. The reticle being used is the fixed reticle with the 70 mil circle and the rocket ladder unmasked.
</gallery>

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Screen shot showing new droop tanks, bomb racks, propeller and part of the K-14A gun sight.
Rockets.png|The new HVAR rockets and the new rocket mounts.
</gallery>

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter December 2013

2014-01-05T19:33:27Z

Wallkon: Alternative camera control: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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 ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

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 [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 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 [[Howto:Start core development | Comenzar como desarrollador del núcleo]].

=== Building from Source ===
Thanks to work done by '''Seatbutler''', the [[Howto:Build FlightGear with NetBeans using CMake]] article has recently been updated and verified to still work.

== Hardware development==
=== Project computer2cockpit ===
Following design changes suggested by FlightGear users, the [[computer2cockpit]]'s flight yoke design has been extended with:
* Map holder
* Additional rocker switch and push button switches on right side of the yoke
* Additional push to talk switch
Curent activities:
* Prototype manufacturing preparation - setting up the CNC router
* Talking with suppliers to lower the initial costs and production price

=== DIY hardware panel for FlightGear ===
At least five projects exist where FlightGear users build their own hardware panels with real switches and knobs to interface with the FlightGear software to improve the flying experience. Follow the build progress of ludomotico's and pommesschranke's panels on [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 this forum thread].

== In the hangar ==

=== New Aircraft ===
==== Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo ====
Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Junkers Ju-288A in development in MetasequoiaLE
Junkers Ju-288.jpg|Another angle of the in-development Junkers Ju-288A
</gallery>

Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" flying over Paris in a morning late fall fog.
File:Caudron Type C.JPG|Caudron Type "C" on the slopes of a Rhone Alp's meadow.
</gallery>

=== Updated aircraft ===
==== North American P-51D Mustang ====
The JSBSim [[P-51D]] is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|Screen shot of the K-14A in action showing the gyroscopic reticle rolled over pulling G. Note how the tracers are converging near the center of the gyro reticle. In addition, the fixed reticle is masked and only the center cross is visible. The fixed reticle center cross is the bore sight line.
rocketladder.png|Screen of a rocket attack on a fishing boat. The reticle being used is the fixed reticle with the 70 mil circle and the rocket ladder unmasked.
</gallery>

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Screen shot showing new droop tanks, bomb racks, propeller and part of the K-14A gun sight.
Rockets.png|The new HVAR rockets and the new rocket mounts.
</gallery>

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Talk:FlightGear Newsletter December 2013

2014-01-05T07:03:37Z

Wallkon:

Es/FlightGear Newsletter December 2013

2014-01-05T06:58:05Z

Wallkon: Implementing VNAV -a Brainstorming: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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 ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|Ventana de administración de ruta con nuevo soporte para exportar a JSBSim o hacia archivos XML FGScript]]
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]]...

===Alternative camera control ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

Fellow FlightGear user Marius_A has created a virtual camera for FligthGear that's written in [[Nasal]], it adds features similar to Ezdok Camera Addon for FSX.

Continue reading [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 the forum]...

=== Usability Improvements ===

=== 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]].

=== Building from Source ===
Thanks to work done by '''Seatbutler''', the [[Howto:Build FlightGear with NetBeans using CMake]] article has recently been updated and verified to still work.

== Hardware development==
=== Project computer2cockpit ===
Following design changes suggested by FlightGear users, the [[computer2cockpit]]'s flight yoke design has been extended with:
* Map holder
* Additional rocker switch and push button switches on right side of the yoke
* Additional push to talk switch
Curent activities:
* Prototype manufacturing preparation - setting up the CNC router
* Talking with suppliers to lower the initial costs and production price

=== DIY hardware panel for FlightGear ===
At least five projects exist where FlightGear users build their own hardware panels with real switches and knobs to interface with the FlightGear software to improve the flying experience. Follow the build progress of ludomotico's and pommesschranke's panels on [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 this forum thread].

== In the hangar ==

=== New Aircraft ===
==== Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo ====
Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Junkers Ju-288A in development in MetasequoiaLE
Junkers Ju-288.jpg|Another angle of the in-development Junkers Ju-288A
</gallery>

Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" flying over Paris in a morning late fall fog.
File:Caudron Type C.JPG|Caudron Type "C" on the slopes of a Rhone Alp's meadow.
</gallery>

=== Updated aircraft ===
==== North American P-51D Mustang ====
The JSBSim [[P-51D]] is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|Screen shot of the K-14A in action showing the gyroscopic reticle rolled over pulling G. Note how the tracers are converging near the center of the gyro reticle. In addition, the fixed reticle is masked and only the center cross is visible. The fixed reticle center cross is the bore sight line.
rocketladder.png|Screen of a rocket attack on a fishing boat. The reticle being used is the fixed reticle with the 70 mil circle and the rocket ladder unmasked.
</gallery>

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Screen shot showing new droop tanks, bomb racks, propeller and part of the K-14A gun sight.
Rockets.png|The new HVAR rockets and the new rocket mounts.
</gallery>

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter December 2013

2014-01-05T06:08:53Z

Wallkon: Wizard-based Aircraft Creation: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Creación de Aeronaves Basado en Asistentes ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

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, [http://wiki.flightgear.org/Canvas 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 [http://es.wikipedia.org/wiki/Stub 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 [http://wiki.flightgear.org/Canvas 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 [[Aircraft Checklists | checklists]], [[Tutorials | tutoriales]], [[Walk View | 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]]...

=== Implementing VNAV -a Brainstorming ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|route manager dialog with added support for exporting to JSBSim/FGScript XML files]]
We've recently had another discussion on the forums about implementing VNAV in FlightGear. In comparison with other flight simulators, FlightGear has been lacking support for simulating VNAV features found on many modern aircraft since day one.

So far, the general consensus has been that it simply isn't yet possible in FlightGear to properly implement VNAV because VNAV depends on having access to an aircraft-specific performance database to provide the proper pitch/thrust changes to make certain VNAV altitude/speed/time constraints, which boils down to a lack of support by the FDMs (JSBsim/YaSim) actually.

As an open source project, we do not have access to the corresponding flight data or such a performance database, and even if we did, we probably couldn't easily use said data due to its proprietary nature.

In addition, a real performance database would probably not serve us too well, because our FDM configurations are custom, too - i.e. the performance database would need to match the performance of the simulated aircraft.

Thus, a performance DB would ideally be provided by the FDM itself. Either in a pre-created fashion, i.e. compiled during an offline "test flight", or preferably at runtime by running a simulation of the FDM inside the actual FDM.

We've now started gathering all information from past VNAV discussions to come up with a brainstorming and determine how to implement the building blocks required for supporting VNAV (vertical navigation) in FlightGear (YaSim/JSBSim). Any feedback is greatly appreciated.

Continue reading at [[Implementing VNAV support in FlightGear]]...

===Alternative camera control ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

Fellow FlightGear user Marius_A has created a virtual camera for FligthGear that's written in [[Nasal]], it adds features similar to Ezdok Camera Addon for FSX.

Continue reading [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 the forum]...

=== Usability Improvements ===

=== 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]].

=== Building from Source ===
Thanks to work done by '''Seatbutler''', the [[Howto:Build FlightGear with NetBeans using CMake]] article has recently been updated and verified to still work.

== Hardware development==
=== Project computer2cockpit ===
Following design changes suggested by FlightGear users, the [[computer2cockpit]]'s flight yoke design has been extended with:
* Map holder
* Additional rocker switch and push button switches on right side of the yoke
* Additional push to talk switch
Curent activities:
* Prototype manufacturing preparation - setting up the CNC router
* Talking with suppliers to lower the initial costs and production price

=== DIY hardware panel for FlightGear ===
At least five projects exist where FlightGear users build their own hardware panels with real switches and knobs to interface with the FlightGear software to improve the flying experience. Follow the build progress of ludomotico's and pommesschranke's panels on [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 this forum thread].

== In the hangar ==

=== New Aircraft ===
==== Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo ====
Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Junkers Ju-288A in development in MetasequoiaLE
Junkers Ju-288.jpg|Another angle of the in-development Junkers Ju-288A
</gallery>

Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" flying over Paris in a morning late fall fog.
File:Caudron Type C.JPG|Caudron Type "C" on the slopes of a Rhone Alp's meadow.
</gallery>

=== Updated aircraft ===
==== North American P-51D Mustang ====
The JSBSim [[P-51D]] is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|Screen shot of the K-14A in action showing the gyroscopic reticle rolled over pulling G. Note how the tracers are converging near the center of the gyro reticle. In addition, the fixed reticle is masked and only the center cross is visible. The fixed reticle center cross is the bore sight line.
rocketladder.png|Screen of a rocket attack on a fishing boat. The reticle being used is the fixed reticle with the 70 mil circle and the rocket ladder unmasked.
</gallery>

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Screen shot showing new droop tanks, bomb racks, propeller and part of the K-14A gun sight.
Rockets.png|The new HVAR rockets and the new rocket mounts.
</gallery>

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Talk:FlightGear Newsletter December 2013

2014-01-05T04:25:37Z

Wallkon: Doubts about some concepts

Hello, I'm translating the newsletter and I have a doubt with the concepts "stub" and "skeleton" used in "Wizard-based Aircraft Creation" section, are these used as C++ concepts?. Thanks.

Es/FlightGear Newsletter December 2013

2014-01-05T03:26:00Z

Wallkon: NavDisplay Improvements: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== Mejoras a NavDisplay ===
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:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|Modo MAP
Navigation display centered MAP mode.png|Modo MAP centrado
Navigation display PLAN mode.png|Modo PLAN
</gallery>

== Wizard-based Aircraft Creation ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

When it comes to aircraft development, one of the areas that people find frustrating is that features used by aircraft developers will be documented in the Wiki but the examples are so minimal that it can be difficult or nearly impossible to get something working because the published examples are lacking in detail or don't show important variations of how to code the feature.

We've come to the conclusion, the best step towards fixing these issues is to have a set of templates for common aircraft configurations (single engine prop, multi-engine prop, single engine jet, multi-engine jet with co-pilot etc). These templates would have all of the minimal components to compose a "production" aircraft (according to the rating guide).

We've been tossing around that idea for a while, i.e. coming up with project-maintained "templates" for things like aircraft, to ensure that people have some way to get guidance without overly relying on extensive copy/paste programming - we really only need someone to start with a "dummy" aircraft that, with lots of comments and options (Nasal, sound, canvas, help, checklists, tutorials). In fact, it would even be possible to provide wizards to help customize such templates, i.e. to change name/author/status, 3D models, file names (sound, textures).

The idea is that we should have a set of standard aircraft templates, or some fancy means of generating an aircraft skeleton based on some user input. These templates would contain all necessary files and code to implement a simple but complete aircraft of a given configuration (single engine prop, multi-engine jet etc), and possibly stubs for common enhancements.
Standard enhancements (checklists, autopilots etc) could be included as comments indicating where code needs to be added, This would make FG aircraft more consistent, but also help newbie aircraft developers to get of the initial obstacle of understanding how it all comes together. I think this would help us overcome the issue of having so many aircraft in various pre-production states of development.

During the discussion on the forum, we came up with the ideas that we could have a template aircraft and parametrize it dynamically inside FlightGear - after all, it's 95% PropertyList-encoded XML, i.e. can be read/manipulated and written via standard FlightGear/Nasal means - in other words, you could take an existing PUI dialog and turn it into an "aircraft wizard", where the user could specify things like 1) filename, 2) description, 3) FDM type, 4) status, 5) thumbnail and so on - this is all straightforward to do, it just involves setprop() stuff after having read the template into the property tree via io.read_properties(), at which point a simple GUI dialog could be shown to streamline the aircraft development process in a step-by-step manner. Many building blocks exist already, including a file picker dialog - missing stuff can be implemented via Canvas extensions.

Such a wizard woud ideally not be implemented as a "hardcoded" XML dialog, but rather as a Nasal submodule that dynamically creates "pages" for each step in the wizard. None of this is difficult, it really just involves 1) property tree, 2) read/write properties via io.nas and 3) basic Nasal (setprop/props.nas) for modifying the template aircraft.
Such a wizard could also be easily made aware of difference between FG versions, and users could be asked to target a certain version, i.e. to omit certain stuff, like for example Canvas support, or effects etc

A first, very basic, prototype of this is now available, and waiting to be adopted by fellow contributors to help grow this "wizard", i.e. by adding features to it, but also by adding new templates to it, for different aircraft features, such as [[Aircraft Checklists]], [[Tutorials]], [[Walk View]] etc.

Given that most of us are already juggling too many projects, we're also looking for people who would possibly like to get involved in this in some way.

Coding-wise, this is currently just about 150 lines of very simple [[Nasal]] code, copied together from various other dialogs and wiki tutorials. So knowing Nasal would be a plus, but if you have any other scripting/programming experience, that will do too. So if you are interested in FlightGear scripting and simplifying aircraft deveopment for newcomers, please get in touch via the forum or the wiki.

Continue reading at [[Aircraft Generation Wizard]]...

=== Implementing VNAV -a Brainstorming ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|route manager dialog with added support for exporting to JSBSim/FGScript XML files]]
We've recently had another discussion on the forums about implementing VNAV in FlightGear. In comparison with other flight simulators, FlightGear has been lacking support for simulating VNAV features found on many modern aircraft since day one.

So far, the general consensus has been that it simply isn't yet possible in FlightGear to properly implement VNAV because VNAV depends on having access to an aircraft-specific performance database to provide the proper pitch/thrust changes to make certain VNAV altitude/speed/time constraints, which boils down to a lack of support by the FDMs (JSBsim/YaSim) actually.

As an open source project, we do not have access to the corresponding flight data or such a performance database, and even if we did, we probably couldn't easily use said data due to its proprietary nature.

In addition, a real performance database would probably not serve us too well, because our FDM configurations are custom, too - i.e. the performance database would need to match the performance of the simulated aircraft.

Thus, a performance DB would ideally be provided by the FDM itself. Either in a pre-created fashion, i.e. compiled during an offline "test flight", or preferably at runtime by running a simulation of the FDM inside the actual FDM.

We've now started gathering all information from past VNAV discussions to come up with a brainstorming and determine how to implement the building blocks required for supporting VNAV (vertical navigation) in FlightGear (YaSim/JSBSim). Any feedback is greatly appreciated.

Continue reading at [[Implementing VNAV support in FlightGear]]...

===Alternative camera control ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

Fellow FlightGear user Marius_A has created a virtual camera for FligthGear that's written in [[Nasal]], it adds features similar to Ezdok Camera Addon for FSX.

Continue reading [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 the forum]...

=== Usability Improvements ===

=== 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]].

=== Building from Source ===
Thanks to work done by '''Seatbutler''', the [[Howto:Build FlightGear with NetBeans using CMake]] article has recently been updated and verified to still work.

== Hardware development==
=== Project computer2cockpit ===
Following design changes suggested by FlightGear users, the [[computer2cockpit]]'s flight yoke design has been extended with:
* Map holder
* Additional rocker switch and push button switches on right side of the yoke
* Additional push to talk switch
Curent activities:
* Prototype manufacturing preparation - setting up the CNC router
* Talking with suppliers to lower the initial costs and production price

=== DIY hardware panel for FlightGear ===
At least five projects exist where FlightGear users build their own hardware panels with real switches and knobs to interface with the FlightGear software to improve the flying experience. Follow the build progress of ludomotico's and pommesschranke's panels on [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 this forum thread].

== In the hangar ==

=== New Aircraft ===
==== Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo ====
Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Junkers Ju-288A in development in MetasequoiaLE
Junkers Ju-288.jpg|Another angle of the in-development Junkers Ju-288A
</gallery>

Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" flying over Paris in a morning late fall fog.
File:Caudron Type C.JPG|Caudron Type "C" on the slopes of a Rhone Alp's meadow.
</gallery>

=== Updated aircraft ===
==== North American P-51D Mustang ====
The JSBSim [[P-51D]] is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|Screen shot of the K-14A in action showing the gyroscopic reticle rolled over pulling G. Note how the tracers are converging near the center of the gyro reticle. In addition, the fixed reticle is masked and only the center cross is visible. The fixed reticle center cross is the bore sight line.
rocketladder.png|Screen of a rocket attack on a fishing boat. The reticle being used is the fixed reticle with the 70 mil circle and the rocket ladder unmasked.
</gallery>

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Screen shot showing new droop tanks, bomb racks, propeller and part of the K-14A gun sight.
Rockets.png|The new HVAR rockets and the new rocket mounts.
</gallery>

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter December 2013

2014-01-05T03:21:27Z

Wallkon: osgEarth integration: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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 ===
{{#ev:youtube|oe0kHoEtvYA|400}}

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++ [http://osgearth.org/ 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.

=== NavDisplay Improvements ===
Gijs has started extending the [[NavDisplay]] framework to support additional display modes typically found on modern Boeing aircraft:
<gallery mode=packed widths=230px heights=230px>
Navigation display MAP mode.png|MAP mode
Navigation display centered MAP mode.png|Centered MAP mode
Navigation display PLAN mode.png|PLAN mode
</gallery>

== Wizard-based Aircraft Creation ==
[[File:Aircraft-template-wizard-intro.png|thumb|270px]]

When it comes to aircraft development, one of the areas that people find frustrating is that features used by aircraft developers will be documented in the Wiki but the examples are so minimal that it can be difficult or nearly impossible to get something working because the published examples are lacking in detail or don't show important variations of how to code the feature.

We've come to the conclusion, the best step towards fixing these issues is to have a set of templates for common aircraft configurations (single engine prop, multi-engine prop, single engine jet, multi-engine jet with co-pilot etc). These templates would have all of the minimal components to compose a "production" aircraft (according to the rating guide).

We've been tossing around that idea for a while, i.e. coming up with project-maintained "templates" for things like aircraft, to ensure that people have some way to get guidance without overly relying on extensive copy/paste programming - we really only need someone to start with a "dummy" aircraft that, with lots of comments and options (Nasal, sound, canvas, help, checklists, tutorials). In fact, it would even be possible to provide wizards to help customize such templates, i.e. to change name/author/status, 3D models, file names (sound, textures).

The idea is that we should have a set of standard aircraft templates, or some fancy means of generating an aircraft skeleton based on some user input. These templates would contain all necessary files and code to implement a simple but complete aircraft of a given configuration (single engine prop, multi-engine jet etc), and possibly stubs for common enhancements.
Standard enhancements (checklists, autopilots etc) could be included as comments indicating where code needs to be added, This would make FG aircraft more consistent, but also help newbie aircraft developers to get of the initial obstacle of understanding how it all comes together. I think this would help us overcome the issue of having so many aircraft in various pre-production states of development.

During the discussion on the forum, we came up with the ideas that we could have a template aircraft and parametrize it dynamically inside FlightGear - after all, it's 95% PropertyList-encoded XML, i.e. can be read/manipulated and written via standard FlightGear/Nasal means - in other words, you could take an existing PUI dialog and turn it into an "aircraft wizard", where the user could specify things like 1) filename, 2) description, 3) FDM type, 4) status, 5) thumbnail and so on - this is all straightforward to do, it just involves setprop() stuff after having read the template into the property tree via io.read_properties(), at which point a simple GUI dialog could be shown to streamline the aircraft development process in a step-by-step manner. Many building blocks exist already, including a file picker dialog - missing stuff can be implemented via Canvas extensions.

Such a wizard woud ideally not be implemented as a "hardcoded" XML dialog, but rather as a Nasal submodule that dynamically creates "pages" for each step in the wizard. None of this is difficult, it really just involves 1) property tree, 2) read/write properties via io.nas and 3) basic Nasal (setprop/props.nas) for modifying the template aircraft.
Such a wizard could also be easily made aware of difference between FG versions, and users could be asked to target a certain version, i.e. to omit certain stuff, like for example Canvas support, or effects etc

A first, very basic, prototype of this is now available, and waiting to be adopted by fellow contributors to help grow this "wizard", i.e. by adding features to it, but also by adding new templates to it, for different aircraft features, such as [[Aircraft Checklists]], [[Tutorials]], [[Walk View]] etc.

Given that most of us are already juggling too many projects, we're also looking for people who would possibly like to get involved in this in some way.

Coding-wise, this is currently just about 150 lines of very simple [[Nasal]] code, copied together from various other dialogs and wiki tutorials. So knowing Nasal would be a plus, but if you have any other scripting/programming experience, that will do too. So if you are interested in FlightGear scripting and simplifying aircraft deveopment for newcomers, please get in touch via the forum or the wiki.

Continue reading at [[Aircraft Generation Wizard]]...

=== Implementing VNAV -a Brainstorming ===
[[File:Route-managed-with-fgscript-support.png|thumb|270px|route manager dialog with added support for exporting to JSBSim/FGScript XML files]]
We've recently had another discussion on the forums about implementing VNAV in FlightGear. In comparison with other flight simulators, FlightGear has been lacking support for simulating VNAV features found on many modern aircraft since day one.

So far, the general consensus has been that it simply isn't yet possible in FlightGear to properly implement VNAV because VNAV depends on having access to an aircraft-specific performance database to provide the proper pitch/thrust changes to make certain VNAV altitude/speed/time constraints, which boils down to a lack of support by the FDMs (JSBsim/YaSim) actually.

As an open source project, we do not have access to the corresponding flight data or such a performance database, and even if we did, we probably couldn't easily use said data due to its proprietary nature.

In addition, a real performance database would probably not serve us too well, because our FDM configurations are custom, too - i.e. the performance database would need to match the performance of the simulated aircraft.

Thus, a performance DB would ideally be provided by the FDM itself. Either in a pre-created fashion, i.e. compiled during an offline "test flight", or preferably at runtime by running a simulation of the FDM inside the actual FDM.

We've now started gathering all information from past VNAV discussions to come up with a brainstorming and determine how to implement the building blocks required for supporting VNAV (vertical navigation) in FlightGear (YaSim/JSBSim). Any feedback is greatly appreciated.

Continue reading at [[Implementing VNAV support in FlightGear]]...

===Alternative camera control ===
{{#ev:youtube|JfHf1OG7-TQ|400}}

Fellow FlightGear user Marius_A has created a virtual camera for FligthGear that's written in [[Nasal]], it adds features similar to Ezdok Camera Addon for FSX.

Continue reading [http://forum.flightgear.org/viewtopic.php?f=6&t=21685 the forum]...

=== Usability Improvements ===

=== 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]].

=== Building from Source ===
Thanks to work done by '''Seatbutler''', the [[Howto:Build FlightGear with NetBeans using CMake]] article has recently been updated and verified to still work.

== Hardware development==
=== Project computer2cockpit ===
Following design changes suggested by FlightGear users, the [[computer2cockpit]]'s flight yoke design has been extended with:
* Map holder
* Additional rocker switch and push button switches on right side of the yoke
* Additional push to talk switch
Curent activities:
* Prototype manufacturing preparation - setting up the CNC router
* Talking with suppliers to lower the initial costs and production price

=== DIY hardware panel for FlightGear ===
At least five projects exist where FlightGear users build their own hardware panels with real switches and knobs to interface with the FlightGear software to improve the flying experience. Follow the build progress of ludomotico's and pommesschranke's panels on [http://forum.flightgear.org/viewtopic.php?f=18&t=11159 this forum thread].

== In the hangar ==

=== New Aircraft ===
==== Junkers JU-288, and Caudron Type 'C' biplane, from Lester Boffo ====
Two new aircraft from my 'Hangar', such as it is. The first one is a Junkers JU-288 Bomber-Interceptor/Bomber presented to the Luftwaffe in 1942 as a hedge against the expected US Bombing campaign and the new Boeing B29. Being as it is with all things bomber-ish in the WWII German air war, the politics of who's company got the funding, and go ahead with production, also doomed this aircraft to only a few prototypes and variants. That it relied upon the then promising Jumo 222 water-cooled inline/radial, only hastened it's demise, as the Jumo's development was rushed, and then the Jumo engine factory was destroyed by Allied bombing in 1944. Finding literature covering this aircraft was a bit hard to find, but with some help from FMG, I was able to source some drawings and spec's. I'm not sure when this plane will be finished, but the basic 3D is done and a rudimentary cockpit is in place.

<gallery mode=packed widths=270px heights=270px>
Junkers Ju-288A.jpg|Junkers Ju-288A in development in MetasequoiaLE
Junkers Ju-288.jpg|Another angle of the in-development Junkers Ju-288A
</gallery>

Secondly is a small, pre WWI early aircraft from Rene Caudron and sibling, his Type 'C' biplane. The first of his 'Public Domain' designs that he released to the early aviation community. This aircraft was to go on to more development as the G series of trainers and observation/bombers during WWI. This particular aircraft was also known as the '10 meter Caudron', it was interesting to note that it employed along with it's wing warping roll control, an enhanced roll control from the divided stab/elevator, which could be flexed with up and down, twisting deflections in addition to it's normal pitch control. It was praised for it's high rate of climb, lightness, and manoeuvrability, on a modest 45 h.p. Anzani 6 cylinder radial. The aircraft is releasable and is under a GPL license. Images of these two aircraft.

<gallery mode=packed widths=270px heights=270px>
File:Caudron Type "C".JPG|Caudron Type "C" flying over Paris in a morning late fall fog.
File:Caudron Type C.JPG|Caudron Type "C" on the slopes of a Rhone Alp's meadow.
</gallery>

=== Updated aircraft ===
==== North American P-51D Mustang ====
The JSBSim [[P-51D]] is undergoing some significant improvements. The most interesting of these is the fully functional K-14A lead computing gun sight. The screen shot below shows the gun sight in action with the aircraft rolled over and pulling about 5G. You can see that there are two reticles. The small cross in the upper center of the reflector glass is the center cross of the fixed reticle and it's sight line corresponds with where the guns would shoot in straight and level flight (IE. slightly below the bore line of the guns). The fixed reticle has been masked so that only the center cross is visible. The reticle consisting of a center dot and six surrounding diamonds is the reticle that is controlled by the gyroscope which is what gives this sight it's lead computing functionality. In the screen shot on the left, the gyro reticle is displaced a significant distance from the fixed reticle and this distance is known as the deflection. Note also that the tracers from the guns are converging near the center of the gyro reticle giving an indication of how effective the new gun sight is when doing deflection shots.

The screen shot on the right is of a ground attack mission using HVAR rockets. In this case the gyro reticle is turned off and the fixed reticle is unmasked. You can see the center cross along with the 70 mil outer circle and the so called rocket ladder in the lower center of the outer circle. This attack missed the target high and to the right mostly because I was distracted by taking the screen shot. But you can see that the flight path traced out by the rockets smoke is right where they should have been relative to the rocket ladder.

<gallery mode=packed widths=270px heights=270px>
gunsight1.png|Screen shot of the K-14A in action showing the gyroscopic reticle rolled over pulling G. Note how the tracers are converging near the center of the gyro reticle. In addition, the fixed reticle is masked and only the center cross is visible. The fixed reticle center cross is the bore sight line.
rocketladder.png|Screen of a rocket attack on a fishing boat. The reticle being used is the fixed reticle with the 70 mil circle and the rocket ladder unmasked.
</gallery>

The following screen shot on the left is a ground view of the aircraft with the new drop tanks, bomb racks and propeller. In addition you can see the back of the gun sight in the cockpit. The pink area on the back of the gun sight is the silica gel pack that keeps the internals of the gun sight dry.

<gallery mode=packed widths=270px heights=270px>
tanks&prop.png|Screen shot showing new droop tanks, bomb racks, propeller and part of the K-14A gun sight.
Rockets.png|The new HVAR rockets and the new rocket mounts.
</gallery>

The bomb ranks and rocket wing mounts were modeled using the factory blue prints and are accurate to within perhaps 0.1mm. The propeller and drop tanks were modeled based on published measurements and have similar levels of accuracy. The gun sight 3D models are based on drawings and dimensions from the USAAF K-14A maintenance manual.

There are other improvements to the FDM and other areas that have been pushed to fgdata. To try out the new features you will need the Aircraft/p51d and Aircraft/Instruments-3d/computing-gun-sights directories. I tested these updates with FG 2.12.1 but it should be OK with any version from 2.4 on.

fgdata also has the new check list functionality that was setup by Stuart Buchanan. I made some additions to the check lists to reflect changes in the FDM that affected the start up procedure. From that experience I know that Stuart spent a significant amount of time getting this in place. Thank you Stuart.

The plan going forward is to continue to improve the external 3D model based on the factory blue prints. So over the next few months you can expect to see things get even better.

Please feel free to give this a try and provide constructive feedback on the FlightGear forum.

== Wiki updates ==
=== Major changes in the wiki help pages ===
During November and December many of the help pages have been moved around and extended, and a few new help pages have been created, [http://wiki.flightgear.org/index.php?title=Help:Tables&oldid=64764 Help:Tables] and [http://wiki.flightgear.org/index.php?title=Help:Glossary&oldid=65365 Help:Glossary].

These changes were made to improve the help mostly for entirely new users, but will probably also be helpful some of the regular editors as well. The rewritten pages now also have links to more advanced help primarily at the [http://www.mediawiki.org/wiki/MediaWiki MediaWiki Wiki], the wiki of the developers of the the wiki software used by the FlightGear Wiki.

In summary, the following changes have been made:
{|
|
* [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=62127 Help:Template]
| → [http://wiki.flightgear.org/index.php?title=Help:Templates&oldid=64726 Help:Templates] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=42573 Help:Tutorial]
| → [http://wiki.flightgear.org/index.php?title=Help:Formatting&oldid=65375 Help:Formatting] || – Rewritten and extended
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=51862 Help:Your first article]
| → [http://wiki.flightgear.org/index.php?title=Help:Tutorial&oldid=65432 Help:Tutorial] ||
|-
|
* [http://wiki.flightgear.org/index.php?title=Help:Your_first_article&oldid=65439 Help:Your first article]
| || – Rewritten and extended
|}

The work is not complete yet though. Most of all the ''translations'' of these pages needs to be moved and/or translated, and a couple of pages, [[Help:Categories]] and [[Help:Tutorial]], could still need a rewrite (though on a ''much'' smaller scale).

And finally, a ''style guide'' (as in a guide, not a manual) is something there is a growing need for. Any suggestions and opinions are welcome at [[Help talk:Style guide]], as well as additions to [[Help:Style guide]], which is currently (very) incomplete.

=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten, for a more detailed article see [[How the FlightGear project works]].

=== YASim looking for a new maintainer ===
{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}

{{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}

<references/>

[[Category:FlightGear Newsletter|2013 12]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter

2013-12-02T22:16:43Z

Wallkon: Agregado noviembre de 2013

[[File:magagazine.png|right]]
'''El Boletín de Noticias de FlightGear''' está destinado a proporcionar una colección de las últimas novedades de la comunidad mundial [[FlightGear]]. Con tantísimo desarrollo continuo, es casi imposible que alguien pueda mantenerse al día. El boletín se inició en Julio de 2009 y se presenta sobre una base mensual.

All editions are initialy written in English, this page only lists translated editions. For a complete overview, see [[FlightGear Newsletter]].

=== Archive ===
{| class="vatop" valign="top"
! align="left" | 2009
! align="left" | 2010
! align="left" | 2011
! align="left" | 2012
! align="left" | 2013
|-
|valign="bottom"|
* [[FlightGear Newsletter July 2009|Julio]]
* [[FlightGear Newsletter August 2009|Agosto]]
* [[FlightGear Newsletter September 2009|Septiembre]]
* [[FlightGear Newsletter October 2009|Octubre]]
* [[FlightGear Newsletter November 2009|Noviembre]]
* [[FlightGear Newsletter December 2009|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2010|Enero]]
* [[:es:FlightGear Newsletter February 2010|Febrero]]
* [[:es:FlightGear Newsletter March 2010|Marzo]]
* [[:es:FlightGear Newsletter April 2010|Abril]]
* [[:es:FlightGear Newsletter May 2010|Mayo]]
* [[:es:FlightGear Newsletter June 2010|Junio]]
* [[:es:FlightGear Newsletter July 2010|Julio]]
* [[:es:FlightGear Newsletter August 2010|Agosto]]
* [[:es:FlightGear Newsletter September 2010|Septiembre]]
* [[:es:FlightGear Newsletter October 2010|Octubre]]
* [[:es:FlightGear Newsletter November 2010|Noviembre]]
* [[:es:FlightGear Newsletter December 2010|Diciembre]]
|valign="top"|
* [[:es:FlightGear Newsletter January 2011|Enero]]
* [[:es:FlightGear Newsletter February 2011|Febrero]]
* [[:es:FlightGear Newsletter March 2011|Marzo]]
* [[:es:FlightGear Newsletter April 2011|Abril]]
* [[:es:FlightGear Newsletter May 2011|Mayo]]
* [[:es:FlightGear Newsletter June 2011|Junio]]
* [[:es:FlightGear Newsletter July 2011|Julio]]
* [[:es:FlightGear Newsletter August 2011|Agosto]]
* [[:es:FlightGear Newsletter September 2011|Septiembre]]
* [[:es:FlightGear Newsletter October 2011|Octubre]]
* [[FlightGear Newsletter November 2011|Noviembre]] **
* [[FlightGear Newsletter December 2011|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2012|Enero]] **
* [[FlightGear Newsletter February 2012|Febrero]] **
* [[FlightGear Newsletter March 2012|Marzo]] **
* [[FlightGear Newsletter April 2012|Abril]] **
* [[FlightGear Newsletter May 2012|Mayo]] **
* [[FlightGear Newsletter June 2012|Junio]] **
* [[FlightGear Newsletter July 2012|Julio]] **
* [[FlightGear Newsletter August 2012|Agosto]] **
* [[FlightGear Newsletter September 2012|Septiembre]] **
* [[FlightGear Newsletter October 2012|Octubre]] **
* [[FlightGear Newsletter November 2012|Noviembre]] **
* [[FlightGear Newsletter December 2012|Diciembre]] **
|valign="top"|
* [[FlightGear Newsletter January 2013|Enero]] **
* [[FlightGear Newsletter February 2013|Febrero]] **
* [[FlightGear Newsletter March 2013|Marzo]] **
* [[FlightGear Newsletter April 2013|Abril]] **
* [[FlightGear Newsletter May 2013|Mayo]] **
* [[FlightGear Newsletter June 2013|Junio]] **
* [[FlightGear Newsletter July 2013|Julio]] **
* [[:es:FlightGear Newsletter August 2013|Agosto]]
* [[:es:FlightGear Newsletter September 2013|Septiembre]]
* [[:es:FlightGear Newsletter October 2013|Octubre]]
* [[:es:FlightGear Newsletter November 2013|Noviembre]]
|}

; ** Las ultimas ediciones no están traducidas aun.

=== Estás invitado a contribuir! ===
Nos gustaría destacar que el boletín mensual no puede vivir sin las contribuciones de los usuarios y desarrolladores de FlightGear. El boletín FlightGear es un boletín informativo impulsado por la comunidad, lo que significa que es creado y editado por personas como **tu** No es necesario ser un usuario de FlightGear desde hace mucho tiempo (o incluso desarrollador) para contribuir con el boletin de noticias.

De hecho, ayudar a escribir el boletín mensual de FlightGear es una manera excelente de empezar a contribuir con la comunidad FlightGear rápida y muy fácilmente.

Incluso si no tienes algo tuyo que añadir, son tambien muy apreciadas las revisiónes y mejoras de las aportaciones de otros, al igual que los esfuerzos para ayudar a traducir los boletines o incorporar imágenes de pantalla al boletín de noticias (por ejemplo, tomadas del foro o las listas de correo). Las capturas de pantalla se pueden cargar en [[Special:Upload]]

Todo el mundo con una cuenta wiki ([[Special:UserLogin|libre de registro]]) puede editar el boletín de noticias y toda contribución es bienvenida. Así que si sabes de algún proyecto relacionado con FlightGear, como por ejemplo un escenario actualizado o una aeronave, por favor, sientete invitado a añadir este tipo de noticias en el boletín.

Si necesitas ayuda usando el wiki, por favor no dudes en ponerte en contacto con nosotros a través de [http://forum.flightgear.org/viewforum.php?f=50 la sección del foro].

Se puede tomar y usar una plantilla simple que proporciona una estructura básica para el [[Talk:Next newsletter|próximo boletín]] Esta plantilla se puede copiar/pegar en cada nuevo boletín para ayudar a los usuarios a empezar a ofrecer contenidos.

El borrador para el próximo boletín siempre se puede encontrar en el [[Next newsletter|próximo boletín]].

Si el Inglés no es tu lengua materna, por favor, que no te preocupe ayudar en el boletín de noticias, siempre puedes fácilmente pedir a otros usuarios de FlightGear que revisen o corrijan tus cambios. Además, una de las maneras más fáciles de empezar es simplemente copiar/pegar texto del foro o de los debates en las listas de correo, tales como anuncios (nuevos aviones, nuevos escenarios, etc).

Otra opción clara para empezar es la aportación de enlaces a videos de YouTube relacionados con FlightGear. Para ello, tenemos una sección dedicada en cada boletín de noticias - mira en: "FlightGear en YouTube": [[Next newsletter#Community news]]

Para incrustar vídeos de YouTube directamente, sólo tienes que utilizar la siguiente sintaxis:
<nowiki>{{#ev:youtube|VBWZ6JZe_Mw|400| vídeo en invierno de planetacancun2 que muestra la nieve en FlightGear.}}</nowiki>

Si estás buscando otras maneras de participar, por favor mira en [[Es/Voluntarios|voluntarios]].

[[Category:FlightGear Newsletter]]
[[Category:Community]]
[[Category:List]]

[[en:FlightGear Newsletter]]
[[fr:FlightGear Newsletter]]

Talk:Es/FlightGear Newsletter November 2013

2013-12-02T22:13:12Z

Wallkon: Partes cuya exactitud de la traducción deben ser revisados

Hubieron partes muy complicadas de traducir, si deseas puedes revisar las siguientes partes en las cuales no estuve seguro de estar traduciendo correctamente (en el menú de la izquierda tienes acceso a la versión en inglés):

* '''The Atmospheric Light Scattering rendering framework adopts a technique that has recently been introduced for the default and the Rembrandt rendering framework which allows to utilize a global map of Ocean water depth. This allows to render the shallow waters around islands in a compelling way. Combined with the ability of ALS to change the basic water color based on location and weather conditions/sky appearance, many combination of shallows, mud content and weather conditions can now be addressed by the highest detail water shader effect:'''
¿ 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 de tiempo/apariencia del cielo, combinaciones de aguas poco profundas, contenido de lodo y condiciones de tiempo ahora pueden ser logradas mediante un mayor detalle del efecto de sombreado del agua. ?

* '''charting displays:''' ¿pantalla de cartas?

* '''for all charting needs in FlightGear:''' ¿para todas las necesidades gráficas de FlightGear?

* '''its overhead is fairly small:''' ¿su gasto es bastante pequeño?

* '''There’s more to this, though, as this is one of the more capable, but complex, components in the set of JSBSim control system components.:''' ¿Este es uno de los más potentes, pero complejos, componentes en el conjunto de componentes de control de JSBSim.? (Creo que acá hay un error en la redacción del inglés)

* '''have its property values set as stated:''' ¿los valores de sus propiedades son según se estableció?

* '''Nasal Internals for hackers: Intern'ing symbols:''' ¿Internals de Nasal para hackers: internando símbolos?

* '''the equals() method that checks for more general key equality:''' ¿el método equals() que comprueba una llave de igualdad más general?

* '''it runs through a hashcode's potential slots:''' ¿este corre a través de slots del hashcode?

* '''The one set first is the one being picked up (e.g. the arg in {arg:nil} versus the arg... that equals []:''' ¿El primer set es el que está siendo recogido (por ejemplo, el arg en {arg:nil} versus el arg... que iguala [])?

* '''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.:''' ¿Creo que una vez conté más de cien símbolos "arg" in the namespace __js0 desde el contínuo lanzamiento de vínculos, lo cual obviamente no es bueno.?

* '''glass reflection on windows and front shield and variable rotor wakes depending on the strength of the downwash.:''' ¿reflejos en las ventanas y parabrisas frontal, y el rotor variable dependen de la fuerza de la corriente descendente.?

De todas formas pueden haber más partes con errores de traducción. Siéntete libre de realizar las correcciones que sean necesarias.

Es/FlightGear Newsletter November 2013

2013-12-02T22:04:54Z

Wallkon: Últimos cambios

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

Esto mostraría:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== Addons y mods para FlightGear ==
=== Nuevas texturas y luces para edificios aleatorios ===
[[File:Lightmap terrain at noon.png|thumb|220px|Luces del terreno al mediodía]]
[[File:Lightmap terrain at night.png|thumb|220px|Luces del terreno en la noche]]
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 [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip 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 [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip este paquete] y sigue las instrucciones de instalación nuevamente.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== En el hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|El "whistle" tomando velocidad para despegar.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|Puedes escoger uno de tres radomos.]]
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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip desde acá]. Esta aeronave YASim tiene un muy buen [[:es:FDM|FDM]], bello exterior y una carlinga básica. Para aportar (a mejorar la carlinga, por ejemplo) contactanos en el [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 foro].

{{#ev:youtube|IbUMgRvEih0}}

Muchas gracias a Helijah, Buckaroo y Cossack90.

=== Nueva aeronave ===
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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 el foro].

=== Aeronave actualizada ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|La variante EMS del EC130-B4, usado por MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|Nueva librea de Helicópteros Gran Cañón]]
[[File:EC130 Mainrotor front.png|thumb|Primer plano del rotor del EC130 , completamente animado en todos los detalles]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 usando el reflector SX-16 Nightsun]]
[[File:EC130 Pilot window.jpg|thumb|Ahora, incluso la ventana del piloto puede ser abierta]]

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, '''[https://gitorious.org/ec130/ dale un vistazo al Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|Un primer plano del Fenestron completamente detallado
File:EC130 snowshoes hook.jpg|EC130 equipado con patines para nieve y gancho
File:EC130 cabin seats.jpg|EC130 Cabina y controles del piloto del Grand Canyon Helicopters
File:EC130 stretcher.png|EC130 Configuración de cabina EMS con camilla
File:EC130 luggage door back.jpg|EC130 puerta de equipaje
File:EC130 pilot.jpg|EC130 controles del piloto
</gallery>

'''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:'''
<gallery>
File:EC130 Config.jpg|EC130 Ventana de configuración completamente integrada.
File:EC130 Help.jpg|EC130 Ventana de ayuda con todos los atajos e información adicional
File:EC130 Config Help 2.jpg|EC130 Configuración de la ayuda con explicación de dependencias
File:EC130 Options.jpg|EC130 Opciones de simulación
</gallery>

'''Mejoras para FG 3.0:'''
* Soporte para Rembrandt
* Corrección de errores

== Actualizaciones de la wiki ==
=== Se necesitan traductores ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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: [[:es:Voluntarios|Voluntarios]].

Para aprender más acerca de cómo trabaja el proyecto, por favor revisa [http://forum.flightgear.org/viewtopic.php?f=42&t=15267#p149971 este breve ensayo] escrito por Thorsten, y para un artículo más detallado revisa [[How the FlightGear project works|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.

[[en:FlightGear Newsletter November 2013]]
[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T12:42:24Z

Wallkon: Eurocopter EC130-B4 Ecostar: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

Esto mostraría:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== Addons y mods para FlightGear ==
=== Nuevas texturas y luces para edificios aleatorios ===
[[File:Lightmap terrain at noon.png|thumb|220px|Luces del terreno al mediodía]]
[[File:Lightmap terrain at night.png|thumb|220px|Luces del terreno en la noche]]
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 [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# 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 [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip este paquete] y sigue las instrucciones de instalación nuevamente.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== En el hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|El "whistle" tomando velocidad para despegar.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|Puedes escoger uno de tres radomos.]]
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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip desde acá]. Esta aeronave YASim tiene un muy buen [[:es:FDM|FDM]], bello exterior y una carlinga básica. Para aportar (a mejorar la carlinga, por ejemplo) contactanos en el [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 foro].

{{#ev:youtube|IbUMgRvEih0}}

Muchas gracias a Helijah, Buckaroo y Cossack90.

=== Nueva aeronave ===
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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 el foro].

=== Aeronave actualizada ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|La variante EMS del EC130-B4, usado por MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|Nueva librea de Helicópteros Gran Cañón]]
[[File:EC130 Mainrotor front.png|thumb|Primer plano del rotor del EC130 , completamente animado en todos los detalles]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 usando el reflector SX-16 Nightsun]]
[[File:EC130 Pilot window.jpg|thumb|Ahora, incluso la ventana del piloto puede ser abierta]]

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, '''[https://gitorious.org/ec130/ dale un vistazo al Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|Un primer plano del Fenestron completamente detallado
File:EC130 snowshoes hook.jpg|EC130 equipado con patines para nieve y gancho
File:EC130 cabin seats.jpg|EC130 Cabina y controles del piloto del Grand Canyon Helicopters
File:EC130 stretcher.png|EC130 Configuración de cabina EMS con camilla
File:EC130 luggage door back.jpg|EC130 puerta de equipaje
File:EC130 pilot.jpg|EC130 controles del piloto
</gallery>

'''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:'''
<gallery>
File:EC130 Config.jpg|EC130 Ventana de configuración completamente integrada.
File:EC130 Help.jpg|EC130 Ventana de ayuda con todos los atajos e información adicional
File:EC130 Config Help 2.jpg|EC130 Configuración de la ayuda con explicación de dependencias
File:EC130 Options.jpg|EC130 Opciones de simulación
</gallery>

'''Mejoras para FG 3.0:'''
* Soporte para Rembrandt
* Corrección de errores

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T11:26:32Z

Wallkon: Eliminada la parte en inglés de la última modificación

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

Esto mostraría:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== Addons y mods para FlightGear ==
=== Nuevas texturas y luces para edificios aleatorios ===
[[File:Lightmap terrain at noon.png|thumb|220px|Luces del terreno al mediodía]]
[[File:Lightmap terrain at night.png|thumb|220px|Luces del terreno en la noche]]
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 [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# 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 [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip este paquete] y sigue las instrucciones de instalación nuevamente.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== En el hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|El "whistle" tomando velocidad para despegar.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|Puedes escoger uno de tres radomos.]]
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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip desde acá]. Esta aeronave YASim tiene un muy buen [[:es:FDM|FDM]], bello exterior y una carlinga básica. Para aportar (a mejorar la carlinga, por ejemplo) contactanos en el [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 foro].

{{#ev:youtube|IbUMgRvEih0}}

Muchas gracias a Helijah, Buckaroo y Cossack90.

=== Nueva aeronave ===
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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 el foro].

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T11:24:56Z

Wallkon: New aircraft: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

Esto mostraría:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== Addons y mods para FlightGear ==
=== Nuevas texturas y luces para edificios aleatorios ===
[[File:Lightmap terrain at noon.png|thumb|220px|Luces del terreno al mediodía]]
[[File:Lightmap terrain at night.png|thumb|220px|Luces del terreno en la noche]]
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 [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# 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 [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip este paquete] y sigue las instrucciones de instalación nuevamente.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== En el hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|El "whistle" tomando velocidad para despegar.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|Puedes escoger uno de tres radomos.]]
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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip desde acá]. Esta aeronave YASim tiene un muy buen [[:es:FDM|FDM]], bello exterior y una carlinga básica. Para aportar (a mejorar la carlinga, por ejemplo) contactanos en el [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 foro].

{{#ev:youtube|IbUMgRvEih0}}

Muchas gracias a Helijah, Buckaroo y Cossack90.

=== Nueva aeronave ===
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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 el foro].

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T11:07:49Z

Wallkon: Tupolev Tu-134: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

Esto mostraría:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== Addons y mods para FlightGear ==
=== Nuevas texturas y luces para edificios aleatorios ===
[[File:Lightmap terrain at noon.png|thumb|220px|Luces del terreno al mediodía]]
[[File:Lightmap terrain at night.png|thumb|220px|Luces del terreno en la noche]]
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 [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# 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 [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip este paquete] y sigue las instrucciones de instalación nuevamente.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== En el hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|El "whistle" tomando velocidad para despegar.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|Puedes escoger uno de tres radomos.]]
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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip desde acá]. Esta aeronave YASim tiene un muy buen [[:es:FDM|FDM]], bello exterior y una carlinga básica. Para aportar (a mejorar la carlinga, por ejemplo) contactanos en el [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 foro].

{{#ev:youtube|IbUMgRvEih0}}

Muchas gracias a Helijah, Buckaroo y 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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T10:48:54Z

Wallkon: New textures and lightmaps for random buildings: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

Esto mostraría:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== Addons y mods para FlightGear ==
=== Nuevas texturas y luces para edificios aleatorios ===
[[File:Lightmap terrain at noon.png|thumb|220px|Luces del terreno al mediodía]]
[[File:Lightmap terrain at night.png|thumb|220px|Luces del terreno en la noche]]
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 [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# 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 [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip este paquete] y sigue las instrucciones de instalación nuevamente.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== In the hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip 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 [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 forum]

{{#ev:youtube|IbUMgRvEih0}}

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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T09:57:05Z

Wallkon: Nasal Internals for hackers: Intern'ing symbols: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

Esto mostraría:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== FlightGear addons and mods ==
=== New textures and lightmaps for random buildings ===
[[File:Lightmap terrain at noon.png|thumb|220px|Lightmap terrain at noon]]
[[File:Lightmap terrain at night.png|thumb|220px|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:
# Download from [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# Unzip the file
# 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/
# I suggest to change the random building density to the middle of your computer default settings, you can make this by edit at [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip this package] and follow the installation instructions again.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== In the hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip 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 [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 forum]

{{#ev:youtube|IbUMgRvEih0}}

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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T07:38:50Z

Wallkon: Getting involved as a programmer: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|Poses de manos que serán seleccionables en la ventana de animación]]

=== 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 [[Howto:Start core development|Comenzar como desarrollador del núcleo]].

== 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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

This should print:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== FlightGear addons and mods ==
=== New textures and lightmaps for random buildings ===
[[File:Lightmap terrain at noon.png|thumb|220px|Lightmap terrain at noon]]
[[File:Lightmap terrain at night.png|thumb|220px|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:
# Download from [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# Unzip the file
# 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/
# I suggest to change the random building density to the middle of your computer default settings, you can make this by edit at [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip this package] and follow the installation instructions again.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== In the hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip 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 [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 forum]

{{#ev:youtube|IbUMgRvEih0}}

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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T07:34:18Z

Wallkon: The Walker: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

[[File:Walker Waldo.png|400px|La transeúnte femenina]] [[File:Walker Amelie.png|400px|El transeúnte masculino]]

[[File:Walker pilot model.png|400px|Un modelo de piloto, copiloto y tripulación están por llegar.]] [[File:Walker hand poses.png|x211px|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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

This should print:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== FlightGear addons and mods ==
=== New textures and lightmaps for random buildings ===
[[File:Lightmap terrain at noon.png|thumb|220px|Lightmap terrain at noon]]
[[File:Lightmap terrain at night.png|thumb|220px|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:
# Download from [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# Unzip the file
# 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/
# I suggest to change the random building density to the middle of your computer default settings, you can make this by edit at [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip this package] and follow the installation instructions again.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== In the hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip 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 [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 forum]

{{#ev:youtube|IbUMgRvEih0}}

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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T07:20:54Z

Wallkon: FGRun repository changes: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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 [http://gitorious.org/fg/fgrun repositorio Git FGRun] ahora usa el mismo concepto de branch que en FlightGear y SimGear. El desarrollo actual toma lugar en la rama <code>next</code>, mientras que las ramas <code>release/X.X</code> 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.

=== The Walker ===
The Walker is currently made portable to be easily incorporated in arbitrary aircraft. Additionally, an animatable pilot model for cockpit placement is in development. Walker and crew will be supporting different hand poses, such as pointing, a fist, thumbsup or a victory sign.

[[File:Walker Waldo.png|400px|The male Walker]] [[File:Walker Amelie.png|400px|The female Walker]]

[[File:Walker pilot model.png|400px|A pilot model, co-pilot and crew are to come.]] [[File:Walker hand poses.png|x211px|Hand Poses that will be selectable within the animation dialog]]

=== 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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

This should print:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== FlightGear addons and mods ==
=== New textures and lightmaps for random buildings ===
[[File:Lightmap terrain at noon.png|thumb|220px|Lightmap terrain at noon]]
[[File:Lightmap terrain at night.png|thumb|220px|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:
# Download from [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# Unzip the file
# 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/
# I suggest to change the random building density to the middle of your computer default settings, you can make this by edit at [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip this package] and follow the installation instructions again.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== In the hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip 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 [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 forum]

{{#ev:youtube|IbUMgRvEih0}}

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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]

Es/FlightGear Newsletter November 2013

2013-12-02T07:10:45Z

Wallkon: New Control System Component in JSBSim: traducido

{{newsletter}}
{{TOC_right|limit=2}}

''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.

[[File:Depth01.jpg|400px|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.

{{#ev:youtube|0aUZTvpdLFU|400}} {{#ev:youtube|dZ5JuQ9ZDEQ|400}}

Aprende más en [http://forum.flightgear.org/viewtopic.php?f=6&t=21351 el tema del foro].

=== Presentamos dos nuevos frameworks: NavDisplay (ND) y MapStructure ===
[[File:MapStructureDialog.png|thumb|Demo de MapStructure]]
[[File:NavDisplay.png|thumb|NavDisplay]]
[[File:Hyde-777-200ER-independent-NDs.png|thumb|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 [[:es:FlightGear Newsletter October 2013#Actualización de aeronaves|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:
<syntaxhighlight lang="xml">
<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>

... 

</distributor>
</syntaxhighlight>
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:
<syntaxhighlight lang="xml">
<?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>
</syntaxhighlight>
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.

=== FGRun repository changes ===
The [http://gitorious.org/fg/fgrun FGRun Git repository] now uses the same branch concept as FlightGear and SimGear. Current development takes place in the <code>next</code> branch, while <code>release/X.X</code> branches are created for each release. In addition to that the FGRun version number is now in sync with FlightGear/SimGear, to make it easier to see whether your FGRun and FlightGear builds match.

=== The Walker ===
The Walker is currently made portable to be easily incorporated in arbitrary aircraft. Additionally, an animatable pilot model for cockpit placement is in development. Walker and crew will be supporting different hand poses, such as pointing, a fist, thumbsup or a victory sign.

[[File:Walker Waldo.png|400px|The male Walker]] [[File:Walker Amelie.png|400px|The female Walker]]

[[File:Walker pilot model.png|400px|A pilot model, co-pilot and crew are to come.]] [[File:Walker hand poses.png|x211px|Hand Poses that will be selectable within the animation dialog]]

=== 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:

<syntaxhighlight lang="nasal">
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=[]
</syntaxhighlight>

This should print:
<pre>
arg
arg
nil
</pre>

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 [http://forum.flightgear.org/viewtopic.php?f=30&t=21308&p=193935#p193935].

== FlightGear addons and mods ==
=== New textures and lightmaps for random buildings ===
[[File:Lightmap terrain at noon.png|thumb|220px|Lightmap terrain at noon]]
[[File:Lightmap terrain at night.png|thumb|220px|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:
# Download from [https://www.dropbox.com/s/r3o06xtxn9gp27m/New_Urban_effects.zip here]
# Unzip the file
# 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/
# I suggest to change the random building density to the middle of your computer default settings, you can make this by edit at [[FlightGear configuration via XML|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 [https://www.dropbox.com/s/75jodt5psqc5yzl/Default_eff.zip this package] and follow the installation instructions again.

<gallery>
File:Lightmap terrain at dusk.png
File:Large building lights.png
File:City at night.png
File:Reflection map at dusk.png
File:Reflection map at night.png
</gallery>

== In the hangar ==
==== Tupolev Tu-134 ====
[[File:Tu134_aeroflot.png|thumb|270px|The "whistle" taking speed for take-off.]]
[[File:Tu-134 liveries nose.gif|thumb|270px|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 [https://www.dropbox.com/s/kskswdwm0ue3xj1/Tu-134.zip 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 [http://forum.flightgear.org/viewtopic.php?f=4&t=15908 forum]

{{#ev:youtube|IbUMgRvEih0}}

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 [http://forum.flightgear.org/viewtopic.php?f=4&t=21277 the forum topic]

=== Updated aircraft ===
==== Eurocopter EC130-B4 Ecostar ====
[[File:EC130 MedFlight N130NE.jpg|thumb|The EMS variant of EC130-B4, used by MedFlight, Ohio, USA]]
[[File:EC130 Grand Canyon Helicopters.jpg|thumb|New Livery of Grand Canyon Helicopters]]
[[File:EC130 Mainrotor front.png|thumb|Closeup of EC130 Mainrotor, fully animated in all details]]
[[File:EC130-B4 MedFlight using SX-16 Nightsun.jpg|thumb|EC130 Helicopter using the SX-16 Nightsun searchlight]]
[[File:EC130 Pilot window.jpg|thumb|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 '''[https://gitorious.org/ec130/ check it out from the Git-Hangar]'''

<gallery>
File:EC130 Fenestron.jpg|A closeup of the full detailed fenestron
File:EC130 snowshoes hook.jpg|EC130 fitted with snowshoes and hook
File:EC130 cabin seats.jpg|EC130 Grand Canyon Helicopters cabin and pilots' controls
File:EC130 stretcher.png|EC130 cabin configuration (EMS) with stretcher
File:EC130 luggage door back.jpg|EC130 luggage door
File:EC130 pilot.jpg|EC130 pilot controls
</gallery>

'''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:'''

<gallery>
File:EC130 Config.jpg|EC130 fully integrated configuration dialog
File:EC130 Help.jpg|EC130 Help screen with all shortcuts and additional info
File:EC130 Config Help 2.jpg|EC130 Config Help with explanation of dependencies
File:EC130 Options.jpg|EC130 Simulation Options
</gallery>

'''Things on stack for FG 3.0:'''
* Rembrandt support
* BUG fixing

== Wiki updates ==
=== Translators required ===
{|
|[[File: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]].
|-
|[[File: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 [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
|[[File: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 [[:nl:Help:Vertalen|Help:Vertalen]].
|-
|[[File: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 [[:es:Help:Traducir|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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 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

[[Category:FlightGear Newsletter|2013 11]]
[[Category:Changes after 2.12]]