✨ Feature Requests

With the dismantling of the almost two decade long "LDPW" and "Mole" naming conventions, it will become increasingly difficult for Official Second Life Viewer users to properly distinguish and verify that a Linden Lab contracted employee avatar account is in fact a genuine one and not just an ordinary Resident account owner fraudulently claiming to be one. This is most apparent in the official Second Life Viewer, where all avatars have identical coloured nametags, mini-map dots and chat text. The official Second Life Viewer currently has no easy visual way to identify real Linden Lab employees and avatars from ordinary Resident accounts. This could become a genuine Trust & Safety issue too. To counteract this, I propose that the Official Second Life Viewer adopts the same system that Firestorm Viewer has used for many years; specific nametag, chat text and mini-map colours linked to Linden Lab employees, contractors and avatars. Firestorm Viewer traditionally uses a dark blue colour to easily identify real and genuine Linden Lab employees and avatars seen inworld. Perhaps instead of using dark blue (which is difficult to read against dark backgrounds), that all genuine Linden Lab employees, contractors and avatars could use the same shade of blue as used in the official current Second Life logo? This particular shade of blue is a lighter blue used inworld at places such as the Welcome Hub and in external websites such as SL Marketplace - and even within this Canny Feature Request page too. In Firestorm, all Residents by default have green coloured mini-map dots, but have a default white nametag and white chat text . Friends have yellow nametags, yellow chat text and yellow mini-map dots. Other third party viewers have also adopted this colour convention, some even expanding on it to include magenta as the colour used by Estate Owners. Firestorm and other third party viewer users also have a Preferences option to change any of these default colours to whatever they desire too, but seen only locally within their own viewer. Additionally, all genuine Linden Lab employees, contractors and avatars should have the Second Life logo permanently displayed in their Profile front page details. Bots should also be given a specific nametag, mini-map dot and chat text colour too. Perhaps red?

Please add a clearly labeled “Urgent: Death Threats / Real-World Violence / Severe Racist Abuse” category to the existing in-world abuse report tool. Selecting this category should flag the report for priority review and prompt follow-up by the Governance team. I am requesting this because I have personally received death threats in Second Life. I filed police reports and submitted them to Linden Lab, yet the person’s main account remains active, and they continue to access Second Life through alternate accounts. This experience has left me concerned about how serious threats are identified and prioritized. While Harassment and Intolerance may already cover this conduct, there needs to be a clear way to distinguish urgent incidents within the reporting system. A direct threat to someone’s life or a severe racist attack should be immediately recognizable to the team reviewing incoming reports. This request is specifically for a category within the existing in-world reporting tool that signals the need for urgent assessment and follow-up. A resident should not have to experience repeated threats before a serious incident receives prompt attention.

When traveling, shopping, exploring, building, etc. with friends, it would be a nice function built into the client to be able to copy the position and focus direction of my own camera to paste into chat or IMs so that other users have the option to left-click/touch/tap it (similar to a SLurl, maybe call it a SLookAt? lol) to look at whatever it was I was looking at. I know there are scripted camera gadgets that can already do this, but having a native copy/paste "Look at this thing" function in the client itself would be immensely helpful for keeping users (especially new users) within the client instead of paying for a gadget or needing to rely on video screen-sharing in third party apps.

We already have avatar complexity controls that help limit how demanding other avatars are to display. I’d like similar control over objects and scenery, available to every resident without needing land ownership or estate permissions. Sometimes a location looks fairly simple but still causes a noticeable drop in FPS. Poorly optimized mesh, excessive detail, and heavy texture use can contribute to that, yet visitors don’t have a straightforward way to identify which objects are the most demanding. Lowering graphics settings affects the entire scene. Residents should also have the option to find and hide individual objects that may be hurting their performance. The main request is a simple viewer tool that lets us: List nearby objects and sort them by estimated rendering cost. Select and highlight an object so we can identify it. Derender that object directly from the list. Easily review and restore anything we’ve hidden. Where practical, the tool could show useful details such as triangle count and texture usage, with a clear explanation that rendering cost is an estimate and performance varies by computer and settings. An optional object complexity limit, similar in purpose to avatar complexity controls, would also be useful. Users should be able to exempt selected objects from automatic hiding, particularly buildings, floors, and objects they need to interact with. These controls would affect only the resident’s own view. They would leave the build and everyone else’s experience unchanged. Even starting with the sortable list and manual derender/restore controls would give residents a practical way to troubleshoot low FPS. It could help people stay and enjoy shops, venues, and events where they might otherwise have to leave because of poor performance.

Just what the title says. The ability to de-render all objects owned by a resident, or de-render entire parcel.

The tiny Empire posting and the strong support it received was dismissed in a manner that can only be described as cavalier, despite the submitted evidence showing that it was a massive abuse of common resources. Bad enough, but to then to close the board was, in my opinion, a very disrespectful act. Please re-consider the closure and please, please at least respond to the very real concerns about the tiny empire abuse with an explanation as to why it is tolerated?

Building on the individual voice moderation option introduced in the recent update, I’d like to suggest a similar control for sounds. Give authorized parcel and estate moderators the ability to mute sounds coming from a specific resident, including gestures, dance attachments, music players, and other sound-emitting objects they own. At venues, someone repeatedly playing loud or disruptive sounds can interrupt conversations, events, and everyone else’s experience. Staff should be able to address that individual without disabling sounds for everybody or immediately having to eject or ban them. The restriction should prevent others within the managed area from hearing that resident’s sounds, including sounds from their attachments and rezzed objects. It should be separate from text and voice moderation, reversible, and limited to the parcel or estate where staff have permission to moderate. The same idea behind muting someone who abuses voice should apply to someone who abuses sounds. Give staff a way to handle the disruption without taking the fun away from everyone else.

Hey everyone, I’d like to suggest this feature because banning someone should give a venue some protection against them coming straight back on another account. I work at Actually Love, a dating agency in Second Life. Like other businesses and public venues, we deal with griefers who threaten to return on alts to keep causing problems. Recently, someone threatened to come back on five alternate accounts to harass our staff and visitors. Abuse reports have been filed, but so far we haven’t seen anything come of them. My suggestion is that when an estate owner or estate manager estate bans an account, its IP connection and any accounts Linden Lab knows belong to that person are also blocked from entering the region covered by the ban. Linden Lab could also use device identifiers to help recognize accounts returning from the same computer, even if the IP changes. Accounts identified as associated later should be included, and known associated accounts should stay blocked when they change connections. Linden Lab would handle this privately. Estate managers, staff, and other residents would not be shown alt identities, account links, IP addresses, or device identifiers. Those accounts would simply be denied entry. They could still log into Second Life and visit places outside the region covered by the ban. I understand connection or device restrictions could also affect a partner, roommate, or someone sharing a computer. Managers should see a clear warning before applying these restrictions and be able to remove them without lifting the original account ban. They should also be able to allow a specific account as an exception if someone unrelated gets caught by it. This won’t stop every attempt to get around a ban, but it would give us a better chance to stop repeat harassment. Staff could spend more time helping visitors and running the venue instead of waiting for the next alt to show up.

Please add an option to attach multiple saved images and chat logs directly to an abuse report from within the Second Life viewer, alongside the current screenshot option. A single screenshot may not provide enough context for the Governance team to understand what happened. Abuse can involve several messages or a sequence of actions. Allowing a few images per report, such as three to five, would help residents document the incident more clearly. Not everyone can capture the abuse at the moment they submit a report. The incident may have happened earlier, the person may have left, or the resident may already have captured screenshots using Gyazo or another screenshot tool. The report window should allow residents to select existing images or textures from their inventory, upload saved images from their computer, and attach relevant chat logs. These attachments should be sent privately to Linden Lab without requiring residents to pay to upload textures or rely on external links. All attached evidence should document activity within Second Life itself. Screenshots and chat logs from Discord, social media, or other outside services should not be accepted through this option because Linden Lab cannot independently verify those services’ records. Images and copied logs from any source can be altered, including those from Second Life. Keeping evidence limited to Second Life activity would allow Linden Lab to check it against its own records where available, rather than relying solely on the submitted attachment. A tool like Gyazo may be used to capture an image, but the content shown must come from Second Life. Allowing multiple images and supporting chat logs would help residents submit more complete reports and give the Governance team the context needed to assess them.

Currently, the Bakes on Mesh (BOM) baking stack places the Universal Layer above standard Tattoo Layers. Because the Universal layer covers all texture channels simultaneously, using it to distribute a full skin (Head, Torso, Legs, and auxiliary parts) completely cakes over and hides a resident’s existing inventory of standard Tattoo layers—including makeups, hairbases, and body art. As a result, creators are heavily discouraged from utilizing the Universal layer for complete avatars, forcing its use to be almost entirely restricted to isolated attachments like mesh ears. Moving the Universal layer's position in the baking hierarchy to sit directly under Tattoo layers and directly above the System Skin layer would fully unlock its original design potential. Use Cases & Community Benefits • Complete-in-One Asset Creation: Skin creators could leverage a single Universal layer file to package an entire avatar skin. This includes simultaneous coverage of the head, body, left/right ears, custom eye textures, fingernails, and auxiliary channels without forcing residents to give up their cosmetics. • Massive Inventory De-cluttering: Instead of a customer having to locate and wear separate system skins, auxiliary body appliers, and independent tattoo layer extensions for specialized mesh parts, everything fits perfectly into one clean wearable asset. • Seamless Customization Workflow: Residents could wear a complete full-body baseline asset via the Universal layer while safely overlaying their existing library of traditional standalone tattoos, hairbases, and cosmetic makeups right on top of it. • No Structural Disadvantages: Because the Universal layer natively supports alpha masking and transparency channels across its target outputs, positioning it underneath specialized tattoo cosmetics introduces no regressions to traditional layout styling or transparency blending. Proposed Technical Change Modify the server-side and viewer-side texture composition pipeline so that the texture baking order stacks as follows (from top/visible to bottom): [Upper Layers: Jackets, Shirts, Underwear, etc.] Tattoo Layers (User-reorderable cosmetics, makeups, hairbases) Universal Wearable Layers (Unlocks baseline full-body/asymmetric texture baking) System Skin Layer (The absolute baseline texture)