Handler (Gestores)

Getting your Trinity Audio player ready...

Tiempo de lectura: 9 minutos

GSX está a punto de cobrar mucha más vida.

La mayoría de vosotros conocéis GSX como la herramienta que aporta un manejo realista en tierra a vuestros vuelos. Habéis visto los camiones de combustible, las pasarelas de embarque conectadas, los carros de equipaje rodando. Muchos de vosotros ya habéis creado perfiles de aeropuertos, y eso es fantástico. Pero hay una nueva capa que va a cambiar la sensación que transmite GSX, y queremos explicarla en términos sencillos.

¿Qué es un «handler»?

Cada avión compatible con GSX tiene un cerebro oculto llamado «handler». Es algo que hasta hoy ha sido inaccesible para los usuarios finales, es el escurridizo «perfil interno», que a veces hace un gran trabajo para adaptarse a algunos aviones, como el funcionamiento automático del FMC en los aviones PMDG: lo realiza el handler interno de GSX.

En casos más sencillos, el controlador solo establece algunos ajustes que hacen que el avión funcione mejor, como la posición de «saludo» de la tripulación al final del retroceso, un punto de vista personalizado (algunos aviones lo tienen mal), la cantidad de inclinación hacia arriba cuando el avión es elevado por un remolcador sin barra de remolque, un montón de pequeñas cosas que antes no se podían personalizar con los ajustes normales.

Ahora, por primera vez, puedes escribir tus propios scripts de controlador, pequeños archivos Python que amplían o modifican este comportamiento, sin tocar el propio GSX. Solo escribes lo que quieres cambiar. Todo lo demás sigue funcionando como antes.

¿Qué es un «handler de aeropuerto»?

Piénsalo de esta manera: los controladores de aeronaves responden a la pregunta «¿cómo se comunica GSX con este avión?», mientras que los controladores de aeropuerto responden a la pregunta «¿cómo deben funcionar las operaciones en ESTE aeropuerto?».

Un perfil de aeropuerto (el archivo .ini que ya conoces) es estático: almacena posiciones fijas de puertas y puntos de vehículos. Un controlador de aeropuerto es un código vivo que reacciona a lo que está sucediendo realmente: qué aerolínea acaba de aterrizar, cuántos pasajeros hay a bordo, qué hora es, si está lloviendo. Es la diferencia entre un fondo pintado y un coordinador de operaciones real.

¿Y lo mejor? Los controladores de aeropuerto se integran directamente con los perfiles de aeropuerto que ya crean los creadores de la comunidad. Cada perfil puede tener su propio controlador. La barrera de entrada es baja: no es necesario escribir un controlador para publicar un buen perfil, pero si quieres profundizar, las herramientas están ahí.

¿Cómo podría ser esto en la práctica? Algunos ejemplos reales:

Toques de queda nocturnos en aeropuertos sensibles al ruido. Imagina que vuelas a Múnich (EDDM) a las 23:30. Un handler para ese aeropuerto conoce la hora local y obliga automáticamente a todos los pasajeros a desplazarse en autobús, sin caminar por la pista. No se despliegan las escaleras. Aparece un mensaje: «Operaciones nocturnas activas: pista restringida». Igual que en la vida real.

Rampas que reaccionan al clima ¿Aterrizando en Ámsterdam Schiphol (EHAM) en medio de una tormenta? El encargado del aeropuerto lee el estado de precipitación del simulador y cambia todo el embarque a pasarela o autobús cubierto, sin escaleras al aire libre bajo la lluvia torrencial holandesa. Vuelve el buen tiempo y las operaciones normales se reanudan automáticamente.

Normas de las aerolíneas de bajo coste en un concurrido centro europeo ¿Vuela con Ryanair a Londres Stansted (EGSS)? El operador lee el código de la aerolínea en su plan SimBrief, ve que se trata de una aerolínea de bajo coste e inmediatamente configura la puerta de embarque solo con escaleras, sin pasarela, porque así es exactamente como Stansted gestiona las operaciones de las aerolíneas de bajo coste. Una aerolínea tradicional en la misma plataforma dispone de pasarela.

Repostaje subterráneo donde realmente existe En la terminal 1 de Fráncfort (EDDF), las puertas internacionales para aviones de fuselaje ancho cuentan con repostado subterráneo, sin necesidad de que un camión se acerque al ala. Un operador del aeropuerto puede comprobar la envergadura del avión y el tipo de destino (nacional o internacional) y activar automáticamente el sistema subterráneo para los vuelos adecuados, mientras que los aviones regionales reciben el camión de combustible como de costumbre.

Aeropuertos de gran altitud con normas especiales de retroceso ¿Vuela a Innsbruck (LOWI)? Las plataformas remotas de montaña no disponen de remolcadores sin barra de remolque: un operario puede detectar el tipo de puerta y forzar el retroceso con barra de remolque y, a continuación, pedir opcionalmente al piloto que lo confirme antes de que nada se mueva.

La legendaria precisión del personal de tierra de Japón En Tokio Haneda (RJTT), un operario podría detectar que se trata de un vuelo nacional de ANA o JAL y aumentar automáticamente la densidad de pasajeros, acortar el tiempo de embarque y mostrar una secuencia estructurada de mensajes de servicio sincronizados como en una vuelta real de JAL: primero la tripulación, luego los pasajeros y, por último, el equipaje, todo ello en un intervalo de tiempo muy reducido. La pantalla VGDS de la puerta de embarque podría mostrar su squawk y su destino si vuela con VATSIM.

Preguntar al piloto antes de comenzar los servicios Algunas aeronaves, como el PMDG 737, tienen una escalera ventral incorporada. En una puerta que tiene una pasarela, un asistente puede mostrar un menú antes de tomar cualquier decisión sobre el vehículo: «¿Desea utilizar las escaleras de la aeronave o la pasarela?». Si elige las escaleras, la pasarela se suprime y la animación incorporada toma el control. Si viaja en una aerolínea de bajo coste, eso es exactamente lo que ocurriría en la vida real.

¿Por qué es esto importante para los creadores de perfiles de aeropuertos?

En este momento, la comunidad de perfiles de aeropuertos es enorme y sigue creciendo. Cientos de aeropuertos han sido cuidadosamente configurados por simuladores dedicados. Pero los perfiles siempre han sido estáticos: la misma experiencia cada vez, independientemente de la aeronave, la aerolínea, la hora del día o el clima.

Los controladores de aeropuertos cambian eso. Un creador de perfiles que escribe un pequeño controlador junto con su archivo .ini ahora puede hacer que su aeropuerto responda al mundo que lo rodea. Y no tiene por qué ser complejo: incluso un simple script que muestre un mensaje de bienvenida personalizado o que permita el reabastecimiento subterráneo en puertas específicas hace que un perfil se sienta mucho más pulido y real.

Incluso hay un editor de scripts integrado en el simulador, con resaltado de sintaxis, una consola Python interactiva y la posibilidad de aplicar los cambios con un solo botón para probarlos en directo sin tener que reiniciar nada.

El futuro de GSX es la inteligencia operativa impulsada por la comunidad.

Los desarrolladores de aeronaves pueden incluir controladores en sus paquetes. Los creadores de perfiles pueden superponer la lógica del aeropuerto. Los sistemas se apilan de forma limpia: el controlador de aeronaves conoce el avión, el controlador del aeropuerto conoce el aeropuerto y ambos trabajan juntos sin interferir entre sí.

Estamos muy emocionados por ver lo que la comunidad crea con esto. La documentación ya está disponible: léela, experimenta con el editor integrado y empieza a convertir tus aeropuertos de escenarios estáticos en operaciones vivas y dinámicas.

La rampa es suya.

Tu aeropuerto GSX acaba de obtener una conexión en directo con el mundo exterior.

Siguiendo con nuestra reciente publicación sobre los scripts de controlador, queremos destacar una de las capacidades más potentes, y quizás inesperadas, que aportan: su aeropuerto y los controladores de aeronaves ahora pueden conectarse a Internet en tiempo real.

No solo para mostrar un mensaje estático. Nos referimos a obtener datos en tiempo real, descargar archivos actualizados, comunicarse con API y mantener su aeropuerto sincronizado con el mundo real, de forma automática, cada vez que vuele.

Veamos qué es lo que se puede hacer.

Tiempo en directo desde una API meteorológica real

En el momento en que aparca en la puerta de embarque, un operador puede llamar a la API open-meteo.com con las coordenadas exactas de su aeropuerto y obtener la temperatura, la velocidad del viento y las condiciones actuales. Sin plugins, sin herramientas externas, solo su operador aeroportuario realizando una solicitud web y mostrándole: «Condiciones actuales en EDDM: 2 °C, viento 18 km/h NW».

Se trata de datos meteorológicos reales procedentes de una API real, obtenidos en el momento en que se detienen las ruedas. Y como el asistente conoce automáticamente la latitud y la longitud de su aeropuerto, la llamada se configura por sí sola.

Tráfico en directo de VATSIM: quién está conectado, qué se ha registrado

Si vuelas en VATSIM, los controladores pueden consultar la fuente de datos pública de VATSIM, un archivo JSON en vivo que se actualiza cada 15 segundos, y cruzar la información con tu plan de vuelo de SimBrief. ¿Tu indicativo está conectado actualmente? ¿Qué código squawk te han asignado? ¿Qué destino has registrado?

Todo esto puede fluir directamente a su pantalla de acoplamiento VGDS en la puerta de embarque. Mientras está en espera, la pantalla muestra su squawk, su destino registrado y su estado en línea/fuera de línea. Se actualiza automáticamente en segundo plano cada 30 segundos, sin que usted tenga que hacer nada.

¿Vuela sin conexión? La pantalla simplemente permanece limpia. Vuelva a conectarse y, en menos de medio minuto, le volverá a detectar.

Perfiles de aeropuertos que se actualizan solos

Aquí es donde las cosas se ponen realmente interesantes para los creadores de perfiles.

Con fetchINI() y fetchPY(), un gestor de aeropuertos puede descargar la última versión del perfil de su aeropuerto y el archivo de personalización de estacionamiento directamente desde su propio servidor, cada vez que el piloto llega a su aeropuerto.

Piense en lo que eso significa: usted publica un perfil actualizado que corrige la posición de una puerta, ajusta una ruta de retroceso o añade una nueva plataforma. Todos los usuarios que ejecutan su controlador lo obtienen automáticamente en su próximo vuelo, sin necesidad de reinstalarlo manualmente ni de publicar en el foro «por favor, vuelva a descargar la versión 1.3». Simplemente aterrizan y ya está ahí.

El sistema también es inteligente al respecto: utiliza HTTP ETags para descargar solo cuando realmente ha cambiado algo. Si sus archivos no se han actualizado desde la última visita del piloto, no se transfiere nada. Cero desperdicio de ancho de banda.

Un ejemplo concreto: usted mantiene el perfil de Milán Malpensa (LIML). Usted envía un diseño de estacionamiento corregido a su servidor. La próxima vez que cualquier usuario con su identificador aterrice en LIML, onEnterAirport se ejecuta, llama a su servidor, obtiene un 304 «nada ha cambiado» en el INI, pero detecta que el archivo PY es nuevo, lo descarga y recarga silenciosamente la personalización del aeropuerto. El piloto nunca se da cuenta. Simplemente funciona.

Fuentes de datos CSV: horarios reales de aerolíneas, ATIS, bases de datos personalizadas

fetchCsv() abre toda una categoría de fuentes de datos estructurados que utilizan el sencillo formato separado por comas.

Algunas ideas que se vuelven sencillas:

• Obtenga un CSV con horarios reales de un aeropuerto específico y compruebe si su número de vuelo coincide con una franja horaria de salida conocida; a continuación, muestre la hora real programada en la pantalla VGDS.
• Mantenga una tabla de asignación de puertas en su servidor: un simple CSV que asigne códigos de aerolíneas a áreas terminales. Su gestor lo descarga a la llegada y dirige automáticamente a cada aerolínea a la parte correcta del aeropuerto.
• Utilice la API VATSIM Slurper (que devuelve CSV sin encabezado) para comprobar la cobertura ATC: ¿hay algún controlador terrestre en línea en su destino en este momento? Muéstralo en el VGDS mientras el piloto se prepara para el retroceso.

La función maneja el CSV sin encabezado con elegancia: usted mismo proporciona los nombres de las columnas y las filas con campos adicionales (como datos de posición de longitud variable) se recopilan automáticamente en una lista separada.

Lectura de archivos de configuración INI y JSON también de forma local

No todo tiene que venir de Internet. Los controladores también pueden leer archivos de configuración locales directamente desde el paquete de la aeronave: el aircraft.cfg, el manifest.json, el 737_Options.ini de PMDG de la carpeta de trabajo WASM o cualquier archivo JSON personalizado que envíe con su complemento.

Esto permite a los desarrolladores de aeronaves hacer que sus controladores sean verdaderamente autoconfigurables. Un controlador puede abrir el manifiesto, leer la versión del paquete y ajustar su comportamiento en consecuencia. Puede leer un archivo de opciones PMDG y detectar si una configuración de aviónica específica está activa, y luego cambiar los parámetros de retroceso para que coincidan. Todo sin necesidad de codificar nada.

Todo es sin bloqueo

Una preocupación que podría tener la gente: ¿no se congelará el simulador al realizar solicitudes web?

No, y aquí está el porqué. Todas las funciones fetch* están diseñadas para ser llamadas desde métodos de controladores que se ejecutan en tareas en segundo plano. Un bucle de sondeo que comprueba VATSIM cada 30 segundos se ejecuta completamente en segundo plano con runAsync(), de forma totalmente independiente de las operaciones principales de GSX. El simulador sigue funcionando, los vehículos siguen moviéndose y los pasajeros siguen embarcando. Su solicitud web se realiza silenciosamente en segundo plano y actualiza la pantalla cuando está lista.

Incluso el almacenamiento en caché ETag está integrado: si el servidor no ha cambiado sus datos desde su última consulta, la respuesta vuelve instantáneamente desde la caché sin ningún tipo de ida y vuelta en la red.

Una nota sobre la seguridad

El sistema de recuperación está deliberadamente restringido. Las descargas de perfiles (fetchINI y fetchPY) requieren HTTPS; se rechaza el HTTP sin cifrar. Los perfiles descargados se analizan de forma segura sin ejecutar código arbitrario. El acceso a los archivos está restringido a prefijos virtuales específicos: ningún controlador puede salir de su entorno aislado para acceder a archivos arbitrarios de tu sistema. Los datos están limitados a 5 MB por respuesta. No se trata de limitaciones, sino de la razón por la que puedes confiar en un controlador creado por la comunidad que se ejecuta en tu máquina.

El panorama general

Los perfiles estáticos de los aeropuertos describen un lugar. Los controladores con datos en tiempo real dan vida a ese lugar.

Un aeropuerto que conoce el tiempo. Una pantalla de embarque que muestra su squawk VATSIM en tiempo real. Un perfil que se mantiene actualizado. Un controlador que lee su plan SimBrief y reconfigura todo el proceso (tipos de vehículos, método de repostaje, flujo de embarque) basándose en el vuelo real que ha registrado.

Esto es lo que ofrece la API fetch. Y ya está disponible, en el editor de scripts de controladores integrado en GSX, con documentación completa y ejemplos prácticos para que puedas empezar a utilizarlo.