This is a project to fix bugs in Morrowind that just aren't possible to do with scripting alone. It comes in the form of a patch to the Morrowind program.

The primary fix included is a large change to the savegame code to reduce the majority of crashes, corruption, and missing objects. It also makes the game properly respond to changes in your load list, making inserting and removing mods from your savegames a lot safer. There are many more smaller fixes that cover all areas of the game.

All fixes and gameplay changes included are optional, you can independently select which ones you want to use in the installer.

Morrowind Code Patch is fully compatible with MPP, MGE, MWSE and MWE. It should work with the Steam edition of Morrowind now. Also, improved Russian version compatibility (supports GFM dll).

Version 1.7 is out now.
Files: http://www.tesnexus.com/downloads/file.php?id=19510 http://www.fliggerty.com/phpBB3/viewtopic.php?f=53&t=1008

New features in 1.7:

- Toggle sneak. Sneak key toggles sneak mode on or off.
- Inventory bugs. Now also fixes an issue with items sticking in inventory when they were supposed to removed by a quest or script.
- Inventory bugs. Fixed a previously introduced bug where soul gems didn't update properly when soul trapping using only touch spells.
- Delayed spell crash fix. Fixes a crash situation where uncast spells remained in memory or savegame.
- Loud armor / shield fix. Fixes occasional ridiculously loud armor hit sounds.
- Unrestrict menu size. Allows stats menu and magic menu to be resized without limit.
- Enable reflection effects on skinned models. Allows skinned objects to have shiny reflection maps.
- Createmaps fix. Causes the createmaps command to skip over interiors, reducing the amount of time it takes to complete.
- Polish keyboard support. Allows typing of Polish characters in-game.
- Better quality splash and title screens. Fixes colour depth issues which reduced splash/title screen quality.
- Spellmaking max. magnitude. New magnitude limit changed from 1000 to 500.
- Transparent clothes in inventory. Should no longer cause the mouse cursor to sometimes have a thin black outline.
- Enchant glow in fog. Slightly optimized, should no longer be linked to transparent clothes fix.



See the previous threads to see how this came about:
Repairing those Cogs http://www.gamesas.com/index.php?/topic/1090176-repairing-the-cogs-of-morrowind-no-18/ http://www.gamesas.com/index.php?/topic/1084044-repairing-the-cogs-of-morrowind-no-17/ http://www.gamesas.com/index.php?/topic/1041353-repairing-the-cogs-of-morrowind-%2316/ http://www.gamesas.com/bgsforums/index.php?showtopic=1032219 http://www.gamesas.com/bgsforums/index.php?showtopic=1026266 http://www.gamesas.com/bgsforums/index.php?showtopic=1013291 http://www.gamesas.com/?showtopic=1009430 http://www.gamesas.com/bgsforums/index.php?showtopic=978076 http://www.gamesas.com/bgsforums/index.php?showtopic=942375 http://www.gamesas.com/bgsforums/index.php?showtopic=925813 http://www.yacoby.net/es/forum/12/9111491226747880.html http://www.yacoby.net/es/forum/12/8942761225301640.html http://www.yacoby.net/es/forum/12/8891531224348540.html http://www.yacoby.net/es/forum/12/8852991223287560.html http://www.yacoby.net/es/forum/12/8837531222826580.html http://www.yacoby.net/es/forum/12/8812671222030860.html http://www.yacoby.net/es/forum/12/8792971221418740.html http://www.yacoby.net/es/forum/12/8744651220076840.html
thread #9 may not have been archived on the forum.

Don't forget the latest http://www.tesnexus.com/downloads/file.php?id=26348 version

Oh... on the subject of balancing. Something that I noticed tonight while watching my roommate play Morrowind: He used a grand soul gem to enchant 400 steel throwing stars with 1 point of absorb health. The fix which allows the enchanting of ammunition creates a number of objects equal to the soul value used to enchant them, assuming the player has a sufficient quantity. However, because of the way the enchanted value fix works, the use of a grand soul gem (even on something with as low a value as a steel throwing star) creates a very valuable enchanted object. And not just one, but 400 of them.

So while it might improve the economy of the game to restructure the value of soul gems, adjusting a golden saint soul from 80,000 down to 7,200 is only a first step, and a meaningless one if the calculation for enchanted items isn't also taken into account. That same much less valuable soul gem can still be used to create 400 enchanted throwing daggers worth 8,000 gold each (that's over 3 million gold). Not only does the value of a custom enchanted item need to be toned way down, but if possible, the value of enchanted ammunition needs to be changed so that it reflects the group quantity. e.g. if you make 400 throwing stars, then the calculated value of 8,000 gold should apply to all 400 as a group, not to each of 400. That would bring the value down to 20 gold each, which is much more practical.

Since neither the value of custom enchanted objects nor the manner in which ammo is enchanted can be adjusted in the construction set, it will need to be balanced within the MCP.

While we're talking about custom-enchanted ammo, I would like to be able to enchant fewer than the required maximum number of items at once. For example, let's say I have all eleven Daedric Darts normally available in the game. There are no 11-point soul gems, so I'd like to be able to use a larger filled soul gem to enchant however many items of ammo I'm trying to enchant at the time (whatever number I have in my inventory up to the maximum allowed by that soul gem). This would allow me to enchant all eleven, or enchant them one at a time (temporarily dropping the others on the ground). Was this option discussed when the feature was first proposed for addition?

I've been having a problem using the toggle sneak option with riding mods. (Abot's Guars and Pegas Horse Ranch, specifically.) It seems like anything requiring the sneak button to be tapped instead of held does not play well with it. I can never press it fast enough to slow down my Guar without dismounting.

The enchanted item price increase has already been adjusted in the last beta. You would have to evaluate things on your end to be sure, but price increases of 8000 should no longer be possible. Thrown weapons probably still need a review. No-one really discussed any of the additions back then, it was accepted as a cool feature but no concern over balance. The enchantment capacity of projectiles really needs to be revised somewhere.

The enchanting restriction can be easily changed, but I felt there needed to be an in-game message for the many people who don't read how it is supposed to work. Since you came up with a reasonable downside it's worth changing. While we're there, should we change the soul required per item to 5 or 10 soul per item?

Riding mods are probably best fixed by changing the mods' scripts. Ask around for assistance if you need it.

I could see a messagebox popping up to notify the player, for example: "Only 11 were enchanted (of a possible 200) due to limited quantity in inventory." I agree that it shouldn't be impossible to enchant a quantity less than maximum, but I also agree that a warning box would be appropriate whenever that condition occurs. I still think that the enchanted price should be calculated and then divided up amongst the potential ammunition and the new value or the base value should apply, whichever is greater. That would prevent a magically enchanted weapon from ever being LESS valuable than the unenchanted version, but it would also ensure that there aren't massive quantities of very valuable items created from a single soul gem. If dividing the value amongst the finished product is even possible, I'd recommend using the potential quantity instead of the actual quantity. If you permit less than the maximum to be produced, a single golden saint soul could create anywhere from 1 enchanted ammunition all the way up to 400 of them, and it wouldn't make sense that ammunition which has 1/2 the quantity would have 2x the value. Instead, the value should always be determined by what COULD have been made, so that whether the user creates 10 or 100, the ammunition value will be the same.

As to cutting the soul per item, I'd recommend against that. Your suggested values would limit someone to no more than 40-80 of any given item. And while that might be fair from the individual enchanting aspect, if the enchant-maker was capable of making multiple batches with the same object ID (like the potion-maker can do) then I would say that would be fine. But since the enchant-maker uses a different ID each time even if the base object and selected enchantment are identical, there's no way to replicate a batch of arrows, so there's no way to make a large quantity that can stack or be used together if such a plan were implemented (unless you can fix the enchant-maker to use IDs more like the potion maker, which would be really cool!) From a role playing standpoint, the suggestion makes a great deal of sense, but the game mechanics make such an idea messy and undesirable, IMO.

As to the issue with enchant pricing, I'm using the version 1.7 patch, but not the new beta, and I noticed that enchanted arrows and bolts do NOT seem to increase in value while thrown weapons seem to increase drastically. Reducing the enchanted value will be a big help, although I think dividing the enchanted value over the group would be better. If doing so ends up reducing the value of the ammunition more often than desirable, perhaps you could divide the enchanted cost amongst the batch and then add the result to the original value to ensure that the end result is always at least somewhat more valuable than the base item. On the other hand, reducing the enchanted value won't be much help to arrows and bolts which don't seem to gain in value from enchanting. Could you look into that?

Speaking of the latest beta, I seem to recall reading about an area-of-effect cost fix that would stop adding it to high-magnitude spells with no range. Was that implemented?

It's in the beta already. The difference was 0.25% so it was less than noticeable if you weren't looking for it. How is the fog of war fix testing?

Enchanted value of ammo should be about the same as (perhaps somewhat less than) the enchanted value of custom scrolls, since they're both effectively single-use items; the main difference is that scrolls are easily targeted and ammo hits based on a skill and attribute calculation. I know that the vanilla game doesn't give much opportunity for worthwhile custom scroll production, but existing blank scroll mods in the wild would change that balance.

Arrows/bolts don't increase in value, I haven't coded those in. Be assured in the beta that the soulgem no longer matters at all, only the enchantment points used. Nothing will reduce items below base price. I'm still thinking of requiring 2 or 3 soul per item, production is excessive at the moment.

So far, so good, but I haven't had time to do too much with it since I spent most of yesterday nursing a really wicked hangover >.<

@Hrnchamd
I did some extended tests with the Fog of War patch and areas are revealed within the appropriate cell as expected now.

While I was testing that I also started noticing the mesh jitter error that occurs the farther from 0,0 you get. I had the PC's hands up continuously in casting position in 1st person mode and noticed all the finger joints starting to jiggle and wiggle - seemed to be more prevalent when facing NW, NE, SE, and SW. And it was even noticeable when facing those compass directions in the outlying cells of the stock Morrowind landmass boundries (e.g. 0,27 Sheogorad Region). I did not have the MCP beta animation patch applied.

This then led to trying to COE greater distances from 0,0 for comparison ... however I ran into some peculiar behavior with COE - coordinates beyond the loaded landmass were invalid and would not teleport player, except in the case where the values were approaching 256; in those cases the player was teleported to an offset from cell 0,0 by the difference between 256 and what ever value was used, as long as that difference would be a valid cell coordinate within the bounds of the landmass - for example:
COE 250,0 would teleport to -6,0 (Bitter Coast Region)
COE -245,245 would teleport to 11,-11 (Azura's Coast Region)
COE 235,-235 would teleport to -21,21 (Solstheim, Isinfier Plains)

COE 256,256
COE 256,-256
COE -256,256
COE -256,-256
each of these will teleport to 0,0 (Ashlands region)

In order to get to wilderness cells beyond the loaded landmass bounds with COE, I had to make short teleports by incrementing / decrementing the coordinates by a cell at a time. Interestingly tho, no cell loading graphic was displayed - the player position just changed to the adjacent cell.

I had no problem manually walking/flying the player out beyond 256 cells.

I'm not quite sure I got all of that, Tetchy. I think what you're saying is that the Fog of War patch is causing some wonkiness when trying to teleport to any cell that isn't part of the landmass proper (e.g. the wilderness cells). I also don't know what you mean by "mesh jitters".

Fog of War is working fine now as far as I can tell. What I was reporting is a separate unrelated issue.

In the process of testing it I was led to a different problem with COE not related to FoW.

'Mesh jitters' are the rendering position errors caused by errant calculations in the position relative to the game map origin (0,0) the farther away from it you get. Try using COE to move the player to -20,26 (Skaal Village) and face NE, you should be able to see it affecting the 1st person hands when readied for casting.

Oh. Thanks for clearing that up >.>

Looks like COE uses a signed byte for cell coordinates.


I think you can only COE to wilderness cells after they are initialized, and 8 other cells surrounding player's cell are initialized. No cell loading, because there is nothing to load there. If next cell had something modded then there would be a loading. What would happen if you leave some object on one of these cells, next go back to modded region, and then COE to the cell, where you left that object. Would it allow you to do that? (I would test it myself, but I can't right now)

It is caused by bad float point calcs, I suppose so. It's a common error when programming games.

A page explaining this phenomenon:

http://www.floatingorigin.com/
http://www.floatingorigin.com/mirror/blitz3D-thoughtZCWasInelegant-04-search.htm

Sure enough. All that's required is that the wilderness cell get initialized somehow, no need to modify the cell from what I can tell (was able to COE back to any wilderness cell I had visited on my way out to 0,50 - I'm guessing that's until the cells are purged from the buffer and without making a save). Additionally, you'll then get the loading graphic upon return visit using COE during the same game session or after loading a save made after having visited those wilderness cells.

It all makes perfect sense. B)

Out of curiosity, is it possible to fix the 1st person female hands? When creating a female character the game displays the male hands in 1st person until the game is saved and reloaded.

Everything explained fine, but I cannot reproduce the issue in the place mentioned by tetchy (COE -20,26 and facing North-East with spell readied, nor even when turning around to find an angle where the glitch would appear).

And single precision IEEE-754 has 23 bits of mantissa, still leaving 5 bits for decimal part, while you are 30 cells in either direction from 0,0 (assuming there are 8192 game units per cell).

@tetchy:
I just tested it, and was about to write it, but you were first.

That's a BB issue, IIRC.

I agree with this completely. I was going to suggest something similar to spreading to value over the entire stack. As it stands, paying for an enchantment on a stack of thrown weapons allows you to sell just a few to cover the price of the enchantment. The prices of the resulting items are far above what a similarly priced spell would cost, and that of the in-game enchanted throwing weapons with similar enchantments. Do you plan on adding arrows and bolts?

I too, would advise against multiple souls for enchanting, unless it were included as a separate patch. I think it sounds interesting though, to be able use multiple souls to make a powerful enchantment. I would like to see the restriction on the amount of ammo enchantable lifted also. It can be a problem when you only have a soul with a high amount of charges but don't have a lot of ammunition. I don't really like the warning message idea ( immersion breaker ), and if people don't want to read the documentation then they deserve to waste the potential of their soul gems... Stackable, identical player-enchanted items would be wonderful though.


No, it happens in the default game.

Report time

Bound weapons no longer deselect the current spell upon expiration, however you are once again forced to equip and draw your last selected weapon/fists. This is true even if the Bound weapon expiry fix is used alone.

NPCs are using 0 magicka powers, but not spells. For the powers, it seems to be working beautifully. My test NPC seems to choose to cast Dragon Skin pretty randomly, which is a good thing. I looks beautiful to see that Breton shielded. Beautiful I say. While those pesky Dunmer in Addamasartus are exceedingly difficult to hit, even with a Redguard Warrior equipped with an Iron Longsword, I think it's good. They don't always cast Ancestor Guardian right away, so you still have a good chance to off them. Any prepared adventurer should have a few offensive spells/scrolls anyway for just such an occasion.

Also, please read this post. It was at the end of the last thread and may have been overlooked.

http://www.gamesas.com/index.php?/topic/1090176-repairing-the-cogs-of-morrowind-no-18/page__view__findpost__p__15988280

I'd like to add a few more requests to the mix. Do you think that you can make it so that spells that have effects of multiple schools, can give experience to each school instead of only the lowest one when cast?

I've also seem to have found that Turn Undead isn't working at all for Skeleton Archers. Could it be because they have a ranged weapon? Spell-casting undead flee, even with ranged spells, so I don't know what the problem could be. Has anyone else ever noticed this?

Lastly, and it's really nothing important, but it would be nice if Morrowind could recognize that I'm not using a QWERTY keyboard. It's fine for playing, but it gets annoying when using the console at times ( which I do a lot of in testing mods and such ). It's probably a problem with my copy originating from the United States, and now that I'm in France it just doesn't get along with the keyboard. It's nothing that I haven't gotten used to, I just thought that you may find it interesting. Well, it's there if you're interested.

Do any other foreign users have inconsistencies with the console, even with localized versions?

Yeah, characters like ':' and '_' are dificult to find to write in the console. From Spain we are using a non-official translation over the english version. The keyboards in France & Spain are QWERTY (the position of the main keys are equal to english one), but the problem is with the special characters, different for each language.

No problems with either Polish or English Morrowind since Polish letters patch in MCP, but most keyboards that are sold in Poland are standard QWERTY with other symbol characters placed like on the US keyboard (it's called programmers keyboard here), and extended characters are achieved by RightAlt+letter, or AltGr+letter. But probably there would be problems with Polish (214) QWERTZ keyboards, which I haven't seen and used IRL (neither at work, nor at high school and university, nor at libraries and Internet cafés, nor at my friends, nor at any computer I've ever seen or were fixing). I've seen them only on pictures.