Jump to content
Our Domain Name Has Changed! Read more... ×
Sclerocephalus

[Skyrim] Object references of the type [Item xx in Container yy]

Recommended Posts

For some time now, I am noticing that certain script operations of which I'm 99% sure that they used to return "none" in the past, are now returning nonsensical "references" of the type [item xx in container yy] instead.

 

For example, if trying to retrieve the reference of an object inside a container, a "none" reference would be expected, but now the scripts return an [item xx in container yy]. The problem with these references is that papyrus cannot handle them. There is no way to check whether a reference is of the [item xx in container yy] type, but this is sorely needed:

  • [item xx in container yy] references behave in most situations like "none" references: attempts at running member functions of the objectreference script on them will fail, and the papyrus log will spam the same errors as one would expect from trying to run those functions on a "none" reference.
  • Logically, however, an [item xx in container yy] reference is NOT none: A check such as "If <anyreference> = None" will ALWAYS return false when <anyreference> is an [item xx in container yy] type reference.

In other words, an [item xx in container yy] type reference is a disguised "none" reference, which slips through all sanity checks - with detrimental consequences for both vanilla and mod-added scripts. One case is documented here, but I am sure that there are many more:

 

http://www.afkmods.com/index.php?/tracdown/issue/13564-no-native-object-bound-to-script-object/

 

I don't know when exactly the engine started to return such references instead of a "none", but it may well be that this is one of the infamous patch 1.9. "improvements" that broke so many things. Scripting has become significantly more difficult because workarounds for preventing those references from slipping through sanity checks are very complicated.

Share this post


Link to post
Share on other sites

Jesus Christ. They couldn't just leave things alone? I'd wager patch 1.9 as well since I never recall having seen errors of this type prior to that. Fortunately I've not seen many in general, but this is going to make a big fat mess of things.

Share this post


Link to post
Share on other sites

Were I to take a guess as to what happened... Someone at Bethesda probably tried to make it so that you could get valid references to items in a container, even if they weren't persistent. They got halfway through it, gave up, and left it worse than it was before. Now the return value of DropObject() is unreliable when the item is persistent.

Share this post


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

Support us on Patreon!

×