Sclerocephalus Posted September 20, 2013 Share Posted September 20, 2013 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. Link to comment Share on other sites More sharing options...
Arthmoor Posted September 20, 2013 Share Posted September 20, 2013 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. Link to comment Share on other sites More sharing options...
Sclerocephalus Posted September 26, 2013 Author Share Posted September 26, 2013 This appears to be another victim: http://www.afkmods.com/index.php?/tracdown/issue/13682-hearthfires-byohdivertprefabsscript-errors-while-processing-bookshelves/ Link to comment Share on other sites More sharing options...
Arthmoor Posted September 26, 2013 Share Posted September 26, 2013 So is one to guess that the bookshelf scripts will need an overhaul now too? Link to comment Share on other sites More sharing options...
NightStar Posted September 26, 2013 Share Posted September 26, 2013 If this keeps up, what won't need an overhaul? Link to comment Share on other sites More sharing options...
Arthmoor Posted September 26, 2013 Share Posted September 26, 2013 The trigger box outside of Whiterun? Link to comment Share on other sites More sharing options...
Jumps-Down-Stairs Posted November 3, 2013 Share Posted November 3, 2013 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. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now