Offering a HUD to an avatar who sits on my chair

[Impresario Beaumont]

Is there a way of offering a HUD attachment to an avatar who sits on my chair by means of my script? I know I could offer the HUD as an inventory item, bu then the avatar has to not only give permissions to accept the inventory but then also attach the HUD.

Thank you for any advice

[Quistess Alpha]

llAttachToAvatarTemp() (if the script is in an experience enabled on the land, accepted byu the avatar, then there's not even a permission request dialog) from the HUD's script after it's rezzed. It's a minor pain getting the HUD to know who it's supposed to attach to though.

You can also do something similar with RLV, but it's even more of a pain.

[Impresario Beaumont]

Ty Quistess! Not sure I follow the sequence of events. The llAttachToAvatarTemp() doesn't identify the avatar. Is my chair script issuing this? I'm sorry, I'm probably missing something obvious

[Quistess Alpha]

1 hour ago, Impresario Beaumont said:

Not sure I follow the sequence of events.

The 'correct' method goes something like this (when to open/close listeners left out for simplicity):

• the chair rezzes the HUD and sets a global variable to the key of the avatar.
• The HUD sends a message back to the chair asking for the key of the avatar it's supposed to attach to.
• The chair sends the HUD a message containing the Key of the avatar to attach to.
• the HUD llRequestPermissions PERMISSION_ATTACH from the avatar, or if experience-enabled, uses llRequestExperiencePermissions instead.
• If/When the HUD gets the permission, it calls llAttachToAvatarTemp()

There are various 'hacks' to simplify steps 1-3, which are to greater or lesser degree 'bad practice' :

• The Chair can set the rez parameter to an integer which partially represents the key of the avatar, then the HUD can llSensor for nearby avatars who's key matches.
• The Chair can set its description field to the key of the avatar the hud wants to attach to. (the HUD can get the key of the Chair that rezzed it with llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]))
• The Chair can rez the HUD at the exact location of the avatar it is to attach to, then the HUD can llSensor for avatars that are very close by. (this can be combined with the first hack)

In any case, it's also important to make sure the HUD is TEMP_ON_REZ or otherwise deletes itself if it does not get permission or cannot find the avatar to attach to, and also invisible and non-physical so as not to be an eyesore.

[Rolig Loon]

Look at the example scripts in the LSL wiki entry for llAttachToAvatarTemp. The sequence is spelled out there IIRC.

[Qie Niangao]

10 hours ago, Impresario Beaumont said:

The llAttachToAvatarTemp() doesn't identify the avatar. Is my chair script issuing this?

Right, the tricky bit is the passing of avatar ID from the rezzer (chair) to the temp attachment once rezzed. What you do not want to do is use the object_rez event in the rezzer as evidence the attachment is ready to receive a message identifying its intended avatar. That will probably work consistently in your test environment, then in another region or another time it will fail consistently until the sim is restarted. Hence the various alternatives Quistess lists.

I'd only add that it may be best to maintain a queue of avatars needing attachments if the chair accommodates multiple sitters and they're faster at sitting than the attachments are at rezzing and learning their intended avatar. The scenario of very slow rezzed scripts and multiple users also imposes risk on some of the "hacks" mentioned, e.g., the chair description advances to the next sitter before the attachment is ready for its intended sitter.

There's also complexity if the getting of permission takes a long time, during which the sitter may stand or change poses before the attachment can attach, so the attachment script may want to handle that possibility. Finally, inasmuch as we're talking about a chair, AVsitter's "prop" plugin scripts handle some of these complexities if that's of interest.

[Impresario Beaumont]

Thank you all for the great advice. I'm still testing different situations, but it looks like it's working perfectly.