Traducción de la página original en inglés de OmsiLaunch 0.1.0-beta3. La página en inglés es la referencia normativa: si difieren, prevalecen la página en inglés y el código.
Esta página enumera, a partir del código, todo lo que en OmsiLaunch 0.1.0-beta3 es UNAVAILABLE, PARTIAL o un riesgo aceptado, para que usuarios e integradores no construyan sobre un comportamiento que el producto no ofrece. Cada fila nombra la limitación, su estabilidad, por qué existe y dónde se documenta en detalle. La documentación en inglés es normativa; las copias traducidas bajo docs/localized/ no se mantienen al mismo nivel y pueden quedar desfasadas (consulta la última sección).
Solo se admite Omsi23004_692EBFBF (692EBFBF...6243); el hash de Steam LAA 7DAB063D...D759 está en la lista de permitidos; su huella y su plan se validaron con una copia controlada, pero la fase de juego necesita una instalación genuina de Steam (la imagen es el ejecutable de Steam protegido con DRM)
LAST_MAP_STATE (/last, WorldMode.LastMapState) no está implementado; nunca se sustituye por un .osn elegido por marca de tiempo
UNAVAILABLE (BI-006)
Diagnóstico del plan OL_E_CAPABILITY_UNAVAILABLE
La fecha, la hora y el año explícitos o del sistema (/date, /time, /year, new.date/new.time/new.year del perfil, DateSpec/TimeSpec/YearSpec) se transportan en la especificación, pero hacen que el plan no sea ejecutable; el plugin rechaza los modos distintos de Unset
Preset meteorológico, ICAO y tiempo real actual en el inicio (/weather*, new.weather)
UNAVAILABLE (STATICALLY_PARTIAL, BI-003)
como arriba
El modelo, el repaint, el HOF, el número de flota y la matrícula del vehículo del jugador en el inicio (familia /vehicle, PlayerVehicleSpec) se resuelven contra el catálogo de contenido, pero no se aplican; solicitarlos hace que el plan no sea ejecutable; la asignación headless determinista de PlayerVehicle es una extensión futura
El punto de entrada por identidad (/entrypoint:<identity>) no se correlaciona con la lista presentada por OMSI; usa /entrypoint-index
PARTIAL (BI-001)
capacidad del plan world.entrypoint-identity = RUNTIME_PARTIAL
Los overlays de documentos de teclado y controladores (InputSpec, Environment.Keyboard, Environment.Controllers) se analizan, pero ninguna sesión los aplica nunca
UNAVAILABLE (BI-005)
capacidades input.*
LaunchBehaviorSpec.RestoreConfiguration y InstallationSpec.ExpectedExecutableSha256 están declarados, pero nunca se leen
Los flags de diagnóstico (/log, /logall, /omsi-logall, /verbose, /trace, /trace-process, /trace-plugin, /trace-native) rellenan DiagnosticsSpec; el efecto visible se limita a la traza del host en .omsilaunch\diagnostics
La detención de la sesión es una terminación forzada: session.stop, «End session» (finalizar la sesión) en la bandeja, Ctrl+C y CloseAsync conducen todos a TerminateProcess. La rutina de cierre de OMSI no se ejecuta, OMSI no reescribe options.cfg ni sus logs al salir, y se pierde cualquier estado de OMSI no guardado. Es deliberado: evita que OMSI escriba sobre los archivos restaurados.
Al cerrar la consola o en el cierre de sesión de Windows, el propietario dispone de un presupuesto de 4 s para detener y restaurar; lo que quede pendiente lo recupera el diario en el siguiente inicio
cierre de consola validado en runtime; cierre de sesión de Windows no probado
El lease de la instalación es un semáforo Local\: un propietario por instalación por sesión de inicio de sesión; no se aplica entre usuarios; no se libera mientras otro proceso tenga un handle; cualquier proceso del mismo usuario puede retener el nombre
La recuperación se rechaza (OL_E_INSTALLATION_BUSY) mientras se ejecuta el proceso de OMSI registrado en el diario o, para un diario sin PID, cualquier Omsi.exe de esa raíz
por diseño
como arriba
Una ruta de overlay originalmente ausente cuyo contenido cambió durante la sesión bloquea la restauración (OL_E_RECOVERY_ABSENT_OWNERSHIP_MISMATCH) hasta que se inspeccione
por diseño
como arriba
Los diarios anteriores a las huellas de propiedad solo puede cerrarlos una sesión con bytes planificados idénticos (OL_E_RECOVERY_ABSENT_OWNERSHIP_UNVERIFIED)
PARTIAL
como arriba
Solo se restauran las rutas propiedad de la sesión. Las escrituras propias de OMSI durante una sesión ([last_map] de options.cfg cuando ningún ajuste aplica un overlay a options.cfg, Texture\standard.ipr, cachés, laststn.osn, perfil de conductor, logs) persisten, igual que tras un inicio directo de OMSI
weather.set se rechaza (OL_E_RUNTIME_SETTING_NOT_PERSISTENT): OMSI sobrescribe ambos candidatos de viento del perfil en su siguiente ciclo meteorológico
Escrituras de variables de cadena, triggers con nombre, triggers de sonido (propiedad de las cadenas gestionadas de Delphi)
UNAVAILABLE (BI-004)
scripts.string.read es de solo lectura
No hay reubicación de vehículos, ni revinculación espacial entre tiles, ni autoridad sobre transformaciones segura para ODE; los campos de posición son de solo lectura
UNAVAILABLE (BI-008)
road-vehicle.read
camera.lock / camera.unlock necesitan un PlayerVehicle; el inicio headless de NEW_MAP no tiene ninguno (una situación guardada proporciona uno)
por diseño (BI-007)
RV-004
Las mutaciones de runtime (time.set, camera.set, camera.lock, vehicle.variable.set, spawn, place-random, texturas D3D) no se registran en el diario ni se restauran
Punto ciego de la huella de los handles: un objeto de la misma clase y definición recreado en la misma dirección entre dos lecturas de lista no se detecta como obsoleto; la vida útil ante la eliminación natural (RV-002) no tiene un productor seguro en runtime y sigue siendo offline
Los resultados están acotados por el buzón de 64 KiB: las listas largas se truncan (truncated=true); las cargas de píxeles se limitan a 48 KiB por d3d.texture.update
Canal de una sola solicitud en vuelo: una solicitud cada vez por sesión; un slot ocupado da OL_E_RUNTIME_CHANNEL_BUSY; los ids de solicitud no deben reutilizarse
La telemetría es un slot de último valor: las ráfagas más rápidas que el muestreo de 100 ms del host pueden perder eventos intermedios (los números de secuencia mantienen diferenciados los eventos consecutivos idénticos; las muestras incoherentes se omiten)
El reset del dispositivo D3D se observó en runtime (resetting, restored, invalidación de generación); no se produjo una transición lost diferenciada porque el dispositivo de OMSI pasó directamente a DEVICENOTRESET
Los resultados de listas acotadas (las operaciones timetable.*.list, vehicle.variables.list, vehicle.string-variables.list) devuelven como máximo las filas que caben en el slot de runtime de 64 KiB; el resto se omite con truncated=true y un returned_count menor (auditoría de documentación BUG-05). No hay paginación en esta versión
timetable.logs.read, road-vehicles.list, humans.list, vehicle.constants.list y vehicle.curves.list no están acotadas: un resultado mayor que el slot falla con OL_E_RUNTIME_RESPONSE_TOO_LARGE (no se ha observado en ninguna de ellas en los mapas probados)
Las cadenas de evidencia autodeclaradas (RuntimeValidation de PublicCapabilityRegistry, EvidenceState de GetCapabilitiesAsync) no se actualizaron tras la ronda de cierre de runtime: camera.lock sigue indicando STATICALLY_VALIDATED y runtime.d3d.lifecycle.resetIMPLEMENTED_NOT_RUNTIME_VALIDATED. La página estado de la validación en runtime es la referencia autorizada
desfase de la documentación, no una diferencia de comportamiento
Algunos campos avanzados del grafo de mapas, tiles, rutas y objetos no se exponen; los lectores de runtime son snapshots tipados condicionados al perfil, nunca acceso arbitrario a memoria
Las lecturas de memoria dentro del proceso siguen el patrón comprobar y luego usar contra un OMSI en ejecución; una mutación concurrente de OMSI entre la comprobación y la lectura puede producir un snapshot incoherente (OL_E_RUNTIME_OPERATION_FAILED)
Modelo de confianza del mismo usuario: la canalización con nombre (CurrentUserOnly), las asignaciones de memoria de handoff, telemetría y runtime y el semáforo del lease son accesibles para cualquier proceso del mismo usuario de Windows. Un proceso así puede leer el estado, detener la sesión o ejecutar operaciones de runtime una vez que ha leído el session_id.
El endpoint de control solo existe mientras el propietario está en Running; un cliente ve OL_E_NO_ACTIVE_SESSION (salida 4) durante el arranque y después de que termine la sesión
Si otro proceso ya posee el nombre de la canalización, el propietario sigue ejecutándose sin endpoint (ListenFault), y un segundo lanzamiento puede notificar erróneamente OL_E_SESSION_ALREADY_ACTIVE
La retención conserva las 50 sesiones más recientes; los diagnósticos más antiguos con prefijo de sesión se eliminan cuando se inicia una sesión nueva
por diseño
como arriba
La salida JSON y los diagnósticos incluyen rutas de la instalación (RootPath, directorios de recursos, rutas .itx)
por diseño (datos locales)
El cuadro de diálogo de fallo de la sesión de OmsiLaunchW.exe muestra como mensaje la carga útil de fallo del plugin (por ejemplo {"name":"world.failed",...}) en lugar de una frase; la línea Code: es correcta
Una solicitud D3D rechazada por el puente nativo antes de cualquier llamada a Direct3D notifica native_status correctamente, pero su texto detail indica HRESULT 0x00000000
La ventana de estado de la bandeja es un snapshot de la sesión planificada tomado al abrirse; no se actualiza y no muestra valores de OMSI en tiempo real
Las páginas en inglés bajo docs/ son la documentación normativa de esta versión. docs/localized/<locale>/ contiene traducciones de las mismas páginas de 0.1.0-beta3 (consulta LOCALIZATION-MANIFEST.md); cuando una traducción difiere del texto en inglés, el texto en inglés y el código son la referencia autorizada. Las páginas históricas y heredadas que allí se enumeran solo están disponibles en inglés.
