Auto attach & Listener issue

[Artorius Constantine]

Finally decide to do my own scripting and hit an "I'm missing something simple" wall last night about 1 AM.

Object rezzes an object and messages on channel whatever. I got that all working. The rezzer says the UUID of the toucher.

Rezzed object hears UUID and requests attach perms. Here's the issue, I bought an auto attach script to use as a base but it;s attach to owner only.

I wrote a  listener into it, it compiled but I can't seem to get the UUID from the listener into the right place for the permission request. While messing with it I broke it good.

How do I get the UUID into the right place? Do I need to convert the string message into a key?

[Charlotte Holmeforth]

---

Artorius Constantine wrote:

Do I need to convert the string message into a key?

---

Yes, if your listen heard the avatar key, you can convert it to a key and do 

llRequestPermissions( (key)AvatarKey, PERMISSION_ATTACH );

When the avatar responds to the permissions dialog, that will trigger the run_time_permissions event, so you can check if you have the permissions, then attach the object.  After attaching the object, you'll have to ask for permissions again as the owner will have changed.

llPermissionsKey() will give you the key that was used in llRequestPermissions, if you need it later.

 

[Innula Zenovka]

Check which command you are using to attach the item.

llAttachToAvatar() only works if the avatar owns the item, so it makes sense for the rezzer to be set to owner only.    

If you want to attach the item to someone other than the owner, you need to use llAttachToAvatarTemp().    That will attach the item to anyone, but it won't create an entry in their inventory and will delete itself when the wearer detaches it (or relogs).

Without knowing what the code you're using looks like, it's a bit difficult to go much further at this point.

[Artorius Constantine]

Thanks, I'm going back in the pool to play now. Yeah this is all abut temp attach. I want to give the agent something that won't persist either in world or in inventory. 10 years in world and I'm just really learning to script. =)

[Rolig Loon]

You'll find a very good example script for llAttachToAvatarTemp in the LSL wiki.  Walking your way through it is a nice test of your logical skills.

[Artorius Constantine]

 I've got attach. It's still something with my listener/ conversion. I can't even get it to compile today.

I've got it on channel 0 just for testing so I can hear it. This is what I have in the rezzed object.

My syntax is messed up now. I shouldn't have worked so late lol.

 

 

default
{
state_entry()
{


llListen(0, "", NULL_KEY, "");
}

listen(integer channel, string name, key id, string message)
key uuid = (string message );
{
llRequestPermissions( (key uuid ), PERMISSION_ATTACH );
}

run_time_permissions( integer vBitPermissions )
{
if (PERMISSION_ATTACH & vBitPermissions)
{
llAttachToAvatarTemp( ATTACH_RHAND );
}
else
{
llSay( (0),"You must attach this to your right hand." );
}
}

on_rez(integer rez)
{
if(!llGetAttached())
{ //reset the script if it's not attached.
llResetScript();
}
}


}// END //

 

[BarcodeBrian]

Inside your listen event, try:

llRequestPermissions((key)message,PERMISSION_ATTACH);

Nothing else for your simple example.

 

Of course, the way you have it written for testing, once rezzed, it will try attaching to what it will interpret as a key to any chat at all on local channel. I'm sure you were planning on filtering for a specific channel, and/or from the rezzing object's UUID. Without shutting off the listener, this attempt will be forever repeating when local chat is heard.

Rather than resetting the script if not attached when rezzed, define a listener (with a variable) and shut it off after hearing or when timer runs out, let it delete itself.

I prefer to temporarily change the rezzing objects description to the target avatar, and in the rezzed object, use llGetObjectDetails for both its own OBJECT_REZZER_KEY, and then OBJECT_DESC of the rezzer for the target UUID. Let the rezzing object reset its description after a short timer, and no listeners unless needed for other tasks.

Your way will also work.

[Rolig Loon]

It's easier to see syntax errors if you indent carefully so you can see where scopes begin and end.  Then count your brackets and be sure that they are in the right places.  This edited version compiles:

default{	state_entry()	{		llListen(0, "", "", "");	}	listen(integer channel, string name, key id, string message)	{	// This bracket was out of place		key uuid = (key) message ;	// This line had a misplaced ")"		llRequestPermissions( uuid , PERMISSION_ATTACH );	// and this one didn't need "(key)"	}	run_time_permissions( integer vBitPermissions )	{		if (PERMISSION_ATTACH & vBitPermissions)		{			llAttachToAvatarTemp( ATTACH_RHAND );		}		else		{			llSay( (0),"You must attach this to your right hand." );		}	}	on_rez(integer rez)	{		if(!llGetAttached())		{ //reset the script if it's not attached.		        llResetScript();		}	}}// END //

I assume that you are using the listen event merely as a test.  Otherwise, I'd suggest sending any old message and grabbing the person's UUID from the id variable instead of taking the longer route of sending the same key as the message.

Now, note that you have possibly only gotten halfway.  If you ever intend to use llDetachFromAvatar instead of trusting that the user will somehow get tired and detach the object himself, you'll need to ask for PERMISSION_ATTACH all over again.   That's because the owner of the object has changed since your first request.  You'll need to write an attached event in which to make that second request.  It's less obvious, perhaps, that you'll need to request any other important permissions in that attached event too. PERMISSION_TRIGGER_ANIMATION or PERMISSION_TAKE_CONTROLS or any other permissions only apply to the current owner --  the one who is wearing your object -- if you have asked him.

 

[Artorius Constantine]

Great! I'll take that shortcut. Never thought of grabbing the key there.

It's just a drink, nothing major. Just want them to auto attach as temp instead of people having to dig for a drink and have it cluttering inventory. or the land if they don't take it. I still have to put a die event in there.

Definatley don't want any listeners left on. I"ll see about pulling the rezzing objects UUID for the listen event. That sounds like the lowest lag. Still really new at this. Thanks again!

[Innula Zenovka]

---

Rolig Loon wrote:

I assume that you are using the

listen

event merely as a test.  Otherwise, I'd suggest sending any old message and grabbing the person's UUID from the

id

variable instead of taking the longer route of sending the same key as the message.

---

Maybe I'm missing something but I thought that Artorius is rezzing an object by script, and the rezzer then tells the object the uuid of the avatar to whom it should attach.   In that case, the id variable is, of course, that of the rezzer object, not the avatar.

[Innula Zenovka]

---

Artorius Constantine wrote:

 I still have to put a die event in there.

 

---

Or you could simply make the object temp-on-rez, so if it doesn't attach it will die after a minute or so without being told to.  It won't die while it's attached to the avatar, and, since it's temp attached, it's going to die anyway once it's detached.

[Rolig Loon]

---

Innula Zenovka wrote:

---

Rolig Loon wrote:

I assume that you are using the

listen

event merely as a test.  Otherwise, I'd suggest sending any old message and grabbing the person's UUID from the

id

variable instead of taking the longer route of sending the same key as the message.

---

Maybe I'm missing something but I thought that Artorius is rezzing an object by script, and the rezzer then tells the object the uuid of the avatar to whom it should attach.   In that case, the id variable is, of course, that of the rezzer object, not the avatar.

---

Right you are.  I missed that part and was paying attention to the temp attach portion, which is the tricker part.  Thanks, Innula.

[Artorius Constantine]

Yep, Yep and yep!

Well I got it to temp attach on touch and it's a temporary object so it'll die either way.

Still fighting with it. I think I need to step back to the starter class on the WIKi again. I keep reverting to Basic programing syntax because it is so close.

Gotta get used to proper formatting too, it does help to work on it.

[Artorius Constantine]

If anyone cares, I had an extra "id." in it. Finally got it.

Auto attach on touch, no open listeners, temporary object,, temp attach. And it works! Yaaaaaaay!

Now to figure out how to make a cumulative score keeper that adds to the count every time someone drinks one.

 

Do I have this order right?

Touch rezzer, drink rezzes and the rezzer says "Touch me to attach", now when they touch it. I have all the permissions I need for the rest of this I think

On attach the drink rezzes a HUD, that HUD auto attaches (I should have the permissions from the drink right?)and Rezzes the AO, which then auto attaches with the same set of permissions.

Make any sense? I want to eventually make these drinks "experiance enabled" but for now I want them to work everwhere.

[BarcodeBrian]

---

Artorius Constantine wrote:

If anyone cares, I had an extra "id." in it. Finally got it.

Auto attach on touch, no open listeners, temporary object,, temp attach. And it works! Yaaaaaaay!

Now to figure out how to make a cumulative score keeper that adds to the count every time someone drinks one.

 

Do I have this order right?

Touch rezzer, drink rezzes and the rezzer says "Touch me to attach", now 

when they touch it.

I have all the permissions I need for the rest of this I think

On attach the drink rezzes a HUD, that HUD auto attaches (I should have the permissions from the drink right?)and Rezzes the AO, which then auto attaches with the same set of permissions.

Make any sense? I want to eventually make these drinks "experiance enabled" but for now I want them to work everwhere.

---

No, you are not correct.

Each item will need its own permissions granted for themselves; unless Experience enabled, in which permissions for the Experience as a whole need only be granted one time.

You shouldn't need an AO; you can always ask for permission to animate after the first attach happens (the trickier part Rolig mentioned). Any animations for it should be inside the same attachment, and the script holding those permissions should handle it.

[Innula Zenovka]

Just to add to BarcodeBrian's reply, while the HUD will need to ask for its own set of permissions, these should be granted silently since the glass (which, if I properly understand it, is what rezzes the HUD) belongs to the avatar at this point.

If I were doing this, first I'd have the glass ping the avatar to see if a HUD is needed before I rezzed one.

[Artorius Constantine]

That's what I was thinking. Since the drink is owned by the agent it should be able to get silent permissions.

A ping is a great idea. If they reply that they already have the hud on, that whole section can shut down.

I never thought of letting the hud do the ao work. duuuh. Thanks!

Running the money and 2nd party drinks permission tests right now. So far so good.

Got the Mesh NPC animated with simple llSetPos scipts. Only rotating one piece and moving 3 so the load is low.

On to the HUD!

[Qie Niangao]

---

Innula Zenovka wrote:

Just to add to BarcodeBrian's reply, while the HUD will need to ask for its own set of permissions, these should be granted silently since the glass (which, if I properly understand it, is what rezzes the HUD) belongs to the avatar at this point.

---

Either I don't understand what this means, or I don't think it works this way. It should still need to explicitly ask the owner for permission to attach. Shouldn't it?

(That is, unless this is Experience permissions, but then ownership wouldn't matter, among other things.)

[Rolig Loon]

Innula is talking about the second request for permissions, the one issued in the attached event after the HUD has been attached.  Before the HUD is temp attached, PERMISSION_ATTACH must be granted explicitly.  Once it is attached, though, the HUD has changed ownership. You still need to request PERMISSION_ATTACH and PERMISSION_TRIGGER_ANMIATIONS at that point, but they are granted implicitly.

[Qie Niangao]

Oh, thank you!  Yeah, I see now the earlier post about wanting to eventually detach from the avatar, and that combined with the PERMISSION_TRIGGER_ANIMATIONS and/or PERMISSION_TAKE_CONTROLS would need a fresh permissions request that would indeed be granted silently.

[Innula Zenovka]

Actually, now I come to think of it,I'm pretty sure  Qie is right, and I'd misremembered --  I don't think PERMISSION _ATTACH is granted silently to the owner  (I'm so used to using RLV and Experience Tools that I'd forgotten how it works under normal circumstances).

That's what we used to need the "Lulu Loophole" for.    Sorry about that.

[Rolig Loon]

Yes, PERMISSION_ATTACH is granted silently to the owner if the item is already attached.

https://gyazo.com/c066094fef02062321caf9df3bd2f89d

It has to be granted explicitly before that, but once the HUD is attached, PERMISSION_ATTACH (which is needed for a scripted llDetachFromAvatar) will be granted implicitly.