Not OMSI 3 Yet: These Are openOMSI’s Current Problems!

The most important point first: openOMSI already works well enough for maps to load, buses to be driven, services to be started and numerous OMSI contents to be used in principle. The project is therefore much more than a technical demo. At the same time, the current version still explicitly points out that functions may be missing, faulty or change between builds. This classification is important because the project’s ambition is very high: existing OMSI content should continue to run as unchanged as possible. That does not mean that every bus, every map and every mod already works completely error-free today.

How well does openOMSI currently work?

The current state depends heavily on which content you use. Standard content and simpler vehicles can already run significantly more smoothly than complex community buses with many custom scripts, dynamic materials, special displays or unusual functions. Current feedback shows, for example, that some buses load but have texture errors or do not execute certain functions correctly. Materials can also still look wrong in advanced rendering modes and, for example, appear excessively shiny.

This is particularly relevant in OMSI because a bus consists of much more than just a 3D model and a few textures. Doors, gearbox, engine, lighting, matrix, IBIS, displays, sounds, animations, variables and passenger functions are partly tied to extensive scripts. openOMSI has to reinterpret all these systems while still reproducing the original’s behavior as accurately as possible. A vehicle can therefore be visibly present on the map and drivable while individual functions are still not working correctly in the background.

Which OMSI buses still do not work properly?

There is currently no blanket list of all functioning and non-functioning vehicles. Given the size of the OMSI modding world, that would hardly work anyway. However, current tests continue to show examples where vehicles have texture problems, certain horns do not work or individual vehicle states are not displayed completely correctly. Dynamic materials and textures also remain a sensitive topic.

This particularly affects buses that rely heavily on custom script textures or special display methods. In OMSI, matrix displays, passenger information and screens in particular are often not simply static images, but are generated and changed during the simulation. If the new engine does not yet fully reproduce precisely this behavior, a bus can load in principle while individual displays nevertheless remain incorrect.

Why do scripts cause openOMSI so much work?

The greatest challenge lies less in reading an OMSI file than in reproducing its behavior exactly. Many community buses use scripts, special solutions and sometimes unusual tricks that have developed over the years to implement functions OMSI originally never anticipated. openOMSI has to interpret this logic so that the bus behaves as similarly as possible to the original.

This also includes small things that you barely consciously notice during normal gameplay. A door button can be linked to a specific variable, a display can require several textures, an engine can react to various script values and passengers can expect certain states before boarding. If just one part of this chain behaves differently, the vehicle may function in principle but still visibly differ from its behavior in OMSI 2.

That is precisely why “100 percent mod compatibility” in the project is above all a development goal and not a description of its current state. In the long term, openOMSI wants existing content to be usable without modifications. Until then, special cases will continue to be discovered, reported and corrected piece by piece.

Do all OMSI maps already work?

The same applies to maps: loading does not automatically mean that everything works correctly. An OMSI map consists of much more than roads and buildings. Splines, intersections, scenery objects, terrain, traffic lights, timetables, AI traffic, HOF files and dynamic textures all have to work together.

For example, there are still problems with scenery objects whose texture is changed during operation. Such functions are used, among other things, for bus stop signs, advertising surfaces or other dynamic elements. If openOMSI displays only the standard texture there, the map may load completely, but certain details will remain incorrect.

The situation is similar with AI traffic and destination displays. There are still open cases in which individual systems do not yet produce the same result as classic OMSI 2. Especially on large community maps with many custom objects, Chrono states and add-on packages, the likelihood of encountering such special cases increases.

Passengers and everyday systems are not finished either

Not all current problems concern graphics. Tests also show cases, for example, in which passengers try to board even though no route or destination has yet been set. Such errors may seem minor, but they demonstrate quite well how many interdependent systems openOMSI has to reproduce correctly.

Real-time synchronization is also not currently reliable in every situation. In addition, there are occasional crashes or graphics errors, such as when the graphics unit loses the available memory. Such cases do not automatically mean that openOMSI is fundamentally unstable, but they do show that the engine is still under intensive development.

How compatible is openOMSI with mods?

The goal remains very ambitious: existing maps, buses, scenery objects and mods should generally work without conversion. The technical foundation for this is already in place, and many contents can indeed be started. At the same time, actual compatibility currently depends heavily on the individual mod.

A simple bus with classic OMSI functions can run much more smoothly than a highly complex vehicle with its own plugins, unusual script solutions and numerous dynamic displays. The same applies to maps. A small map with standard objects places different demands on the system than a large project with hundreds of additional objects and special functions.

For this reason, openOMSI should not currently be judged by whether any one favorite bus already runs completely perfectly. What matters more is how quickly such special cases are found and fixed, and whether compatibility continues to grow with every new version.

When can openOMSI really replace OMSI 2?

There is currently no reliable date. openOMSI is developing quickly, but a complete OMSI 2 replacement requires many different types of content to work reliably. The openness of the OMSI community in particular makes this goal laborious, because countless individual solutions have emerged over many years.

For some players, openOMSI may therefore already be interesting today, for example for testing certain maps, for Android, multiplayer or simply because of the new technical foundation. Those who, on the other hand, own a large personal collection with numerous complex add-ons and expect every bus and every map to run exactly as in the original should still expect problems for now.

That is precisely why openOMSI is currently neither “finished OMSI 3” nor merely a technical gimmick. It is a functioning, rapidly growing alternative runtime environment that can already do a great deal, but has not yet fully achieved its own compatibility ambitions.

Which function would have to work absolutely reliably in openOMSI before you would leave OMSI 2 aside more often in favor of it?