Bug Reporting Guidelines
Search for duplicates
This goes without saying - 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.
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.
- 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?
- 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?
Does the problem occur everytime, or sometimes, or randomly, or did it only occur once and was not reproducible again?
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.
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.
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.
If the problem occurs when loading a specific savegame, make sure to attach it. Note that savegames are not compatible across MW installations of different languages, so you should state what language your MW installation uses.
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.
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.
Contains the names of used esm/esp files, bsa archives, data directory and imported Morrowind.ini settings. Always a good idea to attach.
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.
GUI system messages. Always attach in case of GUI issues.
Contains saved input bindings. Does not need to be attached, unless you are having a problem with input bindings.
Always watch the terminal output. If you see errors, warnings or exceptions, make sure to attach it.
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.
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.
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
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.