Unofficial Patch crashes my game...

[taleden]

I have the same problem with USKP 1.3.3c, and the hotfix mentioned in this thread does not appear to address it.

 

You can see the problem yourself if you unpack the USKP .bsa (or unzip the hotfix) and look at WeaponRackActivateSCRIPT.psc, in the PlaceItem() function:

Function PlaceItem (ObjectReference ItemToPlace, ObjectReference TriggerMarker)
;This function grabs the specified item and places it on the rack
 
; 	Wait to make sure the item is loaded before proceeding, in order to prevent an "Object has no 3D" error when its motion type is set below:
	While !ItemToPlace.Is3DLoaded()
		Utility.Wait (0.1)
	EndWhile

If ItemToPlace somehow becomes None while this thread is Wait()ing, that loop will never exit because <None>.Is3DLoaded() is an invalid call, and !<invalid call> == True. Even worse, I don't think the infinite loops can be fixed on an existing save because if you change the script, the game will still restore and resume the copy baked into the save, which has the infinite loop:

[10/21/2013 - 10:55:53AM] Warning: Function WeaponRackActivateScript..PlaceItem in stack frame 3 in stack 4277881 differs from the in-game resource files - using version from save 

My current save has 80 threads stuck in this loop. I can see all the thread ID numbers but there doesn't appear to be any console command to force-kill a running Papyrus thread, so I think I'm out of luck.

 

I've posted all this same information in the USKP's own forum, so hopefully v1.3.4 can fix this bug and stop breaking save games.

[Lord Garon]

Well, isn't the actual cause of the loop that ItemToPlace "somehow becomes none"? Maybe there should be a loop counter or some other exit condition to get out, but l would say that "somehow becomes none" is a higher priority problem. You can't go around losing references, that's pretty bad for a game on almost double digit official patches.

 

And, is that a USKP authored function, or is it just in an otherwise modified original script included in the USKP? I know they've been working on the weaponrack scripts for a while (they were pretty broken originally, I guess).

 

I'm not trying to defend anyone here, its just that the USKP guys are WAY better at fixing things than breaking them. I guess that's the bottom line, for me. They've fixed a lot of game issues I actually experienced. And, I can't break that script to cause log spam no matter what, and its not for a lack of trying.

Edited October 22, 2013 by Lord Garon

[Shadeybladey]

Yes, I've never had this problem in 20 months and I really don't remember playing without USKP in all that time.

 

But they have been messing with this weapon rack script for months and whenever they think it's fixed they find another problem.

 

But, as I say, I don't care about weapon racks and I'm not particularly interested in the Companions questline. My first character used the weapon and shield rack at Breezehome, but since I got Pocket Campsite and then Pocket Empire Builder, I build my own stockades anyway.

 

I'll probably do it with my new character for the Silver Hand quest as I have made a mod that adds new silver weapon types, so I'd like to test it to see what they drop. But I won't be putting weapons on any racks at the Companions HQ.

 

~.~

[taleden]

So it turns out that there are at least two separate reasons that PlaceItem() can get stuck in this loop.

 

The first one is caused by trying to put specific items on a weapon rack -- Ghostblade, Zephyr, probably others. Anything whose original world-placed reference attaches the defaultDisableHavokOnLoad script. In those cases it's not that ItemToPlace *becomes* none, it's that for these particular items, right off the bat ItemToPlace is a weird variety of pseudo-ObjectReference that Bethesda added in a recent patch, but which does not behave correctly in papyrus scripts. This is the really bad case that OP and I both reported because they spew errors into the log every 0.1s forever.

 

But PlaceItem() can also get stuck here when trying to handle items which are pre-placed on racks (usually it's the iron shield and two iron swords). If you take the pre-placed items off the rack and sell or destroy them, their reference goes into limbo and then PlaceItem() will also get stuck waiting for them to "load" which they never will. But in this case it at least doesn't print error messages every time, it just silently spins in the background. So you probably do have lots of threads stuck in this loop that you'd have no idea about unless you do something like 'dps' to show all running papyrus threads, or update the weapon rack scripts and see how many threads refuse to load the new code because they're still running. In my case I only had the 1 really bad thread writing errors, but I have another 78 threads stuck in the loop doing nothing but taking up scripting resources.

 

And yes, unfortunately this script is a USKP invention. I don't know how long ago it was, but at least as of 1.3.3c, the USKP comes with almost complete rewrites of the weapon rack scripts. So this particular infinite loop is not vanilla Bethesda code -- not that Bethesda doesn't write their share of bad loops. But I think we are making progress convincing the USKP developer who wrote those weapon rack scripts to put a failsafe into this one, so at least it'll stop biting people.

 

I also may have a way to break the really bad loops which spew errors every cycle. I tried it on my save and it seemed to work, so after a little more discussion with the USKP devs I'll post it here.

[Lord Garon]

Yeah, I checked the vanilla script;

...

if (PlayersDroppedweapon)
int Count = 0
      While(!PlayersDroppedweapon.Is3DLoaded()) && (Count < 10)
; Have to wait to make sure the item is dropped before setting it's motion type, or else I get a "Object has no 3D" error.
	     Utility.Wait(0.1)
	     Count += 1
        EndWhile
endif

Obviously, some function call changes before this, but at least there is a loop counter While condition in this one. Its also inside an IF block.

 

Looks like there is some kind of a timing or threading issue involved at this point in the script. But the original author was worried about a different error than the one you guys are seeing. This segment still has a <ObjectReference>.Is3DLoaded() check and a None or bad (pseudo?) reference will work the same way, if it can happen after the IF condition here, but will only give ten errors per loop.

 

Your explanation of the cause just verifies that the actual problem lies with ObjectReference handling. Couldn't you just move the original object (even a cloned one) back to the same cell as the problem racks to break your loops? At least, for the pre-placed items. I don't know about the 1.9 patch; I have no idea what a "pseudo-ObjectReference" is, or what it is used for.

 

Unique items on weapon racks were zero-day bugs in Skyrim. I don't know how many things I've actually lost to the clothes dryer-sock phenomenon (Where in the hell did it go?) by putting them on a rack, or mannequin. Or not being able to get them off once on a rack. Or having them randomly just fall off. It appears there is a fundamental ObjectReference handling/logic/scope error somewhere in the weaponrack or other attached scripts. I know I'm not telling anyone anything new here, just thinking as I type.

 

What game symptoms do you experience? I would imagine these type errors would only slow script execution. Do you have lower FPS or sluggish play near the racks? I don't know a repeatable CTD mechanism , as the OP reported, from these particular type script errors, unless the game engine is really busy (hello other bugs). Maybe, as in your case, many of them will cause stack issues. However, bad ObjectReference handling is another issue altogether.

Edited October 22, 2013 by Lord Garon

[jkprice]

^{I can't use the unofficial patches. Scripted events frequently stop working... such as the first dragon you kill, at the watchtower near whiterun, it doesn't give me a dragon soul and the quest never completes with the unofficial patch installed. Without it, it works fine.}

Edited October 22, 2013 by jkprice

[Lord Garon]

I just whacked ole Mirmulnir for about the 200th time just before I logged in here, no problems. Usually, the absorbing souls problem stems from installing the Dragonborn DLC and not having the Unofficial Dragonborn patch, or a load order problem.

Edited October 23, 2013 by Lord Garon

[Madcat221]

^{I can't use the unofficial patches. Scripted events frequently stop working... such as the first dragon you kill, at the watchtower near whiterun, it doesn't give me a dragon soul and the quest never completes with the unofficial patch installed. Without it, it works fine.}

 

 

Your problem is not USKP, but one of three other causes:

 

1: You have Dragonborn DLC but no Unofficial Dragonborn Patch, or the two Unofficial Patch files are not in the proper load order. Install it and ensure that Unofficial Dragonborn Patch loads after Unofficial Skyrim Patch, as all the Unofficial Patches are meant to work together with all official modules you have, and loaded in the same order as their associated official modules. The UDBP combines fixes that USKP does to the scripts (cauterizing debug messages, making subsequent visits to word walls result in the dragon giving a soul as they should) with the additions that the Dragonborn DLC makes.

2: You have loose DragonActorScript.pex or MQKillDragon.pex script files. Delete them.

3: You have another mod altering one or both of the two aforementioned scripts that breaks the Dragonborn DLC additions to them, and thus breaks the rest of the script as well.

 

Dragon soul absorb problems are well documented and the focal point of the problem is well known. USKP's involvement with them was diagnosed and corrected in (IIRC) a day after it was discovered during Dragonborn DLC's release. If the Unofficial Patches are properly installed, then they are not the cause.

[Shadeybladey]

So it turns out that there are at least two separate reasons that PlaceItem() can get stuck in this loop.

 

The first one is caused by trying to put specific items on a weapon rack -- Ghostblade, Zephyr, probably others. Anything whose original world-placed reference attaches the defaultDisableHavokOnLoad script.

 

<snip>

 

But I think we are making progress convincing the USKP developer who wrote those weapon rack scripts to put a failsafe into this one, so at least it'll stop biting people.

 

 

 

If they cannot fix the script for all items, could they not just have a Warning Message Box whenever you click on the racks that says

 

DO NOT PUT THESE ITEMS IN THE RACK.

 

with a list of the troublesome items?

 

~.~

[RatcatcherOfKvatch]

@LordGaron: re: "Clothes Dryer Sock Phenomenon"

 

You, sir, have a way with words. I got a good laugh out of that. :)