Jump to content

Always quit to desktop before reloading (was: Issue #30235)


Recommended Posts

Quote

Given that you have a post on the forum where you've mentioned having used a save editor on your game, my guess would be this is the fallout from having done that. It's the kind of corruption I've seen countless times caused by tools people insist are safe.

I've never used a save editor. Arthmoor is confusing me with somebody else.

Anyway, I'd included 2 saves. And the console command to verify the quest status. Easy to reproduce.

Link to post
Share on other sites

Someone was saying they saw a post from you stating you'd used a save editor. Apparently they mistook the DLL loaders you're using for one or something. You ARE however using a number of "game fixes" type of plugins which IMO don't strike me as something we should be providing support for, no matter how enamored the community has become with them. That kind of black box data manipulation is unpredictable and doesn't give consistent results for a lot of people.

Regardless, I did check, and as I stated in your ticket there is no connection at all anywhere in the game data between Nimhe and Favor151. The two have no references to each other at all, so it simply isn't possible for this to be a vanilla game issue. Don't leave relevant information out of your forum posts like this. I'm not sure what end goal you're after with this kind of tactic but it's not appreciated and never has been.

Also there were no save files attached anywhere in your ticket. Not that it would have mattered.

Link to post
Share on other sites

I'd thought I'd attached a pair of save files, before and after. My mistake.

I'd reported it in the bug tracker, but I'm unable to find the connection either. Hoping that others will test. I'm raising it here, because we don't get enough eyeballs on the tickets. Also you closed it saying I'm using a save editor, which is false.

That new runthrough does use SSE Engine Fixes. I'm unsure how it could have bolloxed any setstage across quests. But it does fix the savegame issue that ended my previous long run. There are some terrible programming errors in the vanilla game.

Did you actually test killing Nihme before talking to the Jarl, then checking the stages as described in the bug report?

I'll do that myself with a new runthrough to see whether it is reproducible across runs.

Link to post
Share on other sites

I've killed Nimhe plenty of times before ever talking to the jarl and Favor151 has never once been impacted by doing so. I don't use any of those so-called fixer plugins either and my game has never once encountered any of the terrible things they say will happen to it without them.

Link to post
Share on other sites
  • 2 weeks later...
On 4/28/2021 at 2:35 PM, Arthmoor said:

I don't use any of those so-called fixer plugins either and my game has never once encountered any of the terrible things they say will happen to it without them

On my third test run, the problem has gone away.

I'd made only 3 changes:

  • I've reverted to original data. I've not run SSEEdit Autoclean on any of the original game files.
  • Scrambled Bugs (https://www.nexusmods.com/skyrimspecialedition/mods/43532) instead of Flora Respawn Fix. This patch fixes the engine problem directly, instead of running tens of thousands of OnUpdate events (that add tens of thousands of new objects).
  • Always Quit to Desktop before Load (Continue). The engine is not correctly cleaning up before Load. Only Quit to Desktop seems to ensure the environment is clean.

Sadly, this makes the Load process painful. It's much slower. Requiring the .NET Script Framework (https://www.nexusmods.com/skyrimspecialedition/mods/21294) is particularly slow.

There are many extant examples of things not not correctly cleaned up before load. For example, folks have reported New Game will start on whatever day/time that a previous load had run. I've not verified any of them (many are unverifiable). But I'm thinking that using as ultra-clean practices as possible will avoid long term corruption.

Link to post
Share on other sites

Yeah, that's another thing too. I haven't cleaned the game master files in a long time and won't be doing so again after a run of bugs xEdit had with doing that and causing worldspace issues. That's the stuff people noticed because it was obvious.

As far as saving/loading, as long as you don't reload inside the same cell you saved in you'll be fine. It's only when doing a reload from the same cell where you get potential problems. Most noticeable with death reloads in a dungeon. Sometimes you can come back and find dead NPCs you killed prior to the reload. And who knows what else that's not obvious. Either pick a different save from a different cell, or exit to desktop first.

I have no experience with the .NET Script Framework mod. The tracebacks it generates on a crash are generally gibberish and from what I've seen of other peoples' dump files, not terribly useful in general anyway. They often point the finger at mods which aren't causing any actual problems with the game.

Link to post
Share on other sites
17 hours ago, Arthmoor said:

bugs xEdit had with doing that and causing worldspace issues

Could you place a warning at the top of the cleaning pages here? I didn't know, and only recently noticed obvious problems that caused me to search and find the warnings.

 

17 hours ago, Arthmoor said:

Either pick a different save from a different cell, or exit to desktop first.

This needs to be prominently documented somewhere. Reload after death is probably important.

Personally, I'm a rather tediously cautious role player, and rarely die. Simply by not doing a quest as soon as it is offered. By rule of thumb, wait at least 10 levels after it is offered. Unfortunately, there are some severe surprises, such as opponents that are always 1.2 or even 1.5 times your level. That's small at levels 5-10, but often insurmountable by level 30. So UESP warnings help, too.

In my case, I've been frequently reloading in the same cell. I'm a "completionist", and like to hear what alternative answers they've recorded. Then pick the most interesting one.

[I've changed the title to reflect that this is the most likely culprit, at least from my testing process.]

Link to post
Share on other sites
  • DayDreamer changed the title to Always quit to desktop before reloading (was: Issue #30235)
On 5/12/2021 at 10:50 AM, Arthmoor said:

I have no experience with the .NET Script Framework mod. The tracebacks it generates on a crash are generally gibberish and from what I've seen of other peoples' dump files, not terribly useful in general anyway. They often point the finger at mods which aren't causing any actual problems with the game.

I've played with it a little bit and that pretty much summarizes my experience with it for the most part when it comes to weird script and record clobbering issues.  It has saved my bacon in a few really stupid "filthy unclean mesh" CTDs I've had though.

For example it seemingly found a conflict between the roof meshes in Bee Hives and the late-2020 ENB Particle patch I was using. Since I trust your BSA-packed stuff that has never caused an issue for me in almost a decade, I excised the offending nif from the particle patch. Magically the crashes stopped.  Later it found a buggy headpart in a 3DNPC update with similar results.

Correlation isn't causation, but those two examples gave me some faith in its utility.

Link to post
Share on other sites

Bee Hives is only a .esp file and has no meshes. Everything placed by it is vanilla assets.

All I've ever seen of dumps from it were pretty generic stuff with random junk sitting on the stacks. Nothing about nifs. I suppose it's possible it does a better job of catching those.

Link to post
Share on other sites
On 5/16/2021 at 8:19 PM, Arthmoor said:

Bee Hives is only a .esp file and has no meshes. Everything placed by it is vanilla assets.

I think what happened was the dump mentioned the nif was loaded or modified by "bee hives.esp". so that explains the derp.

On 5/16/2021 at 8:19 PM, Arthmoor said:

All I've ever seen of dumps from it were pretty generic stuff with random junk sitting on the stacks. Nothing about nifs. I suppose it's possible it does a better job of catching those.

I'm actually using it to troubleshoot a LAL->Own hold property -> Tundra Homestead CTD I've kind of been able to reproduce.  Nothing but generic stack dumps so far, but I'm hoping coming in the front door or loading in from a save at the LAL load-in spot will let me reproduce it.

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...