Heya folks. Sorry about that, as Mur4s4me shows below, there's some cases where it's resetting doors to pre-quest states and things like that, so I've removed the xEdit script from the upload. I'd recommend not using it if you already have it downloaded.
Mod makers, who can curate the PersistentRefs formID list to those which they're moving and know are fine, please feel free to use this in your mods.
Wanted to say that your mods have been exceptional in making our collective games so much better and coexist with the numerous amount of great mods that are out there. I've read through both the description and comment thread and I did see justifiable reason for removing the xedit script.
However even just looking at the plugin it's a bit difficult as even a semi advanced user to make use of it. Personally in my current playthrough I neglected to see that a 3dnpc's patch wasn't part of your great village of mixwater mill patch collection and that another mod author had made one separately. All those objects in the plugin are indeed persistent and I was trying to find out how to rework your plugin to accommodate it but I'm unsure exactly where to enter the changes correctly.
An example guide or maybe a more targeted xedit script could be useful. Thanks for all your hard work on all the pretty exhaustive patch collections its super appreciated.
First off, check the sticky and the below - this thing shouldn't be used by end users anymore, unfortunately. :)
At this point, it should be considered a sort of "I guess this works" which can be utilized by other mod makers to integrate into their mods, specifically on persistent references they move - everything can be taken wholesale, they just need to populate the "persistentrefs" formid list with the items that change.
Originally this was an attempt to make it globally applicable, but it will introduce more problems than it solves for most people.
The description says to copy an xedit script from an included edit script folder in the directory, but the download from this mod contains no "edit script" folder, or any .pas files at all
Note at the top of the description - I took the xEdit script down, because we found that this broke some quest progression stuff, etc. I left the page up as an educational tool/as a method for mod authors themselves to see how they can add scripts to move their persistent references in their mods, but the "run this xedit script and go" method shouldn't be used.
Effectively this should absolutely not be used by end-users, just for mod authors who want to add similar functionality into their own mods.
Coming back to say that the persistent reference reset seems to close some doors that previously are opened through quest, such as 7284d (the door to the Augur in the Midden Dark). I believe it should stay open after the Augur first opens it for you during the MG questline, and should stay open for the Restoration Master Ritual. The reference is within the PersistentRefs FormID list.
I think some doors in Saarthal may have that issue too, such as the jail bars at the beginning of the dungeon where you need to wear the amulet to break the wall (the wall is also "restored"). I think it could be caused by this trap trigger being in listed too.
Gotcha! Yeah on the user's end, especially on an ongoing save, there's a number of unexpected results that can occur, unfortunately. Still, thank you for the tool!
Hey there! Sorry, no screenshots, my issue is far worse. *sighs* I seem to be too stupid to get your script to work. It only took 34 seconds to load my mods with xEdit and there was no teleportation after loading my save. :( What could possibly went wrong?
Edit: Okay, looks like I forgot to install your Tweaks... *facepalm* Now I only have to figure out why my save crashes upon loading. And, yes, I downloaded the ini, but maybe it's in the wrong place...
Sorry, I'm afraid I'm not sure I'm following what you're saying? Loading xedit by itself does nothing, that's a script you have to copy to an appropriate place and run.
I'm not sure what tweaks you mean? Or what ini?
Like, I'm legitimately confused XD
But given it sounds like you might be new to running scripts in xedit and such, this tool might not be a good fit - it's more an advanced modding resource (and honestly would be best utilized via implementation on mod author side).
Geez, no! xD I do know how to run scripts with xEdit. My problem is, nothing happens in-game. In the meantime, I‘ve installed all the requirements (I forgot to install your very own Tweaks mod, which is required for your Papyrus Extender to run, which is required for Persistent Reference and Object Mover to work in the first place ), but still nothing happens. Again, I let the script does its thing, I save the new ESP, I load my save and ... nothing. No teleportation, no process to see in the left corner... *sighs* Edit: And, yes, I do have Address Library etc. pp. installed.
Hmm. If nothing happens in-game, that sounds like the plugin isn't enabled? Teleporting won't happen immediately, but there should be some notifications telling you to not move until it's done, etc.
Yes, the plugin is enabled, but there’s still no notification. I‘m sorry I can’t be more helpful. I‘ve tried reinstalling and double checking everything for so many times, that I‘m afraid I can’t use your script. I know it‘s my fault, and I‘ve obviously missed something, but I just can’t put my finger on it. Anyway, thank you for trying to help!
Only things it should need are the plugin, po3's extender, skse, and the address library for the respective version, I think. Hm.
I'd take a peek at the plugin in xEdit to make sure it looks like it actually got populated with stuff, but other than that not sure how to go about debugging.
Yes, that’s right!! I‘m using Alternate Start, and the quest Unbound doesn’t exist in this mod. How far am I supposed to follow the main quest, so that the script can start? Actually, it’s nothing I am planning to do soon... Anyway, I‘m glad we finally figured out what was going on! (Unfortunately, I don’t know how to change that requirement myself like the other user.)
Just need to have MQ101 done. Might be possible to do so via console commands - I wouldn't normally recommend it, but this tool is already throwing stuff at the wall to see what sticks, so maybe?
Why is "MQ101 is completed" a requirement for the script to run?
I use a alternate start mod and have not begun the mainquest yet, so MQ101 is not completed in my case. Is MQ101 a hard requirement to prevent something from breaking or could this check be disabled?
It's something of a deadman switch to prevent anything bad from happening if a person were to boot a new game with the plugin enabled. The teleportation that happens after it runs would completely hose any sequence which is going on, etc, and irrevocably break things. As such, it was made with a shield to protect from that (because I have no control over what else you've got installed, I can't handle every potential combination).
If you're comfortable editing stuff to remove that check, knock yourself out - in your case, it should work fine.
Hello again Janquel! It seems that your mod MIGHT be bringing back some previously dead and cleaned-up NPCs back to their location. In this case, it's Jaree-Ra. I can also confirmed he's in the Persistent References FormList
So in thinking about it, NPC refs are of the type which a) could be legitimately moved via script, and b) NPCs tend to teleport to navmesh so having it in the wrong spot isn't the end of the world.
I'll upload an update tomorrow that removes npc ref marker types.
Thanks! EDIT: just a little note. Typing "help runmarker" in console doesn't do anything, since console searches cannot find reference IDs (unless I'm missing a plugin, More Informative Console doesn't do it).
EDIT 2: In an attempt to rerun the mod after your update, I renenabled the start marker (FEx805 and was previously disabled, as verified through MIC), saved, quit the game, and came back. However, it seems I'm not getting notification of the mod running like the first time I installed it. It's still saying the marker is enabled upon loading. I'm currently waiting to see if the mod is running with notifications not showing up, but yeah it's kinda odd.
Coincidentally, the run marker (FEx804) was already enabled. I don't know if that says anything or not though. I assume that one never disables anyway?
Is it possible that this patch causes issues with some weapon displays, both vanilla and LOTD? After running the patcher, I have several displays I can't interact with anymore. Most noticeable so far was the Blade of Woe display (which had a replica placed in it) and some weapon wall hangers in the Safehouse's crafting room.
Given you've been a help on other pages, I'm going to ignore the lack of screenshots like requested in the sticky, but actually finding the stuff is a bit of a pain in the butt. Focusing on Blade of Woe since it's a specific one.
Do you have any mod which is touching reference xx1260D5 or xx16BCA0 for LOTD specifically? This is the activator for Blade of Woe and the Blade of Woe display. The first one is enabled initially but set to be the opposite of the latter, the latter is disabled initially. Those would be the two which would factor for this case, and more to the point, the script should only include them if you have something that moves them (which actually seems unlikely). Additionally, can you open the console and type "prid <the formid above>" with MIC enabled to see if they're currently enabled/disabled? Finally, can you open your load order in xEdit, search for that formID, click the "referenced by" tab in the right panel, and see if either is included in the PersistentRefs formid list?
My apologies! I forgot to check back here! I figured screenshots wouldn't be too helpful in this case because all you'd see is a lack of interaction while I stare at Blade of Woe.
Loading my entire load order, I found no other mods touching upon those references. It was actually the first thing I checked, to see if your fix didn't move it to the "edited location" or something. However, checking the "references by" tab, only xx16BCA0 is in the FormID list. The other one isn't, by default.
As for using console commands, here are the results.
Spoiler:
Show
?
Note: If I disable xx16BCA0, then the option to put Blade of Woe comes back, as expected. The issue is that I am unable to take it out myself when I've put it there, because the activator to take it out isn't enabled, it seems, or has moved.
Note 2: It is possible it's simply my save starting to crumble down. This issue happened to the White Phial as well, before even installing your mod, but I only noticed it happening to a few daggers in the dagger rack after running your mod. I might have been a coincidence.
No worries, but please check back frequently because I do want to figure out bugs :D
My question was actually if either were in the PersistentRefs.esp formID list, which from your screenshot looks like neither one of them is, which means that my script wouldn't have done anything to either of them. Effectively, in order to get added, they would need to be highlighted yellow in xEdit (ie, a patch touches the activator/item itself, and moves those) which isn't the case from your shots.
Although....hmmm. Out of curiosity, can you check if 0009CCDB is in PersistentRefs? Rather than being the display itself, that's the reference for Blade of Woe which is placed in the world when Astrid dies, allowing you to pick it up. I'm wondering if maybe that was moved by something (it is a persistent ref), which in turn is causing LOTD to get confused....but it doesn't reference that ref, so I'm not seeing how that could happen.
yeah, if xx16BCA0 being disabled the option to place it comes back, then that's not moved - something seems to have gotten the dynamic display script out of sync. So that activator is "initially disabled" - basically, it starts out disabled (which is how you're initially able to place things). Decompiled the dynamic display script, and it appears that the important bit is a property "Grabable" which is supposed to say whether an item can be taken, and if it's set to false, block activation. This is defaulted to false, but is supposed to get overridden with true somehow.
So my best guess would be to go into the LOTD MCM - there should be some toggle in there which makes it reset displays (run through what's in there, etc) and try giving that a go. It'll take a few minutes you'll want to sit there while it's checking everything, but that might get you unstuck. But unfortunately (or fortunately?) I don't think that's related to this mod.
Yeah I think you're right. It seems to be an unrelated issue that happened in coincidence with me using this mod for the first time. The Blade of Woe (0009CCDB) also wasn't moved by any other mods. Anyway, I think this concludes it, since your mod definitely couldn't have affected these references! Sorry for the trouble.
60 comments
Mod makers, who can curate the PersistentRefs formID list to those which they're moving and know are fine, please feel free to use this in your mods.
However even just looking at the plugin it's a bit difficult as even a semi advanced user to make use of it. Personally in my current playthrough I neglected to see that a 3dnpc's patch wasn't part of your great village of mixwater mill patch collection and that another mod author had made one separately. All those objects in the plugin are indeed persistent and I was trying to find out how to rework your plugin to accommodate it but I'm unsure exactly where to enter the changes correctly.
An example guide or maybe a more targeted xedit script could be useful. Thanks for all your hard work on all the pretty exhaustive patch collections its super appreciated.
At this point, it should be considered a sort of "I guess this works" which can be utilized by other mod makers to integrate into their mods, specifically on persistent references they move - everything can be taken wholesale, they just need to populate the "persistentrefs" formid list with the items that change.
Originally this was an attempt to make it globally applicable, but it will introduce more problems than it solves for most people.
Effectively this should absolutely not be used by end-users, just for mod authors who want to add similar functionality into their own mods.
I think some doors in Saarthal may have that issue too, such as the jail bars at the beginning of the dungeon where you need to wear the amulet to break the wall (the wall is also "restored"). I think it could be caused by this trap trigger being in listed too.
I'll update this thing tonight to be a modders resource for mod authors that want to make formid lists for their specific mods.
Edit: Okay, looks like I forgot to install your Tweaks... *facepalm* Now I only have to figure out why my save crashes upon loading. And, yes, I downloaded the ini, but maybe it's in the wrong place...
I'm not sure what tweaks you mean? Or what ini?
Like, I'm legitimately confused XD
But given it sounds like you might be new to running scripts in xedit and such, this tool might not be a good fit - it's more an advanced modding resource (and honestly would be best utilized via implementation on mod author side).
Geez, no! xD I do know how to run scripts with xEdit.
Edit: And, yes, I do have Address Library etc. pp. installed.
I‘ve tried reinstalling and double checking everything for so many times, that I‘m afraid I can’t use your script. I know it‘s my fault, and I‘ve obviously missed something, but I just can’t put my finger on it.
Anyway, thank you for trying to help!
Only things it should need are the plugin, po3's extender, skse, and the address library for the respective version, I think. Hm.
I'd take a peek at the plugin in xEdit to make sure it looks like it actually got populated with stuff, but other than that not sure how to go about debugging.
I use a alternate start mod and have not begun the mainquest yet, so MQ101 is not completed in my case.
Is MQ101 a hard requirement to prevent something from breaking or could this check be disabled?
If you're comfortable editing stuff to remove that check, knock yourself out - in your case, it should work fine.
I will edit and recompile the script then and let it loose.
It seems that your mod MIGHT be bringing back some previously dead and cleaned-up NPCs back to their location. In this case, it's Jaree-Ra. I can also confirmed he's in the Persistent References FormList
I'll look into it, thanks :)
I'll upload an update tomorrow that removes npc ref marker types.
EDIT: just a little note. Typing "help runmarker" in console doesn't do anything, since console searches cannot find reference IDs (unless I'm missing a plugin, More Informative Console doesn't do it).
EDIT 2: In an attempt to rerun the mod after your update, I renenabled the start marker (FEx805 and was previously disabled, as verified through MIC), saved, quit the game, and came back. However, it seems I'm not getting notification of the mod running like the first time I installed it. It's still saying the marker is enabled upon loading. I'm currently waiting to see if the mod is running with notifications not showing up, but yeah it's kinda odd.
Coincidentally, the run marker (FEx804) was already enabled. I don't know if that says anything or not though. I assume that one never disables anyway?
Now I can talk to Mercer Frey without TCLing through a wall, and avoid the consequences of my own bad practice
No comeuppance!
It's great work, cheers
Is it possible that this patch causes issues with some weapon displays, both vanilla and LOTD? After running the patcher, I have several displays I can't interact with anymore. Most noticeable so far was the Blade of Woe display (which had a replica placed in it) and some weapon wall hangers in the Safehouse's crafting room.
Given you've been a help on other pages, I'm going to ignore the lack of screenshots like requested in the sticky, but actually finding the stuff is a bit of a pain in the butt. Focusing on Blade of Woe since it's a specific one.
Do you have any mod which is touching reference xx1260D5 or xx16BCA0 for LOTD specifically? This is the activator for Blade of Woe and the Blade of Woe display. The first one is enabled initially but set to be the opposite of the latter, the latter is disabled initially. Those would be the two which would factor for this case, and more to the point, the script should only include them if you have something that moves them (which actually seems unlikely). Additionally, can you open the console and type "prid <the formid above>" with MIC enabled to see if they're currently enabled/disabled? Finally, can you open your load order in xEdit, search for that formID, click the "referenced by" tab in the right panel, and see if either is included in the PersistentRefs formid list?
Loading my entire load order, I found no other mods touching upon those references. It was actually the first thing I checked, to see if your fix didn't move it to the "edited location" or something. However, checking the "references by" tab, only xx16BCA0 is in the FormID list. The other one isn't, by default.
As for using console commands, here are the results.
Note: If I disable xx16BCA0, then the option to put Blade of Woe comes back, as expected. The issue is that I am unable to take it out myself when I've put it there, because the activator to take it out isn't enabled, it seems, or has moved.
Note 2: It is possible it's simply my save starting to crumble down. This issue happened to the White Phial as well, before even installing your mod, but I only noticed it happening to a few daggers in the dagger rack after running your mod. I might have been a coincidence.
My question was actually if either were in the PersistentRefs.esp formID list, which from your screenshot looks like neither one of them is, which means that my script wouldn't have done anything to either of them. Effectively, in order to get added, they would need to be highlighted yellow in xEdit (ie, a patch touches the activator/item itself, and moves those) which isn't the case from your shots.
Although....hmmm. Out of curiosity, can you check if 0009CCDB is in PersistentRefs? Rather than being the display itself, that's the reference for Blade of Woe which is placed in the world when Astrid dies, allowing you to pick it up. I'm wondering if maybe that was moved by something (it is a persistent ref), which in turn is causing LOTD to get confused....but it doesn't reference that ref, so I'm not seeing how that could happen.
yeah, if xx16BCA0 being disabled the option to place it comes back, then that's not moved - something seems to have gotten the dynamic display script out of sync. So that activator is "initially disabled" - basically, it starts out disabled (which is how you're initially able to place things). Decompiled the dynamic display script, and it appears that the important bit is a property "Grabable" which is supposed to say whether an item can be taken, and if it's set to false, block activation. This is defaulted to false, but is supposed to get overridden with true somehow.
So my best guess would be to go into the LOTD MCM - there should be some toggle in there which makes it reset displays (run through what's in there, etc) and try giving that a go. It'll take a few minutes you'll want to sit there while it's checking everything, but that might get you unstuck. But unfortunately (or fortunately?) I don't think that's related to this mod.