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.

Full release is out now.
Files: http://www.tesnexus.com/downloads/file.php?id=19510

Here is a summary of what's in so far:

- Month fix (missing Morning Star)
- Enchanted item display bug
- Mercantile bug
- Transparent clothes in the inventory
- Unarmored bug
- Spellmaking limits
- Enchanted item value increase
- Merchant equipping
- Restore attributes issue
- Stealing from knocked out NPCs
- Reflect fix
- NPC health bar change
- StreamMusic fix
- Calm spells fix
- Vampire stats fix
- ESP load order fix
- Damage fatigue change
- Map expansion
- Local ref bugfix


See the previous threads for more detail:
Repairing those Cogs #1
Repairing those Cogs #2
Repairing those Cogs #3


Full release is out now.
Files: http://www.tesnexus.com/downloads/file.php?id=19510

And again, a shameless plug for the Morrowind Code Patch Showcase Mod.

This mod offers a guided tour of most of the changes and fixes of Hrnchamd's patch. It's designed like one of those museums where you get to try out the exhibits. Plug it in, enter the trap door between Sellus Gravius' office and Vodunus Nucchius' house in Seyda Neen, and enjoy.

I'll try that when he finishes the final patch, Psyringe, since I'll have plenty of time to wait while reinstalling all of my mods... >> 8 GB of content, you know. LOTS of time.

I can't wait! Will this patch interfere with MGE or other programs which mod the games programming? Will there be further releases?

The patch is compatible with MGE and FPS Optimizer (tested). It should also be compatible with MWSE and MWE - I didn't test those and haven't seen any reports of someone who did, but from the way these programs are functioning there shouldn't be a conflict (and Hrnchamd has taken care to use a console command not hijacked by MWE in the one occasion where he needed to). People are welcome to run compatibility tests though.

Psyringe, tell me something about the Local Ref fix of Hrn's. Everything works logically now, right? So I won't have to take an hour in Mash changing load times, so long as the changes I want MOST are below the things being changed?

The local ref patch - when it's finished, it's still in beta at the moment - should remove the major "illogical" source of mod conflicts, yes. The local ref bug causes vanishing references (mostly doors and NPCs), and possibly crashes and other problems too, due to a bug in Morrowind's way of dealing with references internally. The conditions under which the bug happens are not easily visible for Morrowind players, so this bug is a reason for many "illogical" compatibility problems.

Even with the local ref bug fixed, there can (and will) of course still be compatibility problems between mods, however these should be more overt. I.e., if two mods change the same reference and overwrite each other's content, or use the same id for different new objects, then obviously there will be a conflict. But such conflicts are easier to grasp and can be easier detected, e.g. with TESPCD. Incompatibilities due to the local ref bug cannot be detetcted with TESPCD.

Does that answer your question?

Not quite.

If no mods I want to use do the same exact thing, and I load them in a more or less logical order, is it safe to say I won't need to play in Mash for hours on end?

EDIT: Logical order as in a hierarchical order in which the things I want most are loaded last.

The savegame loader superbly messed up at rematching mods after you add/remove mods. That is a seperate fix already in release 6 which should always work. It allows you to add/delete without messing with load order.

The localref patch fixes certain incompatibilites and missing items when two mods edit the same cell (you most often see it with multiple mods in the same town), enables clean removing of mods (like using Wrye Mash but automatic), fixes the first mod wins behvaiour with non-persistent objects (like statics), grants lifelong happiness and enlightenment.

Yes, I think so.

In the setup you describe, there should be no mod conflicts. The local ref bug could cause conflicts even in such scenarios, which could only be prevented by renumbering references with Wrye Mash. This is easy if you do it for only a handful of mods, but can become quite laborious and requires careful planning if you're trying to make a large amount of mods compatible - because the range of numbers that Mash can assign is limited and won't suffice to assign a unique number to each one, so to be safe that the bug won't occur, you'd have to carefully assign identical ranges to mods that wouldn't affect the same cells.

When the local ref bug gets fixed, then this prevention method won't be needed any more.

The current state of affairs is that the local ref bug *is* fixed, but there are still undeirable side-effects (currently related to containers), which Hrnchamd is working on.

Well Hrn, then the Local Ref patch is what I'm waiting for. ^^ Besides the awesome bonus of lifelong happiness and enlightenment, the problems I have occur with mods that edit Seyda Neen, Suran and Pelagiad -- namely they add houses and/or stores to those towns and stuff gets REALLY ugly. Similar stuff has occured with dungeons.

I noticed it mentioned the patch merges changes (e.g., as in Psyringe's tests, move scroll and resize it, get resized scroll somewhere else) -- does that include leveled lists?

No, that's something different. The "merging" that emerged in the patch only affects subrecords of references. Leveled lists are different, they operate on the object level (a level that the localref patch doesn't touch because the patch deals with references, not objects).

Edit: short terminology for interested readers:

object: A "template" for something, like a template for a door, or a template for an NPC, etc.

reference: An implementation of such a template in the game word. If you place a door in a cell, then you place a *reference* (the in-game door) to an *object* (the door template).

This difference is very important for modders since it's very easy to mess something up if you change an object where you just wanted to change a reference. The most common way to do this is changing container contents. These are specified per object, not per reference. If you change the contents of a container in the CS, then you are changing this container *object*, which means that the change automatically applies to all *references* to this object in the game world. I.e., a coin of gold that you just dropped in the barrel_01 you placed in your cell will appear in every other barrel_01 in the game.

The localref patch fixes a bug that happens with references, so it only touches references.

Leveled lists do not deal with references (a leveled is nothing placed in the game world), hence it is not affected by the patch.

Ah. How unfortunate.

EDIT: Still going to wait for a working LocalRef patch before i go and muck around, though.

Well, there are several tools that can generate leveled lists with very little effort required. Given that code patching on the level required here is *extremely* difficult and time-consuming, it definitely makes sense that he focuses on fixing things that can't easily be fixed by other means. And it's amazing how much he has achieved in the time he's working on that. So asking for leveled list merging would be a bit like saying "Thanks for this wonderful car you gifted us, but can't you make it cook our food too?"

Edit: And I know that you didn't ask *for* leveled list merging, I just want to state that imho there's little reason to be disappointed that the patch doesn't do it, because it can be done by other programs very easily and the patch fixes lots of things that other programs can't.

Okay, I've completed a specific container testbed now. Also added some doors to test whether problems arose with them too.

The testbed contains all permutations of the following variables:
- persistent vs. non-persistent chests
- locked/trapped vs. unlocked/untrapped chests
- empty vs. full chests
- chests that were moved by an esp vs. chests that never got touched by an esp
- chests that remain empty after interactoing with them vs. chests that I put something into or exchange contents

Things that it does not test (If you think that it would be good to include any of those, just tell me):
- differences between treatment of locked/untrapped or untrapped/locked chests. I assume that these get treated like the locked/trapped ones.
- differences if many plugins try to manipulate the same reference. That's what the Reference Override testbed is for.
- differences between chests with fixed vs. chests with random content. I assume that this doesn't make a difference; the content of the chests in the testbed is fixed.

The "doors" part of the testbed tests all permutations of the following variables:
- persistent vs. non-persistent doors
- locked/trapped vs. unlocked/untrapped doors
- doors that were moved by an esp vs. doors that never got touched by an esp

I'll edit the posts with the results as I go along.


First batch: Save the game normally, then quit, restart, and load

Effects:

- The non-persistent *doors* that had been moved by the esp had their position, locked/trapped status, and open/closed status reset to the one stated in the esp. Doors that had *not* been moved by the esp remembered their status correctly. All persistent doors remembered their status correctly too.

- All non-persistent containers that were moved by the esp had their contents and their locked/trapped ststus reset

- All non-persistent containers that had *not* been touched by the esp had their locked/trapped status reset too, but their contents were only reset if something was inside the containers when I saved the game.

- All persistent containers were treated correctly.


Conclusion:

There appear to be two bugs (that's what made the analysis difficult in the previous testbeds, which didn't test all permutations available for containers):

- One: Non-persistent references that have been manipulated by a plugin, and then manipulated (but not deleted) by the player, reset to the status specified in the esp, when the player loads a savegame. The information in the savegame is ignored for them.

- Two: Non-persistent containers do not remember their contents correctly if something was inside when saving a game, instead their contents get reset.

The bug that I reported previously ("persistent containers cannot be moved by plugins") turn out to be *not* true. This may have been an effect of changing the status of containers to "persistent" in the plugin that moved them. This might have been caused by the bugs listed above: The game loaded the plugin that set the previously non-persistent containers to persistent and tried to move them, but instead of applying the changes, the containers reseted. This *might* fix itself when the bugs above are fixed.


Second batch: Removing the esp that moved several containers/doors, then loading a non-KRR'ed save

Under this condition, all references that had been moved by the esp did reset completely, as desired. This included the position, locked/trapped status, and contents of the chests, and the position, locked/trapped status, and open/closed status of the doors.

Looking good here, but this will have to be rechecked after the bugs mentioned in the first batch have been fixed. (We cannot be totally sure that removing the mod resets the references correctly if the references reset already when the mod is still in place). I don't expect problems here though, it's just something that will have to be checked.


Third batch: Removing the esp that moved several containers/doors, then loading a *KRR'ed* save

Effects:

- Persistent doors that were opened retained the position that the (now removed) esp moved the to. Their locked/trapped and open/close status was successfully merged back.

- Non-persistent doors had their position and their locked/trapped status reset to that in the esm. Their open/closed status was successfully merged back.

- All persistent containers had their contents and locked/trapped status merged back correctly. Good!

- Also, all persistent containers that had been moved by the (now removed) esp, and that I manipulated (so that their info went into the save), retained the position that the esp moved them to.

- All non-persistent containers had their contents, locked/trapped status, and position (if they had been moved by the esp), reset to the values specifies in the esm.


It's still a bit entangled, but I think I've got good diagnostic tools now to disentangle it. Can I do anything else to help?

When this is done, if i understand correctly it solves the problem of corrupting saved games upon loading, right?

The patch fixes two major causes of savegame "corruption":

1. Morrowind gets confused when you change the load order of your mods and then load a savegame that depended on your previous load order. This usually results in lots of doubling and vanishing. Hrnchamd's patch fixes this. This fix is already working well.

2. Even without changing load order, Morrowind will mess up certain references when loading a savegame, due to the local ref bug. This usually leads to vanishing doors and NPCs. Hrnchamd is working on a fix for this. Present state of affairs is that the bug *is* fixed, but there are some undesirable side-effects we still have to work on (like containers not remembering their content). This part of the patch will also allow clean, easy removal of mods.

So, two major causes of savegame corruption are being addressed. There's perhaps a third one (reloading a save from a running game, not from the main menu) that we're keeping an eye on, but it's not the center of attention, nd we're currently not seeing problems with it. A fourth alleged way to corrupt saves is to use quicksaves, this is *not* being addressed by this patch, but easily prevented by not using quicksaves.

Oh, oh, maybe when Hrn has a ton of free time next he can fix quicksaves. ^^

is quicksave corruption due to the lack of menumode for scripts?

I don't think he has at the moment, but in any case that would require a clear definition of the problem, its effects and the circumstances under which it does and does not occur, so that it can be reproduced reliably. As long as this is lacking, it's highly unlikely that this issue can be addressed.

As far as I know there's no known way to *reliably* corrupt a save by using quicksaves, so even if someone did try to fix it, how would we determine whether the fix was working, or still needed more work?



That's the best working hypothesis we have imho, but no one has managed to corrupt saves reliably with this. It has been tried, but the saves were still okay, so other variables/conditions might be involved.

I also read that overwriting old saves can cause trouble. Will this fix that, or was that semi-superstitious to begin with?

The latter, imho. I haven't seen any good explanation why overwriting old saves *could* possibly cause problems. Windows doesn't even use the same physical space on the HD to overwrite files. The only difference between overwriting an old save and starting a new one is that in the former case, the file of the previous save gets deleted (by removing its entry from the respective directory). I can't imagine how that could cause problems. Imho the "overwriting saves can cause corruption" proposition is an urban myth, at least as long as Windows is concerned. It might have been true for other systems which use the same physical space for storing a save each time, like memory cards for consoles, but I don't see how it could apply to Windows.

Definately understand now why Bethsoft made it so only one change could be made to non-persistent refs. They have a primitive merge-target matcher stuck in there, but the way it's done limits it to seeing one change back. If that works then the override goes through, otherwise it gets run through all the other matchers.. which actually throw away the ref if it's a match. They are supposed to reject any changes if there's a newer ref there already. When I enabled multiple overrides, I uh went in the wrong direction with that. Now there's a much neater solution than a huge rematcher, containers should behave themselves.

Test it, but I'm concerned about container contents when you add a mod that changes the container you've used in your savegame. Normal Morrowind just screws you over and makes a fresh container, I'm not sure if I should fix that or not.

Will test at once. Regarding the "adding a mod that changes a saved container" issue, my guts tell me that it would be better to get everything else working first, especially since I guess that your time will be more limited now, but you're the one who can look at the code and see how easy/difficult such a change would be. If you want to address it, I'd certainly be here to do the tests.

I'm not sure how often the situation arises that someone adds a mod that a container he/she has in use. Perhaps when adding a stronghold expansion ... hmm.

I'm glad someone else thinks so too. I've never seen any evidence for it, or any explanation for a likely mechanism.

I say leave it alone because trying to fix it could cause more issues and headaches. Besides, doesn't Wrye Mash fix or attempt to fix that anyways?

A case where this is readily repeatable can be found in New Suran. This mod includes a teleportation skull with multiple levels of message box menus to teleport the character to almost every destination in morrowind. When the skull is used and the game is saved over a previous save file the skull will malfunction the next time it is used. This happens every time. I tinkered with the script a bit but could find nothing wrong with it.

Perhaps what the game does when saving is it uses all the records of the old save file and just appends/replaces changed ones.

EDIT: Yes, this makes sense! ^^ When it's overwriting the save file, if this is the case, it has to read from AND write to the same file -- very tricky if I'm not mistaken.

This really makes no sense from a programming design point of view. As you say, it would be very much trickier, and it would be a whole lot easier to just write a completely new data stream. I'll eat my hat if that's not the case.

It would have to be tested whether the skull *works* if, instead of overwriting an old save, a new save is started instead. I'm interested. I got New Suran somewhere here (always wanted to try that out ), I'll test that when I got some time. Can you give me specific directions on where the skull is and what's required to use it?

I'm aware, john.moonsugar. But I've been following Hrn's progress with the patches since the moment I joined and it seems they did some REALLY inexplicable things. Calm calling StopCombat every frame, as one admittedly poor example? xx'

Personally, if I were you, I'd keep the salt and ketchup ready because that hat looks a bit... leathery? >>

Reports on LocalRefBeta12:

Summary: Looking good. None of my testbeds was able to produce a bug so far. Haven't tried them all yet, but this LocalRefBeta has reached a state now where I *did* find bugs in the others, and I don't see any in this one. I will continue to hammer at it, of course. There's the issue with the changing persistence status in a mod that came up during the last LocalRefBeta, and I'll have to test for that.


First report: Container testbed batch 1: Save the game normally, then quit, restart, and load

Effects:

- All doors (persistent and non-persistent) had all their states (position, locked/trapped, open/closed) remembered correctly.

- All chests (persistent and non-persistent) had all their states (position, locked/trapped) and their contents remembered correctly.


Second report: Container testbed batch 2: Removing the esp that moved several containers/doors, then loading a non-KRR'ed save

All references that had been touched by the esp did reset completely, as desired. This included the position, locked/trapped status, and contents of the chests, and the position, locked/trapped status, and open/closed status of the doors.


Third report: Container testbed batch 3: Removing the esp that moved several containers/doors, then loading a *KRR'ed* save

All references that had been touched by the esp and that had been manipulated by the player had all their states merged back correctly. This included the position, locked/trapped status, and contents of the chests, and the position, locked/trapped status, and open/closed status of the doors.

One pair of empty chests (one persistent, one non-persistent) that I (the player) did not manipulate got correctly reset to their data as specified in the esm.


Fourth report: Local Ref bug / cups & plates testbed

Local ref bug continues to be fixed. No vanishing references, no doormarker issues.


Fifth report: Moving statics across cells / moved house testbed

The moved house correctly vanished from the place the esp took it from, and correctly appeared at the place the esp took it to.


Sixth report: Reference Override testbed

Upon entering the cell for the first time, all references (persistent misc items, non-persistent misc items, persistent NPCs, non-persistent containers) were displayed correctly, through all permutations of moves and deletuions this testbed tests for.

I took all misc items, emptied all containers, bought suff from all NPCs, left, saved, and quit.

Upon loading the save, every reference had its data rematched correctly.

Upon removing all plugins that manipulated the references, and loading the non-KRR'ed save, all references got reset correctly. This incliudes position, contents, and inventory. Those references which were only part of the main master, and had never been touched by any of the plugins that manipulated the others, correctly maintained their status.

Upon removing all plugins that manipulated the references, and loading the *KRR'ed* save, all references had their data merged back correctly. This includes position, contents, and inventory. For the first time, position of the containers did not get reset, but merged back correctly. Those reference which had not been manipulated by the player got correctly reset to the data specified in the esm.


Breaking LocalRefBeta12 appears to be a challenge. I'll continue to try, of course.

Maybe try out some merchants, they are containers too. NPCs are instantiate on cell load like non-persistent refs, but only the first time you see them. Well, some of their data is. Kind of.

Well, I've had to eat my hat before, so I'm used to digesting tough food. I'll certainly agree that the Morrowind works in mysterious ways.

I understand that there is not a download for all of the patched simulatiously? The mapfix, the localref test and the ordinary fixes? Does it work to patch over an already patched morrowind file and still get the desired effect or will it revert back to the original morrowind.exe and patch that ?

Hot damn, Psyringe. Why not try your real-world testbed again? See if anything coughs up a few spleens. >>

The most recent version of r6 shoulf have the map patch included. The localref patch is not included yet. Patching over an already patched exe won't work since the patcher always takes the morrowind.original.exe that it created and apllies the patches to that one - you could try to replace that file with a patched one, but I have no idea whether that works. Hrnchamd is putting together a version which integrates all patches and provides a UI for applying them, estimated release date is October 4th.

Wanted to report in on some things I noticed regarding r6:

Tested with MW/TR/BM and Psyringe's Morrowind Code Patch Showcase.esp - very nicely done btw!
No other plugins running.
MWE v1.6 & MGE v3.6.1 running.

While testing the Mercantile patch, noticed that offering gold would result in more or less gold in trade depending on the mercantile ratio. Should exclude gold from the formula and only offer the same amount of gold in trade. Otherwise, amounts offered for items seemed to be in line with mercantile skill level, tho never was offered the full value even at really high levels.

Spell duration needs to be more than 180. IIRC this was going to be changed to 600? I second that, maybe even 900. BTW, are spell durations tied to GetSecondsPassed as in real world seconds? Would be nice if it was a function of TimeScale so that spell/power durations would be proportional to that setting.

Enchanted item values worked. However, might want to increase the resulting value a bit - soul gem worth 4000 gp only ended up adding 400 gp to item's value.

Shouldn't increased unarmored skill protect better against unarmed attacks? I saw no difference to how quickly fatigue dropped with the unarmored patch - once fatigue reached zero, unarmored skill reduced proportionately the amount of damage to health as expected.


I'm trying to reproduce a crash I was having running with MWE, MGE, and FPS Opt v1.96a
I'll post again when I can verify that and provide the mem dump.

I will try and see if it works then =)

Thank you for the fast reply man. Sry to be a bother with my petty questions.

GetSecondsPassed is realtime seconds. ^^

EDIT: And yeah, I think spell durations are based on it. Sorry, misread your question.

Thanks


Suggestion to Hrnchamd: Since you're making the patch components modular anyway, what do you think about splitting the spell effect size and spell duration patch into two separate ones? This way everyone who wants the stronger effects without reducing the maximal duration could do so.


My (very superficial) first impression was similar. I didn't have the time to look into it further though (was too occupied with LocalRef testing) - this is something were really more input would be needed. Not sure if there's still time to implement changes though, but collecting data won't hurt.


You're not bothering at all. I'm glad to be of service.

Regarding enchanted item values, adding 4000 is a bit much to expect, as that would COMPLETELY eviscerate the economy even using PTE or similar. Perhaps double the added amount, e.g. from 400 to 800. I think, personally, that's a reasonable amount.

What kind of enchantment was added, though?

Did you use up all the enchant points offered by the soul, or only a few?

Soul gem value scales with the soul size squared, I'm never going to peg the formula to soul gem values because of that.

Seventh Report: Non-persistent containers turned into persistent ones

Okay, I managed to break it again. (One of these days saying this is going to get me killed, I know it ... ). It's a very specific bug though, so fixing it *might* be relatively easy.

I reactivated the testbed in Fine-Mouth's hut. This hut has two barrels inside. I made a plugin that moves those barrels and turns them into persistent ones.

In previous versions of the localref beta, the barrels would not move to their new positions. This is fixed now, the barrels get moved.

However, when I take something out of them, save the game, and reload, then the contents of these barrels will reset. This happens regardless of whether I left the barrel empty or put something else inside.

This happened neither with the persistent chests nor with the non-persistent chests in the container testbed, so I suspect that the problem is related to the fact that my esp is changing the persistence status of the barrels. Interestingly, regular Morrowind can re-match the contents of these barrels correctly.

I'll run some more tests on changing persistence status, but it will take a while to prepare the respective tests.

Edit: Also, when loading the KRR'ed save, the container contents are correctly merged back. This was what made me believe that fixing it might be relatively easy - forgot to say that.

Reporting that the patcher will only apply to the original, not even to it's own patched Exe. hehe.

Eighth Report: Changing persistence status of references in mods

I modified my Containers & Doors testbed so that the esp switched the persistence status of all objects involved. This led to the following effects:


a ) Upon loading a normal save:

- Originally non-persistent doors got doubled: the original door appeared as specified in the esm (or esp if the esp had moved it), and the door as specified in the savegame appeared too.

- Originally persistent doors got doubled in the same way *if* they had been moved by the esp. The door that was not touched by the esp was processed correctly, it had no double and appeared in the correct position with the correct open/closed and locked/trapped status.

- All containers (persistent and non-persistent) that had been moved by the esp had their contents and their locked/trapped status reset. There might have been doubling with the containers too, but I can't see that since I can't move them.


b ) Upon loading a KRR'ed save:

- All originally non-persistent containers and doors get treated corectly

- All originally persistent containers and doors that got never touched by the esp got treated correctly.

- All originally persistent containers amd doors that had been moved by the esp got reset to the values specified in the esp.


c ) Upon loading the non-KRR'ed save in original Morrowind:

- Results were identical to those in (b ).


Conclusion:

Looking at this, I'm not sure whether this *requires* a fix. Clearly, changing the persistency of an object with a plugin is a dubious action. Neither regular Morrowind nor LocalRefBeta12 can deal with it under all circumstances. If it can be easily achieved, it might make sense to make the LocalRefBeta fail in the same way that regular Morrowind does - in case there are mods that actually turn non-persistent refs into persistent ones. That could be the case if a mod puts a script on a formerly non-persistent reference. I don't know whether there are such mods though. I'll check the herbalism mods, they look as if they might be doing such things.

Edit: Checked the three most popular herbalism mods. Two of them add scripts to flora containers, but none change persistency.

Use disable on containers to check for doubles.

Something I completely forgot to mention before that would be nice to see if it's not too late, is the ability to enchant arrows. They have enchant values and you can enchant throwable marksman... I never got that and it's always been annoying. Maybe it could be a future fix.

Ah, right. Thanks.

Update: All containers that had been moved by the esp, and then manipulated by the player, got doubled. One version had the data from the savegame, the other had the data from the esp.

Well, there's also the cost incurred for enchanting the item which isn't figured into the final value.

sword value = 10000 (8 ench pts)
scamp soul/common gem = 4000
enchantment cost = 10560 (8 pt spell: absorb health 21-22 on touch)
This cost varies based on mercantile/disposition ratios, but will always be the same cost for the same spell regardless of soul/gem used.

resulting value = 11600

So, outlay for this example is 24560 resulting in 11600 value which if I turned around and sold back immediately would get 3/10 ths of this value (using same merc/disp ratio) - I'm better off just selling the sword and soul gem at 30% value and keep the 10560 gp for ench cost.
Granted, I am extending the damage range of the sword and at the same time getting a heal mechanism, but if that's valuable to me in the field it should be just as valued in the shop.



The sword allowed for 8, and yep I used 'em all!


In regards to my findings on the mercantile patch - I rechecked setting merc/disp ratios and merchants will offer you more than the full value of items (I'll edit out that bit in my previous post).

Also, ran r6 with MWE+MGE+FPSopt w/134 plugins for 90+ minutes and did all the interactions I tried before when it crashed, but didn't get a crash this time.
Will keep trying

I'd compare it this way:

You have an item (here: sword) and a filled soul gem. You can either sell those, or you can use the soul gem to enchant the item yourself, and then sell the enchanted item.

Currently, it seems that selling the raw materials earns you more money than selling the produced trade good,, which is a bit odd ... especially considering that you might waste a couple of soulgems due to failed enchantments.

However, the problem is not necessarily that the enchanted item is too cheap. The problem might actually be that the filled soul gem is worth too much, due to the fact that the soul value gets squared during calculation. However, soul gem value calculation cannot easily be changed (IIRC Piratelord tweaks it in PTE by modifying soul gems and changing two GMSTs, but he cannot change the base formula). So we're in a bit of a dilemma.

Personally, I think I'll use Hrnchamd's enchantment value patch, and Piratelord's PTE (assuming that it does reduce soulgem value), and see how that plays together. I probably can't give much feedback until I actually tried that out though.

Ninth report: Teleporting NPCs around

Just rechecked a testbed I haven't touched for a while now: the one where I placed NPCs in Foryn's shack and teleported the away via PositionCell. Everything worked okay with LocalRefBeta12. NPCs correctly vanished at their original position, appeared at the new position, MVRFs were correctly written to the savegame and correctly interpreted when loading the save. Removing the mod with the NPCs did not lead to any problems.

So Hrn has come up with an almost working local ref patch? Can't wait for epic morrowind.

Sorry to come back about the map fix but my tests were not entirely successful. I would like to understand if the problem comes from 1- a bad install of the patch; 2- an incompatibility with MW French version; or 3- a problem related to the mass land mod I use for the tests.

What happens with the patch installed (each time with a new game):

I- On Vvarfendell and Solstheim, no problem. The map is ok, I can edit notes, save and re-load a game without problem

II- When I go to an area outside the original map, using a land mass mod adding a large island west of Solstheim:
1. at first, I could see the new area on the map, but I could not see the name of cities when draging the mouse over the cities shown on the world map, and I could not see the arrow representing the player position/orientation (mini map is fine).
2. I restarted a few games, and this bug did not happen again. Instead, I could not see any new area on the world map (only the local map shows explored areas). When I click anywhere on the map, the map is automatically auto-centered on Vvardenfell (even if my character is located on a new area), and the new area is ignored (it does not display at all). Restarting, saving or loading a save game does not change anything.

Did people who tested the map patch encountered any similar problem?

PS: For the patch installation: I applied patch 1 + patch r6 + map fix. I did not install the ref patch yet. A few cities names in the mod I used for tests have French accents (symbols), but I suppose it cannot cause these problems.

It's English MW only right now. Hrn does want foreign language testers, though, so I'd PM him.

French and German use the same exe as the English version, it's okay.


I didn't test saving and loading outside the normal area, thanks for testing it for me. I'm working on a solution.


Can't include enchant cost because you are able to enchant things yourself. With the enchant value, it scales with enchant points, 8 is a pretty small enchant compared to most armour pieces (20-200), which is why the value added is so much smaller. I could probably make it scale more slowly and bump the overall multiplier. Try out the high end items, see what the value scaling on those are like.

Yea, I realized after posting that I had forgotten about player enchanting

I'll give it a go with a higher ench pt item and report back.

You can count on me for further testing of the map.

A small possible request, if it is not too late and if we are not asking too much... Many modders have tried to determine the class of the player. Unfortunately, %PCClass and %Class value exist as string pseudo-variables and can be "displayed" in dialogues and MessageBox, but cannot be "compared", since the TESCS scripting language only supports numerical variables (if %PCClass = .... is not possible actually). Thus, it is impossible to find out what the PC and NPC's class is (it would be very useful for many quest mods), nor to change it. %PCclass is determined by MW during the chargen process, and then it cannot be used or changed... the only possibility is to say "Hello %PCClass". Would it be something easy to modify?

examples of topic on this:
http://www.bethsoft.com/bgsforums/index.ph...=869786&hl=
http://www.bethsoft.com/bgsforums/index.ph...=841699&hl=

I think you should send that to the MWSE team, it is a modification to the script system. Adding commands requires changing the script compilers in the mod editor as well as editing the game.

OK. I am pretty sure that modders like Yacoby and Fliggerty are aware about this problem, I will try to remind it to them.

Tenth Report on LocalRefBeta12: Mash Compatibility

Since a previous version of the LocalRefBeta produced references which got cleared out by Mash's "Repair All" function, I tested that on the new LocalRefBeta. I took a save where I interacted with most of the testbeds I have, and ran that through Mash's "Repair All" function.

Results:

- The "normal" save yielded no errors, no mismatched refs. Good.

- The KRR'ed save yielded lots of mismatched refs. This is expected since KRR saves references in a way that makes Mash think they were mismatched. I think we should add that to the readme:

"Do not use Mash's 'Repair' function on a KRR'ed savegame - doing so would remove all the changes that you want to keep."

I think we should also mention in the readme that "KRR'ed save" refers only to the one save that has been saved with KRR on, and that following *normal* saves after that one are not considered "KRR'ed". Otherwise people might wonder whether they can use Mash's "Repair All" if they ever used KRR on their game.

A bit late I know but... I've heard from several people that they've noticed a small slowdown whenever they had more constant effect spell effects on them. Would it be possible to check the code to see how the constant effect items and abilities on the player is done, and perhaps even if there's anything that can be done to improve it?

Eleventh Report on LocalRefBeta12: Leveled Creatures

I've now constructed a testbed for leveled creatures. This had two reasons:

1. Regular Morrowind does get confused when two mods place leveled creatures with the same objectindex in the same cell. This effect is not well researched, but known and reproducible. It is possible that this is just another symptom of the local ref bug, so checking how the LocalRefBeta deals with it makes sense.

2. The problem might be caused by transitions between persistent and non-persistent refs (because spawnpoints are non-persistent, while creatures are). This is an area where LocalRefBeta12 behaves different from regular Morrowind, so researching it (and making sure that it doesn't break things) makes sense.


Procedure:

- created an esm with an empty interior room
- created an esp which spawns a leveled creature in this room
- created another esp which does the same
- started regular Morrowind, entered the cell, left, saved, quit, restarted, loaded the save, checked the cell
- did the same for LocalRefBeta12


Results:

- With regular Morrowind, the creature from the second leveled list doubles when re-entering the cell after loading the savegame. "Ori" reveals that one version of the creature comes from the savegame, and the other from the plugin. Hence, regular Morrowind failed to match the saved data of the second creature to the data in the second plugin.

- With LocalRefBeta12, there is no doubling. Both creatures get treated correctly. Their position, health, and dead/alive status gets correctly rematched when loading the savegame.


Points of note:

- These findings strengthen the hypothesis that Morrowind's problems when dealing with leveled lists added by several plugins to the same cell are just another symptom of the local ref bug.

- One problem with this hypothesis is that creatures are persistent, so two mods that add creatures should not be susceptible to the local ref bug. However, creature *spawn points* are *not* persistent. I think that this might be what triggers the local ref bug with leveled creatures: The non-persistent spawn point of the second plugin gets confused with the persistent creature produced by the first spawn point. That's just a raw hypothesis though and it does have some problems of its own.

- This *may* be linked to the "growing herd" problem too. There is a known (but not yet well understood) problem with plugins that create herds of creatures, like guar herds in the grazelands. Sometimes, especially when merging objects, the amount of creatures doubles. This can happen several times, until there are so many creatures that passing through the cell becomes almost impossible due to extremely low FPS. It might be worth checking whether this herd problem is linked to the local ref bug, and can be fixed by this patch. I don't know about an easy and reliable way to reproduce these problems though, any help of someone who does will be appreciated.

that's really great news!

According to PirateLord, his Creatures should never be included in a merged objects process for exactly that reason. I don't have any experience with this mod, but it is very popular, so I bet someone on these forums is familiar with the issue and knows how to reproduce it.

From what I know, the two problems (creature herds and the local ref bug with regard to creature spawn points as decribed in my report above) *might* be related, but they also might not. I don't have a clear understanding of the exact mechanism that causes the doubling yet, and I don't know how Creatures does place its herds.

So I can't be sure that this is really the same bug, it might be something different, in which case the LocalRefPatch wouldn't fix it.

However, it's certainly worth looking it a bit further, since there's at least one common aspect (the doubling of creatures).

If anybody would want to run a few tests on this, this would be very welcome.

Update on Enchanted Item value

This time I tried an item with greater ench pts

ebony towershield value = 25000 (150 ench pts*)
scamp soul/common gem = 4000 (100 charge)
enchantment cost = 78750 (99 cast cost spell: absorb health 25 in 50ft of target & calm humanoid 25 for 10sec in 50ft of target)
This cost varies based on mercantile/disposition ratios, but will always be the same cost for the same spell regardless of soul/gem used.

resulting value = 29750

That's a bit more reasonable: value of the shield + gem = 29000

However the value of better gems with better souls might need more balancing, ex:

ebony towershield value = 25000 (150 ench pts*)
golden saint soul/grand gem = 80000 (400 charge)
enchantment cost = 180000 (157 cast cost spell: absorb health 45 for 5sec in 50ft of target)

resulting value = 55000

Better than twice the value of the shield alone, but nowhere close to value of shield + gem (105000).

* These ench pt values are 1/10th of the item's actual ench setting in the CS. I haven't done any high character level enchanting, so don't know if this value increases as the player levels up, but there's a game setting for fEnchantmentMult set to 0.1000 by default.


There appears to be another bug in unpatched MW related to enchantments which might want to address - when casting spells from enchanted items, the cost/charge amounts shown in the Magic Menu tend to be off by 1 in relationship to the pop-up rollover for the item in the active spell hud. Seems to be more prevalent with items that have higher charge totals. Probably a round off calc error is occuring.

Another thing that always bugged me is the hud showing enough charge left for one more casting but not being able to. For example: Fargoth's ring of healing has 20 charges and costs 5 to use for most starting characters, but I have never been able to use it 4 times in a row - when it gets to 5/5 and you try to use it, message box saying "this item does not have enough charges left..." is displayed. I have seen items go to zero charges, so it's not a limitation of an item having to always have 1 charge left (unless it's a display issue).

I'd guess it's a rounding issue here as well. Suppose it's not 5, but really 5.1 (for example). You cast it three times, and the 20 charges are reduced to 4.7, rounded up to 5 in the display but 0.4 short for casting it again.

Twelfth Report on LocalRefBeta12: Scripted non-persistent items

Another odd bug in Morrowind is the following: Have one plugin place a non-persistent reference (that does not have a script attached to it) in a cell, and have another plugin place another non-persistent reference (that *has* a script attached to it) in the same cell, with the same objectindex.

If the player now manipulates both objects, i.e. both objects get saved to the savegame, then - upon reloading the save - the first object will vanish.

This is odd for several reasons. First, when we see ref conflicts, usually one of the two refs involved is persistent, while the other is not. This is not the case here, we're dealing with two non-persistent refs. Second, it's usually the persistent ref that is vanishing. This is not the case here, it's a non-persistent ref that goes missing.

Since LocalRefBeta12 performed well in the other tests, I prepared two scenarios for it which tested for the bug mentioned above. One added two doors to an otherwise empty room, the other added chests. In each case, both added references were non-persistent and locked, and one of it had a script attached to it while the other had not. I then entered the room, unlocked both references, left, saved, and reloaded the save with regular Morrowind and with LocalRefBeta12.


Results:

- With regular Morrowind, the reference that did not have a script attached to it vanished.

- With LocalRefBeta12, both references were treated correctly.


Conclusion:

LocalRefBeta12 continues to perform very well. With the "scripted ref" bug, and the "leveled creatures" bug mentioned in my previous report, it fixes two bugs which were linked to the local ref bug, but which occured under different circumstances than the "standard" local ref bug that we know.

After more tests on a clean install properly patched (French version):

- the streammusic bug has completely disapeared. Something really amazing: now Morrowind remembers the sound volume/settings when re-launching the game or loading a saved game.

- for the map: there is no major bug, even on new area (far west of Solstheim) the local and world maps display correctly, cities names display properly too. Also no problem with saved games. Yet there are still a few minor glitches:

1. "Edit notes" is working on new area local map (just once, in one city, I could not add a note, I don't know why, clicking on the map was not responding properly, and then, after moving to a new location, it was fine)

2. to check (not sure): the scale of the map seems to change during the game (it appears with the usual size at the beginning of the game, on Vvardenfell, and then the scale is resized according to your new scale settings).

3. the scrolling of the map within new area could respond better when reaching the edges (the map tends to center automatically on Vvardenfell).

That's all! I also noticed that there is a large space for the map south of Vvardenfell, but no so much for west, east and north direction... but I guess you deliberately centered Vvardenfell to the north of the whole world map.

Edit: BTW, Psyringe's Morrowind Code Patch Showcase is very nice and useful! Thanks!

Does it show casting cost for a "typical" caster, or for your character specifically? As one gains Enchanting skill, casting cost decreases, from what I've seen. As a starting character, it MIGHT show the cost for a skill 30 or 40 caster, NOT for you, since it also never shows the DECREASE in cost as your skill grows. With a 100 skill, the ACTUAL casting cost might only be 1 charge, but it will still show 4.

The cost of enchanted items with high-value souls uses doesn't necessarily need to come out to the FULL value of the gem. Using a larger soul may not necessarily make the item any more useful: having a Cure Disease item with 200 uses would be a waste of most of a very large gem, and probably wouldn't be worth a whole lot more on the market than one with 2 uses.

These values sound about right to me.

Remember, that with the Golden Saint soul, it is more valuable as a soul (or 'potential enchantment') than as an enchanted object. With a GSS, you could hypothetically make an enchantment far superior to the absorb spell you made. So in its raw form, it is more valuable. And the fact that the shield more than doubles in value shows that the value added to the shield is very much taken into account. The thing to remember is that value is actually subtracted from a soul when it is enchanted, because it's losing all the potential it has.

So, yeah, it kinda makes sense.

Basically, I think Hrnchamd's got it right.

Back from work. Discovered yet more bugs with the loader.

You know it tries to load the savegame cells twice? And the second time round there's nothing to read, so it goes about creating rubbish refs everywhere, then throws them away again when the reference loader notices there's no more references left.

It misassigns mod source names because of that. And some other junk eugh.

With the enchanting I was aiming for people to turn a profit with midrange enchants without making the high capacity items too overpriced. I think I'll bump the constant multiplier around a bit and reduce the scaling on enchant points.

Odd. Could this second pass have any reason? Checking / Reassigning anything, but only in a few cases so you didn't see it yet? Or is it cler from the code that the second pass can never make any sense?

New Report: I'm researching the multiplying herds in Creatures X. I can reliably multiply a whole guar herd with the method described in report 11, because the herd gets generated by a script attached to a creature which gets spawned via a leveled list. So at least one way of herd multiplying happens due to local ref bugs, and would be fixed by your patch. Good news, I think. I'm currently researching what the other alleged causes of herd multiplying are.

Something else: It occurred to me that there are certain resources I referred to a lot while testing - without them my tests would have taken a lot longer, so I thought they deserve a mention. Specifically I'm referring to these people and resources:

- Wrye (Wrye Mash & Research about doubling etc.)
- Ieldra (for the guide "No more 'reference xxx not found in master'")
- Dave Humphrey and Jim Adam (ESM/P/S file format documentation)
- Farren Hayden (Enchanted Editor)

wow, awesome find.

You know, that could be the cause of 90% of corrupt savegames. Nothing's ever wrong with the savegame ITSELF, EE says it's all fine and Mash says it is too. It just doesn't LOAD.

You may well have found the reason why. ^^ Quicksaves and autosaves may become viable. ^^

I assume it's to reincarnate refs from deleted mods, but it's super inefficient reloading everything as it does. It doesn't always double-load of course, only when you're not looking for it, then it pokes you in the eye. It's no big deal.

It's great you're checking out other stuff too. I'm going to push a documentation 'beta' tomorrow, so the help file will be as understandable as possible if everyone here goes over it.

Making an item with Almalexia / Vivi's soul?

This is GREAT! I've been wondering for years if Bethesda would ever release another patch to fix these various issues, and eventually gave up hope of it ever happening. I never thought anyone else would do it, but here you are! Bravo! This will make a better game for all of us.

One thing I would like to see fixed, which I'm not sure is even a coding problem, is the way the UI reacts to larger font sizes. I have very poor vision, and have made myself a large font to use for ingame text. Some of the windows and buttons expand to display the text just fine, but other windows and buttons do not. For example, the options windows don't expand for the larger text, so that in most of the tabs, the "OK" button is pushed down out of reach. Dialog windows do alright, but the selection area for highlighted link words is frequently kind of screwy - often I have to highlight the word above or below the link to be able to click on the link. I hope I'm explaining this correctly.

Is there anything you can do about this? That is, if you're willing to! If not, that's alright, too. I can send screens, or the font so you can see for yourself.

Thanks for working on this patch, and on MGE. The animated grass is way cool to see, and it'll be nice to finally play a pure mage without role-playing away that armored glove. This is something Bethesda should've done years ago, IMO.

New enchanting formula: Going to try 30 * (1/fSoulGemMult) * sqrt(enchant points) * (soul size), expect it in r7

Also. Localref beta is updated. Slight change to loading refs this time, refs get a merge target even if the merge target isn't loaded yet.

How will this change affect the game (so I can adjust my tests to specifically check it)?

It affects non-persistent->persistent transitions. I.e. containers, loading saves, activators, scripted objects. It does solve the container thing you were talking about earlier too.

Speaking of enchanting, is it possible to make arrows enchantable?

One thing that always bothered me and I have never seen addressed. The fact that you shoot a bow as a lefty; why has this never been addressed it has bothered me since I started playing back when it was released. I kept waiting for a patch but it has never come out.

The patch is on feature freeze for now. I've looked at the code for you, enchanting is kind of hmm. It's possible to hijack the scroll enchanting to work for ammunition instead but there's a lot of UI changes required, which will take a lot of time to understand. It won't allow arrows in the items to enchant selector, and you won't be able to enchant multiple arrows at once without some major changes.


That's an animation issue. I'm trying to fix game logic issues.

I don't think that this is something that can be changed by patching the exe. It's an animation issue. Check out LizTail's AnimKit 2.0 for a way to mod animations.

Thank you.

I've always found that odd too. And that made me think, why can't we have the choice of left/right handed? Or ambidextrous. I'd like to choose which hand my weapon is in, even if it's not the dominant hand.


Hmm. Thank you for checking. And just to be sure, is it at all possible to add new spell effects? Sure would be nice to see a reflect damage.

Tested, confirmed. Transition of non-persistent refs into persistent ones now works as in regular Morrowind.

There's a small difference concerning transitions from persistent to non-persistent references: In regular Morrowind, such references reset their status. With LocalRefBeta13, they get doubled; one copy has the status from the savegame and the other one has the status from the plugin. Not an issue imho. LocalRefBeta13 doesn't break anything that isn't broken already in regular Morrowind, and I have a hard time imagining a situation in which switching objects to non-persistent would make sense.

I'll probably fall asleep soon, will continue testing tomorrow. Will repeat the tests I did for LocalRefBeta12 now for LocalRefBeta13.

Go on testing the map with a mod that add another island, east to Vvardenfell this time. The center of the island is around (-133, 133):

1. the world map cannot display such a location, it is all blank (local map is ok)

2. the arrow showing the player position/orientation disappears too (local map is fine).

It may be too far from the center of the original map?

Original map is approximately (-28, -28) to (28, 28).
Map expansion is approximately (-51, -64) to (51, 38).

You would need 1 pixel size cells to see that island at (-133, 133).

Maybe that's a solution? >> You'll need a LOT of cells to see all of TR when they finish it. Maybe you should allow people to choose the amount of expansion vs. cell size. Me, I'd pick 1-pixel cells. ^^

Hmm, how time-consuming / difficult would it be to give the playera choice of cell size when installing the patch? 4 is great for most people, but I can see a cell size of 2 making sense for people who want to use Tamriel Rebuilt, but have transferred many other mods to areas beyond TR's border. TR overlaps the landmasses of many mods, so people are using TesFaith to move those (mostly to the east and north, since the area to the west and south is supposed to be occupied by Tamriel).

It already covers all of TR with the current release, please take into account land area scales with distance squared. No more features, I want to release on time, tomorrow will have to be a r7 while I fix the other editions of Morrowind.

Ah, I see - I hadn't taken into account that you're also working on the international versions, so you'll have a lot of work even without people suggesting expansions of existing features.

In the meantime, I've run LocalRefBeta13 through all my testbeds. Like LocalRefBeta12, it passed them all:

- Local ref bug: fixed
- manipulations of references by several plugins propagated properly
- containers and doors treated correctly
- matching moved NPCs with PositionCell: working correctly
- matching statics moved across cell borders: working correctly
- leveled creature doubling: fixed
- vanishing refs due to added scripted refs: fixed
- resetting refs after removing plugins: working correctly
- merging back ref data with KRR'ed saves: working correctly

I'll run some more tests today, checking for things that I didn't give much attention to yet.

Oh, Psyringe, with the fixing of the savegame loader's tendency to reload junk references and stuff, can you test if formerly corrupted saves work now? I have a feeling they will, personally. ^^

Dd this get changed? I didn't think so, might have overlooked something of course.


Define "corrupted save". Many types of corruption are fixed already by fixing the local ref bug. That is unrelated to the loading and discarding of junk references though.

Corrupted as in CTD on load.

EDIT: Checked, I don't know if this was fixed or not.

Well, somebody would have to prepare some saves that CTD on load for that.

I remember that the CTDs on load that I had were linked to attempts of removing mods from a savegame with 250 mods installed. I had to remove the mod with Wrye Mash to prevent the crashes. This particular problem should be fixed already by Hrnchamd's fixes to the ESP loader (which now correctly recognizes changes in load order) and the fixing of the local ref bug, which also includes a clean removal of mods. I don't have any save at hand to test that, though.

Oooh. Could CTDs on load ALSO be caused by adding mods to a running game or updating existing ESPs with lots of new stuff? ^^!

Might be, although both usually result in doubling or vanishing refeences rather than crashes (and adding mods to the *end* of the load order works well in regular Morrowind already).

The former should be fixed by Hrnchamd's patch. The latter can't be fixed by patching the exe without a *lot* of work, you should use Wrye mash's "Updater" function for updating mods.

Next report on LocalRefBeta13:

While trying to reproduce a local ref conflict between "Children of Morowind 1.0" and "Immersive CharGen 1.24", I actually managed to create a savegame that will crash reproducibly upon loading it with a regular Morrowind exe. There is very little info going into this savegame, I just went throgh CharGen an picked up a couple of items that belonged to the "Immersive CharGen" mod.

Loading the savegame with LocalRefBeta13 worked fine.

This is the first reproducible example I have of the local ref bug crashing a savegame (I've always suspected that, and heard other people telling about it, but never had that myself). Nice to see that LocalRefBeta13 fixes it.


Edit: Unrelated update: Ran LocalRefBeta13 through a couple of testbeds that I didn't use for a while since they had been superseded by others (Baly Omavel's plates, for example). No problems to report.

Edit2: Ran a test with items dropped in front of the character. There's no reason why this *should* make problems, but it's something that I've never tested in any of my testbeds, so for the sake of completeness it had to be checked. As expected, no problems.

Edit3: Going through former threads now to look for suggestions that I might have overlooked. Hrnchamd, you suggested testing merchants, but the the NPCs in my Reference Override Testbed already are merchants, so that's already checked.

...Psyringe, have I ever told you that you are awesome?

And you too, Hrnchamd?

Oh boy. No more corrupting savegames. No more ;-;!

EDIT: I'm just.. wow. That made my decade. Screw my modding hiatus, I'm going to go work on Nchardumz. ^^

I agree. This is some mind blowing work here. I'm just...stunned.

Keep up the awesome work. Can't wait to get the finished patch.

Thanks, Dirges, but all credit should really go to Hrnchamd. I think I succeeded in making the process quicker, but he's the one who's making it *happen*.


Next report on LocalRefBeta13:

I've thrown it into my "humongous installation" testbed now. During the past few hours no problems cropped up - at least none that could be traced back to the patch. Two former problems (both vanishing doors) appear to have been fixed. Another problem (game freezes while loading one specific interior in Ebonheart) has *not* been fixed, but I did't expect that either. This freezing is probably a problem of any of the scripts that are at work in this cell, and unrelated to lcoal refs. It's a good reminder that the local ref patch won't fix *everything* though, although it's really amazing how much can be fixed with it.

Not to rush your or anything, Hrnchamd, but how close do you think a finished version is? I haven't run into any problems running beta code 5, but I can't wait for the finished version.

It's on the first post, but this forum doesn't have blink tags. If there was ever a time for it...

I generally go to the last page/post. Thanks for the info, though.

Fine work both of you! You appear to have fixed an awful lot more then I expected could be done in such a short timescale!

Well done indeed!

I'm pretty excited to pick this one up. In the readme, will you explain just what needed to be fixed about all of these?

There's a showcase mod by Psyringe, that demonstrates most of the fixes, and there's going to be a documentation beta sometime tonight. Map integration is taking a lot of time, trying to make it as automatic as possible.

I feel the same!
Just following this thread makes my head go all woozy! Great know-how there! The code-hunting is almost epic!


Good work mates!

Next report on LocalRefBeta13:

After several hours of playing, I didn't notice any problems in-game. I then saved the game and used Mash's "Repair All" function on the save.

To my surprise, Mash found three bad references. I tried to track those down. Two were easy:

BAD REF>>NO MASTER 113 88 max_ex_redoran_win_02a_e15
BAD REF>>NO MASTER 113 87 max_ex_redoran_win_02a_e14

Mod 113 is "Windows Glow" by Max. The ids of these references only appear in one mod: "Windows Glow" by Max. So if the savegame says the references are from Windows Glow, and a text search shows that they only appear in this mod, then why does Mash complain about bad references? One explanation could be that the objectindices got corrupted, so I tried to check these - but couldn't because EE cannot read Windows_Glow.esp. I suspect that Mash has the same problem and that the references may actually be correctly matched, but Mash cannot see this because the esp uses an illegal file format.

The third reference that had gone bad was a leveled list:

BAD REF>>NO MASTER 110 332109 ex_ascadianisles_lev-1

Mod no. 110 is Korobal, a mod that my character is currently involved in. What's irritating is the high objectindex, it looks as if it might be an objectindex of Morrowind.esm. The leveled list was changed by several plugins (among those Korobal and Giants), as well as a merged_leveled_lists.esp. I'm currently unsure what's happening here.

Mash found also three orphaned references, two were birds with ids that started with "abot", so they had apparently been created by abot's "Where are all the birds going?", the other was a scrib.

I'll continue to investigate. Hrnchamd, do you have an idea what might be happening here?

"No master" in Mash means it can't find any mod that matches both the ref name and physical ID, or possibly multiple mods.

ex_ascandianisles_lev-1 is from Morrowind.esm, physical ID 332109. It's not the levelled list (those don't have refs), it's the spawn point in (0, -5). I'm not sure what's up with that, have to check the levelled creature stuff in the savegame.

Edit: Checking out the mod, it does edit that cell and move the spawn point. I don't see the big deal. What does the pre-cleaned save game say?

hrnchamd, will you be changing the indicated version number shown on the main menu screen?
I'm still showing 1.6.1820 after patching to r6. Morrowind.exe (r6) is dated after Morrowind.Original.exe which also had its original date changed, but I guess that's why you renamed it with .Original.
I'm seeing the same version for both in the file properties as well (1.6.1820)

Not really, it might break other patchers that match the version number. Good night, see you tomorrow.

I went through the showcase mod, and while I liked what I saw I was a little confused with which parts already had their tweaks in place as opposed to which ones were showing "This will be different in the final version". Still though, great work!

Yea, figured that might be a problem. I'd suggest leaving the date of the .Original. unchanged from its source exe if possible.

Sounds like one big mod to fix many smaller mods already out, gotta love how the comunity is still going strong with all these wonderfull ideas, cant wait to try it

This isn't a mod. This is a patch. It changes your Morrowind.exe, and fixes things no mod could ever fix.

It's the best thing there is, though, IMO. ^^

The pre-cleaned save shows nothing unusual, looks like a normal spawnpoint with a scrib spawned (that's the same scrib that Mash clears a bit later as "orphaned" btw.)

I suspect that the following is going on:
1. Korobal moves a spawn point from Morrowind.esm across cell borders (confirmed)
2. The game does not throw any errors with regard to that spawn point (confirmed)
3. The game can deal with the moved spawnpoint correctly, and can match information from the savegame corectly. (suspected)
4. Wrye Mash does not expect spawnpoints to be moved across cell borders, therefore thinks the reference has gone bad, and tries to rematch it, which fails. (suspected)
5. Mash then deletes the reference from the savegame, which in turn leaves the spawned creature orphaned, so it's deleted as well. (follows logically from (4))

I'll try to construct a testbed which tests for (3) and (4).

I agree that it doesn't look like a big deal, but I think it's important enough to investigate. If Morrowind manages its references correctly (which we hope it does after the patch), then bad references shouldn't happen unless the current load order is different from the savegame's masters. If we still get bad references, then this means that either (a ) Morrowind still misassigns references, which could be an old and yet unfixed bug or even something new that the patch introduced, or (b ) Wrye Mash reports an error where there is none. Since (a ) has a risk of corrupting people's save games I'd like to prove (b ) so that I can exclude (a ).

A small testbed with a couple of spawnpoints moved across cell borders, run through the game and processed by Mash, should be sufficient to check that. Will take a bit though since I'm actually sleeping right now, I just woke up for a few minutes as my girlfriend went to bed.

Still working on map integration from last night. Most of my time is being spent on upgrading old savegames that already have a landmass outside the map, it took a long time to find out where to hook it to draw the new cells without hosing existing map data. Morrowind only redraws map data for newly added mods, so I had to investigate exactly how it marks those.

It doesn't help that when original MW draw cells on the edge of the map it wraps around to the other side.

I've got to say that I'm staggered by the work and dedication being put into this to fix a game I love so much.

I did some tests on the moved spawnpoint that caused a bad ref.

As suspected, Wrye Mash always clears spawnpoints that have been moved across cell borders. Actually my tests indicate that this extends to *all* references that have a MVRF subrecord in the plugin data (I've tested an NPC and a load door and both were treated exactly like the spawnpoint). Mash is either unable to interpret MVRF subrecords in a plugin correctly, or it decides that these are problematic anyway and that it's better to clean references to them out of the savegame.

In any case, Mash's "Repair All" will remove such references from the save, which means that they will reset to the data specified in the last plugin that manipulated them. Spawned creatures will be removed.

In my tests this threw a "reference not found" error for a rat that had also changed cells in the savegame. In theory it can also lead to relocked doors, NPCs that forget that they have met you, etc. However, it *only* affects references that have been moved across cell borders by a plugin, then saved because their state has changed, and then processed through Wrye Mash's "Repair All" function. This should be a rare occasion, since moving references across cell borders is considered illegal or at least inadvisable anyway.

Even if we wanted to change the situation, we'd have to modify Mash (or write some complicated routine that generates "camouflage" data for the moved references so that Mash thinks they are correctly matched to non-moved references, and therefore won't clean them). Both approaches appear to be to ocomplicated for a problem that only shows itself under the specific circumstances listed above.

Side note: I wonder *why* Mash cleans these references. It might be something that Wrye didn't see a need to implement otherwise, but it might also have been a conscious decision, since several documents mention the moving of references across cell borders as a source of problems. Unfortunately none of the documents I have really specifies which kind of problems these are, and I'm not seeing any, so at the moment it looks like Mash cleans this data unnecessarily.

So, in short: This is either a problem of the plugins (if what they do is illegal), or a problem of Mash (if it cleans out data unecessarily), but not a problem of the local ref patch.

I'll do some quick contacting, Psyringe. ^^

What's next? Hmmm. I noticed that I was unable to load my "huge" savegame back into the regular Morrowind exe. Doing so would reliably result in a crash during the "Loading Save" phase. Repairing the save with Mash did not change that.

This might be important if people want to have the option to switch back to a regular, non-localref-patched Morrowind.exe, so I'll investigate what exactly is causing the crash. Since this is a 22 MB savegame with 2250 cells stored inside, this may take a while even with a binary search algorithm. I'll check the forums from time to time to see whether something more important comes up.

I don't think there is any reason to ever change back to the non-patched. It'd be like reverting from the latest Bethesda patch to an earlier one. If you don't like what you get and didn't make backups, be prepared to deal with the consequences. This is far more friendly than original Morrowind ("I'll screw you over every ten minutes whether or not you make backups").

And besides, it should only be a problem with the LocalRef patch, which NO ONE should ever have good cause to remove.

I do not see any reason to change Mash to address a possible problem that we have been advised to avoid.

I have wondered about some of the 'bad reference's, but have never encountered a problem due to their removal. As a matter of fact, I have found that frequent Save 'Repair All's have stabilized my game (I have not a CTD in a long, long time).

sieboldii

You will run into a problem if, for example, a city expansion moves an NPC across a cell border, a quest changes the NPC (and depends on this change), and you then use "Repair All" on the save. This will break the quest because it will reset the NPC.

Teaching Mash to process MVRF subrecords in plugins (which it currently doesn't seem to do) would cause Mash to not reset such references and therefore wouldn't break such a quest.

It's rather hypothetical however because I don't think anybody has the skill and the will to update Mash. Wrye has kept the architecture open so that other people could add their own stuff, but no one ever did.


Well, out of curiosity, do *you* see any problem that such a (hypothetical) update to Mash would cause? Because currently I'm not seeing any evidence for such problems, and I'd like to know if I'm missing something.


Yep, definitely - because Mash circumvents the local ref bug (or repairs many errors it causes), which otherwise leads to lot of problems. One of the goals of the code patch is to fix this bug in the code, so that this circumvention won't be as necessary any more (plus, the circumvention *can* go wrong under certain circumstances, although they are rare and you don't seem to have encountered them yet).

Biggest problem I could see with a possible update to Mash to accomodate the Cogs patches would be causing problems with Vanilla Morrowind. Easily fixed by allowing people to choose what version they're Repairing for -- Bethsoft Only or Cogs Patched.

What about Wrye himself?

Erm, perhaps I should've made that clearer. Mash's resetting of references that have been moved across cell borders is unrelated to the Morrowind Code Patch. It affects the code-patched game in the same way as the unpatched game. The "fix" I hypothesized about would, likewise, apply to the code-patched game as well as to the unpatched game.

But the keyword really is "hypothesized", because as I said, I don't think anybody is going to do it. Plus, there's still the possibility that other problems are associated with MVRFs in plugins, which is why I was aking if anybody knew the exact problems that those are supposed to cause (still interested in that btw).

Wrye has often said that he has retired from Morrowind and moved on to other things.

sieboldii

Hum, lost an hour wondering why state blocks didn't work. Looks like MGE stubs them out, ah well. Back to working on the GUI.

Not many people use Python in the MW community.

I don't even use Wyre because I didn't want to have to download python.

I use Python (but can't code in it) because a lot of my *nix wannabe programs use it. ^^

Uhh the patcher you've been using for a month is already written in Python. It's packaged up so you can't see it though.

Your loss.

sieboldii

Okay, after 5 hours of hunting I've got the two of the 40,643 records in my savegame that caused it to crash nailed down. The result is boring and interesting at the same time.

It's boring because the cause of the crash is - surprise - a local ref bug. In the savegame, I have a cell in Vos with one of Emma's children (persistent) and a banner of Indybank (non-persistent), both sharing the same objectindex. Due to the local ref bug the game confuses the two and crashes upon loading the save. When I remove either of the two from my savegame, the save loads.

The interesting part is that this has implications for the code patch. It means that people may be unable to revert from the local ref patch back to an unpatched exe, but (that's the nice thing about it) it's not the patch at fault. It's just that while playing with the patch, the savegame may accumulate reference pairs that would trigger local ref bugs with regular Morrowind, but of course don't do so with the local ref patch active. When the player now reverts to the non-patched exe, all these combinations *will* trigger local ref bugs, which may make the save unloadable. Wrye Mash will not be able to clean those references from the save because Mash's "Repair All" function can only clean out references *after* the bug has happened. If you take a save from a local-ref-patched exe, then the bug hasn't happened there yet, all references are matched to their counterparts in their respective plugins. Hence, from Mash's perspective, there is nothing to clean.

I suggest mentioning this in the readme to prevent people from thinking "the patch has corrupted my savegame" because they can't load it any more with the unpatched exe.

That's unending dedication. In the current documentation I've made it clear it's save-compatible with original Morrowind, but it may need a more concrete example. I think the documentation needs a few hours more attention than I've given so far, instead of writing I've been working on feature integration, which takes forever. Probably have to finish this off tomorrow.

Feel free to post (or PM or mail me) what you already have, perhaps I can take up some of the work while you're finishing feature integration. I'm basically finished with testing - I'll continue to check some things, but as far as I'm concerned the local ref patch is good to go. If it still has bugs then they're hiding quite well.

I'll be off shortly, but could start to work on the documentation (or anything else you throw at me) in about 10 hours.

Okay, I've been informed. No promises (enjoying my retirement too much), but I'll probably fix it before too long.

Heehee. Who did the summoning ritual?

That would be me. >>

Heehee...this could also be translated thusly: (in a Warcraft 2 mage voice)

"Who summoned me?"

The great Wyre-Man himself! Unfortunately no one has apparently utilized your open-source code (I believe your program's code is public domain, correct me obviously if I am mistaken), and assumed responsibility for any future development. I am the wrong person for this; the last programming I have done was for my own pleasure and involved GW-BASIC (A DOS program!).

Still, an added option to merge objects, would IMO make TESTool obsolete (unless you like TESTool's automated cleaning procedure). I would like to see a more-friendly way to sort load order, as I have seen in Yacoby's Reorder Mods. It would also be nice to view each plug-ins records and delete or merge these together with another mod (a la TESAME). Overall, I would like to see the features of the several most popular TES Utilities merged into a single, elegant program.There is off course Psyringe's issue that needs to be addressed.

So Wrye, Psyringe is very interested in why your repair all function for saves, deletes references that have been migrated between cells. He would like a clear explanation as to why this filter is incorporated in the repairing of saves, and whether it would be wise or even if there is enough interest to create a new repair process which excludes this step.

I hope I had done some justice to the issues involved, as I must admit I have only a superficial understanding of these matters.

He's considering updating one part of the reference matcher - getting back into code and concepts he hasn't touched for months will be hard enough, let's not swamp him with wish lists.

I'd certainly like to have the one unified Morrowind tool as well, but the problem is, somebody would have to spend dozens of hours programming it. And those people who have the skill to do that may find that hard to justify if there already is another tool which does the same thing reasonably well.

That said, a tool that takes over TESTool's job would be most welcome - TESTool was written at a time when we didn't know as much about plugins as we do now, and as a consequence it sometimes cleans things it shouldn't, dialogue merging often causes problems, and merging objects crashes when you throw lots of data at it. But I wouldn't ask Wrye for it, I think Wrye has given this community a lot already.


We're already in PM contact about that.

I probably thank you very much.

I certainly wasn't trying to request anything from Wrye. I am more than satisfied that he might look into this specific issue with the Repair All function. My post above was simply me gushing about what could be in an ideal world.

Hmm, here's something strange that cropped up in my game: I saved the game (with LocalRefBeta13), reloaded, and noticed that my strength had been reduced to 0. Casting "Restore Strength" several times brought it back, but I wonder what caused that.

My character had 40 strength and was wearing the Right Fist of Randagulf (constant effect +20 strength). In this game I'm using GCD.

I don't think it's related to references, but this may be a bug or incompatibility in the "restore attributes" part of the patch. Has anybody else encountered this?

Test it further, I suggest.

In the past, I have noticed that if my PC advances a level while I have a fortify attribute active, often the PC will end up with that attribute reduced by the amount of the fortification and I will have to employ restore spells to recover. I always thought it was a quirk because it does not always happen.

sieboldii

Of course I will, I just thought that someone else might have seen this already, or might want to test it too, since it isn't something that requires intricate knowledge of the engine to check.

Of course I will, I just thought that someone else might have seen this already, or might want to test it too, since it isn't something that requires intricate knowledge of the engine to check.

But I've almost tracked it down now. It's an interesting interaction of effects. First of all, my strength really *was* zero points. That happened an hour of game time ago when I encountered an Elder Bonelord who apparently sapped my strength from 60 right down to 0. However, I never noticed this because I'm also wearing a magic backpack with a constant 135pt Feather enchantment, and at the time the curse happened, this backpack reduced my weight to 0 stones. With zero strength and zero weight, I was able to move around normally. Each savegame after the encounter with the Bonelord has my current strength saved at 0 points, which appears to have been correct.

What's going wrong is that somewhere along the road my current weight gets miscalculated. When I load my most recent save, and drop everything from my inventory, then a load of 135 points remains although I'm not carrying anything.

So, apparently my character was running around with 0 strength and zero weight for quite some time, but didn't notice. Upon loading the savegame, something gets recalculated (perhaps the effect of the Feather enchantment), and suddenly I cannot move.

This looks unrelated to the code patch, but I'll investigate a bit further just to be sure.

sieboldii: I checked, my character remained at the same level throughout the process, so leveling is unlikely to have had an effect here.


ADDENDUM: Confirmed that it's unrelated to the patch. The problem happens with the patched exe and the non-patched exe, and does not occur for any of them when I set the character's current strength to 60 in the savegame before loading it.

Current working hypothesis: Loading a game with a character of 0 strength causes this character's current encumbrance to be miscalculated - Feather enchantments are not taken into the account. The enchantment itself however will get initialized, and when it gets removed or cancelled, the game will add the weight that it *thinks* the enchantment had nullified before, therefore the player will now get unremovable encumbrance added.

Solution: Set character's strength to a non-zero value in the savegame (easy with EE).

Heyas, just trolling through all the threads for FAQs before I release it. Documentation is taking 2 days by itself heh.

Have Psyringe write it, he seems to have the time.

And the knowledge too! ^^

It's there. (5.1MB)

5.09MB is for the GUI. I've packaged all the libraries with it to reduce support issues. Tell me if it runs properly.

Hmm, 5 weeks since the first release. Still a little while to go.

downloading now, will report back on PAL GOTY version

EDIT: patch applies and runs with my old settings (MGE, etc) fine. Started a new game and interrupted the cutscene with ESC, got Now reinstalling and trying with mcp + fpu2sse.

And me from pretty much stock updated US version. Should work without problems I guess.

Stellar job! Works grand under Linux, just in case anyone was wondering.

Yay - it's out, it's out! And it seems I'm getting famous - thanks for putting my name on the product too.

Tested on my humongous installation. Patches work. Two oddities:

- During CharGen, while walking from the ship to the office, the water surface was plain white
- When entering the Morrowind Code Patch Showcase mod area, the local map shows a blurred messagebox with the line "Loading Area" instead of a map of the room. The door box appears though.

These might be caused by something in my installation (code patch r7 + fpu2sse + MGE 3.6.0 + FPS-Optimizer 1.96 + about 300 mods), I'll investigate.

Edit: Yep, definitely a problem of the installation. Both problems don't show on my unmodded test installation. The problem might be related to the fact that the (rather messy) install they occur in tries to start dozens of scripts when the player enters Seyda Neen (the game freezes for a minute at that point), so it might be too much for the engine to handle.

The patch fails to apply on my vanilla (no exe opt, no crack file, nothing fancy at all) 1.6.0.1820 English executable file. I have the European CD GOTY edition of the game. I just get this error when I try to patch it:


Should this be expected with the version of the game I have?

My tip to you. Make a clean mw installation. Patch up that exe. I'm almost certain that it will work. THe patcher doesn't seem to work on exe's that has been patched already manually before this installer.

But anyhow that should make you 100% certain.

Here's something interesting: this worked perfectly on my Windows 98 machine which has the exact same executable file as this computer does (I got the vanilla executable on this computer by copying it from that one). I seem to have got the patch to work on this computer by doing... nothing. I just checked it on the Win98 machine to verify that it worked with my executable version, then tried it again on this computer and it worked just fine.

The only thing I can think of is this: when I first tried to apply this patch, I did not have a completely unmodified executable file to apply it to. I left the patcher open while I copied the vanilla executable file over, then tried again and got the exact same error. It seems I had to restart the patcher to get it to recognize my new executable file and patch it.

Glad you got it working, and thanks for the info.

I thought of a couple more Morrowind bugs that I'd like to propose for consideration. The "fog bug" and the "red damage ring" bug. I'll describe them as best I can below, but if anyone else has a better understanding of them, feel free to chime in.

The fog bug notably happens with nVidia graphics cards when the fog density parameter for an interior cell is set to "0.0", the room is displayed as a blank screen. You sometimes see only light fixtures and the player's hands, but all other features of the room are obscured. This notably happens in Tribunal in the Dome of Serlyn. But a number of mods also have this problem. For Oblivion, Wrye fixed this in the Bashed Patch feature of Wrye Bash. These bugs are very easily fixed in the CS on a mod by mod basis. But it's a small pain in the rear, and it would be great not to have to worry about patching mods you download.

The "red damage ring" bug notably happens when you are a vampire taking sun damage and you enter an interior cell from the exterior. But I believe that it can actually happen to any character when you switch from interior to exterior or back, when taking damage. While you are taking damage, a red ring pulses around the edge of the screen. When the bug happens, the ring stays constant and does not fade away after the cell change. I believe the only way to make it go away is to again take damage, or to restart the game. Even starting a new game (without restarting) does not make it go away. This bug doesn't affect gameplay, it's purely cosmetic, but it is irritating to have that red ring not go away. And despite best efforts, this little bug really can't be fixed by a mod.

Both of these bugs are small. IMHO if it is found that they are very easy localized fixes, it would be great to have the Morrowind Patch address them. But if they require any great thought or complexity, it is probably not worth the effort.

Thanks!

Just slipping my pedant hat on but wasn't the bug in ATi cards? See this fix

Actually, I had that very mod in mind, but it also works for nVidia cards (like the one I have ), which have the same exact problem in that cell. But whether to call it an nVidia or ATI bug, the problem is that some cards fail when the Fog Density parameter is set to 0.0.

Well, well, well. Didn't know that, I'll have to keep an eye out for the bug (Nvidia here, atm).

So I have to download the file and the patcher will modify my EXE? but what happens if I still use mods that fix some of theses problems, like the fix for merchants so they dont wear the stuff you just sold em

The mods will still work like they did before, but they're no longer needed.

Just reporting that the error I reported earlier does *not* occur on fresh install + MCP.

Yep.


For most of the bugs that the patch fixes there are no mods that fix them. For those that are addressed by other mods, like the merchant equip bug, you can now safely remove those mods (note that removing mods causes much less problems now if you have the savegame corruption fix activated). If you can't or don't want to remove these mods, things should work anyway, perhaps with the exception of the missing month fix. If you have a mod that addresses this bug,and don't want to remove it, I recommend not activating this fix in the code patch.

I cannot confirm this with my UK version. Patcher has been restarted with the backup.exe from exe opt. restored, same error.

Maybe I should unmothball my Win98 steam PC as well..

It's a bit oblique but it means you didn't have MWSE running at the time.


I just realised.. the installer may have an issue with that. It can't tell you just reinstalled Morrowind.exe. Delete Morrowind.Original.exe if it's there.

Great! Now it worked all righty. Thanks, Hrnchamd

I hope everyone's read the readme on the savegame fixes. Is it clear enough? Need some feedback.
Is the GUI okay? It's fully translatable if you edit the .txt files.
I better add another check before it backs up the file.

I don't see how it could be made clearer.

I agree with the above poster. The explanation in the readme is necessarily a bit technical. Nevertheless, it seems to be about as clear as possible. I just read it through a few times to make sure I understood everything.

This is my worldmap now: http://i5.photobucket.com/albums/y196/nope...creenshot12.jpg

Something seems to be wrong in the upper right corner, I have to check that.

Does it re-draw the map every session? Or what happens if I'd use Wrye Mash's redraw map feature, which presumedly would only draw the old part of the map?

If you go there in-game, is the land there?


Hmm, I guess Mash would redraw the map in Morrowind's regular scale, and the patched exe would then redraw it. But I haven't checked. Will do.

Edit: Checked. Loaded a fresh savegame, saved it with the wnlarged map, used Mash to update the map, loaded the savegame and checked the map. It had the correct, enlarged scale, but some artifacts - among those a faint "crosshair" of light blue squares (the same color as coast water) painted over Vvardenfell.

Out of curiosity, what are the landmasses southeast of Veldion and east of Telvannis?

Upper right could be from Five Keys of Azura, I have to check that.

East of Telvannis, I thought it belongs to map 1? It looks like it would fit perfectly to map 1. I will have to take a closer look.
EDIT: Do you mean Telvanni Islands? Or the small island SE of Telvanni Islands?

SE of Veldion, no idea. Now you are chasing me all across the map here.

This looks like Five Keys of Azura to me. It's normal. Yeah, it looks a bit glitchy, but it's normal. The landmass is square, and since the author didn't expect it to be covered by the world map, he didn't bother using several cells to make transitions.

It's a bit smaller, and more colorful, but otherwise looks like it did with MWFPSOpt2. So no, nothing's wrong.


Edit: the "crosshair" comes from Mash's grid-drawing. Patched Morrowind doesn't erase your map but rescale it and adds the missing parts, so the reduced lines from the grid are there. You can deactivate that in Mash IIRC.

Yes, you're right. I just hadn't seen this part before because I never used FPS-Optimizer 2.


Sorry.

Hmm, this opens a nice opportunity to update Cryonaut's map of mods to a larger scale. Would be quite a bit of work though.

Edit: gez - Ah, I didn't know about the crosshair. So it's a feature of Mash? In that case, Mash's "update map" function and the code patch's "larger map scale" seem to be compatible. Nice.

Took the time to get all the map features working seamlessly. The code watermarks the map on save, to be able to detect if it's an expanded map or not, and therefore it can tell if it's been modified by Mash.

The patch is missing my dwemer coherer icon too.. wonder what happened to it. I'll the check the packager.

In the "saves" tab, right click on the header bar (the one with file, modified, size and so on) and you'll see a "World Map Gridline" option. It's on by default, but you can turn it off there. Use an unpatched exe to see how it's supposed to look like.

Thank you very very much!

I am going to try this out, as i am sure many others will be

Wow, I'm so excited to test this!

Kudos maestros!

Just wondering, whats that landmass west of Firemoth?

Excellent. I think I'll post a newspost at TesNexus so this gets a little more attention. But I'll wait for a few more days in case some major bugs show up in the current version.

I'll mention the new MGE and probably the UUMP too.

edit: What was the reason for reducing the max duration for spellmaking?

Is there a list anywhere of all of the fixes made by this patch with detailed descriptions of each? If so, would someone please link me to it or tell me where it is?

If not, then will somebody please tell what is the "Calm spells fix"? I only know of one big problem with the "calm" effect - it just keeps on working. This allows exploits like weapons enchanted with "cast calm on strike" which make your character completely invincible. Has that exploit been nerfed by this patch?

I did a test on removing mods, specifically I removed an esm, which had modindex 3 (it came even before Bloodmoon in my load order). When I loaded the save game, I got lots of errors from global scripts unable to locate their references, among those some Vloodmoon scripts.

I remember that I tried to remove that esm before with Mash, and it didn't work either. So I don't think it's something that the patch breaks, rather something that neither Morrowind, nor Mash, nor the code patch, is able to re-match after removing a mod. Any idea what's going on?

The "Calm" spells forced enemies out of combat no matter how low the magnitude of the spell was. This was caused by the spell effect calling StopCombat every frame. This call has been removed. I don't know whether this affects the situation you're describing too.

Could be just the sheer amount of stuff in the BM master. Try this:

Move the TR Map 1 ESMs to the bottom of your ESM load order. Then uncheck a couple .ESMs before it, and see what happens.

I'm pretty sure that the effect is not limited to Bloodmoon, it'just easier noticeable when an error like "Cannot locate reference for global script BloodmoonMain" pops up.

I was thinking that maybe if a .esm file has several megs of crap, it'll be more likely to throw errors.

great news!

What happens if you change the esm's load order prior to trying to remove it?

sieboldii

Update: I think I found the reason why the scripts lost their references. Scripts are saved with a RNAM subrecord which has a modindex and objetindex listed. The modindex apparently doesn't get rematched when the load order has changed.

Name that ESM, Psyringe. What does it change?

Gyahhh.. it's targeted global scripts. All the RNAMs I checked were set to 0xffffffff.

It's Giants_Dragons.esm, a rather old one that shouldn't be in much use anymore. But the problem is unlikely to be limited to that esm.

I tried syncing the save to load order with Mash. This changed the modindex of the RNAM subrecord, and I didn't get these errors when loading the save afterwards.

I'm here in case you ned quick tests to be done.

Time to start a new thread. Once it is up, Do the "report" thing, and one of the mods will add a link to the new topic, to this one.