Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007163opensim[REGION] OpenSim Corepublic2014-05-12 05:432014-07-29 13:43
Assigned Tojustincc 
PlatformOSUbuntuOS VersionUbuntu
Product Versionmaster (dev code) 
Target Versionmaster (dev code)Fixed in Version 
Summary0007163: Chat Issues: 1) Chat across region borders 2) Script chat always hearable
Description1) Chat across region borders

Possition two avatars next to a region border of two regions simulated by the same OpenSim process. These avatars need to be in chat range, while both avatars are on different regions. Then let one or both avatars send public chat messages to each other.

That works, but when these avatars move away from each other, the chat messages of these avatars are still hearable anywhere (!) on the other region.

It looks like that the way cross region public chat is not correct. When avatars move away from the region border messages should not cross the region border anymore.

2) Script chat always hearable

There seems to be a similar bug related to objects sending chat messages.

Additionally llOwnerSay, llRegionSay, etc. are hearable on the same region and on neighboring regions, even if the recipient is not the owner, or if the channel is not zero, or if the recipient is out of the defined hearing range.
TagsNo tags attached.
Git Revision or version number873eee543192632a7febb99aa77b53d14d926674 r/24432
Run Mode Grid (Multiple Regions per Sim)
Physics EngineODE
Script Engine
EnvironmentMono / Linux64
Mono Version2.10
ViewerFirestorm 4.6.1
Attached Files? file icon clock.lsl [^] (521 bytes) 2014-05-14 10:47

- Relationships
related to 0007039closedjustincc [VAR] Objects using llSay & whisper have no limits on distance 

-  Notes
justincc (administrator)
2014-05-14 10:49

I cannot replicate either problem. As expected, on normal neighbouring regions avatars can hear each other across the border when within range but not when they move away. Neither is script chat (with attached clock.lsl) misbehaving on my test region.
Snoopy (administrator)
2014-05-18 02:52

Strange that you cannot reproduce that. I have even found out that this happens for regions next to each other, running on the same server but using different OpenSim processes.

Region wide public chat using llRegionSay as well as public chat of avatars is affected. People can hear such chat messages on neighboring regions, even if they are outside chat range.

Justin, I could not find the code that implements public chat across region boundaries. If you could give me a hint where and how that is implemented, I can have a closer look myself and try to find that bug, using the regions currently having this issue.
vegaslon (reporter)
2014-05-18 14:16

This was the last commit that worked on chat accrossed region borders [^]
vegaslon (reporter)
2014-05-20 12:41

I would ask that you run the command: show users full
while this behavior is happening between two users on the affected regions. This may possible give a good idea about where the regions think the child avatars are related to one another.
zadark (reporter)
2014-05-20 13:21
edited on: 2014-05-20 13:23

Response to show users, the 2 avatars are approx 50m, yet chat still active. (sim default is 20m)
The simulator appears to know avatars position

Agents connected: 2

<505.4301, 185.7474, 21.98426>
<43.63458, 186.2249, 22.3411>

justincc (administrator)
2014-05-20 14:19
edited on: 2014-05-20 14:20

zadark, before your edit, I think I saw that these avatars were on the different regions, shed2 and shed2A? Where is shed2 in relation to shed2A? What are the sizes of these regions?

justincc (administrator)
2014-05-20 14:21

Also, we do need "show users full" output. This will show the position of child agents as well as root.
zadark (reporter)
2014-05-20 14:27

Justin, Further testing reveals this is not a simple case of chat across borders not enforcing chat distance. Depending on avatar movements the chat can be enabled one way only, or work as intended. Further testing required.

For instance some chat exchange prior to one avatar border crossing before the system ignores chat distance.

Yes, both var regions, both 512x512

Agents connected: 2

Firstname Lastname Agent ID Root/Chi
ld Region Position
var one d1e6193f-c274-4b9f-9413-c64f27ce524b Root
    shed2 <493.3015, 182.3059, 21.98426>
var two 12438e02-2092-40c3-8611-9ca2747546b2 Root
    shed2A <7.008034, 183.2609, 22.48426>
vegaslon (reporter)
2014-05-20 14:39

looking as your last comment, one avatar should be showing up as a child if they are in diffrent regions.
zadark (reporter)
2014-05-20 14:44

vegaslon, this is a standalone with multiple regions from a single console. show users requested from region <root>
vegaslon (reporter)
2014-05-20 14:49

if you were using "show users all" from one of the regions (most likely the one you are hearing stuff from) with an agent in each region acrross. It will show a agent in the other region as being a child. This is what I wanted to see in the first place is if it showed as a child and if the child agent is showing up with the proper offset from the corner of the region.
zadark (reporter)
2014-05-20 14:55
edited on: 2014-05-20 14:56

vegaslon, note the negative value for child in shed2a.

show users full (shed2)
Firstname Lastname Agent ID Root/Child Region Position
var one d1e6193f-c274-4b9f-9413-c64f27ce524b Root shed2 <498.482, 182.3552, 21.98426>
var two 12438e02-2092-40c3-8611-9ca2747546b2 Child shed2 <529.1697, 183.8425, 22.48411>

show users full (shed2a)
Firstname Lastname Agent ID Root/Child Region Position
var one d1e6193f-c274-4b9f-9413-c64f27ce524b Child shed2A <-0.1073198, 184.0913, 22.48412>
var two 12438e02-2092-40c3-8611-9ca2747546b2 Root shed2A <5.652132, 183.1877, 22.48426>

justincc (administrator)
2014-05-20 15:10

Yes, I'm also seeing strange child agent positions from Sandbox Plaza I and II on osgrid. There will be some error since not all updates are transmitted from source to destination (to avoid huge message traffic), but these numbers are extremely out of whack.

They don't improve on movement, which makes me think there is some logic issue rather than race (maybe an overflow somewhere). On OSGrid, Sandbox Plaza is at 10228,10126 in region-coords with Sandbox Plaza II at 10228,10127. Do other people who see problems have regions situated in high co-ords or also fairly low co-ords?
justincc (administrator)
2014-05-20 16:15
edited on: 2014-05-20 16:15

Okay, first of all, I forgot that negative child agent positions are entirely normal - it's part of the way in which we tell which neighbouring region contains the root agent for the child agent.

However, what was very anomalous were positions I observed in Sandbox Plaza II such as

Firstname Lastname Agent ID Root/Child Region Position
Justin Clark-Casey ece69759-2201-45e7-96dc-4f22acfe4043 Child Sandbox Plaza II <159.8064, 4.294967E+09, 36.52023>

On analysis, it turns out that when the child agent was in a region with a co-ord greater than the root agent (in this case, the y-coord), a change in commit beeec1c meant that this silently overflowed an unsigned integer and set it to an extremely high number, very probably causing the later chat distance calculations to stop working properly.

I have addressed this in git master 9479f64. I believe this should fix the problem. I probably didn't see this before because my child agent was in the lower co-ord region.

As an aside, child positions will also not completely accurately reflect the root agent positions. This is because updates from root agent to child agent region are only made on 'significant' movement to avoid higher network traffic between those regions.

justincc (administrator)
2014-05-20 16:21

@Snoopy - I'll try and write something up about how this works when I get the chance. It's a little complicated and tbh, I need to clarify some details myself.

- Issue History
Date Modified Username Field Change
2014-05-12 05:43 Snoopy New Issue
2014-05-12 06:18 danbanner Relationship added related to 0007039
2014-05-14 10:47 justincc File Added: clock.lsl
2014-05-14 10:49 justincc Note Added: 0026093
2014-05-14 10:49 justincc Assigned To => justincc
2014-05-14 10:49 justincc Status new => feedback
2014-05-18 02:52 Snoopy Note Added: 0026123
2014-05-18 02:52 Snoopy Status feedback => assigned
2014-05-18 14:16 vegaslon Note Added: 0026126
2014-05-20 12:41 vegaslon Note Added: 0026135
2014-05-20 13:21 zadark Note Added: 0026137
2014-05-20 13:23 zadark Note Edited: 0026137 View Revisions
2014-05-20 14:19 justincc Note Added: 0026138
2014-05-20 14:20 justincc Note Edited: 0026138 View Revisions
2014-05-20 14:21 justincc Note Added: 0026139
2014-05-20 14:27 zadark Note Added: 0026140
2014-05-20 14:39 vegaslon Note Added: 0026142
2014-05-20 14:44 zadark Note Added: 0026143
2014-05-20 14:49 vegaslon Note Added: 0026144
2014-05-20 14:55 zadark Note Added: 0026145
2014-05-20 14:56 zadark Note Edited: 0026145 View Revisions
2014-05-20 15:10 justincc Note Added: 0026146
2014-05-20 16:15 justincc Note Added: 0026147
2014-05-20 16:15 justincc Status assigned => resolved
2014-05-20 16:15 justincc Resolution open => fixed
2014-05-20 16:15 justincc Note Edited: 0026147 View Revisions
2014-05-20 16:21 justincc Note Added: 0026148
2014-07-29 13:43 chi11ken Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker