This has me genuinely stumped.

I have a item display script that uses some functions similar to the vanilla weapon rack. However, just like the vanilla rack, there are some weapons that refuse to mount. For example Ghost blade and Ebony Blade.


the papyrus error i get is:

error: Unable to call Is3DLoaded - no native object bound to the script object, or object is of incorrect typestack:[Item 1 in container  (0300300E)].defaultDisableHavokOnLoad.Is3DLoaded() - "" Line ?

this error happens on the following line in the script:

ObjectReference MountedItem = DropObject(akBaseItem)While (!MountedItem.Is3dLoaded);   etc etcEndWhile

basically mountedItem returns a value of ([Item 1 in container (0300300E)].defaultDisableHavokOnLoad) instead of a form ID.... no idea why. i think it has something to do with a quest screwing up these items somehow.



i can launder out this error if i use PlaceAtMe then RemoveItem on the original, and everything works great. of course the potential downside to this is that when the player takes the item off of the display rack, the item is a CLONE of the original item with a reference ID starting with FF, and not the original editor ref ID.

Now, most of the time with quest items, you cant even remove it from your inventory in the first place. but if this is something that is running in an active alias and not designated a quest item, i think the clone will no longer be filling the alias, and the original (filled in the alias) will be sent into oblivion, remaining persistent somewhere in between planes of reality LOL.


tl;dr version - my question is why the hell is MountedItem returning [Item 1 in container (0300300E)].defaultDisableHavokOnLoad after the DropObject call, when in the event OnItemAdded, akBaseItem returns the proper form ID of the base item and akItemReference returns the original editor REFR id

nevermind, i fixed it.

basically there is some inexplicable glitch with the function DropObject on certain quest-based, reference-specific items (this only happens to item which are/were once a part of a quest, and are using a specific placed reference - i.e. permanently persistent reference (rather than an object created from a base ID, or an object that originated from inside a container). in this case, DropObject will NOT return a proper FormId for the actual reference which was dropped


for the curious, how i fixed it (this fix applies to vanilla weapon racks, if anyone is inclined to correct that script):


after you call DropObject(akBaseItem)
you need to "catch" the objectreference using akItemReference from your OnItemAdded event and pass that argument to your "mounting weapon" function, so that you can run your Is3DLoaded, and MoveTo/TranslateToRef call onto the proper reference ID.

casting DropObject to a new ObjectReference returns the funky non-formID value i mentioned above, so just call DropObject by itself, and use akItemReference after the drop to do your object manipulating.

pain in the *** but at least it works


Edit, you need to pass both akBaseItem and akItemReference to the weapon mounting function and run an if statement to see whether akItemRef returns a value of none, otherwise the normal non-persistent items will fall to the floor.

so if it returns a value of none, run the original script as intended using an Object Reference = DropObject and manipulate the ObjRef, but if it returns something other than None, use akItemReference to manipulate the object


example:

ObjectReference MountedObjectIf (akItemReference)  DropObject(akBaseItem)  MountedItem = akItemReferenceElse  MountedItem = DropObject(akBaseItem)EndIf

like i said, this will fix vanilla weapon racks as well, so you can adapt this concept to that script if anyone wants to fix and release it

in any case, i have updated the wiki with this finding, and this just serves as another good example as to why you should NEVER mark a reference as permanently persistent unless you absolutely have to.


Edit: nevermind. i just looked at the vanilla weapon rack script again... good god, what a mess. since the weapon rack depends on the player wielding the weapon, applying this fix dynamically is nearly impossible.