Bem Beyaz has left the sim ...

[Bem Beyaz]

I have an attachment that relies on a constant listen on a negative channel while another avatar is in the same sim. In the interests of good housekeeping, I would like to kill the listen if the avatar leaves the sim or logs off and reactivate it should the avatar return.

Bearing in mind that the avatar may be gone for a considerable time period, should I:

a) Use llSensorRepeat every few minutes and kill or reactivate the listen when the avatar leaves or comes back?

b) Work something out with llGetAgentList on a timer?

c) Forget about it and leave the listen hanging?

d) Try a more efficient solution if anyone can suggest it here.

 

[arton Rotaru]

You could do

if (llGetAgentSize(avatar_key)){   // Avatar is in the region}else {   // Avatar is not in the region}

 in a timer as a simple test.

Though, personally I would just go with option c).

[Rolig Loon]

---

arton Rotaru wrote:

[ .... ]

Though, personally I would just go with option c).

---

I agree.  The tiny load of one open listener on a high negative channel is negligble.  So is the server load of running a slow timer and checking llGetAgentList or whatever.  Given the choice between two negligible loads, I'd just flip a coin. My coin says, "do nothing."

[Miranda Umino]

Just change the status of your listener  manually , "on" when you want to listen your other avatar ( he is on the sim ) , "off" when you don t want to listen him ( he is not in the sim ) ; for instance in touching your attachment . You have not 200  attachments

 

// constants : change these two lines integer channel = -84552147;key otherAvatarKey = "f7ce2caa-dca0-44f7-8326-7eff69b33060";// variablesinteger handle;integer toggle;default{    state_entry()    {        handle = llListen(channel, "", otherAvatarKey, "");           llListenControl(handle, TRUE);           	llOwnerSay("Listening "+(string)otherAvatarKey + " on channel " + (string)channel );    }     touch_end(integer total_number)    {        toggle = !toggle;  
        // Make the listener active or inactive as required        llListenControl(handle, toggle);                   if(toggle)        {            llOwnerSay("Listening "+(string)otherAvatarKey + " on channel " + (string)channel );        }        else        {	    llOwnerSay("Not Listening "+(string)otherAvatarKey + " on channel " + (string)channel );        }         }     listen(integer channel, string name, key id, string message)    {        llOwnerSay( name + " just said " + message);    }}

 

[Bem Beyaz]

Thank you all.

As it happens I already have a number of toggle controls on the device and I had initially controlled the listen through the touch event more or less as Miranda has shown above (but from my avatar and not from the wearer who will just have to do as he is told -- mwahahahahah-h-h-h-h ..). The trouble is that there is a 'twin' device that needs to have some messages relayed to it so that has to stay open regardless of whether or not it is touched and that is what I was concerned about.

I also considered removing the sensor or timer solutions while my avatar is away and having him reactivate it on the first touch event following his return but that creates a minor but very annoying usability issue.

So all in all, it seems best to go with option c) if the device is unlikely to cause a heavy load (the script reads as something like 0.012 on a sim test). Since the device is on a second avatar, the listen will be dropped when he logs anyway.

[Innula Zenovka]

In general, listeners are only a problem if they're using a channel that has a lot of traffic, because that means the simulator has a lot of work deciding which scripts can hear a particular message, and then the individual scripts all have to process the messages they can hear, at least to decide whether the message means anything to them.

That's why open listeners on 0, the public chat channel, should be avoided unless there's no alternative.    But a listener on an unused, very negative, channel isn't going to involve the simulator in processing anything that's not intended for that particular script, so I don't see it as any sort of problem.

So I vote for option c, too.

[Bem Beyaz]

Thanks, Innuala. To all intents and purposes, the channel will be unique as the device will generate a negative integer from the wearer's UUID (gkCaptive) using this snippet I picked up from somewhere:

 

giChannel = (integer)("0x8" + llGetSubString(gkCaptive, 0, 6));

 

On that score, I had been using a modified version of this init() function from the Wiki on llGetOwner() instead of llResetScript() on the changed(integer changed) routine to reset the listens:

 

init()

{

   gkCaptive = llGetOwner();

   giHandle = llListen(giHandle, "", NULL_KEY, "");

   llListenControl(giHandle, FALSE);

   llRequestPermissions(gkCaptive, PERMISSION_OVERRIDE_ANIMATIONS | PERMISSION_TRIGGER_ANIMATION | PERMISSION_CONTROL_CAMERA);

}

 

Since I'm running the device in a permanently open listen on this more or less unique channel, would it be good practice to retain that function or should I remove it altogether and run the code block in state_entry() before opening the listen?

[Innula Zenovka]

That looks to me like something the captive would wear.   If that's the case, I would turn the listener on either in the attach event or when the permissions are granted.

Otherwise I would just open the listener in state_entry and keep it open.   I don't  think it matters much either way, but I would always try to keep things as simple as possible, and if you're not going to be turning the listener on and off, then I don't see the need to use llListenControl at all.

[Bem Beyaz]

Indeed this is an RLV attachment and I agree that it's best to keep the script as simple as possible.

I was running the init() function while the device was still hard-coded with an obscure negative channel and I found that llResetScript() wasn't immediately registering the listen to the new owner in the changed event. Things got very messy when two avatars in the same sim wore the device.

Since I'm still very much a learner, I kept the function even after discovering that trick of generating a more or less exclusive channel for the wearer until I could be sure what I'm doing.

Now that I'm wiser, I'll follow your suggestion and set the listen in the attach event.

A second script will use llListenControl to turn particles on and off so I'll keep the init() function in that.

[Innula Zenovka]

Without being able to see the scripts, it's a bit difficult to comment,    However, I'm surprised that the script wasn't registering the new owner properly.    If it's something people wear, though, I tend to do my initialisation in the attach event, on the argument that the wearer has to be the owner.   

If you have another item listening and need to distinguish between the owners of different devices using the same channel, use llGetOwnerKey(id) in the listen event to find out who owns the device that's talking to the script.

[Bem Beyaz]

It's a bit tricky for me to be sure since I overwrote that messy draft of the script but as far as I recall the listen was not updating immediately when the new owner wore the item but only when he wore it for the second time -- and that included the test you're suggesting with llGetOwnerKey(id). In fact I'm pretty sure that it wasn't updating at all until I started using that filter. When I looked into the problem, I found this on the llGetOwner page of the Wiki:

The one problem many coders come up against is that previously-activated events referring to the owner don't automatically change when the owner changes. The most often-seen result is a listen registered to owner will continue to listen to the PREVIOUS owner rather than the CURRENT owner. It is often confused as a bug in

llGetOwner

or

llListen

it is not in fact a bug but part of the design. There are several ways of working around this problem. The easy solution is to reset the script when owner changes or it is rezzed. The easy solution is not always the right solution.

The same article suggests the init() function as a workaround instead of llResetScript and indeed that did the trick. But it's redundant now that I am using a bespoke channel for each new owner.