A possible new issue has arisen: http://www.gamesas.com/bgsforums/index.php?s=&showtopic=848399&view=findpost&p=12411597

In the Horse Armor DLC shipped by Bethesda, the script HorsePCWhiteAnvilScript dropped the TellPC and Mounted variables. In TES4Edit, this shows up as a purple background conflict. Elminster's explanation of this sounds like installing the DLC on an existing game is going to create issues with the script, and the UOMP appears to magnify this as the order of the variable indexes is also not correct. Since TES4Edit doesn't allow the order of these to be changed, I'm not sure how to resolve it, but it's the only critical conflict in the UOMP, UOP, or USIP that needs to be addressed.

Also noticed while I was at it that the HorsePCWhiteAnvilScript has a bad InCell check:

Begin OnPackageEnd HorsePCAnvilGoHome	If TellPC == 0 && Mounted == 1		If GetInCell Leyawiin == 1			Message "Your White horse has returned to Anvil's stables."			Set TellPC to 1		EndIf	EndIfEnd

It should be checking GetInCell Anvil.

@SteelFalcon & Arthmoor: noted all those. Nice catch on the Anvil horse script. I'll have to see if the fix in the UOMP overriding the bad DLC script (Anvil horse would not return home if the player rode another horse so the Anvil one was lost) can be fixed without the variables, but if not, I'm going to have to try it out: start a new game without the UOMP Horse Armor, get the Anvil horse and ride it around/lose it, etc. and then activate the UOMP Horse Armor plugin. I'll let you know if there's any result. Right now, working on the USIP letting reports like this filter in.

Great job!
I noticed a few bugs though (nothing big). The room in frostcrag with the summoning altar is called "Bruma House Test". Also, I noticed a wall in the Vile Lair is a little out of alignment. Works great though!

The Frostcrag room name being wrong is due to another mod (perhaps the Black Screen Fix) loading after the DLC and UOMP patch. It alters the cell header so overrides both the others' names. If you use the UOP/UOMP you don't need the black screen fix any more.

If you can get me the formID (open console, click the object, eight hex digits at the top ie 0A004321) of the wall I'll fix it. I am planning on a small re-release of the UOMP for the leftovers.

Anyone still getting this while using the black screen fix should grab the update I posted to Nexus. Even with the fix in the UOPs there's still value in having the separate plugin for mods that alter vanilla cells and thus revert the changes. The update renames the cells used by Frostcrag, and in its case also fixes the ambient lighting problem.

Meta thanks!! No problems with the install.

Having a look at this right now and to the best of my understanding it's as good as it can be,

Vanilla:
Short RespawnHorse
Short TellPC
Short Mounted

DLC:
Short RespawnHorse
short FakeDeath

UOMP:
Short RespawnHorse
Short TellPC
Short Mounted
short FakeDeath
Long ItemsStolen
Long BountyGold

The UOMP has the same first three vars. as vanilla in the same order so it's shouldn't be throwing off any indices. It adds three vars but that doesn't change any original ones (inserting one or changing the order of the three original ones would.) It would seem that the real problem is the DLC itself by it changing the second short.

However as promised I'm still going to try out the Anvil horse without the UOMP and then with it to see if anything messes up. I've never heard of a problem with this and the UOMP has been around with this script change in it since Feb. 2007 (and when there was the problem with Shadowmere running off after being armored it was reported the same day.)

Edit: I tried it out... nothing bad happened. I started a new game with the DLC and UOMP patch disabled, went to Anvil, stole a horse, got a bounty, paid it off, bought a horse, rode it around, left it in the wilderness, stole another horse, the Anvil one went home and I got the message this time, rode it some more, saved. Quit and activated the DLC and loaded the save. No problem. Did some more riding/stealing/leaving horse in in wilderness. Saved/quit. activated UOMP patch, loaded, fine, ride/leave/steal/wait/message/ride, yadda. Quit, went back to save with no DLC, activated DLC and UOMP at same time. Did as above. No crashes, no misbehaving, no problems at all. I did a showvars on the horse on all of these and nothing out of whack. Using the horse would set what needed to be if it was wrong. Well I fixed the message so that will go in the next UOMP. And that... will be tomorrow.

Edit: Well, make that "should be" tomorrow. You never know.



Agreed! Inserting a variable at the top instead of adding one at the bottom, or changing the variable type of an existing one to one of a different size in bytes would definitely be a bad idea.

Yes. I think in this case since the affected indexes are both short/long type variables that it won't cause corruption issues. It's still something to keep in mind for the future though

I'm having a bug with Battlehorn Castle where when I buy all the upgrades, no quest updated popup appears, and the upgrades doesn't apply. Although when I get back to the castle, I receive a letter about going back to The Merchant's Inn and buy the dwemer forge.

Also, there's a tree that is incorrectly rooted and positioned (it's in the middle of the way to the castle, just in front of the castle gates): Cell: -23, 24 | FormID: 000e0dd7

Hope it helps!

My char: lvl 1 orc, just got out of the tutorial sewers

Installed mods: Just Oblivion/SI 1.2.0416, and all the unofficial patches.

Heard of this many times (even from people on the 360) but wasn't able to recreate it. If you could send me a save in this state it would be much appreciated. http://mailhide.recaptcha.net/d?k=01L781oIFafS9dPEHc_jH9SQ==&c=gm2bUaUtpVwg7kAeZuF4tVBFfvI9quzUk0nfRInqh8E= and I'll PM it as well. That would be a nice one to finish the UOMP off. (You don't get the completed popup until you buy the forge though.)

Edit: Nope, false alarm. I wonder if this was the problem with all the other instances of this. The upgrades were all there but they don't affect the entry hall or wing where the statues go. They're present if looked for.

I've seen the same tree before, and reported it once before as well. Problem is, the very same character in the very same day went back to the very same location without altering load order and that tree was gone. I know the one you're talking about because it was right smack in the middle of the road, you couldn't miss it. But it vanished without explanation and I never looked back - had forgotten to get the FormID at the time.

Looking at it in TES4Edit, the tree is lowered by the UOP but then Battlehorn comes along and moves it aside, as the XYZ values are all changed. Doesn't explain why it's not still sitting in the road though

Having looked at it in the CS, apparently the data is assigned to cell -23,24 but the tree's coordinates were changed enough to actually shove it into cell -23,23 which may account for the anomaly being seen and then vanishing later as it's position in the save is updated. Would explain it for me since that character had visited the area before buying Battlehorn.

Thanks for your one of kind as only you can do it work Kivan and Quarn aswell as for your patience dealing with the countless bugs and us fans especially when we get flaky.

Very minor issue. The DLCThievesDen - Unofficial Patch - SSSB.esp file didn't get the fog fix treatment, which is apparently needed

Already caught that in the current edit, but thanks. Should be ready to test out today. I audited the entire Mehrunes' Razor (some of those cells have 8-900 objects in them!) so I don't get any submissions for that one for stuff being slightly out of place. Nothing too bad but did fix a few things. I'll update the changelog once I'm done.

Edit: And updated. Barring introduced bugs this will definitely be the last UOMP. Now to write up the readme's and build the installers.
Edit2: Readme written, installers built and tested, betas uploaded, beta testers PM'ed.



After the amount of time I've thrown into this project, my disregard for important things outside of it, and my obsession to make every little detail perfect, I may qualify for the epithet "flaky" as well.

The order of the variable declarations in the script source is totally irrelevant.

The system works like this:

The SCPT record (and other places where scripts occur, like quest scripts) contains an array of SLSD/SCVR sub record pairs.

The SLSD subrecord contains an index number, the SCVR the variable name.

These subrecords define a mapping between variable names and index numbers.

When you compile a script, the first thing that happens is that this mapping as it already existed (from previous compilations of the script) is being loaded in. All variables for which a mapping already existed will keep their index number, no matter in what order they occur in the source. All mappings for variables which are not longer in the source are deleted. And all variables still left will get new indexes assigned starting after the highest index that ever was assigned to any variable for this script before.

If you have a script with a variable, compile it, remove that variable, compile it again, add a variable with the same name, compile again then this variable will now have a different index number then it had before.

Now suppose you got a script from oblivion.esm, and you got 2 different esp's which override that script.

Suppose you start editing the first of the 2 plugins, adding a variable:

Short B

compile (the variable with the name B now gets it's index assigned), play around with the script, try different things... then you need another variable, so you add:

Short A

in front of Short B, compile (the variable with the name A now gets it's index assigned, which is higher then the index for variable B even tho variable B is declared further down in the script source).

After some further editing you are done with the script. Great. You copy the whole script text, close this esp, open the other esp, past in the complete script and compile.

But now on this compile there is no index assignment yet for both variable A and variable B. And because variable A came first in the source it got it's index assigned first.

You now got 2 esp's containing 2 times the exactly same script text. But the variables A and B now got different indexes assigned in these 2 plugins!

Variable names have no meaning except during the compilation of the script. All the compiled script data only ever refers to variable indexes. And the save game only contains the information variable x contains value y.

So if you now start the game with the first of the 2 plugins loaded, the script runs, writes values into the 2 variables, you save the game, exit oblivion, add the 2nd plugin to the load order after the first (or replace the first with the 2nd), start again, load the savegame. When the script runs it will find whatever value was written into variable A is now in variable B and whatever value was in B is now in A. Because the save game only had values stored for index 5 and 6 and with one script 5 and 6 are B and A, and with the other they are A and B.

Obviously this is especially bad if one of the 2 variables was a ref and the other some numerical value. But even if it's just 2 variables with numbers that get mixed up it can cause real problems.

You can fix such problems with TES4Edit by opening the SCPT record and changing the index values so that the same variable name has the same index in all involved files (keeping in mind whatever effect changing indexes will have on already existing save games..). There is no problem with having holes in the sequence, so a script can have a variables 1, 2, 6, 9 defined.

Also, in the SCHR subrecord you'll find a VariableCount value. That name is actually not quite right. It's not the number of variables in the script, it's the number that will be used as the next variable index if a compile finds a variable name for which no index is yet assigned. So that value should be larger then the highest variable index currently defined.

Hope this clears up any confusion...

Certainly does and thanks for the detailed explanation.



Done and I fixed the variables to match vanilla; RespawnHorse, TellPC and Mounted now come up as the same as vanilla. Can't do much about them matching DLCHorseArmor.esp as TellPC is missing, but if the DLC and the UOMP are both installed at the same time or on a new game if they are present there will be no discontinuity whatsoever. Thanks again, and for your amazing utilities!

One important thing I forgot to mention, after you change the assigned indexes with TES4Edit it's vital to load that script in CS and recompile it. The index/name mappings in the module have no effect on the game engine. They are just used during the compilation of the script. If you don't compile again after changing the indices then the compiled script data still contains the old assignments and nothing will have changed.

Final changelog of the final UOMP is posted. Installer's built and tested and I'll be uploading it soon. If there was anything else, you're too late.

Released... up at Nexus and PES.

Two down, one to go.



You're welcome! So time for my one and only rate-beg for the UOMP now that I got the UOP's and USIP's out of the way. Please keep in mind that two years' work have gone into the Unofficial Patches. If you feel that they improve your game, please show your appreciation. It's the only payment I ask.

(Not you Khalim, I know you already did.)



Thanks X'tyfe.



Heh... maybe for the UOP. Not for this one though; barring introduced bugs the UOMP is done, finished, and also complete! Did I mention it's finalized?

You're truly amazing, Kivan. Thanks a million for the hard work you've done. :foodndrink:

awesome UOP, UOMP, and USIP have been rated

Kivan, you and the team are working so fast we'll need a RSS feed to keep up. Thanks to you and everyone who helped for all the hard work :thumbsup:

Just wanted to drop in and say "Thanks" to Kivan and everyone for all the hard work and attention to detail that has gone into this and all the unofficial patches.

There's no such thing as a perfect game, but with this mod community, the TES games creep ever closer to that unattainable goal!

Good to see it released. Congratulations.

well, its good to know that its been noticed by bethesda

A hush falls over the thread; it's so quiet you can hear Kivan's jaw drop. Thirteen is a lucky number. Thank you.



Agreed.

To anyone who beta-tested: yes, of course I went and added more stuff so grab it from Nexus or PES for the latest and last. It does appear that anything that still hasn't been fixed is so minor as to not warrant even having been, never mind a re-release. At least I hope so! Too many other things to work on.

@Vezner: Thank you! That's very kind.



Thanks!

Going to hit my smiley limit soon on this post!