Jump to content
TechDave

Listen to Nearby Chat....

Recommended Posts

OK.. I'm a beginner here.. tho do know enough to be 'dangerous' with scripting. I've search library for what I'm seeking but didn't find anything. I THINK it's a simple addition to my overall project. 

I want a script to 'listen' to Nearby Chat for a specific 4 letter word. When word is entered, then I want to 'continue' to do next task... then reset to idle listening again. 

1.. Listen for WORD

2. WORD is entered... so continue

3. Do next thing (got script for this... basically.. Get Data and OwnerSay)

4. Return to Listen for that WORD again. 

May be heading into the tutorials if I can't find anything, which is what I should do.. but I thought I'd ask here first!  Thanks for any comment/help!! 

Share this post


Link to post
Share on other sites

It's a very simple matter.  In the listen event, simply include a conditional test
 

if ( llSubStringIndex( llToLower(message), "word" ) != -1 )
{
    // Do something
}

where "word" is your designated word, typed all lower case.  However ..... you should be aware that keeping an open listener on the PUBLIC_CHANNEL (channel 0) puts a demand on the region servers that can create measurable chat lag for others, especially if there are many people within chat range.  This sort of script is quite generally frowned upon, so ask yourself seriously whether this is necessary.

Edited by Rolig Loon
  • Like 2

Share this post


Link to post
Share on other sites

OR you could set your listen to filter (listen) for just that word:

llListen(PUBLIC_CHANNEL, "", NULL_KEY, "word");

Then you would not need the conditional check in your listen event, and said event code is not firing constantly when people are speaking nearby .. you do lose the flexibility that Rolig's method hase, my example will not hear 'Word', 'WORD', 'word ' etc., nor will it hear it as part of an overall statement ... only 'word'

And Rolig's statement regarding the load and lag is very, very true. You might want to pair this with some sort of sensor so that the object only starts to listen when someone is withing chat range (20m).

  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, TechDave said:

4. Return to Listen for that WORD again. 

LSL is an event-based language. There's no need to return to listen. It keeps on listening whenever the listen event is triggered. And it will keep responding.

Share this post


Link to post
Share on other sites
12 hours ago, Rolig Loon said:

.  However ..... you should be aware that keeping an open listener on the PUBLIC_CHANNEL (channel 0) puts a demand on the region servers that can create measurable chat lag for others, especially if there are many people within chat range.  This sort of script is quite generally frowned upon, so ask yourself seriously whether this is necessary.

Yes... I did sort of assume demand on servers... especially for what little it is. The data is just a region 'status' at moment, called by me and given to me. Wanted to keep coding and loads LITE on all... (especially ME!).

This morning I have it working with Touch, and that's FINE. Wearing it as a HUD helps.. don't need to cam in order to touch it. 

Thanks ALL!! for comments and advice!!  I was so at a mental block there yesterday when digging thru libraries of avial. scripts.

Share this post


Link to post
Share on other sites
7 hours ago, Wandering Soulstar said:

OR you could set your listen to filter (listen) for just that word:


llListen(PUBLIC_CHANNEL, "", NULL_KEY, "word");

Then you would not need the conditional check in your listen event, and said event code is not firing constantly when people are speaking nearby .. you do lose the flexibility that Rolig's method hase, my example will not hear 'Word', 'WORD', 'word ' etc., nor will it hear it as part of an overall statement ... only 'word'

And Rolig's statement regarding the load and lag is very, very true. You might want to pair this with some sort of sensor so that the object only starts to listen when someone is withing chat range (20m).

That's going to work only when someone says "word" on its own, rather than part of a phrase or sentence.

That is, if you set up a listener like

llListen(0,"","","Innula"); 

it's not going to hear "Hello, Innula."

Share this post


Link to post
Share on other sites
On 2/1/2019 at 11:58 AM, TechDave said:

Yes... I did sort of assume demand on servers... especially for what little it is. The data is just a region 'status' at moment, called by me and given to me. Wanted to keep coding and loads LITE on all... (especially ME!).

This morning I have it working with Touch, and that's FINE. Wearing it as a HUD helps.. don't need to cam in order to touch it. 

Thanks ALL!! for comments and advice!!  I was so at a mental block there yesterday when digging thru libraries of avial. scripts.

For the sake of making this post complete for beginner scripters that might look up this post in the future: the OP describes a use case that - if you want to implement it with a listener - would not need to operate in open chat. It should be perfectly fine to speak to the object on another channel and t hus creating less lag...

Quote Edit

Share this post


Link to post
Share on other sites
On 1/31/2019 at 10:32 PM, Rolig Loon said:

 


 

..... you should be aware that keeping an open listener on the PUBLIC_CHANNEL (channel 0) puts a demand on the region servers that can create measurable chat lag for others, especially if there are many people within chat range. 

That was the case years ago, not any more. Scanners are the bain.

Share this post


Link to post
Share on other sites
1 hour ago, steph Arnott said:

That was the case years ago, not any more. Scanners are the bain.

As before, on open listener on channel 0 in a crowded text-chat area is going to force the script to run whenever there's chat and that still incurs substantial overhead. What's changed is that, with Mono, it can be relatively less expensive for the running script to filter out irrelevant chat compared to the ancient LS0. (And I suppose Voice made some avatar-crowded areas less chat-intensive than they once were.)

I don't know what "scanners" are in this context. If this refers to a hypothetical script that turns on a listener only when avatars are within range, yeah, that would be the worst of both worlds because you incur the overhead of the sensor (or other avatar location-tracking) and then activate the listener just when it may incur processing too. (That said, sensibly scheduled repeated sensors can be pretty cheap especially if they can filter results externally to avoid activating the script; obviously a no_sensor() event handler defeats that particular efficiency.)

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, Qie Niangao said:

As before, on open listener on channel 0 in a crowded text-chat area is going to force the script to run whenever there's chat and that still incurs substantial overhead. What's changed is that, with Mono, it can be relatively less expensive for the running script to filter out irrelevant chat compared to the ancient LS0. (And I suppose Voice made some avatar-crowded areas less chat-intensive than they once were.)

I don't know what "scanners" are in this context. If this refers to a hypothetical script that turns on a listener only when avatars are within range, yeah, that would be the worst of both worlds because you incur the overhead of the sensor (or other avatar location-tracking) and then activate the listener just when it may incur processing too. (That said, sensibly scheduled repeated sensors can be pretty cheap especially if they can filter results externally to avoid activating the script; obviously a no_sensor() event handler defeats that particular efficiency.)

I am refering to repeat llSensor scans. The listen issue is old hat. An open 0 channel has very little affect on server resources and has not done so for several years. The issue was not much to do with the sim servers any how it was the internet infrastructure. In order to cause actual sim lag it is the result of bad code, old code, rediculouse sensor repeats and anything that the server has to constantly repeat and evaluate garbage. An open com on zero does not cost anything. 

Share this post


Link to post
Share on other sites

I give up trying to tease this apart. There's simply one overwhelming consideration affecting sensors, listeners, and everything else: Saving resources means minimizing events that awaken the script.

The sim can do a tremendous amount of background filtering using fewer resources than a single script-awakening event. So, open listeners are cheap on channels and at locations where chat is rare. Sensors can repeat many times without a hit for less cost than ever once firing a sensor() event (as long as there's not a no_sensor() event waking the script on each repeat).

To be sure, scripts use some sim resources even if not running (memory), if no event handlers are active (scheduler), and if there are handlers for which no events fire (filtering), but it takes events handled to really burn script time.

(The other big exception is the arrival of scripts into a sim, which consumes resources disproportionate to the steady-state demands of those scripts.)

  • Like 1

Share this post


Link to post
Share on other sites
46 minutes ago, Qie Niangao said:

 

I agree, scripts can and do spike the the load on entry, but once established a listen open pipe is minimal server load.

Share this post


Link to post
Share on other sites
21 minutes ago, steph Arnott said:

once established a listen open pipe is minimal server load.

Unless it is listening on the PUBLIC_CHANNEL.  I refer you to the LSL wiki for llListen, where you will find

  • Avoid channel zero (PUBLIC_CHANNEL) and set name or id where possible to avoid lag. llListen(0, "", NULL_KEY,"") can be laggy as it listens to all chat from everyone in chat range and so should be avoided.
  1. Chat that is said gets added to a history.
  2. A script that is running and has a listen event will ask the history for a chat message during its slice of run time.
  3. When the script asks the history for a chat message the checks are done in this order:
    • channel
    • self chat (prims can't hear themselves)
    • distance/RegionSay
    • id
    • name
    • msg
  4. If a msg is found then a listen event is added to the event queue.
So, the region servers check first to filter a message to see whether it was sent on the specified channel.  If it was not, they look no farther. When they do find one, they continue down the stack of filters in item #3 above., only stopping when they have found that the specific message does not meet the filter criteria and therefore should not be added to the even queue.  If your script has specified that it is listening on the PUBLIC_CHANNEL, then all chat generated by avatars will pass that filter.  On a busy region, that means a lot of messages will pass the first filter before the servers even get to checking to see whether the speakers are within chat range, and so on.
The bottom line is that opening any listen handler costs some server resources, but opening a listen handler on PUBLIC_CHANNEL uses significantly more, especially if there are many avatars sending chat messages.  Hence the general advice to avoid listening on PUBLIC_CHANNEL if you can. 
 
Is it worth fretting over a lot?  Probably not, particularly on a sparely populated region, but if many scripters started ignoring the advice, we'd have a worse chat lag problem on busier regions.  Therefore, please don't.
  • Like 3

Share this post


Link to post
Share on other sites
3 minutes ago, Rolig Loon said:

Unless it is listening on the PUBLIC_CHANNEL.  I refer you to the LSL wiki for llListen, where you will find

  • Avoid channel zero (PUBLIC_CHANNEL) and set name or id where possible to avoid lag. llListen(0, "", NULL_KEY,"") can be laggy as it listens to all chat from everyone in chat range and so should be avoided.

Sorry to inform you but this is 2019 and not 2007.

Share this post


Link to post
Share on other sites
11 minutes ago, Rolig Loon said:

Thanks, Steph. And the advice remains the same.  🙂

Ten years out of date and i can not believe with the rapid advance in computer tech and coms that you truely believe what you are saying. Any how it has no valid statistical proof it makes any difference, but SL is not real life so ....

Edited by steph Arnott

Share this post


Link to post
Share on other sites
16 hours ago, steph Arnott said:

Ten years out of date and i can not believe with the rapid advance in computer tech and coms that you truely believe what you are saying. Any how it has no valid statistical proof it makes any difference, but SL is not real life so ....

I have not run any test on the issue and I don't plan to. But Rollig has (past) evidence to back up her advice and you have your opinion. Unless there is new evidence, I will stick to good practises, especially when it doesn't make a difference for the use case.

  • Like 1

Share this post


Link to post
Share on other sites
13 minutes ago, Estelle Pienaar said:

I have not run any test on the issue and I don't plan to. But Rollig has (past) evidence to back up her advice and you have your opinion. Unless there is new evidence, I will stick to good practises, especially when it doesn't make a difference for the use case.

 Channels establish on sim entry. Also an 'opinion' is not based on factual data. The bulk of the server is agent tracking and com channels are way down the priority list. Voice is far greater a resource issue than an open channel. As for past evidence, my broadband runs at ten times the speed it did in those past days, do i use ten year old tech in todays analysis? No of course i do not. The issue is not whether a channel is open, it is if it is being closed and openned many times. That is when the hit takes place.

Edited by steph Arnott

Share this post


Link to post
Share on other sites
40 minutes ago, steph Arnott said:

 The issue is not whether a channel is open, it is if it is being closed and openned many times. That is when the hit takes place.

Rolig has explained to you earlier that this is not true. The hit also takes place in the process of filtering the chat messages. You might have missed these explanations which are cited from official SL documentation. Or it's your personal opinion that this documentation is out of date and you and everyone else can disregard them, but you have no evidence for it apart from your personal guesses.

However, despite this discussion somewhat going in circles, I do appreciate your oposition to established best pratices. It might be a good idea to go to an LL content creators meeting and ask the question if this information is still valid or outdated. Another way of testing would be to go to a crowed sim, observe the chat and chat lag for a bit. Then wear about 50 attachments which have listeners to the public channel and see if any chat lag arrises. If any chat lag occurs, then the rules are still valid. My personal bet would be that chat lag will appear, but who knows... PS: I guess that the number of about 50 listeners at public channel should be realistic if every scripter would make all  of their objects listen to user input on the public channel.

Edited by Estelle Pienaar
  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, Estelle Pienaar said:

 

The script writter needs to establish what usage the channel is used for. My channels in my sim disconnect on a timer if not used after say five mins. If the script is in periodic use then closing the com will use more resources than leaving it open. Another issue is many do not use the llListenRemove( ) correctly. They ineffect are closing nothing.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...