Jump to content

SenorCorruptedSave

Members
  • Posts

    6
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

SenorCorruptedSave's Achievements

Clanfriend

Clanfriend (1/10)

0

Reputation

  1. That's interesting. I'd speculate that doesn't apply functions with returns values. How would you even be able to program if it did? But, if the function doesn't have a value that gets utilized locally, I could see how you could generally split it off and few would notice.
  2. Yeah that makes sense. Cheers! Looks like it is still used to me. Internally, you can see that the code, quest names, etc. All have a history dating back to the separate patches. That USLEEP version actually was the master version until at least version 4.2.2 of USSEP. Since then the separate USSEP version tracker was added. However, there are still version tracker for each of the 4 originals, plus LE, and now the new SSE one. SSE checks in with all of them before doing its thing, as they all still track their internal versions. I'd characterize the design as similar to a handful of Lego blocks. It looks like it was relatively easy to slap an LE one overtop the 4 originals, then an SSE one over top that. The originals done seem like they need to be touched ever again. But they do get included, and do the same bugfixes they always did. So during an update the new SSE block needs to check and make sure they and LE finished, before adding itself on top.
  3. One other thought, if you do wrap the Revert() in a conditional that only fires for updates, would it make sense to do a popup notifying people of the potential incompatibility the Revert() causes? I don't know if you guys ever do that, nor how common it is to introduce small incompatibilities out of necessity. But, if this is rare a popup could be welcome. I am tempted to write a custom SKSE script, one that outputs which non-duplicate entries were deleted and allows one to reinstate them. This would be for my own use, but I'd happily share it in the forums or somewhere, for other SKSE users. I completely agree about ReSaver being dangerous, which is why I wanted to get to the bottom of this rather than using it. This script should be a decent alternative, assuming you have a save from just before the CTDs started.
  4. I appreciate ya giving it a second shake. The fix looks great. I would note it introduces a tiny incompatibility with other mods that also added to this item via scripts. Notably the Exotic Arrows CC does this. The incompatibility is tiny, in that most folks will probably never notice it. I wonder though, would it make sense to check if you need to run the Revert()? For brand new installs that never updated, their leveled list is pristine (in theory), and the Revert() can only remove entries from other mods. I'd speculate that by having a USLEEP LastVersion > 400, you can reliably tell whether or not the person has updated or it's a new install. The Revert() actually fixes another bug, one that was so small I didn't even want to report it. In previous versions like 4.2.2, the Bandit Arrows were added inside of UDBP_Retroactive212Script. Scriptname UDBP_Retroactive212Script extends Quest Quest Property MQ101 Auto UDBP_VersionTrackingScript Property UDBPTracking Auto Quest Property DLC2MQ06 Auto Quest Property DLC2SkaalVillageFreeform2 Auto ReferenceAlias Property Edla Auto Quest Property DLC2RR03Intro Auto LeveledItem Property LItemBanditWeaponArrows Auto Ammo Property DLC2NordicArrow Auto Function Process() ;Bug #19338 - Nordic arrows never added to bandit arrows list. DLC2Init does 4 of these for bows, so we'll do 4 for arrows too. LItemBanditWeaponArrows.AddForm( DLC2NordicArrow, 24, 1 ) LItemBanditWeaponArrows.AddForm( DLC2NordicArrow, 25, 1 ) LItemBanditWeaponArrows.AddForm( DLC2NordicArrow, 26, 1 ) LItemBanditWeaponArrows.AddForm( DLC2NordicArrow, 27, 1 ) This Logic was moved to USSEPRetroactive423Script. Thus for anyone updating, they would have already had the bandit arrows added by the old UDBP scripts, and would have them added again by the new 423 one. Thus, 423 always creates at least one duplicate during updates. But by calling Revert() afterwards, you fixed it.
  5. I encountered a save corrupting bug. And after many hours of isolating it I finally figured out what is causing this, and I can easily reproduce it on a new vanilla save with only one mod installed: USSEP. Here are the steps to reproduce. Click New Game, wait for intro to finish and you have your hands freed. This pushes us well past stage 70 of MQ101. Install USSEP version 4.2.2. Wait for it to finish running the retroactive scripts, which can take quite a while due to them purposefully calling wait(). Checked my Papyrus.0.log to ensure they had all finished. Save, Exit, and update to USSEP 4.2.4b. Now, every single time you load this save, and a subsequent save, you will see the following two entries in your Papyrus.0.log: [05/24/2021 - 05:14:09PM] VM is thawing... [05/24/2021 - 05:14:09PM] USSEP 4.2.3 Retroactive Updates Complete [05/24/2021 - 05:14:09PM] USSEP 4.2.4 Retroactive Updates Complete Every time. As Arthmoor recently said these scripts should only run once, but they clearly aren't. I figured out why. In USSEP_VersionTrackingScript we see the following code. ;Previous USLEEP script was handling tracking for both, bring over its version value if it's greater than 307, which was the last USLEEP retro script version. ;Some of the stuff in the USSEP retro scripts should not be run twice. if( USLEEPVersionTracking.LastVersion > 307 ) LastVersion = USLEEPVersionTracking.LastVersion endif if( LastVersion < 424 ) if( LastVersion < 406 ) Retro406.Process() Elseif( LastVersion < 407 ) Retro407.Process() Elseif( LastVersion < 408 ) Retro408.Process() Elseif( LastVersion < 413 ) Retro413.Process() Elseif( LastVersion < 414 ) Retro414.Process() Elseif( LastVersion < 415 ) Retro415.Process() Elseif( LastVersion < 417 ) Retro417.Process() Elseif( LastVersion < 420 ) Retro420.Process() Elseif( LastVersion < 421 ) Retro421.Process() Elseif( LastVersion < 423 ) Retro423.Process() Elseif( LastVersion < 424 ) Retro424.Process() EndIf EndIf This script is flagged to run on OnPlayerLoadGame(), which fires everytime the player loads a save. Thus everytime it loads the game, the LastVersion gets reset to the stale USLEEPVersionTracking.LastVersion, which in the case of an update from 4.2.2 this var will equal 421. Which means as the code continues it will satisfy the conditions to trigger Retro423.Process(). Which brings us to the save corrupting symptom of this simple bug. It's quite delayed. You have to save and load a vanilla game 59 times to have your save corrupted. What is happening is that Retro423.Process() was only intended to be run once, and it adds 4 entries to a Level Item. Run it 59 times though, and it ends up adding 236 entries! That's on top of vanilla's 20 entries, so 20+236 = 256. However, Leveled Items can only have 255 entries. If you add more than this via scripts, the save is corrupted. How this manifests itself is that when the game engine attempts to create a new save, you get an instant CTD. The same exception code you get from circular leveled lists, which also cause a CTD on save. Is this a bug I should report in the tracker? Or is it perhaps possible that USSEP does not support updating from one version to the next? I attempted to report this earlier, but Arthmoor marked it "Invalid". I probably did not do a good enough job of describing things, it seems like Arthmoor thought this had something to do with ReSaver. It doesn't. It can even be reproduced in a brand new save with only one mod, USSEP. Since this issue was already closed (And props on the fast triage! I wish our team was that quick.) I figured I should open a topic and discuss it first. If folks, especially if Arthmoor, agreed it's a bug that merits fixing, then I'd open a new issue with a better description. Plus my better understanding of the problem, after working a few more hours to further isolate and reproduce. If you guys need my full Papyrus Logs or anything let me know, I purposefully made copies every step of the way. Thanks for a great mod!
×
×
  • Create New...