PepperDog017 Posted August 26, 2019 Posted August 26, 2019 So, I have searched this topic high and low -- here, Reddit, Nexus, Google, any random website, etc. with lots of information on this topic, none of which has been particularly helpful. Let me preface by saying I am not specifically looking for a diagnosis of my load order. I am hoping to advance my modding knowledge and hopefully learn what causes/why "Random" CTDs happen so that I might help myself to fix them whenever they occur. Yes, my current load order does have what appear to be completely random CTDs. Sometimes I can play for many hours with no problems and save/quit normally, occasionally I will crash within 5-10 minutes of play, usually I will CTD after about an hour or two. (Note that I am nearly certain this is NOT due to a bad asset/texture/mesh file). Per the Skyrim SE conversion tracking thread: Random CTD • Too many animations. Try to stay below 10k. • Could be anything. Or nothing. You might be screwed. Sorry. • Get a stack trace with .NET Script Framework for hints. Too many animations: My understanding was these would generally be CTDs at save/load. Is it true that these sorts of CTDs may also occur randomly while just running around the map? Could be anything, Or nothing: is it true to say there are just so many possible reasons for random CTDs, that discovering the source is a "finding the needle in the haystack" sort of thing? While most reports I see suggest that Skyrim SE is very stable. Is it possible random CTDs can be due to "nothing"? Or, they may be simply due to pushing the game/gfx/scripting engine too hard? Or, perhaps a previously undiscovered hardware issue (this idea has crossed my mind *many* times)? I have reached the point in my modding journey where I am thinking the best course of action is to nuke my entire Skyrim SE install and simply start over, and use an absolutely meticulous approach when re-building. The old disable half, play until crash, disable half, etc. etc. routine -- is that the best approach to diagnosis? I mean, with truly random CTDs, how is it possible to know for certain you've found the batch of mods the crash is coming from? It could be extremely time consuming to truly narrow down random CTD causes with this approach! Sorry if this might be a little rantish. I eagerly await any wisdom any Skyrim SE experts can provide...Thanks in advance!
Psalam Posted August 26, 2019 Posted August 26, 2019 11 minutes ago, PepperDog017 said: So, I have searched this topic high and low -- here, Reddit, Nexus, Google, any random website, etc. with lots of information on this topic, none of which has been particularly helpful. Let me preface by saying I am not specifically looking for a diagnosis of my load order. I am hoping to advance my modding knowledge and hopefully learn what causes/why "Random" CTDs happen so that I might help myself to fix them whenever they occur. Yes, my current load order does have what appear to be completely random CTDs. Sometimes I can play for many hours with no problems and save/quit normally, occasionally I will crash within 5-10 minutes of play, usually I will CTD after about an hour or two. (Note that I am nearly certain this is NOT due to a bad asset/texture/mesh file). Per the Skyrim SE conversion tracking thread: Random CTD • Too many animations. Try to stay below 10k. • Could be anything. Or nothing. You might be screwed. Sorry. • Get a stack trace with .NET Script Framework for hints. Too many animations: My understanding was these would generally be CTDs at save/load. Is it true that these sorts of CTDs may also occur randomly while just running around the map? Could be anything, Or nothing: is it true to say there are just so many possible reasons for random CTDs, that discovering the source is a "finding the needle in the haystack" sort of thing? While most reports I see suggest that Skyrim SE is very stable. Is it possible random CTDs can be due to "nothing"? Or, they may be simply due to pushing the game/gfx/scripting engine too hard? Or, perhaps a previously undiscovered hardware issue (this idea has crossed my mind *many* times)? I have reached the point in my modding journey where I am thinking the best course of action is to nuke my entire Skyrim SE install and simply start over, and use an absolutely meticulous approach when re-building. The old disable half, play until crash, disable half, etc. etc. routine -- is that the best approach to diagnosis? I mean, with truly random CTDs, how is it possible to know for certain you've found the batch of mods the crash is coming from? It could be extremely time consuming to truly narrow down random CTD causes with this approach! Sorry if this might be a little rantish. I eagerly await any wisdom any Skyrim SE experts can provide...Thanks in advance! You're right about the animations and CTD. If you have too many it shouldn't load at all (or load and CTD). Look here for the latest on this topic: Make sure that you have the appropriate stability tools. Fortunately for SE all you need is: https://www.nexusmods.com/skyrimspecialedition/mods/17230 Which, in turn, requires SKSE64 (always the most recent version). Most of the rest of "random" CTDs tend to be due to corrupted meshes. This requires figuring out which mod(s) are trying to load said meshes and can take some work. When they occur at the same place it's generally easy - find the mods that impact that place and eliminate them one at a time until the problem is resolved. Unfortunately, it isn't always that simple. Recently More Nasty Critters (MNC) on the LE side, had issue with horse cocks. Thus, whenever you went near a horse the game crashed. This wasn't always easy to diagnose since there are horses at stables consistently but they can be found in Random Encounters as well (Noble and Guard, Peddler, etc.). So, it can be quite difficult to sort that out. Skyrim won't "just crash." You have to not do the footwork to get your game stable. If you tax your game too much you can cause issues but with effort you can have a large load order and play consistently without CTD.
PepperDog017 Posted August 26, 2019 Author Posted August 26, 2019 Thank you for your post Psalam! I am reviewing your blog on CTDs, and while it is written for LE, it still has quite good information. Thanks especially for this: 42 minutes ago, Psalam said: Skyrim won't "just crash." You have to not do the footwork to get your game stable. If you tax your game too much you can cause issues but with effort you can have a large load order and play consistently without CTD. which was my suspicion. I just couldn't help but think -- have I just pushed the engine too far? Is my hardware showing previously unknown instability? But it must be user error. I had a seemingly stable build some months back. I had put the game down for a while, recently returned, got everything updated that needed it (SE x.80, SKSE x.16, all DLLs, mods, etc.) and am now in random CTD land. Unfortunately, it would be nearly impossible to revert back to a last known good build at this point in time -- which is why I felt nuking everything and a completely fresh rebuild (as painful as that may be) might just be the best approach. And perhaps even less time consuming than a binary search for the possible causes. Anyhow, I am reading you blog and will be back to discuss further. I guess my original intent was to get it in my head that Skyrim doesn't just crash -- "99% of all problems (in modded Skyrim) are user caused."
Fotogen Posted August 26, 2019 Posted August 26, 2019 16 minutes ago, PepperDog017 said: .. got everything updated that needed it (SE x.80, SKSE x.16, all DLLs, mods, etc.) and am now in random CTD land. Unfortunately, it would be nearly impossible to revert back to a Also had lots of CTDs when I swithed to x.80. My solution was to let Steam "verify local game files". Steam didn't do much. I did noticed I got "new" .ini files (skyrim.ini and stuff). Not so much new as "vannila". I did solved my CTDs. Perfectly stable after that.
Guest Posted August 27, 2019 Posted August 27, 2019 It can indeed be anything, because computer (programs) crash, when they encounter something unexpected, which (!!!) can be anything. Therefore, knowledge of what can cause crashes won't help you much in solving them (though, it can help with not causing them in the first place, as i.e. certain ini-edits not being a good idea - but that's got nothing to with buggy mods or incompatibilities between them.... or the installation instructions just being a mess, cause freeware needs to be "lawful", and so instead of mods being packaged in a way that is easiest, they're packaged into a dozen dependencies to be "lawful"). Sorry, trailed off a bit there. What's most useful IMO is learning how to MANAGE your mods (and savegames!) in a way, that costs you a minimum amount of time and lost playhours, when something bad happens. I mean, lets be honest here: Skyrim modding is as big as it is a mess, so mistakes will happen, and they might not even be your fault. My point is: Instead of focussing on avoiding crashes and savegame corruption, expect and be prepared to deal with them. And for that i have a few golden rules: 1. Manage your mod-archives. Keep the archives of your mods stored and sorted in a seperate directory, and always keep at least two versions (i.e. the one you're evaluating/running now, and the one that worked in the past - this way you can rollback, cause in the year 2019, don't expect fucking developers to provide downloads for even the version they released yesterday, when they got a new one today, which they believe to be "the bestest thing ever"). If you apply texture-patches, keep those also as archives. 2. Use modmanager and make every single mod/patch a seperate package - NO MERGING EVAR! Ideally your archives described in #1 should be like a mirror of your modmanager packages (plus one version back, as described). The reason this is so important is: If you just have one big mess (like people who prefer to throw everything into the data-dir), then if something ever goes wrong, it becomes a nightmare to selectively work on individual mods. I.e. you if you threw all body-mods into a single package, i promise you if you ever got a problem with the body, you will end up breaking it even more, and after hours give up and reinstall all body mods from scratch - trying to remember which order was the right one). If everything is its own modman package instead, you can selectively and cleanly enable, disable, down- and upgrade individual mods and patches. 3. Install one mod at a time, and test its features for at least 1 hour. Yes, that means if you want 100 mods, you can expect over 100 hours to install and verify them safely. Is this nuts? Yes. Is it bethesda-reality? Also yes. When a mod requires multiple dependencies you don't have yet, allocate even more hours to test that one. 4. The reason for #3 isn't just "knowing when something broke", but also minimizing the risk of savegame corruption. You see: Even if the beth-launcher or modmanager lets you do it, Skyrim is not designed to remove ANYTHING from a running game. You're supposed to only ever add stuff, and never remove/disable anything. If course that's not practical, but you need to understand Skyrim absolutely hates uninstalling stuff from a running game, in order to deal with it. So how do you deal with a broken-by-design modding infrastructure? Damage-Control: At least one new savegame for every mod you install. In combination with #3, this minimizes the risk of having to rollback dozens of playhours, because i.e. way back in february you installed a mod that turns out leaking zombie-stacks to infinity, and it cannot be safely removed (hey, i'm speaking from experience here - that happened to me (FY "Skyrim Jobs"). If you never looked into what's in a save, this might sound like hyperbole to you: Most of the time, you can just disable mods and skyrim complains, but then continues working normally? Wrong: Even if a mod offers an uninstallation-feature, that only takes care of the worst - trash will remain in the savegame, and by now you should be familiar, with beth's distaste for 32-bit integers. Translation: That "trash" might not just cause incompatibiilities down the road, but also contribute to hitting limits (i.e. there was a limit on the max numbers of text-strings - not sure if it's still there in SSE). What i'm trying to say here is: Consider mod-removal something that's "expensive" and "risky" - never "free". Plan your game and mod-installations to minimize the amount of times you need to remove a mod (disabling stuff for testing is different of course, since you do that on a seperate savegame - right?).
PepperDog017 Posted August 27, 2019 Author Posted August 27, 2019 On 8/26/2019 at 2:04 PM, Fotogen said: Also had lots of CTDs when I swithed to x.80. My solution was to let Steam "verify local game files". Steam didn't do much. I did noticed I got "new" .ini files (skyrim.ini and stuff). Not so much new as "vannila". I did solved my CTDs. Perfectly stable after that. Interesting...my CTD mess started when I upgraded to x.80 (from x.62, I think...). I did actually regenerate all my inis (let steam re-downloaded fresh, stock ini files) but have since edited them a bit with BethINI. I don't suspect this is the issue, but thanks for that bit of info. I'll likely do another reset of all INIs once I've (yet again) revamped my load order. The foundation of my build is based on a STEP guide (https://wiki.step-project.com/User:DarkladyLexy/Lexys_LOTD_SE) -- my plan right now is to revert to 100% guide state to get a (hopefully) fully working install. And only then start the process of adding in all the more interesting mods from LL on top. I suspect my biggest mistake that has led me to CTD land is not thoroughly testing the base build, adding in all the LL mods on top, then bash/Smash patch/zPatch on the entire load order. In order to make this happen I had to not only liberally ESL flag, but also deactivate a number of mods for the final patching steps (Mator Smash and zEdit/zPatch unfortunately will not run on >255 mods). That said, I guess I shouldn't be surprised my build is "broken"!
PepperDog017 Posted August 27, 2019 Author Posted August 27, 2019 7 hours ago, lynak said: It can indeed be anything, because computer (programs) crash, when they encounter something unexpected, which (!!!) can be anything. Therefore, knowledge of what can cause crashes won't help you much in solving them (though, it can help with not causing them in the first place, as i.e. certain ini-edits not being a good idea - but that's got nothing to with buggy mods or incompatibilities between them.... or the installation instructions just being a mess, cause freeware needs to be "lawful", and so instead of mods being packaged in a way that is easiest, they're packaged into a dozen dependencies to be "lawful"). Sorry, trailed off a bit there. What's most useful IMO is learning how to MANAGE your mods (and savegames!) in a way, that costs you a minimum amount of time and lost playhours, when something bad happens. I mean, lets be honest here: Skyrim modding is as big as it is a mess, so mistakes will happen, and they might not even be your fault. My point is: Instead of focussing on avoiding crashes and savegame corruption, expect and be prepared to deal with them. And for that i have a few golden rules: 1. Manage your mod-archives. Keep the archives of your mods stored and sorted in a seperate directory, and always keep at least two versions (i.e. the one you're evaluating/running now, and the one that worked in the past - this way you can rollback, cause in the year 2019, don't expect fucking developers to provide downloads for even the version they released yesterday, when they got a new one today, which they believe to be "the bestest thing ever"). If you apply texture-patches, keep those also as archives. 2. Use modmanager and make every single mod/patch a seperate package - NO MERGING EVAR! Ideally your archives described in #1 should be like a mirror of your modmanager packages (plus one version back, as described). The reason this is so important is: If you just have one big mess (like people who prefer to throw everything into the data-dir), then if something ever goes wrong, it becomes a nightmare to selectively work on individual mods. I.e. you if you threw all body-mods into a single package, i promise you if you ever got a problem with the body, you will end up breaking it even more, and after hours give up and reinstall all body mods from scratch - trying to remember which order was the right one). If everything is its own modman package instead, you can selectively and cleanly enable, disable, down- and upgrade individual mods and patches. 3. Install one mod at a time, and test its features for at least 1 hour. Yes, that means if you want 100 mods, you can expect over 100 hours to install and verify them safely. Is this nuts? Yes. Is it bethesda-reality? Also yes. When a mod requires multiple dependencies you don't have yet, allocate even more hours to test that one. 4. The reason for #3 isn't just "knowing when something broke", but also minimizing the risk of savegame corruption. You see: Even if the beth-launcher or modmanager lets you do it, Skyrim is not designed to remove ANYTHING from a running game. You're supposed to only ever add stuff, and never remove/disable anything. If course that's not practical, but you need to understand Skyrim absolutely hates uninstalling stuff from a running game, in order to deal with it. So how do you deal with a broken-by-design modding infrastructure? Damage-Control: At least one new savegame for every mod you install. In combination with #3, this minimizes the risk of having to rollback dozens of playhours, because i.e. way back in february you installed a mod that turns out leaking zombie-stacks to infinity, and it cannot be safely removed (hey, i'm speaking from experience here - that happened to me (FY "Skyrim Jobs"). If you never looked into what's in a save, this might sound like hyperbole to you: Most of the time, you can just disable mods and skyrim complains, but then continues working normally? Wrong: Even if a mod offers an uninstallation-feature, that only takes care of the worst - trash will remain in the savegame, and by now you should be familiar, with beth's distaste for 32-bit integers. Translation: That "trash" might not just cause incompatibiilities down the road, but also contribute to hitting limits (i.e. there was a limit on the max numbers of text-strings - not sure if it's still there in SSE). What i'm trying to say here is: Consider mod-removal something that's "expensive" and "risky" - never "free". Plan your game and mod-installations to minimize the amount of times you need to remove a mod (disabling stuff for testing is different of course, since you do that on a seperate savegame - right?). lynak -- thank you. This is all excellent advice. I do already follow these golden rules to some extent, but haven't always. Honestly, part of the fun for me (and probably a good many others) is the building, modding, and testing process. But now I am ready to do an actual, perfectly working play-though (I've never actually "finished" Skyrim's main plot, or even any of the DLCs!). For this to be successful, I think I must take these golden rules to heart and follow them as absolutes. Since that hasn't always been the case up to this point, it is entirely possible my latest CTD problem is a direct result. (Part of my frustration -- as explained in my original post -- is some gaming sessions will be perfectly fine for hours, while others not so much. It's been totally random as far as I can tell.) Rule #1 - Definitely. I keep a separate hard drive with every mod I've ever downloaded on it. Many of them are now completely obsolete, but storage space is relatively cheap. As for Rule #2 -- this is something I have begun to do, but not always. How i wish I had always done this! I don't know how many total mods you have, or what is "typical", but my MO left panel is now up to 901 (!!!), and a good 25% of those are probably multiples merged into one (of course not all 901 are always active, and many are only asset files with no plugins). Bottom line is that it's far, far easier to manage your mods if every single install is it's own separate entry in the left panel (and of course use MO!). Rule #3 -- This is a tough one, with so many mods! My current build is 296 ESM/ESP/ESL files, along with 732 active in the left panel. I think it's high time to carefully review this. I am certain many of these can be eliminated, replaced, etc. (e.g. I have 10! left panel entries for Devious Devices, which could probably now be replaced with a singular DD All-In-One. Just one example. Although somewhat in contrast to Rule #2...) Rule #4 -- I am guilty of this for sure. I am familiar with and have used Fallrim tools more times than I can count (but not so much on this last save. In fact, I don't think I have cleaned it once since starting it -- no mods have been removed). So my plan is to re-create a fully working build, lock it in place, never touch it, and proceed. I am pretty much to the point of knowing exactly which mods I want to use, so hopefully no removals will be necessary (this was actually the plan for this last save -- to set in stone the final build. It was more or less a test build preparing for the release of LoTD v5.0, probably happening next month.) As for the string limit, I had done some searching on this some time ago and not totally certain if a conclusion was ever reached. Perhaps I should take a second look at this issue, since my last save has (@ PC level 30-ish): 87998 Strings 9588 Scripts 213494 Script Instances 109045 Change forms I have nothing to compare to, but I am sure these numbers are quite high (probably would be broken if an LE save?). Any thoughts?
Janik Posted August 28, 2019 Posted August 28, 2019 One thing that I recommend is to watch Nexus' "Last updated" dates for mods that you are using. If you have two mods that do similar things but ModA was last updated before ModB even came out, that may be an issue (Unless ModB has a compatibility patch for ModA). Mods that haven't been updated in years can often run into compatibility problems with brand new ones, especially when they do similar things. I used to have tons of random CTD problems until I re-evaluated every mod in my list and removed many that were redundant (How many weather/lighting mods do I really need?). Now my game runs solid *knocks on wood*. The CTDs I get now are my own fault, not random. ?
Guest Posted August 28, 2019 Posted August 28, 2019 15 hours ago, PepperDog017 said: Rule #1 - Definitely. I keep a separate hard drive with every mod I've ever downloaded on it. Many of them are now completely obsolete, but storage space is relatively cheap. As for Rule #2 -- this is something I have begun to do, but not always. How i wish I had always done this! I don't know how many total mods you have, or what is "typical", but my MO left panel is now up to 901 (!!!), and a good 25% of those are probably multiples merged into one (of course not all 901 are always active, and many are only asset files with no plugins). Bottom line is that it's far, far easier to manage your mods if every single install is it's own separate entry in the left panel (and of course use MO!). Rule #3 -- This is a tough one, with so many mods! My current build is 296 ESM/ESP/ESL files, along with 732 active in the left panel. I think it's high time to carefully review this. I am certain many of these can be eliminated, replaced, etc. (e.g. I have 10! left panel entries for Devious Devices, which could probably now be replaced with a singular DD All-In-One. Just one example. Although somewhat in contrast to Rule #2...) Rule #4 -- I am guilty of this for sure. I am familiar with and have used Fallrim tools more times than I can count (but not so much on this last save. In fact, I don't think I have cleaned it once since starting it -- no mods have been removed). So my plan is to re-create a fully working build, lock it in place, never touch it, and proceed. I am pretty much to the point of knowing exactly which mods I want to use, so hopefully no removals will be necessary (this was actually the plan for this last save -- to set in stone the final build. It was more or less a test build preparing for the release of LoTD v5.0, probably happening next month.) As for the string limit, I had done some searching on this some time ago and not totally certain if a conclusion was ever reached. Perhaps I should take a second look at this issue, since my last save has (@ PC level 30-ish): 87998 Strings 9588 Scripts 213494 Script Instances 109045 Change forms I have nothing to compare to, but I am sure these numbers are quite high (probably would be broken if an LE save?). Any thoughts? On a completely unrelated note about "memory is cheap": I always find it amusing when developers bring up that line, but don't understand the difference between HDD-space and Network-bandwidth/quotas, or HDD-space and HDD-speed, or HDD-space and RAM, or RAM and VRAM. Somehow in their minds, all types of memory become abundant, just because a few of them are. Meanwhile in reality, only HDD-space is cheap. RAM is "adequate", and everything is scarce and slow. Now with that in mind, what takes up the most space? Textures. What are they loaded into? VRAM, which is only 3-8GB for the whole game, and it needs to be streamed from a storage, that has millisecond latencies (translation: millions of cycles) even on SSD. Rule of thumb for all devs: All that "abundant" HDD space is only good for storing stuff (like keeping archives in your case). The actual runtime has 4-8GB at its disposal. All the other space is only usable for loading-screens and low-speed background streaming. #2 and #3: As much as i hate to be the "joykill" here, i'm afraid the ES-modscene has a consumer-behavior problem. Thousands of pretty looking mods to choose from, all for free, and if you don't like one, just pick another! It's consumer-heaven. Meanwhile, the game as a platform is the exact opposite: It's completely unsuitable for that kind of usage. But the former sounds so nice: Look at all those things i COULD have! Well yes: You can have them, and then will pay for it with a lot of frustration and lost playhours - just like everyone else. I was like that too at one point. But eventually the analyst in me did the maths: I was spending more time on fixing broken stuff than actually playing the damn game. In fact i was spending over 75% on tinkering. So eventually i drew the conclusion: All the pretty candy out there is a con. This dream-game with 200-300 mods is not something i can actually play - it's an illusion. Instead: Every single mod i add raises the the chance of ruining my game. TL/DR: If i can't have "everything", then i rather pick my mods carefully and conservatively, and each time ask myself: "Fancy, but how much does this actually add to my game in practice? How much will i be using those features, after the initial novelty wears off? How complex is it: Does it provide a big gain by modifying a minimum of things, or does it touch everything across Tamriel, "overhaul"-style? My current ESP-count is at about 100, including basics like the community-patch, skyUI, etc. Modman packages about 140 including texture-patches and plugins. About the string-limit: Last time i checked, i remember there was no conclusion either. My current savegame has 57K, with about 50K being from vanilla SSE. One thing to also keep track of is suspended stacks (as mentioned in my previous post). Suspended stacks are "parked" script-actions which SSE couldn't "finish" before saving. When you load a save, it constantly tries to finish them (in which case they're removed). So when you see a large (or even increasing) number of suspended stacks across saves, it means they are zombies: Pending actions that skyrim constantly tries to finish, but fails to do so. And the "constantly tries" means "work", so it lowers your FPS. When too many accumulate, papyrus is slowed down to a point, where other scripts fail to complete too and become suspended stacks - hence creating a vicious circle that will CTD your save shortly after load. When does that happen in numbers? Depends on machine and papyrus-time, i guess - in my case, "Skyrim Jobs SE" had leaked over 100.000 unfinishable zombie-stacks over months, and at that point my saves crashed a minute after load.
alphafr Posted August 28, 2019 Posted August 28, 2019 From my latest CTD issue experience I can confirm the "needle in a haysack" problem to find the cause Because you don't expect a mod such a racemenu to cause CTD when using lightning spells as example
Kristus Kringle Posted August 30, 2019 Posted August 30, 2019 My 2 cents for what it's worth ... but if you use MO2, manage conflicts, have your dependencies, then it comes down to load order and system resources. Some people believe you can run LOOT and be okay but in my experience LOOT only gets you 90% to a rock solid stable game. I always have to move some mods around in the load order to be 100% stable. Sometimes just moving one mod is the difference. Some mods are more trouble and some are not worth the hassle. Something I figured out a long time ago, software crashes are never random. They might seem random and the pattern might be very difficult to figure out but it will be there. Truly random crashes come from hardware, and they aren't random in the butterfly flaps it's wings sense, but close enough.
-Player1- Posted August 30, 2019 Posted August 30, 2019 Because, sometimes, it just doesn't work! Incompatible mods wrong loadorder wrong settings for mods too many animations too many scripts lighting issues shadow issues texture issues overlapping textures messed-up .Nifs messed-up .Ini's LOTS MORE
PepperDog017 Posted September 6, 2019 Author Posted September 6, 2019 Did not mean to abandon this post so soon, but I've been seriously sick with some kind of flu-like bug that's somehow gotten my eyes all fucked up where I can't stare at a screen for more than 5-10 minutes at a time. I am finally recovering and do plan to be back. "Something I figured out a long time ago, software crashes are never random." That is my thought as well. Coming from a technical background with a lot of coding experience, my take is that with sufficient time, effort, and resources, a bug, crash, conflict, etc. can always theoretically be solved in some way or another. Just some end up requiring much more pain than others! Perhaps coincidentally, I seem to have forgotten that I had updated RaceMenu sometime shortly before my random CTD problems began. So I was on 0.3.5 (stable afaik), updated to 0.4.3 (lots of "random" CTDs), and now have updated to 0.4.7 and the CTDs seem to have settled down... but still need more time to test. Only played for maybe an hour so far. With the quick version changes to RaceMenu over the last few days, I can only speculate that may have been part of the issue (thanks alphafr).
psychochild Posted September 8, 2019 Posted September 8, 2019 On 8/26/2019 at 12:03 PM, PepperDog017 said: Sorry if this might be a little rantish. I eagerly await any wisdom any Skyrim SE experts can provide...Thanks in advance! So my answer is mod order, compatibility, and mod order, with a side helping of mod order. Often authors all clamor for "put mine at the bottom" but really they just need you to load under certain types of mods, further I find many people just blindly rely on Loot to sort their mod order and I find it is very inconsistent and often even incorrect about some things. It is a great tool for checking for compatibility issues, dirty edits, and more, but really you should do your own mod order to be sure it won't ctd. I currently have over 300 mods - I converted some to esls and I have NO CTDs. This is only possible because of doing my mod order myself and occasionally fixing load order issues and keeping up mods (I track them on nexus). Also, reading the mod author page and directions is important. Here's how I sort my mods by category: Spoiler DLCs: Patches Bugfixes: Utility/Tools: ESMs: UI: Enironment Overhaul: Race Mods: Perk Mods: *also cloaks of skyrim if you use it Mission and Quest Mods: Weather Mods: Lighting Mods/Exterior: Water and Fire Overhauls: Sound Overhauls + Patches to already loaded mods: Worldwide Content Mods: (Settlement Mods, Building Mods, and Interior Mods) Plants and Foliage Worldwide: Combat Changes: Perk Changes: EXP Changes: Skill Changes: Quest and/or Text Changes: Magic Changes: General Gameplay Changes: NPC Gameplay Changes: Item Changes: Changes/Addons for NPCs: Custom Followers/Follower Behavior: Visual/Texture/Atmosphere Changes/Adjustments: Sound/FX/Music Changes: Cheat Items: Hair: Face: Body: Eyes: Skin: Weapon/Armor/Clothing Addons: Crafting Mods: Misc Items: Weapon/Armor/Clothing Changes: (i.e. Armor Rating Redux, Leanwolf Better Shaped Weapons) Physics: (CBP, CBPC, HDT, HDT SMP, SOS HDT SMP) Animation: (FNIS, etc) Patches: Load at End: Convenient Horses Alternate Start Hope this helps!
PepperDog017 Posted October 30, 2019 Author Posted October 30, 2019 Just circling back to this thread to add some potentially helpful information for other users looking for help with "random" CTDs. SSE Engine Fixes, EngineFixes.ini: [Experimental] MemoryManager = true UseTBBMalloc = true *Appears* to have solved the vast majority (all?) of my CTDs. If you have random CTDs and have not tried this, you may want to. And to add to my last post, I personally have had major CTD issues with nearly every RaceMenu update from 0.4.3 on. The only thing that seems fail-safe is rolling back 0.3.5, unfortunately.
PepperDog017 Posted October 30, 2019 Author Posted October 30, 2019 Now I have another problem I'd like some input on so I can further my knowledge of papyrus scripting: On a new game, load order re-fresh, based on https://wiki.nexusmods.com/index.php/User:Darkladylexy/Lexys_LOTD_SE I am getting intermittent stack dumps, always when in combat. I've been gradually solving these by selectively disabling mods or mod features that are spamming OnHit() and/or OnMagicEffectApply() events (every stack dump is nearly all OnHit() events or OnMagicEffectApply()). My understanding is that OnHit() events CAN run concurrently, but of course that cannot be "infinite" concurrent executions, i.e. there is always a limit. Then I found something interesting in the last Papyrus log. Here is a snippet of the stack dump: [10/29/2019 - 11:27:17PM] Dumping stack 2130114: [10/29/2019 - 11:27:17PM] Frame count: 3 (Page count: 3) [10/29/2019 - 11:27:17PM] State: Waiting on other stack for return (Freeze state: Freezing) [10/29/2019 - 11:27:17PM] Type: Normal [10/29/2019 - 11:27:17PM] Return register: False [10/29/2019 - 11:27:17PM] Has stack callback: No [10/29/2019 - 11:27:17PM] Stack trace: [10/29/2019 - 11:27:17PM] [ (A3111E06)].Actor.IsGhost() - "<native>" Line ? [10/29/2019 - 11:27:17PM] IP: 0 [10/29/2019 - 11:27:17PM] [alias Male1 on quest DefeatNPCMonitorQst (BA06E968)].defeatnvnonhitscr.IsAggressorValid() - "DefeatNVNOnHitScr.psc" Line 18 [10/29/2019 - 11:27:17PM] IP: 75 Instruction: 4 Line: 18 [10/29/2019 - 11:27:17PM] [Aggressor]: [Actor < (A3111E06)>] [10/29/2019 - 11:27:17PM] [::temp0]: True [10/29/2019 - 11:27:17PM] [::temp1]: False [10/29/2019 - 11:27:17PM] [::temp2]: False [10/29/2019 - 11:27:17PM] [alias Male1 on quest DefeatNPCMonitorQst (BA06E968)].defeatnvnonhitscr.OnHit() - "DefeatNVNOnHitScr.psc" Line 25 [10/29/2019 - 11:27:17PM] IP: 101 Instruction: 4 Line: 25 [10/29/2019 - 11:27:17PM] [akAggressor]: [ObjectReference < (A3111E06)>] [10/29/2019 - 11:27:17PM] [akSrc]: [Form < (A30D74C2)>] [10/29/2019 - 11:27:17PM] [akProjectile]: [PROJECTILE < (A30E5198)>] [10/29/2019 - 11:27:17PM] [abPowerAttack]: False [10/29/2019 - 11:27:17PM] [abSneakAttack]: False [10/29/2019 - 11:27:17PM] [abBashAttack]: False [10/29/2019 - 11:27:17PM] [abHitBlocked]: False [10/29/2019 - 11:27:17PM] [::temp8]: [Actor < (A3111E06)>] [10/29/2019 - 11:27:17PM] [::temp9]: True [10/29/2019 - 11:27:17PM] [Aggressor]: [Actor < (A3111E06)>] [10/29/2019 - 11:27:17PM] [::temp10]: False [10/29/2019 - 11:27:17PM] [::temp11]: None [10/29/2019 - 11:27:17PM] [::temp12]: [] [10/29/2019 - 11:27:17PM] [::temp13]: None [10/29/2019 - 11:27:17PM] [::temp14]: False [10/29/2019 - 11:27:17PM] [::temp15]: 0 [10/29/2019 - 11:27:17PM] [::temp16]: False [10/29/2019 - 11:27:17PM] [Victim]: None [10/29/2019 - 11:27:17PM] [::temp17]: 0.000000 [10/29/2019 - 11:27:17PM] [::temp18]: False [10/29/2019 - 11:27:17PM] [::temp19]: 0.000000 [10/29/2019 - 11:27:17PM] [::temp20]: False [10/29/2019 - 11:27:17PM] [::temp21]: False [10/29/2019 - 11:27:17PM] [::temp22]: False [10/29/2019 - 11:27:17PM] [::temp23]: False [10/29/2019 - 11:27:17PM] [::temp24]: [] [10/29/2019 - 11:27:17PM] [::temp25]: None [10/29/2019 - 11:27:17PM] [::temp26]: None [10/29/2019 - 11:27:17PM] [::NoneVar]: None [10/29/2019 - 11:27:17PM] [::temp27]: False [10/29/2019 - 11:27:17PM] [::temp28]: None [10/29/2019 - 11:27:17PM] [::temp29]: False [10/29/2019 - 11:27:17PM] [TheNext]: None Whats interesting is this exact stack appears to be repeated 70 times in the dump. Of course I didn't check EVERY instance, but spot comparison shows that the stacks seem to be line-by-line identical. I had hoped some more experienced papyrus experts might comment on whats happening here. Why am I getting stack dumps where the majority of the dump seem to be duplicate stacks? Is the Defeat mod creating some instruction stack (see above), it gets suspended for whatever reason, then another duplicate gets created, gets suspended, on and on, etc. etc. until the dump occurs? Note that I also looked at the DefeatNVNOnHitScr.pex source, and it *seems* like it should be throttling OnHit() events with a SpamGuard bool. Is the source of these stacks not actually Defeat itself, but the IsGhost() check on the NPC in question? (I'm probably misunderstanding exactly how the papyrus byte code is executing here.) EDIT: Long ago I found this thread: https://forums.nexusmods.com/index.php?/topic/5174600-throttling-onhit-scripts/ which may be relevant here. Correct me if I am wrong (and this may be a little tangential) but the use of the SpamGuard bool is basically flagging to prevent multiple concurrent executions of the OnHit() event in DefeatNVNOnHitScr.psc. And this may be best discussed over in the Defeat support threads, but wouldn't this be an example of where using States (https://www.creationkit.com/fallout4/index.php?title=GotoState_-_ScriptObject) might be better? Getting more OT here, but another link I found interesting: http://www.cipscis.com/skyrim/tutorials/states.aspx And a little more reference mat'l: https://www.creationkit.com/index.php?title=States_(Papyrus) Perhaps I should begin coding my own papyrus scripts in order to learn...
PepperDog017 Posted July 30, 2020 Author Posted July 30, 2020 Circling back to this thread again. And it has been some time since I posted to it...Wow how time can fly by. So my original question of why do CTDs happen did seem to be almost entirely due to racemenu bugs that have since been corrected. I've been on version 0.4.12 for quite some time now and have an extremely stable SSE build -- but I still do get stack dumps from time to time, running perhaps too many "heavy" scripted mods at once. I can probably live with it, since it happens very rarely (and I can usually tell -- when "too many" scripted events end up happening all at once). That said, I've learned a good bit of papyrus scripting in the meantime as well. I've found the use of states (busy states) on scripted effects such as OnHit(), OnMagicEffectApply(), OnItemRemoved(), OnCripple() (FO4), etc. can greatly reduce the likelihood of stack dumps. I am sure this post will get lost in the millions of posts here, but I just wanted to say -- for any Papyrus scripters out there, please consider the use of STATES on any/all events that can potentially be spammed. It is super easy to do in the most basic sense, and can (in my entirely anecdotal experience) minimize or eliminate stack dumps.
anjenthedog Posted July 30, 2020 Posted July 30, 2020 Player 1 said it pretty well. The question is a bit like asking why people die (no offense to the OP). There are myriad answers to that question. And to why CTDs happen. bad mod mod conflicts load order issue hardware/OS problems (problems literal problems) excessive numbers of animations too little memory too little computational power excessive numbers of mods being in the wrong place at the wrong time (like when a whirlwind storm kicks up around 0,0,0) etcetera
Recommended Posts
Archived
This topic is now archived and is closed to further replies.