DCS Mission Authoring Gateway

dcs-me-gateway es un servidor MCP local situado entre un diseñador de misiones con IA y el puente del Editor de Misiones de DCS-SMS. Convierte muchos comandos frágiles del editor en un pequeño protocolo de creación versionado.

El gateway 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 Editor de Misiones está limitado, una solicitud permanece en cola hasta que se reanudan los ticks o expire el plazo seleccionado por el llamante.

Implementado en 0.9

• Treinta y cinco herramientas MCP: descubrimiento de actualizaciones, creación/validación de misiones, preprocesado 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 base aérea y portaaviones, enrutado de transporte nativo, descubrimiento de configuraciones de carga derivadas de DCS, descubrimiento de tareas de IA en vivo, planificación de perfiles/flujos de tiempo, 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 declarativas de patch para el entorno de la misión, grupos, unidades, equipamiento, rutas, opciones/comportamiento de waypoints con tipo, Triggered Actions de grupos con nombre, triggers, zonas circulares, frecuencias de grupo y indicativos de unidad.

• Referencias lógicas estables, incluyendo la adopción de entidades de misión ya existentes y de nombres de unidades que DCS ha asignado.

• Las directrices de creación de misiones se anuncian como instrucciones de inicialización del servidor MCP, no solo como recurso/prompt opcional; así, los clientes compatibles eligen automáticamente los valores por defecto de planificación, temporización, cargas y política de IA.

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

• Asociaciones por misión y registros de idempotencia protegidos mediante escrituras atómicas y bloqueo inter-proceso.

• La caducidad absoluta de las solicitudes y el tratamiento explícito de OUTCOME_UNKNOWN evitan ejecuciones tardías y una reproducción no segura después de perder la respuesta.

• Un parche validado se envía en una sola llamada de retorno del Editor de Misiones; si un verbo posterior falla, se registran los prefijos confirmados hasta ese momento.

• Los fragmentos de misión con forma de plantilla utilizan un endpoint de transacción dedicado de DCS-SMS con asignación nativa de IDs/nombres, remapeo de referencias cruzadas, rollback y protección de repetición en el editor.

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

• Se han fijado protecciones de compatibilidad para las rutas de vehículos creadas con DCS-SMS y para la propiedad obsoleta del panel de rutas del Editor de Misiones.

• No hay ninguna herramienta MCP de Lua arbitraria.

• Las anotaciones del mapa F10 con seguimiento de revisión 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 misiones basado en datos ofrece disposiciones de sitios S-300PS/Buk y circuitos en óvalo (racetrack) para AWACS/repostadores. Los dos paquetes SAM se comprueban en vivo contra la base de datos de unidades DCS instalada; son puntos de inicio funcionales y representativos, no órdenes de batalla reales exactas.

• La creación de paquetes de portaaviones descubre en vivo la habilitación de Supercarrier, las plantas disponibles (gratuitas/de pago) y las aeronaves capaces de operar desde portaaviones según los metadatos de categoría de pista del propio DCS. Una sola transacción puede colocar un carguero en solitario o en una formación de escolta junto a una coalición azul/roja representativa, calcular el viento sobre cubierta, generar las acciones TACAN/ICLS/Link 4/ACLS compatibles, asociar los arranques de las aeronaves y los puntos de rumbo de recuperación opcionales a la cubierta, y aplicar puntos de transmisión de nombre específico además de consumibles de combate.

• La escritura de comunicaciones de base escribe frecuencias de grupo y códigos de unidad normalizados. La validación sin conexión avisa cuando los grupos AWACS/repostadores comparten una frecuencia.

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

• La creación en modo mixto incluye un dosier de jugador determinista de 1024×1440 de estilo militar y una capa de contenido externo .miz con copia en escritura. El dosier consiste en código, o hora de partida, ruta, tiempos, radios, ayudas de aterrizaje, combustible, armamento, cañón y contramedidas de una misión guardada fijada; la prosa táctica opcional sigue siendo entrada explícita del agente. Las páginas de ruta usan terreno DCS en caché limpio y con las superposiciones semánticas y F10 desactivadas. La capa gestiona musgos de aeronave y generales, el texto y las imágenes de la misión principal, y recursos de imagen/sonido/Lua limitados sin modificar la misión original.

• Una caché de fichas reanudable extrae la elevación y el tipo de superficie autorizadas de DCS, deriva pendiente, orientación, aspereza y posibles rasgos de cresta/valle/paso, y genera a la vez un PNG de terreno limpio y un PNG contextual anotado, sin necesitar DCS para consultas posteriores.

• Una capa de hidrología reanudable de forma independiente muestrea el tipo de superficie de DCS a 50 m por defecto, sin necesidad de reconstruir elevación, pendiente o regiones semánticas. Empaqueta cada muestra en dos bits, salta mosaicos base de tierra uniforme y mar abierto con alta confianza, obtiene componentes de río/lago conectados en ocho direcciones con costura conservadora de pequeños huecos reportada por separado, y puede ampliar desde una diciada validada hasta la cobertura completa del conjunto de datos con identificadores de mosaico estables.

• Cada caché almacena los lugares con nombre creados por DCS y los metadatos fijos de los bases aéreas, incluidos los umbrales/longitudes de pista, los límites de aparcamiento, las banderas de refugio y los racimos de plataforma derivados. Las etiquetas de lugares se mantienen explícitamente sin orden de prioridad, porque la fuente de ciudades de DCS aporta nombres y de coordenadas, no importancia.

• Un grafo de anclaje acotado analiza los corredores nativos de carretera y de ferrocarril entre lugares próximos cercanos y bases aéreas, con pruebas de desvío, elevación/peralte, el ajuste del punto final y el cruce de agua. El enrutado 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 asentamientos aproximadas son grupos de lugares con nombre con buffer y procedencia explícita y con con límites de visualización de imagen recomendados. No son huellas de edificios; las estructuras individuales siguen estando sujetas a inspecciónación visual del mapa.

• La caché semántica almacena además entidades consultables de bases aéreas, asentamientos y lugares con nombre, y algunas regiones de terreno contiguas clasificadas por superficie, elevación, pendiente, rugosidad y evidencia de bajo detalle. Las regiones usan series de filas compactas y registran y data de la adyacencia, en ves de pretender que una celda deo sea un límite administrativo real.

• Un grafo de transporte macro reanudable utiliza centros de conectividad de base aérea y de asentamiento. Sus aristas son trayectos DCS de carretera/ferrocarril con pasos de retorno de extremos ajustados, de modo que una consulta sin conexión puede elegir una ruta regional de varios tramos mientras que el enrutado DCS en vivo sigue siendo el punto de referencia para la geometría exacta del convoy en el primer y/dorado kilómetro.

• La inspección del mapa bajo demanda encaja el mapa live del ME con los límites solicitados, captura solo su widget de mapa, e escribe un PNG georreferenciado y restaura la cámara anterior. La comprobación de marcador por movimiento de cámara detecta cuando el editor está oculto (por ejemplo, cuando la vista F10 de una misión en ejecución está el fondo realmente visible).

• El preprocesamiento comprueba automáticamente la geometría de la caché, los volúmenes compartidos exactos y 16 puntos deterministas contra el DCS en vivo. Este informe puede repetirlo validate_map_dataset, o con el modo de equivalencia en vivo desactivado, para un control de calidad solo sin conexión.

• La detección conservadora de bajo detalle registra su evidencia y solo guarda una laja gruesa si el terreno casi uniforme supera todos los umbrales; no equipara silenciosamente el terreno llano normal con los marcadores externos del borde de los frame.

• Pruebas doradas guardadas por DCS, pruebas offline de archivo/Lua/referencia, y un proxy de creación en vivo aislado que edita una copia, restaura el original y verifica su hash de archivo.

• La planificación activa de bases aéreas usa la rueda de categoría/arpa deDCS y los puestos reservados de la misión abierta, el viento en superficie, las etiquetas de pista y un proxy de taxi de rampa a umbral probable. La creación verificada soporta puestas en marcha en frío, caliente y en pista para entre una y cuatro aeronaves, y elimina un grupo parcialmente construido si falla un paso de la creación. La estrategia de pista activa puede reasignar la elección de estacionamiento compacto nativo al conjunto de puestos preferidos verificado.

• La autoría de cargas de armamento preestablecida consulta la instalación de DCS por los ajustestablecidos con nombre de cada aeronave, su compatibilidad de tareas declarada, los depósitos y el peso. Los parches pueden aplicar un predefinido o realizar un ajuste acotado por punto de unión; el puerta nunca pide al modelo que invente CLSIDs o una carga armada completa. La creación de combate también comprueba explícitamente la munición de cañón; se advierte a un avión de combate con cero de batería, salvo que esa omisión sea deliberada.

• El descubrimiento de tareas en vivo lista únicamente las acciones de punto de trayectoria y en ruta que DCS ofrece para un grupo existente. Las descripciones de tarea proporcionan los valores por defecto, los valores permitidos y la guía para cortar objetivos olvidados; la creación del parche empieza después de ese análisis.

• La fecha/hora la misión y los parámetros meteorológicos útiles se pueden leer en cualquier instantánea semántica y se pueden escribir como una sola operación de entorno de revisado. Las opciones tipadas de punto de parámetro incluyen Reacción ante amenaza, ROE, uso de radar/ECM, bingo RTB, silencio y prohibición de soltar y usar postcombustión.

• Los perfiles de ala fija basados en roles y las estimaciones de arranque, transferencia, rodaje y tránsito tienen transparencia, lo que ayuda a sincronizar franjas de llegada. La evaluación interránea sin conexión avisa cuando una interceptación de IA comienza su tránsito a baja altitud o baja velocidad.

• La comprobación de comportamiento sin conexión advierte sobre aviones de combate AI no armados, grupos de combate sin misión de contacto, misiones de objetivo sin IDs de objetivo, nombres de waypoints semánticos sin comportamiento correspondiente y rutas aéreas sin igualade aterrizaje/óvalo/diagrama final. La comprobación de consequence también avisa de eventos opuestos que pueden encenderse simultáneamente, condiciones de captura que bastan con que sobre un miembro del grupo, grupos denominados en el briefing que no aparecen en ningún resultado reconocido y waypoints de interceptación asignados a grupos que no son aéreas. Son advertencias autorales de aprueba heurística, no afirmaciones sobre la exactitud del comportamiento de la IA de DCS marina.

El gateway no dispone de rollback para los parches declarativos. Los verbos de parche de DCS-SMS se ejecutan secuencialmente en un único callback del Editor de Misiones; si el verbo N falla, los verbos 1 a N-1 pueden ya haberse confirmado. El resultado registra el prefijo confirmado y la clave de idempotencia, lo que evita un reintento duplicado a ciegas. El endpoint separado apply_mission_fragment usa el rollback nativo de DCS-SMS y detecta de manera explícita un rollback incompleto. Si su resultado acordado o la instantánea posterior a la aplicación no pueden aplicar el resultado solicitado, el gateway devuelve OUTCOME_UNKNOWN y exige inspección de la misión antes de la recuperación. En ese caso resulta que una verificación fallida ha deshecho la categoría. El futuro parche de transacción se describe en docs/dcs-sms-extension.md. Como la revisión semántica en vivo no incluye el contenido del almacén, el primer paso es una estrategia de cursor: los fragmentos con brillo que contienen efectos de almacén no se pueden reproducir en boca de lar, la cache; enviés debe inspeccionar la misión antes de elegir una nueva clave. Los dibujos se incluyen en las revisiones semánticas y de la verificación de guarda/reabrir.

Todas las revisiones y la verificación de guarda/reabrir pueden ser de creación con la superficie de creación del 0.1: el entorno semántico, el grupo y los registros de grupo son válidos. No hay un tipo de entorno, pero la actual 0.1 es compatible; el área de autoría es la cuenca de la versión.

No se admiten caminos técnicos.

La persisten los rumbos de vehículos a nivel de grupo. Por esa razón la instantánea semántica usa el rumbo del vehículo principal para cada unidad de ese grupo de vehículos. Un intento de dar una dirección de una sola unidad distinta del líder no supera la verificación de condiciones posteriores y no tod subterráneamente una deriva tras elreopen.

Requisitos

• El paquete de Windows incluye su propio runtime de Node.js. El desarrollo del código fuente requiere Node.js 20.17 o nuevo.

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

• Editor de Misiones abierto con DCS-SMS -> External execution habilitada para permite para la modificación, incluida la misión en vivo.

• inspect_map_context requiere además que el mapa del Editor de Martin esté abierto en una ventana no minimizada. DCS puede permanecer sin foco o cubierto; el gateway captura directamente su ventana de aplicación, nunca la trae al primer plano y no recurre 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 worktree 0.32.4 del ME-mod de DCS-SMS adjunto.

Instalar la versión para Windows

La versión es un único ZIP. Incluye la puerta de enlace, las dependencias de producción bloqueadas, un runtime 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 de misión de DCS-SMS ni los archivos opcionales 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 MCP local 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 que ejecuta DCS. Consulta la documentación MCP de OpenAI y la documentación MCP de Claude Code actuales 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 deshabilitado, pero nunca edita 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 GPLv3 incluido y añade únicamente su bloque require delimitado al archivo del editor propio 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 puerta de enlace 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 disponible una versión semántica más reciente, 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 puerta de enlace y, a continuación, ejecuta:

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

El actualizador vuelve a preguntar antes de cualquier mutación, descarga únicamente la versión de Windows versionada, verifica su SHA-256 publicado por separado e invoca el instalador normal con preservación de copias de seguridad. Establece DCS_ME_GATEWAY_UPDATE_CHECK=0 para deshabilitar la comprobación automática. check_gateway_update realiza una comprobación bajo demanda 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 habilita DCS-SMS -> External execution. Ese conmutador es solo para la sesión.

La puerta de enlace es MIT. El puente DCS-SMS incluido sigue siendo 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 hasta 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 en datos sin cargar ni ejecutar código de misión.

Dado el parche declarativo y los archivos guardados de inmediatamente antes y después del mismo, produce 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. Sale con código distinto de cero si el archivo posterior es inválido, falla una postcondición, una dependencia cambia inesperadamente, los metadatos/opciones/almacenes de la misión no relacionados cambian o una entidad fuera del ámbito cambia. Los parches que hagan referencia a IDs lógicos creados anteriormente deben proporcionar el objeto de enlace {"entities": ...} correspondiente (antes y, si las asignaciones cambiaron, después); los IDs no resueltos se notifican explícitamente y fallan la aceptación.

test:live lee únicamente 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 guardada ya abierta en el Mission Editor. El harness primero clona esa misión mediante Save-As en .artifacts/live, edita solo el clon, comprueba la idempotencia, los conflictos de revisión, la edición de rutas, las zonas y la estabilidad de 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 debería 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 una anulación, la puerta de enlace lee el valor de configuración saved_games de DCS-SMS y luego 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 ha reubicado y DCS-SMS no ha 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, acotada por su recuento de bytes registrado, verificada contra su SHA-256 registrado, extraída de forma segura, validada para identidad e integridad de 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 iniciar 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 la 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 mediante la conversión de coordenadas autoritativa de DCS, fusiona las etiquetas de ciudades nativas de DCS y escribe JSON más un PNG etiquetado en .artifacts/settlements. No muestrea ni reconstruye datos de terreno, elevación, cobertura del suelo, hidrología, transporte o bases aéreas. Use --output <directory> para elegir una ubicación de salida estable.

El comando de empaquetado imprime la entrada de registro exacta, incluidos el tamaño del archivo y el SHA-256. Añada esa entrada a maps/registry.json y suba el .tgz al lanzamiento correspondiente. La compilación local es el respaldo para los 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 de teatro autoritativos 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 MCP a 200 teselas faltantes por defecto. Si el resultado tiene complete=false, repita la llamada con geometría de conjunto de datos y configuraciones de muestreo idénticas. 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 con uniones inválidas 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 de teatro utilizados por los objetos de misión. La preparación conservadora predeterminada puede retener mar uniforme de alta confianza o tierra uniforme similar a marcador de posición a resolución gruesa; cada decisión de este tipo es visible en el manifiesto y el resultado de la consulta. Las líneas de costa, superficies mixtas y terreno plano que no satisfacen todos los umbrales permanecen a resolución completa. Las bases aéreas y las etiquetas de lugares creadas en 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 ciudades del teatro; los ID de lugares se derivan de coordenadas porque las claves Lua duplicadas se sobrescriben cuando DCS carga algunos conjuntos de datos de teatro. Una compilación de terreno DCS cambiada 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 rodilleras de DCS pueden apuntar a todas las aeronaves o a un tipo de aeronave; no pueden distinguir dos vuelos que utilizan el mismo tipo, así que combine esas instrucciones o use páginas de briefing cuando se requiera separación específica por vuelo. La tarjeta de misión identifica el tipo de aeronave sin implicar una cantidad por vuelo. La página de comunicaciones/loadout usa nombres canónicos legibles de armamento, combustible en libras y munición de cañón como porcentaje; nunca muestra CLSIDs internos. Si la misión guardada tiene armamento pero no un nombre de ajuste preestablecido legible, llame a get_aircraft_loadouts con include_struitierra-berter/index estacións=true …] y pase sus nombres de etiqueta de DCS en flight_notes.loadout_summary. El renderizado emite una advertencia explícita hasta que se proporcionen esos nombres. Las tablas de puntos de ruta usan valores ETA verificados de rutas guardadas cuando la ruta está realmente planificada; los eventos gobernados por estado o marcados por el ritmo del jugador pueden usar flight_notes.waypoint_notes[].time_label para indicaciones y ventanas temporales sin inventar una hora de reloj fija. El renderizado advierte cuando una ruta de jugador con múltiples veces no tiene ni valores ETA útiles ni etiquetas de tiempo. Los mapas de ruta añaden solo etiquetas dispersas de bases aéreas y asentimientos, conservando la prioridad visual y para evitar colisiones de la ruta y los puntos de ruta. Previsualice cada página antes de convertirla.

El apply_miz_overlay no pretende ser un editor general de tablas de misión. Guarde la misión viva en el editor de misiones, cierre a un archivo o ácalor diferente, inspeccione el contenido externo existente, devele el SHA-256 reportado de ese archivo a la fuente y escriba en una nueva ruta de salida. La herramienta valida firmas reales de imágenes, sonidos y guiones, rechaza la eliminación de recursos referenciados y solo elimina las imágenes de briefing reemplazadas cuando no queda ninguna referencia de misión. Después de que the overlay has success, opens the output in ME and runs save_and_verify. Los grupos principales, las rutas, los disencastes y los objetivos permanecan all author-son en el editor; esto evita que dos escritores divergen en silencio respecto the same .miz.

Skynet-IADS opcional

Para una red multi-sitio/EWR significativo, un escenario SEAD/DEAD, o una mission whose la equilibra depende de las tácticas de emissiones de radar, the agent may recommend Skynet once and ask whether the user accepts runtime-script-dependent behavior. No should interrupt each isolated SAM design with that question. The native DCS alarm states and deterministic triggers of emission remain the default for pushes an isolated, predictable or training threat.

After the user accepts, assign one common prefix to the managed SAM group names and a distinct prefix to the managed EWR unit names, save the mission, and call setup_iads with the SHA-256 contract of the saved file and a new output path. The tool verifies and embeds Skynet-IADS 3.3.0 with the MIST 4.5.107 previously tested, then adds a MISSION START trigger that loads MIST, Skynet and the generated configuration in that order. The resulting .miz is self-contained; Plaktors install nothing. Open the output in the mission editor and run save_and_verify before continuing.

The setup validates script hashes, the order of loading, coalition membership, the prefixes, and the named command centers. I cannot prove runtime the IADS behavior without executing both missions. Keep a single SAM system type per managed SAM group, a single EWR radio per managed EWR group, and do not add native emission actions that compete with Skynet for the same radars. Origin, exact hashes and licenses are registered under vendor/skynet-iads/3.3.0 and THIRD_PARTY_NOTICES.md.

analyze_terrain_line performs bilinear interpolation of the finest cached flush covering each sample and returns from clear, blocked or indeterminate result. The classifier uses an explicit elevation-resolution envelope: clear and blocked require the entire envelope to remain on at one side of the line of sight. Allow-only cached mode reports the uncertain corridor and recommended spacing without contacting DCS. refinement_mode=auto-live obtains a sample of that bounded corridor on an open Mission Editor theater, divides it by the maximum number of calls of the extension, stores the finer tiles under the dataset, and immediately repeats the LOS. Later queries access usable tiles; you don't need DCS open. A fine rerun may legitimately become indeterminate; the response reports a resolution limit and, if possible, a smaller subsequent spacing instead of inventing a clear or blocked answer. This is suitable for placement of radar/SAM and route filtering, but not final visibility assertions when buildings or trees matter.

After the terrain decks are ready, semantic processing generates a classification raster of 2 km, smooths isolated non-water cells, and converts every four-connected component into a compact terrain region with statistics, adjacency and row series. Airbases and settlement clusters become graph hubs. The path candidates include up to four neighbors in 80 km plus limited connectivity repair; the railway candidates include up to two neighbours in 120 km. The DCS railway path is evidence of candidate evidence, because its terrain network selector can return unrelated linear features. A railway corridor must be attached within 1.5 km to both anchors and the path length must cover at least half of their direct separation; weaker results remain rejected but available for review, instead of exposing themselves to the agent as railroad lines. transport_batch_limit restricts useful DCS path extraction per invocation, and the pending/complete/failed edge is persistent and can be resumed. The complete polylines retain LSIDs and connecting access points. query_transport_context uses Dijkstra to raise over the cached edges for an offline path between named hubs; route_ground_transport applies the same interval-volume range to exact current DCS paths used for authorizing the mission. Watercourse routes are labeled as water-crossing-candidate, notays down a "it is a bridge" state. The parish clustering deliberately avoids a building-by-building catalogue, which would be too sensitive and unnecessarily large.

The Persian Gulf processor supplements the town labels provided by DCS with the curated vanity, from maps/settlements/persian-gulf.json. It contains major cities, ports, and island settlements chosen for an approximate scenario vocabulary from the 1980–1990 decade; It is not a historical footprint of the city. During the preprocess, DCS converts each WGS84 point into local coordinates of the theater that is now loaded. When matching DCS labels exist at the same time, they maintain a position. The local DCS position and gain curated its name, aliases, type, and importance. A standalone curated point remains only regional semating evidence. The SHA-256 of the catalogue and the provenance (source/era) are stored in semantics.json, which automatically invalidates and reconstructs the settlement and transport semantics of the cache if the catalog is changed, without reusing elevation tiles. For the intentionally simple cleanup format, the format. See maps/settlements/README.md.

Interaction and map view

About query_map_context and semantic_search (continue)

The query_map_context call may be made with a bounding box, with semantic_search, or both. Semantic search can filter by terrain classes, the minimum area of a region, by proximity to an entity, by type/name of the entity, and by approximate accessibility to a road, without loading terrain; we don't require DCS. inspect_map_view is the complementary detail path: it does not cache all buildings or road clearance, but it returns the current render content of Mission Editor at the requested scale, through an affine transformation pixel->theater. This temporarily writes the ME map camera, serializes against other controller mutations, and restores the previous camera even when the capture fails or the visibility check fails. It determines exactly the DCS window descriptor and, if DCS is minimized or an exclusive full-screen Alt-Tab has removed its capturable surface, fails and provides window geometry and inspection details. The windowed DCS without restriction may remain behind the MCP client during inspection. If an airbase, a settlement cluster and a local DCS point share the same name, use the returned entity ID or a selector kind:name such as settlement:Batumi or airbase:Batumi; ambiguous fuzzy names fail instead of silently selecting one.

Local layer cache viewer

Run npm run viewer during development, or npm run viewer:start after npm run build and then open http://127.0.0.1:4317. It allows you to visualize the clean cache of the local area, contiguous terrain regions, usable and unusable transport edges, title hulls, semantic entities and labels, without contacting DCS.

Dataset validation

W validate_beta_dataset reads tile accessibility and arrays in a streaming object, compares only adjacent shared edges, and does not loads the entire map into memory. The default ‘points 16’ compares uniformly distributed pawned samples with the current display of DCS in the theater; use direct_samples=0 for offline-only tests. The report is also saved as validation.json in the dataset directory. Finished dataset overview is generated the same way, drawing tile by tile in a final bounded raster.

The constrained Caucasus harness purposely samples the detailed coast-to-mountain Batumi-Kobuleti strip rather than the map's varied outer area:

npm run test:live-map

It samples nine north=-370000..-330000, east=610000..670000 at 250 m, persists progress after each tile, and is safe to re-run. Add -- --force only to intend refresh the already cached tiles. It does not process the entire map.

Hydrology refinement

The 250 m original terrain cache is not deliberately treated as real river geometry: the narrow river can remain between grid points and appear as sparse blue dots. preprocess_hydrology_layer adds a separate hydrology/ cache on an existing completed dataset. Its default 50 m grid stores only a simple 2-bit surf. code per sample; elevation and terrain derivatives remain at their base resolution. The based tiles, already known to be uniform or open ocean basic clothing, are omitted from the plan, while the detailed and mixed tiles of the coast are literally captured.

Start with the essential range constraints and repeat identical calls until completeForBounds=true. Later omit bounds to expand the same layer over all detailed base tiles. t from existing application constrains each call and max_tiles is only a protection ceiling of conscious. Data of a different interval or tile size, theater or DCS type, certificate of mismatch fails in closed mode; force=true deliberately starts a new hydrology refresh and next resumable calls use force=false. query_map_context returns details, specific number of surface cells for the selected bounds, deterministic stitching metrics and for gathering components/eversible 8/log modules, when the layer exists. The preview and clear documentation maps integrate this water mask more precise.

Los códigos originales de DCS y los recuentos de superficie siguen siendo una evidencia inmutable. Un empalmador direccional sin conexión puede rellenar como máximo dos celdas faltantes cuando las muestras de origen en ambos extremos continúan a lo largo de la misma línea; las celdas inferidas se notifican por separado y se utilizan únicamente para la continuidad de los componentes y el renderizado. Esto es deliberadamente más conservador que el cierre morfológico sin restricciones, que puede fusionar vías de agua cercanas no relacionadas entre sí. La geometría de un componente no es 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 utiliza una pasada delimitada más ajustada o inspecciona el mapa en vivo cuando la ubicación exacta de las riberas sea importante. Las teselas base de alta confianza de tierra provisional de baja resolución y de mar uniforme quedan fuera de la cobertura de hidrología por diseño; esta optimización asume que la calibración base de bajo detalle ya ha separado el terreno de la misión del resto de las llanuras detalladas reales del mapa. El visor expone la capa generada como una superposición independiente conmutable Rivers / lakes. La presentación es derivada, no probatoria: los lagos conservan un ráster suavizado del área muestreada, mientras que las bandas de ríos se adelgazan de forma determinista, se unen en sus huecos de forma conservadora, se simplifican y se dibujan como líneas centrales SVG con anti-aliasing y ancho fijo en espacio de pantalla. Las consultas y la validación siguen utilizando las celdas empaquetadas originales y los puntos de empalme identificados por separado.

El esquema completo del parche también queda expuesto como recurso MCP dcs-me://schema/mission-patch/0.1. Véanse examples/f16-rwr-patch.json y su consiguiente 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 hacer preguntas de alto impacto, recomendar por defectos, sugerir alternativas y mantener un registro vivo del rol del jugador, el resultado, la solución, el propósito de cada grupo, la interacción causal, las capacidades/uñas de munición y la exigencia. La instrucción canónica legible por humanos es docs/design-dcs-mission.md; el servidor carga ese mismo archivo tanto para las instrucciones de inicialización como para el prompt MCP y el recurso de práctica. Una columna coherente y un primer segmento preceden a la mutación, pero los detalles posteriores pueden quedar abiertos mientras las secciones aprobadas se redactan y prueban. La misma instrucción también está disponible como recurso de solo lectura ecs-me://guidance/mission-design/0.1. Los conceptos de misión se desarrollan con la persona usuaria y se implementan de forma incremental para respetar las barreras de bloqueo del Mission Editor.

El esquema completo de base de modo presentado en dcs-me://schema/mission-fragment/0.1. Acepta el modelo de datos que usa un prefab de DCS-SMS (meta, groups, parque, zones, far draw , triggers) más una política de colocación explícita. El endpoint ejecuta su pre-infraestructura previa y su mutación dentro del Mission Editor, por lo que llamarlo requiere DCS; no así desarrollar y ejecutar los conjuntos de pruebas del repositorio y la pista.

El esquema de aplicación de portaviones de alto nivel se estructura en field_me://schema/carrier-package/0.1. En primera consulta, get_pawn; con kind=carrier_capabilities especifique el catálogo de la instalación DCS abierta: cascos, entitlements, aeronaves compatibles con portaaviones y tipos de escolta. dry_run=true devuelve el fragmento y la distribución planificada del viento sobre cubierta compilados y evitados, sin cambiar la misión. La selección automática de módulo prefiere Supercarrier cuando DCS indica que está instalado y autorizado; en caso contrario, elige el portaviones gratuito de la coalición.

El esquema de solicitud de base aérea de alto nivel está en ground-me: //example/airbase-start/0.1. other_airbase_start solicita una Mission Editor abierta, revisa la revisión semántica y la adjudicación de idempotencia solicitadas, analiza cuando los puestos libres son compatibles, invoca el verbo de construcción nativo de DCS-SMS y verifica en una nueva snapshot radiante, tipo de aeronave, unión con el aeródromo en el waypoint cero, el modo de elevación y los identificadores explícitos de estacionaación. La estrategia básica de estación; active_active_runway usa el viento de superficie y los deseñadores de pista para ordenar los puestos libres según la distancia de espera en línea recta, y verificar la reasignación; compact conserva la elección cercana del grupo original de DCS-ES. Esa distancia es un asistente para el taxi, no una garantía de tiempo de trayecto. En lo alto de aeródromos fijos se usa este endpoint; en las posiciones de cubierta de portaaviones se usó setup_carrier_package. Los FARP siguen siendo una superficie separada para el futuro.

Los valores de los campos de los disparadores pueden referirse a una entidad lógica anterior con "$ref":""; el compilador sustituye el nombre estable de DCS de esa entidad. Una referencia a una Triggered Actioncon nombre se resuelve a la tupla comuna actual de DCS{groupId, upstream}inmediatamente a antes de que se añada la acción cativadora del disruptor. Los valoresindexde los puntos de ruta en las instantáneas y todos loswaypoint_indexde los parches son que los índices de regla de disparador y los huecos Triggered Action` siguen siendo 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. Establezca lead_logical_id para create_group cuando los parches posteriores deban referir la primera unidad, y la pasarela para vincular 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. El icono payload y de consumibles: set_unit_fuel, set_unit_chaff, set_unit_flare, set_unit_gun.

• Rutas: add_waypoint, insert_waypoint, remove_waypoint, link_waypoint_airbase.

• Comportamiento de punto de ruta: 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 tipio set_waypoint_option. Los fields de una tarea admiten matrices y reglas anidadas como JSON, incluidos selectores como target como target .

• Triggered Actions de grupo: add_triggered_task, replace_triggered_task, remove_triggered_task. Estas crean entradas de tarea y de tarea en ruta con nombres estables; use el logical ID de la tarea en el campo de acción de un disparador a_ai_task o a_set_ai_task. Quite la acción disparadora que hace que las referencias se eliminen antes de eliminar la tarea.

• Entorno: set_mission_environment para fecha/hora, temperatura, QNH, visibilidad, turbulencia, viento en tresalturas, nubes y polvo.

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

• Zonas: create_zone_circle, remove_zone.

Para editar una ruta de un grupo creado en el mismo periodo parche, es necesario un bloque posterior para que el Mission Editor pueda terminar de construir su estado de ruta. Para editar o eliminar una unidad creada mediante add_unit, o un líder, indicado mediante create_group.lead_logical_id, también necesito un bloque posterior, porque el DCS asigna el nombre de la unidad final en el resultado de la operación. La validación report assortment estos casos como errores de barrera explícitos antes de emitir cualquier mutación.

Flujo de trabajo basado en preselecciones de aeronave

Para una aeronave con portación de armas, llamar a get_aircraft_loadouts con aircraft_type e purpose. Priorize un preset de DCS que declare compatibilidad con esa tarea; cuando hagan juego varios, elija el preset moderado, claramente nombrado, y cuya carga se ajuste a misión y autonomía esperada. Solicite include_stations=true para el preset elegido antes de afinar nada. Luego apague con set_unit_loadout, y use set_unit_payload o clear_unit_payload solo para un requisito explícito que no cumple el preset. Un preset de DCS acuerda solo los pitillos: compare el cache de la unidad de valores de combustible/chaff/flare/cañón y los valores máximos del icing motor y las contramedidas que regresan, luegofijándolas explícitamente si no son adecuados. No se han entrado de los platos de fusión/programa específicos de cada conjunto de carga no todavía para el esquema de par cos constreñido de la pasarela.

La enumeración de lo carianos de arm es un adaptador de lectura no remitido de la pasarela sobre el me_loadoututils de DCS Mission Editor, no un verbo formal de DCS-SMS. Por tanto depende delimita la versión, alérgico a fallos, si la API de Mission Inditeria cambia y está verificado con la build DCS local instalada en lugar de estar publicado como una interfaz estable de Eagle Dynamics.

Para comportar AI, primero llame a get_ai_task_catalog para el grupo y tipo de tarea reales; posteriormente describe_ai_task. EngageGroup o AttackGroup requieren una MSc numérica groupId; las variantes de unidades requieren una unitId; EngageTargetsInZone requiere las coordenadasx (norte) e y (este) del teatro local. Use los identificadores encuentrados en la instantánea semántica actual. Un nombre anteriormente no forma una asignación de objetivos válida.

Límite de seguridad

El bridge subyacente de DCS-SMS ejecuta Lua en el idioma de ejecución comple ex. Este servidor no restringe el código posterior a un dispatch de lotes fijo y a llamadas de verbo ID-MSS serializadas en JSON/base64. Mantíllalo local, no transmitir su stdio a travesting HTTP por màquina no autenticado, y no dejar ejecución externa deshabilitada cuando no sea necesaria.

El validador sin conexión y el informe de parses no utilizan la bandeja de entrada de la plataforma de DCS-SMS ni requieren DCS instalado o en ejecución. Solo establecen la integridad estructural y referencial. No pueden poner a prueba que DCS cargue el archiveComp it normalice igual al guardar, ni que el comportamiento del BC, los sensores, los disparadores y las armas se como disponible, que seanstrate explícitamente en las capas de aceptación posterior.

Licencia

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

Generar una versión para Windows

El creador de la versión compila la pasarela, solo instala las dependencias de producción fijadas de npm en la zona de staging, descarga la distribución oficial de Node.js Windows y verifica la huella SHA-256 publicada, copia el código fuente del bridge compatible y la do con DCS-SMS y el texto GPL, clasifica la licencia de npm, escribe un manifiesto por archivo y produce un paquete ZIP más un checksum:

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

Hasta que el código fuente de bridge 0.32.4 se comprometa y se publique, las versiones deben compilarse desde el árbol led de trabajo de DCS-SMS controlado verificadamente localmente. El payload/bridge/SOURCE.md generado registra la revisión base y si el árbol de trabajo estaba sucio; no lo es, el resto del código fuente correspondiente del bridge dentro del misma paquete.