Hi, if you are fixing various scripts there's one bugged during MQ105. Involving the trap marker on the ground that opens and closes the gate.
Disclaimer: I do use vanilla scripts optimized mod. Maybe, worth a check anyways.
This is the quest involving the greybeards where you are supposed to dash through. But after that, my save log had many instances of MQ105 trap script, forgot exactly what it's called. This was months ago, I fixed it by terminating that script.
I haven't had that happen to me before. I can potentially take a look, but I'll need to know which script is it exactly. MQ105 is a very broad term that expands both The Way of the Voice and The Horn of Jurgen Windcaller quests and you use Whirlwind Sprint at least twice across both quests. If you still have the save, you can send it over and I'll see what I can do.
I don't have the save, as it was months ago... but I did find the script in question. I'd made a copy in overwrite.
MQ105SprintTriggerScript
The issue happened during the part where greybeards tells you to sprint through the gate, during the way of the voice quest. Anyways it created 70 instances of that script after that part, persisting for a long time. They had to be manually terminated.
Yeah I'm getting that issue to for some reason. Resaver told me says it has 366 occurances. How could I go about fixing that if necessary on my own. It's a new save but it happend in another playthrough as well.
I have to say, your timing is interesting Ketenn, as I've been investigating that script in the last couple of days lol. I was able to reproduce the bug and I'm currently working on fixing it. So far I've managed to significantly reduce the chance of it happening, but it can still slip up for some reason that I'm still trying to work out. Hopefully I'll be able to release the fixed script in the next few days.
If you want to clean up that script yourself, you can do so by terminating every active version of it in ReSaver, but that will only shut down currently stuck instances of it and it might come back again eventually.
Pro tip for when the changelog takes a while to appear: go to files, click on the version number of the latest file and it will show you the changelog for that version.
LOTD is the only one I've come across, during the Rkund excavation, but there may be more. Just to be clear, I'm not taking shots at LOTD with this mod, sometimes these things happen and it's better to have contingencies on the script itself in case other mods use it in the same way.
Hard to say. I don't know which mods may be using the script in this way. It won't hurt your game even if you don't need it though, so you can look at this mod as extra precaution.
I figured out a workaround that should assure functionality identical to the vanilla script with a very minimal function call cost. Here's the modified script file, I used version 1.0 of your script as the base for my modifications. I'll explain the changes I made below.
Since as far as I could tell the only problematic situation was when the state of the seal was changed while the seal was disabled, I added a flag to track when this happens. The flag starts as false, and is set to true if ReleaseSeal() or RestoreSeal() is called while the seal is disabled. Then in OnUpdate() I modified the conditions so that the loop won't exit while the flag is true, updating every 1.0 seconds. If during an update we find the seal to be enabled, the flag is set back to false. If the flag is false the script functions exactly like in 1.0.
Of course this means that the script will continue updating indefinitely if the flag is true. To counteract this I added an OnCellDetach event that calls UnregisterForUpdate if the flag is true. This ensures that while the updates will be happening when the player is in the same cell as the seal that was toggled while disabled, they will stop when the player leaves the cell, and start again when the player re-enters the cell. I personally think this is an acceptable tradeoff, as it's quite unlikely any mod would do something like this in the first place.
Here's an example flamegraph while in the same cell with a seal that was released while disabled:
And here's a graph after leaving the cell:
I also made sure that the script still stops updates retroactively when installed on an ongoing save.
LGTM, nice work. I wanted to avoid using OnCellDetach in case the seals are used in a worldspaces where it can be unreliable, but the chance of that being the case is minuscule for a case that is already highly unlikely to happen to begin with. Will see if I can optimize this a bit more and upload it as a new version. Thank you for the help! :)
During my testing of the werebear script fix, sometimes the update wouldn't get unregistered when OnCellDetach is called, I'm not sure why. My theory is that it's not thread safe as it was happening if OnUpdate gets called at the same time as OnCellDetach. Also the CK wiki mentions that this event is not reliably called between multiple intervening OnCellAttach events, so I tend to avoid it for worldspaces if possible.
Oh right. Yeah it isn't thread safe if the OnUpdate makes external calls, unlocking the script during the execution of the event. But in this case the OnUpdate doesn't do any external calls, so it shouldn't be an issue afaik.
Regarding the event not being reliably called between multiple intervening OnCellAttach events, I think is also threading related. If there is a OnCellAttach event that locks the script, and more OnCellAttach events are queued while the script is locked, there is no guarantee that the OnCellDetach events that were queued are processed in the order that they were queued, since there generally is no guarantee of the processing order of queued threads. That would make the most sense to me at least.
With the werebear script I think the issue could have been that OnCellDetach only fires if the cell the NPC is in detaches. If the NPC itself moves into a detached cell, OnCellDetach won't fire, but instead OnDetachedFromCell fires.
No, I'm pretty sure the NPCs were not moving to a different cell, but the OnUpdate was calling global functions, which counts as an external call based on the reference you sent, so that was most likely it. In any event, you've been very helpful, thanks! Kudos. :)
I've further expanded on your changes to support initially disabled doors and doors which were reenabled if the player left the cell with the door disabled, returned and then tried to unseal it before enabling it, which with the vanilla script would make the door unusable even when enabled again after that point. Also restored the opening and closing animations if the door is enabled after being toggled to make it less jarring and simulate the usual seal behaviour. Will upload it as a new version soon.
I actually thought my script already supported initially disabled doors. The other things I purposefully left out since I only targeted vanilla behaviour.
Well, your changes support initially disabled doors but only to an extend, sorry I wasn't fully clear on that. The vanilla behaviour is broken if the door is disabled, the cell gets loaded, the seal gets toggled and then enabled, which won't activate load doors, so it is an issue. As for the animations, it looks nicer with them and simulate the door waiting to get enabled again if its state is changed in the meantime, so why not. Still, I appreciate your vanilla commitment on that.
> In the vanilla game this works perfectly fine Please stop bashing devs for your modding desire. Which is allowed by Betheda's engine. Games works perfectly without any mods.
If they don't open the source engine of this game. This whole community doesn't exist anyways and this game is dead. Probably we are at The Elders Scroll X or XII by now if Bethesda get the same attention they got by letting everyone on this game
It's not like the Dev's have time to design contingency plans for mods while working on the game. If you read the description page, it is noted that the vanilla script runs just fine on the vanilla game. Zero issues. It is mods that break the script. So it's not the Developers fault for the script being broken. The fault really lies on the mod itself.
yes it's entirely the mods fault Bethesda can't plan for every mod and quite frankly i haven't found any mods that i use regularly that breaks the script anyway mod auhtors often seem to actively avoid breaking vanilla scripts so maybe stop bashing the Devs they even say in the mods category in game that they are not responsible for any problems you may run into while using mods if you think you can do better then you make a game it's not easy and devs are literally incapable of having contingencies for everything bugs glitches and mods breaking scripts are inevitable deal with it
First, thank you for your work! Full disclosure, I play on LE not on SE - and I did recompile with the external compiler just to be safe, although that probably wasn't necessary. Both here and on your werebear script fix, I found that your updates detected and fixed things up for me. I had several questions, but reading through the other comments and your replies answered all of them. In my case, I had two scripts on doors from LotD that were waiting for update, over and over... that have been doing that for months since I had not been in the LotD Ruins of Rkund for a very long time.
Thank you again, not only for the fix - but also I learned a few things looking at this this morning, in large part because of the great way you have responded to many of your comments! Kudos! Endorsed! Now... I am off to review the output from the DumpPapyrusUpdates (DPU) console command that I learned today, to see what else might surprise me in my LE game.
You're welcome, glad to be of help! Thank you for the endorsement and kudos. Can't say I've heard of this console command myself, but I may find use for it. :D
Just a suggestion. It might be worth packing the script into a BSA and including an empty ESPL file to load it incase some other mod also includes a changed version of this script for whatever reason. Otherwise the game will ALWAYS load the loose file and it could break things and unless the user opens up that other mods BSA they would likely have no idea what went wrong.
I'd like to avoid unnecessary ESPs for people on VR which doesn't have light plugin support. Furthermore a BSA for a single script is a bit of a waste, as well as being more annoying to manage in case of conflicts.
That's understandable but its also important for people to understand the risks involved in using loose script mods like this. Regardless, I'v said my peace. What you do with your mod is ultimately up to you and you don't have to justify yourself to me or anyone else.
=== edit === But if it were me, I would expand on the compatibility notes to warn people who may not know how these things work.
If this is a real concern, there are plenty of ways to view or extract the contents of a bsa. As you say, loose files always win. Mod users need to know what they are installing, whether it is a loose file or packed in a bsa.
82 comments
Disclaimer: I do use vanilla scripts optimized mod. Maybe, worth a check anyways.
This is the quest involving the greybeards where you are supposed to dash through. But after that, my save log had many instances of MQ105 trap script, forgot exactly what it's called. This was months ago, I fixed it by terminating that script.
MQ105SprintTriggerScript
The issue happened during the part where greybeards tells you to sprint through the gate, during the way of the voice quest. Anyways it created 70 instances of that script after that part, persisting for a long time. They had to be manually terminated.
If you want to clean up that script yourself, you can do so by terminating every active version of it in ReSaver, but that will only shut down currently stuck instances of it and it might come back again eventually.
But yes, it's safe to update mid game.
Since as far as I could tell the only problematic situation was when the state of the seal was changed while the seal was disabled, I added a flag to track when this happens. The flag starts as false, and is set to true if ReleaseSeal() or RestoreSeal() is called while the seal is disabled. Then in OnUpdate() I modified the conditions so that the loop won't exit while the flag is true, updating every 1.0 seconds. If during an update we find the seal to be enabled, the flag is set back to false. If the flag is false the script functions exactly like in 1.0.
Of course this means that the script will continue updating indefinitely if the flag is true. To counteract this I added an OnCellDetach event that calls UnregisterForUpdate if the flag is true. This ensures that while the updates will be happening when the player is in the same cell as the seal that was toggled while disabled, they will stop when the player leaves the cell, and start again when the player re-enters the cell. I personally think this is an acceptable tradeoff, as it's quite unlikely any mod would do something like this in the first place.
Here's an example flamegraph while in the same cell with a seal that was released while disabled:
I also made sure that the script still stops updates retroactively when installed on an ongoing save.
https://www.creationkit.com/index.php?title=Threading_Notes_(Papyrus)
Please stop bashing devs for your modding desire. Which is allowed by Betheda's engine. Games works perfectly without any mods.
Edit: nvm i just need to open my eyes :)
Thank you again, not only for the fix - but also I learned a few things looking at this this morning, in large part because of the great way you have responded to many of your comments! Kudos! Endorsed!
Regardless, I'v said my peace. What you do with your mod is ultimately up to you and you don't have to justify yourself to me or anyone else.
=== edit ===
But if it were me, I would expand on the compatibility notes to warn people who may not know how these things work.
Read carefully op's post.
Specially about conflict resolution and more on this further.