0 of 0
File information
Created by
KirbonatedBeverageUploaded by
KirbonatedBeverageVirus scan
Safe to use
videogame_asset My games
Install hundreds of mods with the click of a button.
Notifications
-
Give Feedback
166 comments
I am wondering (and this is something we often see when troubleshooting games for people in the Steam forums), if, in fact, it is possibly some other mod which is causing the results that you have shown, and not the script by tarlazo? And, if your testing was done on a completely vanilla game so as to ensure that nothing else could be causing this? Because, if it is the tarlazo script at fault, then, as I stated, these issues should appear in my game, or in anyone else's game who has tarlazo's script.
Anyway, thanks for your checking into this issue - anything that advances our knowledge of the game and how it works is greatly appreciated!
The issues should appear in any game using the script, based on my knowledge. The script shouldn't be able to be read by the game because of the programming error.
Not only shodiffern issues appear in every savegame, the fix can't even work to begin with the way it's written.
they assign onUpdateGameTime as a function, which is invalid, as described in the post, but even if it weren't invalid, the script would never fire because they never invoke the function anywhere in the script.
In short, the possibilities are:
1) you have some mod overwriting dragonactorscript besides tarlazo's fix
2) You have some mod that changes dragons to use some other script instead of dragonactorscript
3) You have been experiencing the issue, but you aren't using enough script mods to notice the symptoms (this also makes it easier for the stacks to get cleared out)
4) the version of the fix in the reupload is somehow different to version that I compared to (version 2.0.1 obtained from Tarlazo's original nexus page, before it was deleted)
As much as I would love to be wrong here, I fail to see any way that tarlazo's script could possibly be functional
"I don't see any harm in the code change, [...] events may trigger functions, and functions may trigger events. But MA's explanation that it causes stack overflow doesn't make sense at all...."
See: https://steamcommunity.com/app/489830/discussions/0/154643795211522292/?tscn=1631535113#c3038230013036827733
And I have checked and compared all three scripts - the version I am using, the re-upload, and yours. As I stated, I am extremely thorough - I could not run the builds, nor give the help on the forums I do, if I were not.
I have to ask again, though - even at the risk of seemingly being impertinent (which is not my intention at all - I have the utmost respect for people who attempt to make the game better through their work in modding it), did you test this on a purely vanilla game?
"4) the version of the fix in the reupload is somehow different to version that I compared to (version 2.0.1 obtained from Tarlazo's original nexus page, before it was deleted)"
As I had stated, I was using tarlazo's version that he had removed - and not the reuploaded version - (though it is version 2.0.0, and not the 2.0.1 that you state you had). I compared all three versions tarlazo's, the reupload, and yours. Yet, if you had checked the reupload, you would know it is essentially the same - yet here you state that there may be a difference - which leaves me to wonder if you had checked the reupload? Which, with all due respect, makes me wonder about other things - such as how exactly you tested this.
In my original playthrough many years ago, before I had ever added any mods in (amazing as that may seem compared to now - LOL!), I did experience the dragon stalking bug once. Now, while a negative does not necessarily prove anything, since I started using the fix when it was first released years ago, in the thousands of hours since, I have never suffered the bug, nor have I ever experienced the lag you are referring to - not in my script heavy 2233 mod build having 1638 plugins, nor in the the script heavy one before it having 1535 mods and 1103 plugins, nor in any of the other extreme builds I have run - all of which are and were totally stable and CTD free. Nor have any of the others who I have spoken to encountered this, nor have we seen this issue in the forums as pertains to tarlazo's version of the script.
I do not wish to sound harsh or argumentative, so I certainly apologize if it seems that I may appear so, but we do (all too often), in the Steam forums, see errors where people wrongly attribute certain things to a certain mod when, in fact, the problem actually lies elsewhere - one such frequent incident being people wrongly attributing bugs as being caused by the Unofficial Patch, when, in fact, it is caused by another mod and due to the fact that they did not test on a vanilla game. What we do in the forums, those of us who are frequent helpers, is to try and ensure that information is 100% accurate, and to determine if what is being stated as the problem, actually is the problem - and not something else.
Thanks :)
I jumped the gun significantly when I made the original claims in the mod description, and for that I deeply apologize. Further testing has revealed that the stack overflow doesn't appear to occur in an otherwise unmodified game. I will be updating the mod description and stickying this post.
All that said, tarlazo's script was still broken. Even if it isn't causing a stack overflow, it's still not valid to call OnUpdateGameTime() as a function. The way its written, the part of the code that is meant to prevent dragon stalking will never actually run in tarlazo's code, since the function they defines as "OnUpdateGameTime()" is never called in the script.
I am still investigating the cause of this stack overflow, because it has been driving me crazy. Changing this code DOES fix the issue in my game, which leads me to believe that it is somehow involved, even if it is not necessarily the root cause.
"I don't see any harm in the code change..."
So, it may be, Blackspipne, but I am not convinced, nor are others, that there actually is a problem caused by tarlazo's mod and that this is not an issue caused by some other conflict - but I myself have not tested this mod and so cannot personally recommend it - especially since, as far as I can determine, the alternate fix does work. Others will, no doubt, be able to state if it works in their game - I personally, just cannot comment as to that.
Let there be no doubt about it - I am not criticizing KirbonatedBeverage's work so much as myself and others are wondering if what is being shown is really caused by a scripting error in tarlazo's original work, as re-uploaded by fairkauri, or if the issue is caused by something else. So far, the consensus is that this issue is caused by something else.
I apologize if that is not clear enough, but that is all I can say barring any further information.
And, thank you for being so patient with reading my posts - I can be long winded at times, so patience is definitely a virtue!
And, a kudos to you for taking the time to do all this! Just added one!
On why I feel like a buffoon, I feel like I should know better since I made sure to test multiple load orders when I created Hand to Hand Rebalanced, but did not do so here. I'm metaphorically slapping myself for making a mistake that I so often critique others for making.
I am saying this because the author mentioned that SKSE cleans the stacks eventually (and I always save after killing a dragon because I have the difficulty of those encounters very high) and if this was the case, I am sure I will have seen the problem at some point. Also, because smr asked for personal experiences regarding this ¿issue?.
Thanks to you two for engaging in productive discussions. Kudos.
While I have some suspicions about the cause, I don't feel comfortable sharing them because my previous suspicions turned out to be incorrect, at least partially, if not wholesale. Once I can concretely prove a cause, and replicate the stack overflow in multiple load orders, I'll update the mod page with the information.
event OnInit()
endEvent
function OnInit()
endFunction
It's just a way of making the purpose of a function more clear to the reader. This fact makes this fixed fixed version redundant. However, I can agree with your sentiment that there's a lack of documentation surrounding this.
When I originally read through the documentation, my interpretation was that while Events and Functions are similar in construction, the compiler treated them differently. Upon re-reading said, I can now see how they are treated the same by the compiler.
https://winmerge.org/
If both pex files result in the same code, then you know the papyrus compiler will treat "function" and "event" in the same way. This method could also be used for other things, to understand whether changes to a script's syntax results in the same or different code.
The problem appears to me to be an engine problem related to how actor scripts are loaded. It seems that the code that loads actor scripts checks for a script instance for the target actor on every frame, and if it doesn't find one, it attempts to load the script. The problem with this is that it doesn't check suspended script stacks, so if the game can't load the script immediately due to high script load, the game will generate a new actor script instance on every frame until one successfully load, typically resulting in hundreds of generated script instances. Most of the time, actors with scripts attached to them are in interior cells, where your active script count is dramatically lower, so you don't notice the issue, but dragons and wispmothers can be found in exteriors, and dragons can be found in very busy areas, so most people only notice the issue with dragons. The wispmother loop is worse though, since it consistently causes the game to crash after a few seconds.
Thanks for this mod
Disclaimer: Everything below is all conjecture, and entirely driven from my personal experience. I don't know how the engine handles scripts and am basing this purely on observation. Everything I say here could end up being false.
Honestly there doesn't seem to be a good actual fix for the Dragon Stalking bug, as I'm beginning to suspect that the true cause has little to do with the dragon scripts themselves and more to do with how the game handles excessive active script counts. The actual "Dragon Stalking" seems to be related to the behavior that allows dragons to follow you in and out of cities (since those cities are technically completely separate worldspaces from the actual skyrim exterior. I think that in games where there are a lot of active scripts, the dragon script can get incorrectly suspended, leaving the dragon in a broken state. It should also be noted that in every save game where the dragon stalking glitch occurs, there are hundreds, if not thousands, of suspended dragon script stacks.
The problem seems to be that the game continually queues up the associated script for a loaded actor until it loads successfully, gradually overflowing the stack buffer. I have noticed similar stack overflow issues with other types of actorscripts, such as the scripts for Wispmothers. This means that the only real solution is to not use mods that make heavy use of the papyrus quest scripts. But even that probably won't work as the vanilla civil war quests are script heavy enough to potentially fill the active script count. To truly fix this issue we would probably need an SKSE mod that alters how the game loads papyrus scripts, likely by arbitrarily increasing the active script thread limit.
Good read! I reckon get in touch with Fudgyduff, Meh321, powerofthree, MaskedRPGFan, maxsu2017 and/or Doodlezoid. These are the guys who I've found are usually really good at this Jazz. KernelEgg? is also good as well. He did Scrambled Bugs. Chat to these guys about this problem, they're kings as SKSE.
I would really appreciate a list of potential culprits if you ever end up finding them, and thank you for your work.
To clarify, the dragon stalking is related to a function in the dragonactorscript, specifically the function that allows dragons to follow you in and out of cities. The thing is, I don't think the script getting stuck and overflowing the stack buffer has anything to do with the scripts themselves.
The one constant with the dragon stalking bug is that the more heavily modded your game is, the more prevalent the mod seems to become. Specifically, the more mods you have that load Papyrus quest scripts into the game, the more likely you are to get the bug.
Another fact I've noticed is that these buffer overflows are not limited to dragonscripts, rather they occur with any script that is loaded alongside an actor (such as Wispmothers). This implies that the cause is related to how the game loads actor scripts. I every frame an actor is active, the game checks to see if it's script is loaded. If the script is not loaded, it attempts to load the script. The problem is that it only seems to check the active script threads, not the script buffer. This means that if there are too many active papyrus scripts loaded, the game will continue queue up script instances on every frame until one of them loads.
TLDR; I think it's an engine issue related to incorrect handling of the script stack buffer.
No it did not. Killed some Dragon 2296 DragonActorscrips stacked up
Can it even work in Skyrim VR? :)
Also, I just killed Sahloknir with delphine, after I had the conversation with her and walked away just a few steps, I turned back and the corpse of the dragon is gone. Is this normal? I set my timescale to 10 and it take me almost 3 minute to finish conversation with her(I didn't skep the dialog). If the dragon corpse disappear so fast, if I stay there more then 3 minute, would the corpse just disappear right in front of me?
although a good point is that the mod author does say this is not a fix for the stack overflow so keep an eye out for its possible return
So, well, thank you for your effort and for sharing your deep programming knowledge :)