DCS Mission Authoring Gateway

dcs-me-gateway es un servidor MCP local entre un diseñador de misiones de IA y el puente del Mission Editor de DCS-SMS. Convierte muchos comandos frágiles del editor en un pequeño protocolo de autoría versionado.

La puerta de enlace no hace clic en la interfaz de usuario y nunca enfoca DCS. Las solicitudes se escriben en el buzón existente de DCS-SMS. Si DCS no está enfocado y el bucle de actualización de su Mission Editor está limitado, una solicitud permanece en cola hasta que se reanuden los ticks o expire el plazo seleccionado por el llamador.

Implementado en 0.9

• Treinta y cinco herramientas MCP: descubrimiento de actualizaciones, autoría/validación de misiones, preprocesamiento persistente de mapa semántico e hidrología, consultas sin conexión, inspección de mapa en vivo, asignación en vivo de paquetes de aeródromos y portaaviones, enrutamiento de transporte nativo, descubrimiento de cargas de armamento autorizadas por DCS, descubrimiento de tareas de IA en vivo, planificación de perfiles de vuelo/temporización, plantillas de paquetes, dibujos, documentos de misión deterministas, configuración opcional de Skynet-IADS y gestión acotada de contenido externo sin conexión.

• Cuarenta y una operaciones de parche declarativas para el entorno de la misión, grupos, unidades, cargas útiles, rutas, opciones/comportamiento de puntos de ruta tipados, acciones activadas por grupos con nombre, disparadores, zonas circulares, frecuencias de grupo y distintivos de llamada de unidades.

• Referencias lógicas estables, incluida la adopción de entidades de misión existentes con nombre y nombres de unidades asignados por DCS.

• La guía de diseño de misiones se anuncia como instrucciones de inicialización del servidor MCP, no solo como un recurso/aviso opcional, por lo que los clientes compatibles reciben automáticamente los valores predeterminados de planificación, temporización, carga útil y política de IA.

• Instantáneas semánticas compactas, revisiones deterministas, concurrencia optimista y comprobaciones de poscondición por operación.

• Enlaces por misión y registros de idempotencia protegidos por escrituras atómicas y bloqueo entre procesos.

• Caducidad absoluta de solicitudes y manejo explícito de OUTCOME_UNKNOWN para evitar ejecución tardía y reproducción insegura después de una respuesta perdida.

• Un parche validado se envía en una sola devolución de llamada del Mission Editor; los prefijos parciales confirmados se registran si un verbo posterior falla.

• Los fragmentos de misión con forma prefabricada utilizan un punto final de transacción DCS-SMS dedicado con asignación nativa de ID/nombre, reasignación de referencias cruzadas, reversión y protección de reproducción en el lado del editor.

• La verificación de guardar/reabrir espera una revisión semántica estable y migra los enlaces a través de cambios de identidad de Guardar como.

• Guardas de compatibilidad fijas para rutas de vehículos creadas por DCS-SMS y propiedad obsoleta del panel de rutas del Mission Editor.

• Sin herramienta MCP de Lua arbitraria.

• Las anotaciones de mapa F10 con seguimiento de revisiones admiten lotes verificados de círculos, líneas, polígonos, etiquetas de texto y eliminaciones sin exponer una herramienta por forma.

• Un catálogo de plantillas de misión basado en datos devuelve diseños de sitios S-300PS/Buk ajustables y circuitos de espera escalonados de AWACS/repostadores. Los dos paquetes SAM se verifican en vivo contra la base de datos de unidades DCS instalada; son puntos de partida funcionales y representativos, no órdenes de batalla exactas del mundo real.

• La autoría de paquetes de portaaviones descubre en vivo el derecho de Supercarrier, los cascos gratuitos/de pago disponibles y las aeronaves capaces de operar desde portaaviones a partir de los metadatos de categoría de pista de DCS. Una transacción puede colocar un portaaviones solo o en una formación de escolta azul/roja representativa, calcular el viento sobre cubierta, autorizar acciones compatibles de TACAN/ICLS/Link 4/ACLS, vincular los arranques de aeronaves y los puntos de ruta de recuperación opcionales a la cubierta, y aplicar cargas útiles con nombre más consumibles de combate.

• La autoría básica de comunicaciones escribe frecuencias de grupo y distintivos de llamada de unidades normalizados. La validación sin conexión advierte cuando los grupos AWACS/repostadores comparten una frecuencia.

• El terreno en caché puede responder perfiles de coordenadas/elevación y línea de visión de terreno en línea recta con puntos explícitos de despeje y obstrucción. Los edificios y la vegetación quedan fuera de ese modelo.

• La autoría en modo mixto incluye un expediente de jugador militar ligero determinista de 1024×1440 y una superposición de contenido externo .miz de copia en escritura. El expediente lee distintivo de llamada, aeronave, ruta, temporización, radios, ayudas de portaaviones, cargas, combustible, armamento y contramedidas de una misión guardada fijada; la prosa táctica opcional sigue siendo una entrada explícita del agente. Las páginas de ruta usan terreno DCS en caché limpio con superposiciones semánticas y F10 deshabilitadas. La superposición gestiona rodilleras de aeronaves/generales, texto e imágenes de briefing, y recursos acotados de imagen/sonido/Lua sin editar la misión fuente en su lugar.

• Una caché de teselas reanudable extrae elevación y tipo de superficie autoritativos de DCS, deriva pendiente, aspecto, rugosidad y características candidatas de cresta/valle/paso, y renderiza tanto un PNG de terreno limpio como un PNG de contexto anotado sin requerir DCS para consultas posteriores.

• Una capa de hidrología reanudable de forma independiente muestrea el tipo de superficie DCS a 50 m por defecto sin reconstruir elevación, pendiente o regiones semánticas. Empaqueta cada muestra en dos bits, omite teselas base de tierra uniforme de alta confianza y mar abierto, deriva componentes de río/lago conectados de ocho vecinos con costuras de huecos cortos conservadoras reportadas por separado, y puede expandirse desde una rebanada validada a cobertura completa del conjunto de datos con IDs de tesela estables.

• Cada caché almacena lugares con nombre autorizados por DCS y metadatos de aeródromos fijos, incluidos umbrales/longitudes de pista, envolventes de estacionamiento, banderas de refugio y grupos de plataforma derivados. Las etiquetas de lugar permanecen explícitamente sin clasificar porque la fuente de pueblos de DCS proporciona nombres y coordenadas, no importancia.

• Un grafo de anclas acotado almacena en caché corredores de carretera y ferrocarril nativos de DCS entre aeródromos cercanos y lugares con nombre, incluida evidencia de desvío, elevación/gradiente, ajuste de punto final y cruce de agua. El enrutamiento en vivo sigue disponible para puntos finales precisos porque la caché no es una exportación completa de la red de carreteras.

• Las regiones de asentamiento aproximadas son grupos de lugares con nombre amortiguados con procedencia explícita y límites de vista de imagen recomendados. No son huellas de edificios; las estructuras individuales siguen siendo una tarea visual de inspección de mapas.

• La caché semántica también almacena entidades consultables de aeródromos, asentamientos y lugares con nombre, además de regiones de terreno contiguas clasificadas a partir de evidencia de superficie, elevación, pendiente, rugosidad y bajo detalle. Las regiones usan ejecuciones de fila compactas y registran adyacencia en lugar de pretender que una celda ráster es un límite administrativo del mundo real.

• Un grafo de transporte macro reanudable usa centros de aeródromos y asentamientos. Sus aristas son rutas de carretera/ferrocarril nativas de DCS con puertas de enlace de punto final ajustadas, por lo que una consulta sin conexión puede seleccionar una ruta regional de múltiples aristas mientras que el enrutamiento DCS en vivo sigue siendo la autoridad para la geometría exacta del convoy de primera/última milla.

• La inspección de mapas bajo demanda ajusta el mapa ME en vivo a los límites solicitados, captura solo su widget de mapa, escribe un PNG georreferenciado y restaura la cámara anterior. Una verificación de fotograma de movimiento de cámara rechaza capturas de editor oculto (por ejemplo, cuando la vista F10 de una misión en ejecución está realmente en pantalla).

• El preprocesamiento verifica automáticamente la forma de la caché, los bordes exactos de teselas compartidas y 16 puntos deterministas contra DCS en vivo. El mismo informe se puede volver a ejecutar con validate_map_dataset, o con paridad en vivo deshabilitada para control de calidad solo sin conexión.

• La detección conservadora de bajo detalle registra su evidencia y solo almacena una tesela gruesa cuando la tierra casi uniforme pasa todos los umbrales; no equipara silenciosamente terreno plano ordinario con marcadores de borde del Cáucaso.

• Accesorios dorados guardados por DCS, pruebas de archivo/Lua/referencia sin conexión y un arnés de autoría en vivo aislado que edita un clon, restaura el original y verifica su hash de archivo.

• La planificación de aeródromos en vivo usa el filtro de envolvente/categoría de aeronave de DCS y las plataformas reservadas de la misión abierta, el viento de superficie de la misión, las etiquetas de pista y un proxy de rodaje de plataforma a umbral probable. La creación verificada admite arranques en frío, en caliente y en pista para de una a cuatro aeronaves y elimina un grupo parcialmente construido si falla un paso de construcción. La estrategia de pista activa puede reasignar la elección nativa de estacionamiento compacto al conjunto de plataformas preferidas verificado.

• La autoría de cargas útiles con prioridad de preajuste consulta la compilación DCS instalada para preajustes de aeronaves con nombre, su compatibilidad de tareas declarada, cargas y peso. Los parches pueden aplicar un preajuste o hacer un ajuste acotado por pilón; la puerta de enlace nunca pide al modelo que invente CLSIDs o una carga útil completa. La autoría de combate también verifica explícitamente la munición de cañón; se advierte sobre una aeronave de combate sin cañón a menos que esa omisión sea intencional.

• El descubrimiento de tareas en vivo enumera solo las acciones de punto de ruta y en ruta que DCS expone para un grupo existente, y las descripciones de tareas proporcionan valores predeterminados, valores permitidos y orientación sobre selectores de objetivos faltantes antes de que se autorice un parche.

• La fecha/hora de la misión y los campos meteorológicos útiles son legibles en cada instantánea semántica y escribibles como una operación de entorno con verificación de revisión. Las opciones de punto de ruta tipadas incluyen Reacción ante amenaza, ROE, uso de radar/ECM, bingo RTB, silencio y prohibiciones de lanzamiento/postcombustión.

• Los perfiles de ala fija basados en roles y las estimaciones transparentes de arranque/rodaje/ascenso/tránsito ayudan a sincronizar la llegada del paquete. El lint sin conexión advierte cuando un scramble/interceptación de IA comienza su tránsito bajo o lento.

• El lint de comportamiento sin conexión advierte sobre aeronaves de combate IA desarmadas, grupos de combate sin tarea de enfrentamiento, tareas de objetivo sin IDs de objetivo, nombres de puntos de ruta semánticos sin comportamiento correspondiente y rutas aéreas sin aterrizaje/órbita/bucle terminal. El lint de objetivos también advierte sobre resultados opuestos que pueden dispararse ambos, condiciones de captura satisfechas por un solo miembro sobreviviente del grupo, grupos nombrados en el briefing omitidos de toda condición de resultado reconocida y puntos de ruta de interceptación asignados a grupos no aéreos. Estas son advertencias heurísticas de autoría, no afirmaciones sobre la corrección de la IA en tiempo de ejecución de DCS.

La puerta de enlace no afirma reversión para parches declarativos. Los verbos de parche de DCS-SMS se ejecutan secuencialmente en una sola devolución de llamada del ME; si el verbo N falla, los verbos 1 a N-1 pueden ya estar confirmados. El resultado registra el prefijo confirmado y la clave de idempotencia, evitando un reintento duplicado a ciegas. El punto final separado apply_mission_fragment tiene reversión nativa de DCS-SMS e informa explícitamente una reversión incompleta. Si su resultado reconocido o la instantánea posterior a la aplicación no pueden probar el resultado solicitado, la puerta de enlace devuelve OUTCOME_UNKNOWN y requiere inspección de la misión antes de la recuperación; nunca finge que una verificación fallida deshizo la mutación. Un verbo de parche transaccional futuro se describe en docs/dcs-sms-extension.md. Debido a que la revisión semántica en vivo no incluye contenidos de almacenes, la puerta de enlace bloquea conservadoramente la reproducción en caché de fragmentos que contienen efectos de almacén; inspeccione la misión antes de elegir una nueva clave. Los dibujos se incluyen en las revisiones semánticas y en la verificación de guardar/reabrir.

Las revisiones y la verificación de guardar/reabrir cubren la superficie de autoría del protocolo 0.1: registros semánticos de entorno, grupo, unidad, ruta, disparador, zona y dibujo, más la ruta de la misión y el teatro. El briefing, los almacenes y las opciones globales de la misión quedan fuera del límite de revisión actual.

DCS persiste los rumbos de los vehículos a nivel de grupo. La instantánea semántica usa por lo tanto el rumbo del vehículo líder para cada unidad en ese grupo de vehículos. Un intento de dar solo a un vehículo no líder un rumbo persistente diferente falla la verificación de poscondición en lugar de desviarse silenciosamente después de reabrir.

Related MCP server: DCS Lua Runner MCP Server

Requisitos

• El lanzamiento de Windows incluye su propio runtime de Node.js. El desarrollo de fuentes requiere Node.js 20.17 o más reciente.

• Windows, DCS World y el mod ME de DCS-SMS solo para herramientas de editor en vivo.

• Mission Editor abierto con DCS-SMS -> External execution habilitado para mutación.

• inspect_map_view requiere además que el mapa del Mission Editor esté abierto en una ventana no minimizada. DCS puede permanecer sin enfocar o cubierto; la puerta de enlace captura su ventana de aplicación directamente, nunca la trae al primer plano y no recurre silenciosamente a una captura de monitor sensible a la oclusión.

La extracción de mapas requiere los verbos tipados terrain info, terrain sample-grid, terrain list-places, terrain nearest-transport, terrain transport-path, airbase plan-start y airbase create-start en el árbol de trabajo del ME-mod 0.32.4 de DCS-SMS.

Instalar la versión para Windows

La versión es un único ZIP. Incluye la pasarela, dependencias de producción fijadas, un entorno de ejecución de Node portátil y el código fuente compatible del puente del Mission Editor de DCS-SMS. No requiere una instalación separada de DCS-SMS y no instala el hook del Mission Editor de DCS-SMS ni los archivos opcionales de LuaSec/OpenSSL.

Extrae el ZIP, cierra DCS y ejecuta:

powershell -NoProfile -ExecutionPolicy Bypass -File .\install.ps1 -Clients codex

Los valores admitidos para -Clients son codex, claude-code, claude-desktop y generic; se puede pasar más de uno. generic escribe un mcp-config.json portátil. Codex y ChatGPT desktop comparten la configuración local de MCP de Codex. Claude Code y Claude Desktop se registran de forma independiente. Otros clientes pueden usar el mismo comando stdio y entorno del archivo genérico. ChatGPT en la web no puede lanzar directamente un servidor stdio local; este paquete está dirigido a ChatGPT desktop/Codex en la máquina donde se ejecuta DCS. Consulta la documentación de MCP de OpenAI y la documentación de MCP de Claude Code para sus superficies de configuración nativas.

El instalador:

• detecta DCS y Saved Games o acepta -DcsPath y -SavedGames;

• verifica que DCS tenga Full Screen desactivado, pero nunca modifica esa preferencia;

• se niega a parchear el Mission Editor mientras DCS esté en ejecución;

• hace una copia de seguridad del MissionEditor.lua del usuario y de cualquier puente anterior;

• instala el código fuente del puente incluido bajo GPLv3 y añade solo su bloque require delimitado al archivo propio del editor del usuario; y

• registra únicamente la entrada MCP dcs-me solicitada por el usuario y fija esa entrada a la instancia de Saved Games seleccionada.

Al iniciar MCP, la pasarela comprueba el endpoint de la última versión estable de GitHub, con un tiempo de espera de 2,5 segundos y una caché local de seis horas. Cuando hay una versión semántica más reciente disponible, sus instrucciones MCP indican al agente que pregunte al usuario si desea actualizar. La comprobación nunca instala nada. Tras la aprobación explícita, cierra DCS y todos los clientes MCP que usen la pasarela, y luego ejecuta:

powershell -NoProfile -ExecutionPolicy Bypass -File `
  "$env:LOCALAPPDATA\DcsMeGateway\update.ps1"

El actualizador vuelve a preguntar antes de cualquier modificación, descarga solo la versión de Windows con su versión exacta, verifica su SHA-256 publicado por separado e invoca el instalador normal con copia de seguridad. Establece DCS_ME_GATEWAY_UPDATE_CHECK=0 para desactivar la comprobación automática. check_gateway_update realiza una comprobación manual o forzada. Las etiquetas de prerelease se excluyen deliberadamente de este canal de actualización.

Para una instalación guiada por agente, entrega la carpeta extraída a un agente y pídele que siga VIBEINSTALL.md. Tras la instalación, reinicia el cliente MCP, abre una misión en el Mission Editor de DCS y activa DCS-SMS -> External execution. Ese conmutador es solo para la sesión.

La pasarela es MIT. El puente DCS-SMS incluido permanece bajo GPLv3 y se distribuye con su código fuente completo y su licencia en payload/bridge; consulta THIRD_PARTY_NOTICES.md.

Instalar desde el código fuente y verificar

cd C:\path\to\dcs-me-gateway
npm install
npm test
npm run build
npm run test:golden
npm run test:live

Todo lo que pasa por test:golden es totalmente offline; DCS puede permanecer cerrado. Valida cualquier misión guardada de forma independiente con:

npm run validate:miz -- D:\Missions\mission.miz

El validador comprueba la integridad del ZIP y los límites de expansión, las entradas requeridas, la sintaxis literal de Lua, la estructura de la misión, los IDs/nombres, las rutas, las coordenadas, las referencias a entidades, las claves de diccionario y los recursos empaquetados. Analiza Lua como datos sin cargar ni ejecutar la misión.

Dado el parche declarativo y los archivos guardados inmediatamente antes y después, genera un informe de aceptación centrado con:

npm run report:patch -- patch.json before.miz after.miz [bindings-before.json] [bindings-after.json]
npm run docs:render -- --mission <saved.miz> --dataset <dataset-id> --output <new-directory>

El informe contiene los objetivos directos del parche, el contexto de dependencias de un salto, las postcondiciones de la operación, los hallazgos de validación introducidos/resueltos y cualquier entidad modificada fuera de ese ámbito. Termina con código distinto de cero si el archivo posterior es inválido, falla una postcondición, una dependencia cambia inesperadamente, o cambian metadatos/opciones de la misión no relacionados o una entidad fuera del ámbito. Los parches que hagan referencia a IDs lógicos creados anteriormente deben proporcionar el objeto de vinculación {"entities": ...} correspondiente (antes y, si las asignaciones cambian, después); los IDs sin resolver se notifican explícitamente y fallan la aceptación.

test:live solo lee la sesión del editor. Añade -- --snapshot para una instantánea de misión en vivo y de solo lectura.

npm run test:live-authoring es intencionadamente mutador. Requiere una misión ya abierta en el Mission Editor. El arnés primero duplica la misión con Save-As en .artifacts/live, edita solo la copia, comprueba la idempotencia, los conflictos de revisión, la edición de rutas, las zonas y la estabilidad tras guardar/reabrir, y luego reabre el original y verifica que su SHA-256 no ha cambiado. No lanza ni vuela la misión.

Inicia el servidor MCP a través de stdio:

node C:\path\to\dcs-me-gateway\build\index.js

Un host MCP debe configurar ese comando y ruta como un servidor stdio llamado dcs-me. Los diagnósticos van a stderr; stdout está reservado para las tramas MCP.

Configuración

Sin anulación, la pasarela lee el valor de configuración saved_games de DCS-SMS y elige la instancia DCS, DCS.openbeta o DCS.server con el latido de ME más reciente. Establece DCS_SMS_SAVED_GAMES cuando Windows Saved Games se haya reubicado y DCS-SMS no haya registrado esa ruta en su configuración.

Herramientas MCP

Ciclo de vida del paquete de mapas

Antes de la planificación de misión específica del mapa, se instruye al agente de misión a llamar a ensure_map_dataset para el teatro. La herramienta primero reutiliza un conjunto de datos local completo, luego verifica el registro empaquetado y su registro remoto opcional alojado en GitHub. Una descarga se transmite, limitada por su recuento de bytes registrado, verificada contra su SHA-256 registrado, extraída de forma segura, validada para identidad e integridad del conjunto de datos/teatro, y publicada atómicamente. El registro empaquetado en maps/registry.json es también el registro remoto canónico. Los conjuntos de datos grandes son activos de lanzamiento de GitHub inmutables y fijados por SHA-256; las cachés sin procesar y los archivos generados nunca se confirman en Git.

Si no hay ningún paquete registrado, la herramienta devuelve permission_required en lugar de abrir DCS o comenzar horas de extracción por sí misma. Solo después de que el usuario apruebe, el agente puede repetir la llamada con allow_local_build=true. El teatro solicitado debe estar instalado y abierto en Mission Editor con ejecución externa habilitada. La compilación es reanudable y puede requerir llamadas repetidas.

Los desarrolladores pueden compilar y empaquetar explícitamente un teatro no alojado:

npm run maps:settlements
npm run maps:build -- --theatre Caucasus
npm run maps:package -- --dataset caucasus-full-v01-250m `
  --base-url https://github.com/ALasek/DCS-ME-gateway/releases/download/maps-v0.9.0

maps:settlements es una pasada de revisión rápida e independiente para el teatro actualmente abierto en Mission Editor. Resuelve el catálogo curado coincidente a través de la conversión de coordenadas autoritativa de DCS, fusiona las etiquetas de pueblos nativas de DCS y escribe JSON más un PNG etiquetado en .artifacts/settlements. No muestrea ni reconstruye datos de terreno, elevación, cobertura terrestre, hidrología, transporte o bases aéreas. Use --output <directorio> para elegir una ubicación de salida estable.

El comando de empaquetado imprime la entrada de registro exacta, incluido el tamaño del archivo y SHA-256. Agregue esa entrada a maps/registry.json y suba el .tgz a la versión correspondiente. La compilación local es el respaldo para mapas que el autor del proyecto no posee; nunca es consentimiento implícito.

preprocess_map_region valida el rectángulo solicitado contra los límites autoritativos del teatro de DCS. El límite de 4,096 de DCS se aplica a las muestras en cada solicitud de cuadrícula de terreno, no a las teselas del conjunto de datos. max_tiles es solo una protección deliberada del tamaño del conjunto de datos (50,000 por defecto); tile_batch_limit limita cada invocación de MCP a 200 teselas faltantes por defecto. Si el resultado tiene complete=false, repita la llamada con la misma geometría del conjunto de datos y la misma configuración de muestreo. Cada actualización de tesela y manifiesto ya es duradera, los conjuntos de datos incompletos rechazan consultas normales, y la validación final puede expulsar teselas ilegibles, malformadas o inválidas por uniones para reparación automática en el siguiente lote. Los cambios de tamaño de lote y de protecciones de seguridad no cambian un ID de conjunto de datos generado automáticamente. Sus coordenadas north/east son los mismos metros locales del teatro utilizados por los objetos de misión. El prepaso conservador predeterminado puede retener mar uniforme de alta confianza o tierra uniforme similar a marcador de posición en resolución gruesa; cada decisión de este tipo es visible en el manifiesto y en el resultado de la consulta. Las líneas costeras, las superficies mixtas y el terreno plano que no satisfacen todos los umbrales permanecen en resolución completa. Las bases aéreas y las etiquetas de lugares creadas por DCS se almacenan en caché junto a las teselas de terreno y se anotan en las vistas previas. Los registros de lugares no se clasifican como ciudad/pueblo/aldea porque la fuente de DCS no expone esa distinción. La procedencia semántica registra la compilación de DCS, la configuración regional y la fuente de pueblos del teatro; los IDs de lugar se derivan de coordenadas porque las claves Lua duplicadas se sobrescriben cuando DCS carga algunos conjuntos de datos de teatro. Un cambio en la compilación del terreno de DCS requiere una reconstrucción explícita con force=true en lugar de reutilizar silenciosamente teselas obsoletas. query_map_context, query_airbase_context y query_transport_context leen solo la caché, por lo que DCS puede estar cerrado. La agrupación de plataforma de 200 m y las bandas de envolvente compacta/estándar/grande son heurísticas de navegación, no afirmaciones de compatibilidad con DCS. plan_airbase_start siempre vuelve a verificar la aeronave solicitada y la ocupación actual a través de DCS antes de la mutación.

render_mission_documents es determinista para la misma misión guardada, caché de terreno, versión de estilo, grupos seleccionados y prosa suministrada. Por defecto selecciona vuelos Player/Client. Produce un manifiesto y entradas kneeboard_images listas para pasar, pero no modifica la misión. Las carpetas de kneeboard de DCS pueden apuntar a todas las aeronaves o a un tipo de aeronave; no pueden distinguir dos vuelos que usan el mismo tipo, así que combine esas instrucciones o use páginas de briefing cuando se requiera separación por vuelo. La tarjeta de misión identifica el tipo de aeronave sin implicar una cantidad por vuelo. La página de comunicaciones/carga usa nombres de tiendas canónicos legibles por humanos, combustible en libras y munición de cañón como porcentaje; nunca muestra CLSID internos. Si la misión guardada tiene tiendas pero no un nombre de preset legible, llame a get_aircraft_loadouts con include_stations=true y pase sus nombres de visualización redactados por DCS en flight_notes.loadout_summary. El renderizado entonces emite una advertencia explícita hasta que se suministren esos nombres. Las tablas de waypoints usan valores ETA verificados de la ruta guardada donde la ruta está genuinamente programada; los eventos controlados por estado o con ritmo del jugador pueden usar en su lugar flight_notes.waypoint_notes[].time_label para señales y ventanas de tiempo sin inventar una hora de reloj fija. El renderizado advierte cuando una ruta de jugador con múltiples waypoints no tiene valores ETA útiles ni etiquetas de tiempo. Los mapas de ruta añaden solo etiquetas dispersas de bases aéreas y asentamientos principales, con las etiquetas de ruta y waypoints conservando prioridad visual y de colisión. Previsualice cada página antes de incrustarla.

apply_miz_overlay no es deliberadamente un editor general de tablas de misión. Guarde la misión ME activa, cierre o abra un archivo diferente, inspeccione el contenido externo existente, fije el SHA-256 reportado de ese archivo fuente y escriba en una nueva ruta de salida. La herramienta valida firmas reales de imagen/sonido/script, rechaza la eliminación de recursos referenciados y recolecta como basura las imágenes de briefing reemplazadas solo cuando no queda ninguna referencia de misión. Después de que el overlay tenga éxito, abra la salida en ME y ejecute save_and_verify. Los grupos centrales, rutas, disparadores y objetivos permanecen redactados por ME; esto evita que dos escritores diverjan silenciosamente en el mismo .miz.

Skynet-IADS opcional

Para una red multi-sitio/EWR significativa, un escenario SEAD/DEAD, o una misión cuyo equilibrio depende de tácticas de emisión de radar, el agente puede recomendar Skynet una vez y preguntar si el usuario acepta un comportamiento dependiente de scripts en tiempo de ejecución. No debe interrumpir cada diseño de SAM aislado con esa pregunta. Los estados de alarma nativos de DCS y los disparadores de emisión deterministas siguen siendo el valor predeterminado para amenazas aisladas, predecibles o de entrenamiento.

Después de la aceptación, dé a los nombres de grupos SAM gestionados un prefijo común y a los nombres de unidades EWR gestionadas un prefijo distinto, guarde la misión y llame a setup_iads con el SHA-256 del archivo guardado y una nueva ruta de salida. La herramienta verifica e incrusta Skynet-IADS 3.3.0 con su MIST 4.5.107 probado upstream, luego añade un disparador de Inicio de Misión que carga MIST, Skynet y la configuración generada en ese orden. El .miz resultante es autocontenido; los jugadores no instalan nada. Abra la salida en Mission Editor y ejecute save_and_verify antes de continuar.

La configuración valida hashes de scripts, orden de carga, membresía de coalición, prefijos y centros de mando nombrados. No puede probar el comportamiento IADS en tiempo de ejecución sin ejecutar la misión. Mantenga un tipo de sistema SAM por grupo SAM gestionado, un radar EWR por grupo EWR gestionado, y no añada acciones de emisión nativas que compitan con Skynet por los mismos radares. La procedencia, los hashes exactos y las licencias se registran en vendor/skynet-iads/3.3.0 y THIRD_PARTY_NOTICES.md.

analyze_terrain_line interpola bilinealmente la cuadrícula en caché más fina que cubre cada muestra e informa clear, blocked o indeterminate. El clasificador usa una envolvente explícita de resolución de elevación: clear y blocked requieren que toda la envolvente permanezca en un lado de la línea de visión. El modo solo-caché informa el corredor incierto y el espaciado recomendado sin contactar a DCS. refinement_mode=auto-live muestrea ese corredor acotado desde un teatro de Mission Editor abierto que coincida, lo divide al límite de muestras por llamada de la extensión, persiste los tiles más finos bajo el conjunto de datos y vuelve a ejecutar inmediatamente el LOS. Las consultas posteriores reutilizan esos tiles con DCS cerrado. Una re-ejecución fina puede legítimamente permanecer indeterminada; la respuesta informa un límite de resolución y, cuando es posible, un siguiente espaciado más pequeño en lugar de inventar una respuesta clear/blocked. Esto es adecuado para la colocación de radar/SAM y el cribado de rutas, pero no para afirmaciones finales de visibilidad donde importan edificios o árboles.

Después de que los tiles de terreno terminen, el preprocesamiento semántico deriva un ráster de clasificación de 2 km, suaviza celdas no acuáticas aisladas y convierte cada componente conexo de cuatro vecinos en una región de terreno compacta con estadísticas, adyacencia y geometría de filas corridas. Las bases aéreas y los grupos de asentamientos se convierten en centros de grafo. Los candidatos a carretera incluyen hasta cuatro vecinos dentro de 80 km más reparación de conectividad acotada; los candidatos a ferrocarril incluyen hasta dos vecinos dentro de 120 km. El enrutamiento ferroviario de DCS se trata como evidencia candidata porque su selector de red de terreno puede devolver características lineales no relacionadas. Un corredor ferroviario en caché debe encajar dentro de 1.5 km de ambos anclajes y su longitud enrutada debe cubrir al menos la mitad de su separación directa; los resultados más débiles permanecen como candidatos fallidos para inspección en lugar de exponerse al agente como ferrocarril. transport_batch_limit acota la extracción de rutas DCS en vivo por invocación, y el estado de aristas pendiente/completa/fallida es duradero y reanudable. Las polilíneas completadas conservan IDs de centro y puntos de puerta de enlace ajustados. query_transport_context usa Dijkstra sobre aristas en caché completadas para una ruta de centro nombrado sin conexión; route_ground_transport aplica las mismas comprobaciones ferroviarias conservadoras a rutas DCS actuales exactas usadas para la redacción de misiones. Las ejecuciones de superficie acuática se etiquetan water-crossing-candidate, no se afirma que sean objetos de puente destructibles. La agrupación de asentamientos evita deliberadamente un catálogo por edificio, que sería sensible a la versión del terreno e innecesariamente grande.

El procesador del Golfo Pérsico complementa las etiquetas de ciudades propias de DCS con el catálogo disperso y editable en maps/settlements/persian-gulf.json. Contiene ciudades principales, puertos y asentamientos insulares seleccionados para un vocabulario de escenario aproximadamente 1980-1990; no es una huella urbana histórica. Durante el preprocesamiento, DCS convierte cada punto WGS84 en las coordenadas locales del teatro cargado. Las etiquetas DCS cercanas que coinciden conservan su posición DCS mientras ganan el nombre curado, alias, tipo e importancia. Un punto curado independiente permanece solo como evidencia semántica regional. El SHA-256 del catálogo y la procedencia de fuente/era se almacenan en semantics.json, de modo que editar el catálogo invalida y reconstruye la semántica de asentamientos y transporte en caché sin reconstruir los tiles de elevación. Vea maps/settlements/README.md para el formato de limpieza intencionalmente simple.

query_map_context puede llamarse con límites, un semantic_search, o ambos. La búsqueda semántica puede filtrar clases de terreno, área mínima de región, proximidad a una entidad, tipo/nombre de entidad y acceso aproximado por carretera sin cargar tiles de terreno ni requerir DCS. inspect_map_view es la ruta de detalle complementaria: no almacena en caché cada edificio o marca de carretera, pero devuelve el renderizado ME actual a la escala solicitada con una transformación afín píxel-a-teatro. Escribe temporalmente la cámara del mapa ME, se serializa contra otras mutaciones de puerta de enlace y restaura la cámara anterior incluso cuando falla la captura o la validación de visibilidad. Resuelve el identificador exacto de ventana de DCS y falla con detalles de geometría de ventana y recuperación cuando DCS está minimizado o un Alt-Tab de pantalla completa exclusiva ha eliminado su superficie capturable. DCS sin bordes/ventana puede permanecer detrás del cliente MCP durante la inspección. Si una base aérea, un grupo de asentamientos y un lugar DCS crudo comparten un nombre, use el ID de entidad devuelto o un selector kind:name como settlement:Batumi o airbase:Batumi; los nombres simples ambiguos fallan en lugar de seleccionar silenciosamente uno.

Ejecute el visor de caché en capas local con npm run viewer durante el desarrollo o npm run viewer:start después de npm run build, luego abra http://127.0.0.1:4317. Visualiza la topografía limpia en caché, las regiones de terreno contiguas, las aristas de transporte utilizables y fallidas, los cascos de asentamientos, las entidades semánticas y las etiquetas sin contactar a DCS.

validate_map_dataset transmite la legibilidad de tiles y comprobaciones de arrays, compara solo aristas compartidas adyacentes y no materializa el mapa completo en memoria. Su direct_samples=16 predeterminado compara puntos en caché distribuidos uniformemente con el teatro DCS actualmente cargado; use direct_samples=0 para las comprobaciones solo sin conexión. El informe también se guarda como validation.json bajo el directorio del conjunto de datos. La vista general del conjunto de datos completado se pinta igualmente de un tile a la vez en su ráster de salida acotado.

El arnés de desarrollo acotado del Cáucaso muestrea deliberadamente la franja detallada de costa-a-montaña Batumi-Kobuleti en lugar del área exterior plana del mapa:

npm run test:live-map

Muestrea north=-370000..-330000, east=610000..670000 a 250 m, persiste el progreso después de cada tile y es seguro de re-ejecutar. Añada -- --force solo para refrescar deliberadamente tiles ya en caché. No procesa todo el mapa.

Refinamiento de hidrología

La caché de terreno de 250 m no se trata intencionalmente como geometría fluvial autoritativa: un río estrecho puede caer entre puntos de cuadrícula y aparecer como puntos azules dispersos. preprocess_hydrology_layer adjunta una caché separada de hydrology/ a un conjunto de datos completado existente. Su cuadrícula predeterminada de 50 m almacena solo un código de superficie compacto de dos bits por muestra; la elevación y las derivadas de terreno permanecen en su resolución base. Los tiles base ya probados como tierra de relleno uniforme o mar abierto se omiten de la planificación, mientras que los tiles costeros detallados y mixtos se muestrean.

Comience con límites representativos y repita llamadas idénticas hasta completeForBounds=true. Después omita bounds para expandir la misma capa sobre todos los tiles base detallados. tile_batch_limit acota cada invocación y max_tiles es solo un techo de seguridad deliberado. Un espaciado, tamaño de tile, teatro o firma de terreno DCS cambiados fallan en modo cerrado; force=true comienza deliberadamente un nuevo refresco de hidrología y las llamadas reanudables posteriores usan force=false. query_map_context devuelve cobertura, recuentos de superficie acotados exactos, métricas de costura deterministas y componentes muestreados de río/lago conexos de ocho vecinos cuando la capa existe. Sus mapas de vista previa y documentación limpia incorporan la máscara de agua más fina.

Los códigos DCS originales y los recuentos de superficies siguen siendo evidencia inmutable. Un empalmador direccional sin conexión puede rellenar como máximo dos celdas ausentes cuando las muestras de origen en ambos extremos continúan por la misma línea; las celdas inferidas se notifican por separado y se usan solo para la continuidad de componentes y el renderizado. Esto es deliberadamente más conservador que el cierre morfológico sin restricciones, que puede fusionar vías fluviales cercanas no relacionadas. La geometría de componentes no es ni un polígono de ribera ni una garantía de navegación. Los ríos más estrechos que el espaciado elegido pueden seguir quedando fragmentados, así que usa una pasada acotada más ajustada o una inspección del mapa en vivo cuando la colocación exacta de las riberas importe. Las teselas base de alta confianza de tierra aproximada gruesa y de mar uniforme quedan fuera de la cobertura de hidrología por diseño; esta optimización supone que la calibración base de bajo detalle ya ha separado el terreno no relacionado con la misión del mapa respecto de las llanuras detalladas reales. El visor expone la capa generada como una superposición Rivers / lakes que se puede alternar por separado. La presentación se deriva, no es evidencia: los lagos conservan un ráster de área muestreada suavizado, mientras que las bandas de río se adelgazan de forma determinista, se unen por huecos de forma conservadora, se simplifican y se dibujan como líneas centrales de SVG con suavizado de bordes y un ancho fijo en espacio de pantalla. Las consultas y la validación siguen usando las celdas empaquetadas originales y los puntos de empalme identificados por separado.

El esquema de las posibles correcciones del parche también se expone como recurso MCP dcs-me://schema/mission-patch/0.1. Consulta examples/f16-rwr-patch.json y su posterior examples/f16-rwr-route-patch.json.

La creación de una misión completa debe comenzar con el prompt MCP design_dcs_mission. Guía una conversación en lugar de exigir una especificación de una sola vez: el agente puede formular preguntas de alto impacto, recomendar valores predeterminados, sugerir alternativas y mantener un registro vivo del rol del jugador, el resultado, cada fase, la finalidad de cada grupo, la interacción causal, la capacidad/configuración y el equilibrio. La instrucción canónica legible por humanos es docs/design-dcs-mission.md; el servidor carga ese mismo archivo para las instrucciones de inicialización, el prompt MCP y el recurso de orientación. Una columna vertebral coherente y una primera parte preceden a la mutación, pero los detalles posteriores pueden permanecer abiertos mientras se redactan y prueban las partes aprobadas. La misma instrucción está disponible como recurso de solo lectura dcs-me://guidance/mission-design/0.1. Los conceptos de misión se desarrollan con el usuario y se implementan de forma incremental para respetar las barreras de enlace del Mission Editor.

El esquema de fragmento completo se expone en dcs-me://schema/mission-fragment/0.1. Acepta el modelo de datos que usa un prefab de DCS-SMS (meta, groups, statics, zones, drawings, y triggers) además de una política de colocación explícita. El endpoint realiza sus comprobaciones previas y su mutación dentro del Mission Editor, por lo que invocarlo requiere DCS; desarrollar y ejecutar las suites de pruebas del repositorio no.

El esquema de solicitud de portaaviones de alto nivel se expone en dcs-me://schema/carrier-package/0.1. Consulta primero get_catalog con kind=carrier_capabilities para inspeccionar los cascos, las licencias, los aviones compatibles con portaaviones y los tipos de escolta de la instalación DCS abierta. dry_run=true devuelve el fragmento compilado y el plan resuelto de viento sobre cubierta sin modificar la misión. La selección automática de módulos prefiere Supercarrier cuando DCS lo informa como instalado y autorizado; en caso contrario, selecciona el portaaviones gratuito de la coalición.

El esquema de inicio de base aérea de alto nivel se expone en dcs-me://schema/airbase-start/0.1. create_airbase_start requiere un Mission Editor abierto, comprueba la revisión semántica solicitada y la clave de idempotencia, verifica las posiciones disponibles compatibles, invoca el verbo de construcción nativo de DCS-SMS y verifica el tamaño del grupo, el tipo de aeronave, la vinculación con el aeródromo del waypoint cero, el modo de despegue y los IDs de estacionamiento explícitos en una instantánea nueva. La estrategia de estacionamiento por defecto active_runway usa viento de superficie y designaciones de pista para ordenar las posiciones compatibles libres por distancia en línea recta al umbral, y después verifica la reasignación; compact conserva la elección original de grupo cercano de DCS-SMS. Esa distancia es un proxy de rodaje, no una garantía de ruta temporal. Los aeródromos terrestres fijos usan este endpoint; los espacios de cubierta de portaaviones usan setup_carrier_package. Los FARP siguen siendo una superficie futura separada.

Los valores de los campos de disparador pueden referirse a una entidad lógica anterior con "$ref:<logical_id>"; el compilador sustituye su nombre DCS estable. Una referencia a una Acción disparada con nombre se resuelve a la tupla actual {groupId, taskNumber} de DCS justo antes de añadir la acción del disparador. Los valores index de los puntos del camino en las instantáneas y el waypoint_index de cada parche son de base cero. Los índices de regla de disparador y los espacios de Acciones disparadas siguen siendo de base uno.

Las operaciones admitidas son:

• Entidades existentes: adopt_entity para nombres exactos de grupo, unidad, disparador o zona.

• Grupos: create_group, set_group_task, set_group_late_activation, remove_group. Establece lead_logical_id en create_group cuando los parches posteriores deban direccionar la primera unidad; la pasarela enlaza el nombre que devuelve DCS.

• Unidades: add_unit, set_unit_skill, set_unit_heading, set_unit_loadout, set_unit_payload, clear_unit_payload, remove_unit. Consumibles de la cantidad: set_unit_fuel, set_unit_chaff, set_unit_flare y set_unit_gun.

• Rutas: add_waypoint, insert_waypoint, remove_waypoint, link_waypoint_airbase.

• Comportamiento de waypoint: add_waypoint_task, add_waypoint_enroute_task, remove_waypoint_task, remove_waypoint_enroute_task, clear_waypoint_tasks, clear_waypoint_enroute_tasks y la operación tipada set_waypoint_option. Los fields de las tareas aceptan matrices y registros tipo JSON anidados, incluyendo selectores como targetTypesHelpers: ["Air"].

• Acciones disparadas de grupo: add_triggered_task, replace_triggered_task y remove_triggered_task. Estas crean entradas con nombre estable de tarea y tarea de ruta; usa el ID lógico de la tarea en un campo de acción a_ai_task o a_set_ai_task. Elimina la acción disparadora que la referencia a antes de eliminar la tarea.

• Entorno: set_mission_environment para fecha/hora, temperatura, QNH, visibilidad, turbulencia, viento a tres niveles, nubes y polvo.

• Disparadores: create_trigger, add_trigger_condition, add_trigger_action, remove_trigger_condition, remove_trigger_action y remove_trigger.

• Zonas: create_zone_circle, remove_zone.

Editar una ruta para un grupo creado en el mismo parche requiere un parche posterior para que el Mission Editor pueda terminar de construir el estado de la ruta. Editar o eliminar una unidad creada por add_unit o un líder declarado con create_group.lead_logical_id también requiere un parche posterior porque DCS asigna el nombre de unidad en el resultado de la operación. La validación informa estos casos como errores de límite explícitos antes de despachar cualquier mutación.

Flujo de trabajo de aeronave con preferencia por valores programados

Para una aeronave armada, llama a get_aircraft_loadouts con aircraft_type y intended_task. Prefiere un preset con nombres original de DCS que declare compatibilidad con esa tarea; si hay varios que coinciden, elige el moderado, el que tenga un nombre claro y cuyas cargas se adapten a la misión y al alcance esperado. Solicita include_stations=true para el preset elegido antes de cualquier ajuste. Aplícalo con set_unit_loadout; después utiliza set_unit_payload o clear_unit_payload sólo para un requisito explícito que el preset no cumpla. Un preset tiene una designación con un panel: compara los valores de combustible, chaff/flash/cañón heredados de la unidad con el máximo del plano devuelto y los valores predeterminados de contramedidas, y después establece explícitamente los valores no adecuados. Los ajustes de espoleta o programa específicos de la carga aún no forman parte del esquema de parche restringido de la pasarela.

La enumeración de cargas es un adaptador de solo lectura propiedad de la pasarela sobre me_loadoututils de Mission Editor de DCS, no un verbo de DCS-SMS formal. Es sensible a la versión, falla en modo cerrado si la API del Mission Editor cambia y se ha verificado contra la instalación local de DCS, no como una interfaz estable de Eagle Dynamics.

Para el comportamiento de la IA, primero llama a get_ai_task_catalog para el grupo y tipo de tarea reales y luego a describe_ai_task. EngageGroup/AttackGroup requieren un groupId numérico; las variantes de unidad requieren unitId; EngageTargetsInZone reque el teatro local x (norte) y y (este). Usa los IDs de la instantánea semántica actual. Un nombre de tarea por sí solo no constituye una asignación de objetivo válida.

Límite de seguridad

El puente subyacente de DCS-SMS ejecuta Lua en el entorno del Mission Editor. Este servidor restringe el código generado a un despachador de lotes fijo y a llamadas de verbos de DCS-SMS serializadas en JSON/base64. Mantenlo local, no expongas su stdio a través de un servicio de red no autenticado y deja la ejecución de script no autético deshabilitada cuando no sea necesario.

El validador y el informe de parches sin conexión no usan el buzón de DCS-SMS ni requieren que DCS esté instalado o ejecutándose. Establecen solo integridad estructural y referencial. No pueden probar que DCS pueda cargar el archivo, normalizarlo igual al guardar estos datos, ni que la IA, los sensores, los disparadores y las armas se comporten como se espera en tiempos de ejecución; esos siguen siendo capas de aceptación explícitas posteriores.

License

MIT. DCS-SMS es un proyecto separado; su árbol tools/ tiene licencia GPLv3.

Crear una versión para Windows

El compilador de la versión compila la puerta de enlace, instala solo las dependencias de producción con bloqueo npm en la prepara, descarga una distribución oficial de Node para Windows y verifica su SHA-256, copia la fuente del puente DCS-SMS compatible exacta y el texto de GPL, inventaría las licencias npm, escribe un manifiesto por archivo y genera un ZIP con su suma de verificación:

npm run release:windows -- -DcsSmsSource C:\path\to\dcs-sms

Hasta que la fuente del puente personalizado 0.32.4 sea confirmada y publicada, las versiones deben compilarse desde el árbol de trabajo local verificado de DCS-SMS. El payload/bridge/SOURCE.md generado registra su revisión base y si el árbol de trabajo estaba sucio; la fuente completa del puente correspondiente está dentro del mismo paquete.