Unofficial Skyrim Special Edition Patch

Correction:
The book's RefID is 000ddfaf.

A few others that are owned by HagravenFaction (see list below), which should have their ownership removed completely (i.e. they should have it set to NONE). These individual references don't need an ownership setting as long as the owner faction for the cellar (AnisesCabin01) is changed as explained in Issue #33973. If I remember correctly, when individual items have specific ownership set it overwrites the owner setting for the cell. Hopefully that's not too confusing, but I know Arthmoor understands how it works.

000ddf9d, 000ddfca, 000ddfcb, 000ddfcc, 000ddfde, 000ddfe1, 000ddfe7, 000ddff0, 000ddff2, 000ddfee, 000ddff5, 000ddff6, 000ddff7, 000ddff8, 000f6019

One more thing:
The trap door(s) (000de023 & 000ddfb0) probably need their ownership setting changed from HagravenFaction to dunPOIWitchAnise. There are two references for the trap door (for the exterior cell and the interior cell). Setting one of them using the Creation Kit automatically sets the other (i.e. you can't change both). However, xEdit only shows one of them as being edited and the other still retains the HagravenFaction setting. Maybe xEdit is incorrect on this? Either way, it's very confusing.

Sorry for all of the posts, but I wanted to make a correction to the information in the comment above (#3). The exterior trap door reference (000de023) is all that would need to be changed in the CK. The interior trap door reference (000ddfb0) doesn't have an ownership setting after all.

Fixed everything except the respawning, I'm not positive that's a bug.

Maybe I should have explained what made me think the book, barrel, and boots being able to respawn is a bug. Every other item and container in the exterior area of the cabin has deliberately been set to not respawn by the developers. That is accomplished by changing the encounter zone to 'NoResetZone' or by removing the respawn flag on each specific item or container. The only exception I can see to this rule are decorative junk items that have extremely low value and have no specific use (ex. plates, tankards, pots, shovels, empty bottles, etc.). In the case of the cupboard, sacks, and dresser, they can never respawn since their base object is non-respawnable. The barrel, however, has a respawning base object and that's why respawns its contents.

An explanation regarding encounter zone settings and why they are necessary: They're used in exterior cells that are part of a specific location that isn't supposed to reset. In this case AnisesCabinLocation includes two cells: AnisesCabin01 and AnisesCabinExterior. The encounter zone record (AnisesCabinZone) has the 'Never Resets' box checked. The big problem with exterior cells is that, due an engine bug, the game doesn't recognize that the Encounter Zone (ECZN) record has the never reset flag checked, which is why each individual reference has to individually be set to never respawn. It should also be noted that exterior cells don't have a specific option There are a number of locations where this is the case that have already been corrected by USSEP previously.

Something else that could potentially be very important - regarding xEdit's recognition of DOOR records in very specific cases: Changing the ownership setting on the exterior trap door (000de023) using the Creation Kit automatically makes an edit to the trap door reference in the basement (000ddfb0). When the plugin is cleaned using xEdit, it will remove the CK's edit to 000ddfb0 (this may have already happened to the fix plugin uploaded in post #4 above). I reached out to the xEdit people a while back and they insisted that this is the way xEdit is supposed to work and that the CK's edit to 000ddfb0 is unnecessary (or to use their word - benign). I'm not so sure that what they said is actually true because the CK usually doesn't make unneeded edits. Arthmoor, I suspect, would know if edits to both of the trap doors are necessary. If the edit to the interior cell's trap door is in fact important, you're likely going to have to do something (such as a very minor or harmless edit to the record) in order to force xEdit to not throw it out when cleaning the fix plugin, and maybe USSEP itself (if that is done). See this screenshot from xEdit regarding the situation.

Ah, OK. This should be a full fix, then.

Attached Files:

33972.esp

Thanks. Maybe Arthmoor would be able to comment about the information in the last paragraph of my comment (#6) above before he closes this ticket, whenever that may be. It's possible that there isn't anything to worry about, but I just wanted to make sure since xEdit sometimes removes legitimate Creation Kit edits when plugins are cleaned.