Would changing Whisper, Say and/or Shout chat ranges break your content? The option to change these ranges is coming.

[Lucia Nightfire]

As per @Rider Linden at the last TPV meeting, estate owners/managers will soon be able to change chat ranges for Whisper, Say & Shout on a region. I IM'd Rider to get more details.

This will affect chat originating from BOTH agents & objects.

I filed this feature request in hopes content creators can get access to what these region values are in case an increase or decrease in any particular chat type's range will negatively affect their content.

I encourage those who know someone whose content might be affected to let them know as soon as possible as well as tell them to mention their concerns on the related jira in case I haven't covered them all.

Thanks.

P.S. Sorry for not bringing this to everyone's attention sooner as I only just saw the TPV meeting video this morning. I also wish LL would give us an early heads up about stuff they're working on that could potentially break content so concerns can be addressed.

Edited May 26, 2020 by Lucia Nightfire

[Innula Zenovka]

Thanks, Lucia.    

Certainly in the past when I've needed to be sure the transmitter and receiver are within 10 or 20 metres I've used llWhisper or llSay rather than llRegionSay and then checking the distance between the sender and receiver in the listen event.

Does this mean that those assumptions are now unreliable and I'll need to go back and insert distance checks?  

[Lucia Nightfire]

8 hours ago, Innula Zenovka said:

Does this mean that those assumptions are now unreliable and I'll need to go back and insert distance checks?

Distance checks for chat ranges that have been extended, maybe.

It would be emmensively great if LL implemented BUG-6012 so applications can know what kind of chat they are receiving.

But if chat ranges are reduced, you're applications that depend on llSay() and/or llShout() could miss chat, thus break.

Edited May 26, 2020 by Lucia Nightfire

[Innula Zenovka]

13 minutes ago, Lucia Nightfire said:

It would be emmensively great if LL implemented BUG-6012 so applications can know what kind of chat they are receiving.

Thanks.    But since it looks as if we'll need to rescript stuff anyway, what's the advantage to your suggestion rather than simply using a test like this in the listen event?

 

		if(llVecDist(llList2Vector(llGetObjectDetails(id,[OBJECT_POS]),0),llGetPos())<20.0){
				//do stuff
		}

What do we need the extra function for?

[Lucia Nightfire]

1 hour ago, Innula Zenovka said:

What do we need the extra function for?

For applications that react based off chat used.

Could be anything from gaming applications to moderation applications.

Differentiating Whispers,Says,Shouts,Regionsays,RegionSayTo's <5m, Says,Shouts,Regionsays,RegionSayTo's <20m, Shouts,Regionsays,RegionSayTo's <100m, Regionsay,RegionSayTo's of any distance.

[Kyrah Abattoir]

Yeah I second that, it's annoying that you can never be sure whether someone specifically targeted your script with regionsayto or not.

[Lucia Nightfire]

1 hour ago, Kyrah Abattoir said:

Yeah I second that, it's annoying that you can never be sure whether someone specifically targeted your script with regionsayto or not.

RegionSayTo targeting is a big concern on its own, yes.

[Innula Zenovka]

2 hours ago, Lucia Nightfire said:

For applications that react based off chat used.

Could be anything from gaming applications to moderation applications.

Differentiating Whispers,Says,Shouts,Regionsays,RegionSayTo's <5m, Says,Shouts,Regionsays,RegionSayTo's <20m, Shouts,Regionsays,RegionSayTo's <100m, Regionsay,RegionSayTo's of any distance.

Yes, I see that, but when you're trying to differentiate the various calls, you're really asking "how far away from the receiver is the transmitter?"    

At the moment, I find that out by calling llGetObjectDetails(id,[OBJECT_POS]) in the listen event and then calculating the distance between the sender and the receiver.    Then I know exactly how far away the sender was, and I can use that information as I choose.

What can my listening objects not already do using the method I describe that they will be able to do with your proposed new feature?

Edited May 26, 2020 by Innula Zenovka

[Lucia Nightfire]

1 hour ago, Innula Zenovka said:

Yes, I see that, but when you're trying to differentiate the various calls, you're really asking "how far away from the receiver is the transmitter?"    

At the moment, I find that out by calling llGetObjectDetails(id,[OBJECT_POS]) in the listen event and then calculating the distance between the sender and the receiver.    Then I know exactly how far away the sender was, and I can use that information as I choose.

What can my listening objects not already do using the method I describe that they will be able to do with your proposed new feature?

Can your open listen application determine if a chatting object 2 meters away is using llWhisper(), llSay(), llShout(), llRegionSay() or llRegionSayTo() ?

At the moment, applications can only "guess" if chat heard from >100m is either llRegionSay() or llRegionSayTo(), chat >20m is either llShout(), llRegionSay() or llRegionSayTo(), chat >5m is either llSay(), llShout(), llRegionSay() or llRegionSayTo() and chat <5m could be anything.

With the ability to increase chat range for whispers, says & shouts and decrease chat range for says & shouts, this throws all manner of "guessing" out the door.

Again, the necessity is determined by application or use case, not explicitly if the application hears the chat or not.

This is in regards to BUG-6012 only.

[Innula Zenovka]

1 hour ago, Lucia Nightfire said:

Can your open listen application determine if a chatting object 2 meters away is using llWhisper(), llSay(), llShout(), llRegionSay() or llRegionSayTo() ?

At the moment, applications can only "guess" if chat heard from >100m is either llRegionSay() or llRegionSayTo(), chat >20m is either llShout(), llRegionSay() or llRegionSayTo(), chat >5m is either llSay(), llShout(), llRegionSay() or llRegionSayTo() and chat <5m could be anything.

With the ability to increase chat range for whispers, says & shouts and decrease chat range for says & shouts, this throws all manner of "guessing" out the door.

Again, the necessity is determined by application or use case, not explicitly if the application hears the chat or not.

This is in regards to BUG-6012 only.

Well, no, but I don't see how your proposal tells me that, either.    

You wrote, "I am proposing the constants "whisper_chat_range", "normal_chat_range" & "shout_chat_range" be added to llGetEnv() so content creators can update their content to detect if these chat range values have been changed in the region their content is operating in."    

That tells me that, if I send a message using llSay, in what range objects or avatars will hear the message.    It doesn't tell me whether the object is using any particular function, only that if the maximum range for llWhisper on a particular region is  n, and I can hear an object that's more than n metres away from me, then it can't be using llWhisper.  

The only time I can imagine wanting to know what the maximum range is for llWhisper is if I don't want anyone outside that range to receive it, which I can do now to by calculating the distance between the sender and the recipient when then recipient does something that triggers the message (or when she's detected by llSensor or whatever) and then sending the message using llRegionSayTo only if the recipient is within however many metres I want it to be.     When else would I need to know it for a script?

[Lucia Nightfire]

1 hour ago, Innula Zenovka said:

Well, no, but I don't see how your proposal tells me that, either.    

You wrote, "I am proposing the constants "whisper_chat_range", "normal_chat_range" & "shout_chat_range" be added to llGetEnv() so content creators can update their content to detect if these chat range values have been changed in the region their content is operating in."    

That tells me that, if I send a message using llSay, in what range objects or avatars will hear the message.    It doesn't tell me whether the object is using any particular function, only that if the maximum range for llWhisper on a particular region is  n, and I can hear an object that's more than n metres away from me, then it can't be using llWhisper.  

The only time I can imagine wanting to know what the maximum range is for llWhisper is if I don't want anyone outside that range to receive it, which I can do now to by calculating the distance between the sender and the recipient when then recipient does something that triggers the message (or when she's detected by llSensor or whatever) and then sending the message using llRegionSayTo only if the recipient is within however many metres I want it to be.     When else would I need to know it for a script?

I think you're confusing two different feature requests. There is BUG-228816 & BUG-6012. What I just explained above is for BUG-6012 only.

In regards to BUG-228816, the reason we need access to "whisper_chat_range", "normal_chat_range" & "shout_chat_range" is to allow applications that currently depend on static ranges to decide whether to work, not work or work differently in an environment where those ranges have changed.

The example you gave entails known target(s)/recipient(s). What if an application doesn't have an explicit target? What if it is only meant to chat a message that only who/whatever within Whisper, Say or Shout range is supposed to hear? What happens when a object, whose creator has depended on whisper range being 5m max, uses a whisper in a region where the whisper chat range has been raised to shout distance or higher? With access to what the whisper range is, the creator can script the object to check this range and decide if the current range is acceptable to broadcast the message, to do nothing or to use a more resource intensive means, such as loop through a sensor or llGetAgentList() return, checking distances & sending regionsayto's to each. The same can be done whether chat ranges are increased or decreased: follow protocol, don't follow protocol, follow a different protocol.

I would rather creators have access to these values instead of being forced to set up their applications to use ONLY the resource intensive alternative method for assured operation.

 

Edited May 27, 2020 by Lucia Nightfire

[Mollymews]

do we know if the restriction is only on channel 0 ?  If so then I can see why Shout might be able to be varied.  Not getting why Whisper or Say would be

[Lucia Nightfire]

1 hour ago, Mollymews said:

do we know if the restriction is only on channel 0 ?  If so then I can see why Shout might be able to be varied.  Not getting why Whisper or Say would be

There was a suggestion that it should only apply to channel 0 in today's Server UG, but there was no acknowledgement that that is the current restriction.

I asked @Rider Linden if he could list some bulletpoints of operation here later. Hopefully he will help us all to understand the finer points.

The one interesting operational aspect of the change is that allegedly only agents/objects in the same & adjacent regions can hear chat from within extended chat ranges. So for example, if you raise whisper, say & shout all to 512m or even 4096m and chat near the region border, no agents/objects 2 or more regions away will hear it.

Edited May 27, 2020 by Lucia Nightfire

[animats]

This is intended for large meetings. I suggested it apply only to channel 0 (the one users listen to). Everything else is machine to machine communications, and changing that will probably break something in a non-obvious way.

[sandi Mexicola]

This kind of change, without scripts being able to access what the new say distance is, would definitely break the HUD I scripted.  My HUD lets me know if people are within chat range.  I use it for hosting, and also I use it when I am out and about in SL to know if i am having  a private conversation with someone.  If chat ranges can be different for every sim, and cannot be checked with scripts, I will have to check manually every time I teleport somewhere and enter the new numbers into my HUD every time.  

Edited May 27, 2020 by sandi Mexicola

[Innula Zenovka]

10 hours ago, Lucia Nightfire said:

What if an application doesn't have an explicit target? What if it is only meant to chat a message that only who/whatever within Whisper, Say or Shout range is supposed to hear? What happens when a object, whose creator has depended on whisper range being 5m max, uses a whisper in a region where the whisper chat range has been raised to shout distance or higher? With access to what the whisper range is, the creator can script the object to check this range and decide if the current range is acceptable to broadcast the message, to do nothing or to use a more resource intensive means, such as loop through a sensor or llGetAgentList() return, checking distances & sending regionsayto's to each. The same can be done whether chat ranges are increased or decreased: follow protocol, don't follow protocol, follow a different protocol.

You ask, "What happens when a object, whose creator has depended on whisper range being 5m max, uses a whisper in a region where the whisper chat range has been raised to shout distance or higher?"

At present, whisper distance is 10 metres, so if I want to be sure that the sending object is no more than 5 metres away, I would use a filter like this

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

		if(llVecDist(llGetPos(),llList2Vector(llGetObjectDetails(id,[OBJECT_POS]),0))<5.0){
			//object is within 5 metres, so respond to it
		}
     	}                                                                                     
                                                                                           

What's confusing me is that I am trying to think of a reason why I would want to know what function a script is using to send my script a chat message unless I wanted to know the maximum possible distance it could be from the receiver, and since I can already easily tell exactly what that distance is anyway,  I'm struggling to see why I need to know the maximum range for llWhisper or llSay, so long as I know the script has received the message and how far away the sender was.    Since I know how far away the object is, and I can use that to decide whether the script should process the message, why do I need to know whether the object 7 metres away is whispering, saying, shouting or using llRegionSay?     

OK, if I know the range for llWhisper has been reduced to 5 metres on that region, I can exclude the possibility that the object was using llWhisper rather than any other chat function, but since I know exactly how far the object is away from the receiver anyway, I struggle to think why I would need to know that a message might have been sent by one function rather than another.

I mean, I receive a message from an object, and the script calculates it's 15 metres away.    Under what circumstances does it matter whether the message was sent using llSay or llShout?    All that tells me is the maximum distance away from which it could have been sent, but I already know the exact distance anyway.

The only time I can imagine needing to know that the range of llSay is vs llWhisper is if I want to have a greeter send a message, but since I can trap the recipient's ID in the event that triggers the message,  I would normally use that to check on the distance anyway and then, if I want to respond, use llRegionSayTo, so I don't spam everyone in earshot.

 

 

Edited May 27, 2020 by Innula Zenovka

[Kyrah Abattoir]

1 hour ago, Innula Zenovka said:

What's confusing me is that I am trying to think of a reason why I would want to know what function a script is using to send my script a chat message unless I wanted to know the maximum possible distance it could be from the receiver, and since I can already easily tell exactly what that distance is anyway,

Protocol strictness on my end

Until RegionSayTo became a thing for instance, the LockMeister reference specified that to avoid wasteful message processing in potentially busy areas, messages should under no circumstance be sent using llSay or llShout.

Personally? I'd love if there was a way for scripts to know which function was used to send a given message. Being unable to differenciate llRegionSayTo from all the other public broadcasts is frustrating.

[Innula Zenovka]

18 minutes ago, Kyrah Abattoir said:

Protocol strictness on my end

Until RegionSayTo became a thing for instance, the LockMeister reference specified that to avoid wasteful message processing in potentially busy areas, messages should under no circumstance be sent using llSay or llShout.

Personally? I'd love if there was a way for scripts to know which function was used to send a given message. Being unable to differenciate llRegionSayTo from all the other public broadcasts is frustrating.

Yes, I understand that, but ever since we've had llRegionSayTo -- several years now -- I've been using that function whenever possible , combined with distance checks in the sender or receiver script as appropriate, unless I really do want to broadcast a message to all potential receivers in the area rather than to the object I want to affect.

So if I want to chain someone with Lockmeister, I use llRegionSayTo since there's no point in having the simulator check all objects on the region listening on the Lockmeister channel to see how far they are from the furniture when I know which particular avatar's attachments I want to target.

 

 

[Kyrah Abattoir]

I agree but, with LM for example, we always HAVE to supply a target key as part of the payload, because there is no way to know if the message was for us or not.

Would be nice if we could know for sure "this script used our key in llregionsayto", maybe not for LM but for future protocols, it has always been weird being unable to know this.

Edited May 27, 2020 by Kyrah Abattoir

[Lucia Nightfire]

8 hours ago, Innula Zenovka said:

At present, whisper distance is 10 metres

Yes, I for some reason, keep thinking whisper is capped at 5m when it is indeed 10m.

 

8 hours ago, Innula Zenovka said:

What's confusing me is that I am trying to think of a reason why I would want to know what function a script is using to send my script a chat message unless I wanted to know the maximum possible distance it could be from the receiver, and since I can already easily tell exactly what that distance is anyway,  I'm struggling to see why I need to know the maximum range for llWhisper or llSay, so long as I know the script has received the message and how far away the sender was.    Since I know how far away the object is, and I can use that to decide whether the script should process the message, why do I need to know whether the object 7 metres away is whispering, saying, shouting or using llRegionSay? 

I think you're focusing too much on chat delivery itself and not on application type, use case or the possibility of better script efficiency.

Here's one example(there are most likely more) of a in-world application that tries to operate based on chat type: Shout Detectors

They are used in clubs, events or even sandboxes and are usually tied to moderation (warnings, ejects, send homes, tbans).

They are typically set up above the flow of traffic outside of chat range(20m) and inside of shout range.

These devices still check distance of a chatting agent/object and if they are greater than chat range(20m) it is assumed the agent/object is shouting.

What these devices cannot determine, though, is if an agent/object inside of chat range(20m) from the detector is shouting or chatting.

An agent/object inside this range could be shouting and agents within the detector's operation range would hear it, but the detector would not be able to do anything about it.

In this example, if the application had access to llChatType() it would not have to do distance checks at all, nor would it fail to detect a shouting agent/object closer than say range.

Again, this goes back to BUG-6012, a completely separate feature request from BUG-228816.

I've already explained that access to the chat range values requested in BUG-228816 would save people from only using resource intensive means for chat delivery.

One possible scenario I envision happening without access to these chat range values is a shift in chat usage standards, one that does away with using llWhisper(), llSay() or llShout() and instead focuses on llRegionSayTo() usage only. Granted, it won't be feasible for everything, but I see a big increase in its dependency because creators may have no choice. This may also be coupled with increased usage of llSensor() or llGetAgentList() followed by looping through results, consuming more script bytecode to handle events and more script memory to handle data returns, in-turn causing more resource intensive script usage than before/necessary. This comes from the good possibility that a lot of current content may break in the presence of variable chat ranges and creators will be rewriting scripts to address it. This is why I want to give them the tools they need now and not after the variable chat range feature is released.

The overall goal is script efficiency.

[Lucia Nightfire]

18 hours ago, Mollymews said:

do we know if the restriction is only on channel 0 ?  If so then I can see why Shout might be able to be varied.  Not getting why Whisper or Say would be

According to @Rider Linden in today's user group, channel has now been restricted to only 0 after evaluating concerns in yesterday's user group.

I assume this is for both agents and objects.

[Innula Zenovka]

3 hours ago, Kyrah Abattoir said:

I agree but, with LM for example, we always HAVE to supply a target key as part of the payload, because there is no way to know if the message was for us or not.

Would be nice if we could know for sure "this script used our key in llregionsayto", maybe not for LM but for future protocols, it has always been weird being unable to know this.

I'm not sure I understand, Kyrah (and I'm very conscious both that I'm risking going way off topic here and I've probably missed something really obvious) but I've always wondered why can't you use llRegionSayTo(kVictim,iLockMeisterChannel,command).

My cuffs should hear that, so long as they are attached.   And when the sender receives the confirmation, it can check the message is from my cuffs  with llGetOwnerKey(id) in the listen event.

As I say, it's probably obvious but I've never really dug that deeply into your system's internal workings -- I know how to script furniture using it, but that's not the same.

Edited May 27, 2020 by Innula Zenovka

[Kyrah Abattoir]

8 minutes ago, Innula Zenovka said:

I'm not sure I understand, Kyrah (and I'm very conscious both that I'm risking going way off topic here and I've probably missed something really obvious) but I've always wondered why can't you use llRegionSayTo(kVictim,iLockMeisterChannel,command).

I actually do and recommend doing so, I just have no way to know that the talking object did, and thus the first argument of a TB message HAS to be the targeted avatar.

Which wouldn't be necessary if we could just check who the message was sent TO.

[Anna Salyx]

I think one of the confusion points that is being danced around is that its less about what 'channel' (whisper, normal, shout) that my script is getting the message from (and I'm sure it is important to some) is I need to know if a given chat range is been reduced.  I have some project objects that whisper to child objects and avatars in close proximity, with the expectation that they will be within the 10 meter 'standard' range.  if that range is reduced to 5  meters then potentially things break if people or objects are placed at 6 to 9 meters from the central sending object.   Being able to check a region setting that tells what the whisper range is will allow me to have the script better understand if the broadcast is being received by all of the intended audience 

On the other point on being able to know the chat dynamic type (whisper, shout, etc): is an example of the chat extender that I use.  It hears the avatar, and checks the area and determines the distance each member of the intended audience from the speaker.  If they are in normal chat range (20 meters) that person is excluded from the relay and the message is only relayed to those that are > 20 meters.  When I accidentally whispers (which I do about 1/5 of the time) everyone 1 to 10 meters 'hears' me, those >20 meters 'hear' me via relay, but those >10 <=20 currently get nothing.  The relay assumes they heard it and doesn't serve it up to them. 

So, the ability to detect a whisper or shout that can be dynamically accounted for and would be of great help.  No more missed messages for those close in, and also no more duplicated messages for those further out: Oh the person shouted, I'll not relay to anyone inside the default (or current) shout distance.

Lastly and one important point:  as I understand it, the chat range changes are going to be region based only and not parcel based.  With this assumption the changes in chat ranges my not be that wide spread or might only be minimal.  Chat extenders, again for example,  might still have their place where some regions want to make only tiny changes to the default ranges (reduce or extend whisper and normal in some combination and tweaking shout or not as fits their needs), but parceled off places like clubs, classrooms, or lecture/presentation hall might need a different rule set and chat extenders might still be able to accommodate those situations.  I know I'm not going to want to be in renting a shop parcel and have the club parcel on the other side of the region "chatting" normally into my shop, so there are going to still be limitation to just how much chat ranges are extended based on regional make-up.  At least in my mind that will be the case. But If the chat range changes are going in a parcel level then that's a horse of a different color and ignore mos of what I said here.  lol 

Awyways, that's my thoughts on the matter while I still digest this news.

Edited May 27, 2020 by Anna Salyx
added a side/secondary thought about shops and clubs on the same region.

[Kyrah Abattoir]

As a region owner i know i would definitely try to reduce whisper range to 2 meters But not if it's also applied to non-zero channels.

It would also break a lot of "emote" systems that rely on whisper to relay textual cues that should be "visible" to people nearby. There is no real way for those to "ignore" the reduced whisper range, they would have to use either llSay/llShout (not a great idea) or to spam llRegionSayTo to everyone in close range, which is just inefficient.