llListen integer returned?

[Gregory McLeod]

Is there any circumstance when the integer returned from a llListen(channel,"",NULL_KEY,"") is negative?

If so when and why?

[Gregory McLeod]

Please ignore this question I have found the answer.

memo to self read the WHOLE decription before asking stupid questions.

It is assigned starting at 1 so never negative.

[PeterCanessa Oh]

The only stupid question is the one you don't ask - we all have forehead-slapping moments :-)

@ All: Here's my stupid question inspired by carefully reading the llListen() wiki page (which I probably haven't done before) thanks to this thread -

The wiki page (in notes) says, "The integer returned can be assigned to a variable (then called a handler) ..." and continues to refer to this as a handler, which I believe is incorrect.  This might be a bit abstruse so apologies to everyone, but in the interests of accuracy:

• This value should be known as the llListen() handle - it is the means by which the script holds on to the llListen filter reference
• The function that handles an event - such as listen() - is an event handler

The big difference is that you use a handle to manipulate the llListen() itself - llListenRemove(), llListenControl() - and a handler - listen() - to handle the events that arise from it.

So, my question is - should I edit the wiki or does everyone prefer the way it is?

 

[Madelaine McMasters]

---

PeterCanessa Oh wrote:

The only stupid question is the one you don't ask - we all have forehead-slapping moments :-)

@ All: Here's my stupid question inspired by

carefully

 reading the llListen() wiki page (which I probably haven't done before) thanks to this thread -

The wiki page (in notes) says, "

The integer returned can be assigned to a variable (then called a handler) ..." and continues to refer to this as a handler, which I believe is incorrect.  This might be a bit abstruse so apologies to everyone, but in the interests of accuracy:

• This value should be known as the llListen() 
  handle
  - it is the means by which the script
  holds on
  to the llListen filter reference
• The function that 
  handles
  an event - such as listen() - is an event 
  handler

The big difference is that you use a

handle

to manipulate the llListen() itself - llListenRemove(), llListenControl() - and a 

handler

 - listen() - to handle the events that arise from it.

So, my question is - should I edit the wiki or does everyone prefer the way it is?

 

---

I don't care for the wording either, though it didn't seem to prevent me from understanding llListen well enough use it. But that's probably because I understood handlers and handles long before encountering LSL.

I think I'd change it on principle, as understanding the difference between a handler and its handle is of importance beyond llListen.

[Rolig Loon]

Agreed.  You aren't the first person to point this oddity out in forum conversations, Peter, but nobody has taken the time to change the language.  Go for it.

[PeterCanessa Oh]

2-0 in favour is good enough for me.  I didn't realise this had come up before.

[LepreKhaun]

Make that 3-0. Good catch that.

[steph Arnott]

And i still do not understand, 

[Rolig Loon]

A handle is handled by a handler.  A handle is something that you hold onto.  A handler is someone or something that holds onto a handle.  :smileywink:

[steph Arnott]

That still does no explain what difference is from this integer chat_chan 	= 20;integer chat_chan_handle;chat_chan_handle = llListen(chat_chan, "", ownerid, "");and this integer chat_chan 	= 20;llListen(chat_chan, "", ownerid, "");just seems to me exta lines to say the same thing.

 

[Qie Niangao]

The handle returned by llListen() is what you need if you're going to use llListenRemove() or llListenControl().

Notice that it's not the channel that you -Remove or -Control, but rather that handle.  There can be a bunch of active llListen()s on a single channel (for specific speakers or messages), controlled independently.

[steph Arnott]

integer chat_chan 	= 20;llListen(chat_chan, "", ownerid, "");llListenRemove(chat_chan)//So this is not removing the channel?

 ADDED.

integer my_handle;integer your_handle;integer everyones_handle;so if i  remove "your_handle" say they all on public and havea spesific word it will not hunt for that word any more,

llListen(0,"","","")//This is realy badllListen(0,"","","me")//This is betterllListen(-1000,"","","me")//This is even more better and so on.RegionSay is more efficient than whisper, say and shout and RegionSayTo is the most efficient and 

handles reduce lag even more by not have them in the que.?

Sorry i not a programer.

 I really wish i had never read this post, lol. Now i have to edit all my scripts.

 

[Rolig Loon]

That's not the question, Steph.   They are the same thing, but that's irrelevant.

What Peter is talking about, and the rest of us agree, is the English words we use to describe what's going on.  llListen provides an integer handle; that is, something that the script uses to hold onto the communication channel that has been opened.  Your script uses that handle to manipulate the communication.  The event or function that does the work is handling it, and is therefore a handler.  We're talking about clear usage of English words.

As an analogy, if I call you on the telephone, I am using your telephone number as a tag -- a handle -- to represent the connection between us.  Your telephone's hardware and software (and mine) are doing the work of making and maintaining the communication and are therefore handlers.

[Qie Niangao]

---

 I really wish i had never read this post, lol. Now i have to edit all my scripts.

 

---

Not necessarily. Well, if you were calling llListenRemove on a channel number instead of a handle, yeah, that's not going to work, but these listen filter optimizations are not such a huge thing anymore. Back before Mono, it was really expensive for a listen() event to be raised and cause the script to check deeper into the message to see if it really needed to do anything. It's still certainly best to avoid waking up a script unnecessarily, but it's nowhere near the huge penalty it used to be. So it's certainly bad to listen on channel 0 if one can possibly avoid it, but on obscure channels fiddling with message filters may not even be worth an extra llListen() call anymore.

[steph Arnott]

I accept what you saying, but not all of us are English speeking as a first language and it is not easy to understand when the person explaining knows exactly what they understand and expressing badley  to dumbo's like me.

ADDED: Not in the wiki or examples does it any were actualy  say what a handle does. I just been putting it in becouse eveeryone else does.

[steph Arnott]

ok, now i understand. Thanks.

[Rolig Loon]

---

steph Arnott wrote:

[ .... ]

Not in the wiki or examples does it any were actualy  say what a handle does. I just been putting it in becouse eveeryone else does.

---

Yeah, that's a good point.  And as Peter pointed out, it's made more confusing by the way the words are used.  Look at it this way, perhaps ....

Suppose that you and I each know where the other one lives. You'd think it would be easy to communicate by mail.  So, I send you a letter.  Unfortunately, so do hundreds of other people.  You are inundated with junk mail and you don't want to have to open all of that trash just to figure out which envelope contains a letter from me. How do you tell?  You look for my name in the corner of the envelope.  That's my handle, a brief descriptor that says, "This one is from me."  I can make my handle more specific by also writing my street address and my mail code on the envelope.  However I do it, though, the information in the corner of the envelope is your clue to who it's from.  As you look through your pile of mail, you are applying a mental process that says, "Nope, not that one .... nope, not that one either .....  Aha!  That one!"  You are using a handler to sort the mail.  Once you have found what you are looking for, you might say, "OK, now I donlt have to look for THAT letter any more."  If so , you are using a different mental handler to stop sorting the mail.

You're not dumb at all, Steph.  You understand the concept and have been using it correctly all along, and so have all the other scripters who trade ideas here.  We forget that the concept may be totally new to a beginner, and we make it harder to understand by being sloppy about the words we use.  I vaguely remember being confused about what llListen does when I started scripting LSL years ago. Despite the odd wiki wording, I must have figured out on my own that it is telling my listen event which return addresses to accept as it sorts messages.  Peter just wants to make it easier for others to figure out.

[steph Arnott]

Thankful for that. I find mental visual comparisons easier to grasp.

[PeterCanessa Oh]

I did say it might be a bit abstruse (= difficult to understand) Steph, it's not your fault   The problem is the English words "handle", a noun, something you hold onto and - spelt and pronounced exactly the same! - "handle", a verb, meaning to touch, examine or process.  In Rolig's example the person who brings your letters will, in the sense of the verb, handle them.  It is unlikely that your letters have a handle, in the noun sense, fixed onto them - although the postman's bag probably has.

[OK, I've re-read that and I'm not sure it makes any more sense now.  Sorry.  I'm trying]

These words have come into computer terminology for a variable reference to something - a noun handle - and as the function or procedure that processes a certain type of 'thing' - a handler of 'things'.  Specifically in LSL the events raised by SL.  This example will help, I hope:

integer PetersHandle;integer RoligsHandle;integer StephsHandle;default{    state_entry(){    	// 'Handles' - nouns - are references to something.  In this case 'listeners'    	PetersHandle = llListen(0, "PeterCanessa Oh", "", "");    	RoligsHandle = llListen(0, "Rolig Loon", "", "");    	StephsHandle = llListen(0, "steph Arnott", "", "");    	llSay(0, "I will only hear you once.");    }	listen(integer ChannelIn, string FromName, key FromID, string Message){		// An event handler, "handles" - verb - or processes the events that are raised		if("PeterCanessa Oh" == FromName){			llListenRemove(PetersHandle);			llSay(0, "OK, I'm not listening for Peter any more");		}else if("Rolig Loon" == FromName){			llListenRemove(RoligsHandle);			llSay(0, "OK, I'm not listening for Rolig any more");		}else if("steph Arnott" == FromName){			llListenControl(StephsHandle, FALSE);			llSay(0, "OK, I'm not listening for steph any more - but I will be again in a few seconds");			llSetTimerEvent(5.0);		}	}	timer(){		llSetTimerEvent(0.0);		llListenControl(StephsHandle, TRUE);	}}

 

 

[steph Arnott]

Now that is what can be understood  and should be on the wiki. Sorry al, i just was not getting it. LOL. 

[LepreKhaun]

Your confusion on this may be partly due to a bit of sloppiness LSL coders have in general. For instance, we constantly say "I have a listen event in this script" or "this touch_start event isn't working". But, strictly speaking, scripts don't have "events", they contain "event handlers" that may be triggered by events. No problem there though, we all know what the other is talking about when someone says "My dataserver event is acting up".

But the fact is that an "event handler" does have a specific definition in computer science but "event handle" doesn't. We might have easily agreed to call it the "event handler ID" or "listener registration number" and both would be technically correct, but "event handle" gets the job done just fine. In fact, it's a pretty good use of the word, since a "handle" is something you can grab and hold, which should be done with an event handler ID when it's presented by llListen(), which is technically a library function that registers a masked (Edit for correctness) filtered listener for the listen(){} event handler.

But mistakenly using "handler" instead of "handle" should be corrected, they are two distinctly different things.

[PeterCanessa Oh]

---

steph Arnott wrote:

...Sorry al, i just was not getting it. LOL. 

---

Nothing to apologies for Steph - it's a problem with English, not you.  It all gets worse when it's not just English but also twisted into computer jargon.  Then, to make it even worse, we have the potential confusion of llListen() versus listen(), 'listener' and 'listen filter'.

Glad you like the example, I think it works quite nicely because it shows the use of llListenRemove() and llListenControl() - plus another sneaky example of 'else if' - but I'm not sure about adding it to the wiki.  Too much explanation of English and 'commonplace' computer jargon would be out of place there.  Perhaps I'll put it on my own page, if I ever make one.

[LepreKhaun]

I agree that most of the problem arises within the English language itself, what with it's ambiguities and overloading a word depending on context. But part of the problem is also a great number of LSL coders have no background in programming. And who has time for learning the basic terminology of the craft when they're just trying to wade through over 400 library functions to write their killer tip jar app?!

 

The wiki does try to present all this as best it can but there is a need to balance things between users that are complete neophytes or coming from a strong programming background or coding in LSL for a number of years or simply a cargo-cult coder trying to do a quick hack of a freebie script they found. I guess the best one can do is to correct misuse of the terms that do have computer science definitions, try to be consistent in the common English terms that we use and hope those that get lost can find their way here, where any number of helpful people will try to explain things better.

[PeterCanessa Oh]

Yes, that's my thinking - the wiki is a great reference [resident-created like so much else of SL - thanks everyone, especially Strife (now I'm reminded by Rolig)] - but it is only meant to be a quick-lookup reference, not a complete guide to "how to programme in LSL, even if you don't know how to switch your computer on without help".  Pages like that which summarise rotations (http://wiki.secondlife.com/wiki/Rotation) are an absolute god-send for me because I can understand the code but never remember the maths (doh!).

For someone who isn't a programmer - or an LSL programmer - there are several tutorials (http://wiki.secondlife.com/wiki/LSL_Tutorial - plus, of course, the video-series currently being discussed in this forum).

If those don't answer the question or opinion is sought then, indeed, this is meant to be the place to come.  Other fora - outside LL's control - often do a better job for either beginners or the very experienced.  [Please name some, it's allowed and encouraged - I just don't have the RL time to join in and keep up!]

I just hope we're keeping each other honest and that we make sure our explanations make sense!

 

[Rolig Loon]

This has been an off and on theme of conversation here in the LSL forum for many years.  You're right that there is no good resolution, Leprekhaun.  We do have a solid cadre of professional programmers in SL, and they are responsible for much of the wiki's content.  Strife Onizaka has probably contributed more content than anyone and is responsible for maintaining its standard format and professional quality.  It's an ongoing challenge, and he has done a marvelous job.  It's no coincidence that it reads primarily like a technical manual. 

While there is a lot to praise in that work, however, there has always been a murmur of discontent from "amateur" LSL scripters --- those who are not computer science professionals in RL --- about how hard it is to understand the technical language if you are not one of the geeky few.  We often hear people complain that you can't follow the LSL wiki unless you already know what it says and are just looking to remind yourself of the more arcane details. 

There's no good way to resolve these two perspectives.  A helpful scripting resource needs to be clean, consistent, and as free as possible of ambiguity.  That argues against fluffy language and long-winded explanations --- precisely the traits that many early LSL scripters liked about the OLD LSL wiki. Adding many good, brief examples has helped to make the wiki more approachable.  Strife, in particular, has made a great effort to clean up confusing language and unnecessarily complex tables.  Still, the wiki is clearly aimed at people who speak the language of professionals.

I am hardly one to argue against a geeky wiki.  I'm not a professional, but I have been programming in one language or another since the mid-1960s.  I'm the sort of oddball who reads technical manuals with fair ease, if not pleasure. I love scripting for the challenge of solving complex logic problems.  I do sympathize with the poor beginner who has to leap into the wiki feet first, though.  I suppose that's one reason why I hang around this forum as much as I do, and why many of the other familiar folks here do as well.  We were all new at this stuff once.