which is better? 2 specific llListens or 1 all purpose llListen?

Way cool, thanks. The timings look wrong though.

Okay, this is only my third day on SL, and I'm in the midst of trying to learn how to script, so I want to make sure I have this all right at the beginning.

Here's a little code I wrote earlier in the day for listening. Somebody said something about running the listen as a variable and using an end listen.. how and why would I do this? What does it mean? Here's what I have so far:

state Listening
{
    state_entry()
    {
	llListen(1, "", llGetOwner(), "");						

	llSay(0, "Speak to me by first typing /1");		
	llSay(0, "For example:  '/1 Hello'");				
    }

	
    listen(integer channel, string name, key id, string message)  
   {
	if(message == "Hello")
            {
                llSay(0, "Hi!");
            }        
    
        else if(message == "Bye")
            {
                llSay(0, "Bye!");
            }
   }
}
        

Thanks in advance for the help.

Lorenzo -

What you have looks OK - not great, but not bad. The thing is, often people have different "states", or multiple listeners active at different times in their script.

When you want to do this sort of thing, its important to remove your listeners when you are done with them, or no longer want them active.

See this section of the LSL Wiki:
http://secondlife.com/badgeo/wakka.php?wakka=llListen

In short, use something like this to start a Listener:

//As a global variable declared outside the "default" mode:
integer g_listenHandle;
.
.
.
//Start Listening on channel 1
g_listenHandle  = llListen( 1, "", llGetOwner(), "" );

And then something like this to turn it off - like in your "state_exit" events or similar situations:

//Remove Listener
llListenRemove(g_listenHandle);
g_listenHandle = 0;

Note that calling "llListenRemove()" even when no listener is active, is OK.

In your case, this object doesn't have any llListenRemove() calls - so the way you have it set up, there will always be a listener active, if it has ever been put into the "Listening" state in the past.

The listener will be "changed" (i.e. a new one will start) every time you enter this mode again. Technically your code is leaving "old" listeners running when the script state is changed. Since you don't currently store the handle from your llListen() call, you can never retrieve the "old" listener - but what I would recommend, is something like this:

integer g_listeningStateHandle;

state Listening
{
    state_entry()
    {
	//Remove any old listeners, in case they're active still
	llListenRemove(g_listeningStateHandle);

	g_listeningStateHandle = llListen(1, "", llGetOwner(), "");						

	llSay(0, "Speak to me by first typing /1");		
	llSay(0, "For example:  '/1 Hello'");				
    }
.
.
.
    state_exit()
    {
	//Remove the listener I set up in state_entry()...
	llListenRemove(g_listeningStateHandle);
    }

...Oh, and in the future, feel free to post your questions by starting a new thread.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

Tread... listens are removed when you leave a state. So are other callbacks such as timers.

Personally, I see nothing wrong with leaving them around for the LSL interpreter to clean up when I leave states. There is no need to remove your listens manually in state_exit, and if you have another need to remove them, ie a one-shot listen... well, maybe you might want to see if you could break it up into sub-states.

Lex -

I knew there had to be a mechanism to keep them from clogging up the works (but I didn't want to get into gory details with his answer)...

But I could swear I've read in some Scripting Compendium in SL that Listens and Timers are not removed during state changes...

*rummages around the 'net*

A-ha! Check out the llSetTimerEvent() entry in the LSL Wiki:
http://secondlife.com/badgeo/wakka.php?wakka=llSetTimerEvent

"The timer persists over state changes, but gets removed when the script is reset."

...But from further reading on the Wiki, I see that the persistance of listens over state changes was a bug, & removed in 1.3... So I guess it was a case of bad (or old) in-game documentation I ran across originally.

Thanks Lex!

Take care,

--Noel "HB" Wade
(Tread Whiplash)

Well... I'm not sure I trust the wiki in this case. I'll test the timer thing out later today. I would definitely consider it a bug if they did persist over state changes, especially after they stopped letting listens persist because that was a bug.

Oh, check this out:

http://secondlife.com/badgeo/wakka.php?wakka=State



I take "all callback settings" to mean timers, too. Either way, one of these is incorrect...

Actually, timers work across states. At least according to the wiki.

One *major* difference:
say/listen tops out at 255 characters.
link messages will transmit a lot more -- i've sent 10,000 character messages successfully.

255 is a very low number for chat messages, imo, and very limiting.
for one of my projects, it's easier for me to:
rez a new object
link it
spam it with link_messages
unlink it.

which is silly, but oh well.

OK, there is one potentially bad thing about LM's that just occurred to me:

If you have 100 prims, with a couple of scripts in each one, a Link-Message is going to be processed by an awful lot of scripts. Granted, listeners have this same pitfall, on an even larger scale... But I don't want people to get too over-confident about LMs. All other things being equal, the more scripts you have linked together, the less efficient LM's probably become relative to llListen() calls... But I'm betting you need a large number of scripts receiving an LM to make it slower than an llListen() - again, does anyone have a free afternoon to test?

I often use the "key" parameter with a small string to identify which script is sending the LM, so I can use an "if" statement to skip over the entire event, in scripts that don't need to process certain LM's.

Take care,

--Noel "HB" Wade
(Tread Whiplash)

Time Dilation 1.0
Sim FPS 1913
Main Agents 3
Active Objects 221
Active Scripts 259
Sim CPU 0.50

drown(){
    llDie();
}
default{
    state_entry(){
        llListen(0, "", NULL_KEY, "");
    }
    
    listen(integer channel, string name, key id, string message){
        if(message == "Never let go."){
            drown();
        }
    }
}

Shift copy 100 of them.

sim dips to...

Time Dilation 1.0
Sim FPS 864
Main Agents 3
Active Objects 319
Active Scripts 357
Sim CPU 0.50

wait a few moments and sim goes to..

Time Dilation 1.0
Sim FPS bounces between ~1840 and ~1250
Main Agents 3
Active Objects 319
Active Scripts 357
Sim CPU 0.50

run..

integer chan = 0;
default{
    touch_start(integer total_number){
        integer i;
        for(i = 0; i < 100; i ++){
            llSay(chan, "Im sayin sumthin.");
        }
    }
}

Sim FPS stays around 1800 and Dips to 200 when the loop is done.

run 2 more times...

sim stays at ~1200 whole time

sim drops just below 1k and then bounces back to ~1400


changed code to llSay on channel 1.

integer chan = 1;
default{
    touch_start(integer total_number){
        integer i;
        for(i = 0; i < 100; i ++){
            llSay(chan, "Im sayin sumthin.");
        }
    }
}

1. sim bounces between ~1200 and ~1500
2. from ~1100 to ~1200
3. ~1100 - 1200

Sim appears to be running at around 1300 steady now.

Child agents while b4 was 0 is now also 3..

Time Dilation 1.0
Sim FPS 1300
Main Agents 3
Child Agents 3
Active Objects 320
Active Scripts 358
Sim CPU 0.50


...

Now 100 llListen's on channel 1.

Time Dilation 1.0
Sim FPS 1900
Main Agents 3
Child Agents 3
Active Objects 319
Active Scripts 357
Sim CPU 0.50

run loop on channel 1.

1. ~1600 to ~1800
2. ~1500 - ~2000
3. ~500 - ~2000

Loop on 0.

sim is at..
Time Dilation 1.0
Sim FPS ~1900 - ~1500 jumping again.
Main Agents 3
Child Agents 3
Active Objects 321
Active Scripts 357
Sim CPU 0.50

1. ~1700 - ~1300
2. ~1700 - ~240
3. ~1200 - ~1600


2 mins after all tests, prims still rezed.

Time Dilation 1.0
Sim FPS ~1500
Main Agents 3
Child Agents 3
Active Objects 319
Active Scripts 357
Sim CPU 0.50


said "Never let go."
wait a min.

Time Dilation 1.0
Sim FPS ~2300 - ~1500
Main Agents 2
Child Agents 2
Active Objects 218
Active Scripts 257
Sim CPU 0.50

It appears theres definetly sim preformance drops with listens, But it seems to do so regardless of channel Or what channel u talk on.

Yeah, this is true, but you can always send your link messages directly to specific prims via the link number, rather than just sending it to every prim with LINK_SET. I have about 200 prims, each with one script waiting for link messages (WHEN will we get llSetLinkTexture()??). When I loop through and message each in turn, it isn't horribly laggy... it does take awhile though.



Well, if you have only one script per prim, you can just use the first integer argument to the link_message event to determine how to process messages. That number is the link number of the prim that sent the message.

Nice work.