Bug Reporting Guidelines

Search for duplicates
Before doing anything else, use the Search function to check if your particular issue has already been reported. Please note the bugtracker Search function is somewhat clunky and only matches exact keywords. Try searching for keywords describing your issue (e.g. "dead npc collision"). If that didn't work, try using Google.

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

'''Good: '''Screen flashes blue when opening a container and selecting "Take All"

'''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).


 * 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, open the console (F2 by default), click on the problematic object, then use the betacomment (bc) instruction:
 * Are there any error messages in the openmw.log file (see Bug_Reporting_Guidelines?

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.

Attach files
Note: Where possible, 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.

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.

See Paths for the location of save files.

It is a good idea to compress savegames before uploading them (.7z, .rar, .zip, ...) and will also make it less likely to exceed the filesize limit of the bugtracker (5 MB).

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.

OpenMW-specific

 * openmw.log: Contains game messages and errors.


 * openmw.cfg: Contains the names of used esm/esp files, bsa archives, data directory and imported Morrowind.ini settings.


 * 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_v2.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

OpenMW-CS-specific

 * opencs.ini
 * opencsOgre.log

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.