openOMSI is a 64-bit Rust engine that plays the content you already own

No content of its own, and that is the point

openOMSI is a from scratch recreation of the bus simulator OMSI 2, written in Rust, and it loads the existing OMSI 2 maps, buses, scenery and mods as they are. The README states the constraint in a highlighted note that anyone evaluating the project has to accept first: it needs an installed copy of OMSI 2, contains no game content of its own, plays on the maps, vehicles and other files of your own installation, and will not start without one. The payload is therefore your legally owned Steam or retail copy with its stock content, and the promise is that the content loads the way OMSI 2.2.032 loads it, with the OMSI 2 folder never written to. The list of what works is long and specific: maps, buses, AI traffic, scenery, scripts, timetables, HOF files, weather and plugins. For a player with a large mod collection this is the difference between a rebuild and a reimplementation, and it is the reason the project is credible rather than a demo.

A 64-bit engine and four graphics modes

What changes is the engine under the content. The README describes it as 64-bit with no 2GB limit, with tiles and textures loaded on worker threads, and a modern renderer using Metal, Vulkan and DirectX 12 through wgpu. The graphics modes are the interesting choice because they are a range rather than a single setting, running from a Vanilla mode that looks like OMSI 2 to an Enhanced+ mode with physically based lighting, ray traced shadows and reflections. For a simulator with a large map and a lot of scenery, loading tiles and textures on worker threads is what keeps the frame rate honest, and the 64-bit move removes a ceiling that people hit in the original. The trade-off is that your hardware decides which mode is usable, and the read on the modes is that Vanilla exists so that a machine that cannot run ray traced reflections still gets a faithful reproduction. The renderer is also what makes the VR support on Windows through OpenXR possible, and what makes the platform list, Windows, macOS, Linux and Android, credible.

The launcher replaces the old interface

A rewrite of this scale is usually as much about the shell around the game as the game itself, and openOMSI spends a paragraph on the launcher. You pick a map, a line, a tour, a bus and a livery on one screen, with a route map and a live bus preview. Mods come from a folder or from zip, 7z or rar archives, or dropped onto the window, and there is support for keys and for game controllers including wheels, pedals and force feedback, with updates offered on a Stable or a Beta channel. The launcher keeps itself up to date: when a newer version is available it offers it at startup and installs it with your yes, and the settings page under General then has the Updates entry to pick the channel, turn the check off, or install without asking. On Linux the launcher window needs WebKitGTK 4.1, which is a dependency the README spells out per distribution, and it needs a Vulkan or OpenGL driver. That dependency on a web view toolkit for a native game launcher is an unusual choice, and it is the reason the Linux requirements are not just a graphics driver.

Modders get a plugin system and better materials

The modding story is where a rewrite can change what is possible, and the README lists more for modders: PBR materials, larger textures, more lights, and plugins written in Lua or compiled to a byte code that is either Lua or WebAssembly, plus the option to use OMSI's own plugin DLLs on Windows. Supporting a WebAssembly plugin target alongside Lua is a notable step, because it lets a plugin be written in a language with a real compiler toolchain and still load in a sandboxed form, and keeping the original Windows DLL path means existing OMSI plugins do not have to be rewritten to work with the new engine. The rendering side gives plugins more to work with, since physically based materials and a higher light count change what a scene can look like in a way the old engine could not express. The workspace layout shows the plugin system is not a single module, with separate crates for the plugin runtime, a demo plugin, the plugin user interface and a source scanner.

Multiplayer, a dedicated server and a multi platform build matrix

Multiplayer is described as LAN sessions plus a dedicated server, with the server documented separately in the repository under docs. The dedicated server is shipped as its own archive for Linux and Windows on x64 and arm64, separate from the client packages, which tells you the project treats a headless host as a first class deployment rather than an afterthought. The build matrix is unusually wide for a game rewrite: Windows on x64 and arm64 with a setup executable that installs into the user folder without administrator rights, macOS on Apple silicon and Intel with a disk image, Linux on x64 and arm64 as a zip, and Android 8.0 or later as an arm64 package, where the OMSI 2 folder is copied onto the device first. Each release also publishes a SHA256SUMS file listing the checksums of all files, which is a small detail that matters when you are pulling a large archive from a release page. The documentation directory carries separate guides for the server, for VR, for Android and for users, and the site directory and the launcher directory are part of the same tree.

Forty Rust crates, one workspace, and a licence to think about

The Cargo workspace in the repository root lists the whole architecture, and it is a good map for a reader who wants to know where a particular feature lives. The members cover configuration, scripting, the O3D model format, vehicles, maps, a map drawing module, the navigator, timetables, content, textures, geometry, rendering, simulation, the HTML engine, audio, networking, the plugin system and its user interface, the UI, launcher core, API and model, admin, LAN play, platform abstraction, input, XR, weather, career mode, a soundscape module, the world, the scene, photo mode, multithreading, the app, a source scanner and a check tool, with the launcher's Tauri front end excluded from the workspace.

    "crates/omsi-cfg",
    "crates/omsi-script",
    "crates/omsi-o3d",
    "crates/omsi-model",
    "crates/omsi-scenery",
    "crates/omsi-map",
    "crates/omsi-mapdraw",
    "crates/omsi-navigator",
    "crates/omsi-vehicle",
    "crates/omsi-timetable",
    "crates/omsi-content",
    "crates/omsi-texture",

The dependencies are the modern Rust stack, with thiserror for errors, glam for maths, rayon for parallelism, hashbrown and smallvec for collections, parking_lot for locking, arc-swap for the world snapshot the simulation reads without a lock, clap for the command line, and wgpu for the renderer. The licence is AGPL-3.0-only, and for a project with a dedicated server and multiplayer networking that is a decision with consequences, since the copyleft reaches the network use case. The repository also carries governance, security, trademark and contribution files, and a TRADEMARKS file is a good sign for a project that reuses a commercial game's name and assets.

Early development, with the caveats stated up front

The README opens with a warning that this is early development, that bugs should be expected, that things may be missing, broken or change between versions, and that problems should be reported in the issue tracker or on the Discord server. That framing matters when reading the rest of the document, because a lot of what is listed is a plan rather than a finished feature. The release history is one indicator of the pace: 0.3.39 was published on 2026-10-20, 0.3.38 on 2026-10-18 and 0.3.37 on 2026-10-18, so this is a project shipping several builds a week. The workspace package version in the manifest reads 0.1.0, which is a detail of the internal build rather than the release number. Stable builds are on the latest release page and the website, and newer untested builds are published as pre-releases on the releases page, with the launcher offering both through its update channel setting. For a player, the practical advice is to try the beta channel and report what breaks, and for a reader considering the code, the AGPL licence and the early warning are the two things to weigh before investing time.

Editorial conclusion

openOMSI suits a bus simulation fan who owns OMSI 2, wants a 64-bit engine without the old memory ceiling, and wants to run maps and mods on Linux, macOS, Android or in a VR headset. It is the wrong tool for anyone without a copy of OMSI 2, since the project contains no content of its own and will not start without an installed game, and the wrong choice if you cannot accept the AGPL-3.0 licence, which obliges you to offer modified source to users of a networked build. Verify three things before you commit: which release channel you want, since pre-release beta builds are published alongside the stable ones and the README warns that things may change between versions, that your platform has the runtime dependencies openOMSI needs, in particular a Vulkan or OpenGL driver and WebKitGTK 4.1 on Linux, and whether the OMSI 2 installation stays untouched, which the README states it does. The newest release is 0.3.39 from 2026-10-20.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. openOMSI-org/openOMSI on GitHub
3. Project website
4. README
5. Releases