Jump to content

[Skyrim] The papyrus function GetParentCell() and what may happen when it runs on a persistent reference


Sclerocephalus

Recommended Posts

As it turned out, the GetParentCell() function can be used to gain some insights into the handling of persistent references by the game engine, and more specifically, what happens to them when they are physically removed from the game world. As we all know, persistent references are never actually deleted, but there are situations where they can be physically removed, e.g. when you sell the respective item to a merchant and wait until his chest respawns or when you drop it somewhere into the game world and wait until the cell resets. They will physically disappear, i.e. they are removed from the chest and nowhere to be found in the cell, respectively, but where do they go ? Or, more precisely, where does the engine relocate them ?

 

GetParentCell() will tell you where, but the result may be totally unexpected, and when you once have used this function in a script which you couldn't get to work, it may well be that this was because you accidentally did run it on a persistent reference. As usual with unexpected discoveries, this behaviour is nowhere documented and I had to learn it the hard way.

 

In the specific case I was troubleshooting, there was a weapon rack (what else ?) which was properly working and had passed all tests with the new script, and then, after two in-game days, it suddenly became completely inoperative. I could still grab the weapon, but the activator remained disabled. No way to get it to work again, and resetting the script's properties on this specific rack (from an external "helper" script) had no effect either.

 

So, what had happened ? It took me two full days to reconstruct what happened: I had grabbed the starting items (that crappy iron shield and those two similarly crappy iron greatswords - all those pre-placed items are persistent!) and sold it to the merchant next door. After two days or so, his chest respawned and the items were physically gone. Now, from this point on, running GetParentCell() on any of those items did return the rack's parent cell (i.e. the cell where those items are persistent and where they did "start life" in the game). That's where the engine relocates them!

 

Logically, this result is plain nonsense, because none of the items is to be found anywhere in this cell. The activator script, which compares the rack's parent cell with the starting item's parent cell to find out whether the starting item has been removed, will be misled to believe that the starting item has not been removed and then hooks up in an endless loop while waiting for its 3D to load (which never happens, of course ...).

Link to comment
Share on other sites

Oh, joy. That doesn't sound like a lot of fun at all. Is it possible to break the loop at all once this has happened? Scripts getting stuck into loops that never break is BAD.

Link to comment
Share on other sites

This was actually pretty easy. I have set counters on the 3D lload checks and found out that all weapons in a cell load within less than one second. Instead of the GetParentCell() check (ironically, this was the last check left from the vanilla script), there is now a custom LoadsInSameCell() check, which waits one second for the starting item to load and returns false if this was not successful. Since the starting item is handled before all other items anyway, the extra second will effectively result in all other 3D load checks being skipped, so the script is not even slowed down.

 

What makes me really angry is that this was nowhere documented. You can find piles of tutorials on how to make tits wobbling, how to prevent them from glitching out (pun intended) and other questionable stuff, but no one tells you that you shouldn't run GetParentCell on a peristent reference. It's an insane world ...

Link to comment
Share on other sites

Maybe nobody was aware of this problem before and that's why it isn't documented? It happens. There's a lot we still don't know about Skyrim's ways of doing things.

Link to comment
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...