Odd behavior with llAttachToAvatarTemp

[Helium Loon]

I've been playing around with llAttachToAvatarTemp(), and ran into some odd behavior, which isn't in the wiki.....

 

I created an object with a ZHAO-II AO in it.  I'm having this object rezzed by another object, and it attaches to the person who touched the object that rezzed it.  That all works fine.  I'm testing it with an alt, while I am online as well.

 

But when the person who it is attached to TPs to a different sim, the AO stops.  I've checked and the scripts still appear to be running.  What's stranger.....TP back to where I am, and the AO starts up again.  But even stranger.  TP away, then I (the creator) TP to them, and it starts up again when I enter the sim they are on!

 

Any ideas on WHY this would be happening?

 

[Helium Loon]

As an addition, I've tested a little further.  The scripts are still running (at least one of them, so I'd assume all of them, and the 'Script Info' shows all three as active) and the menus respond......it's just no animations seem to fire.

 

[Innula Zenovka]

That sounds as if some of the scripts are retaining their old permissions -- that is, permission to animate you -- after they've been temporarily attached.   I don't think they're supposed to, and certainly in some cases they don't -- I've been caught by that and PERMISSION_ATTACH, which has to be granted again to detach the item if the person to whom it attaches doesn't own the rezzer -- but that's certainly what it sounds like.  

I think I'd check to make sure it always requests PERMISSION_ANIMATE and PERMISSION_TAKE_CONTROLS when it's attached.    I don't know if that will fix it, but that's the first thing I'd try.

[Qie Niangao]

Glancing at the code, there's a global variable Owner that get set in state_entry() and on_rez(), but not on attach() nor on CHANGED_OWNER. That Owner variable is used in a call to llGetAnimation() to decide what if any animation needs to be overridden.  If it's still trying to get your animation, as the owner before attachment, and you're not in the sim, it's not going to know there's an animation to override.

On the other hand, if that's the problem, I don't know how it managed to push the right animation at the right time on the alt while your main was in the sim, instead of pushing animations to that alt that were appropriate to whatever you were doing with your main.

Anyway, if you want to test this hypothesis, throw in a call to intialize() in the attach() handler and see if it works.

[Helium Loon]

That was it.  ZHAO-II needed to check that to properly recognize the change in owner.  Not sure a whole initialize() is needed, maybe just updating that global variable.  I'll fiddle with it some more.

 

Thanks again, Qie!