Bug Reporting Guidelines

Search for duplicates
Before doing anything else, use the Search function to check if your particular issue has already been reported. Searching for the important keywords (e.g. "dead npc collision") usually works best.

Subject
Give a description of the problem, and the circumstances under which it occurs. Prefer a long, descriptive title.

'''Good: '''When opening a container and selecting "Take All", the screen flashes blue

'''Bad: '''Container issue

Please do not add additional information (e.g. OpenMW version) to the subject. This will only make it harder for us to browse the issue list. Instead, add it to the Description field.

Description
Describe the issue as detailed as you can. Below is a list of questions that should be answered in the description (if they apply).

player->getpos x player->getpos y player->getpos z
 * Is the problem OpenMW specific or does it also happen in vanilla Morrowind?
 * Do you use any mods? If so, does the problem also occur in a clean vanilla install without any mods?
 * What version of OpenMW did you encounter the problem with? If you used a bleeding edge build, state the exact revision used.
 * What are the exact steps to reproduce the problem?
 * What did you expect to happen? What happened instead?
 * Where is the in-game location this problem can be observed? Avoid vague statements such as "west of town X". Instead, use the getpos console commands to get the exact location. When done, you can copy the results to the system clipboard.

Note: in OpenMW 0.31 (and later versions), this is even easier: open the console, click on the problematic object, then use the betacomment (bc) instruction:

bc, ""

It will print lots of useful information about the object that you can copy and paste into the bugreport: Content file: Morrowind.esm RefID: ex_nord_door_01 Cell: Caldera Coordinates: Vector3(-12472, 20680, 1652)

Reproducibility
Does the problem occur everytime, or sometimes, or randomly, or did it only occur once and was not reproducible again?

Operating System
What operating system where you using when you experienced the issue? If it occurred on multiple OSes, or you are absolutely sure it is not an OS-specific issue, select Other.

Other fields
Please leave all the other fields blank. They will be filled in by the OpenMW team once we have taken a closer look at the issue.

Screenshots/videos
Feel free to attach screenshot(s) or videos of the problem. Often this does a much better job of conveying what the problem is than a wall of text.

Savegames
If the problem occurs when loading a specific savegame, make sure to attach it. Note that savegames are not fully compatible across MW installations of different languages, so you should state what language your MW installation uses.

See Paths for the location of save files.

Logs & configuration files
Below is a list of configuration files and logs used by OpenMW that can be extremely useful for us in finding the problem. If in doubt, just zip the whole configuration folder and attach it.

See Paths for the location of logs & configuration files.

Note: Please use the issue tracker's file attachment function rather than an external host (dropbox, etc) so we can be sure the files stay available as long as needed.

OpenMW-specific
openmw.log (Used by OpenMW 0.31 and later versions)

Contains game messages and errors.

openmw.cfg

Contains the names of used esm/esp files, bsa archives, data directory and imported Morrowind.ini settings. Always a good idea to attach.

settings.cfg

Contains user settings as configured by the launcher or the ingame settings menu.

ogre.log

Contains errors and messages from Ogre3D. Also contains detailed information about your graphics card. Always attach this if you are having a graphics related issue.

MyGUI.log

GUI system messages. Always attach in case of GUI issues.

input.xml

Contains saved input bindings. Does not need to be attached, unless you are having a problem with input bindings.

Launcher-specific
launcher.cfg launcherOgre.log

OpenCS-specific
opencs.cfg opencsOgre.log

Terminal output
Always watch the terminal output. If you see errors, warnings or exceptions, make sure to attach it.

Stick around
After you've reported the issue, make sure to check back occasionally (or enable email notifications) in case we require more information from you.

Explanation of issue states
Do not get discouraged when some of your issues get rejected, and feel free to continue reporting any other issues you find.
 * Resolved - A developer has fixed the issue, but the fix has not been reviewed by others and is not included in the official main repository (yet).
 * Closed - The fix is now available in the main repository. If you still see the issue happening, then complain!
 * Rejected - The issue was invalid. This can happen for several reasons:
 * 1. It is a duplicate of another issue that was already reported earlier (watch for "Duplicates #XYZ" in the activity log).
 * 2. It is a bug in the game data, and not in the engine, so OpenMW cannot fix it.
 * 3. The bug is not reasonably fixable due to constraints outside of our control.

Test git master
If you are reporting issues frequently, it might be a good idea to switch to testing bleeding-edge builds. That way you can test out the newest features, and we get less reports of problems that have already been fixed in the development version.

We maintain nightly builds for Windows and an Ubuntu PPA. You can also build yourself, which is rather easy on Linux and only takes a few minutes. See Development_Environment_Setup.

Obtain a stack trace
If the problem is a crash or an exception, you can help us by providing a stack trace.

On windows, this requires having a build environment set up.

On linux, a stack trace is automatically created and a window will pop up telling you where to find it. To work properly, this requires gdb to be installed.

For non-fatal exceptions, OpenMW will not exit. To get a stack trace anyway, you need to launch OpenMW in the debugger and tell it to break on exceptions. For gdb, this can be done with the 'catch throw' command.

Bisect
If the problem is a regression, i.e. earlier versions of OpenMW did not suffer from the problem, you can help us by identifying the revision that introduced the problem. The git bisect tool makes this very easy. You need a build environment set up to do this.

Start the bisect process using:

git bisect start

Mark the HEAD revision as bad:

git bisect bad HEAD

Mark a tag or revision as good (you can get a list of all tags using git tag -l):

git bisect good openmw-0.29.0

A revision will now be checked out and you need to build and test whether the problem exists in this revision. If a revision fails to build for some reason, do

git bisect skip

to skip it. Once you have found a good or bad revision, mark it using either

git bisect good

or

git bisect bad

Now git will checkout the next revision to test. Repeat this process until the first bad commit has been found. Usually this will only take a couple of steps, since it is a binary search.