Q: Is openOMSI free and open source?

openOMSI's code is published on GitHub under the GNU AGPL v3 licence (version 3 only; the historical MIT licence notice is kept, and old versions published under the MIT keep their own terms), and the downloadable versions are on the Releases page. The project describes itself as independent, with no ties to the rights holders of OMSI 2. The current README also has links for anyone who wants to support the author with voluntary donations (Buy Me a Coffee and Ko-fi); that is not a charge for the program. Remember that the original OMSI 2, which you need in order to use openOMSI, remains a separate product. Learn more: Official README.

Question 1

What is openOMSI?

Accepted Answer

openOMSI is an independent project that recreates the OMSI 2 bus simulator from scratch. It is written in the Rust language, is 64-bit, uses several processor cores and draws the image with modern graphics APIs (Metal, Vulkan or DirectX 12). The project's stated goal is to work with the maps, buses, sceneries and mods that already exist for OMSI 2. According to the current README, there are versions for Windows, macOS, Linux and Android. For iPhone and iPad, openOMSI is available for testing (Beta) through Apple's official TestFlight, on iOS or iPadOS 18.0 or newer; it is not a final App Store release (iPhone and iPad support entered the code in version 0.2.36, and building with Xcode, for iPhone, iPad and Mac, is still possible). Since version 0.3.0 the project separates Stable versions (the default) and Beta versions (for those who want to test). According to the 0.3.37 notes, the downloads now include, next to the .zip files, a Windows installer (per user, no administrator rights needed) and a disk image (.dmg) for macOS; and, according to the 0.3.40 notes, the launcher on iPhone, iPad and Mac gained the settings and pages that only the desktop launcher had. This Help Centre is a community initiative (Portal OmsiModsBR). It is not the project's official documentation. For the official source, see the GitHub repository (the project was renamed from openOMSI-Project to openOMSI-org; old links usually redirect) and the documentation at openomsi.org. Learn more: Official openOMSI README; Documentation at openomsi.org; Does it replace OMSI 2?.

Question 2

Does openOMSI replace OMSI 2?

Accepted Answer

No. openOMSI does not contain the game: it needs an original OMSI 2 installation on your computer (or phone) to read maps, buses and other files. Without OMSI 2, openOMSI does not start. Think of it as another “engine” that reads the OMSI 2 files. You still need the original OMSI 2, and it keeps working normally, the way it always has. openOMSI does not write to the original installation: the mods you install (through the launcher's Mods page or in the Mods folder next to the program) go into a folder of openOMSI's own, which is checked before the original one. Learn more: Do I need to own OMSI 2?; README: installation.

Question 3

Do I need to own OMSI 2?

Accepted Answer

Yes. The project states that an original copy of OMSI 2 is required (Steam or retail version, any version), with the default content, such as the Grundorf and Berlin-Spandau maps and the buses that come with the game. openOMSI does not distribute any OMSI 2 content. The launcher usually finds the installation by itself (Steam libraries and the usual folders). If openOMSI says it could not find OMSI 2, open the launcher's Setup page, choose the folder where Omsi.exe is located (or Omsi.exe itself) and save; the error message usually says what is missing from the folder you chose. On Steam, the folder is at ...\Steam\steamapps\common\OMSI 2. On Android, the whole OMSI 2 folder has to be copied to the phone first. On iPhone and iPad (Beta through TestFlight) the same applies: copy the files of your original OMSI 2 to the device (through the Files app or Finder, into the openOMSI/OMSI 2 folder) and, in openOMSI, open Mais > Setup and choose the OMSI 2 folder; since 0.3.0 the first launch shows how to copy OMSI 2 and looks for the copy by itself. The launcher was rebuilt in version 0.2.36, so the look and the button names may differ in older or newer builds, but the Setup page is still where you point to the folder. According to the 0.2.39 changelog, the desktop launcher became the only one (the game's own launcher window was removed; if WebView2 is missing on Windows or WebKitGTK on Linux, the game says what is missing instead of opening another launcher) and Setup no longer saves an incomplete OMSI 2 folder over the one that worked. Since 0.3.34 the launcher's left-hand menu is split into groups (in the notes, in English: Play, Content, Options and Help), with Setup under Options; the names in your language may vary. In 0.3.42 Setup also gained the choice of the .openomsi folder (settings, profiles, logs and caches), which can sit on another drive; the default is still ~/.openomsi. What to check: OMSI 2 is installed and already opens normally (on the PC).; The folder chosen in Setup has Omsi.exe, maps and Vehicles.; OMSI 2's default maps and buses are present.; openOMSI is in a folder you can write to (Documents, a games folder or OMSI 2's own folder), not in Program Files: the launcher cannot update itself there. Since 0.3.37 Windows also has a per-user installer, which does not ask for administrator rights.. Learn more: README: installation and Setup.

Question 4

Is openOMSI stable yet?

Accepted Answer

Not yet. The project itself warns, on GitHub, that it is an early release (“Early release. Expect bugs.”) and that features may be missing, fail or change between versions. That does not mean it doesn't work. It means you may run into problems, and an update may improve or worsen something. Version 0.3.0 (Stable) is a stabilisation release: it fixed slowdowns and breakages that came with earlier updates (for example, large maps with a lot of AI traffic run more smoothly again, and the game opens again on older processors without POPCNT), but the early-release warning is still in the README. The most recent Stable (on 26/10/2026) is 0.3.42, from 25/10, preceded by 0.3.37, from 18/10; together they gather what came in Betas 0.3.34 to 0.3.41, with big changes (for example, the graphics modes and quality presets were reorganised, and online play gained a new protocol in 0.3.40, which means updating the game on both sides). Before them, the Stable was 0.3.33, which gathered what came in Betas 0.3.30 to 0.3.32 (rain and video memory performance, lights, OMSI 1 editor maps, safer online play and many smaller fixes) and which carried, in its notes, the same warning (“Early release, expect bugs”); the notes for 0.3.37 and 0.3.42 repeat that warning. If something fails, don't assume it is your fault or your hardware's. Since version 0.2.32 (the changelog describes the feature under 0.2.31, which was never published), the project describes a start-up safeguard: if a version crashes or never gets as far as opening the launcher, openOMSI tries to install a newer version, go back to the previous one or open in safe mode, telling you through message boxes (this does not cover crashes in the middle of a session, and older builds do not have this protection). Learn more: How to follow the changelog; How to report problems (GitHub Issues).

Question 5

Why can updates change the behaviour?

Accepted Answer

Because the project publishes new versions often, and there are behaviour changes between them. The version number has the format MAIOR.MENOR.NÚMERO, for example 0.2.38: the last number goes up with each change (some numbers are never published, such as 0.2.31 and 0.2.35). Up to 0.2.60, every change sent to the main branch (main) produced a version, often several on the same day. Since 0.3.0 (2026-10-14) this has changed: the maintainers start releases by hand, and there are two tracks, Beta (for testers) and Stable (a Beta that has been tested and promoted). In Settings > General > Updates there is an update channel: Stable is the default and Beta is for those who want to test. Beta version numbers (and those of TestFlight builds on iPhone and iPad, which have their own update cycle) may not match those of the Stable version. So something that didn't work may start working, and a tweak may affect something else. That is why answers about features, performance and compatibility can change from one version to another. When an answer in this Help Centre depends on the version, it carries the corresponding tag. If something changed after you updated, check the changelog. The launcher updates itself (it asks at start-up, unless you turned on installing without asking) and, in recent versions, it can download a new version in the background during a session and install it only afterwards. According to the 0.2.39 changelog, the desktop launcher went back to looking for, offering and installing updates, and in the Updates area of the settings (Settings > General > Updates, according to the guide) the Choose a version option lists the published versions and installs the chosen one (an older version stays until you choose the latest again); since 0.2.60/0.3.0 this selector marks Beta versions. When in doubt, prefer the Stable version. On 26/10/2026 the Stable is 0.3.42 (from 25/10), preceded by 0.3.37 (from 18/10), and no Beta is ahead of it; what shows up first in the Beta usually reaches the Stable in a later version (the city-map route launcher, for example, debuted in Beta 0.3.31 and has been in the Stable since 0.3.33; what came in Betas 0.3.34 to 0.3.36 reached the Stable in 0.3.37, and what came in Betas 0.3.38 to 0.3.41 in 0.3.42), and what exists only in a Beta is covered in the Beta FAQ. One example of a change that calls for attention: online play moved to a new protocol in 0.3.40 (LAN 15), and a version with it cannot join a session of an older version, or the other way round; people playing together need to update on both sides. There have been versions with start-up problems, such as 0.2.28 on Windows, fixed in 0.2.29; in that case the broken launcher cannot update itself and you have to download the new version manually. Learn more: How the project numbers versions; Where can I see the changelog?; Published releases.

Question 6

Where can I see the changelog?

Accepted Answer

The changelog (the list of what changed in each version) is in the repository's CHANGELOG.md file (sections run from newest to oldest) and also in the notes of each version on the Releases page, generated from the commits. The texts are in English. The CHANGELOG has an Unreleased section at the top, with fixes not yet published in a Stable version (they may already be in a Beta). Up to 0.2.60 the third number of the version went up with every commit to main, so there could be releases newer than the last section of the CHANGELOG; since 0.3.0 versions are started by hand, and releases marked as pre-releases (*Pre-release*) are Betas. Some numbers are never published at all (0.2.31 and 0.2.35 never came out; what they would have brought arrived with 0.2.32 and 0.2.36); in that case, the release notes and the commit history show the rest. The general documentation (user guide, Android, server, VR) is at openomsi.org. Note: CHANGELOG.md shows the state of the main branch, which may be a few changes ahead of the version you installed. Compare it with your version number. Learn more: CHANGELOG.md on GitHub; Releases on GitHub; How do I find my version?.

Question 7

How do I find out which openOMSI version I have?

Accepted Answer

According to the project documentation, the version appears in the launcher sidebar, on the first line of the log file (game.log, in the .openomsi folder of your user profile; the launcher.log next to it also starts with the version) and when you run openomsi --version on the command line. The name of the downloaded file also includes the version, for example openOMSI-0.3.42-windows-x64.zip (or openOMSI-0.3.42-windows-x64-setup.exe, the Windows installer, which has existed since 0.3.37). Test builds of pull requests have a suffix, such as 0.1.1313-pr1192. Beta and Stable versions use the same number format, and TestFlight builds (iPhone and iPad) have their own numbering and update cycle, which may not match those of the Stable version for Windows, Linux, macOS and Android. When asking for help or reporting a problem, always give the full version number. Note: the new launcher (from 0.2.36) at one point showed the wrong version, 0.1.0; according to the changelog, this was fixed in 0.2.37 and, for macOS and Linux (About window, multiplayer sessions, plugins), in 0.2.38. If the launcher shows 0.1.0, check the name of the downloaded file, game.log or openomsi --version instead. What to check: Look at the launcher sidebar (according to the project documentation; the exact position may have changed in the new launcher).; Or open game.log (on Windows: C:\Users\SEU_USUARIO\.openomsi; on macOS and Linux: ~/.openomsi) and read the first line. Since 0.3.42 the .openomsi folder may have been moved elsewhere on the Setup page; if you cannot find game.log there, check which folder is chosen in Setup.; In Settings > General > Updates you can check whether a newer version is available (Check now option; since 0.2.39 there is also Choose a version, which lists the versions and installs the one you pick). If the screens are named differently in your launcher, look for Updates in Settings. Since 0.2.60/0.3.0 this area also has the update channel (Stable, the default, or Beta).. Learn more: How the project numbers its versions; Published versions.

Question 8

Will my OMSI 2 mods work in openOMSI?

Accepted Answer

The project's goal is to be compatible with existing maps, buses, sceneries and mods, but that is a goal, not a guarantee: the project is still early and each mod can behave differently. Some work well, others have visual or functional problems. Mods with OMSI plugins (.opl + DLL) are loaded by a 32-bit helper program (on macOS and Linux, through Wine), according to the plugin documentation; a plugin that reads the memory of Omsi.exe does not work. The launcher's Mods page installs a folder, .zip, .7z or .rar; since 0.2.22 it has had a list of installed mods, with the option to switch each one off and delete it (I have not confirmed whether the new launcher keeps the list and the options to switch off and delete; the 0.2.39 changelog says the Mods page got back cancelling an installation, the file size check, filters, the content folder and dropping a mod anywhere in the window). Since 0.3.0, on phones the Mods page has its own storage browser, for installing a folder or a .zip, .7z or .rar file (before that, “Add folder” and ZIP did nothing). Since 0.3.32 (Beta; in the Stable since 0.3.33), plugins can see and choose the ticket each passenger buys (reduced fares, passes); without a plugin nothing changes. Maps made with the OMSI 1 editor, such as Great Grundorf 2, have had the whole street network and the starting points since 0.3.31 (Beta; Stable since 0.3.33). Since 0.3.39 (Beta; Stable since 0.3.42), each mod on the Mods page shows which game folders it put files in and how many (for example “Vehicles 1, Fonts 2”); since 0.3.40, the page asks before sharing a map's depot (HOF) files with all buses. In 0.3.42, the Troubleshooting page (in the launcher's Help group) lists problems with the installed content, such as packages waiting for the bus, buses with parts from packages that are not installed, a map HOF that could not be added and installations that failed. According to the 0.3.40 and 0.3.42 notes, existing OMSI 2 trolleybus maps and add-ons run as they are, with openOMSI's own overhead wire for maps that include it; the rule that this depends on each mod still applies. To find out whether a specific map, bus or mod has already been tested, use the Portal OmsiModsBR community compatibility database. It is independent, unofficial and complementary to the project. Learn more: Search for a mod or map; Test a mod.

Question 9

What is this site? Is it from the openOMSI developer?

Accepted Answer

No. This site is the community compatibility database, maintained by Portal OmsiModsBR. It is independent, unofficial and complementary to the project. It is meant for looking up and recording whether a given map, bus or mod works in openOMSI. Problems with openOMSI itself (program errors) should be reported on the project's GitHub Issues (or on the Discord server given in the README). When the game ends with an error, the launcher shows the error with options to copy the report and to report it on GitHub (according to the 0.2.39 changelog, the launcher went back to warning when a game ends with an error or is sent away by the server). On Android, since 0.3.39 (Beta; Stable since 0.3.42), after a crash the next start of the app opens the dialogue with the report and the GitHub buttons. In 0.3.42 the launcher also has the Troubleshooting page (Help group), which helps you find problems in the installed content. This site and the Help Centre do not replace the official documentation. Learn more: Search; openOMSI Issues.

Question 10

Is openOMSI free and open source?

Accepted Answer

openOMSI's code is published on GitHub under the GNU AGPL v3 licence (version 3 only; the historical MIT licence notice is kept, and old versions published under the MIT keep their own terms), and the downloadable versions are on the Releases page. The project describes itself as independent, with no ties to the rights holders of OMSI 2. The current README also has links for anyone who wants to support the author with voluntary donations (Buy Me a Coffee and Ko-fi); that is not a charge for the program.

Remember that the original OMSI 2, which you need in order to use openOMSI, remains a separate product.

Learn more

Official README

Question 11

Which systems are supported?

Accepted Answer

According to the README, the published versions are for Windows (x64 and ARM64), macOS (Apple silicon and Intel), Linux (x64 and ARM64) and Android (arm64, Android 8.0 or newer). There is also a dedicated server for Linux and Windows (x64 and ARM64). In every case you need the original OMSI 2 installed: openOMSI brings no content of its own and does not open without it. Since 0.3.0 there are Stable versions (tested, the default option) and Beta versions (for testers, marked as pre-releases on the Releases page); the numbering of the two may differ. According to the 0.3.37 notes, the releases also include, next to the zips, a Windows installer (-setup.exe, per user, no administrator needed) and a disk image (.dmg) for macOS; on Linux and Android the zip and the APK remain. In the sources consulted, the project does not publish a list of minimum Windows, macOS or Linux versions. iPhone and iPad (iOS/iPadOS 18.0 or newer) have a Beta version for testing through Apple's official TestFlight, which is not listed in the downloads table and is not yet available on the App Store; the implementation entered the source code in 0.2.36, and the TestFlight versions have their own cycle and numbering. See the question about installing on iOS. Building the code with Xcode (docs/APPLE.md) is still possible. Learn more: Downloads (README); How do I install it on iOS?.

Question 12

How do I install it on Windows?

Accepted Answer

1) Install the original OMSI 2 (Steam or retail version) if you do not have it yet, with the factory content (according to the README, the Grundorf and Berlin-Spandau maps and the standard buses). 2) On the Releases page, download the file openOMSI--windows-x64.zip (or openOMSI--windows-arm64.zip, if your PC is ARM); the version marked Latest is the Stable one, and those marked as pre-releases (Pre-release) are Betas for testers (since 0.3.0). 3) Extract it into a folder for it alone, where you have write permission, such as Documents, a games folder or OMSI 2's own folder (in that case, according to the user guide, openOMSI keeps its content in an openOMSI folder inside it and never writes to the game's original folder). Do not use Program Files, because automatic updating cannot work there. 4) Open openomsi.exe. Since 0.3.37 the Releases page also offers an installer (openOMSI--windows-x64-setup.exe, per user and without needing an administrator) as an alternative to the zip; the notes do not describe its steps, so if you prefer the zip, follow the steps above. The first time, Windows SmartScreen may show a warning. According to the README, click More info and then Run anyway. The launcher usually finds OMSI 2 by itself (Steam libraries and the usual folders); if it does not, open Setup, choose the folder that contains Omsi.exe, maps and Vehicles (the folder or Omsi.exe itself will do) and click Save. Then, on the Drive page, choose a bus, a map and a duty and click Start the duty. Since 0.3.37 the Drive page brings everything together on one screen (map, line and tour, route notebook, bus and start button), and the left-hand menu is split into Play, Content, Options and Help; so the design and position of the buttons may differ from those in older tutorials. The launcher has been rebuilt more than once (the 0.2.22 one was withdrawn in 0.2.23, and the 0.2.36 one is the current one) and stays in English unless another language is chosen; so the names and positions of buttons may vary between versions. According to the CHANGELOG, since 0.2.39 the desktop launcher is the only one (the game's own launcher window was removed). If it does not open (or, on a version up to 0.2.38, a different screen appears), see the question about the new launcher. According to the CHANGELOG, 0.2.4x brought the Launcher size setting and Launcher layout: Classic (the step-by-step Drive page), and 0.3.0 made that classic page show the bus's chosen livery again too. According to the 0.3.33 notes (Beta since 0.3.32, Stable since 0.3.33), the launcher gained two smaller sizes, Very small and Smallest, and the desktop launcher now has French. According to the 0.3.37 notes, the layout of the Drive page is chosen in Settings > Launcher layout: Big Map (the default), Control Room, Classic+ and Classic; so the description of Classic as “Drive in steps” applies to the Classic layout, not to the default. According to the 0.3.41 and 0.3.42 notes, Help has a Troubleshooting page (problems with the installed content, with “Scan again”), and 0.3.42 allowed choosing another location for the data folder in Setup (.openomsi folder field). What to check: The downloaded file is from the project's official Releases page.; Everything was extracted (do not open it from inside the zip).; The folder is not in Program Files.; The original OMSI 2 is installed and was found in Setup (the message “The original OMSI 2 was not found” says what is missing from the chosen folder).. Learn more: README: installation; My PC does not open it. What should I check?; The new launcher does not open or a different screen appears.

Question 13

How do I install it on Android?

Accepted Answer

According to the official documentation: 1) download android-arm64.apk from the Releases page and install it (Android asks you to allow installing from this source). 2) Open the app and grant the access to all files permission, which is needed to read OMSI 2's thousands of files. 3) Copy the whole OMSI 2 folder from a PC to the phone, for example to openOMSI/OMSI 2 in internal storage. 4) The app looks for the folder by itself in openOMSI/, in Download/ and at the root of the storage; if it is somewhere else, use Setup > Browse > Use this folder > Save to choose it (the folder browser has found the SD card since 0.2.21). The device must be arm64 with Android 8.0 or newer. See also the question about phone compatibility. On first start, according to ANDROID.md, the app uses lighter graphics defaults (MSAA 2x, no ambient occlusion, a 1024 shadow map, 60 fps and objects up to 900 m), which can be changed on the launcher's Settings page. Current versions (from 0.1.523) create .nomedia files automatically in the content folders and in the OMSI 2 installation, so that the gallery does not list the textures as photos; screenshots go to openOMSI/Screenshots and remain visible. Do not delete those images: they are part of the game. See the question about the gallery. Since 0.2.36, the app has its own launcher for phones (an icon bar, the duty as a list whose rows open full-screen pickers) and the game's internal launcher is no longer created underneath it, which, according to the CHANGELOG, makes the app start faster (0.2.28 had already sped up opening on Android). Button names and positions may change between versions. According to the notes, 0.3.39 began showing the window of the last unexpected close at the next start of the app (with the report and the GitHub buttons), 0.3.40 made the Support package in the settings work on Android (the ZIP goes into the openOMSI storage folder; before, it gave an error) and 0.3.40 and 0.3.42 adjusted the game menu for the phone held upright; all of this is in Stable 0.3.42. What to check: The phone is arm64 and has Android 8.0 or later.; The “Manage all files” permission was granted to the app.; The copied folder contains Omsi.exe, maps and Vehicles (a complete copy from the PC).; There is enough free space for the OMSI 2 folder.; If the app did not find the folder, it was chosen in Setup > Browse > Use this folder and saved with Save.. Learn more: ANDROID.md (official); Does it work on any phone?; How do I install mods on Android?; OMSI textures in the Android gallery.

Question 14

Does it work on any phone?

Accepted Answer

There is no way to guarantee that. The official documentation asks for an arm64 device with Android 8.0 or newer and a GPU with Vulkan 1.1 (if there is none, the app tries OpenGL ES 3). In the public sources consulted there is still no list of compatible devices, and no memory or processor requirements. The project's history contains specific fixes for Mali and Adreno drivers and for the OpenGL ES fallback. For example, the fs_blur shader error on OpenGL devices was fixed starting with 0.1.479: the ambient occlusion pipelines, which OpenGL ES cannot compile, are no longer created on that backend (ambient occlusion remains available on Vulkan). In 0.1.759 the scene shader compiled again on OpenGL and GLES, which fixed black screens and crashes on some Android and Linux devices (that does not mean every OpenGL problem is gone). In 0.1.1098, a crash on a phone long after the shaders had been compiled stopped being automatically blamed on Vulkan, and waiting for the GPU on OpenGL stopped holding the context for seconds (a crash); keep reporting version, GPU, driver, backend and log, because this does not guarantee that every crash has been resolved. In 0.1.1234, OpenGL chips without storage buffers in the vertex shader (some Mali on GLES and the Intel HD 2500, for example) started drawing the scene from textures instead of failing to start; this widens what can open, but it does not promise performance or that every device will work. This shows that the result can vary with GPU, driver and version; so use a current build before concluding that the device is incompatible. 0.2.0 brought new shaders (snow, lamps in fog and street-lamp shadows) that some phone drivers cannot compile, and on those devices the game opened to a black screen; 0.2.1 detects this at startup, opens the GPU again without those three features and draws as before (the snow falls without flakes). If you are on 0.2.0 and see a black screen, update. Other fixes recorded in the CHANGELOG: in 0.1.1502, the black screen on Adreno 6xx, 7xx and 8xx chips is avoided by rebuilding the shader cache; in 0.2.21, devices that cannot read 4-byte storage arrays started reading them from textures, and the shadow pipeline worked again on Xclipse/ANGLE. These are fixes for specific cases, not a guarantee that your device will open it or run it well. Since 0.3.0, when the graphics driver resets the GPU and the game restarts with lower graphics, the game tells you instead of silently getting worse; the launcher also records in the log where it crashed, which helps with reports. The current Android version is ARM64, and the README's downloads table lists only android-arm64.apk: there is no 32-bit build listed. “32-bit” would not be a lightweight version either: the processor architecture does not work as a graphics quality level. Meeting the technical requirements does not guarantee good performance. According to the notes for 0.3.30 to 0.3.33 (Betas, Stable since 0.3.33), there are gains that may help borderline devices: about a fifth less texture memory for the same image, phones keeping their own graphics defaults and a card that runs out of memory no longer losing the whole image; this is not a promise that your device will run it well. According to the 0.3.37 to 0.3.42 notes (Stable), the game gained the Optimise for my PC button (it measures for about a minute during a session and keeps only the lightest options that really bring frames; “Restore my previous settings” goes back), the Low to Ultra quality presets (Low uses the Vanilla mode), lower memory use (0.3.40), rain and snow falling again on OpenGL and ANGLE (0.3.41), and the city map being capped more carefully so as not to exhaust weaker cards (0.3.41). None of this guarantees that your device will run well. Learn more: How do I know if my phone is compatible?; ANDROID.md (official); What kind of computer or phone is most suitable?; CHANGELOG.

Question 15

How do I install mods on Android?

Accepted Answer

According to the official documentation, there are two ways: copy mod folders or .zip, .7z or .rar files to openOMSI/Mods in the phone's storage (they are installed when the launcher opens), or use the launcher's Mods page (Choose a folder for a mod folder, Choose an archive for a compressed file). Only .zip files can also be placed in openOMSI/Archives, where they are used where they sit (in place); .7z and .rar files are always unpacked during installation. On phones, according to the 0.3.0 CHANGELOG, the Mods page got its own storage browser for installing a folder or a .zip, .7z or .rar file; before that, “Add folder” and ZIP did nothing. If those options do not respond in your version, update or copy to openOMSI/Mods. Each mod may work differently in openOMSI. To find out whether one has already been tested, check the community compatibility database. In current versions (from 0.1.523), the content folders and the OMSI 2 installation are automatically protected from gallery indexing (openOMSI creates .nomedia files): you do not need to create anything manually. If textures still show up in the gallery, do not delete them: see the question about the gallery. According to the CHANGELOG, the Mods page began to list each installed mod, with its type, size and date, and to let you switch a mod off, on or delete it after a confirmation (0.2.22 and 0.2.23); in 0.2.27 it began to show the contents of each mod, folder by folder, and what a mod puts in shared folders, such as fonts and textures, began to be recorded as belonging to it. The launcher was rebuilt again in 0.2.36, so check in your version what the page offers. According to the CHANGELOG, 0.2.39 gave the Mods page back cancelling an installation, the file size check, filters, the content folder and the ability to drop a mod anywhere in the window; the CHANGELOG does not say which of these appear in the phone launcher (dropping files, for example, is a computer gesture). Learn more: ANDROID.md (official); Search for a mod; OMSI textures in the Android gallery; Can I install mods as .zip, .7z or .rar?.

Question 16

OMSI textures are showing up in the Android gallery. Can I delete them?

Accepted Answer

DO NOT DELETE THE TEXTURES. The images shown by the gallery may be real files used by OMSI. Deleting them can break maps, buses, objects and repaints. No. Those images are part of OMSI 2, of the maps, buses, objects, repaints and other mods. The gallery is normally showing the very files the game uses, not extra copies. If those images are deleted through the gallery, files that the content needs may be removed, which can leave you with white buses, missing textures and broken maps. From openOMSI 0.1.523, the app itself creates .nomedia files on Android, in the openOMSI content folders and also in the OMSI 2 installation, wherever it is, so the gallery does not list the thousands of textures as photos (that kept phones busy with media scanning). openOMSI does not move, rename or delete content, and it leaves the openOMSI/Screenshots folder out, so the screenshots you take keep showing up in the gallery. Since 0.2.26, according to the CHANGELOG, a photo taken in photo mode goes straight to the gallery on Android: those photos are yours, not game textures. According to the 0.3.34 notes (Beta, Stable since 0.3.37), screenshots on Android also show up in the gallery right away, and the pause menu has the Screenshot row again. If you use an older version, update openOMSI first. If the gallery had already indexed the images, it may take some time, or you may need to restart the device, for it to forget them. Do not delete the images, do not clean out the OMSI folder, do not rename textures and do not reinstall everything as a first step. Older versions / manual workaround. If for some reason you cannot update a build older than 0.1.523, creating an empty file named .nomedia in the OMSI content folders (such as Vehicles, maps, Sceneryobjects, Splines and Texture) prevents indexing: Android ignores the images in the folder where the file sits and in all of its subfolders. Do not put the .nomedia in a folder above openOMSI/Screenshots if you want your screenshots to keep showing up. In current builds you don't need to maintain this manually. What to check: Check your openOMSI version: from 0.1.523 the .nomedia files are created automatically.; Only for old builds: the manual file is named exactly .nomedia (a dot at the start, no extension) and can be empty; one per content folder (for example in Vehicles) already covers everything below it.; You do not need to edit, move, rename or delete any texture.; If the file manager won't let you create a name starting with a dot, create the file on a computer and copy it to the folder.; Images that were already indexed may stay in the gallery for a while: close and reopen the gallery, wait for a new scan or restart the device (it varies by Android version, manufacturer and gallery app).; “Hide album” may hide the images only in the app's screen, without stopping the indexing: it is not a substitute for .nomedia.. Learn more: How do I install it on Android?; How do I install mods on Android?; How can I improve FPS?; My bus or repaint appears with a white texture; How do I update openOMSI?; CHANGELOG (0.1.523, Android); Issue #443 (gallery).

Question 17

My PC won't open openOMSI. What should I check?

Accepted Answer

Start with the basics and work your way up. Don't assume the problem is your equipment: it could be the folder, OMSI 2 not being found, the graphics driver or even a bug in openOMSI itself. Also confirm that you are on a current version: many problems have already been fixed by the project. The official README recommends: if the game closes after a few seconds or “graphics device was lost” appears, update the graphics driver by downloading it straight from the NVIDIA, AMD or Intel website and, on Windows, switch to DirectX 12 in Settings > Graphics > Graphics API (the launcher offers this after a crash like that). On older cards without Vulkan, the README says openOMSI falls back by itself to DirectX 12 and then to OpenGL. According to the 0.1.1234 CHANGELOG, on Windows DirectX 12 is tried first and the Vulkan and OpenGL interfaces only start when it cannot draw, which keeps their loader from breaking startup on notebooks with two GPUs; a card without a DirectX 12 driver draws on its own Vulkan or OpenGL, not on Microsoft's software renderer. Since 0.2.17, Windows also has the ANGLE (DirectX 11) option, for chips whose DirectX 12, Vulkan and OpenGL drivers do not run the game (the user guide mentions Intel HD Graphics 2000 to 4000 and Radeon HD 5000/6000): it is tried last and only if the ANGLE DLLs are next to openomsi.exe; the guide says the Windows package should include them, and that has not been checked in every version. It is neither a requirement nor a promise that those chips will work. Since 0.3.0, openOMSI starts again on older processors without the POPCNT instruction (before, Windows could say “this app can’t run on your PC”, code 0xC000001D); if that appears, update. When the game ends with an error, the launcher shows Copy report and Report on GitHub (0.2.39 gave the desktop launcher back the notice of a game that ends with an error or is sent away by the server). Since 0.2.18, Setup > Export diagnostics (in the 0.3.40 notes the equivalent feature appears as Support package, in Settings; if you cannot find the old name, look for this one) produces a support ZIP (versions, graphics card and driver, graphics settings, controls and the last map and bus, with no folders, names, chat, LAN codes or addresses); nothing is sent, and the folder opens so you can look at the contents before attaching it to a report. Messages from old builds. The error “The code execution cannot proceed because VCRUNTIME140_1.dll was not found” could appear in old versions, on PCs without the Visual C++ Redistributable; since 0.1.476 the required runtime DLLs ship with openomsi.exe (game and dedicated server). If you see that message, update openOMSI before installing anything; if it persists in a current build, treat it as abnormal and collect the report. Likewise, 2 GB cards could lose the graphics device from lack of memory in the first frames: since 0.1.455, cards of up to 4 GB use smaller memory blocks and the texture budget is reduced to what the card can hold. This is not a minimum requirement and does not guarantee performance. According to the 0.3.33 notes, the Video memory setting now limits everything the game keeps on the card (before, it could use gigabytes beyond the set value, and 8 GB cards spilled over into system memory) and a card that runs out of memory no longer loses the whole image; if the game closed or lost the picture from lack of video memory, update. According to the 0.3.41 and 0.3.42 notes, on DirectX 12 and Vulkan the Video memory limit now also counts the empty space the driver is still holding (before, the frame rate could collapse after about half an hour, with the card paging); if that happened to you, update. The Optimise for my PC button (0.3.37) and the quality presets, from Low (Vanilla) to Ultra, help you find lighter options. On Android and Linux with OpenGL or GLES, builds before 0.1.759 could show a black screen or close on some devices: update first (this does not mean every OpenGL problem is gone). The new launcher (0.2.36) needs WebView2 on Windows and WebKitGTK on Linux. Up to 0.2.38, where it could not open, the game's own launcher opened instead; since 0.2.39 that old launcher no longer exists, and the game says why the launcher did not open and where it should be: see the question about the new launcher. Since 0.2.31, a windowless watchdog tries to repair by itself a version that hangs or closes before the launcher (it installs a newer one, goes back to the previous one or opens in safe mode): see the question about the start-up watchdog. Anyone who installed 0.2.28 on Windows needs to download 0.2.29 by hand, because that version's launcher does not open and so cannot update itself. If it still won't open, you can submit an equipment test: Submit my test, choosing that openOMSI could not start. Hardware, version and, if you like, the log help the community understand on which equipment openOMSI opens. What to check: openOMSI is up to date (an already-fixed bug is resolved by updating; see the CHANGELOG).; The original OMSI 2 is installed and was found (Setup page; the message “The original OMSI 2 was not found” says what is missing from the chosen folder).; openOMSI is in a folder with write permission, outside Program Files.; The graphics card driver was updated from the manufacturer's website.; You tried another graphics API in Settings > Graphics > Graphics API (for example DirectX 12).; Does the new launcher open? On Windows it needs WebView2 and on Linux WebKitGTK (see the question about the new launcher).; The launcher's error report, the game.log (in the user's .openomsi folder; since 0.3.42 it may be somewhere else, if someone changed it in Setup > .openomsi folder) or the ZIP from Setup > Export diagnostics can help whoever answers.. Learn more: README: when something goes wrong; The new launcher does not open or a different screen appears; I updated and now it won't open: start-up watchdog and safe mode; Search the Issues for the problem; My mod/map doesn't work: search; Submit my test; CHANGELOG.

Question 18

The new launcher won't open, or a different launcher appears. What should I check?

Accepted Answer

Since 0.2.36 (CHANGELOG), on Windows, macOS and Linux, a normal start of openOMSI opens a new launcher: the duty on a single page, with the bus rotating in a preview drawn by the game itself, plus Multiplayer, Profile, Mods, Settings, Controls, running games and Setup. Since 0.3.37 the Drive page fits on a single screen, with the Big Map (default), Control Room, Classic+ and Classic layouts in Settings > Launcher layout, and the menu is split into Play, Content, Options and Help (0.3.41 put the Troubleshooting page in Help and the Add-ons list in Content); so what you see may differ from the description above. It needs WebView2 on Windows (part of Windows 10 and 11) and WebKitGTK 4.1 on Linux (the libwebkit2gtk-4.1-0 package). From 0.2.36 to 0.2.38, where it could not open, the game's own launcher (the previous one) opened instead, which is why you could see a different screen from the one described in tutorials. Since 0.2.39 (CHANGELOG), that old launcher was removed: the desktop launcher is the only one, and where it is missing or cannot open its window (without WebView2 on Windows, which is offered for installation, or without WebKitGTK on Linux) the game says why and where it should be, instead of opening another launcher. Since 0.2.37, on a Windows without WebView2, the game offers to install it with Microsoft's installer and opens the new launcher once it is installed; in 0.2.36 this did not exist (up to 0.2.38 the offer came from the game's own launcher). The launcher README we consulted still mentions openomsi --launcher and the OMSI_CLASSIC_LAUNCHER=1 variable as a way of opening the game's own launcher on purpose but, as the 0.2.39 CHANGELOG says that window was removed, do not count on it in new versions (we have not confirmed what those commands do now). The project says it uses its own build of Tauri that avoids WebKitGTK's blank window on NVIDIA cards on Linux. Since 0.2.42, the WebView2 installer is offered only when the runtime is really missing (before, any launcher failure in the first two seconds was taken as its absence, and the offer appeared at every start); with the runtime installed, the launcher is tried again with a fresh profile and shows its own error. If the launcher opens but the game does not, see the question about the PC that won't open openOMSI. If a new version broke the whole start-up, see the question about the start-up watchdog. On phones the launcher is a different one, made for Android (and for iPhone and iPad, as in the TestFlight Beta; since 0.2.39 the “Cross-Platform Launcher” option no longer exists on iPhone and iPad, and 0.3.0 brought a first launch that welcomes you and helps find the OMSI 2 copy; according to the 0.3.40 notes, the launcher on iPhone, iPad and Mac gained what it lacked compared with the desktop, such as Depot, Timetable and the key editor). What to check: Windows: is WebView2 installed? It is part of Windows 10 and 11; on a Windows without it, 0.2.37 or newer offers to install it.; Linux: is the libwebkit2gtk-4.1-0 package installed?; Are you on 0.2.38 or earlier and a screen different from the tutorials appeared? It may be the game's own launcher, which also let you choose the duty and start the game; since 0.2.39 this no longer happens (a message appears saying what is missing). The button names may differ from those in tutorials.; The new launcher in 0.2.36 and 0.2.37 could show the wrong version (0.1.0); this was fixed in 0.2.37 and, on macOS and Linux, in 0.2.38. Check the version from the name of the downloaded file when making a report.. Learn more: My PC does not open it. What should I check?; How do I update openOMSI?; Launcher README; CHANGELOG (0.2.36, 0.2.37).

Question 19

I updated openOMSI and now it won't open. What are the start-up watchdog and safe mode?

Accepted Answer

Since 0.2.31, the program's first act is to start a small, windowless watchdog. If the launcher fails, ends with an error or does not draw its first frames within two minutes (it is then closed), the watchdog steps in when that version has never opened on that computer or has failed twice in a row. According to the CHANGELOG and the user guide, it tries, in this order: 1) installing a newer version, if there is one (its program has to open before anything is replaced); 2) going back to the version before the last update, which is kept until the new one has opened successfully once; 3) opening one more time in safe mode (basic graphics, no plugins); 4) showing a message saying what to do. Each step appears in a message box, in the game's language. A version that failed is not installed again on that computer, only a newer one. The project can also list a published version as broken, and it is replaced at the next start even if it opens. A crash in the middle of a session does not count as a broken start and changes nothing. The watchdog keeps its record in ~/.openomsi/guard/ (guard.log, starts.json, bad-versions), and OMSI_NO_GUARD=1 turns it off. On Android, after a start that did not reach the launcher, the app looks for an update at the very next start (the system installer asks you); going back to the previous version is left to the system. Versions before 0.2.31 do not have the watchdog: anyone who installed 0.2.28 on Windows needs to download 0.2.29 by hand, because 0.2.28's launcher does not open and so cannot update itself. This does not guarantee that every broken start will be repaired: if the final message appears, download the latest version from the Releases page and keep the game.log or the ZIP from Setup > Export diagnostics for a report. What to check: Wait for the watchdog's message boxes: it can take a few minutes (up to two minutes of waiting before it acts).; Look at the record in ~/.openomsi/guard/guard.log (on Windows, C:\Users\<você>\.openomsi\guard).; If you are on 0.2.28 on Windows, download 0.2.29 or newer by hand.; When reporting, give the version and attach the game.log or the ZIP from Setup > Export diagnostics (check the contents first).. Learn more: How do I update openOMSI?; My PC does not open it. What should I check?; The new launcher does not open or a different screen appears; Published versions; User guide (project documentation).

Question 20

How do I install on macOS and Linux?

Accepted Answer

macOS: download openOMSI--macos-arm64.zip (Apple silicon) or openOMSI--macos-x64.zip (Intel), extract it and open openOMSI.app. The first time, macOS may refuse an app downloaded from the internet: right-click the app and choose Open (and Open again) or, according to the README, run xattr -dr com.apple.quarantine /caminho/openOMSI.app once. Since 0.3.37 there is also a .dmg disk image, for dragging the app to Applications, next to the zip (the notes do not say whether the first opening still asks for the step above). An app opened straight from the Downloads folder cannot update itself: openOMSI warns you and says what to do. A new openOMSI.app in Applications keeps its content in ~/.openomsi/content, instead of creating the OMSI folders among the applications; content already installed there stays in use (0.1.1223). On the Apple M4, there were Metal shader fixes in 0.2.21 and 0.2.22 (4x MSAA, snow, lamps in fog and street-lamp shadows compile again); if you are on an older version, update. Linux: download openOMSI--linux-x64.zip or openOMSI--linux-arm64.zip, extract it and run ./openomsi (use chmod +x openomsi if it does not start). A Vulkan or OpenGL driver is required (Mesa, for example the mesa-vulkan-drivers package, or the GPU manufacturer's driver) and, for the new launcher (0.2.36), libwebkit2gtk-4.1-0; without it, up to 0.2.38 the game's own launcher opened and, since 0.2.39, the game says what is missing and where it should be (the old launcher was removed). On Linux with OpenGL, builds before 0.1.759 could show a black screen or close on some devices; update. The window size can be chosen in Settings > Graphics > Window size, steering-wheel hats are read (0.1.927) and, under gamescope, the game opens in full screen (0.1.1120); an update on Linux could open the old launcher instead of the current one, which was fixed in 0.1.1028. According to the 0.3.42 notes, the data folder can be changed in Setup > .openomsi folder; on macOS the file that stores that choice sits next to the .app, so that an app update keeps it. For Linux the notes list only the zip (no installer). This is not an announcement of official support for any specific device. In both cases the original OMSI 2 is also required, and the folder must allow writing. Learn more: README: installation; The new launcher does not open or a different screen appears; How do I update openOMSI?.

Question 21

How do I update openOMSI?

Accepted Answer

According to the README, since 0.1.7 the launcher updates itself: when it opens, it looks for the latest version and, if there is one, asks whether you want to download it (Update now); if you accept, the download is checked against the SHA-256 that GitHub lists, the program is replaced and openOMSI restarts. On Android, the update goes through the system installer: the first time, Android asks you to allow openOMSI to install apps and then asks “Do you want to update this app?” (Update replaces it and opens again; Cancel returns to the launcher as “not updated”); the APK has to be signed with the same key as the installed app, which is the case for the releases. Your mods, content and settings are kept. According to the CHANGELOG, 0.2.39 made the desktop launcher check for, offer and install updates again (fixes issue #2309); we cannot say from the sources in which earlier versions this failed, so check whether the notice appears in yours. Since 0.3.0 there are two version channels, chosen in Settings > General > Updates: Stable (the tested ones, the default) and Beta (each new version before it is tested, for testers); the version selector marks the Betas. Releases are now started by hand by the maintainers (a push to main no longer publishes by itself), and a tested Beta can be promoted to Stable; that is why a Beta's numbering may differ. 0.3.33 was published as a normal release (Stable), but its notes say “Early release, expect bugs”; it includes what came in Betas 0.3.30 to 0.3.32. When a Beta is ahead of the Stable, it brings new features that do not yet apply to the Stable: see the Beta FAQ. On the date of this review (26/10/2026), the Stable 0.3.42 (from 25/10) already includes what came in Betas 0.3.34 to 0.3.41, and the notes for 0.3.37 and 0.3.42 carry the same warning “Early release, expect bugs”. In the same area you can turn off the check on opening, install without being asked or check right away (Check now). Since 0.2.39, the Choose a version option, in the Updates area of the settings, lists the published versions and installs the one you choose; an older version stays installed until you choose the latest again (according to the CHANGELOG; the user guide may not describe this yet). Note a change in the online protocol (LAN 15, since 0.3.40): to play in a session or on a server, players and server must be on 0.3.40 or newer, because old and new versions cannot join each other's session; update both sides. If you installed in Program Files (or, on macOS, opened the app straight from the Downloads folder), automatic updating doesn't work: openOMSI tells you what to do; move it to a folder with write permission. The launcher checks for an update again every 30 minutes while it is open and after a game started by it ends. During a session, the game looks for a new version, downloads it in the background and tells you with a card over the browser; it is only installed when the session ends, never during the session. The card can be turned off in “Tell me about a new version during a session”. Since 0.1.1515, updates that failed with “Timeout” on slow or unstable connections are retried, an interrupted download resumes where it stopped and, if the GitHub API does not respond, the version is requested from github.com. If a new version does not open, since 0.2.31 there is the start-up watchdog, which tries to install a newer one or go back to the previous one (see the question about the watchdog). Because the project receives fixes very frequently, problems described in this FAQ may already be solved in a later build: check your version and update before trying other solutions. Learn more: Published versions; README: updating; I updated and now it won't open: start-up watchdog and safe mode; ANDROID.md: updating on Android; CHANGELOG.

Question 22

Will openOMSI come to iOS?

Accepted Answer

It is already out, in testing: openOMSI is available as a Beta for iPhone and iPad through TestFlight, Apple's official testing programme, with the official invitation. It asks for iOS 18.0 or iPadOS 18.0 (or newer) on a compatible device. The implementation entered the source code in 0.2.36 (CHANGELOG), and the repository has docs/APPLE.md, which describes the game on iOS with touch controls and a launcher of its own. According to the 0.3.40 notes, the launcher on iPhone, iPad and Mac gained what it lacked compared with the desktop (the Depot and Timetable pages, the key editor, guided multiplayer invitation and joining, among others). It is still a Beta and not a final App Store release. TestFlight versions have their own update cycle: do not assume the numbering is the same as the Stable version for Windows, Linux, macOS and Android. Performance, content compatibility and stability may vary with the device and the Beta version, and none of this is a guarantee. Building from source with Xcode (docs/APPLE.md) is still possible. For the steps, see the question about how to install on iOS. Learn more: Official Releases (all platforms); docs/APPLE.md (iPhone, iPad and Mac); How do I install it on iOS?.

Question 23

How do I install it on iOS?

Accepted Answer

openOMSI is available for testing on iPhone and iPad as a Beta, through Apple's official TestFlight (iOS 18.0 or iPadOS 18.0, or newer, on a compatible device). It is not a final App Store release. Step by step: 1) install the free TestFlight app from the App Store. 2) Open the official invitation. 3) Accept the invitation and install the openOMSI Beta. 4) Transfer the files of the original OMSI 2 to the device. 5) Open openOMSI, go to More > Setup and select the OMSI 2 folder. openOMSI does not include the OMSI 2 files: you need an original copy of the simulator. The files can be transferred through the Files app or Finder, arranged in the openOMSI/OMSI 2 folder; according to docs/APPLE.md, you can also choose a copy on iCloud Drive or on compatible external storage in Setup. Since 0.3.0, a first launch welcomes you, shows how to copy OMSI 2 and finds the copy by itself. TestFlight versions have their own update cycle, and the numbering may not be that of the Stable version on the other platforms. Performance, content compatibility and stability may vary with the device and the Beta version. Those who know how to compile can also use Xcode 26, Rust and XcodeGen on a Mac (docs/APPLE.md, script scripts/build-apple.sh); that is a path for developers, with no guarantee. Be wary of third-party files or instructions that promise “openOMSI for iOS”: use only the official invitation above or the official Releases page. Learn more: Will openOMSI come to iOS?; docs/APPLE.md (iPhone, iPad and Mac); Official Releases.

Question 24

Are there official minimum requirements?

Accepted Answer

In the public sources consulted (README and documentation), no minimum or recommended hardware requirements have been published (processor, memory, graphics card or disk). What is documented is: having an original OMSI 2 installed; on Android, an arm64 device with Android 8.0+ and a GPU with Vulkan 1.1 (or OpenGL ES 3); on Linux, a Vulkan or OpenGL driver. The desktop launcher (new since 0.2.36) uses WebView2 on Windows (part of Windows 10 and 11) and WebKitGTK 4.1 on Linux; since 0.2.39 it is the only launcher (the game's own launcher window was removed): where it is missing or cannot open its window, the game says why and where it should be, instead of opening an old launcher; and since 0.2.37 the game offers to install WebView2 when it is missing (on Windows). For very old graphics cards, since 0.2.17 there has been a DirectX 11 (ANGLE) option on Windows (details here). For VR, the documentation mentions an active OpenXR runtime and a card with DirectX 12 support (Windows). On iPhone and iPad, openOMSI can be tested as a Beta through Apple's official TestFlight (it requires iOS 18.0 or iPadOS 18.0, on a compatible device; it is not a final App Store release, and the numbering of TestFlight builds has its own cycle and may not match that of the Windows, Linux, macOS and Android versions); the implementation entered the code in 0.2.36, and building with Xcode (docs/APPLE.md) is still possible. Since 0.2.60 / 0.3.0 there are the Stable (the default) and Beta (for testers) channels in Settings > General > Updates; 0.3.0 also started opening again on older processors without the POPCNT feature. Since 0.3.37 there is also an installer for Windows (per user, no administrator rights needed) and a disk image (.dmg) for dragging the app on macOS, next to the zip files. Practical guidance from Portal OmsiModsBR (not an official requirement): computers with less than 8 GB of RAM are treated by the community as extremely not recommended for openOMSI. This figure is not required by the project: it is this portal's practical recommendation, the same one used by the equipment check (hwcheck). That is why any “minimum PC” number you see out there is not official. For your case, the most reliable path is to test it and check other people's reports. On this site, three kinds of information are treated separately: official (confirmed by the openOMSI project), practical guidance from Portal OmsiModsBR (community interpretation and recommendation, never presented as an official requirement) and community data (results of the tests submitted to Compatibility). Learn more: How do I know if my PC is compatible?; Check my equipment (hwcheck); ANDROID.md (official); What kind of computer or phone is most suitable?.

Question 25

What kind of computer or phone is most suitable for openOMSI?

Accepted Answer

Practical guidance from Portal OmsiModsBR. These are not official openOMSI requirements. “Running” and “running well” are different things: a device may open openOMSI and still have inadequate performance. Computer. Very old hardware, especially graphics cards from the generation when DirectX 9 or 10 was the standard, and legacy drivers, may manage to start openOMSI but with inadequate performance. On those computers, the original OMSI 2 may offer a better experience. CPUs and GPUs from that era, especially when they rely on integrated graphics and old drivers, may be well below the practical profile of the modern renderer. In recent versions, old chips that failed to start because of missing OpenGL features (such as the Intel HD 2500) started to open (0.1.1234), which does not mean adequate performance. For chips whose DirectX 12, Vulkan and OpenGL drivers do not run the game (the documentation mentions Intel HD Graphics 2000 to 4000 and Radeon HD 5000/6000), Windows has had a DirectX 11 (ANGLE) option since 0.2.17: it is tried last, after the others, and only works if the ANGLE DLLs (libEGL.dll and libGLESv2.dll) are next to openomsi.exe; without them it is ignored and the log says so. We could not confirm whether every package already includes those DLLs, and running does not mean running well (fixes for this option came out in 0.2.26 and 0.2.28). As a generational reference (not a requirement), cards from the DirectX 11 generation or later tend to be a more suitable starting point, initially with lighter settings. Modern cards with well-supported Vulkan or DirectX 12 and a current driver are the most suitable profile for openOMSI. The processor generation alone does not decide: the graphics card, the driver, graphics support and the observed results all matter. Memory (RAM). According to the practical guidance from Portal OmsiModsBR, less than 8 GB of RAM is considered extremely not recommended; with 8 GB, use calls for caution (large maps and other open programs can exhaust the memory) and 16 GB gives comfortable headroom. This is not an official openOMSI requirement. On computers with integrated graphics, video memory comes out of the system's own RAM, and memory in two modules (dual channel) usually helps. Since 0.3.37, the Optimise for my PC button (Settings > Graphics in the launcher and Options > Graphics in the game) measures your computer for about a minute during a session and tries lighter settings one by one, keeping only those that really bring frames; your settings are saved first and Restore my previous settings brings them back. It is a help, not a guarantee of FPS. According to the 0.3.42 notes, the quality presets run from Low to Ultra and Medium (Vanilla+) is the one the game uses when it starts; weaker equipment can start from Low or Medium. Phone. The current Android version of openOMSI is ARM64, and the public releases consulted have no 32-bit Android build. “32-bit” also does not mean “lightweight version for a weak phone”: the processor architecture does not work as a graphics quality level. Meeting the documented technical requirements (Android 8.0 or newer and Vulkan 1.1, with fallback to OpenGL ES 3) does not guarantee good performance: it is one thing for the app to start and another for the experience to be playable. openOMSI does not necessarily require a top-end phone, but it is software built on modern technologies, and relatively recent devices tend to be more suitable. A very old or very basic device may have inadequate support or little capacity, and a new entry-level phone can also have limitations: the device's year alone does not define performance. On the first start on a phone, the app uses lighter graphics defaults (for example 2x MSAA, no ambient occlusion and 60 FPS), which can be changed in Settings. On iPhone and iPad there is a Beta version through the official TestFlight (iOS or iPadOS 18.0 or newer, on a compatible device): performance, content compatibility and stability may vary with the device and the Beta version. If an old computer runs the original OMSI 2 well, there is no obligation to move to openOMSI: the original remains a valid option. The equipment tests that the community sends to Compatibility will be used to refine this guidance; the project does not publish an official table of graphics card, processor or memory. The equipment check (hwcheck) applies the practical guidance from Portal OmsiModsBR, which is not official. Learn more: Are there official minimum requirements?; Why does my PC run OMSI 2 well but not necessarily openOMSI?; Submit my test.

Question 26

Why does my PC run OMSI 2 well but not necessarily openOMSI?

Accepted Answer

The original OMSI 2 and openOMSI draw the image in different ways. OMSI 2 is a 32-bit program from the DirectX 9 era (general knowledge). openOMSI is 64-bit and uses modern graphics APIs, through the wgpu library: Vulkan, DirectX 12 or Metal (per the README). They are different “toolsets”, and each graphics card and each driver behaves differently with each of them. That is why 60 FPS in OMSI 2 does not mean similar performance in openOMSI. Older equipment, integrated graphics or outdated drivers may do fine with the old toolset and struggle more with the modern one (general knowledge). This does not mean openOMSI is worse, or that your equipment is bad: they are different situations, and the project is still at an early stage. If an older computer runs the original OMSI 2 well, there is no obligation to move to openOMSI: the original OMSI 2 remains a valid option. There are also community initiatives aimed at improving the experience and performance of the original OMSI 2. What to check: Update the graphics card driver from the manufacturer's website (NVIDIA, AMD or Intel).; Try another graphics API in Settings > Graphics > Graphics API (Vulkan, DirectX 12 or OpenGL; on Windows, on very old chips, also DirectX 11 (ANGLE), since 0.2.17). The user guide also mentions this option under the name Display, depending on the launcher version.; Try the Vanilla graphics mode (or the Low preset, which uses Vanilla, since 0.3.42) instead of Enhanced.; Compare with a light map before testing a large map.. Learn more: README: technologies used; Is openOMSI lighter than OMSI 2?; How can I improve FPS?; What kind of computer or phone is most suitable?.

Question 27

Is openOMSI lighter than OMSI 2?

Accepted Answer

We cannot say that, nor the opposite: the two simulators have very different graphics and processing architectures, so openOMSI may run better on one computer and worse on another. The project aims to use several processor cores, 64 bits (without the original programme's 2 GB memory limit) and a modern design, but that is a project goal: we found no FPS comparison between openOMSI and OMSI 2 in public sources. The user guide has measurements, but they compare openOMSI with itself across versions, on a Mac with an M4 chip (for example, Berlin-Spandau with traffic, passengers and a storm: from 14 to 69 FPS; and a large map that went from about 8.75 GB to 1.93 GB of memory), and not with OMSI 2. In practice, the result depends on your hardware, the map, the mods and the version. In some cases it may be better, in others worse. So avoid treating it as a rule. Learn more: Does it run better?; Why do results change with hardware?.

Question 28

Does openOMSI run better than OMSI 2?

Accepted Answer

It depends, and there is no universal answer. openOMSI may run better than OMSI 2 on some computers and in some scenarios, because it has a modern architecture that uses several cores and features the original does not, and the project has published several optimisations (idle passengers, indexing of large installations, video memory use, AI hitches and, more recently, reworked AI traffic that ran in fixed 20 ms steps (0.2.28; the AI vehicles' scripts went back to running once per frame in 0.3.0), steadier frames with less work per frame (0.2.36) and a roundabout search 2 to 5 times faster when loading the map (0.2.38)). 0.2.39 moved the whole simulation to a fixed 120 steps per second and reorganised the core to read the map data without locks; as that weighed on frames below 120 FPS, 0.2.44 reduced it to 60 steps per second (at most four per frame) and 0.3.0, a stabilisation release, gave smoothness back to large maps with a lot of traffic (AI scripts, passengers, pedestrians, timetables and weather once per frame). The project cites gains with the simulation on its own thread (OMSI_SIM_THREAD=1, which was an experimental mode, off by default; according to the 0.3.37 notes, it now runs on its own thread by default), but that is not a comparison with OMSI 2. On other hardware, especially old GPUs and legacy drivers, OMSI 2 may perform far better. Versions 0.3.30 to 0.3.33 (Stable) brought further improvements: lighter rain on windows, less processor use with the FPS limiter, less video memory, the end of a small hitch every few seconds with timetable traffic and the Video memory setting. After them, the notes for Stable 0.3.37 cite less CPU and GPU time per frame (a shorter ambient occlusion pre-pass, lighter culling, Enhanced's sky cheaper above 60 FPS and the city at night cheaper); 0.3.40 (Stable in 0.3.42) reduced the game's memory again (by the measure of whoever wrote the note, on a Radeon 680M on Linux, from 1058 to 824 MB on the Grand Paris-Moulon map); and 0.3.41 (likewise) reduced the video card's work in Enhanced by day (27.4 to 13.0 ms per frame on an Apple M4 in clear daylight: it is the measurement of that scene, not a gain to expect on every PC). Performance changes from version to version, and there are open reports of FPS drops in some versions and on some devices. If you want to know about your own case, the best approach is to test on your hardware, on the map you plan to use, and compare with what other people report. Learn more: Performance reports on GitHub; Changelog; How can I improve FPS?.

Question 29

How do I know if my PC is compatible?

Accepted Answer

Since there is no official requirements list, what you can check is: whether you have the original OMSI 2, whether the system is Windows, macOS or Linux (x64 or ARM64), and whether the graphics card supports Vulkan or DirectX 12 (if it doesn't, openOMSI tries another API on its own: according to the user guide, in automatic mode it tries, on Windows, DirectX 12, then Vulkan, OpenGL and, last of all, DirectX 11 (ANGLE, since 0.2.17); on other systems, Vulkan and then OpenGL; since 0.1.1234, a card without a DirectX 12 driver draws on its own Vulkan or OpenGL instead of using Microsoft's software renderer). The safest way is to try it: download the version (Stable is the default and the recommended one for most people; Beta is for testers and may have different version numbers), open it on a light map and see. If it errors, the launcher offers Copy report and Report on GitHub, useful for asking for help; in Setup, Export diagnostics (since 0.2.18) produces a support ZIP with versions, graphics card, driver and graphics settings, with no folders, names, chat or addresses, and nothing is sent: open it and check it before attaching it. Since 0.2.31, if a version hangs or closes before the launcher appears, a windowless watchdog tries to repair the start-up by itself (installing a newer version, going back to the previous one or opening in safe mode), with a message at each step. Recent versions improved behaviour on cards with little VRAM, including 2 GB cards that could previously lose the graphics device from lack of memory in the first frames (0.1.455). This does not establish a minimum requirement and does not guarantee performance. In 0.1.1120, large textures waiting for compression started to upload at half resolution in the meantime, which kept a large articulated bus from exhausting the memory of a 3 GB card during loading: it is a memory-peak optimisation, not a requirement (what fits depends on GPU, driver, backend, map, bus, resolution and settings). Since 0.3.0, openOMSI also starts again on older processors without the POPCNT feature (before, “this app can't run on your PC” appeared). Since 0.3.31 (Beta; in the Stable since 0.3.33), on OpenGL and DirectX 11 a dedicated graphics card keeps the chosen MSAA, shadows and texture memory (before, it could be taken over by a small shared chip), and in 0.3.32 (Stable in 0.3.33) VR headsets that stayed black (PICO Neo3 Link with SteamVR) started to show the game. On iPhone and iPad, the TestFlight Beta requires iOS or iPadOS 18.0 or newer. If the equipment is weak, since 0.3.37 there is the Optimise for my PC button (see the question about the most suitable equipment). To tell a content problem from an equipment problem, the Content test (0.3.37) and, in 0.3.42, the Troubleshooting page (in Help) show what is wrong with the installed content (missing bus parts, packages waiting for the bus, failed installations). According to the 0.3.40 notes, the support package also appears as Settings > Support package and works on Android. Equipment reports help improve the community's guidance: Submit my test, including if openOMSI never got to open. For an automatic check, use the equipment check (hwcheck): it applies the practical guidance from Portal OmsiModsBR, including the 8 GB RAM cut-off, which is not an official requirement. What to check: The original OMSI 2 is installed.; The graphics card driver is up to date (manufacturer's website).; Your system is one of the published platforms (Windows, macOS, Linux).; On Windows, WebView2 is installed (the desktop launcher needs it; Windows 10 and 11 already include it, and since 0.2.37 the game offers to install it). On Linux, libwebkit2gtk-4.1-0. Without that, since 0.2.39, the game says why and where the launcher should be (it no longer opens a launcher of its own in its place).; You tested first with a standard map, such as Grundorf.. Learn more: My PC won't open. What should I check?; Are there official requirements?; What kind of computer or phone is most suitable?; Submit my test.

Question 30

openOMSI opens on my PC. Does that mean it is compatible?

Accepted Answer

Not necessarily. These are different things: technical compatibility (the system and the graphics card are supported), being able to start, having a playable experience and performance on specific content (a map and a bus). Opening the launcher does not prove that a large map loads, that the FPS is good or that a specific bus works.

On old hardware, opening may be only the beginning: recent versions can start on chips that used to fail (for example, with the DirectX 11 (ANGLE) option on Windows, since 0.2.17), and that does not prove the game becomes playable. Test from simple to complex: a light map, then the map and the bus you want. If something fails, record the equipment, version and backend (Vulkan, DirectX 12 or OpenGL); this helps the community. There is no official requirements table, and the original OMSI 2 remains a valid option if it runs well for you.

What to check

Did the launcher open? Did a session open? Did you actually drive?
Is the FPS on your map and your bus acceptable?
Are the graphics card driver and openOMSI up to date?

Learn more

Question 31

How do I know if my phone is compatible?

Accepted Answer

According to the official documentation, the phone must be arm64, have Android 8.0 or newer and a GPU with Vulkan 1.1 (if there is none, the app tries OpenGL ES 3). In the public sources consulted there is no device list and no memory or processor requirements. For iPhone and iPad, openOMSI is in Beta through Apple's official TestFlight (it requires iOS or iPadOS 18.0 or newer, on a compatible device; it is not a final App Store release, and performance, content compatibility and stability may vary by device and Beta version). Because the variety of devices is huge, the safe way is to test. If the app closes, the launcher shows, the next time it opens, a report of what happened, with the Copy report option. Equipment reports help improve the community's guidance: Submit my test, including if openOMSI never opened. Recent builds fixed specific OpenGL ES failures and the gallery problem of indexing textures (0.1.523), but that does not create a requirement or a performance guarantee. If the phone became slow right after copying OMSI, also see the question about textures in the gallery. A black screen or a crash on launch on some devices with OpenGL or GLES was addressed in 0.1.759: update before concluding that the device is not suitable. There was also a black screen in place of the game on phones whose graphics driver cannot compile some of the new 0.2 shaders (fixed in 0.2.1, with the game reopening the device without those effects; the snow falls without flakes in that case) and on Adreno 6xx, 7xx and 8xx chips (addressed in 0.1.1502, by rebuilding the shader cache). On the first start on a phone, the app uses lighter graphics defaults (2x MSAA, no ambient occlusion, a 1024 shadow map, 60 FPS and an object distance of 900 m), and below 45 FPS the 3D image is drawn smaller, down to 0.6 of the screen; all of it can be changed in Settings (since 0.3.30, according to the notes, these phone defaults are kept). Since 0.2.36 there is a launcher of its own for phones (an icon bar, full-screen pickers), and the app has opened faster since 0.2.28. In 0.3.0 the phone launcher got its own storage browser on the Mods page (folder, .zip, .7z and .rar). Since 0.3.39 (Stable in 0.3.42), after a crash, the next opening of the app shows the dialogue of the last unexpected close, with the report and the GitHub buttons, which before was lost along with the launcher. According to the 0.3.40 notes, the support package (Settings > Support package) began to work on Android, saved in the openOMSI storage folder, and the launcher on iPhone, iPad and Mac gained the settings and pages it lacked compared with the desktop one (including Optimise for my PC). What to check: An arm64 device with Android 8.0 or higher.; Permission to access all files granted.; The OMSI 2 folder copied in full to the phone.; Enough free space and memory (there is no official number).. Learn more: ANDROID.md (official); How do I install it on Android?; What kind of computer or phone is most suitable?; OMSI textures in the Android gallery; Submit my test.

Question 32

Why does openOMSI take so long to open or load?

Accepted Answer

Several things happen while loading: reading the map and its files, preparing textures and the scene drawing. The bigger the map and the more content it has (more files and textures), the longer it takes, which is expected on large maps. Heavy mods also increase the time (general knowledge). The public sources consulted do not precisely explain the cause of a specific delay. If it hangs while loading a very large map, look for the case in the GitHub Issues and report your version and the content you used. On large OMSI installations, the launcher used to show an empty list for minutes. Since 0.1.850 maps appear immediately and buses appear as the folders are read, with the progress shown in the status line; older builds may look frozen at that moment. On NVIDIA cards without Resizable BAR on Vulkan, loading could take minutes and the game ran at a few FPS; this was fixed in 0.1.1422 (0.1.1423 only changed where the fix lives in the code). Recent versions have also sped up parts of the start: the graphics driver keeps the compiled pipelines between launches on Vulkan and OpenGL, so from the second launch the game usually starts faster (0.2.21); the game window shows the loading screen at once and keeps responding while the shaders are built, and the launcher draws the page from the first frame and loads the 3D preview afterwards (0.2.28); the roundabout search when loading a map became 2 to 5 times faster (0.2.38). If the launcher hangs, closes with an error or does not draw its first frames within two minutes, the 0.2.31 watchdog tries to repair the start-up by itself (newer version, previous version or safe mode) and tells you by message. This is not a guarantee of loading time: it depends on the map, the mods and the equipment. Since 0.3.0, launcher.log also says where the launcher hung, which is useful when reporting the case. According to the notes, 0.3.30 started keeping compressed textures in ~/.openomsi/cache/textures, so that maps and buses load faster from the second opening, and 0.3.31 compiles the shaders on several cores on Vulkan (in a Windows test, the map was ready in 12.9 s instead of 22.4 s on the first opening after an update); both are in the Stable since 0.3.33. According to the 0.3.37 notes, the launcher's route map opens quickly on large maps (the Berlin-Spandau preview in about a second instead of 88 s, by the measure of whoever wrote the note); 0.3.38 (Stable in 0.3.42) went back to decoding the painted ground textures of new areas in the background, with fewer hitches when driving into new regions; and, in 0.3.42, a timetable bus that appeared before it was on the video card (for example, with the clock set far ahead) no longer freezes the frame for 120 to 300 ms. If loading fails because of missing content, the Troubleshooting page (Help, 0.3.42) and the Content test (0.3.37) help you see what is missing. What to check: Wait a little longer the first time you open a large map.; Try a default map to compare.; Check whether the computer has free memory.; If it hangs for good, keep the game.log (in the .openomsi folder of the user profile; the launcher.log is next to it) and, in Setup, use Export diagnostics to produce a support package (0.2.18) that you can check before attaching it.; With ambient sound on (Settings > Sound > Ambience, 0.2.27 onwards), the game downloads about 300 MB of recordings once to .openomsi/ambience on first launch (not on Android, according to the 0.2.27 notes); we have not confirmed that this slows loading, but it is worth knowing if your connection or disk is slow.; On Android, if the problem started right after copying many files or installing mods, the gallery or the media scanner may be indexing thousands of textures (it is not always the cause). Since 0.1.523 openOMSI creates .nomedia automatically to reduce this; on old versions, update before any other step. Do not delete the images.. Learn more: openOMSI Issues; Do mods affect performance?; OMSI textures in the Android gallery.

Question 33

Why do I have high FPS but some feature doesn't work?

Accepted Answer

FPS measures the speed at which the image is drawn, not whether everything in the mod or bus is working. A feature may fail for another reason: openOMSI doesn't support some detail of that mod yet, the mod's script depends on something different, or there is a bug in the program itself. This doesn't mean your hardware is the problem. Check whether the feature has already been reported for that mod or version and, if nobody has reported it, consider reporting it. openOMSI problems go to GitHub Issues (or to the project's Discord, according to the README); the compatibility of a specific mod can be looked up in the community database. When reporting, it helps to give the openOMSI version, the map, the bus, the game.log and, since 0.2.18, the package from Setup > Export diagnostics. People who work with mods can also use the game's development tools (Ctrl+Shift+D, 0.2.28), which show the vehicle's script variables. Since 0.3.37, the Content test (in the 0.3.41 and 0.3.42 notes the same test appears as the Model test tab inside Troubleshooting, in Help) loads any bus, map, mod, file or folder the way the game loads it and lists all the warnings; on the command line, openomsi --check <arquivo ou pasta> [--deep]. The exact names of the screens may vary with the version. What to check: Does the feature work in the original OMSI 2 with the same mod?; Does it work on another bus or a default map in openOMSI?; Is there a newer version of openOMSI?; Has someone already reported the same case in the Issues?. Learn more: Search for the mod in the community database; openOMSI Issues.

Question 34

Do CPU, GPU and RAM affect performance?

Accepted Answer

Yes, all three. The project's documentation says openOMSI uses several processor cores (for example, to decide what to draw and for traffic AI; since 0.2.39 the scripts of map objects run only near the bus and in parallel; according to the 0.3.37 notes, the simulation runs on its own thread by default), so the CPU matters on maps with a lot going on. The GPU and the driver determine drawing quality and speed. RAM (and video card memory) matters on large maps: there are reports of running out of memory in those cases. According to the practical guidance from Portal OmsiModsBR (unofficial), less than 8 GB of RAM is considered extremely not recommended. In general, which one is the limit depends on the map and the settings. Simpler hardware (such as integrated graphics, a phone or a card with little memory) gets a lighter image by default, according to the changelog. Recent versions improved behaviour on cards with little VRAM, including 2 GB cards that could previously lose the graphics device from lack of memory in the first frames (0.1.455). That does not establish a minimum requirement or guarantee performance. In 0.1.1120, large textures waiting for compression began to upload at half resolution in the meantime, which kept a large articulated bus from exhausting the memory of a 3 GB card during loading: this is a peak-memory optimisation, not a requirement (what fits depends on GPU, driver, backend, map, bus, resolution and settings). On texture memory: since 0.3.33 (Stable; before that, only in the Betas) the setting is called Video memory (video_memory, in MB) and covers everything the game keeps on the graphics card (textures, meshes, render targets, shadows and the driver's own memory, as the driver counts it on DirectX 12, Vulkan and Metal), with “Automatic” at nine tenths of the card's memory and options of 8 and 12 GB (and 16 GB for cards of 20 to 24 GB); according to the notes, before that the game could use gigabytes beyond the set value and 8 GB cards started using system memory; the old texture_memory setting is not loaded. Also in 0.3.33, a card that runs out of memory no longer loses the whole image (meshes go to smaller buffers, or only the ones that do not fit are left out), and render targets unused for 5 s are freed. In 0.3.30, the game started using about a fifth less texture memory for the same image (for 2 to 8 GB cards on large maps) and stopped becoming blurry and slow when the card refuses a texture; in 0.3.32, high-quality passengers started to take up a third of the video memory (6 to 8 GB cards ran out within a few minutes). Before 0.3.33 (up to the 0.3.0 Stable), the guide said the limit (texture_memory, in MB) was one eighth of the computer's memory when not defined, that loose textures are compressed on loading and that DXT/BC textures stay compressed on the GPU; turning that last option off (for drivers that draw compressed textures wrongly) makes textures take up about four to eight times more memory. The 2 GB texture ceiling was lowered in 0.1.1502, cards with more than 6 GB get more automatic memory (0.1.1541) and integrated GPUs began to receive the memory the driver reports (0.2.28). If the card loses the graphics device (“graphics device was lost”), the game saves the situation and restarts by itself with lighter graphics, at most twice (0.1.237), and the README suggests updating the driver or switching the API in Settings > Graphics > Graphics API. In 0.2.44, a frame drop after about half an hour of driving on 8 GB cards (from 140 to 25 FPS) was fixed. Since 0.2.38 the performance panel (Settings > Interface) helps you see what limits the FPS in your case. Since 0.3.0, when the driver resets the card and the game comes back with lighter graphics, it tells you so. According to the 0.3.37 notes, textures can now take up to half of the video memory on a card with its own memory (about 3.7 GB on an 8 GB card on Automatic, instead of 2 GB), so that they stay sharp. In 0.3.40, the game went back to using much less memory (the browser map stopped keeping the ground twice: from 1058 to 824 MB on Grand Paris-Moulon, on a Radeon 680M on Linux, by the measure of the note). 0.3.41, Stable in 0.3.42, deals with an FPS drop after about half an hour on DirectX 12 and Vulkan: the free space that the allocator keeps in large blocks was outside the Video memory limit and the card ended up paging (on a 12 GB card set to 6 GB, the driver held as much as 11.5 GB after 18 minutes, at 10 FPS); now that space counts against the limit. The 0.3.41 notes caution that the setting is not a hard ceiling when the textures are already at the smallest size and that long tests were still needed, so we do not treat this as a guarantee. Learn more: User guide: performance and settings; How can I improve FPS?.

Question 35

Do mods affect performance?

Accepted Answer

Yes, they can. Large maps with many objects, heavy textures or lots of curves and detail tend to demand more from the processor, the graphics card and memory. This also applies to the original OMSI 2 (general knowledge). The project's documentation shows that very busy maps have already required optimisation work. According to the 0.3.42 notes, AI cars and buses are now drawn with the model's own lower levels of detail ([LOD]), which can ease maps with a lot of traffic; models with interior lamps, screens or animated parts keep their full meshes. There is no official table of which mods are heavier. For a specific mod, check the community reports. Learn more: Search for a mod or map; Why does it take a long time to open?.

Question 36

How do I improve FPS?

Accepted Answer

The launcher's Settings page groups the options into tabs: since 0.1.486 there are six (Graphics, Driving, Camera, Sound, Gameplay and General, on the phone too), and the user guide still describes them that way; the new launcher in 0.2.36 was rebuilt and the 0.2.38 notes also mention a place called Interface, so the exact names may vary with the version (0.3.42 mentions, for example, a new tab called AI Lists). The options that most affect performance are in Graphics: graphics mode (Vanilla is the classic look; Enhanced is the heavier renderer. Since 0.3.42, Enhanced+ is no longer a mode: it is Enhanced with Real-Time Ray Tracing turned on (ray_tracing=1; a file with graphics=enhanced_plus is read that way), which since 0.1.1551 is heavier still: it uses hardware ray tracing on RTX, RDNA 2 and Apple M3/M4 cards or newer and, on any other card, draws like Enhanced; if the driver refuses ray tracing, it falls back to Enhanced instead of crashing), MSAA, shadows, SSAO/ambient occlusion, render scale, view distance, mirrors, rain quality (Rain quality: High, Medium or Low, since 0.2.24; rain is expensive to draw, and Low uses OMSI 2's own texture-based rain on the glass, without splashes), cloud quality (Cloud quality: Low uses fewer steps in Enhanced's clouds, since 0.2.18) and graphics API. Lowering these options usually eases FPS. Since 0.3.42 Enhanced has options of its own that cost performance and can be turned off one by one: Light has shadows (Off, Street lamps and vehicles or Every light), Cloud shadows and light shafts, Glow of lights, Real-Time Reflections (puddles, wet roads and water) and Reflective objects reflect, as well as Street light (Auto, On or Off; off by default, according to the notes) and, since 0.3.41, the optional AMD FSR 1 (experimental) upscaler in Settings > Graphics > Upscaling, whose FPS gain depends on the card and the scene and is not a promise. According to the 0.3.41 notes, Enhanced at night may cost more with the new lamp shadows (79.8 to 71.6 FPS on a Radeon 680M, in Spandau at 22:00). In current versions (from 0.1.523), mirrors can also be turned off in Settings > Graphics > Mirrors: Off, which may help on slower machines; no specific gain is promised. Updating the graphics card driver and openOMSI itself may also help, since performance changes between versions. Effects vary by equipment and map, so try one change at a time. Recent improvements that help on tight hardware: the launcher frees the graphics card while the game runs (0.1.721; “The launcher rests while a game runs” is an option, 0.1.1098), parked cars can be left out (Parked cars: None, 0.1.1098), there is less stutter when AI vehicles appear (0.1.759) and the big FPS drop at busy stops caused by people was fixed (0.1.774; in 0.1.850, people standing still stopped being recalculated every frame). Passengers and traffic still cost performance, so lowering the density in Settings > Gameplay may help (the People at once option, from 50 to 1000, since 0.2.46, limits the number of people). None of this guarantees a specific FPS. Since then: vehicle scripts about a quarter faster and less CPU spent finding the ground under the wheels (0.1.1541), meshes that share buffer pages, with about a third less drawing work on the CPU (0.1.1707), and larger automatic texture memory on cards with more than 6 GB (0.1.1541) and without the 2 GB cap (0.1.1502). There are also quality presets (0.2.18; since 0.3.42 they are Low, Medium, High, Extra, Max and Ultra, and each also picks the mode: Low is Vanilla, Medium is Vanilla+, which is what the game uses when it starts, High to Max are Enhanced with more options switched on at each step and Ultra is Enhanced with ray tracing and everything on), the Optimise for my PC button (0.3.37: you choose an FPS target, the game measures for about a minute during the next session, tries lighter settings one by one and keeps only those that really bring frames; your settings are saved first and Restore my previous settings brings them back; the launcher also warns in the settings when a choice may cost a lot of frames) and, since 0.2.38, a live performance panel (Settings > Interface) that shows where the time of each frame goes and what limits FPS. Also in 0.2.26 the launcher stopped redrawing a still image and the browser began to be drawn every other frame where FPS is low; 0.2.28 brought per-frame work savings (scripts, lights, Enhanced+ ray tracing) and the texture memory of integrated GPUs began to follow what the driver reports; 0.2.36 brought steadier frames (scenery scripts, traffic and people run on the frame thread with workers helping, without waiting) and an FPS limiter with no extra pause on top of V-sync. In 0.2.39 the simulation began to run at a fixed 120 steps per second (the bus and the camera are drawn between two steps, so the steering is the same at 30 or at 144 frames; this is not, by itself, an FPS gain; as it weighed on frames below 120 FPS, 0.2.44 reduced it to 60 steps per second, at most four per frame, and 0.3.0, a stabilisation release, gave smoothness back to large maps with a lot of traffic, running the AI scripts, passengers, pedestrians, timetables and weather once per frame), the scripts of map objects began to run only near the bus and in parallel, and there was an experimental mode, OMSI_SIM_THREAD=1, that puts traffic, passengers and map scripts on a thread of their own (optional in 0.3.34; according to the 0.3.37 notes, the simulation runs on its own thread by default); the changelog cites 0.5 to 1 ms less on the main thread per frame and 6 to 10 % more frames on a busy processor, with no guarantee on your equipment. Three screens (triple screen) and VR cost more: the render scale and, in VR, the per-eye resolution help. The Mirror panels every frame option (Settings > Graphics, off by default, 0.2.31) draws the cab's mirror panels every frame and costs one mirror image per frame, so leave it off if FPS is the problem. Since 0.3.30, rain on the windows is painted on two threads of its own; in 0.3.31 the windows take turns repainting the drops (fewer hitches of about 20 ms on weak PCs) and, in 0.3.33 (Stable), only the rows that changed go to the card (on a Radeon 680M, in a storm, the windows went from 10-12 ms to 2-3 ms per frame, according to the notes). Also since 0.3.33, Enhanced with ray tracing (formerly called Enhanced+) draws MSAA 8x as 4x (the OMSI_FULL_GPU=1 variable keeps 8x). Other performance improvements that reached the Stable in 0.3.33: an FPS limiter (or V-sync off) that uses less processor (0.3.30), compressed textures kept in ~/.openomsi/cache/textures to load faster from the second opening (0.3.30), the end of the small hitch every few seconds with timetable traffic (0.3.31), shaders compiled on several cores on Vulkan (0.3.31) and the new Video memory setting (see the question about CPU, GPU and RAM). In the Stable since 0.3.37 the rain was reworked (about a quarter of a million drops calculated on the video card, and rain and snow stop under roofs, bridges and shelters); the notes do not give the cost of this on your equipment, so test Rain quality if FPS drops in the rain. Other options for saving frames: Vehicle smoke (smoke from all vehicles, only your bus or none, 0.3.39), Mirror panels on the screen (0.3.39, cheaper to draw) and, since 0.3.42, mirror_shadows and mirror_particles (shadows and smoke in the mirrors, both off by default). 0.3.41 also reduced CPU work for traffic out of sight. On a phone, when FPS drops below 45 the 3D image is drawn smaller, down to 0.6 of the screen, as on the computer (ANDROID.md). What to check: Try Vanilla mode.; Lower MSAA, shadows and SSAO (ambient occlusion, where applicable).; Lower the view distance.; Lower the render scale.; Turn mirrors off in Settings > Graphics > Mirrors: Off (0.1.523 or newer).; With rain or snow, lower Settings > Graphics > Rain quality (0.2.24 or newer); with Enhanced, try Cloud quality: Low (0.2.18 or newer).; Try a lighter quality preset (0.2.18 or newer; before 0.3.42 it did not change the mode, and from then on Low is Vanilla, Medium is Vanilla+, High to Max are Enhanced and Ultra is Enhanced with ray tracing).; In Graphics, try the Optimise for my PC button (0.3.37 or newer); Restore my previous settings brings back the earlier settings.; Try another graphics API in Settings > Graphics > Graphics API (Vulkan, DirectX 12, OpenGL; on Windows, DirectX 11 (ANGLE) for very old chips). The user guide also mentions this option under Settings > Display, depending on the launcher.; Update the driver and openOMSI.; On Android, if the problem started right after copying many files or installing mods, the gallery or the media scanner may be indexing thousands of textures: since 0.1.523 openOMSI creates .nomedia automatically to reduce this (on old versions, update first). Do not delete the images.. Learn more: User guide: settings; Why do results change with hardware?; OMSI textures in the Android gallery; CHANGELOG.

Question 37

My graphics card is very old (Intel HD 2000 to 4000, Radeon HD 5000/6000) and openOMSI won't open. Is there a DirectX 11 (ANGLE) option?

Accepted Answer

According to the changelog and the user guide, since 0.2.17 there has been an ANGLE (DirectX 11) graphics API on Windows, designed for chips whose DirectX 12, Vulkan and OpenGL drivers do not run the game; the examples given are Intel HD Graphics 2000 to 4000 and AMD Radeon HD 5000/6000. In automatic mode it is tried last, after the others, and it can also be chosen in Settings > Graphics > Graphics API (the user guide mentions it under Settings > Display, depending on the launcher version). It only works if libEGL.dll and libGLESv2.dll (Google's ANGLE) are next to openomsi.exe; without them the option is skipped and the game.log says so. We could not confirm from the sources consulted which packages already include those DLLs. The option had fixes in 0.2.26 and 0.2.28 (the launcher and the game started drawing again), so on older builds it may fail. Running does not mean running well: chips from that generation usually fall far below what the modern renderer asks for, and the original OMSI 2 may give a better experience on those computers. This is neither a requirement nor a guarantee. According to the 0.3.41 notes (Stable in 0.3.42), rain and snow fall again on OpenGL and ANGLE. What to check: Are you on Windows and on a recent version (0.2.28 or newer)?; Are the libEGL.dll and libGLESv2.dll DLLs in the same folder as openomsi.exe?; Does the game.log (.openomsi folder) list the adapter? With ANGLE active it appears as ANGLE (...Direct3D11...).; Is the card's driver up to date from the manufacturer (Intel, AMD)?. Learn more: What kind of computer or phone is most suitable?; How do I know if my PC is compatible?; User guide: Graphics API; Submit my test.

Question 38

How do I find out what is limiting my FPS with the performance panel?

Accepted Answer

Since 0.2.38, openOMSI has a live performance panel, compact or detailed (in the notes, under Settings, Interface). According to the changelog, it shows where the time of each frame goes, what is holding back the frame rate, the processor load and the last hitch. It can help you tell whether the limit is more on the CPU or the GPU before you start changing graphics options, but it does not promise an FPS gain by itself. The notes do not detail the screens, so the exact name of the tab or button may vary with the launcher version. According to the 0.3.40 notes, the panel took on the browser's look (dark or light) and can be enlarged or reduced (from 0.6x to 2x) from the bottom-right corner, keeping the size. Anyone who wants to measure in a more technical way can use OMSI_PROFILE=1, which the user guide describes: it records the split of the frame (drawing, mirrors, traffic, people, scripted objects, LAN), counts the frames above 50 ms and notes GPU and CPU memory use in the log. If you report an FPS problem, the version, map, bus, graphics API and what the panel showed help whoever looks at the case. What to check: Is your openOMSI 0.2.38 or newer? (earlier builds do not have the panel); Compare the panel on a light map and on the map that is heavy, with the same settings.; Change one graphics setting at a time and see what the panel says.. Learn more: How can I improve FPS?; Do CPU, GPU and RAM affect performance?; User guide: Performance.

Question 39

In Enhanced mode, the mirror is dark, the sign glows too much, or the water, snow and reflections look odd. What changed?

Accepted Answer

Enhanced mode is the heaviest renderer and has received several fixes. Mirrors: mirrors were much darker than the windshield at dusk and in daytime rain; since 0.1.538 they only darken when the sun is below the horizon. Signs: flipdot matrices (such as the Krueger on the MAN NL/NG) no longer glow like LEDs, and LED panels keep glowing and go dark when the bus power or lights are switched off (0.1.538); the LED mip strength setting (0 to 4) replaced the old on/off toggle (0.1.576). The driver is now lit by the four interior lights at their seat, instead of a flat glow from all the lamps (0.1.538). Note on names: since 0.3.42 Enhanced+ is no longer a mode but Enhanced with Real-Time Ray Tracing turned on (ray_tracing=1); wherever this answer says Enhanced+, read it that way. Enhanced also gained options of its own (Light has shadows, Cloud shadows and light shafts, Glow of lights, Real-Time Reflections and Reflective objects reflect), and the quality presets (Low to Ultra) now choose the mode. Wet road and water: since 0.1.796, with reflections on, Enhanced can reflect buses, buildings and scenery in puddles and on the wet road, following the real height and slope of the road (including nearby articulated sections). Puddles appear as patches on the wet road, not as a single mirror over the whole lane (an adjustment after 0.1.1120), and the asphalt stays visible between them. In Enhanced it is a limited, reduced-resolution effect, not ray tracing (Enhanced+ uses real ray tracing, but only on RTX, RDNA 2 and Apple M3/M4 cards or newer): it does not appear on a dry road, with full snow, or in mirrors (in the 0.1.796 notes OpenGL was also left out). Since 0.1.1196, reflections on the wet road also work in Vanilla and Vanilla+, and are seen through the bus's own windows, not only in Enhanced. Also in Enhanced, the map's water is drawn as water, with small waves and a sky reflection (0.1.1098). The cost is limited, but it exists: if you need FPS, turn reflections off. Other recent image fixes: snow covers the windshield like rain and the wipers clear it, and the map's WinterSnow textures show the snow itself (0.1.1098); houses no longer appear inside out when the mesh had no matrix (0.1.1098), and there are fewer inside-out meshes (0.1.1302); crosswalks and markings are back on top of the road (0.1.1098); rain no longer enters the rear section of articulated buses (0.1.960) and AI cars with transmap are no longer entirely semi-transparent (0.1.1120), not even when the declared [matl_transmap] file is missing, in which case the texture stays opaque (0.1.1169); the high beam reaches what [spotlight] says (0.1.1120); and VR uses Enhanced (0.1.960). In Vanilla+, the white haze on the ground at night was fixed. In Enhanced, the glow of custom weather no longer darkens the mirrors and a white light map no longer “burns” displays and gauges at night (0.1.1223); and stacked transparent layers, such as dirty glass and decals, no longer show through one another (0.1.1166). Since 0.1.1551, Enhanced and Enhanced+ calculate the sky from atmospheric physics (sunset, twilight, the moon with its real phase and stars) and, with no weather chosen, natural weather changes over the days; in 0.1.1707, headlamps light the road evenly, like real ones. 0.2.0 reworked night and weather in Enhanced and Enhanced+: night is dark again (the eye adapts to the lamps and headlamps in view, rather than to a fixed city level), street lamps cast real shadows, light bounces from the ground onto the buses and façades, the moon lights the scene with shadows of its own, and fog and mist form halos around lamps and headlamps (rain does not do this); looking at the sun dazzles, and the image darkens when you see the sun and brightens in a dark cab or under an overpass. The new snow, with up to 150,000 flakes calculated on the graphics card, applies to all graphics modes. In 0.2.42, the mirrors began to be drawn with Enhanced's shading, light and sky, the sun has its real size (0.27 degrees) with the glow of a camera lens around it, and the bodywork of buses and cars gained a varnish shine in Enhanced; in the Vanilla and Vanilla+ modes, the paint and the windows keep their shine at night when lamps light them. AI cars also light the road with their headlamps on in Enhanced and Enhanced+. If Enhanced's night became too dark for you, since 0.2.16 there is the Night brightness setting (Settings > Graphics, off by default), which brightens Enhanced only after sunset. Other changes in the 0.2 series: on Enhanced's wet road, headlamps now reflect as a short glint on the asphalt and an image in the puddles, instead of an endless white line all the way to the camera (0.2.22); the reflection of the bus paint in Vanilla and Vanilla+ follows the light of the moment, rather than a sunny day at night (0.2.26); snow chosen while driving began to cover the ground in Vanilla and Vanilla+ as well (0.2.25); the bus's own headlamps cast shadows in Enhanced (0.2.28); overcast clouds became a dark layer with relief of its own (0.2.30) and stopped “jumping” every few minutes (0.2.36); and Vanilla's glow no longer blows out where lights overlap (0.2.36). In 0.2.39, Enhanced+ reflections gained real textures on the windscreen, the rear window and other glass (before, they were flat colours), headlamps seen from far away began to glow round (before, the halo was square) and the glow of traffic headlamps follows the drawn car, without sliding into the bodywork and looking like a blinking lamp. In 0.2.44, only the 12 AI cars closest to the camera, within 200 m, light the road with their headlamps in Enhanced, which eased the load on the graphics card at night. In 0.3.0, the Enhanced varnish shine became crisp again, ambient occlusion went back to its pre-0.2.46 strength and the Vanilla and Vanilla+ sky no longer has clouds stretched towards the horizon. The 0.3.30 to 0.3.33 series (in the Stable since 0.3.33): in Enhanced, bus windows started to look like glass, showing the cab and the street instead of a bright-sky mirror (0.3.30); on OpenGL and DirectX 11, street lamps, headlamps and interior lamps light their surroundings as on DirectX 12 (0.3.31); a street lamp hidden behind a house, a tree or the ground no longer darkens the whole image at night (0.3.32); instruments on the dashboard, signs on poles and timetables at stops stopped flickering against one another, with the latest one on top, as in OMSI 2 (0.3.33); the headlamp beam comes out of the bus's own headlamps, not from under the bumper or from the fog lamps (0.3.33); and the reflection maps (paint, chrome, glass) gained an intensity control from 0 to 100 % in the game and in the launcher, taking effect immediately (0.3.33). Series 0.3.34 to 0.3.42 (Stable in 0.3.37 and 0.3.42): the sun is back in the Vanilla and Vanilla+ sky; in Enhanced, parked cars no longer look like transparent ghosts, car and bus windows lost the grey glare on overcast and foggy days, a wet bus mirrors the street, grass and dirt no longer shine like wet asphalt in the rain, and the lamps of other vehicles no longer light up the inside of your bus; in Enhanced with ray tracing, lit switches and displays keep their texture at night instead of white blotches (0.3.37); puddles have Low and High quality (0.3.37). In 0.3.42: cloud shadows fall on the ground, wet roads and water mirror the street (not only puddles), more lights cast shadows (Light has shadows: Every light), there is a hand torch (Alt+F), headlight beams in fog, rain and snow have shadows of poles and cars, the ground no longer glows orange from small distant lights, bus shelters show through the bus windows, destination signs light up at night, Vanilla and Vanilla+ headlights light the road as in OMSI 2 and tyre spray comes only from puddles. These fixes do not guarantee that all content will look perfect: if something still looks wrong in a current build, note the version, map and location. What to check: Are you in Enhanced mode (and not Vanilla)?; Is openOMSI up to date? (Enhanced+ with textured glass, round headlamps and traffic glow: 0.2.39; Night brightness: 0.2.16; mirrors and flipdot: 0.1.538; puddles: 0.1.796 and later; water, snow and inverted meshes: 0.1.1098; reflections also in Vanilla: 0.1.1196; stacked glass and white light map: 0.1.1166 and 0.1.1223); Is the reflections option turned on in the graphics settings? (since 0.3.42 it appears as Real-Time Reflections, with Reflective objects reflect for the reflection maps). Learn more: CHANGELOG; How do I improve FPS?; User guide: Enhanced.

Question 40

My map opens with missing objects, roads or textures. Why does this happen?

Accepted Answer

Most of the time, the map depends on objects, splines (roads and rails) and textures that are in other packages (add-ons) that have not been installed yet. Without those files, you get holes, roads without asphalt or white objects. Other possible causes are files in the wrong place, an incomplete download or some content that openOMSI does not read well yet. According to the 0.3.42 notes, a texture that the model asks for as .dds and does not exist now counts as missing, as in OMSI, instead of being swapped for a .bmp or another file of the same name (the example given is the MAN DN95, which looked like a mirror), and houses in binary .x written by the PAD-Labs exporter, which had not loaded since 0.3.38, are back (example: Köln, Engeldorfer Straße). openOMSI warns you when it loads a map like this: it shows how many objects, splines and textures are missing and writes the full list to missing_content.txt, inside the .openomsi folder of your user account (on Windows, C:\Users\\.openomsi). According to the project's changelog, the file is written again when the game ends, this time with the tiles that were loaded along the way, and holes, roads without asphalt and white objects in a map in that situation point to a missing download, not necessarily a failure of the game. Since 0.3.42, in Setup, the .openomsi folder (the notes mention settings, profiles, logs and caches) can sit in another folder or on another drive: if you changed the location, look for the logs in the new folder (the notes do not mention missing_content.txt in particular). History of the search for textures in other content. Between 0.1.1147 and 0.2.23, openOMSI looked for a missing spline or scenery-object texture, outside its own folders, in other content of the same installation that had it (same file name). That helped old content, but it is not good practice for new packages. According to the changelog, from 0.2.24 a texture that is missing from a scenery object's folders is no longer “borrowed” from another folder (examples given: a gantry showing the package's generic sign, and a sign showing the asphalt texture). So in recent builds, do not count on that borrowing: the map's package should ship or declare what it uses. We did not find in the documentation whether the search still applies to splines. What to check: Open the missing_content.txt file (close the game first, because the list is written again when it ends) and see which items appear.; On the launcher's Mods page (0.2.27 onwards), the arrow on a mod's row opens its content folder by folder (Vehicles, Texture, Sceneryobjects, Splines...) and shows how many items each folder has: use it to check that the package the map asks for was really installed. According to the 0.3.39 notes, each mod's row says which game folders it put things in and how many (for example “Vehicles 1, Fonts 2, Texture 1”) and shows “found in the content folder” for a mod copied by hand into the content folder; when opened, the content appears grouped by those folders. In versions before 0.3.39 this list may not exist: check the content directly in the folder. Since 0.3.34 the Mods page is in the Content group of the left-hand menu.; Since 0.3.41, Help > Troubleshooting in the launcher gathers what is wrong with the installed content (packages waiting for the bus, buses that use parts from packages that are not installed, map HOF files that could not be added, failed installations), and the second tab, Model test, loads a whole map the way the game loads it and lists what it places that is not installed. In versions 0.3.34 to 0.3.40 the equivalent check is in Content test, in Settings (on the command line, openomsi --check [--deep]).; Look on the map's page for the list of dependencies (packages it requires) and install them all.; Check that the content folder was installed in the right place (see the question about folders and paths).; Test the same map in the original OMSI 2, if you have it, to know whether the problem is the map.; Note the openOMSI version you are using.; In builds before 0.1.538, TGA textures named .png, .bmp or .jpg could be missing: update before renaming files.; In builds from 0.1.1147 to 0.2.23, the game.log recorded once each texture found in other content: if one appears, the original package should ship it, and it is worth telling the author.; Texture names saved in a Korean, Chinese or Japanese code page started being found in 0.1.1223 (and the content is read in that code page on a Windows set up that way, since 0.1.623): in older builds, a map like that could look as if textures were missing.; On Android: did you delete images that showed up in the gallery? In versions before 0.1.523 this could happen, because textures appeared as photos; current builds create .nomedia automatically. If files have already been deleted, restore or reinstall the affected content.. Learn more: Project changelog; Search for this map in the compatibility database; openOMSI Issues; OMSI textures in the Android gallery; A map works in OMSI 2 but not in openOMSI.

Question 41

The map terrain is missing, has holes or is broken. What could it be?

Accepted Answer

Terrain with holes, transparent ground or roads “sinking” can have several origins: objects or splines that were not installed, problems in the map's own files, a map feature that openOMSI does not yet handle well, or an older openOMSI version. The project has fixed several cases over the versions (for example roads under grass and road slopes), so it is worth checking that you are on the latest version. Some causes have already been fixed in the engine; if your case looks like one of them, update first. A forgotten .water file in the folder no longer floods a tile whose water was removed, because water only exists when the .map declares [water] (0.1.538). Bridges and other [surface] objects modelled far from the origin now sit at road height (0.1.576), and a [surface] without [absheight] sits on the terrain (0.1.623). Excavations and stairs of presurface objects are no longer filled in by the terrain, and [terrainhole] opens deep cuts and underground passages (0.1.623). [terrainmapping] uses only the map's first ground texture, as OMSI does, which fixes ground lighting and seams between tiles (0.1.576), and the terrain texture from the map's own folder takes priority over the global seasonal copies (0.1.623). This is an engine fix: defects from missing content or from the map's files still follow the list below. There are also known bugs related to this system. Before opening a report, follow the list below and search the Issues to see whether someone has already described something similar. Junctions: the terrain is no longer pressed into the crossing's height mesh, which Omsi.exe uses only for paths (0.1.1098), and [terrainhole] now cuts the terrain better at the edge of junctions and roads (0.1.1028). If the defect is objects or parts of the road out of place, see the question about parts of the map floating in the air. More fixes, from 0.1.1313 onwards, according to the changelog: the exposed terrain edges along [terrainhole] cuts are now closed off by walls using the surrounding ground texture (0.1.1423); a junction's slab is only raised by the height field where it covers it, which removed the step and the gap at the U Ruhleben station link on the Berlin-Spandau map (0.1.1671); thin triangles no longer create invisible walls on the road (0.1.1668); tunnel entrances are no longer closed off by stretched terrain (0.2.28); and, when switching to a snow climate with the game open, the plain ground of Vanilla and Vanilla+ kept the summer grass, which was fixed in 0.2.25. In 0.3.0 (Stable), the terrain under splines and spline attachments with [spline_terrain_align] is cut at the right point again, which undoes broken terrain beside or under streets. What to check: Check whether the missing content warning appeared when the map loaded.; Did you get stuck on a bridge or an invisible wall on a modded map? The project's README mentions Collisions with objects (Esc, Options, and also in Settings) to switch off collision with the map's objects; it is a way to get unstuck, not a fix for the map.; Install all the dependencies listed by the map's author.; Update openOMSI and test again.; Compare with the original OMSI 2, if possible.; If it persists, note the map name and version and attach the game.log file.; On Android: did you delete images that showed up in the gallery? In versions before 0.1.523 this could happen, because textures appeared as photos; current builds create .nomedia automatically. If files have already been deleted, restore or reinstall the affected content.. Learn more: openOMSI Issues; Project changelog; How to tell if a map works; OMSI textures in the Android gallery; Map parts in the air or out of place.

Question 42

Why are parts of the map (roads, objects, speed bumps) floating or out of place in openOMSI?

Accepted Answer

It could be content, it could be how the format is read, and only testing on the current version tells which. Several cases like this have already been fixed in the engine: tiles from old versions were read as if they were version 14, so objects attached to the wrong parent ended up suspended and pieces of road appeared in the air (0.1.851), and the terrain around junctions was deformed with the crossing's height mesh, which Omsi.exe uses only for the paths, which could shift terrain, speed bumps and nearby objects (0.1.1098). There were also fixes to the height of surface objects, bridges, [terrainhole] at the edge of junctions and objects with traffic paths. More recent fixes: roads are drawn at their own height again, without the 8 cm lift, so pavements no longer sit above the ground and markings no longer sink under the road (0.1.1196); terrain objects outside their own tile are no longer drawn, which removed leftovers of copied tiles from the middle of the road (0.1.1223); and AI cars whose road appears more than 0.3 m below their lane now come down to it, instead of driving in the air (0.1.1223). From 0.1.1671 onwards: the road link at the U Ruhleben station (Berlin-Spandau) is level again, with no gap or step (0.1.1671); objects placed along a spline (bridge pillars, lampposts, masts, fences, markings) now sit where the map puts them, with no gaps or overlaps where it passes to the next tile (0.2.24); the rules for which objects in a row along the spline are drawn were adjusted again in 0.2.30 (bridge pillars no longer end up on the road on the Grundorf Island 4 map) and in 0.2.31, which went back to drawing row objects that cross the tile edge (parked cars on a Berlin-Spandau street); and objects marked as surface ([surface]) no longer show up in front of what is beside them when seen from a distance, such as a traffic light's pole crossing the signal head, in 0.2.30. According to the notes, in 0.3.40 objects attached to a spline on maps with [worldcoordinates] (Shanghai and others) stopped being displaced on tiles far from the middle of the map, and in 0.3.42 a spline laid over a [surface] object (the Crystal Palace road) or over another spline in the same tile, at the same height, is now drawn on top, as Omsi.exe does; before, London's markings and the red bus lanes fought with the road surface. This does not mean that every misplaced object is an openOMSI bug, or that the map is poorly made: it may be content that depends on an OMSI quirk, a missing dependency, a file overwritten by another package or a real defect in the file. Update openOMSI, repeat at the same point on the map, compare with OMSI 2 and note the version, map and location. The environment variable OMSI_CROSSING_DEFORM=1 restores the old junction behaviour and is for tests and comparisons only. What to check: Is openOMSI on the current version? Reports made a few hundred versions ago may already be fixed.; Does the problem always appear in the same place (junction, bridge, spline stretch)?; Does it happen in the original OMSI 2, at the same point?; Are all the packages the map asks for installed, and has no file been overwritten by another package?; Did you use the game's object editor (Ctrl+Shift+E)? When you save, it writes a copy of each changed tile to maps/<mapa>/tile_x_y.map in the content folder, which the game reads before the installation; delete the copy to go back to the original tile.; Note the version, map and location to submit at /testar or in an Issue.. Learn more: My map opens with missing objects, roads or textures; The map's terrain is missing or broken; CHANGELOG; Submit my test.

Question 43

A map works in my OMSI 2 but has problems in openOMSI. Whose problem is it?

Accepted Answer

That alone does not tell you whose problem it is. openOMSI reimplements the format from scratch and has already fixed several differences from Omsi.exe (many recent changelog entries say exactly “as in Omsi.exe”); the README states as its goal that OMSI 2 content should work unchanged, and it is still an early version. At the same time, OMSI 2 accepts content that depends on its own quirks. The possible causes are: a compatibility difference or bug in openOMSI (maybe already fixed: the project releases versions several times a day); content that relies on an OMSI quirk; a missing dependency or a file overwritten by another package (between 0.1.1147 and 0.2.23 openOMSI even looked for a spline or object texture in other content that had it; according to the changelog, from 0.2.24 a texture that is missing from a scenery object's folders is no longer borrowed from another folder, so shipping the dependencies clearly is what counts); or a genuinely defective structure in the content. The technical evidence is what decides. Test on the current version, compare at the same spot in both games, check missing_content.txt and the game.log, and record the result with the openOMSI version: a report without a version ages quickly. Report on GitHub only what is reproducible on a current build. What to check: Is openOMSI on the current version?; Does the same spot on the map behave differently in the two games?; Do missing_content.txt and game.log indicate anything missing or any warning?; Is there another package that overwrites files of this map?. Learn more: Map parts in the air or out of place; My map opens with missing objects or textures; When to use compatibility and when to open an Issue?; Submit my test.

Question 44

Roads, tracks or other splines have disappeared or show the wrong texture. What can I do?

Accepted Answer

Splines are the pieces that make up roads, pavements, tracks and fences on the map. If they disappear or turn white, the first step is to check that the package containing those splines and textures is installed and in the right place. The missing_content.txt file lists what the game did not find. If everything is installed and the problem continues, it may be a limitation of openOMSI with that map. Junctions that seemed to have their faces turned inside out ([crossing_heightdeformation]) were fixed starting in 0.1.523. Between 0.1.1147 and 0.2.23, a spline texture that was missing from its own folder could be found in other content in the installation that had it; according to the changelog, from 0.2.24 a texture that is missing from a scenery object's folders is no longer borrowed from another folder (we found no confirmation of whether this also applies to splines), so the package should ship what it uses. Objects along a spline (pillars, lampposts, fences, markings) had their placement fixed where it passes between tiles in 0.2.24 and again in 0.2.30 and 0.2.31. On maps made with the OMSI 1 editor (the example cited is Great Grundorf 2), most of the roads did not appear; since 0.3.31 (Beta; in the Stable version since 0.3.33) the whole road network is loaded. According to the notes, 0.3.34 started drawing a street's painted lines over junctions and junction plates, as in OMSI 2, instead of vanishing depending on camera height and distance; 0.3.41 started recognising French street texture names, which brought back missing streets on maps such as HCM; and 0.3.42 fixed street markings that disappeared and returned as the bus approached, and London's markings and red bus lanes that varied with the camera's distance or rotation. There are also known bugs related to this system, as reports in the Issues show (for example about splines disappearing or with a rotated texture). What to check: Read missing_content.txt and look for spline or texture names.; Reinstall the spline package the map asks for.; Check that folder names were not changed when extracting the archive. On Linux, a lowercase texture folder from a mod used to hide the original content's textures; this was fixed in 0.2.28.; Test on another openOMSI version, if you have one, and note the difference.; On Android: did you delete images that showed up in the gallery? In versions before 0.1.523 this could happen, because textures appeared as photos; current builds create .nomedia automatically. If files have already been deleted, restore or reinstall the affected content.. Learn more: openOMSI Issues; Submit a test of this map; OMSI textures in the Android gallery.

Question 45

The map opens and I appear in the middle of the woods or far from the road. Is this normal?

Accepted Answer

The public documentation consulted does not explain this case in general, so we cannot state the cause. Among the possibilities: the chosen starting point (depot or spawn point) is not the one expected for that map, the map has more than one region and the bus came out in another one, or some object or terrain is missing. What exists in the Issues are similar reports, for example a map with two cities where the bus appeared on the grass of the other city; the person in charge replied that they would fix it. That kind of case may have been adjusted in newer versions, but we found no confirmation of which one. On maps made with the OMSI 1 editor (such as Great Grundorf 2), before 0.3.31 (Beta; in the Stable version since 0.3.33) there were hardly any starting points or roads; since then the road network and the starting points are there. A different case, that of buses placed on the map that fell through the ground when the player moved away and were saved kilometres below it, was fixed in 0.2.33 according to the changelog (the bus now keeps its place while the tile is not loaded). What to check: Choose the depot or starting point on the launcher's Drive page (the documentation mentions map, starting point, line and tour; the exact field names changed between launcher versions; according to the changelog, 0.2.39 brought back line and tour as a pair of searchable lists, and a tour is found by any stop; since 0.3.37 the page brings map, line and tour, roadbook, bus and start together on one screen, in the Big Map (default), Control Room, Classic+ and Classic layouts, chosen in Settings, and since 0.3.39 the start bar shows the first trip and where the bus will be placed, with “Entry point N” for an unnamed point) and try another one. If you joined someone else's game, the changelog says that, since 0.2.39, the game starts on the host's map.; In the game, in the free camera (F4), the usage guide says that Ctrl+click on the ground takes the bus to the nearest road; the 0.2.28 changelog says that a click on the F4 map asks whether the vehicle should be moved there. Which gesture applies depends on the version, so check on yours.; Check whether the missing content warning appeared.; Update openOMSI and try again.; Test the same map and starting point in the original OMSI 2, if possible.; If it persists, ask the community or the Issues, giving the map, version and chosen point.. Learn more: openOMSI Issues; Search for this map in the compatibility database.

Question 46

Very large maps won't open or the game closes while loading. What can I do?

Accepted Answer

Large maps use a lot of memory and processing. If the computer or phone does not have enough resources, loading may fail, hang or close the game. Other possible causes are missing content or problems in the map's files. There are reports in the Issues of failures when loading very large maps, both on computers and on Android. We did not find an official map size limit in the documentation consulted, nor a guaranteed solution. What the documentation and changelog say has changed: the usage guide states that large maps are kept within memory using compressed textures, a texture memory budget (texture_memory), a timetable fleet that is read ahead and trimmed again, and tiles that give everything back when they unload (the example given is the Ahlheim V5 map, from 8.75 GB down to 1.93 GB with traffic, passengers and timetables); 0.1.1423 fixed NVIDIA cards without Resizable BAR on Vulkan, where loading took minutes and the game ran at a few frames per second; 0.1.1726 started releasing the old render targets when a heavy map runs out of graphics memory on Vulkan; 0.2.28 started using the texture memory the driver reports on integrated graphics; and 0.2.36 and 0.2.38 brought batched tile loading and a roundabout search that is 2 to 5 times faster when the map loads. According to the changelog, 0.2.39 also reorganised the game core (the map objects' scripts now run only near the bus and in parallel, and there is an experimental simulation thread, OMSI_SIM_THREAD=1, off by default in 0.2.39; according to the 0.3.37 notes, the simulation now runs on its own thread by default), presented as a performance gain and not as a fix for maps failing to open. Since 0.3.0 (the Stable stabilisation release), according to the changelog, the AI vehicles' scripts went back to running once per frame, not at every 20 ms traffic step, and passengers, pedestrians, timetables and weather also went back to once per frame: the text says large maps with a lot of AI traffic run smoothly again, without the drop to a few frames per second. Also in 0.3.0, AI traffic no longer stays stopped forever at large junctions and roundabouts. According to the notes for versions 0.3.30 to 0.3.33, there was also: about a fifth less texture memory for the same image, which helps 2 to 8 GB cards on large maps (0.3.30); the game stopped becoming blurry and slow when the card refuses a texture (0.3.30); and, in 0.3.33, the “Video memory” setting (formerly “Texture memory”) also started to limit meshes, render targets and driver memory, and a card that runs out of memory no longer loses the whole image. In the later versions, according to the notes: 0.3.34 started giving textures half of the video memory on a card with its own memory (about 3.7 GB on an 8 GB card in Automatic, instead of 2 GB with 16 GB of RAM); 0.3.40 reduced the game's memory by no longer keeping the browser's ground twice (from 1058 MB to 824 MB on the Grand Paris-Moulon map, measured by the author on a Linux PC); 0.3.41 started counting towards the video memory limit the empty space the driver holds on DirectX 12 and Vulkan, aimed at the frame-rate drop after long trips (the notes ask for long tests and say the setting is not a hard ceiling when the textures are already at the smallest size); 0.3.41 rejects malformed texture data before upload, using a substitute texture and writing to the log; and 0.3.42 fixed AI traffic where a bus waiting to change lane could block the street forever. The launcher's route preview on large maps also became much faster (Berlin-Spandau's, in about a second instead of 88 s, in 0.3.34). None of this is a guarantee that a specific map will open on your equipment. What to check: From version 0.2.36 the loading screen shows the map name and a bar that advances according to the time of the last loads; seeing the bar move helps tell a slow load from a hang.; In Settings → Graphics (screens, distances and memory) you find the distance at which tiles are kept loaded (view_distance, 1200 m by default according to the guide) and the texture memory (texture_memory; in the interface from 0.3.33 onwards the setting is called “Video memory”); lowering these values may ease a heavy map. Since 0.3.37 there is also the Optimise for my PC button (in the launcher's graphics settings and in Options → Graphics in the game): during the next trip the game measures for about a minute, tests lighter settings and keeps only those that give frames, and Restore my previous settings brings back the previous ones. The quality levels are Low, Medium, High, Extra, Max and Ultra, and each one also sets the mode (Low is Vanilla, Medium is Vanilla+, the default, and Ultra is Enhanced with ray tracing), according to the 0.3.42 notes. This affects performance after the map opens; the notes do not say it helps open a map that fails.; Close other programs and try again.; Test a smaller map first to find out whether openOMSI opens normally.; On a phone, remember that memory is more limited than on a PC.; Keep the game.log right after the failure.; Look in the Issues to see whether the same map has already been reported.; On Android, if the problem started right after copying many files or installing mods, the gallery or media scanner may be indexing thousands of textures (it is not always the cause). Since 0.1.523, openOMSI automatically creates .nomedia to reduce this; on older versions, update before any other step. Do not delete the images.. Learn more: Performance and requirements; openOMSI Issues; OMSI textures in the Android gallery.

Question 47

Where should I put maps and objects? Do upper and lower case in names matter?

Accepted Answer

openOMSI organises the game folder like an OMSI 2 installation and looks for content there before looking at the original installation. The launcher's Mods page installs folders or .zip, .7z or .rar files. If the content was placed outside the expected structure (for example an extra folder inside), it may not be found. The usage guide says paths are resolved without distinguishing upper and lower case and that Windows-style references (with \) work on all systems. There were targeted fixes for folders such as Texture written with different capitalisation on Linux (0.2.28 fixed the case of a lowercase texture folder from a mod that hid the original's textures). Between 0.1.1147 and 0.2.23, a spline or scenery object texture that was missing from its own folders could be found in other content with the same name; according to the changelog, from 0.2.24 the borrowing from another folder no longer happens for scenery objects, so the package needs to ship what it uses. The content folder sits next to the program and is read before the original installation, which is never changed (OMSI_CONTENT changes the location; on macOS, a new openOMSI.app in Applications keeps the content in ~/.openomsi/content, since 0.1.1223). The launcher's Mods page also accepts a folder or file dragged onto the window, or dropped into Mods/ next to the program, and a .zip organised like OMSI 2 can be used in place, in Archives/, without unpacking. Since 0.2.27, what a mod puts in shared folders (fonts in Fonts, textures in Texture) is recorded as its own: it shows up on the Mods page and disappears when the mod is switched off or deleted. According to the changelog, 0.2.39 gave the Mods page back cancelling an installation, the file size check, filters, the content folder and dropping a mod anywhere in the window. On phones, since 0.3.0 (Stable) the Mods page has its own storage browser for installing a folder or a .zip, .7z or .rar file; before that, “Add folder” and ZIP did nothing. According to the 0.3.39 notes, each mod's row says in which game folders it put things and how many; in 0.3.40 the Mods page started asking before copying a map's HOF files to all buses (“Share with every bus” or “Not for this map”). And since 0.3.42, in Setup, the .openomsi folder (settings, profiles, logs and caches) can live in another folder or disk. What to check: Check that the Sceneryobjects, Splines, Texture folders and so on are at the right level.; Prefer installing through the launcher (Mods page) when possible.; On Android, see the mod installation guidance.. Learn more: Usage guide (official documentation); How to install mods on Android.

Question 48

How can I tell whether a map works in openOMSI before installing it?

Accepted Answer

There is no official guarantee for each map. The project aims to be compatible with OMSI 2 content, but it is still early. A practical way is to check the Portal OmsiModsBR community compatibility database (independent, unofficial and complementary), where people record the results of their tests. If the map is not in the database yet, the best way to find out is to test it. Afterwards you can record the result at /testar, stating the openOMSI version and what you saw, to help other people. Always record the openOMSI version: an incompatibility seen a few hundred versions ago may already have been fixed, and the site flags tests made on very old versions. Since 0.3.0 the project separates Stable and Beta versions: in Settings > General > Updates there is an update channel, with Stable as the default and Beta meant for testers, and the version selector marks the Betas. The numbers of a Beta (and of TestFlight builds, on iPhone/iPad) may not match those of the Stable version, so also note which channel you tested on. Since 0.3.42, the launcher shows the transport mode (tram, railway, metro, trolleybus) of maps and buses, the pickers can filter by it, and a vehicle that does not suit the chosen map is marked with the reason and does not start; according to the notes, a bus does not start on a tram map, and a map without these modes accepts any vehicle. What to check: Look up the map name at /buscar.; Check the openOMSI version used in the tests: old results may have changed.; Install all the dependencies listed by the map's author.; After testing, record the result at /testar.. Learn more: Search for a map; Submit a test.

Question 49

What are openOMSI Map Packages (`openomsi-realmap` map packages)?

Accepted Answer

A map package is a folder called openomsi-realmap, placed next to a map's files (Maps/<Mapa>/openomsi-realmap). It holds a pre-rendered image of the map and extra data for the minimap/radar: layers such as water, vegetation, buildings, terrain relief, rivers, railways and borders underneath the street layout, plus lines and timetables. The original OMSI 2 never had a built-in minimap; openOMSI brought its own navigation, and these packages give it context. According to the 0.2.48 changelog, the navigator and the city map show the terrain under the streets (water, parks and woods, rivers, railways and borders, in a dark or light look) on a map that has the package. Since 0.3.31 (Beta; in the Stable version since 0.3.33), the route map on the launcher's Drive page also shows water, green areas, rivers, railways and borders under the streets when the map has the package. According to the 0.3.37 notes onwards, the navigator and the city map started drawing land, water, woods, tracks and 3D houses from the map itself, with no package; the package still adds what the map does not bring: place names, icons, regions and the street and municipality under the bus, the Lines button with the lines and their timetables (if the package has a lines.lin) and, from Beta 0.3.38 (Stable in 0.3.42), the Terrain button with the contour lines and their heights (if the package has contour lines). The package does not replace the map or the OMSI 3D editor: the drivable streets, objects and terrain are still the map's own. Omsi.exe ignores the folder, so a map made for both games loses nothing. The format is public (specification in the openomsi-map-packages repository). This is a community explanation, not official openOMSI documentation. What to check: Does your map have a package? See the question about which maps already have packages.; Is your openOMSI version 0.2.48 or newer? The stable version 0.3.0 already includes 0.2.48; the launcher's route map with the layers comes in the Stable since 0.3.33.. Learn more: Do I need to install Map Packages to play?; How to install a Map Package; Which maps already have packages?; Format specification (openomsi-map-packages repository).

Question 50

Do I need to install Map Packages to play?

Accepted Answer

No. In the official sources the package is an add-on: the folder brings extra layers for the minimap/radar and, if an optional file is missing, the matching feature is simply switched off. A map without a package is still the same map as always, with openOMSI's standard drawing (since 0.3.37, according to the notes, the navigator and the city map already draw the map from the map itself, with no package). Packages also do not replace the download or installation of the map: you still need the map and its dependencies. What to check: Does the map open and play normally without the package? Then there is nothing mandatory to install.. Learn more: What are Map Packages; How to install a Map Package.

Question 51

How do I install a Map Package?

Accepted Answer

Download the package for your map (the ready-made examples are in the v0.2.0 release of the openomsi-map-packages repository) and copy the openomsi-realmap folder to Maps//openomsi-realmap/ inside the openOMSI content folder (the folder next to the program, where the mods live). The specification says the OMSI 2 installation is not changed and that putting the folder directly in the installation's Maps// also works. No original map file is replaced. Then open the map in openOMSI. The repository guide mentions Shift+M for the city map and the nav_surface=0 setting to switch the package off; as these details may change between versions, check them in yours. Use an openOMSI version that supports the format (0.2.48 or newer). What to check: Is the path Maps//openomsi-realmap/, without an extra folder inside?; Is the map folder name the one of the map you installed, and is the package for that same map and version?; Inside the openomsi-realmap folder, is there a manifest.cfg? Without it the package is ignored.; Is your openOMSI 0.2.48 or newer?. Learn more: Where should I put maps and objects?; Which maps already have packages?; v0.2.0 packages (download).

Question 52

What is the Map Package Creator and where do I download it?

Accepted Answer

The Map Package Creator (v1.0.0) is a free Windows program by Leo Monteiro to create packages for the openOMSI minimap/radar: it lets you view, check, annotate, edit and generate openomsi-realmap packages, with layers, lines, timetables, point inspection, annotations and undo/redo. The generator is built in, so you do not need to install Python. The interface has 17 languages, including Brazilian Portuguese (translations made with AI help, so they may contain mistakes). It does not replace the OMSI 3D editor: creating streets, placing objects and shaping terrain are still done in the scenery editing tools. Players who just want to use a ready-made package do not need it. To use it: download ombr-mapcreator-v1.0.0-windows.zip from the app-v1.0.0 release of the openomsi-map-packages repository, extract it anywhere and run ombr-mapcreator.exe. There is no installation. As the file is not signed, Windows may show the "unknown publisher" screen: More info > Run anyway. The program only reads your OMSI 2 folders; when it replaces a package, it keeps a copy in openomsi-realmap.backups. It is closed-source freeware: free to use and share, as long as it is complete and unmodified (see the EULA that comes with the program). What to check: Do you only play? Then you do not need the Creator: it creates the package, and openOMSI reads the package.; Did you download from the official app-v1.0.0 release? Check the source before running a file.. Learn more: Download: app-v1.0.0 release; OmsiModsBR article about the Creator; Can I create packages for fictional maps?.

Question 53

Which systems does the Map Package Creator run on? Do I need it to use a package?

Accepted Answer

The official sources describe Creator v1.0.0 as a program for Windows (ombr-mapcreator.exe) and say nothing about other systems. We will not assume anything beyond that. What matters if you play: the package is a data folder and the Creator is just the authoring tool. You do not need it on the device you play on; to use a ready-made package, just copy the openomsi-realmap folder into the map. What to check: Do you just want to use a package? You do not need the Creator, only the package folder and an openOMSI that supports it.. Learn more: What is the Map Package Creator?; Do Map Packages work on Android, iOS, Linux and macOS?.

Question 54

Do Map Packages work on Android, iOS, Linux and macOS?

Accepted Answer

Packages are data files and the Creator is only the authoring tool, which does not need to be on the device you play on. Whether packages show up in the drawing depends on the openOMSI version and platform: the official documents describe support in the navigator and city map (0.2.48) and, since 0.3.31 (Beta; in the Stable version since 0.3.33), in the launcher's route map, but we have not checked platform by platform (Android, iOS, Linux, macOS), especially openOMSI for iPhone and iPad, which is in Beta via TestFlight (not on the App Store). We do not promise it will work. If you want to test, copy the package folder to Maps/<Mapa>/openomsi-realmap/ in the content folder and see whether the layers appear. On a phone, the content folder is wherever the launcher's Mods page puts it. What to check: Use an openOMSI version that supports the format (0.2.48 or newer) and install the package as described in "How to install a Map Package".; Layers not showing up? Record the platform, version and channel (Stable or Beta) at /testar to help others.. Learn more: How to install a Map Package; Record a test.

Question 55

Can I create Map Packages for fictional maps?

Accepted Answer

Yes. The Creator's generator has the own mode, for an invented map, without OpenStreetMap: it uses the map's own elements, without assuming a matching real city exists. The Fikcyjny Szczecin package is the example: it extracts vegetation, buildings, railway, watercourses and terrain from the map, plus the lines and timetables. For real maps there are other modes (auto, which decides and explains the choice in the report, exact, fitted and shore). Lines, stops and timetables come from the map's own files, and the quality of the result depends on the source content: check the package before sharing it. What to check: Before sharing, check the package in the Creator itself and credit the map and its authors.. Learn more: What is the Map Package Creator?; Which maps already have packages?.

Question 56

Which maps already have Map Packages?

Accepted Answer

The packages' v0.2.0 release brings three examples: Berlin-Spandau (the map that ships with OMSI 2), Projekt Szczecin (the map is not perfectly aligned with the real city; the package prioritises the adjusted hydrography and keeps the map's own roads, with bus and tram lines) and Fikcyjny Szczecin (fictional map, package extracted from the map's own files). Packages complement the maps and do not replace their download or installation. The maps still belong to their authors (Berlin-Spandau to the OMSI 2 developers; Projekt Szczecin to mpaw82 and tomass94, with contributors; Fikcyjny Szczecin to MrYanke$ and contributors). OpenStreetMap data follows the ODbL licence. For other maps, we found no official list beyond this one. What to check: Is the package for the same map and the same map version you installed?. Learn more: How to install a Map Package; v0.2.0 packages (download); Can I create packages for fictional maps?.

Question 57

Do Map Packages modify the original OMSI 2 files?

Accepted Answer

No. The package is a separate folder (openomsi-realmap) next to the map files; it does not change the drivable map, its objects or the simulation structure, and a package for a map you do not own goes in the openOMSI content folder, so the OMSI 2 installation is not written to. Since Omsi.exe ignores the folder, the map keeps working as before in the original game. As for the Creator: it only reads the OMSI 2 folders and writes the package to the folder you choose; when replacing an existing package, it keeps a copy in openomsi-realmap.backups. To remove a package, the sources do not describe a special step; deleting the map's openomsi-realmap folder is what the structure suggests (our own inference). What to check: Is the openomsi-realmap folder inside the map folder? No original file needs to be swapped.. Learn more: How to install a Map Package; What are Map Packages.

Question 58

Do Map Packages work in the original OMSI 2?

Accepted Answer

On its own, Omsi.exe ignores the openomsi-realmap folder: what reads the package is openOMSI (and, according to the repository, Project Depot, which can read the same folder). For the original OMSI 2 there is only integration planning, which the official sources say is not delivered in Map Package Creator v1.0.0. So, today, do not expect to see the minimap with the layers inside the original OMSI 2. Because it is ignored, the folder also does not get in the way of the original game: a map can ship with the package for both games without losing anything. What to check: Want to see the layers today? Use openOMSI in a version that supports it (0.2.48 or newer).. Learn more: What are Map Packages; Do Map Packages modify OMSI 2 files?.

Question 59

When should I use the compatibility site and when should I open a GitHub Issue?

Accepted Answer

Use the Help Centre (FAQ) for usage questions, /buscar to find out whether a map, bus or mod has already been tested, and /testar to record your own test. The compatibility site is an independent database from the Portal OmsiModsBR community; it is not a bug reporting system for the project. When you have a reproducible problem in openOMSI itself, report it on GitHub Issues. Before that, confirm the dependencies are installed, that you are on the latest version, and search for an existing identical report. Include the version, system, map name and the game.log (it lives in ~/.openomsi; on Windows, C:\Users\\.openomsi). A report without the openOMSI version is insufficient: the project changes several times a day. The README also mentions the project's Discord server for reporting problems. Since 0.2.18 there is also Setup → Export diagnostics (on the command line, openomsi --export-diagnostics ), which produces a ZIP support bundle with the versions, the graphics card and driver, the graphics settings, the controls and the last map and bus, without folders, names, chat, LAN codes or addresses. The bundle stays only on your computer and its folder opens by itself, so you can look inside before attaching it. When the game ends with an error, the launcher also shows the message with the Copy report and Report on GitHub buttons (names as they appear in the README, in English). Since 0.3.42 there is also Help > Troubleshooting, which lists problems with the installed content, and Setup, where the .openomsi folder can be moved elsewhere: if you changed that, look for game.log in the new folder. Learn more: Search; Submit a test; openOMSI Issues.

Question 60

How do I move the bus to another point on the map when I am stuck, far from the road, or want to go somewhere else?

Accepted Answer

The usage guide says that, in the free camera (F4, the map camera), Ctrl+click on the ground moves the bus to the nearest road to that point. The 0.2.28 changelog describes the F4 map differently: a click asks whether the vehicle should be moved there, anywhere on the map. The two texts appear at different places in the documentation, so we cannot say which gesture applies on your version: try both. On a touch screen (phones and tablets), according to the 0.3.42 notes, the cab panel gained the Free camera button, with a virtual direction pad to move the camera, and Exit free camera returns to the driver's seat; the notes do not say whether the gesture for moving the bus changed. If the problem is only where the bus spawns, choose another starting point on the launcher's Drive page before starting (the exact field names changed between launcher versions). Moving the bus does not repair a map with missing content or broken terrain: if there is no ground or road at the chosen point, moving the bus there may not help. See the questions about missing content and terrain. What to check: Is openOMSI on the current version? The behaviour of the F4 map has changed over the versions.; Is the destination a road on the map (and not woods, water or a tile with no content installed)?; Did the missing content warning appear when the map loaded?; If the bus got stuck on a bridge or an invisible wall on a modded map, see also the question about broken terrain.. Learn more: The map opens in the middle of the woods or far from the road; Missing or broken terrain; My map opens with missing objects or textures.

Question 61

What are the Apple Maps-style navigator and city map like?

Accepted Answer

This look arrived in Beta 0.3.34 and has been in the Stable version since 0.3.37. The navigator and the city map are drawn in the style of Apple Maps straight from the game's own map, with no map package needed: green terrain, fields, water, woods and single trees, train and tram tracks, and paved surfaces as they are (a car park becomes a grey yard). On the first visit to a map, the layers are read from its tiles, which takes a few seconds on a large map, and after that they are cached. Houses appear in 3D, with lit walls and soft shadows: always in the navigator and, on the city map, when you zoom in (there is a setting for 3D buildings and a 2D/3D button). All the buses, trams and trains in the timetable appear on the maps where the timetable has them, and the other players in a LAN or server session appear with their names. The navigator can become a widget that you drag and resize. After 0.3.37: 0.3.38 started drawing lanes, edge and stop lines, pedestrian crossings, arrows and real houses; 0.3.42 fixed the ground that vanished on large maps (street names appeared over an empty background). Learn more: 0.3.37 notes; 0.3.42 notes.

Question 62

My bus doesn't work or doesn't show up in openOMSI. What should I check?

Accepted Answer

The project's documentation says a bus made for OMSI 2 should work without changes, but that is a goal: the project is still early and some buses have problems. Before assuming it is a program bug, check the items below, since they are common causes: missing dependencies (models, textures, sounds or other packages), a folder in the wrong place and the openOMSI version. The game.log (in the .openomsi folder of your user account; on Windows, C:\Users\<você>\.openomsi) usually indicates the file that was not found. In one public report, for example, the log pointed to a missing .o3d model, and the advice was to check where to get the complete bus. In recent versions there are also two points that cause confusion. In 0.2.38, the launcher's bus list started showing one row per model, with the versions inside it: a bus may be “folded” under the model name. And, up to 0.2.37, large modded buses (the changelog mentions the EN92 and GN92) could end up without the 3D thumbnail in the launcher because the preview was still loading when the launcher was closed or a game was started; this was fixed in 0.2.38, and the previews that had been left out are tried again on every update. In other words, a missing thumbnail on an old version does not prove the bus is broken. According to the CHANGELOG, in 0.2.39 the manufacturer list in the bus selector went back to showing the manufacturers' full names. Since 0.3.0 (the Stable stabilisation release), the in-game vehicle lists went back to offering the Original paint option next to “Random livery”, and the bus preview in the classic launcher shows the chosen livery. Mod makers got a Model test in the launcher in 0.2.48, which loads the bus as on a trip, without a window, and lists warnings, errors and textures that do not exist. Also remember that openOMSI has two update channels (Settings > General > Updates): Stable (the default, tested versions) and Beta (for testers, with versions not yet tested); if a bus fails on a Beta, it is worth checking on Stable, and vice versa. According to the 0.3.42 notes (Stable), the launcher started showing the transport mode of maps and buses (tram, train, metro, trolleybus) and marks, with the reason, a vehicle that does not suit the chosen map, which then does not start (the game also refuses it): a bus that “won't open” on a tram map may be just that. According to the 0.3.37 and 0.3.42 notes, the Troubleshooting page in the Help menu lists what is wrong with the installed content (packages waiting for their bus, buses that take parts from packages that are not installed, failed installations) and brings the Model test (in the 0.3.37 notes the tool appears as *Content test*, in Settings; check where it is in your version). What to check: Read the game.log and look for “not found” or “cannot find” files.; Check that the bus has all its dependency packages installed.; Confirm it is in the Vehicles folder, in the expected structure.; On the launcher's Mods page, see whether the mod is listed as installed and is not switched off (the page lists each mod, lets you switch it off and on, and since 0.2.27 shows the content folder by folder). The launcher was rebuilt in 0.2.36; according to the CHANGELOG, 0.2.39 gave the Mods page back cancelling an installation, the file size check, filters and the content folder. If a button does not appear in your version, update. On phones, since 0.3.0 the Mods page has its own storage browser for installing a folder, a .zip, a .7z or a .rar (before that, “Add folder” and ZIP did nothing). Since 0.3.39, each mod on the page says in which game folders it put files and how many.; Update openOMSI and test again.; Check whether the bus has already been tested at /buscar.. Learn more: Search for this bus; Mod documentation; openOMSI Issues.

Question 63

The bus closes the game (crash) when loading or after a few seconds. Why?

Accepted Answer

An unexpected shutdown can have many causes: missing files, some bus feature that openOMSI does not handle yet, low video memory, the system (especially on phones) or the program version. You cannot conclude the cause just from the fact that the game closed. When the game closes, it usually generates a report in the game.log (in the .openomsi folder of your user account). Keeping that file helps a lot. According to the project's README, when the game ends with an error the launcher shows the error with the *Copy report* and *Report on GitHub* buttons (the names may appear translated), and Setup > Export diagnostics produces a ZIP bundle to attach to a report, without folders, names or addresses; nothing is sent by itself and you can look at the contents first (available since 0.2.18). Two common causes that the README mentions: a game that closes after a few seconds or with “the graphics device was lost” usually calls for an up-to-date video driver (the one from NVIDIA, AMD or Intel, not the one Windows installs), and on Windows it is worth switching to DirectX 12 in Settings > Graphics > Graphics API. Very old cards gained an “ANGLE (DirectX 11)” option in 0.2.17. There are public reports of specific buses that closed the game, including on Android, and they may or may not have already been dealt with in newer versions. Do not confuse this with another problem: since 0.2.31 openOMSI has a watchdog that only acts when a version does not even manage to open the launcher (it installs a newer version, goes back to the previous one or opens in safe mode). A crash in the middle of a trip, caused by a bus, does not trigger that recovery. According to the CHANGELOG, since 0.2.39 the launcher warns again when a game ends with an error or is sent away by the server. Two improvements in 0.3.0 help you understand what happened: when the video driver resets the card and the game comes back with lower graphics, the game now warns you instead of just looking worse; and, if the launcher crashes, its log now says where, which makes a report easier. Also in 0.3.0, openOMSI started opening again on older processors without POPCNT (before, “this app can't run on your PC” appeared). If the shutdown began on a Beta version, test the Stable one. If the problem is short video memory, 0.3.32 (Beta; in the Stable since 0.3.33) made high-quality passengers use a third of the graphics memory, and 0.3.33 started limiting everything the game keeps on the card through the Video memory setting (before, it could be exceeded by gigabytes) and made a card that runs out of memory stop losing the whole image. According to the 0.3.41 notes (Stable since 0.3.42), the Video memory limit now also counts the empty space the driver still holds on DirectX 12 and Vulkan: before, on a 12 GB card set to 6 GB, the driver held 11.5 GB after 18 minutes and the game dropped to 10 fps. That is a performance drop, not a shutdown, but it is worth testing that version if the problem only shows up after about half an hour of play. 0.3.41 also rejects malformed texture data before sending it to the video card (it uses a substitute texture and writes to the log), which closes one route to invalid textures, and, according to the 0.3.39 notes, on Android the launch after a crash shows the report window, with the GitHub buttons. This counts as “fixed since version X”, not as a guarantee. What to check: Update openOMSI to the latest version.; Test with another bus to find out whether the problem is only with that mod.; Check the dependencies and the missing content warning.; Update the video driver; if the log mentions “graphics device was lost”, try another Graphics API in Settings.; Keep the game.log right after the shutdown.; Note the system, device and version before asking for help.. Learn more: openOMSI Issues; Submit this test.

Question 64

The bus works in OMSI 2 but not in openOMSI. Does that mean openOMSI has a bug?

Accepted Answer

Not necessarily. openOMSI is a from-scratch recreation and is still an early project: it may not support some specific feature of a mod. But there may also be dependencies that are in your OMSI 2 and not in the openOMSI folder, different paths, an old version of the program or a bus feature (such as a plugin) that is not loaded the same way. So compare calmly: test other buses, check the files and see whether anyone has already tested that model. There are public reports of mods that work in OMSI 2 and have problems in openOMSI (displays, doors, animations); if that is your case, it is worth registering the result. A lot has changed in this area in the 0.2 series, and an old report may no longer apply. According to the CHANGELOG, for example: destination displays that showed all the variants of a sign at the same time were fixed in 0.2.25; LED destination displays became bright again in 0.2.26; displays that depend on a variable declared only in the model (the Enviro500 case) appeared again in 0.2.31; LED matrices with [matl_alpha] after [matl_change] no longer light up every dot in 0.2.28; and the automated gearbox was adjusted for low-revving buses (0.2.21) and for scripts that keep the gear in their own variable (0.2.33); and, in 0.2.39, door keys stopped triggering two different doors at once (cases cited: GPM C2, Urbanway and Citelis). In 0.3.0, for example, the starting sounds and other triggered sounds that began at zero volume came back, as did the timetable sheet inside the bus and passengers reading the destination from what the bus display shows; in 0.2.48 a livery's folder stopped painting over the details of other liveries, and a paint scheme's [setvar] entries began to be written before each frame of the scripts (the IK-201 display went back to showing only Latin letters because of this). More recently, according to the release notes (Beta from 0.3.32, Stable since 0.3.33): stop departure displays, such as the HVV ones in HafenCity Hamburg, went back to showing lines, destinations and times (0.3.32); timetable buses appear when their trip starts, and articulated buses started to steer the rear axle (0.3.32); instruments printed on the dashboard and signs stopped flickering against the surface they sit on (0.3.33); and headlamps now have the beam coming out of the bus's own headlamps (0.3.33). According to the notes from 0.3.34 onwards (Stable up to 0.3.42): scripts with {else} chains and with $SetLength now work as in OMSI 2 (cases cited: the DBC Chicago Citybus fare box and the Kruger++ matrix display); bus scripts that make a long query at start-up work again, with the destination sign, the IBIS and the Citaro C2 screens in Grand Paris-Moulon; the route text on destination displays no longer vanishes when the camera moves a few metres away (0.3.39); a layered dashboard display no longer hides the front door graphic behind it (ADL Enviro500MMC Facelift, 0.3.40); and the MAN DN95 no longer shows up as a mirror (0.3.41). Treat this as “fixed since version X”, not as a guarantee for your bus. People who create or tweak buses can use the game's developer tools (Ctrl+Shift+D, since 0.2.28), which show and hold script variables and draw paths, seats and mirrors over the bus. The project's MODDING.md also lists what openOMSI accepts beyond OMSI 2 (such as more than four interior lights per mesh); a file that uses this still loads in OMSI 2, which ignores what it does not know. According to the 0.3.34 notes (Stable in 0.3.37), several [visible] conditions of a mesh can be combined with [visible_range], ! and ||; meshes with only a simple [visible] keep the OMSI 2 rule. What to check: Check that openOMSI is reading the content folder where the bus and its dependencies are.; Update openOMSI; some buses were adjusted in recent versions.; Look at the game.log and the missing content list.; Look up the bus at /buscar and register your test at /testar.; If the problem looks like the program's, search for or open an Issue with the version and game.log.; On builds before 0.1.538, TGA textures named .png, .bmp or .jpg could go missing: update before renaming files.. Learn more: Search for this bus; Register a test; openOMSI Issues.