Conflicts and Load Order As stated in the description, this mod should be loaded near the top of the load order; any mod editing the same records for its own purposes should be allowed to 'win' the conflicts. The conflicting records will miss the 'no respawn' flag (with a basic knowledge of SSEEdit you could carry it over), but this can't be avoided without patches.
BlackreachDM This makes sense when installed before having cleared the three dungeons -- they're designed to be played following the regular path and going the "wrong" way isn't good. The extra activators start working only when you exit the related dungeon right after having cleared it.
For example, if you clear Raldbthar with this installed but don't have the attunement sphere at the moment, when you later enter Blackreach from Alftand you can open the Raldbthar lift from below.
Quite possible, I quit updating USSEP since it started to require AE.... sometime later I also quit playing Skyrim.
That specific reference is indeed useless in the mod because it's flagged "open by default", but its presence is a consequence of having made the mod via xedit scripts. I'm not that crazy as to manually check a thousand records one by one :)
Thanks for this mod! There seems to be a small conflict with ccASVSSE001-ALMSIVI.esm CC content: https://i.imgur.com/ITLT3h4.png (since the CC content is part of "vanilla" for AE, we can't order DwemerGatesNoRelock.esl to precede it).
I made a quick compatibility patch just copy/pasting No Respawn flag for that door (https://i.imgur.com/AWkPTMR.png): https://easyupload.io/1ze3xm Hopefully I didn't break anything...
Feel free to include it in the mod if you want to (or your own patch, I imagine for the "full", not just dwemer-only, version it may need a lot more compatibility edits when it comes to CC conflicts). I think FOMOD has a feature where it can detect the presence of plugins (like ccASVSSE001-ALMSIVI.esm) and enable it by default then. Thanks!
The door edit was redundant in the first place because the form is flagged "open by default" -- no point in adding a "no respawn" flag. This happened because I used a script to batch-edit the references instead of manually checking (and losing what's left of my sanity) thousands of records. The best way to fix the conflict is removing the form from the mod (which is what I've done in the update.)
@TorinCollector: Since the mod now doesn't even edit that record anymore (the record that was also edited by the AE content and thus created a conflict) it's compatible with and without AE. So to answer your question it doesn't require any AE but if you have AE content it now doesn't conflict with it anymore. Best of both worlds.
I have a question though: you added "XLRL - Location Reference" records, but I have one .esp that doesn't forward - like vanilla. Is it important? (I couldn't figure out... Are XLRL merged at runtime?)
XLRL are inside Form ID like '00098101' 'Placed Object'... ShimmermistCaveLocation for exemple
They're something that the CK randomly adds or removes by itself, not an available choice. Since they come and go without any visible in-game effect, and they don't exist in the original game plugins, I'm pretty sure they're totally useless.
I see the description says the mod now requires USSEP. But do I need a specific version of USSEP? I'm just wondering because I use the old version of USSEP made for Skyrim version 1.5.97.
This mod is very useful, but I was wondering if it is possible to close the gates afterward. You can close the lever ones, but what about the button ones?
I don't understand what difference you see between a lever or a button, apart from the appearance -- please explain. Anyway, if the button is active by default or made active by solving some puzzle that doesn't reset, it keeps opening and closing the gate. If the button is made active or inactive by some puzzle that resets, you'll probably need to solve it again.
Hey Tarlazo, how do you think this would interact with dyndolod's gates' lods? My guess is that if the gates remain open dyndolod will load the base mesh lod with a closed gate and when you approach it would suddenly be open?
What do you see if you open the gate without this mod, go away and get back before it closes again? I suppose that when it stays open because of this mod you see the same. But your guess is as good as mine; I've never used dild- dyndolod and don't know what it actually does.
Hi, I've never had a problem with this mod and I love it. All the lifts to and from Blackreach to the surface of skyrim all remain open. What drives me nuts is opening the gates in the first place. There is a known bug which involves the lift operation animation, that prevents you from operating the gate lever. The suggested solution on PC, certainly with a xbox controller is to spam the D-Pad control (a menu pops up that returns control you), by interrupting the animation. It works but is quite messy. I was wondering if you knew of a better solution, that could possibly be incorporated in this mod (for years I never had this issue with the lifts, but now it happens everytime I use any of the lifts to and from Blackreach). Thanks again for your mod.
I never heard of this bug. Maybe a more detailed description of what happens could give me some ideas. But I suspect that unless it happens in my own game, it will be nigh impossible to fix.
The bug has been identified by many users, but it's difficult to pinpoint the cause. The animation causes a stuttering effect (both sound and visuals), that makes it impossible control the player character enough to operate the lever. I'm not certain that succesfully pulling the lever in this state would return contol to the player. By bringing the favorites menu up (spamming the D-pad controls) effectively interupts the animation, allowing normal game play to continue. I hazard a guess that something is preventing the animation from completing (it just loops). There is nothing in the log to suggest an issue. Sorry, that is the best description I can give. I suspect that a mod is the cause and elimination by trail and error, installing the mods one by one from the vanilla game would track down the possible cause. At present, I'm close to the mod limit for skyrim so it would be a lengthy process. This error does not occur with lifts that do not connect Blackreach to the surface of Skyrim. There is a lift in the pumping station within Blackreach and the one used to obtain the Elder Scroll. Neither of these lifts are gated.
It's a far shot but the first thing I'd try in a case like that would be attempting to make a save while having the issue (maybe a quicksave could be successful?) and loading it in save cleaner to check for script overload.
I'll give it a try next time I'm in Blackreach, which will be quite soon as I'm on a new game. Cheers for the reply. I'm not sure you can save, while the error is occuring, but I'll try. It might be possible to save via the console if it will allow.
The Blackreach issue still occurs on all gated lifts between Blackreach and the surface. I did manage to make a save and run it through 'Resaver''. I have included the results on active script found.
ACTIVESCRIPT Attachment ID: null Attachment element: None This thread is attached to an instance from Skyrim.esm. ScriptInstance: blackreachExitElevatorScript: *000ef7ba (00000206e226eec0) ID: 00382d55 Type: 00 Version: 0.1 Unknown (var): INTEGER:1 Flag: 00000002 Unknown1 (byte): 00 Unknown2 (int): 00000000 Unknown3 (byte): 00 FragmentData (struct): null Unknown5 (byte): 00
link:
SCRIPT blackreachExitElevatorScript extends ObjectReference Contains 1 member variables, 0 were inherited.
I'm not sure if this helps track down the cause of the lift bug. I also noted that in the time it took to make one manual save, the system made about two dozen autosaves. Presumably in response to an attempt to change cell location Blackreach to Skyrim.
Not really, that only says that you activated the Mzinchaleft lift from Blackreach and that the script is attached to six lift levers (which is correct.) I meant an overload of many active or suspended instances of the same script, not just one. You see that in the left pane expanding Active Scripts and Suspended Stacks.
I think I've found a solution, at least for me. I try to avoid fast travel and prefer to hoof it to wherever I want to go. I simply turn off 'save on travel' in game settings. The lift animation now completes and control is returned to the player, without the bug (link in my second reply). This is obviously not a fix, but a work around. Maybe there would be a way to complete the autosave before or after the lift animation.
@edit: Scrap this idea, it certainly worked the first time, but not everytime. I did find an easier way to interrupt the bug, by pulling up the wait timer. Thanks for your help and patience with me, perhaps this will help others.
Good, and that explains why I never saw the bug in my game: I've always played with all the autosave options disabled. I even bothered to remove all the scripted ones :)
Hi, It's me again. By any chance does this mod alter Ustengrav's gates at all. Normally, if the player uses whirlwind sprint to get through the series of gates, they then remain open for the rest of the party. For some unknown reason they have closed, cutting me off from my followers. It no big deal at that stage of the dungeon, but I was just curious. I know Ustengrav is notorious for having bugs, with mods that have no real connection with Ustengrav.
No, Ustengrav is a "never reset" encounter zone -- no tweak is needed because what the mod is supposed to do already happens by default.
And the puzzle is managed by scripts anyway. The three gates might all close because they're timed, but a trigger after the last one re-opens them setting the dunUstengravQST to stage 50. BTW, I notice that said trigger is very close to the last gate. It's just a hunch but I'd move it farther away to give some extra time to the puzzle scripts to "settle". Actually, I'm going to do it in my game, just in case.
Or maybe you have one of the fashionable script "optimizers" messing with the dunUstenPuzTrigSCRIPT.
Hi, Thanks for the reply. It's weird, I've never had this glitch before. Hah! I had one mod that changed something in the Riverwood area, which in turn made the final chamber in Ustengrav totally inaccessible. I do have two other packages which I've been using for sometimes and without issue, Vanilla Script microOptimization (not sure if this effects scripts in Ustengrav) and Dungeon Revisited (which does make extensive changes to Ustengrav).
Give Feedback
216 comments
As stated in the description, this mod should be loaded near the top of the load order; any mod editing the same records for its own purposes should be allowed to 'win' the conflicts.
The conflicting records will miss the 'no respawn' flag (with a basic knowledge of SSEEdit you could carry it over), but this can't be avoided without patches.
This makes sense when installed before having cleared the three dungeons -- they're designed to be played following the regular path and going the "wrong" way isn't good.
The extra activators start working only when you exit the related dungeon right after having cleared it.
For example, if you clear Raldbthar with this installed but don't have the attunement sphere at the moment, when you later enter Blackreach from Alftand you can open the Raldbthar lift from below.
Quite possible, I quit updating USSEP since it started to require AE.... sometime later I also quit playing Skyrim.
That specific reference is indeed useless in the mod because it's flagged "open by default", but its presence is a consequence of having made the mod via xedit scripts.
I'm not that crazy as to manually check a thousand records one by one :)
I made a quick compatibility patch just copy/pasting No Respawn flag for that door (https://i.imgur.com/AWkPTMR.png): https://easyupload.io/1ze3xm
Hopefully I didn't break anything...
Feel free to include it in the mod if you want to (or your own patch, I imagine for the "full", not just dwemer-only, version it may need a lot more compatibility edits when it comes to CC conflicts). I think FOMOD has a feature where it can detect the presence of plugins (like ccASVSSE001-ALMSIVI.esm) and enable it by default then. Thanks!
This happened because I used a script to batch-edit the references instead of manually checking (and losing what's left of my sanity) thousands of records.
The best way to fix the conflict is removing the form from the mod (which is what I've done in the update.)
@TorinCollector: Since the mod now doesn't even edit that record anymore (the record that was also edited by the AE content and thus created a conflict) it's compatible with and without AE. So to answer your question it doesn't require any AE but if you have AE content it now doesn't conflict with it anymore. Best of both worlds.
I have a question though: you added "XLRL - Location Reference" records, but I have one .esp that doesn't forward - like vanilla.
Is it important? (I couldn't figure out... Are XLRL merged at runtime?)
XLRL are inside Form ID like '00098101' 'Placed Object'... ShimmermistCaveLocation for exemple
Since they come and go without any visible in-game effect, and they don't exist in the original game plugins, I'm pretty sure they're totally useless.
I use the patch for 1.5.97 myself, but I'm pretty sure they are the same in any version.
Anyway, if the button is active by default or made active by solving some puzzle that doesn't reset, it keeps opening and closing the gate.
If the button is made active or inactive by some puzzle that resets, you'll probably need to solve it again.
I suppose that when it stays open because of this mod you see the same.
But your guess is as good as mine; I've never used
dild-dyndolod and don't know what it actually does.I'll tell you next month when I'm back home.
Maybe a more detailed description of what happens could give me some ideas.
But I suspect that unless it happens in my own game, it will be nigh impossible to fix.
Reported lift error with menu solution
ACTIVESCRIPT
Attachment ID: null
Attachment element: None This thread is attached to an instance from Skyrim.esm.
ScriptInstance: blackreachExitElevatorScript: *000ef7ba (00000206e226eec0) ID: 00382d55
Type: 00
Version: 0.1
Unknown (var): INTEGER:1
Flag: 00000002
Unknown1 (byte): 00
Unknown2 (int): 00000000
Unknown3 (byte): 00
FragmentData (struct): null
Unknown5 (byte): 00
link:
SCRIPT blackreachExitElevatorScript extends ObjectReference Contains 1 member variables, 0 were inherited.
There are 6 instances of this script.
- blackreachExitElevatorScript:*000ef7ba (00000206e226eec0)
- blackreachExitElevatorScript:*000ef79b (00000206e1c3e980)
- blackreachExitElevatorScript:*000ef933 (00000206e39135c0)
- blackreachExitElevatorScript:*000ef7b8 (00000206e1c3fe80)
- blackreachExitElevatorScript:*000ef7b9 (00000206e22d4ac0)
- blackreachExitElevatorScript:*000ef7aa (00000206e20a9100)
There are 0 references of this script.I'm not sure if this helps track down the cause of the lift bug. I also noted that in the time it took to make one manual save, the system made about two dozen autosaves. Presumably in response to an attempt to change cell location Blackreach to Skyrim.
I meant an overload of many active or suspended instances of the same script, not just one.
You see that in the left pane expanding Active Scripts and Suspended Stacks.
'save on travel' in game settings. The lift animation now completes and control is returned to the player, without the bug (link in my second
reply). This is obviously not a fix, but a work around. Maybe there would be a way to complete the autosave before or after the lift
animation.
@edit: Scrap this idea, it certainly worked the first time, but not everytime. I did find an easier way to interrupt the bug, by pulling up the wait timer. Thanks for your help and patience with me, perhaps this will help others.
I even bothered to remove all the scripted ones :)
And the puzzle is managed by scripts anyway.
The three gates might all close because they're timed, but a trigger after the last one re-opens them setting the dunUstengravQST to stage 50.
BTW, I notice that said trigger is very close to the last gate.
It's just a hunch but I'd move it farther away to give some extra time to the puzzle scripts to "settle".
Actually, I'm going to do it in my game, just in case.
Or maybe you have one of the fashionable script "optimizers" messing with the dunUstenPuzTrigSCRIPT.