Multiple "listen-fors" within a listen command?

[Poocaz]

So, I have a prim with a basic listen script within it, and a command to rez a object when a certain command is typed into local chat. But, the thing is I would like that command typed in local chat to be in multiple forms. I would like to be able to type:

hi

hello

whatsup

hey

oi

ey

All of those in local chat and still rez the same object, like.... normally you tell the script to listen for one word in the specified chat, and if it heard it (if(message == w/e){ ) to execute the following command. So in the case of replying to an avatars greeting of "hi" with "wasup" on local chat it would be:

 state_entry()    

{        

 llListen(3,"", NULL_KEY, "");    

}

    listen(integer channel, string name, key id, string message)

{        

 if (message == "hi") {            

llSay(0, "Wasup");

          }

}

right? but for it to listen to multiple ones..... i put this in and it did not work

 

state_entry()   

{       

llListen(3,"", NULL_KEY, "");   

}

    listen(integer channel, string name, key id, string message)

{       

if (message == "hi | hello | hey | hola | oi") {           

llSay(0, "Wasup");

          }

}

I hope you guys get what i mean.... Sorry for the really long post for such a simple question lol :p

 

[Poocaz]

Apologies, the listener would be listening to channel 3 * in all those examples >.<

[Rolig Loon]

You can't write if (message == "hi | hello | hey | hola | oi").  That's not an allowed syntax in LSL.  You will need to separate your tests into a series of if ... else if .. else if ...else  tests.  Either that or write something like

 

list replies = ["Hi","Hello","Wassup","Hey","Oi","Ey"];if (~channel = llListFindList(replies ,[message]){     llSay(0,llList2String(replies,channel);}

 with appropriate cleanup to take care of upper/lower case variants....

 

[Darkie Minotaur]

For each 'or' part you would need to define the test:

if (message == "hi" || message == "hello" ....

 

Another way would be to make a ist as Rolig suggested

[Void Singer]

if (~llListFindList( ["hi", "hello", "hey", "hola", "oi"], [llToLower( llStringTrim( message, STRING_TRIM ) )] )){
    llSay( 0, "Wassup" );
}

ETA:
added string trim since it's a channel message instead of public, since people tend to put a space in.

[Helium Loon]

You have it almost right, but your syntax on your IF statement in your listen() is wrong.

 

Try:

 

if (message == "hi" || message =="hello" || message == "hey" || message == "hola" || message == "oi")

 

A better method would be to have a list of the words that match a certain condition, then check if it's in the list.

 

list hellos = [ "hi", "hello", "hey", "hola", "oi" ];state_entry(){    llListen(3,"", NULL_KEY, "");}listen(integer channel, string name, key id, string message){    if(~llListFindList(hellos, (list)message)    {        llSay(0, "Wasup");    }}

 

[Helium Loon]

(wow, everyone pounced on that one at the same time....)

[Void Singer]

and even with a shortened reply I was still only third lol

[Rolig Loon]

Hehe ... And I pounced fast enough that I didn't see the OP only wanted one reply instead of an echo of the triggering message.....  It's been a long day .....

[Poocaz]

wow, thank you guys ^^

I got it now

[LindaB Helendale]

 

One more note on multiple listeners.

If you listen fixed lines like "hey", "hi"  and you don't need to catch arbitrary lines starting with the word (such as "hi guys", "oi there"), it is more efficient to register a listen for each word, up to 65 listener per script. In that way matching the chat line to each word  is executed in the server when it decides whether to send the message to your script as listen-event, instead of your lsl-code doing it.

You can register the listens in a for loop from a list easily

nWords=llGetListLength(wordList);
for(i=0;i<nWords;i++)  {
llListen(  channel, "", NULL_KEY, llList2String(wordList,i) );
}

 

[Void Singer]

I'm going to recommend against that for at least two reasons

1) channel commands are normally (but not always) typed with a space after the channel. The space IS read as a literal and would cause a failure to trigger. when numbers are involved it's worse, since lack of a space will cause a leading number to be read as part of the channel (again causing failures. both of these can be avoided by using string trim in the listen event

2) fixed word listens do not ignore capitalization, so if expects "hi" and you type "Hi" (or vice versa) it fails, but this can also be caught in the listen event with to lower, or to upper.

3) specific message is the last item checked by the region when filtering listens, so the savings vs versaitly is extremely low. I only recommend using that format if you have no filters for name/key, and a re operating on the public channel (which you should already be avoiding at all costs) or it's a very specific limited use channel command (a few maybe, I'd say not more than a handful personally, since you still have to sort them on the other end.)

 

PS
has anyone recently verified 65 listens? I know both wikis state it, but it sure does taste wrong... 63, 64, those I might make sense of.... if someone does or has, adding a note to the wiki would be helpful.

[LindaB Helendale]

---

Void Singer wrote:

I'm going to recommend against that for at least two reasons

1) channel commands are normally (but not always) typed with a space after the channel. The space IS read as a literal and would cause a failure to trigger. when numbers are involved it's worse, since lack of a space will cause a leading number to be read as part of the channel (again causing failures. both of these can be avoided by using string trim in the listen event

 

The space between the channel and the first character and white space after the last character is trimmed off automatically when the message is sent to listen-event.

"/1 2"  will come as "2"  and  

"/1                     hi                         " will come in as "hi" ,

so listen for "hi" on channel 1 will trigger for "/1             hi     "  as well as for "/1hi".

 

2) fixed word listens do not ignore capitalization, so if expects "hi" and you type "Hi" (or vice versa) it fails, but this can also be caught in the listen event with to lower, or to upper.

Yes, if you have fixed list with several versions, they need to be listed. 

 

3) specific message is the last item checked by the region when filtering listens, so the savings vs versaitly is extremely low. I only recommend using that format if you have no filters for name/key, and a re operating on the public channel (which you should already be avoiding at all costs) or it's a very specific limited use channel command (a few maybe, I'd say not more than a handful personally, since you still have to sort them on the other end.)

All the previous checks are done for both fixed listen and open listen, so it would not matter that it's the last item, for comparing those two, and the server code would be more efficient doing the filtering than the lsl code. Basically there's the same stuff that is to be done, either in the server code before triggering the event, or queueing the event, running the script, and doing the filtering in lsl, so if there's any number of false positives that the lsl code would reject, doing it without triggering the event would save resources.

But of course it's useful only if the list of words  is limited. Yet so many scripts listen in public chat for fixed commands "hide", "show", etc with  open listen and filter them in the listen-event.

 

 

[Void Singer]

I wasn't aware that they added trimming behavior to the client (I'm assuming it's in the client rather than a server filter on avatar chat, as the behavior is not the same if the chat comes from a script). I can't say for certain all clients exhibit that, although phoenix and the VaniLLa client do (just tested). thanks for pointing that out though, I hadn't realized there was a change there (at one time I did a secret command version with trailing spaces, so I know it didn't always trim). I'll update the wiki with that info.

however, I don't see opening 4 listens for each two letter command as particularly helpful, since it's 4 tests (hi,Hi,hI, and HI) for the region to match against, when all of them are acceptable to the script with basic clean up, and who knows how many other scripts doing the same on that channel. it gets worse the longer the command is.

the tradeoff for speed vs versatility isn't about just the speed, it's about what you can do not taking advantage of the speed, such as accepting multiple forms of the same command, and also updating the code to use multiple commands, or command with value. and when you do have multiples with different actions you still have to filter out which command gets which action, so you lose most of the savings having a region prefilter gives... not an issue for OP's design, but it is a very common design

I do agree that for dog common commands like show/hide, there is little reason not to prefer separate listens. since they are so standardized, people are very likely not to need or use any of the extra filtering.