One of the things that makes OMSI 2 special is just how much control bus developers have over their vehicles.
Everything from starting the engine to operating the doors, ticket machines and dashboard displays can be controlled through scripts.
It’s also one of the more challenging parts of developing OMX.
More Than Just Running Scripts
At first, supporting OMSI scripts sounds relatively straightforward. Read the files, understand the commands and execute them.
Unfortunately, there’s a lot more happening behind the scenes.
Scripts constantly interact with other parts of the simulator, including vehicle physics, sounds, animations and the environment.
Getting the scripts themselves working is only half the job. The rest of the simulator needs to behave as those scripts expect.
Small Differences, Big Problems
A bus might load perfectly into OMX, with its models, textures and dashboard all looking correct.
But then you try starting the engine, and nothing happens.
The problem might not even be in the engine script. It could be something as small as a variable updating at the wrong time, or another system returning an unexpected value.
These differences can be particularly difficult to identify because every bus approaches things differently.
Something that works perfectly on one vehicle might expose a compatibility issue on another.
Why Compatibility Matters
OMSI has over a decade of community-created buses, many featuring incredibly detailed scripting.
Requiring developers to rewrite those scripts would defeat one of the main goals of OMX.
Instead, we’re working to reproduce the original scripting behaviour as closely as possible, allowing existing vehicles to work without modifications.
It’s a lot of work for something players might never notice.
But that’s exactly the point.
The goal is for your existing OMSI buses to just work.
OMX is a new 64-bit implementation of OMSI 2, currently under active development.
Learn more about OMX and how it differs from OpenOMSI.