Talk:LlAttachToAvatarTemp
Possible Caveat about need to re-request permissions to detach objects
I've just been playing with this, trying to attach and detach items by script, and I think this may be worth a caveat.
I have made an rezzer that, when touched the first time, rezzes an object that asks for PERMISSION_ATTACH and, if this is granted, attaches to you temporarily. The second time it's touched, it tells the object to detach.
If I own the rezzer, then the temp attached object detaches without needing to request PERMISSION_ATTACH a second time. It simply detaches. That's as I would expect, since there's nothing in the script to remove the permission.
However, when my alt touches it, it has to re-request PERMISSION_ATTACH or the operation silently fails. And it's the same when I gave a copy of the rezzer to my alt. Then it needs to re-request permissions when I use it.
The permissions are silently granted once it's attached, but you do seem to need to ask for them. It took me ages to realise this was why another object I was testing worked for me and no one else.
My two scripts are
key av;
integer toggle;
integer avnumber;
/*user function by Kira Komarov http://wiki.secondlife.com/wiki/Key2Number*/
integer Key2Number(key objKey) {
return ((integer)("0x"+llGetSubString((string)objKey,-8,-1)) & 0x3FFFFFFF) ^ 0x3FFFFFFF;
}
default
{
state_entry()
{
}
touch_start(integer total_number)
{
toggle=!toggle;
if(toggle){
av = llDetectedKey(0);
avnumber = Key2Number(av);
llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT,0),llGetPos()+<0.0,0.0,1.0>,ZERO_VECTOR,llGetRot(),avnumber);
}
else{
llRegionSayTo(av,avnumber,"detach");
}
}
}
and
integer Key2Number(key objKey) { /*user function by Kira Komarov http://wiki.secondlife.com/wiki/Key2Number */
return ((integer)("0x"+llGetSubString((string)objKey,-8,-1)) & 0x3FFFFFFF) ^ 0x3FFFFFFF;
}
integer avnumber;
default
{
on_rez(integer start_param)
{
if(start_param){
llSetPrimitiveParams([PRIM_TEMP_ON_REZ,TRUE]);
avnumber = start_param;
llSensor("","",AGENT,20.0,PI);
}
}
sensor(integer total_number)
{
integer i;
while(i<total_number){
key k = llDetectedKey(i);
if(Key2Number(k)==avnumber){
llRequestPermissions(k,PERMISSION_ATTACH);
return;
}
i++;
}
}
run_time_permissions(integer permissions)
{
if(permissions & PERMISSION_ATTACH){
if(llGetAttached()){
llDetachFromAvatar();
}
else{
llAttachToAvatarTemp(ATTACH_LHAND);
}
}
}
listen(integer channel, string name, key id, string message)
{
if(llGetAttached()){
if(llGetPermissions()&PERMISSION_ATTACH){
llOwnerSay("got permissions -- don't need to ask for them again");
llDetachFromAvatar();
}
else{
llOwnerSay("haven't got permissions -- asking for them again");
llRequestPermissions(llGetOwner(),PERMISSION_ATTACH);
}
}
}
attach(key attached)
{
if(attached){
llListen(avnumber,"","","detach");
}
}
}
Innula Zenovka 11:22, 19 August 2012 (PDT)
Yes, I would say the permission to Attach granted before the ownership change doesn't persist. The 'new owner' has to grant permission even though it was that same owner who already granted before the ownership change. Likely LL flushes this permission (and others) anytime a script changes ownership. This is a unique (and new) case where they are pre-emptively asking for permission before the avatar actually owns it. Could be a bug.
—The preceding unsigned comment was added on 11:51, 21 August 2012 by Darien Caldwell
That's exactly right. I have written an attach-on-rez script for an object with an animation in it. If I request PERMISSION_ATTACH|PERMISSION_TRIGGER_ANIMATION in the on_rez event, I get a script error when the script hits the llStartAnimation command after the object is attached, or if I try to detach the object with a scripted command. To beat that, I have had to put a second llRequestPermissions function call in an attach event and ask for both permissions again. The second time, they are granted silently.
Rolig Loon 19:55, 4 October 2012 (PDT)
Unexpected detaching?
I have made an object - let's call it Demo - that, when touched, attaches itself to the HUD Bottom of the toucher using llAttachToAvatarTemp(). When the toucher then detaches a DIFFERENT attachment (on the body or HUD), Demo detaches and is deleted. I see this in both Firestorm 4.2.2 and LL Viewer 3.5.1.
I cannot find anything that documents this behavior. Is it a bug, or an intentional undocumented feature?
Brattle Resident 10:14, 28 October 2013 (PDT)
- Sounds like a bug. You should report it on Jira. In your bug report you should include the source of the scripts that reproduce it. Since you probably don't want to post your scripts (trade secretes etc) as they are, I'd recommend paring them down just what is needed to reproduce the bug. It's good that you are trying different clients but you also need to try regions that run different versions of the SL server software. It maybe that you are seeing a new bug. -- Strife (talk|contribs) 21:45, 28 October 2013 (PDT)
- Update - as of October 2015, this bug has been fixed for a long time. JulieDoll (talk) 14:55, 12 October 2015 (PDT)
Failing to attach a no-transfer object to self
llAttachToAvatarTemp&diff=1173074&oldid=1171869 sounds like a bug. -- Strife (talk|contribs) 13:19, 5 October 2012 (PDT)
Temporary Attachments can't call llTeleportAgent
In case anyone had the same idea I had, that combining llAttachToAvatarTemp and llTeleportAgent would be a great way to make a teleporter that works between regions:
"Temporary attachments cannot request runtime permissions to teleport"
--Samm Florian 12:29, 17 July 2013 (PDT)
Stopping/removing scripts inside a temporary attachment?
I haven't found any reference to this on the main page (and perhaps it should make it there) so I'm wondering if anyone experimented with the following idea:
- Ask for all permissions, blah blah, send object to be temporary attached, check for permissions blah blah
- The object is now attached to the avatar and has changed ownership
- It has inside it a simple script that just does a [llDie]() after, say, five minutes
- In order to prevent that script from firing, the new owner simply edits the object and turns scripts off (formerly you could just teleport to a no-scripting zone) or eventually removes it
- Voilà — no more time restrictions on the temporarily attached object!
Of course, eventually the object will be removed, one way or the other (even if it's just due to a LL bug forcing all attached items to refresh), but I'm thinking about the following 2 scenarios:
1. In a combat RPG area, participants find "power pills" that, once touched, will temporarily grant them a new weapon (or HUD extension) for X minutes, then it llDie's and requires finding another "power pill". Cheaters will simply remove the script or stop it. 2. Imagine a new business model: clothes renting (as opposed to buying them and never using them more than once). You click on a vendor, select a mesh outfit appropriate for your avatar's body, and it gets attached temporarily for, say, L$10 an hour. At the end of the hour, you pay the dress for a time extension, and so forth, until you run out of money. The advantage is that you just pay-for-use and can thus get expensive dresses for a bargain — just not "forever". Needless to say, if there is a way to stop the script or remove it then this business model doesn't work.
Scenario #2 can also be used for demo-ing clothes (some clothes designers are already playing with similar concepts and I always wondered how they managed to do it) but also for more complex interactions. Renting a vehicle, for instance: you don't attach a vehicle (well, not usually), but you get a HUD which generates a license key, valid for X minutes. The vehicle will check if you are wearing the HUD and have paid it for the ride. At the end of the period, the HUD is gone (can you pay HUDs? Probably not. But you might be able to pay some kind of box on the premises to extend the duration). A similar idea is to allow a user to visit a special location, go on a ride, etc. — pay X for the entry, get a HUD with a valid license key, once the time elapses, you're kicked out (figuratively speaking).
I imagine this can be made possible merely by having no mod scripts inside?... so even if you're the object's owner, you cannot change the scripts. Or perhaps not even copy or transfer them. The trick, I believe, is getting the permissions right.
I'm just wondering... perhaps all of the above is actually absolutely trivial and has been done extensively in the past decade, I just never paid attention! :-)
— Gwyneth Llewelyn (talk) 02:38, 6 December 2023 (PST)