OpenMW: the data path, the stricter script compiler, and the mods that stop loading

The data path is the one thing OpenMW cannot start without

OpenMW is an open source open world RPG game engine that supports playing Morrowind by Bethesda Softworks, and you need to own the game for OpenMW to play Morrowind. That single sentence decides the shape of every other problem. The first thing the engine has to resolve is not a setting but a location. The data path tells OpenMW where to find your Morrowind files. If you run the launcher, it should be able to pick up the location of these files on its own, if both Morrowind and OpenMW are installed properly, and installing Morrowind under WINE is considered a proper install. When that guess fails, the command line takes over. The syntax line reads openmw <options>, and four documented flags carry the paths:

openmw --version
openmw --help
openmw --data data
openmw --resources resources --user-data saves

The option table spells out what each one owns:

      --data arg (=data)                    set data directories (later directories
                                             have higher priority)
      --data-local arg                      set local data directory (highest
                                             priority)

So the game data has two entry points, a normal list where later directories win and a local directory that outranks them, while --resources defaults to a directory named resources and --user-data holds saves and screenshots. --config adds further config directories. The project also publishes no install command of its own: the Getting Started list sends you to a separate installation instructions page for binaries and to a wiki page for building from source.

--replace is the switch between overriding and appending

Two of the path flags are really about layering. --config takes additional config directories, and --replace names the settings where the values from the current source should replace those from lower-priority sources instead of being appended. That one option decides whether a config directory you add wins or joins. For a setting the engine treats as a list, the documented behaviour without --replace is appending, so entries from two directories can end up sitting in the same list instead of your value replacing the earlier one. The same append versus replace question comes back through the priority rules rather than through a config flag: later directories under --data have higher priority, --data-local holds the highest priority of all, and later archives under --fallback-archive have higher priority. What the table does not say is which settings count as lists, or what format the files inside a config directory use. --fallback-archive also shows a name that sounds like an error recovery path but is documented as a plain priority list of BSA archives, with later archives winning, which matters when an addon archive and a base archive both define the same record.

The script compiler rejects mods that Morrowind ran anyway

Pre-existing modifications created for the original Morrowind engine can be hit-and-miss, and the reason is mechanical rather than a matter of taste. The OpenMW script compiler performs more thorough error-checking than Morrowind does, which means that a mod created for Morrowind may not necessarily run in OpenMW. Some mods also rely on quirky behaviour or engine bugs in order to work. The project considers such compatibility issues on a case-by-case basis: in some cases adding a workaround to OpenMW may be feasible, in other cases fixing the mod will be the only option. Nothing in that process happens by itself, so a mod list assembled for the retail engine carries no guarantee once you move to this one. The practical consequence is that a save from the original game plus a folder of mods is not a working combination here without checking. The wiki has a Mod status page, and the project asks people who know which mods work or do not work to add them, which makes that page a crowd report rather than a compatibility test run by the maintainers.

--script-warn 2 turns a warning into a failed compile

The script compiler has exactly one knob for how much it complains, and it has three positions:

      --script-warn [=arg(=1)] (=1)         handling of warnings when compiling
                                             scripts
                                             0 - ignore warnings
                                             1 - show warnings but consider script as
                                             correctly compiled anyway
                                             2 - treat warnings as errors

The default is 1, which shows warnings and treats the script as correctly compiled anyway. Zero ignores them outright. Two treats warnings as errors, so a script that merely warned under the default now fails to compile and the content that carries it does not load. That default is the forgiving choice for a large mod folder, and it is also why a warning you saw once may never have mattered. Three startup flags sit around it: --script-all compiles all scripts, excluding dialogue scripts, at startup, --script-all-dialogue compiles all dialogue scripts at startup, and --script-console enables console-only script functionality. --script-run selects a file containing a list of console commands that is executed on startup, which is the hook for driving a session from a script. Compiling everything at startup trades launch time for knowing about errors before you load a save.

All three campaigns finish, and the 1.0 milestone is still open

Completable is the word the project uses, and it covers the main quests of Morrowind, Tribunal and Bloodmoon. Side quests are the other half of that sentence: some issues with side quests are to be expected, though rare. The engine is therefore past the stage where campaigns stop early, and short of the stage where every side thread resolves cleanly. The bug tracker holds a milestone titled openmw-1.0 listing the issues that need resolving before the 1.0 release, and issues carrying the Bug label form the known issues list. That milestone is the honest answer to how close 1.0 is, and it is worth reading before you decide anything, because nothing here names a version in which the remaining side quest problems are fixed, and nothing lists which side quests are affected. Improvements have landed regardless of the version number: the README points at a features page and names improved graphics and user interfaces as things OpenMW already has before 1.0. Newcomers chasing the original engine should also know that mod behaviour is judged against the compiler, not against the quests.

--new-game is ignored unless --skip-menu is set too

The startup flags carry one dependency worth memorising:

      --load-savegame arg                   load a save game file on game startup
                                             (specify an absolute filename or a
                                             filename relative to the current
                                             working directory)
      --skip-menu [=arg(=1)] (=0)           skip main menu on game startup
      --new-game [=arg(=1)] (=0)            run new game sequence (ignored if
                                             skip-menu=0)

--new-game runs the new game sequence and is ignored if skip-menu=0, while --skip-menu defaults to 0, so passing --new-game on its own changes nothing and the main menu still appears. Content comes in through --content, which takes esm/esp files or the OpenMW containers omwgame, omwaddon and omwscripts, and through --groundcover, which takes esm/esp or omwgame/omwaddon. --start sets an initial cell, which decides where a session begins. --no-sound disables all sounds and also defaults to 0, so leaving it out keeps audio on. The trap in --load-savegame is the second half of its own description: a relative filename resolves against the current working directory, so the same command finds your save or does not depending on the directory you ran it from, and an absolute filename avoids that. The save directory itself is set through --user-data, which the table describes as used for saves and screenshots.

The version line on master runs ahead of the newest release tag

The version in the project header and the release tags tell different stories, which matters the moment you file a bug. The README header states Version: 0.53.0. The newest tag is openmw-52-rc1, named OpenMW 0.52.0 RC1 and published on 2026-11-01, preceded by openmw-0.51.0, named OpenMW 0.51.0 Released, on 2026-06-19 and openmw-51-rc2 on 2026-04-29. So the default branch, which is master, advertises a version that carries no tag yet, and a report against a 0.51.0 build is not the same report as one against master. The last push to master was on 2026-11-01, and the repository is not archived. The tree is what you would expect from a C++ engine that publishes its own manual:

apps/
cmake/
components/
CI/
docker/
docs/
extern/
files/
manual/
scripts/
CMakeLists.txt
AUTHORS.md
CHANGELOG.md
CONTRIBUTING.md

There is no package manifest, no installer script and no prebuilt binary in that list, and the presence of CI/ and docker/ says the build is expected to run somewhere automated rather than from a file you can double-click.

Fonts ship with their own licences, and no binaries sit in the tree

The engine brings its own editor and its own fonts, and both come with terms attached. OpenMW also comes with OpenMW-CS, a replacement for Bethesda's Construction Set, which is the half of the project that deals with content creation rather than playing. DejaVuLGCSansMono.ttf is under a custom licence described in files/data/fonts/DejaVuFontLicense.txt. DemonicLetters.ttf and MysticCards.ttf are under the SIL Open Font License, with files/data/fonts/DemonicLettersFontLicense.txt and files/data/fonts/MysticCardsFontLicense.txt named alongside them. The engine itself is GPLv3, and the LICENSE file sits at the repository root. None of that answers the first question a new user asks, which is where the binary comes from. The Getting Started list points at an installation instructions page in the readthedocs documentation and a wiki page for the development environment setup, and it names no download location, no package repository and no build command of its own. The same list points at the bug tracker, the known issues list, and bug reporting guidelines to read before submitting a first bug, which is where the practical knowledge about running the thing actually lives.

Editorial conclusion

OpenMW fits players who own Morrowind, want Tribunal and Bloodmoon running on a setup they control, and are willing to read a wiki page before each mod. It does not fit anyone waiting for a sealed 1.0 release or for a mod list that simply works. Before you commit, check how the launcher resolves the data path on your own install, read the openmw-1.0 milestone to see what is still listed as broken, and look your mods up on the Mod status page, because the engine states outright that its compiler checks more thoroughly than the one those mods were written against.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. OpenMW/openmw on GitHub
3. Project website
4. README
5. Releases