OMSI 2 is still being played more than a decade after its release. The community keeps making buses and maps, but the game running them is still a 32-bit application from 2013.
That’s why several projects are working on new engines for OMSI content. The names can get confusing: OMX, openOMSI, neoOMSI and openOMSI Sobol3D Edition aren’t four unrelated games.
Here’s where each comes from, what you can actually use, and why we’re taking the approach we are with OMX.
Why replace OMSI 2 at all?
The original simulator does a lot well. Its scripting system is a big reason detailed buses can behave so differently from one another, and the catalogue of community content is difficult to replace.
But OMSI 2 has engine-level problems that settings alone can’t fix. It runs as a 32-bit process, so memory is limited. Busy maps can also stutter or suffer from long pauses while content loads. A new PC doesn’t automatically solve that.
The 4 GB patch can help with memory-related crashes, but it doesn’t make OMSI 64-bit or fix slow simulation code. We’ve also covered what actually helps with low FPS and stuttering.
A replacement engine can address those limits. The hard part is making it run the content people already own without changing how that content behaves.
OMX: rebuilding OMSI without changing what OMSI is
OMX is a separate implementation of OMSI 2, written from scratch in C#. It is not based on openOMSI’s code.
Our aim isn’t to turn OMSI into a different-looking bus simulator. We want the same buses, the same maps and the same behaviour, running on a 64-bit engine that isn’t held back by the original application’s limits.
That changes how we approach development. It’s easy to make a bus appear to drive correctly in a video. It’s much harder to reproduce the systems behind it: scripts, physics, AI traffic, timetables, passengers, scenery and the small details that add-on creators depend on.
When something behaves differently, we investigate how the original game handles it rather than designing an approximation that happens to look right. The point isn’t just to load an OMSI file. It’s to interpret it the way OMSI expects.
OMX currently runs on Windows and Linux. Map loading, vehicle scripts, AI traffic and other simulation systems are implemented, though work continues on accuracy and bugs. Dedicated-server multiplayer is also being tested, with plans for client and server modding.
OMX beta access is available through reaction roles in the OMX Discord. We aren’t claiming that every bus or map works perfectly today. You can follow the work on our development page.
openOMSI: a separate engine with public builds
openOMSI is another independent OMSI 2 reimplementation, written in Rust. Like OMX, it is 64-bit, needs an existing OMSI 2 installation, and aims to run original content.
It has public releases for Windows, Linux and macOS, as well as other platforms. Its renderer offers a vanilla-looking mode and optional enhanced graphics. It also has multiplayer and plugin features.
That makes openOMSI easier to try right now: you can download a release rather than wait for beta access. Its own documentation also makes clear that development is ongoing and some things may be broken.
So this isn’t a case of one project caring about OMSI behaviour and the other ignoring it. Both state that accurate behaviour matters. The distinction is in the codebases, the development choices and what is currently available.
For a closer comparison, see OMX vs openOMSI.
neoOMSI: originally based on openOMSI
neoOMSI began from an earlier version of openOMSI’s code and is now developed separately. It’s a branch of that family of engines, not a third unrelated reimplementation.
Its stated focus is on checking behaviour against the original OMSI 2 and improving the engine over time. It has its own website, development process and builds.
One detail worth checking if source-code access matters to you: although neoOMSI originated from publicly available openOMSI code, its current GitHub README says the current game source is private.
As with the other projects, its aims shouldn’t be confused with proof that every OMSI add-on works correctly. That needs testing with real content.
openOMSI Sobol3D Edition: a fork with its own changes
openOMSI Sobol3D Edition is a fork of openOMSI maintained separately by Sobol3D.
It builds on that codebase and makes its own changes. Recent releases describe additions to developer tools, lighting, passenger behaviour and vehicle-related systems, alongside bug fixes.
Unlike the main openOMSI project, its README currently lists downloadable Windows x64 builds; other platforms are built from source. It also uses manual updates rather than an automatic updater.
If those particular changes interest you, it’s worth looking at the project’s release notes. Just remember that fixes or features in one fork don’t necessarily exist in the main openOMSI release or in neoOMSI.
Why we’re choosing OMX’s approach
The case for OMX isn’t that it has the longest feature list today. It doesn’t have a public release yet, and we won’t pretend that closed-beta results are a fair benchmark against software anyone can download.
It’s about what we want the finished game to be.
OMX is for people who want OMSI 2 to stay OMSI 2. We’re not asking map and bus creators to rebuild their work for a new simulator, and we’re not making improved graphics the point of the project. The familiar appearance is intentional.
We’re also not working from an openOMSI fork. That means OMX’s scripting, simulation, rendering and networking systems can be developed around our own decisions about reproducing OMSI, rather than inheriting another project’s implementation. Independence doesn’t automatically mean better results, but it’s an important difference.
The 64-bit engine and native Linux support address two practical limitations of the original. Dedicated-server multiplayer is being developed as part of OMX rather than as a separate modification to the old OMSI executable. And when an add-on reveals a problem, the goal is to fix the underlying behaviour, not require a special converted version of that add-on.
That’s why we think OMX is the better long-term fit for players who want the original OMSI experience without the original engine’s restrictions. It’s the direction we’re working towards, not a claim that we’ve already beaten every alternative in performance or compatibility.
Which OMSI 2 alternative should you try?
If you want to drive a bus today with the most predictable support for existing add-ons, the original OMSI 2 is still the reference point.
If you want a new engine you can download now, try openOMSI. neoOMSI and Sobol3D Edition are separate offshoots worth comparing if their particular changes interest you.
If what you’re waiting for is an OMSI-first replacement that keeps the original look and behaviour while changing the engine underneath, that’s what we’re building with OMX.
OMX beta access is available via reaction roles in the OMX Discord. You can read what OMX is and check beta availability for details.