listen question

[Xed Saunders]

hi everyone, probably this has been already asked but i was not able to find a definitive answer.

i have a hud and a wearable mesh, both objects communicate using listeners,the hud send commands to the mesh and the scripts inside it do the job. all work flawlessy but as reported in the wiki is always a good practice to stop the listener after it got and execute the command. doing this the mesh interrupt the listener and don't get anymore commands from the hud. my simple solution was to comment the lllistenremove row but of course it leave the listener always on. what happen doing this? it will eat memory and lead to a crash soon or later? as second chance, is there any example on how to reactivate remotely a removed listener?

thanks

 

[Arduenn Schwartzman]

Here's a much better practice: add a "Remove Scripts' button to the HUD, that removes the scripts from the wearable mesh. With an extra confirmation dialog, of course, to notify the customer that they have to make sure they have a backup of the mesh object first.

For a better SL!

[Rolig Loon]

If you are genuinely concerned about it, you can always use llListenControl to toggle the listen handler on/off, but really .... don't bother.  You are not causing any harm to anyone by keeping a channel open and inert, especially if it's listening on a high negative channel.  The sole exception might be a very busy HUD that spams the region with messages all the time.  People in a RP region might worry about its small demand on server resources.  Otherwise, turning your listen handler on and off is generally more trouble than it's worth.

[steph Arnott]

1 hour ago, Rolig Loon said:

If you are genuinely concerned about it, you can always use llListenControl to toggle the listen handler on/off, but really .... don't bother.  You are not causing any harm to anyone by keeping a channel open and inert, especially if it's listening on a high negative channel.  The sole exception might be a very busy HUD that spams the region with messages all the time.  People in a RP region might worry about its small demand on server resources.  Otherwise, turning your listen handler on and off is generally more trouble than it's worth.

I dumped that control ages ago. It sounds like a great idea on paper but in usage it is terrible. Simple fact is that nearly all use only a very small group of channels. Put a channel at say 634000 and you have a very high probability of being the only one in the whole of SL using it and most likely to ever have used it.

Edited December 31, 2018 by steph Arnott

[Qie Niangao]

2 hours ago, Arduenn Schwartzman said:

Here's a much better practice: add a "Remove Scripts' button to the HUD, that removes the scripts from the wearable mesh.

Agreed.

Hmm. Come to think of it -- and I haven't tried this, so grain-of-salt etc: As the HUD detects it's detaching, message the wearable to delete its script. Then when the HUD attaches again, it hunts through llGetAttachedList for anything that might be the wearable (checking creator and any other llGetObjectDetails signatures we devise), then calls llRemoteLoadScriptPin to push the script back down to the wearable target. Some overhead during the brief attachment process but zero scripts in the wearable the whole time the HUD isn't worn. The HUD would carry the extra memory of the (not running) wearable script, but that's not a big deal. No state retained in the wearable script, of course. 

Seems worth a try. Or (if it works) it may be common practice and I just don't know about it.

[steph Arnott]

3 minutes ago, Qie Niangao said:

Agreed.

Hmm. Come to think of it -- and I haven't tried this, so grain-of-salt etc: As the HUD detects it's detaching, message the wearable to delete its script. Then when the HUD attaches again, it hunts through llGetAttachedList for anything that might be the wearable (checking creator and any other llGetObjectDetails signatures we devise), then calls llRemoteLoadScriptPin to push the script back down to the wearable target. Some overhead during the brief attachment process but zero scripts in the wearable the whole time the HUD isn't worn. The HUD would carry the extra memory of the (not running) wearable script, but that's not a big deal. No state retained in the wearable script, of course. 

Seems worth a try. Or (if it works) it may be common practice and I just don't know about it.

Well one has to be carefull with that because sometime the script looks like it has be removed from the object and all asociation to the script gone when in fact the association is still present. I have had that issue in the past. The added script simply refuses to run.

[Rolig Loon]

2 hours ago, Qie Niangao said:

Seems worth a try. Or (if it works) it may be common practice and I just don't know about it.

It does seem worth an experiment.  It has a sort of Rube Goldberg feel -- going to a lot of work for rather minimal gain -- and it opens more possible ways for the system to get tangled up in itself, but the concept itself is intriguing. I will stand back at a safe distance while you try it.  😎

[Kyrah Abattoir]

Turning listeners off is good practice in general, obviously it's not always feasible if you intent on receiving commands anytime/anywhere.

But for things like receiving a menu selection from the user, you should close those after a couple minutes, there is no reason to keep them open.

Edited December 31, 2018 by Kyrah Abattoir

[steph Arnott]

3 minutes ago, Kyrah Abattoir said:

Turning listeners off is good practice in general, but obviously it's not always feasibleif you intent on receiving commands anytime/anywhere.

But for things like receiving a menu selection from the user, you should close those after a couple minutes, there is no reason to keep them open.

Except in the high usage bracket leaving a channel open makes no measurable difference at all. LL claims it does, but it was more of a case to stop people leaving open the under twenty channels active. Menu wise closing the channel has more to do with deactivating the script run than the channel itself.

[Xed Saunders]

ok, having just one listener i'll end up to not stop it but to offer the option to remove the scripts if someone is worried about the lag. many thanks and happy new year everyone

 

[Qie Niangao]

On 12/31/2018 at 3:04 PM, Rolig Loon said:

It does seem worth an experiment.  It has a sort of Rube Goldberg feel -- going to a lot of work for rather minimal gain -- and it opens more possible ways for the system to get tangled up in itself, but the concept itself is intriguing. I will stand back at a safe distance while you try it.  😎

Oh, peeking back at this thread, I see a challenge! 😮

So here's a sketch of a couple scripts, both of which live in the HUD, but only the first actually runs there; the second ("Wearable script") gets loaded to a wearable attachment only while the HUD is worn. (It should load automatically if the HUD is added when the wearable is already attached -- most common case, I think -- or manually if the HUD is worn first.)

/*
A sample HUD script that loads a script to a non-HUD object attached
to same agent as this script.

That object must have been prepared to accept a script by having
something like the following line of code run once:

    llSetRemoteScriptAccessPin(MY_SECRET_PIN);
*/

integer MY_SECRET_PIN = -424242424;
integer ATT_SCRIPT_CHANNEL = -242424242;    // used in both directions arbitrarily
string LOAD_SCRIPT_NAME = "Wearable script";
key myCreator;
key targetAttachment = NULL_KEY;
integer attListenHandle;

loadScript()
{   
    targetAttachment = NULL_KEY;
    // Try to find an attachment that matches signature attributes
    list attList = llGetAttachedList(llGetOwner());
    integer attIdx = llGetListLength(attList);
    while ((NULL_KEY == targetAttachment) && (0 <= --attIdx))
    {
        key att = llList2Key(attList, attIdx);
        list attSignatures = llGetObjectDetails(att,
            [ OBJECT_CREATOR    // some criteria for match
            , OBJECT_NAME
            ]);
        if ((myCreator == llList2Key(attSignatures, 0))
            && ("Wearable" == llList2Key(attSignatures, 1)))
            targetAttachment = att;
    }
    if (NULL_KEY != targetAttachment)
    {
        llListenRemove(attListenHandle);
        attListenHandle = llListen(ATT_SCRIPT_CHANNEL, "", targetAttachment, "");   // for wearable to report its detachment
        llRemoteLoadScriptPin(targetAttachment, LOAD_SCRIPT_NAME, MY_SECRET_PIN, TRUE, ATT_SCRIPT_CHANNEL);
    }
}
default
{
    state_entry()
    {
        myCreator = llGetCreator();
    }
    attach(key id)
    {
        if (NULL_KEY == id)
        {
            if (NULL_KEY != targetAttachment)
            {
                llRegionSayTo(targetAttachment, ATT_SCRIPT_CHANNEL, "delete script");
                targetAttachment = NULL_KEY;
            }
        }
        else
        if (NULL_KEY == targetAttachment)
        {
            loadScript();
            if (NULL_KEY == targetAttachment)
                llOwnerSay("Click to sync after you attach Wearable");
        }
    }
    touch_end(integer num_detected)
    {
        loadScript();   
        // Want such a manual "resync" method for when wearable attached after HUD
    }
    listen(integer channel, string name, key id, string text)
    {
        llOwnerSay(name+" "+text);  // debug
        if ("wearable detached" == text)
        {
            targetAttachment = NULL_KEY;
            llListenRemove(attListenHandle);
        }
    }
}

// Example "Wearable script" to be loaded by HUD to a non-HUD worn attachment

integer att_script_channel;

default
{
    state_entry()
    {
        att_script_channel = llGetStartParameter();
        if (!att_script_channel) // Don't run unless remotely loaded
            llSetScriptState(llGetScriptName(), FALSE);
        else
            llListen(att_script_channel, "", NULL_KEY, "");
            // could negotiate on channel to filter only for HUD object that loaded us
    }
    attach (key id)
    {
        if ((NULL_KEY == id) && att_script_channel)
            llRegionSayTo(llGetOwner(), att_script_channel, "wearable detached");
        // whether attaching or detaching, this script shouldn't be here now
        llRemoveInventory(llGetScriptName());
    }
    listen(integer channel, string name, key id, string text)
    {
        if ("delete script" == text)
            llRemoveInventory(llGetScriptName());
        // else process the usual HUD-to-wearable chatter
    }
}

They've hardly been tested, but I hope they illustrate the general idea I was mumbling about.

This would be a very good day if these were the most Rube Goldberg scripts I worked on today. That is, however, a very low bar. Anyway, I'm not sure only "minimal gain" is at stake; it seems better than putting users through the angst* of pressing the dreaded "delete scripts" button.

_______________
*"Have I saved a copy or just attached from the package? Did I save the package? Does this creator have a redelivery terminal? Does that terminal still work?"