Search the Community
Showing results for tags 'GetParentCell()'.
Found 1 result
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 ...).