Category: Simulator User Group

SL project updates Week 21/1: server, viewer CDN change, SL network update

Posted on by Inara Pey

WindWept, Dolly; Inara Pey, May 2015, on Flickr Windwept (General) May 2015 (Flickr) – blog post

Server Deployments, Week 21

As always, please refer to the server deployment thread for the latest updates / news.

On Tuesday, May 19th the Main (SLS) channel received the server maintenance package previously deployed to the three RC channel, comprising:

  • Internal server logging changes
  • Back-end system bug fixes
  • Reply-To email changed in postcard sends

As previously noted in these pages, the “reply-to email changed in postcard sends” relates to changing the way snapshots forwards to e-mail are handled. Until now, the Lab has substituted the user’s e-mail address in the “from” field of snapshots sent to e-mail, rather than displaying the “secondlife.com” address.

However, this added to issues of e-mail originating from “secondlife.com” being treated as spam by a/v software and ISPs. With the new format employed with this change, the sender’s e-mail address is given as the “reply to” address in the snapshot, and the “from” is “no-reply@secondlife.com”, thus avoiding the issue of LL looking like spammers who are forging invalid addresses.

There will be no RC deployment on Wednesday, May 20th.

SL Viewer

The week has not so far seen an RC viewer promoted to release status. If there is any promotion, it would most likely be the Layer Limits RC (currently version 3.7.29.301305). The Experience Tools RC viewer is still awaiting the completion of back-end work, while the Attachment Fixes RC (Project big Bird) currently has an elevated crash rate compared to the current release viewer, which includes a crash-on-exit bug, so further work is required on that RC.

CDN Provider Move

The Lab has been moving between CDN providers, and as a result, some people may have been experiencing particular texture / mesh / avatar rendering delays of late. Commenting on the process at the Simulator User Group meeting on Tuesday, May 19th, Oz Linden said:

We’ve just finished moving from one CDN provider to another, and it may take the caches a little while to catch up. We tried to do it gradually in a way that would be minimally disruptive, but when you’re dealing with as much data as we are, there are no perfect solutions.

One of the cases it is hoped the move will assist is with SL users in Florida (and neighbouring states) in the US who use Mediacom as their ISP, and who have found that there have been what appear to have been issues with Mediacom throttling the service at certain times of the day. Preliminary feedback from users so affected who have been involved in testing with the new CDN provider has been positive.

What Goes Through the CDN, And How

During the CDN conversation Oz reinterated the data that is currently delivered to the viewer through the CDN: textures, world map tiles, avatar baking data, and mesh data. In terms of in-world objects, two distinct operations are taking place:

  • Where an object is, how big it is, and so on, comes to the viewer via the simulator, together with the UUIDs fr the relevant objects / textures
  • The viewer then uses the UUIDs to fetch the mesh and texture data directly from the CDN.

As previously noted on these pages, this should mean faster loading of things like textures and mesh in-world, as the data is coming from a CDN node that is “local” relative to you, rather than coming to you from the Lab and through the simulator itself. However, experience is showing that for a small number of people, this isn’t always the case, and there can be situations where mesh and texture loading aren’t what might be expected. However, the Lab continues to try to improve things.

Second Life Network Architecture

Writing on the forums, noted SL photographer Jackson Redstar recently asked meshmaxconcurrentrequests – does anybody know the real setting? In the ensuing debate, Monty Linden offered an updated overview of the SL network architecture.

Monty Linden's updated SL network diagram
Monty Linden’s updated SL network diagram

To borrow from Monty’s explanation:

  • On the left, in red, are pieces of the viewer; on the right, in blue are simhost/simulators and other backend services; at the bottom (green) are new CDN services
  • Solid lines with arrowheads are communication paths, either UDP or TCP/HTTP; dashed lines are legacy communication paths that are now or soon will be deprecated, obsoleted and/or deleted
  • Sold ball-and-stick indicators (e.g. TextureFetchConcurrency) indicate a viewer debug setting and the communication path or paths that setting influences; dashed ball-and-stick indicators (e.g. MeshMaxConcurrentRequests) indicate obsolete debug settings.

Monty goes on to say:

Generally, things are moving in the direction of simplification and less resource conflict.  The mesh and texture HTTP traffic, which is usually the greatest load, tends to part ways with the UDP traffic a few network hops after a user’s router or modem.  Lacking TCP’s throttling mechanism, UDP often wins in a fight (give-or-take the efforts of fairness algorithms along the path).  Allowing UDP to overrun the path between viewer and simulator does still degrade the experience and the bandwidth setting remains an effective tool for avoiding this problem.

Other settings should generally be left alone.  A lot of bad advice was spread around in the community in an effort to work around throughput problems.  We’re trying to undo that history and get back on track with more typical (albeit aggressive) HTTP patterns.

 Viewer Caching

During the Simulator UG meeting, Oz repeated a call he originally made at a TPV Developer meeting recently, asking that if there is developer wishing to volunteer for a “deep dive” into viewer caching, he’d like to hear from them.

While interest list updates made key changes to how the viewer’s cache is used, there are numerous issues which appear to be viewer-side caching related, so a deep investigation into the code could go further towards improving things.

One long-standing issue, which is thought to be caching related, is If someone uses a texture rezzed in-world same texture for a group profile image or their avatar profile image or in a profile pick, the object will never fully load the texture.

So, if you’re a developer willing to looking into viewer-side caching, Oz would like to hear from you.

SL project updates week 20/1: Server and viewer; outfits

Posted on by Inara Pey
Join Hands: raising money to help the WFP's aid work in earthquake-struck Nepal
Join Hands: raising money to help the WFP’s aid work in earthquake-struck Nepal with Fashion for Food – May 13th through May 16th inclusive

Server Deployments, Week 20

As always, please refer to the server deployment thread for the latest updates / news.

There was no main (SLS) channel deployment on Tuesday, May 11th. On Wednesday, May 12th, the three RC channels were all updated with a new server maintenance package, comprising:

  • Internal server logging changes
  • Back-end system bug fixes
  • Reply-To email changed in postcard sends

As noted in my TPV Developer meeting report for week #17, snapshots are sent via the “secondlife.com” domain, but use the sender’s own e-mail address as the originating address in the “from” field. This, and other ways ways in which e-mails flowing out from “secondlife.com” are handled has resulted in some ISPs regarding the domain as a spam domain, and have been pro-actively blocking it.

The “reply-to email changed in postcard sends” refer to a change made to how the “from” field in snapshots sent to e-mail (which the Lab refers to as “postcards”)  is addressed in an attempt to alleviate the problem.

At the time this issue was raised at the TPV Developer meeting, it was indicated that the Lab was considering removing the the snapshot to e-mail capability server-side. However, as was indicated in the meeting, doing so would break a number of wardrobe HUD systems which are popular among users. Whether or not this fix is an attempt to address the spam issue without having to remove the snapshot or e-mail functionality is currently unclear.

SL Viewer

Attachments Viewer (Project Big Bird)

The attachments viewer was promoted to release candidate status with version 3.7.29.301361, release on Wednesday, May 13th. This viewer provides a series of fixes for attachment-related issues, particularly when multiple attachments are added or removed at the same time. It also has enhanced logging, so the SecondLife.log file will have some additional lines related to avatar state in general and attachments in particular.

Linux

As noted in a separate report, the Lab have now blogged about seeking assistance from open source developers in the continued development and maintenance of the Linux flavour of the viewer.

 Outfit Folder Changes

A recent change to viewer functionality means that it is no longer possible to drag and drop sub-folders of items into the My Outfits  / Outfits folder – see BUG 9209 (FIRE-15603). This change, which is in the official release viewer, is filtering out into various TPVs, and has been causing some consternation.

While it is still possible to create sub-folders within My Outfits / Outfits and drag and drop items into them, many people have tended to simply unpack new clothing items into a default folder and drag that folder (or the Direct Delivery folder for the clothing) into My Outfits / Outfits, and then sort the contents into suitable outfits from there. Others have used the Appearance floater to create outfits, save them, and then drop them into My Outfit / Outfits – which also is no longer possible.

It’s unclear precisely what problems can occur in allowing drag-and-drop in My Outfits, although it appears drag-and-drop into My Oufits was never intended to be allowed. The change itself was made by Vir Linden, shoe has most recently been working on a range of improvements to try to reduce issues of inventory loss; he is now involved in the JIRA discussion, seeking to understand use cases relating to dragging-and-dropping folders into  My Outfits.

SL project updates week 19: server, group chat, child agents

Posted on by Inara Pey

Ichi-go Ichi-E, Fantasy Faire 2015 Inara Pey, April 2015, on Flickr Ichi-go Ichi-E, Fantasy Faire 2015 (Flickr)

Server Deployments Week 19 – Recap

On Tuesday, May 5th, the Main (SLS) channel received the server maintenance package deployed to all three RCs in week #18, comprising internal server logging changes  and a new flag for llGetObjectDetails()  – OBJECT_LAST_OWNER_ID; plus new data which can be requested  via llGetEnv(). These are:

  • “agent_limit”- get the maximum number of avatars normally allowed on the region (teleport home, and login to last location, are allowed to exceed this).
  • “estate_name”- returns the name of the estate (e,g, “mainland”, “Linden Homes”, “My Happy Estate”, etc. )
  • “region_cpu_ratio”- returns the number of regions per CPU for this region type (i.e. “1” or “4”)
  • “region_product_name” – returns the type of region this is: “Estate / Full Region”, “Mainland / Homestead”, “Estate / Openspace”, “Estate / Full Region – Skill Gaming” etc.
  • “region_product_sku” – returns the region’s product number as a string
  • “region_start_time” – returns the time the region was last (re)started, in llGetUnixTime format
  • “simulator_hostname”  – returns the simhost running this region. Same as llGetSimulatorHostname but without the script delay.

There were no planned RC deployments or restarts for Wednesday, May 6th.

Group Chat Failures

There are been a number of odd group chat issues recently, such as those outlined in see BUG-9130. Simon Linden has been investigating the issues, and gave his findings at the Simulator User Group meeting on Tuesday, May 5th, “Basically the chat server gets stuck with bad info about where the avatar is. The normal ways that would get corrected aren’t working right … but trying to log off and back in, or leave and re-join the group might fix it.”

When asked if a re-start of the affected chat servers could clear the problem, he replied, “possibly … except one of the features of the chat servers is that they try to save everything and re-load it when they come back up.   That way everyone isn’t kicked out of all their group chats when it restarts. I’d have to check but I think they may save the bad info about [the affect avatar]. ”

Group chat messages are routed to you via the region you are in at the time the message is sent. However, if you have moved to another region during the conversation, the region will tell the group chat service you are no longer there, and the service then performs a look-up to locate you so that the messages can again be sent to you via the region simulator. “In this case, Simon explained the current issue, “it’s failing with a different error due to a change in the grid configuration, and not handling it correctly.”

With the cause of the issue now identified, the Lab hopes to get an update out to the chat servers to fix the problem very soon.

Attachment Failures

As has been noted in these updates, the Lab currently has a series of viewer-side fixes for problems relating to attachment issues (items detaching on region crossing / teleporting, items showing as attached when detached or vice versa, etc.) which are  at project viewer status (“Project Big Bird”) and  will be progress through the viewer channels in due course.

In addition to the viewer fixes, there are are some server-side issues with attachments the Lab is investigating. In particular, the Lab has identified that requests for multiple simultaneous attachments at or near the upper limit (38) to be attached at the same time will invariably overload the pipe, although why this is the case still has yet to be determined.

Experience Keys / Tools

Work continues with the back-end of Experience Keys / Tools, and Simon Linden has most recently been working on the key values database for the system (which can be used to store information relating to users who have been  / are engaged in an experience, such as their progress, items they may have collected / attached, etc.). Given the anticipated popularity of Experiences, and the fact that people have already identified other potential uses for the key value database, the Lab is trying to ensure it is robust enough to handle and and all uses it might be put to – and can deal with the potential of poorly-written scripts persistently polling / updating it more than is strictly required without necessarily impacting its performance.

Other Items

Agent Updates, Draw Distance and SL Performance

In discussing the group chat issues during the Simulator User Group meeting, the conversation turned to the matter of agents and child agents. While the region you are operating in has the main connection to your avatar (your agent), it may also be sending information to avatars on other regions, and you may also be receiving updates from surrounding regions.

The status panel (CTRL-SHIFT-1) reveals how many child updates the region you are in is sending elsewhere (31 in this case). some of these might be unavoidable, others might simply be down to people 3 or 4 regions away with ridiculously high draw distances
The status panel (CTRL-SHIFT-1) reveals how many child updates the region you are in is sending elsewhere (31 in this case). some of these might be unavoidable, others might simply be down to people 3 or 4 regions away with ridiculously high draw distances

Simon explained things thus, “while you’re here, you’re also talking to the region next door; it will send you updates about what happens over there … it has a camera for you and knows what you can see, and sends you updates but it doesn’t run your scripts, for example.”

This tracking of what is going on in other regions is determined by an avatar’s draw distance and the direction in which they are looking, and the “camera” Simon referred to in his description is known as a “child agent”.

Child agents help with a number of tasks – the such as allowing you to see what is going on in a neighbouring region, as Simon mentioned, and also assisting with aspects of region crossings.

Obviously, there will be child agent updates going on between neighbouring regions as a matter of course. But when you have an abnormally high draw distance, the chances are that you are having an additional impact not only on the regions immediately adjacent to the one your in, but every region that falls within draw distance / view, as you are forcing them to send you updates as well, and you are forcing the region you are in to work that much harder to pass those updates to you.

Hence why it’s a good idea to keep your draw distance down to a reasonable level (say 256 metres or lower) for as much as you can. You’re not only helping improve your own experience (however powerful your own computer might be) – you’re showing courtesy to those active in the regions around you and who might also be affected by the region they are in having to take time serving data you may not need to your viewer.

SL projects updates week 18/1: server, viewer

Posted on by Inara Pey
UNIA launches at 12:00 noon on Monday, April 27th
MadPea’s UNIA is now open for those of a brave disposition, and uses Experience Keys / Tools

Server Deployments Week 18

As always, please refer to the server deployment thread for the latest news.

  • There was no Main (SLS) deployment on Tuesday, April 28th.
  • On Wednesday, April 29th the three RC channels all received the same sever maintenance package. This comprises Internal server logging changes  and a new flag for llGetObjectDetails()  – OBJECT_LAST_OWNER_ID; plus new data which can be requested  via llGetEnv(). These are:
    • “agent_limit”- get the maximum number of avatars normally allowed on the region (teleport home, and login to last location, are allowed to exceed this).
    • “estate_name”- returns the name of the estate (e,g, “mainland”, “Linden Homes”, “My Happy Estate”, etc. )
    • “region_cpu_ratio”- returns the number of regions per CPU for this region type (i.e. “1” or “4”)
    • “region_product_name” – returns the type of region this is: “Estate / Full Region”, “Mainland / Homestead”, “Estate / Openspace”, “Estate / Full Region – Skill Gaming” etc.
    • “region_product_sku” – returns the region’s product number as a string
    • “region_start_time” – returns the time the region was last (re)started, in llGetUnixTime format
    • “simulator_hostname”  – returns the simhost running this region. Same as llGetSimulatorHostname but without the script delay.

Commenting on the llGetEnv() updates at the simulator User Group meeting on Tuesday, April 28th, Simon Linden, who made the updates, said, “these are all pretty simple ones … I went for the easy pickings.  Basically, information we already  sent to the viewer, or was readily available, and thus not a privacy issue.”

He continued, “There was one [further option] for the max number of agents that was in the original list but that one got skipped … not part of a sinister plot but I overloooked it.  want to do some other things with that limit sometime soon as well 🙂 … I’d like to see how the region and viewer performs with bigger numbers. Things go bad with many AVs for a variety of reasons … the server has more updates to send to more people, all wearing more scripts and AOs and HUDS [and] the viewer gets overwhelmed with too many complex avatars and too many textures in the download and graphics pipeline.”

SL Viewer

The Avatar Layer Limits RC viewer updated to version 3.7.29.301305 on April 28th, bringing it to code parity with the current release viewer. This RC allows users to wear up to 60 wearable layers (jackets, shirts, tattoo, alpha, etc.) in any combination – so you can wear 60 tattoo layers with it an nothing else, if you want – rather than being restricted to wearing a maximum of 5 of each type of layer.

Other Items

Online / Offline Indicators

People are noticing that the group chat list (the list of group members in the Group panel), is now much slower to update as people’s status changes (i.e. whether they are on-line or off-line). This is intentional, and comes as a result of the recent improvements made to group chat.

In particular, and as I reported in these pages as work on group chat commenced in 2014, the volume of people logging-in to and out of SL can generate a huge amount of updates for the group chat service (given your status has to be sent to every group of which you’re a member, and to over member of that group who is online to update the group list in their viewer with your new status), meant that more time was being consumed by the group chat servers in handling these update messages than in handling actual messages.  The fix for this problem means there is a natural delay in group list updates, as they are now processed differently to reduce the impact they have on message handling.

However, some people have started noticing that some group chat lists with 20+ members seem to take a very long time to update – times of 5-10 minutes have been mentioned, and this is causing some confusion when seeking things like assistance from group owners / moderators (as they can appear to be logged-in long after they have logged-off). It’s also bee reported that at times the list seems to get stuck with no updates until the group chat itself is closed and re-opened, although this appears to be somewhat intermittent.

SL project updates week 17/1: server, viewer, Avatar Complexity

Posted on by Inara Pey

221B Baker Street; Inara Pey, April 2015, on Flickr 221B Baker Street, circa 2012-2015, as seen in the BBC’s series Sherlock – and in Second Life – blog post

Server Deployments, Week 17

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, April 20th, the Main (SLS) channel received the server maintenance package deployed to all three RC channel in week #16, which comprises internal server logging changes and new flags for llGetObjectDetails()
    • OBJECT_BODY_SHAPE_TYPE – returned list entry is a float between 0.0 and 1.0. Anything > 0.5 is male, otherwise female; -1.0 if the avatar is not found
    • OBJECT_HOVER_HEIGHT – returned list entry is a float, -1.0 if the avatar is not found.
  • There will be no deployment or restart on the three RC channels on Wednesday, April 22nd.

This means there will be no Main channel roll in week #18, but there should be a new RC update, although this is still being worked on.

SL Viewer

The Avatar Layer Limits RC viewer updated to version 3.7.28.301019 on April 20th. This viewer allows users to wear up to 60 wearable layers (jackets, shirts, tattoo, alpha, etc.) in any combination and any number per layer up to the overall maximum of 60, rather than each individual layer being limited to a maximum of 5 items.

The Tools Update RC viewer has been performing very well since the last update (April 15th), and there has been something of a debate in the Lab as to whether or not to promote it to the de facto release viewer. While there is no hard-and-fast rule about when an RC is promoted to release status, very often the Lab prefers to leave two weeks between releases unless something is urgently required. Sticking to this would mean the viewer won’t be promoted until week #18 (week commencing Monday, 27th April); however we’re still early in the week, and things might change.

Viewer Managed Marketplace Beta

The Viewer-Managed Marketplace (VMM) officially started an open beta test on the main grid, which is scheduled to last for about a month for details see:

Avatar Complexity

Avatar Complexity is the term the Lab has settled upon for the upcoming functionality which provides greater control to user to define how other avatars are rendered in their world-view.

The idea is that as avatars can often be the single biggest impact on the viewer in terms of rendering, particularly in crowded places, so  Avatar Complexity will present a means by which avatars which require a load of render processing by your GPU can be rendered as a solid colour instead, which should help with performance on lower specification systems. Due to their solid colours, avatars rendered in this way have already been dubbed Jelly Babies or Rainbow People.

At the Open-source Developer’s meeting on Monday, April 20th, Oz Linden explained that “Avatar Complexity” has been chosen for the name of the capability to distinguish it from avatar imposter rendering, which will remain in the viewer alongside Avatar Complexity when it arrives. The difference between the two can be summarised as:

  • Avatar impostor rendering is a simplified and less frequent rendering of avatars further away from you, while those close to you remain fully rendered
  • Avatar Complexity renders any avatar exceeding the value set within your viewer as a single, solid colour, regardless of the avatar’s distance from you.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.

Oz further indicated that Avatar Complexity will be managed via the Advanced panel in Preferences > Graphics, and will initially be enabled / disabled in the official viewer based on your GPU’s benchmark (the value use to determine the viewer’s default graphics settings when first installed). Some TPVs may opt to leave the capability disabled by default (once the code is available for inclusion in TPVs), and allow users determine whether they wish to use it or not.

Currently, work at the Lab is focusing on a couple of aspects of the functionality:

  • Toning down the colours used by the viewer when rendering avatars in this way – as the functionality can currently be tested via two debug settings within the viewer, there have already been strong criticisms of that “Jelly Baby” rendering on account of the brightness of the colours
  • Server support is being added to pass on the counts of avatars that are and are not rendering to those using Avatar Complexity.

It is also probable that before the capability appears in a project viewer, it will also be set to  display notifications when you change your own complexity, and when the number of avatars not rendering you changes.

If you wish to experiment with the settings are they are at the moment, go to Advanced > Debug Settings and type-in RenderAutoMute. Select RENDERAUTOMUTEFUNCTIONS and set it to 7, then experiment with values under RENDERAUTOMUTERENDERWEIGHTLIMIT (start with 100,000, and increase or decrease it to alter the number of avatars around you rendered as solid colours (lower values = more avatars rendered as colours).

SL project updates week 16/1: server, viewer updates, misc

Posted on by Inara Pey
The City Skyline - Remnants of Earth
The city – Remnants of Earth – blog post

Server Deployments Week 16

As always, please refer to the server deployment thread in the forums for the latest information and updates.

On Tuesday, April 14th the Main (SLS) channel was updated with the server maintenance package previously deployed to all three RC channels. This comprises a crash fix, minor CDN configuration updates and an internal server configuration update.

On Wednesday, April 15th, all three RC channels should receive a new server maintenance package, which comprises internal server logging changes and new flags for llGetObjectDetails()

  • OBJECT_BODY_SHAPE_TYPE – returned list entry is a float between 0.0 and 1.0. Anything > 0.5 is male, otherwise female; -1.0 if the avatar is not found
  • OBJECT_HOVER_HEIGHT – returned list entry is a float, -1.0 if the avatar is not found.

SL Viewer Updates

The Maintenance RC viewer, version 3.7.27.300636 was promoted to the de facto release viewer on April 13th. The viewer contains multiple fixes and improvements, as detailed in the release notes.

This release also includes the fix for the URI parsing error, which was originally issued in the HeatWave RC viewer (formally version 3.7.27.300424, which has been withdrawn from the release channel as a result.

Webkit Replacement, Flash and Quicktime

As I’ve reported on a number of occasions, Webkit is a third-party library which has been used within the viewer for a number of media-related tasks (powering the built-in web browser, displaying profiles, and is used with MOAP  and many in-world TVs). However, it has been something of a problem for the Lab,  with out-of-date libraries and other issues.

Because of this, there is a project under-way in the Lab to replace webkit with the Chrome Embedded Framework (CEF). Work on this within the Lab has been progressing, and they now have CEF working with the windows version of the viewer, and are now focusing on getting it working on the Mac version.  There are no plans to release a test or project viewer with CEF support until it is running on both platforms (it is thought that Linux will be able to use the Mac version).

Avatar Complexity (RenderAutoMute Functions)

The new rendering controls will allow users to set a level above which avatars will be rendered as a solid colour
The new rendering controls will allow users to set a level above which avatars will be rendered as a solid colour “jelly baby”

In week #47. 2014, I reported on how the Lab is working to give greater control to users over how other avatars are rendered in their own view.

Avatars can frequently have very high render costs associated with them which, even in modestly populated areas, can have a detrimental impact on viewer performance on lower specification hardware.

The idea with the new, still-to-be-released functionality is that users will be able to define a render weight for their viewer when drawing avatars. Any avatar that exceeds this limit will be rendered as a solid colour “imposter”, regardless as to how near / far they are from a person’s viewpoint.  Thus, the rendering load is reduced, improving overall performance.  Because of the solid colour aspect of the avatars when rendered in this way, they were somewhat quickly dubbed “Jelly Babies” after the sweets of that name. note they are only rendered like this in your own view, it doesn’t affect how others see them.

This work has been going on for some time, now, and is approaching maturity. Commenting on it at the Open-source Developer’s meeting on Monday, April 12th, Oz Linden indicated that things are currently waiting server side updates. Included in the functionality is a means by which someone can see the number of other people who are rendering their avatar as a “jelly baby”.

The capability can actually be experimented with at the moment, although it is a case of trial and error until the new UI controls are added to the viewer. Should you wish to try, go to Advanced > Debug Settings and type-in RenderAutoMute. This will list a series of options, of which RENDERAUTOMUTEFUNCTIONS and RENDERAUTOMUTERENDERWEIGHTLIMIT are the two you need:

  • RENDERAUTOMUTEFUNCTIONS is essentially the “on / off” option for enabling the other options, and must be set to 7 in order for any of them to work
  • RENDERAUTOMUTERENDERWEIGHTLIMIT is the function that determines how avatars are rendered. Try starting with a value of around 100,000 and experimenting from there.

Group Chat

BUG-9020 reports issues with people being unable to see anything typed in certain group chats they belong to – either their own messages, or anything typed by anyone else. The problem appears to possibly be more widespread than the report indicates – if you are experiencing a problem, please consider adding the details to the report: the specific groups, etc., and specific issues. The Lab is currently looking into this and checking through the additional logging / diagnostic tools they’ve added to the group chat services to see if anything is showing-up as causing the problem.

Other Items

In-viewer Translation Tool Fix

As noted in my week #12 update, the built-in viewer translation tools are now pretty much broken (Google and Bing). Nalates Urriah filed a bug report on the Bing situation recently (see: BUG-8794 “The Bing API used by the viewer is depreciated [sic]”).

Commenting on the situation at the Open-source Developer’s meeting on Monday, April 13th, Cinder Roxley indicated that the Alchemy TPV team are working to get the viewer translation tool working again, although there is currently no ETA on this. The fix is liable to appear in the Alchemy viewer, but the code will be contributed to Linden Lab.

Forum Log-in Issue

As noted in BUG-8953, there is currently an issue with signing-in to the the SL forums, and staying logged-in. the problems are broadly two-fold. In short, people are finding they are being randomly logged-out of the forums for no apparent reason, or are being redirected to the top-level community page when logging-in, rather than being redirected back to the page in the forums they had displayed prior to the log-in request being displayed (e.g. when replying to a post).