Bugs

Bugs that exist in the vanilla Morrowind engine and their status with regards to the OpenMW engine.

This page tracks engine bugs only. Bugs in the game data files or assets should be tracked elsewhere.

See also:
 * Dialogue script bugs
 * Morrowind Data File Bugs

Please note due to the nature of OpenMW being a complete rewrite, most of MW engine bugs never affected it in the first place, so this page is very likely incomplete. If you know of any additional bugs, please add them here.

Legend
Status:


 * Can not fix : This bug can not be fixed without breaking gameplay or rebalancing the game. Eventually we may want to introduce a fix for this issue, but it has to be controlled by an option that is disabled by default so as to not break the vanilla game files.
 * Fixed : This bug or exploit was fixed. Eventually we may also want an option to disable the fix, for purists who like to play the game with its original bugs / exploits.

Impact:


 * Low : No impact on the actual vanilla game experience, but may be a potential pitfall for content developers.
 * Medium : Has a noticable gameplay impact.
 * High : Actually breaks vanilla gameplay in a way the developers did not intend to.

{| class="wikitable sortable" border="1" !Description !Status !Impact !Explanation
 * Stats of actors in unloaded cells can't be changed
 * Scripts can not change the stats of actors in cells that haven't been loaded yet. Notably this was used in the end game scripts. Killing an ash vampire was supposed to reduce Dagoth Ur's health by a certain amount. This never worked in the original game due to the aforementioned bug, but worked in openmw. Interestingly enough, when it started working, a mistake in the scripts was revealed: killing all ash vampires would reduce the health of the first Dagoth Ur instance by so much that he would be dead by the time the player arrived. A very intrusive workaround was put in place to prevent this.
 * Ignored speed attribute for water creatures
 * The Speed attribute for most water creatures is ignored. This is because the movement animation system plays animations without speed scaling if a fallback animation was used (such as falling back to "RunForward" when "SwimRunForward" was requested). This can not be fixed without patching game data as it would require rebalancing the speed values for water creatures in the game. Code location
 * Inconsistent animation text key usage
 * When there are multiple "Stop" animation text keys with the same name (which should not happen, but has apparently happened by accident in some vanilla assets), the behaviour depends on the context. When playing back the animation, the first occuring stop key is used for playback. When calculating the velocity of an animation as used for the movement animation controller, the last occuring stop key is used. As result the animation is played with an inaccurate speed multiplier. Can not be fixed without patching the broken assets. Code location
 * AiTravel distance limit
 * The travel AI will not travel to distances further away than 7168 units. This may have been added to prevent NPCs from travelling to non-loaded exterior cells, but curiously the limit also applies to interior cells. Fixing this would cause controversial behaviour in a vanilla quest. Code location
 * Race height does not affect physics
 * The various races have a "Height" property that scales their model, i.e. Nords are taller than Bosmer. This scale is only applied to the rendering system and not to the physics controller. Fixing this would make certain dungeons unpassable for certain characters. A possible explanation would be that the MW developers designed the environments before work on races was completed, and did not want to re-test all the environments for physics issues with different character heights.
 * Framerate dependent frequency of idle voices
 * The trigger for Idle voices suffers from a design flaw that causes NPCs to chatter more when the game is running at a higher frame rate. See the research page for more details. The framerate dependency was fixed and the frequency of voices was calibrated on vanilla behaviour at 60 FPS. Additionally, changes to the fVoiceIdleOdds GMST did not have the intended effect due to quantization issues, which were also fixed.
 * Diagonal movement is faster
 * Moving diagonally, e.g. by holding Left and Forward, would move faster by a factor of sqrt(2) than just holding Forward.
 * Obvious mechanic bugs
 * Being fatigued made it easier to repair items. The Blindness effect increased the chance of hitting your target instead of decreasing it. This list is incomplete, there were more fixes, which can be found scattered around on the Research page.
 * Various unused GMSTs
 * Various GMSTs are unused by the vanilla engine, even though the value they are set to by default matches the value used in the game mechanic. Affects fBlockStillBonus, fDamageStrengthBase, and fDamageStrengthMult.
 * Calendar error
 * The month of "Morning Star" depicted in the lore was not present in Morrowind, most likely omitted by accident. This was also fixed by MCP.
 * Training exploit
 * The training mechanic uses the Modified skill to calculate the price, but actually operates on the Base skill. Could be exploited by using a Drain spell to get cheaper training.
 * Friendly hits reset
 * The counter for friendly hits on a follower will reset when saving and loading the game. This can be exploited to kill followers without them being able to fight back. Since there does not seem to be another mechanic in place for resetting the friendly hit counter (which admittedly should happen every once in a while) we chose to not fix this for now.
 * Infinite item restock
 * Selling an item to a merchant that has a restocking supply of that item will permanently increase the restock capacity. This can be exploited to buy thousands of items very quickly. I believe this was even mentioned in the TES-CS manual, so it may have been intended by the developers, and we should add an option to disable this fix.
 * Owner contamination
 * When an item owned by an NPC is stolen, all items of that base ID will be flagged stolen, forever, even if they were obtained elsewhere. OpenMW keeps track of a "stolen count" for how many of these items were actually stolen.
 * Various script engine limitations and bugs
 * See Features
 * Sound range limitations
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * Moving diagonally, e.g. by holding Left and Forward, would move faster by a factor of sqrt(2) than just holding Forward.
 * Obvious mechanic bugs
 * Being fatigued made it easier to repair items. The Blindness effect increased the chance of hitting your target instead of decreasing it. This list is incomplete, there were more fixes, which can be found scattered around on the Research page.
 * Various unused GMSTs
 * Various GMSTs are unused by the vanilla engine, even though the value they are set to by default matches the value used in the game mechanic. Affects fBlockStillBonus, fDamageStrengthBase, and fDamageStrengthMult.
 * Calendar error
 * The month of "Morning Star" depicted in the lore was not present in Morrowind, most likely omitted by accident. This was also fixed by MCP.
 * Training exploit
 * The training mechanic uses the Modified skill to calculate the price, but actually operates on the Base skill. Could be exploited by using a Drain spell to get cheaper training.
 * Friendly hits reset
 * The counter for friendly hits on a follower will reset when saving and loading the game. This can be exploited to kill followers without them being able to fight back. Since there does not seem to be another mechanic in place for resetting the friendly hit counter (which admittedly should happen every once in a while) we chose to not fix this for now.
 * Infinite item restock
 * Selling an item to a merchant that has a restocking supply of that item will permanently increase the restock capacity. This can be exploited to buy thousands of items very quickly. I believe this was even mentioned in the TES-CS manual, so it may have been intended by the developers, and we should add an option to disable this fix.
 * Owner contamination
 * When an item owned by an NPC is stolen, all items of that base ID will be flagged stolen, forever, even if they were obtained elsewhere. OpenMW keeps track of a "stolen count" for how many of these items were actually stolen.
 * Various script engine limitations and bugs
 * See Features
 * Sound range limitations
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * Training exploit
 * The training mechanic uses the Modified skill to calculate the price, but actually operates on the Base skill. Could be exploited by using a Drain spell to get cheaper training.
 * Friendly hits reset
 * The counter for friendly hits on a follower will reset when saving and loading the game. This can be exploited to kill followers without them being able to fight back. Since there does not seem to be another mechanic in place for resetting the friendly hit counter (which admittedly should happen every once in a while) we chose to not fix this for now.
 * Infinite item restock
 * Selling an item to a merchant that has a restocking supply of that item will permanently increase the restock capacity. This can be exploited to buy thousands of items very quickly. I believe this was even mentioned in the TES-CS manual, so it may have been intended by the developers, and we should add an option to disable this fix.
 * Owner contamination
 * When an item owned by an NPC is stolen, all items of that base ID will be flagged stolen, forever, even if they were obtained elsewhere. OpenMW keeps track of a "stolen count" for how many of these items were actually stolen.
 * Various script engine limitations and bugs
 * See Features
 * Sound range limitations
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * Selling an item to a merchant that has a restocking supply of that item will permanently increase the restock capacity. This can be exploited to buy thousands of items very quickly. I believe this was even mentioned in the TES-CS manual, so it may have been intended by the developers, and we should add an option to disable this fix.
 * Owner contamination
 * When an item owned by an NPC is stolen, all items of that base ID will be flagged stolen, forever, even if they were obtained elsewhere. OpenMW keeps track of a "stolen count" for how many of these items were actually stolen.
 * Various script engine limitations and bugs
 * See Features
 * Sound range limitations
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * Various script engine limitations and bugs
 * See Features
 * Sound range limitations
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * See Features
 * Sound range limitations
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.
 * Sounds played with the playLoopSound family of functions have a hardcoded range limit of 2000 units, independent of the range specified in the sound record. Does not apply to non-looping sounds. This can not be fixed without causing excessively loud audio in vanilla MW. We could however work on a gradual fade instead of cut-off.


 * Non-uniform scaling bugs
 * There are plenty of bugs with the non-uniform scaling induced by the Weight and Height properties of races, for example incorrect emit direction of particles, as can be seen the differences wielding the Trueflame sword on races with different weights.
 * Disintegrate magic effect bug
 * The disintegrate effect reduces the health of armor and weapons over time. Unfortunately the weapon/armor health is stored as an integer in the game files, meaning damage less than 1.0 per frame can not be applied. For example, with the game running at 60 fps, a disintegrate effect needs to have a magnitude of at least 60 pts to apply at all. Bug 2777
 * There are plenty of bugs with the non-uniform scaling induced by the Weight and Height properties of races, for example incorrect emit direction of particles, as can be seen the differences wielding the Trueflame sword on races with different weights.
 * Disintegrate magic effect bug
 * The disintegrate effect reduces the health of armor and weapons over time. Unfortunately the weapon/armor health is stored as an integer in the game files, meaning damage less than 1.0 per frame can not be applied. For example, with the game running at 60 fps, a disintegrate effect needs to have a magnitude of at least 60 pts to apply at all. Bug 2777
 * The disintegrate effect reduces the health of armor and weapons over time. Unfortunately the weapon/armor health is stored as an integer in the game files, meaning damage less than 1.0 per frame can not be applied. For example, with the game running at 60 fps, a disintegrate effect needs to have a magnitude of at least 60 pts to apply at all. Bug 2777
 * The disintegrate effect reduces the health of armor and weapons over time. Unfortunately the weapon/armor health is stored as an integer in the game files, meaning damage less than 1.0 per frame can not be applied. For example, with the game running at 60 fps, a disintegrate effect needs to have a magnitude of at least 60 pts to apply at all. Bug 2777
 * The disintegrate effect reduces the health of armor and weapons over time. Unfortunately the weapon/armor health is stored as an integer in the game files, meaning damage less than 1.0 per frame can not be applied. For example, with the game running at 60 fps, a disintegrate effect needs to have a magnitude of at least 60 pts to apply at all. Bug 2777