This page lists, from the code, everything in OmsiLaunch 0.1.0-beta3 that is UNAVAILABLE, PARTIAL, or an accepted risk, so that users and integrators do not build on behaviour the product does not provide. Each row names the limitation, its stability, why it exists, and where it is documented in detail. The English documentation is normative; localized copies under docs/localized/ are not maintained at the same level and may lag behind (see the last section).
Only Omsi23004_692EBFBF is supported (692EBFBF...6243); the Steam LAA hash 7DAB063D...D759 is allow-listed; its fingerprint and plan were validated with a controlled copy, but gameplay needs a genuine Steam installation (the image is the DRM-protected Steam executable)
LAST_MAP_STATE (/last, WorldMode.LastMapState) is not implemented; no timestamp-based .osn fallback is ever substituted
UNAVAILABLE (BI-006)
Plan diagnostic OL_E_CAPABILITY_UNAVAILABLE
Explicit or system date, time and year (/date, /time, /year, profile new.date/new.time/new.year, DateSpec/TimeSpec/YearSpec) are carried in the spec but make the plan not runnable; the plugin rejects non-Unset modes
Weather preset, ICAO and real-current at start (/weather*, new.weather)
UNAVAILABLE (STATICALLY_PARTIAL, BI-003)
as above
Player vehicle model, repaint, HOF, fleet number, registration at start (/vehicle family, PlayerVehicleSpec) are resolved against the content catalogue but not applied; requesting them makes the plan not runnable; deterministic headless PlayerVehicle assignment is a future extension
Diagnostics flags (/log, /logall, /omsi-logall, /verbose, /trace, /trace-process, /trace-plugin, /trace-native) populate DiagnosticsSpec; the visible effect is limited to the host trace under .omsilaunch\diagnostics
Session stop is a forced termination: session.stop, tray "End session", Ctrl+C and CloseAsync all lead to TerminateProcess. OMSI's shutdown routine does not run, OMSI does not rewrite options.cfg or its logs on exit, and any unsaved OMSI state is lost. This is deliberate: it keeps OMSI from writing over restored files.
Installation lease is a Local\ semaphore: one owner per installation per logon session; not enforced across users; not released while another process holds a handle; any same-user process can hold the name
Recovery is refused (OL_E_INSTALLATION_BUSY) while the journaled OMSI process, or for a journal without PID any Omsi.exe from that root, is running
by design
as above
An originally-absent overlay path whose content changed during the session blocks restore (OL_E_RECOVERY_ABSENT_OWNERSHIP_MISMATCH) until inspected
by design
as above
Journals from before ownership fingerprints can only be closed by a session with identical planned bytes (OL_E_RECOVERY_ABSENT_OWNERSHIP_UNVERIFIED)
PARTIAL
as above
Only session-owned paths are restored. OMSI's own writes during a session (options.cfg[last_map] when no setting overlays options.cfg, Texture\standard.ipr, caches, laststn.osn, driver profile, logs) persist, as after a direct OMSI start
Handle fingerprint blind spot: an object of the same class and definition recreated at the same address between two list reads is not detected as stale; natural-removal lifetime (RV-002) has no safe runtime producer and stays offline
Telemetry is a latest-value slot: bursts faster than the host's 100 ms sampling can lose intermediate events (sequence numbers keep identical consecutive events distinct; torn samples are skipped)
D3D device reset was observed at runtime (resetting, restored, generation invalidation); a distinct lost transition was not produced because OMSI's device went straight to DEVICENOTRESET
Bounded list results (the timetable.*.list operations, vehicle.variables.list, vehicle.string-variables.list) return at most the rows that fit the 64 KiB runtime slot; the rest are left out with truncated=true and a smaller returned_count (documentation audit BUG-05). There is no paging in this release
timetable.logs.read, road-vehicles.list, humans.list, vehicle.constants.list and vehicle.curves.list are not bounded: a result larger than the slot fails with OL_E_RUNTIME_RESPONSE_TOO_LARGE (observed for none of them on the tested maps)
The self-reported evidence strings (PublicCapabilityRegistryRuntimeValidation, GetCapabilitiesAsyncEvidenceState) were not updated after the runtime closure round: camera.lock still reads STATICALLY_VALIDATED and runtime.d3d.lifecycle.resetIMPLEMENTED_NOT_RUNTIME_VALIDATED. The runtime validation status page is authoritative
In-process memory reads are check-then-use against a live OMSI; a concurrent OMSI mutation between the check and the read can yield an inconsistent snapshot (OL_E_RUNTIME_OPERATION_FAILED)
Same-user trust model: the named pipe (CurrentUserOnly), the handoff/telemetry/runtime memory mappings and the lease semaphore are accessible to any process of the same Windows user. Such a process can read status, stop the session or execute runtime operations once it has read the session_id.
If another process already owns the pipe name, the owner keeps running without an endpoint (ListenFault), and a second launch may misreport OL_E_SESSION_ALREADY_ACTIVE
Retention keeps the 50 newest sessions; older session-prefixed diagnostics are deleted when a new session starts
by design
as above
JSON output and diagnostics include installation paths (RootPath, asset directories, .itx paths)
by design (local data)
The session-failure dialog of OmsiLaunchW.exe shows the plugin's failure payload (for example {"name":"world.failed",...}) as its message rather than a sentence; the Code: line is correct
The English pages under docs/ are the normative documentation for this release. docs/localized/<locale>/ contains translations of the same 0.1.0-beta3 pages (see LOCALIZATION-MANIFEST.md); where a translation differs from the English text, the English text and the code are authoritative. The historical and legacy pages listed there are available in English only.
