✨ 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.

Club ELFIN (since 2008) has floors in non-adjacent Mainland regions Mimolette and Enoki. Both had near-simultaneous restarts/warnings during our events six times in 2026: Sep 25 (~23:05 JST), Oct 9 (~22:00), Oct 12 (~22:00), Oct 16 (22:03/22:04), Oct 23 (22:09/22:10), Nov 6 (~22:10–22:13). All six events stopped; the evacuation region also restarted, scattering staff and guests. Nov 6 screenshots show warnings. We first learned that Boxy 5000 lets anyone request a restart at any time, even outside their home region. In Support Ticket #2568780, Freckle Linden confirmed that the Oct 12 restarts were again requested via Boxy 5000 by the same resident responsible for earlier incidents. One resident repeatedly requested restarts across regions. Please investigate later incidents; their requester is unknown. Please implement NOW a fair system for ALL Mainland residents—homes, schools, shops, clubs—to request advance restart-avoidance windows. These are preferences, not vetoes or guarantees; emergency work remains possible. Improve notices, restart classification and safeguards for resident requests. Without an alternative, ELFIN may have to consider preventive restarts before events to protect them, though we wish to avoid this practice. What would happen if club owners, event organizers and commercial venues worldwide all did the same, even once per 24 hours? Widespread uncoordinated restarts could disrupt Mainland. We may seek joint support from operators in Japan and worldwide, but hesitate: publicizing preventive restarts might encourage their spread. Please issue interim guidance before broad outreach. Please answer: (1) Will you start implementing advance restart-avoidance requests now? (2) If difficult, why? (3) If you consider widespread preventive restarts insignificant, why? This expands our existing request, “Avoid Scheduled Region Restarts During Japanese Prime Time (22:00–24:00 JST)” (40 votes Nov 8). Please link/merge without losing votes or comments; our Oct 31 renaming question remains unanswered. We made three songs to explain this issue simply and calmly to Linden staff and friends worldwide. Please listen and share your thoughts: English: Second Life Goes On and On？ https://youtu.be/RvGjHIndRe0 Japanese: Second Lifeは続くよどこまでも？ https://youtu.be/qf0aNDB93XE Portuguese: Second Life Continua Sem Fim? https://youtu.be/Efh1iaTrrHY We love Second Life and seek cooperation. Crea Shepherd | Club ELFIN

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.

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.

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.

Glad to see terrain painting in progress. One request for its design: please don't lock regions to just 4 materials total. Good-looking terrain needs more variety than 4: rock, a pebble/scree transition around the rock, riverbed, wet dirt along the banks, paths, grass, forest floor. With only 4 slots, creators will keep covering the ground with mesh and alpha decals, and that costs more performance than the terrain itself. Proposal, borrowed from how World of Warcraft handles it: Each region gets a larger material palette (12–16 slots). The region is divided into patches (e.g. 16m or 32m). Each patch picks up to 4 materials from the palette, and the paintmap stores weights for those 4. Why this works: Shader cost per pixel stays the same as today (still 4 layers blended per patch), so low-end hardware isn't hit any harder. The palette can live in a GPU texture array, so the extra memory is predictable and bounded. Because it's per region rather than per parcel, it avoids the texture-loading problems mentioned for parcel-level swatches. The editor can assign patch materials automatically: painting with a material that isn't in a patch's set yet adds it if there's a free slot. WoW has used this exact approach (4 textures per ~33m chunk, drawn from a larger zone tileset) since 2004. It's a big part of why its terrain looks hand-crafted without heavy geometry.