11-02-2012 02:44 PM
I'm fiddling with a temp attach hud and I'm experiencing some strange behavior with it that might be system bugs. My problem is, since the pjira is no longer used, I can't tell if this is a known bug or or not. Or even if it's just my bad scripting. So, here's the situation....
I have an "avatar detector" that is an invisible box using llVolumeDetect() to identify when an avatar enters my landing point (same idea as Linden Realms). When an avatar enters the detector, the collision_start() event Rezzes a "hud" at it's origin passing a randomly generated integer as the start_param. Then it waits a fraction of a second and says the UUID of the avatar that was detected on the channel defined by the start_param.
The HUD listens on the channel indicated by "start_param" and calls llGetPermissions() to get permission to attach to the avatar sent over that channel.
If the avatar accepts the attach request, the hud attaches to the ATTACH_HUD_BOTTOM position and (should) move itself to <0.0, 0.0, 0.04> (this is just above the bottom button-bar on v3 viewers).
When the person wearing the HUD touches it, the HUD sends a dialog box showing the HUDs position. this is really just a test activity so I could figure out where to put the HUD to avoid the viewer clutter that v3 has.
If the HUD wearer changes regions, the HUD detaches itself with llDetachFromAvatar() after a 6 second delay (due to a bug I already know about).
So, the problem I'm having is:
when the avatar teleports, instead of detaching, it spits out the error message, "Script trying to detach from agent but PERMISSION_ATTACH permission not set!". BUT, the script requested PERMISSION_ATTACH as part of the attachment process.
11-02-2012 08:21 PM
That's not the way permissions work when you are using llAttachToAvatarTemp. You still have to request PERMISSION_ATTACH before you can attach the device, but once it is attached, the ownership changes and permission is revoked. You have to request the same permission again in order to be able to detach the device again later without getting an error message. There's a note about this in the wiki for llAttachToAvatarTemp: "All permissions granted prior to actually attaching appear to dumped when successfully attached via this method (possible security measure)." I'd put the second request in the attach event.
11-06-2012 10:06 PM
I think we're working the same thing where all the ideas came from the Realms and some similarities in terms of how we do it, what makes it difference I think is the way passing the UUID.
What I did is when the avatar collided to that invisible phantom object (let's call it Rezzer Object) it rezzes a HUD. The rezzer object create a random negative channel and used it as the last parameter of the llRezObject so that the when the HUD its on_rez event it will listen to that channel. once the HUD is rezzed the rezzer object will send a message to that channel, the message contains the "Avatar ID (the collided avatar)", then the rezzed HUD will pickup that message and the message will be converted into Key ID so that the rezzed HUD knows what avatar it belongs and who will ask permission to attach. to avoid those rezzed object to stay longer in the ground i put a time limit of asking permission, if the avatar denied the request the rezzed HUD will be deleted or if the avatar don't give it's attention to that dialog box in the given time the rezzed HUD will be deleted also.
But still working on it for more improvement.
That's how I did because there's no way to make it Auto-Attachment like the Linden Realms.
Now my next plan is to detach the attached HUD from the avatar if the avatar teleport to the other land. llAttachToAvatarTemp will do the detaching thing when the avatar is disconnected or detach the HUD but not when teleported to the other land. I got an idea using changed event if the avatar teleported in will detach the HUD, the problem I see to it is what if the next land that the avatar teleported is "script not allowed"?, I thinking also a way if we can detach it before the avatar's actual teleportation what I'm thinking is not quite possible i guess.