SL projects update week 31/2: viewer, group chat

Matoluta Sanctuary, Sartre; Inara Pey, July 2014, on FlickrMatoluta Sanctuary, Sartre, July 2013 (Flickr)

Server Deployments Week 31 – Recap

  • On Tuesday July 29th, the Main channel was updated with remaining recent feature changes and bug fixes previously deployed to the RC channels – release notes
  • There were no RC deployments.

SL Viewer

The Zipper viewer, offering a faster install, reappeared on Wednesday July 30th, after vanishing from the Alternate Viewers wiki page in May. There are apparently an issue with the XUI Preview Tool being broken, which has now been resolved.

The new version of the viewer – – appeared as a release candidate in the release viewer channel, rather than a project viewer, where it resides with the group ban viewer and the library refresh viewer, both of which were updated in week 30, are likely the strongest candidates for promotion as the next de facto release viewer.

Group Chat

Testing of on-going group chat updates took place during the Server Beta meeting on Thursday July 31st.

Simon Linden is once more digging into the group chat code
Simon Linden is once more digging into the group chat code

As noted in a previous report, one of the major causes of issues with group chat lies not with the actual messages being sent back and forth, but rather as the chat server tracks who in online or not. The server maintains a list of who is online and in the group chat at a given moment, and is constantly updating the list as people join / leave the session; these updates are then sent to everyone else still active in the group, which interferes with the sending / receiving of actual messages.

“Imagine a popular group with, say 120 people online,” Simon said during the meeting. “Let’s guess the average online time is an hour … and that number varies widely, as there are a LOT of people who are connected for only a minute or two, maybe just checking IMs, see who’s online, or trying to fix something. But with 120 people … that’s very roughly an update every 30 seconds [14,400 updates an hour], sent to the whole group.”

Not only does this impact the sending / receiving of chat messages within the group, it can also impact other group chat sessions which are running on the same back-end server, as they are being starved of resources.

The code being tested on July 31st had been set to delay the sending of these updates from the server in order to see if it improves the throughput of actual messages. The downside of this is that the member list updates are somewhat delayed; however, this would seem to be a small price to pay in order for an increase in the reliability of messages actually getting through the system. As it is, the delay is configurable, so Simon was gathering data to see how the updated code works in terms of people joining / leaving chat sessions and sending messages. The results are liable to be known next week.

One possible future option for group chat is for people to be offered the ability to opt-in or out of receiving group chats until such time as they join a group chat (some TPVs already have an option to disable group chats until such time as you opt to join them).While this may help with the “I’m here!” messages sent to all groups on log-in, and which exacerbate the problem somewhat (again as described in the update linked-to above), such an approach is not seen as optimal, as it is possible users won’t change their behaviour, but will simply opt-in to all group chat sessions anyway.

Simon has also been tracking down an odd bug with joining a group and being able to open a chat session with it. “It’s really an odd one where opening the group is very slow or times out,” he said at the July 31st meeting, “and then can be immediate the next time you try. From what I can tell the chat server isn’t getting the messages … so somewhere between the viewer, simulator and chat server it gets lost.”

 Other Items

BUG-6736 is a feature request for the updating or removal of the current limit on the distance at which objects can be linked (see linkablility rules). The advantage in increasing the limit is that it could allow for bigger builds (in terms of footprint) without having to rely on scripted rezzing systems. A problem here is the if increased, there is a risk that the ability to link objects over greater distances might cause issues were said distances are close to or exceed the draw distance / interest list distance.

“You will get some really funky update issues if the link size is larger,” Simon said at the Server Beta meeting. “As soon as it gets close to your draw distance, things go bad, as in … you stumble against something you can see.”

Commenting on this, Lucia Nightfire added, “I noticed a selection bug/gripe with multi selection and one prim being out of interest range on rez, you deselect everything by clicking on something else then if you pull your cam back you magically select stuff that was out of your interest range.”

Responding to this, Simon said, “Yeah, that’s the kind of thing that can get confusing, you won’t see what you expect because the root might be farther away than your draw distance … That said, I understand the builder desire to make larger parts, but those limits are there because it can conflict with the interest list logic about your updates.” As such, it would seem unlikely that there will be much in the way of change to the linkability limit.

One thought on “SL projects update week 31/2: viewer, group chat

  1. I wonder how many people really look at who is online on the group in a specific moment. I guess very few. Why they don’t just send the update when one actively go to check the list? In this way it is likely they would need to send only and handful of updates per hour, sometimes maybe even none at all, instead of 14,400.


Comments are closed.