Jump to content

Auto attach & Listener issue


You are about to reply to a thread that has been inactive for 2320 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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?

Link to comment
Share on other sites


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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 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 //

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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!

Link to comment
Share on other sites


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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites


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.)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2320 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...