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. Currently in beta.

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 loader fix

See the previous thread for more detail: Repairing those Cogs

Here's what I'm working on now:

- Local ref bug
Description: You've heard of savegame corruption. Morrowind does it differently. It does loadgame corruption.
Status: Most of the way there.

- Fatigue spells
Description: Damage and absorb fatigue cannot drain fatigue below 0 and cause the enemy to collapse.
Status: It'll be done, okay?

- Map
Description: Need a bigger map.
Status: Looking for a bigger piece of paper.



Getting it:

This is still in beta. To start testing, you will need the patch program in release 1, and the latest patch file released. Read the readme, it's important.
Note, if this crashes your Morrowind, please fill in this crash report posted here.

Files: http://www.tesnexus.com/downloads/file.php?id=19510

Last release notes:
Release 6
- ESP loader fix. The mod loader can now identify inserted and deleted mods properly, by matching their filenames. You can now change your load order without problems. Adding mods to your savegame will now cause much less issues. It is still recommended to use Wrye Mash to update or delete mods.
- NPC health bar change. Your pet Ogrim should no longer peg its health bar to the screen. Only restore health spells cast by you will displayed, previously any regeneration ability may have trigged it.
- Transparent clothes in the inventory. More changes, the background is transparent again and drawing errors should be reduced.
- Vampire stats fix. The previous fix unintentionally changed birth sign stat boost abilities. Only new characters were affected. Now working properly.

O.O You FIXED the music bug? I thought you said you weren't going to do it?



*sniff sniff* I'm so happy.

Don't recall if this was answered in the previous thread....

Do you have any plans to incorporate Timeslips exe optimzier, or the FPU2SSE utility into your patch?

You can apply the EXE Optimizer after patching with this one. I don't see any reason to incorporate the EXE OPT into this patch as not everybody will benefit from the EXE OPT.

That's excellent news! This means I can finally play the game with my headphones on (no more music blasting away directly into my ears). Huzzah!

* Swiveller *

I can't wait until this is finished and I can play MW as it was meant to be played.

That was referring to Dirges' request to figure out what was wrong with his audio files.


Other patches are going to be 'at your own risk' for now, they could interact with this patch. It needs a lot of testing.

Fixed the issue with the land disappearing for a second after equipping something.

Tell me if the enchanting values feel right, in particular with the high capacity items, tower shields and that stuff. I want to see total cost (soul gem value + fee + original item value) and final value. It doesn't matter which spells you use, it's calculated from soul size and enchant capacity used.

I had a look at this, it's difficult to reproduce it to find out what's happening. Tell me if you can force it to happen consistently.

The reflect absorb issue is fixed, and I'm going to throw in a change to the NPC health bar so you can see their health go up. Works for healing spells too. Looks like I'm running out of bugs to fix! New release in a few hours.

Wow, this is really impressive! If you're running out of bugs to fix maybe you can look at some of the animation related ones...

1. The list of bone names that can be used seems to be hard-coded. It would be nice if we could use any name, or if the list could be expanded.
2. If a bone exists in an animation but not in the skeleton, the animation will fail to load and show an error message rather than just ignoring that bone.
3. The most annoying one... trying to play an animation via script on the PC causes them to stop animating or writhe, and the player can't regain control. It'd be nice if this could work so long as player controls were disabled and control could be returned when player controls were re-enabled.

By the way, I took a shot at making the sky render with MGE... I could get it to draw but not in the right place in the reflection. I think you requested that, right? Maybe you can take a look at the commented out code dealing with recording renders. You can get it from the sourceforge page now via SVN.

(any chance in setting damage fatigue and absorb fatigue to knock out characters when the fatigue goes negative like drain fatigue?)

wasn't there a bug with setting the music volume in the menu, where setting it completely off caused stuttering?

also could you check how vampire stats are added to the player, i recall it's a bug where the stats are multiplied rather than added.

there's also a bug where actors effected with levitation, when they die, will fall through statics, which is very noticable in interiors.

i'm trying to think of the guard bug, where even if you pay off your bounty on a death warrent, they still come after you. not sure if that is a script error or not though.

there's also the fortify health bug, where when the effect expires, it still subtracts the full ammount of fortified health, which can kill the player, making the spell rather worthless. it should just remove any excess health above the maxmium (at at the very least not kill the player). the same can be said for the fortify fatigue (player get's knocked out) and fortify magicka effects.

this one is a stretch, but some NPCs will 'float' away for no apparent reason, like the orc in the mages guild in balmora. i have no clue where to look for that bug.

thanks for all of your hard work!

1. There's barely any space in the data segment to stuff new things in.
2. Possibly fixable.
3. Could you give me a few sample console commands to try out.


Hmm.. right now I can't see where the final alpha blending ops (src/dest) being set up, and what's up with the scale by 50 thing?

I can tell you more about ers666's "problem." That can happen only two ways: if your character has only one of a particular type of scroll and he uses it, then the magicka icon will go blank and he will leave spellcasting mode. Also, the very same thing will happen if an NPC casts silence on your character.

It's not a random occurrence or a bug, but I could see how someone who doesn't totally understand the magic system would think so. :^)

Your work is awesome. It may be redundant, but I can't wait to try all those new fixes and features.

If you are looking for more bugs to squash, a likely candidate is the Calm bug. Basically, Calm Humanoid and Calm Creature spells are supposed to lower the Fight setting by a given amount, making the afficted character less prone to attack depending on their magnitude. However, both spells are bugged and they always stop the enemy, even if their magnitude is 1.

Sorry, but I understand how the magic system works.

Most of the time I have a Recall or Intervention spell (not scroll or enchanted item) ready when running around the countryside for easy teleportation to my stronghold. After some time, without even casting the spell the icon turns black.

To correct myself from my previous post, I tested it and the Spell appears to be selected on the spell menu, but it won't work until I click on it again. And that with the magicka bar full and 110% Resist Magicka (Breton+Savior's Hide) so, no silece spell could affect that test character. There's no need to do anything special just keep playing with an spell selected and the glitch happens. I might be wrong, but I noticed that the problem seems to occur mostly after area transitions.

I'm running Morrowind with both expansions and the latest patch (1.6.1820), of course.

As I said, it's a minor annoyance, but it's there.

Should I make it work like the Command spell, pacifying actors up to level X? It would scale better in my opinion. I'm not sure just lowering fight will make them stop combat. Hmmm, maybe that's where the bug is, they don't start combat again after the change.

Flat out amazing stuff Hrchamd. Having enchatnment actually add value to items..that's..wow. Suddenly it'll be possible to really play a wondering mage, making money by selling handy enchanted items to the town folk.
Just wanted to say thank you.

Working on it.


Never seen it. How, why, when, who, I need answers.


Ah right, it's in the GCD readme. It's really a bug with fortify attributes doing something stupid when applied as an ability. 99% of vampirism is implemented by scripts, but then they go and do that.


Going to pass on this one.


Fortify effects only affect your current health, even pushing it above maximum temporarily. I don't really want to turn fortify health into an instant heal spell, but the real issue is all the fortify effects share the same code, change one and you change them all.

Also, found out the problem with Calm. The thing calls StopCombat every frame, can you believe it? Fixing it now for this release.

I'm sure this must have been asked before, but a quick scan through the last thread didn't yield any info (or I wasn't looking hard enough; if so: sorry), so, are there any plans to fix the 'map problem' of the map being unable to move to or show land too far from Vvardenfell, in a more elegant/efficient manner than the FPS Optimiser does ('cos with this, presumably, it'd just be a patch and then it'd be fixed forever - you wouldn't have to start up an annoying third-party program each time you want to start the game)?

If this has already been dealt with, sorry!

Yeah, that map fix is a really cool idea, finally would be able to see Telvanni Isles.

Do you plan on making the map scrollable/zoomable/moveable?

Bethesda developer fail!

Anyway, it's great that you've figured it out.

Not installing this when it's done is as stupid as not installing the official patch...

From the first thread.



Let's hope this one works as well as some of the others have.

Crap, yeah it was in the first post.

Thanks for pointing it out.

I have had those days as well......

Just trying to think of bugs. I know there's an issues with companions following you through droos and occationally dieing. I think that's been corrected though for most companions.

I did some testing of the releases, and am really impressed with the progress and stability! Looks like my report is a bit late though.

Month fix (missing Morning Star)
It works, and doesn't cause any of the scripting problems the other fixes produced.

Enchanted item display bug
It works, no more washout enchantment effects.

Mercantile bug
One can now barter for over the display value of an item, a big boost to high mercantile. Balancing can be achieved fairly easy with modding.

Transparent clothes in the inventory
Tried out a few outfits, and they appear correct without any visual artifacts

Unarmored bug
Works perfectly, no need to wear any armor for it to work anymore

Spellmaking limits
This does make it a little more difficult to make small magnitude spells (the slider jumps numbers), and I can't imagine a need for a 1000 magnitude spell, it's nice to have the option outside of the construction set.

Enchanted item price increase
Very interesting, which finally lets enchanters make some money outside of selling filled soul-gems. Like with the mercantile fix, balancing can be done with modding fairly easy.

Merchant equipping
Funny story, testing this out, I decided to start with an Imperial to test initial prices. My wife was curious to see what I was doing, as I told her I was just testing something out. She comes up and watches as a naked imperial boat guard walks up and says to come with him. "Well, he wasn't suppose to be naked..." I explained as my wife just gave me a wierdest look and walked away. We joked about it for the rest of the night.

Restore attributes issue
No longer need to remove magic effects before restoring damaged attributes.

Stealing from knocked out NPCs
No longer need to cast calm spells anymore, and brings back a viable play tactic.

I also experienced the flickering, and looks like you've addressed it.

Keep up the awesome job! We all appreciate it.

LOL!

To my knowledge, the bug itself (companion falls to death when changing cells while levitating) has never been fixed. It was suspected that for some reason the companion's script reseted under these circumstances, and this was deemed unfixable. However, as a workaround, most modern companions have their acrobatics set to 200 now, so if they fall, they will survive. An actual fix of the bug would of course be preferable, because it would enable us to give companions sensible values in acrobatics, and perhaps prevent the fall altogether.

Release 5. Less nakedness.

That's good news. By "less," I take it that there are still some remaining issues and/or more testing needs to be done. That's fair. I hope you can get a final or final-ish version out before you have any major real life obligations. Kudos!

Aye, I have no idea why the chargen guards get naked. Just hope it works.

About testing the reflect changes. Not many NPCs have spell reflect, but you can add 60% to any NPC with the command "addspell reflect_60". Couldn't get the health bar to show the NPC health going up when you eat a reflected absorb health spell, but if you want to see it happen, cast a long duration low damage spell on the NPC, then absorb away.

Vampire stats fix refers to the initial stats gain you get once you become a vampire.

If you can fix the map allowing to see other regions i'll praise you forever
Meanwhile i praise you for all the others fixes

I hope no one hates be for being the barer at bad news, but the only issue Reflect + Absorb Health was an on-touch verses on target enchantment that deals the full range of damage of the weapon + the absorb health damage on you.

Now you've made Absorb Health useless, while before the spell worked but could kill you due to a bug. I mean I can understand why you've fixed every other issue, but this one confuses me. Maybe it's just me and the fact I've never used abosrb health enchantment, but from what I've seen of others posts, the only issue is the difference between on target and on touch. No bugs other than that.

Your patch for that may make sense, but now it's rendered useless as a counter against reflect.

Sorry, but unless these patches can be added seperately, I'm still not going to use it. Despite fixing the music bug.

and the month fix, and the mercentile, and the echant, all of those, really...

If I am wrong, well, you're going to have to show me the source code to prove it.

I came back late, but Hrnchamd.. Her music, not his. xx' And it's getting to be a serious pain, I really wish you'd look at it, every single song I have is beginning to toss errors at me. xx'

I'm not sure I understand what you mean, but if you're saying that Absorb Health wasn't bugged, I think this ...



might be the reason.


You're saying that a spell that allows you to damage your opponent *and* heal yourself at the same time is *useless*?


Absorb Health is ridculously overpowered in Morrowind. Compare it to elemental damage spells, like fire damage:

- AH damages the opponent, FD does so too. Okay.
- AH heals you at the same time. FD does not. Aha.
- AH is immune against reflection (except in one special case which usually is never triggered), while with FD you'll have to deal with the full effect of the reflected spell.
- AH is part of a magic school that almost everyone learns automatically due to teleport spells. FD is in a school that only makes sense if you focus on magical attacks.

Now where is the balance in that? Why should anyone learn FD instead of AH except as a fallback option?

And what is this "on touch" / "on target"-difference you're talking about supposed to be?

DavidB1111, the issue with absorb health is that it has never been reflected by enemies back at your character properly. If your character casts an absorb health spell and it is reflected, your character *momentarily* takes the full hit of the reflected spell, you lose health just as you would if any other damaging spell were reflected at you. Unfortunately, there *is* a bug in the way this spell is reflected that causes your character's health to be immediately replenished as if nothing were reflected at all.

Consequently, a reflected absorb health effect never really hurts you like it was intended to unless your character's current health status is equal to or less than the magnitude of the spell being reflected - in that case, you take the full force of the effect and DIE before the bug restores your health.

Thanks for correcting that Hrnchamd. :^)

Oh, well, all of a sudden I feel really stupid!

Absorb Health does damage to your enemy but if it's reflected back it absorbs your health and then adds to it, killing you if your health was too low...

Okay, what's the problem here anyway...fire damage murders you if you reflect it back on yourself, unless your immune. Same with all other spells that deal damage. So, the bug part is if it reflects back on you it kills you if you don't have enough health to survive the reflected damage.

So, does this mean Reflect is bugged?

I mean come on here, you're telling me that making a spell and casting it at an enemy and having it reflected back and blowing you up is a bug? <sarcasm>
Look, I understand the issue here, but breaking the spell by removing it's ability to actually hurt something with a high reflect while all others don't, doesn't seem like the right choice.

Look, yes, perhaps it's a bug in the game engine, maybe I've never understood how spells work playing war mages with emphasis on the war, but shouldn't all spells carry a risk? Even a spell that's too good to be true, such as the awesome absorb health.

THat's all I'm saying, if I got it all wrong, please explain. I know I'm not a living God like Vivec, but still.

Edit: For great justice, understand I don't make pure mages...

And for Psy

Wait, what? No, that's what it's unmodded, unchanged version does.... To be honest, it doesn't even affect the monster you get it reflected off of.

Look, you hit something now, with this new patch he added, and it reflects, seriously injuring you while healing the monster/NPC. This is now broken, unless you can come up with a valid reason for this, in which case I'll recant my complaint, and juggle live nuclear warheads, in Moscow....

I'm sorry, but just because you can use a spell against reflected enemies with only a little worries doesn't mean it's broken...

I have agreed with all other adjustments to the game he has written, this is the first real one I can't figure out and think is broken...

I think I'm approaching text limits, so I'll have to wait for someone else to post...

Its quite simple. When you cast the spell at an enemy without reflect you eat their health, therefore your hp gets restored if its not full. But if you cast the spell and it gets reflected then you eat your OWN health instead of the enemy GAINING health from reflecting the spell back at you.

Now the enemy will gain health from you, and you will no longer eat yourself and then heal yourself afterwards with your own eaten life when an enemy reflects it. Bug fixed.

No, the bug part is that Absorb Health *does not* hurt you in Morowind. All other spells, when reflected, hurt you. Absorb Health, which is already more powerful than the other damage spells because it also has the side effect of healing you, doesn't hurt you. I don't see what's so hard to understand about that.


That's the opposite of what I said, please read my post.


I have no idea what you're talking about. Your statements are in contradiction to the unpatched game, to the patched game, *and* to everything I said. It's as if you lived in your own, totally different world where everything is turned around and no communication is possible.


It's the whole *point* of Hrnchamd's fix, and of eveything *everyone* has said in these threads anout this topic, that absorb health did *not* have an adequate risk and now, with Hrnchamd's fix, has one.

Please, at least re-read the posts that people have made on the topic. It's hard to believe that someone could actually consistently misunderstand them as the opposite of what was bein said, so I'm really wondering whether you're just trolling.

You just need to think logic here.

What reflect does? It reflects the effect of a spell, making it turn back and harms the caster instead of the target. What is the effect of Absorb Health by definition? Absorbs the health from the target and gives to the caster? What is the reverse of that? Absorbs the health from the caster and gives to the target. See? Simple. That's how it should work from the begining.

The old way turns all the other damage effects useless and is unbalanced. Why would I risk burning myself casting a fire damage spell at a Frost Atronach when I could just use Absorb Health instead? It is far more secure. And the only way to "kill yourself" if the AH gets reflected is if the total amount of health absorbed in one second is equal or greater than your own health. If you have 200 health, attack an Riekling with the Black Hands Dagger (wich has a potential to absorb 300-750 points of health after 30 seconds) and the effect gets reflected you won't die, because the spell will drain only 10-25 pts per second and will heal these points the next second, but if it doesn't get reflected the Riekling will have a death sentence in 30 seconds. Doesn't sound fair to me.

I know they are different games but, just as a reference, this is exactly how it works in Oblivion, if an AH spell gets reflected, the target absorbs the casters health. I don't believe that they changed how the spell works just for the hell of it, they changed because the Morrowind version was buged.

Okay, Then I apogize to Psy and to all others. Can we go back to being friends now, and I like to point to my sig again...
Asperger's syndrome is not a fancy word for I am a troll with 126 posts.

Trolls usally get banned before double digits...

Anyway, I'm sorry, I just got everything all mixed up, therefor I apologize. Are we all cool now, Psy? THe big guy who created this thread?

Also, Sometimes I fail to read things correctly, it doesn't happen that often mind you, but I do. A troll though, I don't know how to troll?

I"ll shut up about the Troll comment before I get yelled at by a moderator...

One subtle change I noticed is that the paper doll character is drawn on a solid black background, where before it was drawn on a background that could be solid black or completely transparent(user settable).

I usually run with a completely black menu background, however when I wear black outfits a little transparancy in the menu helps to better see the clothing. Is the solid black background needed to implement the paper doll fix or would it be possible to have user selectable transparency?

All the other fixes I tested work perfectly(as far as I can tell).


I spent some time trying to think of other possible game fixes. The only other fix I could come up with is to fix the shadow rendering problem. If you are below NPC in a multilevel structure shadows will still be casted through the floor on to the ceiling. I know you hate graphical fixes however this is all I could come up with.

Great Job and thanks for making a good game better.
DR

"Acrobatics skill enables one to jump long distances and to avoid damage when falling from great heights. Nimble acrobats can reach areas others cannot get to and can direct their paths while falling."

Well I tried high values like 3000 but it doesn't work for the part"...can direct their paths while falling."
Without speed you can't direct your path and you should be running too for speed effect your ability to change your path. Maybe it's not a bug, but it looks wrong for me.

Excuse me for that. If you tell me the actual errors, I can say if it's a problem with Morrowind or your codecs.

I sort of understand David, there's quite a bit of spell reflecting going on in Bloodmoon, and it's a good to have a spell to get around that, but there should be more creative ways of doing so. Absorb just had no risk. If you could test the features you do like, that would be more constructive. When I get the GUI installer up you can choose to turn off whatever you want, so relax. Betas are for testing.

The errors are simply "Cannot play "Explore/mx_explore_3.mp3"." and similar followed by a close. It'll play SOME songs, but not others, and it changes which ones it will or will not play seemingly at random.

For example, mx_explore_17.mp3 used to work, while 16 didn't. Now that I removed 16, 17 doesn't work. 11 was screwed up so I removed it too, and its counterpart seemed to be track number 14. Another one also caught the error bug, track number one, and 5 more exploded when I removed this bunch.

I fixed it by simply re-encoding (at significant loss of quality) all tracks at the SAME exact bitrate with no tags.

So far it works, but it's troublesome and irritating, and the compression artifacts are murderous to an audiophile such as myself.

Judging from the fix and the symptoms, I really wanna say it's Morrowind. xx' But you'd know better.

It used to have a nasty red colour leaking through transparent clothes so I tested it with a black background, I'll set it to back to the original transparency. The game uses stencil shadows, which have gone out of fashion for pretty much the reason you gave me, not fixable.


Checked the code, it is in fact an error from DirectX that causes the message to appear, Morrowind just passes the file name over and gets ok or fail back. It could be an issue with the codec that gets selected by DirectShow, or some weird characters ending up in the filename.

Well it's not the filename. How do I fix the codec? All of my music programs play the songs fine, I could just snatch one of theirs, I just need to know what to replace xx'

Have you got ffdshow? It has lots of configurations including DirectShow control, you can choose which programs will use it.

No, but I definitely will get it. Thanks ^^

An install question.

I'm avare you need for r1 to install and then the current latest version ( r5 for now ).

What if r6 comes out?

Do i have to reinstall r1 again and then r6 ?
or
install r6 over the installed r1r5?

You can update from the latest patch.

At least I tried both ways and found no problems.

I'd assume updating from r5 to r6 wouldn't hurt anything, since it'd be overwriting all the old changes with the same exact thing as was previously there (with possibly some differences if he was fixing something previously still screwed up). It's kinda like having a text file with the numbers "23" and overwriting it with one that says "2345" -- no data lost.

It's supposed to be as easy as possible to change between patches. Whatever version of the mwpatch file is there, is the version you will end up with when you run the program. You can go from any version to any other.

Little bit of a surprise to me, because from what I see the first release won't set the fixes of, say, r5 back to the MW defaults. So you could conceivably end up with naked merchants, but everything else fixed. Maybe it's something invisible, though. xx'

Hrnchamd, how about fixing the Trueflame bug, where the flame looks off the blade? PIC

The bug occurs on Imperial characters and maybe Nords.

Wasn't there some kind of bug with the corprus disease where the strength bonus given by the disease would stay permanently even after getting cured? I'm not sure if that was actually the problem or if it's something the regular Unofficial Morrowind Patch can fix or has fixed instead of this project.

I do recall there being a corprus bug that completely breaks the main quest -- you can get the disease from someone in the Vivec Arena, I think, and Divayth won't cure you. But that's outside of the scope of Hrn's patches, I think xx'

I don't recall the strength issue, but I could be underinformed.

That's hardly an issue, IMO; doing the main quest, few people would hang around a long, long time with the disease; I for one have never been around more than 1 day/night.
Unless on purpose to exploit that ... and those would prefer not to have it fixed.
And I think, the 1st encounter with a bonewalker (drain) or GBW (damage) would fix that anyway, except for those gifted with 100% absorb, reflect or resist.

It doesn't need any code to undo the previous changes because it will always take the original exe as a base for its patches. From the readme:

Oooh. I feel dumb ^^

actually, this bug also affects archery too, those functions assume your character is the scale 1.0x1.0, so if your height and weight is different, then the effects are off, and archery is skewed.

Any test results yet? The GUI installer is coming along.

How about the bug involving overlapping alphas disappearing?

When you have an object with full transparency behind another object with full transparency the object in the background disappears.

For example: object A, a geometric plane alpha-mapped to look like a leaf, is partially obscuring object B, a... second geometric plane alpha-mapped to look like a leaf (I have 0 imagination ). When this is the case, object B fails to be rendered.

I think.

I hate to bring more rain onto this, and from the number of posts praising the new paperdoll I can only assume it's something with my setup (Radeon X1600, latest Catalyst drivers (8.8), August '08 DX9 release, MGE 3.5.5, Morrowind Enhanced and FPS Opt 1.96, GotY edition Morrowind, patch r1 through r5 in careful order), but taking my trousers off leads to a red wash over the screen and text becoming pale yellow blocks. Putting on trousers or vanilla armour sets things back to normal (not tested with user-made armour that doesn't use transparency yet). I'm assuming it's related to alphas, but I know nothing of how this stuff works.

Photobucket is still refusing to play ball for me, but I have screenshots if you need them (which prove the paperdoll works with this aside, via the aptly-named 'chainmail bikini'. I laughed).

I haven't been able to test anything else, sadly. This seemed the most obvious place to start.

(Re: New bones, requested by Liztail)


Interesting. Does this mean there is NO space for new bones or that there is very little space and only a few can be added?
If only a few, of the top of my head, Liztail and Axel are the people to ask for useful new bone names.
I'd recommend a wobble bone, as used by other Nif-based games for interesting effects!

Been discussed before, it is a classic problem in computer graphics. There is no order which you can draw the whole objects to make it look right, one of them needs to be cut in half. Requires a full engine rewrite to solve it properly.


First, try it without FPS optimizer, it's essentially a patch program too and could conflict. Send me the pictures by email.


Seen LizTail's work on the Better Bodies forums? It's interesting. Now there's no real way to add more bones to an animation group, but we can change the groups in-place, which is verrry interesting. It may be possible to bind finger bones to the upper arm and forearm for wobble bones, they are in the same group. Hey, maybe I could make a left-handed patch. ....
So gonna try that now.

any chance about a more exe friendly version ?

I mean it say "Original file is not the correct version"

other programe such as fps optimster doesn't say that, it works on allmost every version of morrowind.

Very, very familiar with all of Liztail's work. Which is why I suggest if you can add any kind of extra bones, Liztail is the man to consult first. His recent animation kit is astounding!

As has been said, the Hrnpatch is currently in beta stage, so at the moment the focus is on getting the patches right. Compatibility with other versions of Morrowind will come later; I think Hrnchamd has already said that he's planning to support other languages too, but we'll have to see how it works out and in any case it's not a priority right now. First we have to make sure that the patches actually work, *then* we can think about porting them to other versions.

Patches that actually work is already done -- but there's more awesomeness yet to finish (map, etc)! Once that's done, maybe ^^

Were you able to figure out how it decides what bone names are okay and which to ignore? I was wondering if it was possible to make it accept any bone name rather than adding to the list of acceptable ones, but maybe there's a special structure that controls NPC animations which only has so many slots? Is that what you're saying? It's just interesting that creature characters like Almalexia can have as many bones as they want but NPCs can only use certain bone names.


It would be really really awesome if either of these can be fixed!

Here's an excerpt from the "Morrowind Scripting for Dummies" guide which talks about the animation scripting functions and the problems with trying to use them on the PC:

[codebox]Not all models have animation groups, but the different banners (under activators) are good examples to see what is
meant (see example below). Examples for GroupName are: idle, idle2, idle3, walk, etc. These functions do not work on the player character.

PlayGroup, GroupName, [Flags]

PlayGroup, walk, 1

Plays the animation group defined by GroupName. Optional flags can be used to start the group in different ways (see below).

LoopGroup, GroupName, Number_enum, [Flags]

lays the animation group defined by GroupName. The animation will be looped the number of times specified, and then return to the Idle animation.
Optional flags can be used to start the group in different ways (see below).

SkipAnim

Causes the current animation to not be played for this frame.

Flags:

0 = Normal

The current animation will finish its full cycle, and the new animation will start from its beginning.

1 = Immediate Start

The current animation will stop regardless of the frame it is on, and the new animation will start from its beginning.

2 = Immediate Loop

The current animation will stop regardless of the frame it is on, and the new animation will start at the beginning of its loop cycle.

Note: PlayGroup does not work on the PC. With Bloodmoon installed (not necessarily Bloodmoon.esm selected) some of
NPC animations are crosswired. When called from console, they may look correct, but if you insert NPC->PlayGroup,
group, 1 into the script, you may be unpleasantly surprised to see a different animation than you expected (Forum info / Kir).
You may have to experiment to find the correct animation (Check out the info in the section on AIWander for a list of NPC
dle movements; Kir is working on a tool called "NPC Animation Explorer", keep an eye out for it!).[/codebox]


I just copied the commands that I saw in PIX exactly so it uses texture stages rather than alpha blending. The scale was there just so I could see it so long as I didn't jump too high... I think the basic problem is that a different projection is probably used for the sky than is used for everything else but I didn't spend too much time looking into it.


Well, not necessarily a full rewrite... basically the problem is that all the alpha objects have to be drawn twice. I'm not sure exactly how you're doing what you're doing, but if you could somehow find the command that causes the alpha scene to draw and rig it so you could call it again at a later time then you'd be set. The order of events would have to be something like this:

1. Set user clip plane which causes everything ABOVE the water to be invisible.
2. Draw all the alpha objects, pixels above the water will be clipped away.
3. Disable the user clip plane.

4. Draw the water

5. Set a user clip plane which causes everything BELOW the water to be invisible.
6. Draw all the alpha objects again, pixels below the water will be clipped away.
7. Disable the user clip plane.

I'm not sure if that's possible or not, but that should solve the issue if it is. Ideally the engine would draw only the objects that were possibly visible in steps 2 and 6, but it should look the same to just draw all of them even if it's sub-optimal. For MGE to do that I'd have to implement a system to capture all the states of all the objects rendered so that I could re-render them later, but if there's a way to just invoke the drawing of that alpha scene twice, that'd be awesome.

EDIT: Oh, and do you have any idea if it would be possible to add Morrowind's wind speed to the memory map in MGE so I could make the grass react to it? Thanks =)

I have always wandered my Morrowind wants to process all scripts running each frame. Some CPU heavy scripts are coded to return without fully running to get around this, however, the script needs to be called regardless. Could a perfromance gain be optained by patching Morrowind to skip the processing of the scripts every other frame? Or 1 out of 3 frames? For a target FPS of 30, scripts would process every 100ms; I can not image needing to process scripts more than 10 times a second.

I have no idea how Morrowind handles script calls internally I am just wondering if a tweak can be made to improve perfromance?

Thanks
DR

If I remember right, he wants to stay away from tweaks. But doing so would cause some mods that use timers based on frames some problems? Timers would need to be tweaked for mods if there were some timed event.

Eeeh...It'd be a better idea to just add a new function that sets the number of frames between each individual processing of the script (1 being default behavior). If the function isn't set, then it defaults to every frame. This leaves mods alone while allowing you to lighten the load, if absolutely necessary.

This may be better left as a tweak if it is even possible. However, it may not cause a much of as problem as you think. The timer I have seen in scripts is not based off of FPS, since this can vary 10 to 1 on different machines. Also, since the FPS or script execution rate can vary tremendusly, if someone did write a script that depended on FPS for timing, it would perfrom wildly different from machine to machine and probably yield bad results anyway.

The corpus cure which Divayth Fyr gives you is supposed to leave all of the positive effects of corpus, while only ridding the negative effects. That means the strength and endurance bonuses are intentional.

It's rarely an issue for characters with max strength or endurance to start the main quest, but if they do, they only get a temporary bonus when normally it would be permanent. It's a bug that once obtaining over 100 strength or endurance from corpus, damaged stats cannot be restored.

Once upon a time, ThePal has removed Month Fix from the UMP, because there was a problem with Powers that sometimes did not reset so you were not able to use Powers anymore. I guess this problem would be hard to find, but are you aware of this and have you fixed the Power reset issue as well?

EDIT: Nm, found it in the older thread.

There are hardcoded bone names because the animation override groups, AI movement code, and attach point system needs to know about them. Not sure how the loader will handle extra bones, I can turn off the error message but I can't see any extra code that does anything with it. The game might choke, it might not. You can try it in the next patch.

PlayGroup breaks the AI controller on NPCs immediately, they stop moving, and stop responding to commands too. I guess the AI waits for an animation to finish before changing movement state, and when an unexpected animation plays it loses track of everything. Seems a bit hard to figure out.


Morrowind does basic state change minimization, it reuses state from the last call if it hasn't changed instead of setting it every time. You would have to copy the alpha blend state to avoid using the blend state of the last drawn object, etc for most of the state. Yes, the sky has it's own root node with some transform on it, just have to copy the modelview matrix and flip it, that would be close enough without doing the full reflection calculation.


I've got the wind vector, took 10 minutes to find. It's 3 floats at *(*masterImage + 0x58) + 0xb8. You might want to check if Mournhold works.
Also a pointer to the current weather struct can be found at weather = *(*masterImage + 0x58) + 0x3c. If it's not null, then the weather type is at *weather + 4.

I've already accounted for the state changes... I cache the current state whenever it changes so I know what it is when I "record" the render. I also store all the matricies except for the projection one since I was trying to use the reflected projection from the world... it seems like I have to store the projection used at the time the sky was rendered as well. One I have that, using a negative scale and reversing the culling might be the easiest way, that's a good suggestion.


Awesome! That's exactly what I need!

Going by the code on the SVN, you don't record the framebuffer blending state (D3DRS_SRCBLEND & DESTBLEND), which is pretty important, and only record the world matrix, and you use a calculated reflection view matrix from distant land instead of a recorded view matrix. Talk to me on MSN or something.

I love to see these geniuses' brainstorming. This means we'll probably have new candies
Thank you guys for all your work!!!

Kinda creepy, that with them using their mojo-language and whatnot...but you're right. Morrowind board has quite some "Master Trainers" and we're happy!

I don't know if this can be fixed, but is there a way to prevent saved game corruption?

The magical pony vendor is fixing that in the next thread down.

Does he sell horse armor for his pony's?

ouch. ^^" Even I felt the recoil from that one man.

r5 seems to work fine so far. Havn't had much time to test it. Still trying to figure out why the guards keep using spells even while I have the no spells mod...probably MCA guards that need tweaking..

A simple no would have sufficied, no need to be rude.

I think it was just intended as a tongue-in-cheek reply.

I guess that not being able to see eachother's faces means we need to be a bit more careful than we are in real life. :-)

* Swiveller *

You may be right, Swiveller. The problem with the internet is that it's sometimes hard to judge intention, we're limited to what the other person says. Anyways, keep up the good work, Hrnchamd. I'm glad somebody is taking the time to fix the issues with Morrowind.

So that's what it's not doing? Excellent description there Liztail!

Nah! Makes sense to some of us even if we haven't the skills/patience to do this sort of trawling! (I wade through binary/other peoples object code for money, not fun! Well, OK, sometimes a Nif or two).

If it's any consolation Jac, I've narrowed down the local refs bug (the cause of missing doors and NPCs when multiple mods are in the same cell, interior or exterior) to only six pages of code. In tiny writing.

The engine would need a full rewrite to handle clipping through the situation described earlier >>

That may require an excessive amount of clip planes.

*Wishes the magical pony would implement sky reflections already*

The problem described here could be due to this local refs bug?

Well, you've done such good work so far, I was hoping this was also possible. Anyways, I finally took the updates for a spin and so far, it looks like the merchants wearing stuff has been fixed as well as the music bug, which is a Godsend. I use a mod that changes interior music at night and it's nice not having to reset my slider when I step outside afterwards...

Unlikely, it only happens when two mods are in the same cell. She tried it as the only mod loaded. Local refs usually just go missing instead of crashing the game.

Just to let you know, my offer to help you narrowing it down further still stands. For example, would it help to

a) prepare an esm/esp combination with an absolute minimum number of references, which still triggers the bug
b ) another one which has only one ref number changed so it doesn't
c) a third one in which the "REFS_PERSIST" status is changed so that the bug isn't triggered?

As I said, I know that this beast would be very hard to tackle, so I'd understand if you decide that there are better options to waste one's time. However, *if* you want to tackle it, I'm offering any help I can muster.

Well, I patched the ref loading code so it doesn't do that stupid reassignment.

First try, looks like it works, but of course it needs a lot of testing since it can affect saves. The patch is in the savegame loader, it looks to be in a bit of code that repairs saves after you remove a mod, but badly implemented of course. That will need checking out.

As well as checking the bug behaviour is gone, you'll have to test the working behaviour is still working.
- Test removing mods with saved non-persistent refs in the savegame.
- Test that with another mods replacing it using the same modindex.
- Test inserting mods before it in the load order.
- Test for object doubling in containers.
- Test some more.

Going to upload it somewhere. Just a moment.

This is awesome! Just wondering, I already got doubling not from removing, but from adding a mod in the middle of the load list. Specifically, Bob´s Armory 1 had a newer modified time than Bob´s Armory 2...and when I added Bob´s Armory 2 all doors from Bob´s Armory got doubled.. even Wrye Mash could not fix this. Would the patch address this situation?

It doesn't fix doubling of any kind, it fixes missing persistent objects (NPCs, doors, lights, containers). Wrye Mash, properly used, is still the only way to fix doubling.

Test report rev 5

* Patcher programme worked without any errors;
* Morrowind launched normally;
* Even the number of crashes was the same as before!

* Features tested so far:

- Alpha blending > works; the Kheran fishtail finally shows on the paperdoll!
- Merchant fix > works; armour and expensive clothes to merchants are no longer donned by the buyer.
- Music fix > works; no glitches encountered.
- Spell points fix > appears to work; have not yet had any 100+ spells created, but spell-creating NPC's offer the option.

Thanks, Hrmchamd!

Cheers,

Swiveller

You have the heart of a beta tester. The patch is up at tesnexus. ESMs don't really conflict because the ref ids rarely match up due to their size. Use two ESPs.


And don't forget about using Wrye Mash to check the refs, like the UESP bug page says.

For enchanted value increase, is the formula straight up (soul gem value + fee + original item value)? I haven't had a chance to test this all out yet, just holding a side discussion in the PTE thread about it.

It can't include the fee because you can enchant stuff yourself. It's currently soul size (not soul gem value) * enchant points used (as a proxy for the strength of the enchant) * a constant (currently 0.5). Note that soul gem value = (soul size) * (empty soul gem value) which is ridiculous for any kind of balanced economy.

The formula you had before is the total money you invest in enchanting an item. Asked for some testers to check out the balance, but noone's reported back on that yet.

Wow! *puts all other tasks on hold and starts testing* It's just past midnight here right now, I should have some results by tomorrow morning.


Yep, my idea to use a minimal ESM was just to reduce the general amount of reference processing going on, so that it it might be easier for you to find the relevant bits in the code. It's not needed for testing (unless I find something going on which I'm incapable of understanding unless I reduce data complexity as much as possible).


Aye.

Results of the LocalRefBug Beta Patch Test:

Unfortunately, I'm not seeing a difference between regular Morrowind (RM) and beta-patched Morrowind (BP). The testing procedure was as follows:

Procedure P1:

1. I created two plugins "Plates" and "Cups". The former puts three metal plates in Foryn Gilnith's hut (which, for whatever reason, were flagged as "ref persist" in the CS), the latter puts three silverware cups (which aren't persistent) in the same cell. I hope Foryn doesn't mind that I'm abusing his home for testing purposes, but anyway, most people tend to simply kill him and use his home as a base for further operations, so I guess I'm not too bad. Anyway, if anybody wants to reproduce these tests and wants to save himself some time, here are the two plugins: Rapidshare link.

2. I used a fresh, never-modded Morrowind install which had a save of a character standing in Sellus Gravius' office, just about to step into Seyda Neen or the first time. In this installation I created two executables, one for RM and one for BP.

3. I activated the two plugins, startet RM and loaded my save.

4. walked to the front of Foryn's hut, saved "RM1". Entered the hut.

5. took the three cups

6. left the hut, saved "RM2".

7. immediately reloaded "RM2", entered hut.

8. Result: saw three cups, no plates. This is the expected behavior of the bug: The savegames contains three deletion records, one for each cup. All are correctly set for modindex 5 (cups.esp). Yet, the game engine, when reading the files, misassigns those entries to the persistent plates instead and deletes those.

I then repeated steps 3-7 with the BP exe. Results were identical.

While testing, I found out a couple of other things which may or may not be helpful:

- The statement on the UESP page, that doors are automatically persistent, does not appear to be correct. At first I used doors instead of plates, and wondered for two hours why I couldn't even reproduce the well-known bug behavior. Turned out that the doors weren't persistent.

- Oddly, for RM as well as BP, the bug vanishes when savegame xx2 (i.e., RM2 or BP2) is loaded from a cell where the plates are present. To reproduce:

Procedure P2:
1. Start Morrowind
2. load savegame xx1
3. enter the hut
4. load savegame xx2 from there
5. enter the hut
6. Result: you see three plates, no cups - *no* local ref bug

I don't think that this is a fix though, I rather suspect that this is another bug kicking in, i.e. information from the current cell leaking into a new savegame. I do remember reports of such a bug, but don't know whether it has been properly defined yet. In any case it seems to be important to save and load from *outside* the testing cell, otherwise we may get artifacts due to this other bug kicking in.

- However, what's *really* odd: once I perform procedure P2 mentioned above, I cannot get the bug to happen again. To reproduce:

Procedure P3:
1. Perform P2 as described above
2. leave the hut
3. load savegame xx1
4. Perform steps 4-7 from P1
5. Result: you see three plates, no cups - *no* local ref bug

This is rather odd, and I'd appreciate it if someone could confirm this.

Hrnchamd: I haven't checked for unwanted side-effects of the beta patch, since the desired effect does not work yet. If you think that checking for unwanted side-effects will help, then just say so, and I'll do some tests in that direction.

Currently I'm trying to make the testing procedure secure from side-effects caused by other bugs. Presently, I'd recommend to never load or save inside the test cell and to restart Morrowind for each new test.

Alright, where I patched was the cell loading function where it loads a reference (REFR), deletion records (DELE) are handled a bit further up, I'll have to find it. Try testing by moving the non-persistant items around a little instead while I check it out.

Doors seem to become persistent when a script is assigned to them.

When you reload from the same cell the code just jumps over all the ref fixing parts, no idea why but it's definately what you're seeing. You just have to load from outside the testing cell since the odd behaviour is in the loader. Saving can be ruled out. It's definately a data leak of some kind, it goes back to buggy behaviour when I leave the cell.

Moving them im-game isn't possible (I think), they can only be picked up and dropped. This, however, still deletes the original reference and creates a copy of it with modindex 0 (and an objectindex depending on some ref count in the savegame).

I'll replace the cups with something that can generate a different savegame entry than just "delete". It might also be worthwile to see whether can make another *mod* which changes these references, and then see how the engine deals with this. Hmm. *goes back to workshop*

Hmm. Replaced the cups with the non-persistent doors I couldn't use earlier (replaced Cups.esp with Doorslocked.esp). Made the doors locked. In-game, I unlocked them, then left the hut, and saved.

Inspection of the savegame: As expected, all three doors wrote information about their changed lock status to the savegame. Mod- and object indices are correct and point to the doors in the Doorlocked.esp. These are FRMR records though, I'm not sure whether this was what you're working on? (You said something about REFR records, but the only context in which I heard about REFR in savegames is as "Plaer reference data", i.e. attributelevels and such - not related to the local ref bug, but my knowledge of the file formats is scarce, so I may be wrong.)

Results as of yet are still negative; the patched exe still removed the plates when I re-entered the hut.

I'll run some further tests. If anything would be particularly helpful, just name it.

The reference IDs are stored in FRMRs, and possibly MVRFs, yes. Looks like we have to check and patch every subrecord type, sigh. I got it working using a NPC and a container, just stole something out the container and saved. Went outside and reload -> bug, and the patch fixes that at least. Could you check that?

YES! With NPCs and containers, the patch is working. Regular Morrowind removes the NPCs (and restores the content of the containers). The beta patch lets the NPCs live and correctly removes the content of the chests.

I'll check some other combinations now ...

Found another place in the code where it does stupid things very well. Get the new localref patch from tesnexus, hopefully it fixes every other local ref bug, haha. Thanks for the ESMs you posted, they were nice for testing.

Downloaded new beta patch, tested - works! Tested it on NPCs, the plates, a persistent weapon and a persistent door. All vanished with unpatched Morrowind (and the respective non-persistent objects reappeared), and in all instances this bug was fixed by the patch.

Also tried it on a persistent door with a script that disables itself. With regular Morrowind: bug, with beta-patched exe: no bug.

Also tested a scripted door which was flagged as non-persistent in the CS (blocked door to Abuwhatever), this didn't trigger the bug.So the assessment that scripted doors automatically become persistent appears to be incorrect, perhaps a special type of script is needed.

Sooo ... now that the patch exhibits the desired behavior, we'll have to check for unwanted side-effects. This will probably take a while, and I have to leave for an hour or two (and may need to actually get some sleep afterwards), so my next report may take until tomorrow. But I'll keep testing.

HOLY... OO'

He... he... fixed the local ref bug?!

...Oh dear. Oh DEAR. I think I'm going to faint approximatelyRIGHTNOW.

I wouldn't call it fixed just yet - we'll have to test for unwanted side effects first. There's a long list of things to go through, and since we don't want this patch to screw up people's savegames, we'll have to be extra careful.

Looks promising though - so feel free to faint nevertheless - but just keep in mind that there's still work to do on this beast, and there's still a possibility for setbacks.

Tell me how to test for side effects and I'll do it.

I´ll certainly use this.

Download the local ref beta patch from TESNexus and apply it. Before you do, make a copy of your Morrowind.exe so that you can start the game with or without the patch applied, by choosing the appropriate exe.

Simply loading savegames and checking for errors should already help. Especially in conjunction with removing (or adding) mods - see post #95 in this thread.Load savegames with the patched exe and with the unpatched exe and check whether the patched exe might have broken something that the unpatched exe didn't break. Report your findings.

Will do. ^^

EDIT: I can test the adding mods, but not the removing.. currently, at least. Hard to explain, but.. just be aware that you might still need to do some things. Also, I don't know diddly about persistent/non-persistent refs. I assume if I add enough stuff before something in the order I WILL break something. What exactly it is I break may vary. (Also, 520 mods is an awful lot, and I only have like 15 installed so far. If I save that game now... >>) ..Just warning you so you know I may not test everything.

EDIT2: On second thought I'll never get around to it at this rate. I broke an ESP and stuff like sleeping needs to happen... xx' Sorry.

I'm back home. Malnutrition danger sufficiently reduced for the next couple of days. Decided not to sleep and run some more tests instead. Sleeping is overrated.

Testing the effects of mod removal now.

Load order: Morrowind - Tribunal - Bloodmoon - Cups (non-persistent) - Plates (persistent)

Procedure P1:
1. Started regular Morrowind (RM)
2. loaded character from my unmodded savegame
3. entered Foryn's hut, took the three cups, left hut, saved RM1
4. quit game
5. removed Plates.esp
6. restarted RM, loaded RM1
7. entered hut. No plates and no cups to be seen. Not necessarily a sign of the bug, since the plates.esp has been removed - there's no good reason for the plates to show up.
8. left hut
9. saved RM2

Procedure P2:
Afterwards, I repeated the steps 6-9 of P1 for the beta-patched exe (BP).

Results: The second savegames of both versions (i.e. saves RM2 and BP2) show both 3 delete records for the three cups. Modindex is correctly set to 4. No traces of the plates in the savegame. Conclusion: No difference between RM and BP when a trailing esp with persistent refeences is removed.

Next, let's see whether removing the Cups.esp works as well. It probably won't since the Cups.esp is not at the end of the modlist, so there's a higher chance of misassignments.

Load order (as before): Morrowind - Tribunal - Bloodmoon - Cups (non-persistent) - Plates (persistent)

Procedure P3:
1. Started regular Morrowind (RM)
2. loaded character from my unmodded savegame
3. entered Foryn's hut, took the three cups, left hut, saved RM1
4. quit game
5. removed Cups.esp
6. restarted RM, loaded RM1
7. entered hut. No plates and no cups to be seen, although the Plates.esp is still active, so they *should* be visible. This is either the local ref bug kicking on, or a failure of the game engine to recognize that the modindex of plates.esp has changed from 5 to 4. (Savegame analysis is needed to clear that up).
8. left hut
9. saved RM2

Procedure P4:
Afterwards, I repeated the steps 6-9 of P3 for the beta-patched exe (BP). This time, in step 7, the three plates were there.

Results: Savegame analysis shows that savegame RM2 has 3 delete records for objects of mod 4. This is a bug because mod 4 (Cups.esp) has been removed. Regular Morrowind failed to recognize this, although it *could* have seen that the delete records weren't meant for the plates: the NAME subrecord still shows the names of the cups. However, these delete records also contain an XSCL (scaling) subrecord that they inherited from the plates (I had scaled the plates down, but not the cups). Hence, these delete records in the savegame share subrecords from the cups (NAME) and the plates (XSCL). Which is pretty weird, but can be a result of the local ref bug.

Savegame BP2 (the one saved with the beta-patched exe) has three delete records for cups. No XSCL records are present, presumably because the local ref bug hasn't kicked in to mix up subrecords. Interesting: The modindex of all three records is 0, the objectindices are 34, 35, 36. This is something new. Usually, delete records point to a reference in another mod which should be removed. Here, the FRMR is not a pointer to an existing object, but denotes an object that is created by the savegame ... and (because of the delete subrecord) immediately gets deleted.

This needs further study. Such "self-deleting" records *could* cause several problems:
a) The engine could try to create and delete the object at the same time, which may have a risk for misassignments, memory corruption and/or crashes
b ) These records will probably never go away, since the engine does not clean delete records (even if it did, it's unclear whether it would recognize a self-deleting reference as such). So they could bloat a savegame.

Edit: Apparently I was partly mistaken. The self-deleting records *do* go away. All that's required to make them go away is to reload and save the game. In the new save, the self-deleting records will be gone. I suspect that the game actually creates and then deletes the object, and then forgets about it (like a quaffed potion, for example), so that it doesn't get written to the savegame again. It seems that while looking for potentially negative side-effects, I might have found a beneficial one. In regular Morrowind, the delete records for the cups/plateswill stay in the savegame forever, or until they get cleaned out with Wrye Mash, because the game thinks it needs them to remove some objects that have been changed. With the beta-patch, no delete records remain.

It was the local ref bug that caused that door to The Underground from the mod The Underground (2) to disappear right?

I don't know if this has been answered yet, but companion NPCs properly equip new clothing and armor if it's better than what they're wearing.

It's the same behaviour as SetDelete 1, it doesn't get saved on the next save. I'm glad it renumbers the refs though.


Yep.


Aye, I definately restricted the change to the 'on successful barter' function. Thanks for checking.

Wow! That's amazing, you fixed one of the most major bugs ever...

I'll definitely keep an eye out on this modified code/edit/patch thing, keep this up and Bethesda might hire you!

I also apologize for my previous dunderheadedness. That's sorta a word....

Just want to poke people to test the other features too, they need love.

About the local ref patch. Please test mods that replace items in the original game / other mods. I had some issue with dej's plain paper fix saying object not found, but the author didn't use the CS to change the objects, but used a global replace tool (from the readme) which isn't exactly kosher. I'm concerned about other mods that do replace items of course.

I applied r5. The NPC Health bar is always on in my game, even when I am not looking at an NPC. When I enter dialog with an NPC, the Health bar disappears after a few seconds and then returns when I exit dialog. That's the bad news. The good news is that I really love the barter fix. It works well.

Further testing shows that the problem happens when I have an MCA 5.2 companion. Without one it appears to work correctly.

More testing has the NPC Health bar sticking on after I alter the inventory of a non-MCA companion.

After a short period of involuntary unconciousness (i.e. fell asleep on my keyboard - hrmph ...), testing continues.

Next batch: Removing the mod with the non-persistent refs and replacing it with another.

Load order: Mw -> Trib -> Bloodmoon -> Cups -> Plates

Procedure:
1. Went to hut, took the cups, left hut, saved
2. replaced Cups.esp with Chests.esp (i.e. new mod on modindex 4, Plates.esp remains on modindex 5)
3. loaded save, entered hut, checked
4. left hut, saved, analyzed savegame

Results:
With regular Morrowind, the plates were gone in step (3). Savegame analysis revealed that the game had again mixed up subrecords (names from Cups.esp with XSCL from Plates.esp) in three deletion records. The FRMR of these deletion records now pointed to modindex 5 (plates), which is a clear bug.

With the beta-patched exe, the plates were there in step (3). Savegame analysis yielded three self-deletion records (pointing at modindex 0), as in previous tests of this exe. The plates remain unaffected. There are also no side-effects towards the chests added by the mod which replaced the cups.

Conclusion: Again, the behavior of the beta-patched exe is much more sound and safe than that of regular Morrowind.

This isn't looking too bad. I'll continue testing.

Psyringe, can you give an estimate on just how safe the patch is to use, based on what you've tested so far, assuming everything else is a horrifyingly broken pit of despair?

Next batch: Inserting a mod

Load order: Mw -> Trib -> Bloodmoon -> Cups -> Plates

Procedure:
1. Went to hut, took the cups, left hut, saved
2. inserted Chests.esp between Cups.esp and Plates.esp
3. loaded save, entered hut, checked
4. left hut, saved, analyzed savegame

Results:
With regular Morrowind, the plates were gone in step (3), and the cups had reappeared. This is the local ref bug in action. Savegame analysis revealed that the game had again mixed up subrecords (names from Cups.esp with XSCL from Plates.esp) in three deletion records. The FRMR of these deletion records now pointed to modindex 6 (the plates). The chests are unaffected.

With the beta-patched exe, the plates were there in step (3), and the cups were correctly gone. Savegame analysis yielded three deletion records which pointed at modindex 4 (Cups.esp), which is correct. No side-effects towards the chests.

Conclusion: Again, the behavior of the beta-patched exe is much more sound and safe than that of regular Morrowind.


I then repeated the test with one condition changed: I inserted Chests.esp before (not after) Cups.esp in the load order. This introduces additional difficulty for the engine, because now the esp with the changed references has moved.

Results with RM (regular Morrowind) were identical: Plates gone (with subrecord mixup), cups reappeared, chests unaffected.

With BP (beta-patched exe), things have changed now. The plates are unaffected, but the cups have reappeared, and the *chests* are gone. The deletion records point to modindex 4 (now Chests.esp), although the names contained in the records are still those of the cups. What's happening here is that the game engine reads the deletion entries for the cups (which were on modindex 4 when the game was saved) from the savegame. It then tries to delete the references 1-3 in mod 4, which is successful, because mod 4 (now Chests) has references with the objectindices 1-3. The engine works only by mod- and objectindex. it does not check the NAME subrecord and hence doesn't realize that it was actually meant to delete cups, not chests.

So, in this setup, RM exhibits the local ref bug, while BP avoids the local ref bug and then falls right into the fangs of another bug (mod mismatch on changed load order). That's not ideal, but at least it isn't worse than RM's behavior. Actually, RM exhibits the same behavior as BP when I also remove Plates.esp in stage (2). Then there are no persistent references that RM can misassign the deletion records to, and hence it misassigns them to the chests, not realizing that the load order has changed.

Conclusion: Still looking good for the beta-patched exe. It might be worthwile checking why the engine fails to recognize the changed load order, perhaps this can be fixed too, because this reassignment *does* work for esm files. Wrye was wondering about that when he wrote Doubling Explained:



It might also be a can of worms best not opened - your call.

So far, the local ref patched has performed admirably well in my patches. It appears to have fixed the local ref misassignment, and so far I've only found it running into problems in situations where the unpatched game ran into problems too.

However, we're not through yet. There are areas we haven't even touched yet in our tests, and we can't exclude the possibility that something ugly will show up when we do.

To answer your question, I'd use the patch already if you know that you have local ref conflict related problems in your mod setup, and if you could live with having to roll back to a previous save *if* we find some problems with it. Otherwise, it will currently be safer to play without the beta patch, diligently use Wrye Mash to clean the misassigned references that this patch would prevent, and wait until the patch is out of beta.

Edit: Assessment changed, see problems mentioned in post 130. I'd recommend to wait until this gets resolved.

What would happen if you did a Mash repair all before reloading MW?

sieboldii

In which kind of situation specifically?

Generally, Mash's Repair All should never hurt. It will fix many of the broken records that the local ref conflict will produce. However, in many situations it cannot *prevent* them. There are situations in which Morrwind will simply break the references again as soon as it is started, and then you're playing with the broken references ... you can only remove them from your savegame afterwards, only to have the engine break them again as soon as you re-enter the cell in question. This patch might be a solution for such situations where Mash cannot do much (or where you'd need a *lot* of work to prevent local ref conflicts, as in systematically renumbering references in all your mods).

Suggested reading: Ieldra's guide.

Next batch of testing: real-world conditions

Since the beta-patch behaved well under laboratory conditions, I decided to take it out to the real world. Specifically, I let it loose on a humongous 300+ mod installation of mine, with a 22 MB savegame which takes 15 minutes to load and initialize.

I've encountered several problems:

First, there was an increased number of "object reference xxx not found in master" messages, during mod loading as well as during cell transitions. Some of these references appeared to be still there in the game though, but that will need further testing. I suspect that the problem may be connected to multiple replacements of the same reference, but again, this needs further testing. Also, it was noticeable that some mods seemed to throw many of these errors, while others didn't.

Edit: It is definitely related to multiple replacements. I took four plugins that threw a lot of errors in this setup, and loaded into an otherwise unmodded setup. There wasn't any error at all.

Second, there were 4 instances of Sharn gro-Muzgob in the Balmora mages guild. I checked that out because one of the "ref not found" message was related to her. It came from the unofficial patch 1.6.3 btw.

Third, there are a couple of places in this game where I know that objects are missing due to reference conflicts. When I checked those, some of these (like a house in Seyda Neen) now appeared (which is good), others (doors in Pelagiad and Ald'Ruhn) didn't. This needs further testing too; it also may be related to the savegame, so I'll have to redo this test with a new character.

So, since the first real-world exposure yielded problems, the obvious next task is to try to isolate these problems and make them reproducible. *jumps back into workshop*

Edit2: Okay, I've narrowed it down a bit. Here are three examples of this bug:

1. Sharn gra-Muzgob (Balmora Mages Guild)

I activated the following mods (listed according to load order), all of which change Sharn:
- Assassins Armory.esm
- Morrowind Patch 1.6.3.esm
- Complete Trade Fix.esp

When I start the game, and it loads the Morrowind patch esm, I receive a message that Sharn's reference is missing in the master file.

In-game, I see two versions of Sharn. One is from Assassins Armory, the other from the Complete Trade Fix. No version from the Morrowind Patch is present.

2. Marayn Dren (Balmora Mages Guild)

The following plugins affect him:
- Morrowind Patch 1.6.3.esm
- Clean Inscription 2.0.esp

When I start the game, and it loads Clean Inscription 2.0.esp, I receive a message that Marayn's reference is missing in the Master file.

In-game, I see two versions of Marayn. One is from the Morrowind Patch, the other is from Clean Inscription.

3. Galbedir's Grand Soul Gem (Balmora Mages Guild)

The following plugins affect it:
- MW-CultofClouds10.esp
- Byb-300-Traders.esp

When I start the game, I receive no messages regarding the soul gem. When I enter the Balmora mages guild, I receive a message that the reference of the grand soul gem from Byb-300-Traders.esp is missing in its master. (The reason that I get this message upon entering the cell, and not during program initialization, is probably that Sharn and Marayn are NPCs and therefore persistent, while the soul gem is not.)

In-game, I see the soul gem from MW-Cultofclouds10.esp. When I pick it up, then I see the soulgem from Byb-300-Traders.esp in the same spot, so it has doubled. (Edit: This doubling is independent of the beta patch, it also happens in regular Morrowind). There is no other copy of that soulgem on the desk.

I'll tinker around with it some more. Tell me if you have any suggestions about what to try or look for. I'll update this post with my progress.


Edit3: Tested the same setup as described above, but with the *previous* version of the local ref beta patch (the one that only worked on NPCS). Results were identical for NPCs. I didn't get a message regarding a missing reference for the soul gem.

Also tested the same setup with the regular Morrowind exe. There was only one Sharn (the one from Complete Trade Fix.esp), only one Marayn (the one from Clean Inscription 2.0.esp), and both soulgems (so that's a problem of the plugins involved, not of the beta patch).

Clearly this is the code that deals with 'last to load wins' behaviour. It compares items by objectIndex only. The question is, what is the intended proper behaviour? Mods that override the same object in a master should go last one wins. Mods that add items to a cell shouldn't override each other. Mods that delete items do what?

I'm going to try and hack it to override on matching objectIndex + source modIndex, and skip testing if the object belongs to the mod (modIndex == 0).

Okay - in the meantime, I'll try to create a proper testbed.

Okay - here's a testbed. Kind of. Might turn out to be a bed of nails for anybody but its creator - it's not very clearly laid out, sorry. I should've startet on a clean slate instead of just moving various existing objects around, but realized this too late.

Anyway, here are the files: Rapidshare Link

The test takes place in Seyda Neen, in the house of Teruise Girvayne. Why should Foryn have all the fun? Anyway, her house is the one left of Arrille's on the main plaza.

The plugins in the zipfile (which should all be activate) all move around or delete reference in this house, in various combinations and with various dependencies. Here's the data as it is presented to the game engine:

- The pillow gets moved a bit to the west (W) by Move3.esp

- The bottle on the crate near the bed gets moved W by Move3.esp, then a bit further W (to the edge of the crate) by Move2.esp.

- The cup on the crate near the bed gets moved W by Move3.esp, then a bit further W (to the edge of the crate) by Move2.esp, then into the room (floating) by Move1.esp

Move1.esp. Move2.esp and Move3.esp only depend on the three main esms of the game, so here we have three plugins which (partly) change the same reference of the master.

Now to the table:

- The candlestick gets moved W by move5m.esm.

- The large bread gets moved W by move5m.esm, then moved further W by MoveBreadM.esm

- The bowl, like the bread, gets moved W by move5m.esm, then moved further W by MoveBowl.esp. The difference is the second move is done by an esp which is dependent on move5m.esm

- The plates get moved W by move5m.esm, then N (into the room) by MovePlates.esp. The difference to the bowl is that MovePlates.esp is *not* dependent on move5m.esm

- The eastern plate also gets moved further S (into the room) by MovePlate2.esp.

- Two pieces of Comberry and a sheet of paper get deleted by DeleteLeavesM.esm

- One of them gets moved afterwards by MoveLeafM.esm

- The bottles get deleted by DeleteBottles.esp (this is an esp deleting stuff as opposed to an esm in the example with the comberries)

- One bottle gets moved afterwards by MoveBottle.esp

Compare this room when running regular Morrowind and when running the beta local ref patch, and you'll immediately see the differences. Regular Moorowind only applies the first change to each object and ignores the rest (*). The beta-patched exe copies references over and creates many duplicates of objects; it also complains (when entering the room) about missing references.

This testbed might be too convoluted to be useful for other people; if you think that it will help, I can recreate it in a clearer layout.


(*) Actually, this is not what I expected, and it's not what usually happens when several esps change the same reference in the esm. Note that regular Morrowind moves all three objects (pillow, bottle, cup) to the position specified in Move3.esp, the first esp that that moves them. The following two esps *do* get processed, and "ori" on the bottle and the cup gives the name of the last esp that tried to move them. However, all moves after Move3.esp are discarded, meaning that the cup stands in the position where Move3.esp placed it, although "ori" says that its data originates from Move1.esp. This oddity might make the testbed less useful, so I'll have to investigate this.I'll try whether changing something else than spatial position changes the engine's behavior.

It seems to me like the beta-patch tries its damnedest to make ALL of the files valid. It tries to make sure absolutely no file has a hiccup.

And it does an exceedingly [censored] job of it. (Excuse the foul language but there really isn't another way to put it.)

It seems like every item which has something changed in the beta-patch has instead a new reference CREATED for absolutely no reason whatsoever, and if you opened the save in Enchanted Editor, I'm sure you'd have 3-5 times as many references as you should.

No, the save won't have any of these references, because the player hasn't changed them. Hence there's no need to record anything in the save.

Also, "no reason whatsoever" doesn't actually apply to computer programs. There's always a reason. You "just" have to find it, then you can fix it. Which isn't exactly easy when you're working on compiled code ... but that's why I'm trying to create a testbed, to (hopefully) make it easier for the code wizard.

I'm pretty sure this is the equivalent of the local ref bug for ESMs, overwriting modIndex onto the wrong item instead of making a new ref with the right properties and deleting the old one. Actually, Wrye does mention this on the UESP wiki.


Not really about valid or not.. it's about changing the behaviour of references that replace other references. The patch turns off searching ESPs with a different modIndex for the ref to replace. In a savegame, the original modIndex is saved already and no searching is really required. Looks like I broke the ESP loader doing that though, so I narrowed the function of different parts of the loader.

I've uploaded another localref patch where the ESP reference loader is back to normal and only the savegame loader is changed.

This looks like a great project. I hope you will try to address the shield spell bug. I'd like to point out in the case that you didn't know, that for the elemental shields there is no workaround like there is for the regular shield spell.

Yep, I remembered that when I saw the results of my testbed, I never *quite* grasped that part until now.


Tested the new version - works. The local ref bug in the Cups&Plates&Stuff testbed is still squashed. In the "move objects around" testbed in Terurise's house, there's now no difference between the behavior of regular Morrowind and the behavior of the beta.patched exe.

This will fix the local ef bug for savegames; it won't fix those instances where doors or NPCs disappear without a savegame in between though. Hmmm ... *thinks about a testbed*

I'll have a try at the ESP replacement order issue while you think about it. Also looking at how Morrowind renumbers ESMs.

Wow - sounds great.

Btw, I ran some further tests an the new beta patch. Specifically, I repeated the test where I removed the Cups.esp from the game so that the engine had to delete the records of the cups. I also took a plate before removing the Cups.esp, so that the savegame had a "delete object 3 in mod 5" command that had to be reassigned to modindex 4. I thought it might be good to test this since you said you turned the modindex search off for savegames. It still works correctly, the record for the plate was reassigned to modindex 4.

Regarding the issue with "first change wins, all others get ignored" that I was seeing with the objects I moved around: The odd thing is that this seems to be limited to references in CELL. It doesn't matter which subrecords I change; as long as I'm only changing records in CELL, the rule is "first change wins". It's different for other areas, for example NPCs. I made three mods which each changed an NPC's race into something different, and the *last* change won in this case. I'll poke around with that some more when I have the time.

I have to take that back. It's not the record type that determines whether "first change wins" or "last change wins". It is - surprise - the "references persist" flag.

Here is a zipfile with 3 small plugins: Rapidshare Link. Activate them and have a look.

RefPersTest1.esm creates two new scrolls and places them in Arrille's tradehouse, on the ground. One of them is persistent, the other is not.

RefPersTest2.esp lifts these scrolls in the air.

RefPersTest3.esp leaves them on the ground, but scales them to double size instead.

What you'll see is this:
- The *persistent* scroll will lie on the ground, scaled to double size. For the persistent scroll, the info from the last esp won, it overwrote the info from the first loaded esp.
- The *non-persistent* scroll wll float in the air, unscaled. For the non-persistent scroll, the info from the first esp won, the info from the following esp ws ignored. Oddly, the "ori" of the scroll will nevertheless claim that its information came from RefPersTest3.esp.although this information got ignored.

For convenience, the text on both scrolls explains the difference.

So, it seems that the "references persist" flag governs whether the first or last change wins - not the record type, as I thought previously (it just so happens that NPCs are always persistent, and items in cells mostly aren't, hence my first tests led me to believe that the record type would make the difference).

The behavior of the non-persistent scroll may be seen as a bug, since its "ori" gives incorrect information.

Unfortunate news about the new beta patch - it's still throwing "reference not found in master" errors on my humongous "real-life" installation. It didn't do this in my testbed. I suspect that you stopped the errors for non-persistent references, but not for persistent ones. My testbed only has non-persistent references so far, and the bugs that appeared in the huge game were mainly related to NPCs, which are persistent (4 copies of Sharn gra-Muzgob etc.).

On further notice, I had a bit of time to test the other patched functions. Higher spell maximum works fine. Merchants didn't equip the stuff I sold them, and they weren't naked. One oddity was that I always had a yellow bar (for companion health?) in my display. I do have 3 companions, but these aren't even in the same cell.

Question: would installing these patches affect mods being made in any way? I'm working on a fairly big mod and I don't want it to break on somebody's computer that doesn't have the patch. I don't see how it would, but I would rather be safe than sorry.

Let's have some time for the recent questions:


Please explain the bug fully, I don't know about it.


It won't affect any mod making programs or savegames.

Finally, I've found all the places where mods get renumbered. It looks like it should work properly, it does filename matching, but of course there's a bug somewhere.

Cool. I'll install the beta five release then and not worry a 1a80 bout it.


It will deffinantly help if you can get that fixed. Hopefully that can prevent the ref conflicts we've been having.

Normally, casting a shield spell should add to you AR the magnitude of the spell, but this doesn't happen unless first you add/remove a piece of armor or clothing. Someone mentioned it in the first thread.

Now, with fire/frost/lightning shield, it doesn't add to your AR at all, even when you add/remove armor or clothing.

Just bursting in randomly, with a bug in the game that I'd forgotten about, but just remembered now. I have no idea if this is possible/falls within the remit of this project, but here's the relevant thread from a while back. It's to do with a 'hardcoded' CTD bug when you name certain exterior cells.

Sorry for wild OTness, and general irrelevance.

I am sure the shield thing is a display bug. You don't even have to equip anything, just pick up some unequipped armour from your inventory and the AR updates itself. I will check the elemental shields though.


Interesting but it will have to wait a while before I look at it.

To me, it's pretty clear that the developers had no clear idea of what Elemental Shields should do. While the spell descriptions portrait their effects as "Shield + Resist Elements", in-game they add elemental resistance and damage the incoming attackers with the chosen damage-type. To make the confusion even worse, the damaging effect is set so low that it is barely noticable during normal gameplay (though this can be corrected through a simple GMST change).

Personally, I think that having those spells damage near enemies is much more interesting than an armor rise, and I would actually prefer them to stay as they are (though the spell descriptions would have to be corrected). Maybe that's just me .

Always thought they added elemental resistances instead of armour... um ... submit it to UUMMPP? (for fixing the description)

Gah! There's an annoying issue with multiple replacements of objects. The first replacing mod overwrites the ref's mod ID, and the next replacer "can't find the reference from the master file" because it's been eaten by the first mod. At the time it hasn't even read to the ref name yet so it can't check that. There has to be a better solution than overwriting the first thing you see like vanilla Morrowind does.

Would be because of that the "merge objects" function is needed? Like, if two mods modifies the same object, it adds (in theory) all modifications to the same object? (sorry if this makes no sense... Im trying to follow all the ref discussion with some difficulty)

You're right. At the moment it either replaces the original object, or replaces the last thing with the same objectID (bug central), no merging capability at all. It's essentially too hard to add merging stuff, so I have to find the best path through the mess.

Hmm I suppose the problem isnt the merge algorithm itself (testool probably would give some directions on how to do it) but how to "merge" it with morrowind´s code that hadn´t been thought that way?

As said a bit further above, I think that the third version of the beta patch fixed that for non-persistent objects, otherwise the buggy behavior should have shown up in my testbed with the moved around bottles / plates / etc, which are all non-persistent. But the third beta fixed that. The fix just doesn't seem to apply to persistent objects at the moment.

I'll do some testing to check whether this assessment is correct.

Edit: Thinking further about it, I don't think it's correct because in the RefPersistTest with the two plates I made, I already had a persistent reference ... and I didn't get any doublings or error. Likewise, I could change the rsce of an NPC in multiple mods without causing an "reference missing in master" error.

There must be some differences which determine whether or not the bug will occur. Back to further testing ...

Edit2: Okay, the third beta has a problem with multiple changes to a persistent reference in a master. I tried this with the two scrolls I put in Arrille's (see posts further above). This testbed has a persistent scroll (added by an esm file) that then gets moved by one esp, and scaled instead by another esp. With regular Morrowind, the engine correctly removes the original scroll and places the moved scroll, then correctly removes this moved scroll and places the scaled scroll. With the third beta-patch however, the enigine leaves the original scroll in place when creating the moved copy of it. It then removes this copy when creating the scaled version of the scroll though.

I still haven't managed to reproduce the "reference xxx not found in master" bug under controlled settings with the third beta patch. Working on it ...

According to Wrye, the engine already does correct renumbering for esms, but not for esps (see link and quote at the bottom of post #126). Perhaps that's what you're seeing?

First, what is UUMMPP?

And the CS description says "This effect creates a shield of elemental fire/frost/shock around the subject's entire body. The spell adds its magnitude to the subject's Armor Rating, and also greatly reduces damage from fire/frost/shock attacks." Though it makes no mention of the nearly unnoticeable damage the shield does, which is made wore because you can't see the enemies health bar while they take damage from the shield. Maybe you can make it visible?

After some testing, it seems that the shield spells do increase AR, but only the non-elemental shield spell will show the AR increase on your inventory screen. I always thought that shield protected me a bit but I didn't notice it much as I don't use it often and when I did it was usually a low magnitude spell. But once I saw that it didn't update my AR I thought it wasn't working correctly. So when I tested I used 50 and 100 point shield and elemental shield spells, I did notice quite a difference. By the way, just how much elemental protection does an elemental shield provide?

So I guess the only bugs are the display problems. But maybe they can be fixed. Another note is that the shield spell updated my AR sometimes when not fully armored. And since we are on the subject, what about unarmored increasing even if you are fully armored?

And one more note, one test character I used was an Argonian male with the head and hair 01. The hair has that reddish glow on the paper doll seen with Truflame/Hopesfire. Maybe this is seen in other faces/hairs and could be fixed.

Morrowind renumbers refs as soon as it reads the FRMR (modIndex+objectIndex). It can't match the whole record because it hasn't been read yet, and anyway it's not always wise to match by object name, it breaks item replacers.


Yep, I think that merging multiple changes issue is why the local ref bug exists, they wrote in a 'overwrite anything with the same ID' policy to cover the merging. I'm going to try and get it to save the mod ID of the object being overriden and check that instead.


Deleting a mod always works, as far as I've checked. Inserting a ESM or ESP doesn't update the indices, instead it gets rematched by the searching code. ESMs only work properly because high ID numbers mean there are no ID collisions.


First, thanks for testing the patch. Unarmored increases because you take 10% of hits to the shield slot, even if you are otherwise wearing full armour. I will need screenshots of your character portrait, you need to tell me which model and textures you are using. I made the background of the portrait solid black to avoid any issue with the red colour leaking, wonder why it's there. Try sending a screenshot of Trueflame too. UUMMPP is the unofficial-Unofficial Morrowind Patch update by quorn, a few threads down.

Take a look at the next localref beta. I've changed the loader to record the full index of the ref it replaces, so mods can replace refs from other mods if the target to replace matches too. It should eliminate any master file not found issues, please run all your tests on this one, as far as I can tell it fixes the local ref issue and the ESP version of local ref. I've changed the ori command to print in hex so you can see the modIndex byte more easily. Note that physidx should now show the modIndex of the original item (before any replacers).

Fixed remapping mod numbers when adding or removing mods, all the correct code was in place, except one messed up part which happened to be the bit that changes the old number to the new number. It's a separate fix that will be rolled into r6. You should be able to add and remove mods without Wrye Mash as long as the filenames stay the same.

Bethesda is great, don't get me wrong. But the g00n who put this together ... you should fight him.

With code. Yeah, that's right.
A code duel.

...You'd probably win.

Hmm, there's a guisarme on display in the hall, I've always wanted to poke someone with that.

I wonder if Psyringe is sleeping, it's testing time again.

Did ffdshow fix the audio issue for you, Dirges?

Not sleeping yet, just tinkering in my workshop ... will be finished soon though, and then I'll start testing at once. I'll update this post with the result of my tinkering then.

Well I might need to tweak a bit more, didn't look too closely at the other cell loading function and put the wrong variable in there.

Okay, shall I wait then with the testing until the next release?

Here's the thing I was tinkering with during the morning: Rapidshare link. It's not finished yet (obviously), but it should be apparent what and how it's meant to be. Have a look at it in a spare minute and tell me what you think.

Edit: Some directions might be helpful ... after plugging it in, check the place in front of the Sellus Gravius' office in Seyda Neen for a trapdoor.

Edit2: Couldn't resist and did some testing with the fourth iteration of the beta-patch. It's definitely doing something right with the persistent refs now; I'm seeing no missing ref errors or doubling on NPCs or other persistent objects. Also, in my "humongous installation" testing condition, I now see all the previously missing doors. One odd thing: From two instances of two esps trying to change the same persistent ref from a master, I'm seeing the first esp win on one instance, and the second win in the other instance. I'll keep an eye on that.

What's broken again is the handling of non-persistent refs (which appeared to have been fixed by the third iteration of the patch). These now throw missing ref errors and show doubling in my testbed.

I'm seriously impressed you have managed to at least mitigate this issue. It may be that the actual conceptual model is too flawed to allow foolproof further correction mind. Remember that Beth revisited this in a major way for Oblivion.

Can I ask that you glance at the code for Nif composition (that which does reside in the exe)? The pressing issue for me is Gloss maps. These are one of the additional textures on the NiTexturingproperty nodes and are part of the Nif 4.0.0.2 spec and documentation. They control the scope of NiTextureEffect nodes, such as the shrink wrap enchanted item effect.

I've verified the game engine WILL read such a texture, but then ignore it. I see one or both of two things may be happening.
The game engine culls the texture as 'useless'
The game engine imposes it's own, 100% white Gloss texture to support it's own NiTextureEffect nodes. Such a Gloss texture is unsubtle, to say the least.

The ability to use gloss maps would give a massive appearance boosts to Morrowind! Better yet, meshes designed to support this feature would be backwards compatible. (The extra details being ignored).

I thought that was the case for unarmored.

And sorry, I haven't actually tested yet, those are just things I noticed and thought I would post as I noticed you said something about the paper doll background. I plan on trying it out at least, though I don't know how well I'd be as a beta tester.

I see you're working on a refs patch Nice.

How goes the map work? I have no idea if it'll help, but what FPS Optimiser 2.0 did is turn everything grayscale so the engine didn't complain about the memory assigned to the map.

How's the fix for the recalcitrant NPC Health bar doing? I assume you won't be working on it until you finish with the local ref problem. Correct?

It turns things grey because it throws away the old map information when it redraws everything, it doesn't keep the map texture the game renders.


I guess I'll add more checks to make sure the restore health spell is cast by the player. Will try and get it out late tomorrow.

The local ref thing just seems to uncover bugs with every change, it will take a while.

Your efforts are much appreciated. Keep up the good work. The fixing the ref bug will solve many a headache with Morrowind.

DR

Hey, how about fixing some of the broken scripting functions?

From MWSFD:



*This one could be so incredibly useful...





Also, on that note, what about the bug that makes it so that NPC's don't move their arms when you use PlayGroup or LoopGroup to play an animation?

Four questions which came up while fiddling around with the showcase mod:

1. How can I easily reproduce the bug with transparent clothing? Is this possible with stock clothes, or do I need modded clothes for that? If so, where can I find a small resource of one such piece of clothing that I can add to the mod?

2. Regarding the underwater display bug: Magical clothing now doesn't look uniformly bright any more, but it now looks uniformly dark. I still can't see the original colors. Is this the intended effect?

3. What determines now whether a calm humanoid spell will take an opponent out of combat? I still can do that on a test NPC with a with spell of magnitude 1 and duration 1. He has high disposition and low level though, is this relevant?

4. What's an easy method of turning the player into a vampire for testing purposes? AFAIR there were problems when not doing it the way the game expects it (i.e., contracting the disease, then waiting three days)

On further notice: I'm working on an improved testbed for the ref bugs, taking a more organized approach now. As far as I can see, plugins can attempt the following things:

- ESMs and ESPs can create new objects / new references
- ESMs and ESPs can try to alter or delete objects/references created by another ESM

Thois means that there are a fair bit of variables to control:
- Object or Reference?
- created by ESM or ESP?
- type of action: change or deletion?
- action tried by ESM, ESP or ESS?
- sequience of tried actions (e.g. trying to delete a moved object)
- Type of object: persistent or not?

It's possible to create a testbed for most of these permutations, but it won't be easy. I'll try nonetheless. However, if you're certain that something and the test should be tested specifically well, or isn't really necessary to test, then that would be good to know, as it might make the creation of the testbed easier.

Tinkering away ...

I think you can become a vampire by something like player->addspell "clanname blood".

I don't know if this is an engine bug or something else, but I've had CTDs if I swtich from hand-to-hand to a melee weapon if I'm wearing gauntlets. I was wearing custom armor (Akivirian) when I noticed this bug, so I don't know if it came from that or if it would happen no mater what armor I was wearing. I'll test it out on stock armor to make sure it's not a bug.

It happened to me on stock armor, Jac. It was exceptionally irritating.

Right. Is there any way to fix this, then? Some of us like to wear armor while punching our enemies senseless.

I'm trying not to recode the game, hah. Have no idea where all this data is stored, you know. It's just about doable when I can see what a function is doing, with these it's unimplemented stuff. NPCs don't do proper movements after playing an animation on them because it breaks their animation controller, I have no idea how to reset it.


1. Get some modded clothes that suit your taste.
2. It's supposed to look like it's underwater. Compare it with unenchanted version of the same thing, say, Veloth's robe and the equivalent expensive robe 2a.
3. Calm reduces the AI fight level and stops combat. If the the NPC no longer wants to fight they won't enter combat again. Try using it on actual bandits instead of forcing NPCs with startcombat.
4. Start scripts VampTest1, VampTest2, or VampTest3 (different clans) to get the full vampire effects immediately.

I'm still having issues, using load game from the menu calls ... another... function. 'ReloadReference'. Still understanding it.


Is it reproducible? It didn't crash for me just now.

If it's bugged, Hrnchamd can fix it.

He's THAT good.

I'll check when I get a chance. I've only noticed it while using custom armor, but then again, I rarely use hand-to-hand, so I don't know if it's because of that particular armor or if it's from any armor.

[edit]: I just tried this with bare fists (no armor) and it crashed when I switched from hand-to-hand to an iron sparksword (the one you get from the falling Bosmer). No errors, it just CTDs. I'm using Better Bodies, if that might make a difference.

It may be not completely fixed. StreamMusic command is OK now, but when I use PlayLoopSound3DVP command, and then StreamMusic, the volume is set again to maximum. Could you check this?

May be the same problem occurs with similar commands: PlayLoopSound3D, PlaySound3DVP, PlaySound3D, PlaySoundVP. I am not sure.

Next, another bug related to sounds are the pitch and volume values. They both do not work.

PlayLoopSound3DVP, "SoundID", Volume, Pitch

For example : PlayLoopSound3DVP "Spirit Ambient Voices", 1.0, 1.0
(1.0 = maxium, 0.1 should be minimum, but if you change thoses values, you will notice that the sound does no change at all)

Another localref beta is up. Remove any saves from the previous beta. Run all the tests, it's pretty solid.

I think the non-persistent override behaviour is intentional. There's a flag there that skips overwriting other ESPs, not sure why. The origin information should now display the correct source (it seemed to fix itself).

Please check in particular:
- Loading a game from the in-game menu. It calls a different function to overwrite references in memory instead of freeing and reallocating memory, may have different behaviour than loading from the main menu.
- modIndex in savegames, the save function may rewrite the modIndex (seen it happen to NPCs so far), not sure under which situations.


This bug does not happen on my system, in either software or hardware sound mode. Looking at the code, music volume is stored separately and isn't changed by the PlayLoopSound3DVP function at all. For the *VP functions the volume value works fine for me, and the pitch does nothing. Morrowind doesn't seem to use the pitch value anywhere so I assume it's unimplemented.

Thanks. Starting tests at once. I'll update this post with the results (or add new posts if the thread has grown in the meantime).

First impressions of the fifth localref beta:

- local ref bug in Cups&Plates testbed is fixed (took cups, left, saved, reloaded, entered hut -> the non-persistent cups are still gone, the persistent plates are still there)

- When removing the Cups.esp, the engine correctly removes all info about the cups, and updates the modindex of the plates. Contrary to the last version I tested that with, this time the cups don't even create self-deleting reference in the savegame when I remove their esp, they leave no trace.

- In the "moving lots of stuff around" testbed, where I tested multiple esps making changes to the same reference in a master, there are now no "missing ref" errors when entering the cell. Behavior is roughly the same as in regular Morrowind: For non-persistent objects, the mod that makes the first change wins, all other mods' changes to this reference are ignored. For persistent objects, the *last* mod wins. The difference between regular Morrowind and this version of the patch is one details: "ori" on such references now shows the name of the mod that first changed the reference, i.e. the mod that "won".

- In the "Scrolls" testbed, where I specifically tested a persistent vs. a non-persistent scroll, this time for both scrolls the first loaded mod won. This is consistent with regular Morrowind. I still have no idea why the scrolls and plates are treated differently.

- In the reduced "real-world" testbed, where I isolated some mods that caused missing ref errors with previous versions of the patch, no errors are shown when the game initializes, and no errors are shown when entering the respective cells. The multiplying of NPCs in the Balmora Mages Guild has ceased, instead the last mod that altered a given NPC won (according to ori information, that is - this will have to be checked a bit more thorough). In cases of non-persistent objects (like two mods making changes to the same soulgem), the mod that loaded first won.

Looking good so far. I'll let it loose on my humongous installation now and see how it behaves there. I'll also run further tests on mod removal / replacement.

Btw, I still wonder why the last loaded mod wins for persistent objects, while the first loaded mod wins for non-persistent objects. It doesn't seem to make much sense, imho.

Report from the "humongous installation" testbed: Still looking good ... after running around for 20+ minutes, I did have two errors. One was a missing NIF for an MCA head, probably nothing to do with the localref patch (but hard to test), the other was a single marshmarrow near Pelagiad that was throwing a "ref missing in master" error (might be a problem of the mods used, not of the localref patch). I'll keep testing.

Jumping back into the workshop now ...

No surprise, but nice to have solid proof! Many of us have been convinced that a key to avoiding corrupt games is NOT to use this.
If you have chance, I'd look at this code with a VERY jaundiced eye! Empirical evidence suggests it is very broken!

Aye, the ReloadReference function uses the same half-assed replacement method that causes the local ref bug. I'm investigating now, but somehow it doesn't cause as many conflicts as you would think, probably because it isn't used to load the save game, only the ESPs. Only way to test it is to break it.

Managed to break something again.

This one is a bit odd. Apparently, removing a mod led to a door marker being ignored. Steps to reproduce:

1. Load Order: Mw -> Trib -> BM -> Cups -> Plates

2. Enter Foryn's hut, take the cups, leave, save "Save1"

3. Optional: Enter and leave Foryn's hut a few times: everything is okay. Quit Morrowind.

4. Optional: Restart Morrowind. Load Save1. Enter hut. See that the cups are gone and the plates are there: Good, the local ref bug seems to be fixed. Leave and enter ForynÄs hut a few times: everything is okay.

5. Now, quit Morrowind and remove Cups.esp from the load list. restart the game. Load Save1. Enter the hut, leave it, then enter it again.

Notice something? You're standing somewhere else than before.

player->getpos on x, y and z reveals that you're standing at x/y/z-coordinates 0 / 0 / -16. Apparently the door has teleported you to 0/0/0.

Now why would it do that? It's certainly connected to the removal of the Cups.esp (I've tested that), but what exactly is happening? Does the doormarker get deleted when the engine "remembers" that cell and notices the commands to delete the cups (which it doesn't know because the Cups.esp has been removed)?

Optional next step: Leave the hut and save the game as "Save2". Quit Morrowind and analyze the save with EE. I didn't find any evidence of the deletion of any doormarkers, but I'm not sure where that info would be stored either. Also, when I start Morrowind again and load Save2, the problem has gone. So whatever went wrong, it didn't find its way into Save2.

Oddity: Sometimes, it was suficient to simply load Save1 twice in a row for the bug to appear. But this didn't work always.

With regular Morrowind, the door always teleports you to the correct place. The plates are missing, of course, due to the local ref bug, but the door works correctly.

What might be happening? Anything specific you'd want me to test?

Door markers aren't stored in the cell you exit into, rather they are attached to the door you use to get there. Deletion records inside the shack won't affect it. In the save game you will have to check the Seyda Neen (-2,-9) cell for a FRMR and a door record, DNAM is the destination. I guess it's doing something funny there.

There's about 400 possible places (structure offsets) to check how it uses the ref numbers, probably about 50 real ones - it's going to take a little bit longer before I catch them all.

Check everything with ori before and after.

...

Just did some testing. It's the most entertaining bug yet. One time instead of teleporting you into inky blackness it flipped the camera upside down and put you in front of your character, so you're looking up at them from the ceiling, and you could only select objects behind your head.

I had the inky blackness once (and couldn't acess the menu any more, so the game apparently had crashed), but I usually get the "teleport to 0/0/0" effect. which puts me right in front of Foryn.

I checked the savegame, there's no information about the door in any of them, no matter whether they were saved before or after the bug appeared. That's consistent with the fact that the bug goes away after saving (after the bug has happened), quitting, restarting, and reloading the save. I suspect that the game is misplacing some data in memory when encountering the deletion records for the cups while loading the savegame. Perhaps it's writing some zeroes in places where it shouldn't.

Might be hard to track this one down. The good thing about it is that it apparently only happens when removing mods, something that shouldn't be done anyway without properly adjusting the save with Wrye Mash.

On further notice, I ran some tests on objects (as opposed to references). Wanted to make sure that none of the changes affects how the game deals with changes to objects. So I made multiple esps that changed object data (value, model, name), and merged those with TESTool. Worked fine in regular Morrowind as well as with the beta-patch. I expected that, but thought it wouldn't hurt to check.

Well, I think it's the result of the delete markers actually working. Try this: nudge Foryn left in plates.esp and right in cups.esp. Load them all up and talk to Foryn. Remove the last esp in your load order (it's cups.esp for me). There may or may not be two Foryns when you reload, one with ori information of all zeroes, and you might be standing inside one of them. Probably the loader not realizing zero = don't load, then adding him to the end of the list of objects in the cell, overwriting the spot used for a door marker. I'll play with it.

Redid the tests about mod insertion for the new localref beta (original tests here)

Load order: Mw -> Trib -> Bloodmoon -> Cups -> Plates

Procedure:
1. Went to hut, took 2 cups and 1 plate, left hut, saved
2. inserted Chests.esp between Cups.esp and Plates.esp
3. loaded save, entered hut, checked
4. left hut, saved, analyzed savegame

Results:
The game correctly showed 2 cups and 1 plate missing. Chests were unaffected. Modindex in the savegame was correctly increased for the plate. All ori information was correct.


I then repeated the test with one condition changed: I inserted Chests.esp before (not after) Cups.esp in the load order. This introduces additional difficulty for the engine, because now the esp with the changed references has moved. Previous iterations of the local ref patch had trouble with this condition, removing chests instead of cups.

With the new version, the game correctly shows one plate and two cups missing. Chests are correctly unaffected. All ori information was correct. Modindex of the cups and plates in the was correctly updated in the second savegame. This is pretty amazing. What did you do to achieve this? I see you changed the way physidx and virtidx are assigned? (Hmm, what will happen if a mod has more than 2^24 references so that the numbers roll over? Granted, that might be a theoretical question ... )

Conclusion: Insertion of mods now seems to work properly

(Edit: Btw, there's this unrelated, but still open question of whether or not doors are automatically persistent. I think I got it now. Doors automatically become persistent as soon as you add a doormarker to them. Can be seen easily on the "Details" tab in the CS. Make a door, save the mod, look at Details -> door is under temp_refs. Link a doormarker to it, save again, look at Details again -> door is now persistent. That is why I had problems with my very first test, the doors weren't linked.)

Redid the tests for mod replacement now (original tests here)

Load order: Mw -> Trib -> Bloodmoon -> Cups -> Plates

Procedure:
1. Went to hut, took 2 cups and 1 plate, left hut, saved
2. removed Cups.esp and placed Chests.esp in its position
3. loaded save, entered hut, checked
4. left hut, saved, analyzed savegame

Results:
The game correctly showed all chests and 2 plates, and of course no cups. All ori information was correct. No records of the cups remained in the savegame, no records of the chests were entered (which is both correct). Modindex for the plate correctly remained the same.

At the moment there's 2 main fixes.
1 - Fixed the ESP reindexer to actually work, someone probably typo'd some code there. This means you can insert mods as much as you like without breaking the game. Deleted mods get remapped to index 0, and the objects (usually) get deleted straight away.
2 - Changed all the code that uses the physical index slot, to use it as a replace-target index. Conflicting ESPs can match on the target and won't overwrite anything else.

Your first test I can guarantee will always work. Second test, deals with object deletion. That's not 100% yet, as you know. While it does discard the information eventually, the deleted items get written to the refs list anyway, possibly messing up the door markers / other stuff that is generated. Been looking at it for a few hours and there's some flags in the function that control whether an object gets loaded or just passed over, but it's slightly broken as usual and will take a while to fix. That will be the third fix.

I want you to test a lot more of the multiple replacement issues, and find out what the deal with your marshmerrow was.

Hrnchamd, I'm still running release canidate five because I didn't want to install six until I was sure it was stable. What's the status and are the later releases okay to install? I'm starting a new game soon, so corrupted mods won't be an issue for me. Thanks.

Release six won't be out for 2 or 3 more hours, I'm tracking down the NPC health bar issue. The localref beta is for Psyringe to help me figure out how the loading system works.

Works for me, I got a little lost with all of the talk about local refs and didn't know if you had release 6 out yet or not. Thanks.

Release 6 done. One big fix and some small ones.

I'm closing the project to new bugs, since I'll be starting work again. You're free to discuss about whatever you like, might have time later in the year to work on it. Not too bad for three weeks work so far. Hopefully we can pronounce it stable in a week's time.

Please playtest the enchanting value thing and tell me if it's balanced? It's something that needs tuning.

Woot! You posted right as I was about to ask where you went.

Had to type up a nice summary of the changes and package it with the stuff, and test it doesn't crash horribly on a big install etc. etc. Include 10 minutes looking for the Heal Companion spell vendor in the wrong building.

Coolness. Not to bad for a hobby, huh? Thanks again for fixing a large part of what was broken in Morrowind.

New thread over there.