Playing OMSI 2 together: This is how multiplayer works in openOMSI!

The original OMSI 2 has no integrated classic multiplayer. openOMSI takes a fundamentally different approach here and develops networking directly as part of the new engine. This means that several players can, in principle, use the same map within a shared session and see the other players’ vehicles in the same world. The current focus is on LAN sessions or directly connected multiplayer sessions rather than on a finished public server browser with hundreds of open community servers.

For shared journeys, players must still own the required content themselves. openOMSI does not automatically distribute maps, vehicles or paid DLCs to other participants. If the host uses, for example, a map from their regular OMSI 2 installation, that map must also be present for the other players. When joining, openOMSI detects which map the host is using, switches to it and points out if it is missing from the user’s own system. This is particularly important for the enormous OMSI modding scene, because otherwise multiplayer would quickly become a licensing and compatibility problem.

How does multiplayer work in openOMSI?

Multiplayer does not simply synchronize a point on the map. Other players must be displayed within the same simulation with their vehicle position, speed and various vehicle states. With OMSI in particular, this is considerably more complicated than in a simple driving game because a bus consists of numerous scripted states. Doors, lighting, wheels, displays and other functions must be transmitted so that the vehicle appears as plausible as possible to the other participants.

openOMSI already has its own networking logic for this. At the same time, technical limitations still apply. In a LAN session, for example, only a limited number of certain states are transmitted for other vehicles. The currently documented figures include up to seven doors, 15 wheels and 127 lights per vehicle. This is sufficient for normal city buses in many cases, but it makes it quite clear that multiplayer is not yet a magical, complete copy of every conceivable OMSI vehicle state.

Details like these are particularly important in OMSI. A community bus can have its own scripts for doors, the matrix, lighting, passenger information or unusual special functions. For two players to really see the same behavior, theoretically a great deal of this would have to be synchronized. openOMSI therefore does not simply try to place a multiplayer camera over the old OMSI, but instead builds the networking functions directly into the new simulation.

What is an openOMSI Dedicated Server?

In addition to the regular game, openOMSI already provides a Dedicated Server . This is a separate server version that can host a session without a complete game window or normal graphical display. The server therefore does not have to run simultaneously as a driver’s station, but takes care of the shared session and the necessary world state.

There are now separate server builds for various systems. This approach is particularly interesting for larger groups in the long term, because one player does not always have to keep their regular game client running permanently as the host.

The Dedicated Server is nevertheless not a finished “OMSI Online” service with public accounts, automatic add-on distribution and complete operations management. It initially provides the technical foundation on which shared sessions can be hosted.

Can virtual transport companies operate their own OMSI servers?

Technically, the Dedicated Server opens up exactly this possibility. A virtual transport company could, for example, operate its own openOMSI server for shared journeys. Several drivers could then be on the same map, serve routes in parallel or take part in an event together.

However, it is important to clearly distinguish between what the technology makes possible in principle and what openOMSI itself already offers as a finished operations system. Features such as scheduling for entire companies, automatic control centers, dispatcher roles, vehicle allocation or large persistent online operations are not automatically part of the current multiplayer. Such concepts could build on the server technology, but they are not equivalent to the current range of functions.

Community servers in particular would also depend heavily on all participants owning the same content. A public session on Grundorf is comparatively simple. With a large mod map containing numerous object packages, payware dependencies and several community buses, preparation becomes considerably more demanding.

Do all players need the same OMSI mods?

For the map being used, the basic answer is: Yes, the necessary content must be present. openOMSI cannot simply distribute paid or third-party files via a server. The same applies to DLCs and other protected content.

Although the new mod manager helps integrate content separately from the original OMSI installation, it does not automatically resolve every dependency. If a map is missing an object package or a vehicle uses files from another add-on, that dependency remains.

This is precisely why multiplayer in OMSI will probably always rely somewhat more on shared preparation than a game in which every participant owns exactly the same unchangeable content. The openness of the OMSI modding world is both a strength and a challenge.

How far along is multiplayer currently?

Multiplayer is really present, but openOMSI as a whole is still in an early stage of development. The project itself explicitly points out that features may be missing, faulty or change between versions. The same applies to multiplayer as well as vehicle compatibility, rendering and Android.

It is therefore important not to present openOMSI as a finished MMO-like successor to OMSI at this point. Shared sessions and Dedicated Servers already exist, so the technical foundation is in place. At the same time, synchronization is still being developed, and complex vehicles or unusual scripts can continue to create situations that are not transferred perfectly between multiple clients.

For OMSI in particular, however, this is the more interesting approach than a multiplayer mode added on afterward. If networking is directly part of the new engine, future improvements can start exactly where vehicle, world and script states are created. This lays the foundation for shared driving to eventually go considerably deeper than just two bus models rolling alongside each other along the same road.

For the community, this is probably the biggest difference from everyday OMSI up to now. Virtual transport companies have usually had to organize their shared activities outside the game. With openOMSI, at least part of this can take place within the same simulation for the first time.

What would the perfect OMSI multiplayer look like for you: simply driving a route together, a virtual depot with friends or a large community server with many drivers at the same time?