Tutorial: Script Listen to Owner + owner's Objects

The basic owner only listener is like this...

default
{
    state_entry()
    {
        llListen(0,"",llGetOwner(),"");
    }
    listen(integer channel, string name, key id, string message)
    {
        if (message == "start")
        {
            llOwnerSay("Starting...");
        }
    }
}

But if your building a item that is to listen to a remote object (HUD, or Relay) aswel as yourself, you might find this tutorial handy.

default
{
    state_entry()
    {
        llListen(0,"","","");
    }
    listen(integer channel, string name, key id, string message)
    {
        if(llGetOwnerKey(id) == llGetOwner())
        {
            if (message == "start")
            {
                llOwnerSay("Starting...");
            }
        }
    }
}

Notice "llListen(0,"","","";" does not list a owner! Leave this alone. There is no need for a owner. You may however still use another channel.

Notice "if(llGetOwnerKey(id) == llGetOwner())" was added? This will check if the object or person talking to it is owned by this scripts owner. All Agents own themselves! This is to filter out the listener. Everthing else is ignored!

I used this function in several attachments i've created for myself. Of course i dont keep the listeners perminently open hehe, This is just a example script. I know in many Script/Program languages theres more then 1 way to do a specific task (some shorter, some exactly the same but with different commands). This is just a basic example. If you have another idea for this, feel free to add it to this tutorial.

ADVICE: Make sure you don't use channel 0.. that ticks a lot of us off having to listen to all the spamming green text.

You might want to consider posting this on the wiki. It probably needs a tutorials/projects category anyways.

/me nods
sounds like good idea.

And also, please, _please_ include llListenRemove. People don't do that a lot these days, and often end up registering Listener after Listener until the system stops you.

llListen(...) returns an integer value. Store in in a variable. Befor registering a new listener, check if you don't already have one running. Call llListenRemove(myListener) in the state_exit script. Since passing on a wrong listener ID to the script doesn't cause an error, you can even do something like:

integer myListener=0;

default 
{ 
    state_entry() 
    { 
        llListenRemove(myListener);
        myListener = llListen(1,"","",""); 
    } 
    listen(integer channel, string name, key id, string message) 
    { 
        if(llGetOwnerKey(id) == llGetOwner()) 
        { 
            if (message == "start") 
            { 
                llOwnerSay("Starting..."); 
            } 
        } 
    } 
}

Just.. please.. unless you are _very_ sure what you do, unregister your listeners again ^.^ In Yiffy's tutorial example, if I'd add a second state, start that state from the first, then fro m the second one go back to default state, it'd register a second listener. Next round, a 3rd. Until the script breaks with the message that it registered too many listeners.

Also, if you make this a public example.. you might wanna use a different channel than 0 for the start.. else too many people will just use it "as is".. and you'll end up by even more in-world objects that have to me commanded on the normal chat. Channel 0 listeners cause more stress to the server and more distress to the people around you that have to listen to your cryptic commands ^.^

*meow*
Sheila!

That would be a waste of server resources.



This is incorrect. Exiting a state always eliminates any open listeners. While removing listeners you don't need while in a state is a good idea it is unneeded and wastes CPU cycles in state_exit.

Test Script

default
{
    state_entry()
    {
        llListen(0,"","","");
    }
    listen(integer channel, string name, key id, string message)
    {
        llOwnerSay(message);
    }
    touch_start(integer total_number)
    {
        state test;
    }
}

state test
{
    listen(integer channel, string name, key id, string message)
    {
        llOwnerSay(message);
    }
    touch_start(integer total_number)
    {
        state default;
    }
}

*just read up on the LSL wiki about it*

I stand corrected.. hmm.. can it be that this changed somehow since 2004? That's when I started scripting with LSL, and back then I found it essentially necessary to unregister listeners again.. as far as I recall, I had some nasty issues with that back then. Strange.

*mews and is lost in deep thaughts*
Sheila!

Hmm. Being using this for a while now. Didn't realize it was tutorial-worthy.

Something more tutorial-worthy: NO MORE CHANNEL 0 LISTENS AND/OR SAY/SHOUT/WHISPERS!

Multigadget seems to be the one of the worst offenders of the latter issue (around my haunts, anyway), mainly because it is so popular. I don't need to know that someone is using an item, and could care less what version of it they are using to boot.

llOwnerSay has been around for a while now. Please use it!

*notes that her tutorial does use llOwnerSay, and that this was just a example*
If someone uses the script as is, its their own fault. I was trying to show a basic example (Nothing fancy). The reason i find this to be worthy of a tutorial is i wanted to help those who are creating HUD devices and such. I've been asked lately (since im a scripter) "How can i prevent my attachments from listening to other peoples HUDs?". This is the answer.

They did change what things are kept and released on state change a while back (a year agoi give or take 6 months).

states are a bit of a pain so I use llListenRemove alot.

Oh, definitely. I was mainly kinda making a general rail, more as suggestion along the same lines.

As you can tell, though, people don't often know to do the simplest things in scripts, and often end up cutting/pasting examples verbatim into something they end up selling. As such, I was more intending to suggest that, even in tutorials, we avoid some of the more common gotchas and script etiquette problems. After all, it is all about setting a good example, no?

So, I would recommend changing the listen to not use channel 0, in the example.