✨ Feature Requests

A common problem is the "Out Of Date LM". I just had an awkward situation with that: I used a seasonal LM, and the first things that rezzed were seasonal decorations, but when everything finally rezzed: I had TPed into a private residence. And they were home. Very, very awkward. Whenever the topic of killing off "dead LMs" comes up, it is pointed out that it would require a search of everyone's inventory, be very computationally expensive, etc. Very valid concerns. I would like to propose a different mechanism: the region or parcel owner may set an "Expire Old LMs" property on their land (perhaps for a nominal fee, if overuse is a concern for some reason?) that sets to the current date and time. When someone uses an LM, have it check for the presence of that date, and if the LM was created before that timestamp, the TP fails and the Resident is noted that their LM has "expired". At which point, several possible outcomes. 1) The LM is moved to Trash. 2) The LM just "poofs", is removed entirely. (I can see both sides of the argument on this one.) 3) The LM is moved to an "Expired Landmarks" folder. 4) Nothing is done to the LM, the Resident has to deal with it manually. (Which will just lead to repeated attempts, tbh.) This removes the massive-inventory-search problem: it is comparing two properties at the time of use, and the thousands of LMs sitting idle in the inventory DB don't get bothered at all. It would reduce the incidence of "Hey, you just TPed into my house!" and "Didn't this used to be a club?" When land is abandoned, I would have the date set automatically.

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.

Request: a per-cell hole mask on region terrain, applied to both rendering and collision. Region terrain gets a bitmask (e.g. one bit per 4m×4m cell) marking cells as "no ground." The viewer skips the triangles for masked cells. The physics heightfield leaves those cells out, and the sim's ground-penetration correction ignores them. Editing uses the same terraform permissions as painting. This would allow real cave entrances, mine shafts, and sunken basements instead of faking them with mesh shells over raised terrain. Open questions for the Lab: what happens at region borders, and what to do with avatars or objects that fall through a hole with nothing built underneath (e.g. treat them like falling off the world edge, or keep a floor below the minimum terrain height). WoW's ADT terrain uses this same approach: a hole bitmask per chunk that both the renderer and the collision code respect.

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.

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?

Ban bots from being able to invite to conferences - so its should be a requirement for Bot operators to only send direct messages, for example, buying products; then the bot can send the message; that's it. - Can't do conferences - however, we need to see who started the conference so it's quicker to remove the bots and Bot operators who break rules and allow SL users be in peace and not be bothered = for example, quicker to find out who invited, for example, the name of user who started the conference, and limit the conference to 20 people with only for Group or friends. because i experinced getting confences in default viewer for unwanted reason - this should be stopped because i have to close each conferences if they pop up and not knowing who invited me resulting bot spamming directly to my DM - i want LL to enforce the bot rules more strictly - for example banning spamming bots more quickly and tightly control the way bot operates for example bot only be activted when person buys product or directly messages the bot also cant be allowed to start or join conferences

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.

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)