✨ Feature Requests

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.

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?

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.

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.

===Feature Description=== We request that Linden Lab extend the existing Combat 2.0 (C2.0) damage teleport functionality to individual parcel owners, including those on mainland regions. Currently, C2.0 damage teleport settings are controlled at the estate level. Private estate managers can configure these settings to support scripted combat systems that teleport defeated players to designated respawn locations. However, individual mainland parcel owners cannot independently configure these options, even when their parcels are already damage-enabled. We propose introducing parcel-level controls for C2.0 damage teleport settings, allowing landowners to implement modern combat functionality without needing to purchase or rent an entire private estate. ===Background=== The Second Life Military Community (SLMC) has maintained an active presence in Second Life since approximately 2005, with many longstanding groups originating on the former Teen Grid, now known as the Sharp Continent. Linden Lab has supported this community through the development of Combat 2.0 and the continued availability of dedicated combat sims, including Concord, Lexington, and No Man's Land. These improvements have created new opportunities for scripted combat, but the current estate-level configuration limits their accessibility to groups operating on private regions. Historically, many SLMC organizations developed on small mainland parcels, gradually expanding their holdings as membership and activity increased. Requiring estate-level permissions for essential C2.0 functionality creates an unnecessary barrier for new and smaller organizations. ===Proposed Implementation=== We recommend the following: Parcel-level damage teleport controls: Allow parcel owners or authorized land managers to configure C2.0 damage teleport settings through the About Land interface or equivalent parcel management controls. Damage-enabled parcel requirement: Maintain the existing restriction that damage teleport functionality operates only on land where damage is enabled. Parcel boundary protections: Ensure that enabling these settings does not alter the behavior of neighboring parcels or regions where damage is disabled. Compatibility with existing systems: Preserve existing estate-level functionality while allowing parcel-specific configuration where technically feasible. This proposal would not require damage to be enabled by default or change the existing rights of landowners who do not wish to participate in combat. ===Benefits to Second Life=== Greater accessibility: Smaller military groups and individual landowners could participate fully in Combat 2.0 without the substantial expense of private estate ownership. Mainland revitalization: Expanded combat functionality would encourage the acquisition, development, and active use of mainland parcels for military bases, training facilities, and organized combat events. Community growth: Lowering the cost of entry would make it easier for new groups to form, recruit members, and participate in the SLMC. Increased adoption of Combat 2.0: More residents would have opportunities to discover and experiment with C2.0 features, expanding the audience for Linden Lab's recent combat improvements. Consistency across land ownership models: Mainland parcel owners would gain access to functionality currently available primarily through private estate management, without needing equivalent estate-level administrative powers. ===Conclusion=== Combat 2.0 represents an important improvement to Second Life's combat capabilities. However, its full potential cannot be realized if essential functionality remains inaccessible to the smaller mainland communities that have historically contributed to Second Life's military culture. We respectfully request that Linden Lab implement parcel-level C2.0 damage teleport controls, allowing mainland combat groups to access this functionality. This relatively focused land-management improvement could encourage new organizations, stimulate mainland development, increase adoption of Combat 2.0, and strengthen the long-term sustainability of organized combat in Second Life. Submitted on behalf of representatives of New Rome and the Second Life Military Community (SLMC).

Group chats lack the ability to be moderated like in most forms of widespread chats. As such we get things such as scam links, hate speech and various other undesirable aspects. I propose we add a new feature to groups that allows the ability of chat moderator. That chat moderator(s) is able to delete chat sent, mute a participant from chat for x minutes, 0 would be forever making them unable to chat. Chat moderation could allow for things like blocking hyperlinks all together, muting people indefinetly within the group chat.

Please improve the responses of the Utility URLs described in https://wiki.secondlife.com/wiki/Linden_Lab_Official:Map_API_Reference#Utility_URLs Since the map API utility URLs need a repair (see https://feedback.secondlife.com/server-bugs/p/map-api-failures-coords-region-name-region-name-coords ), I suggest to add these little improvements of the API along with the fix: If "var" is left out, the response should not be some Javascript code, but: the pure region name, like: "Wicktro", HTTP status code: 200 the coordinates as a simple JSON array, like: "[1134,1056]", HTTP status code: 200 In case that no data is found for the requested coordinates or region name, the response should be an empty body "" with HTTP status code 204. In other cases like the recent error, the HTTP status code should an error code like 500. HTTP status 200 should be reserved for a valid request with found data only. If "var" is given though, the response should be like it has been all the time before the php2shell fix, to not break any scripts that rely on this behavior. REASON The javascript code in the response is useless if you regard basic programming rules and due to SOP. Called from LSL scripts or PHP servers it makes even less sense. In LSL scripts the memory is very limited, so you won't want to waste any of that precious memory on unnecessary parsing. Here is a test example how LSL code could handle the suggested responses: key queryGetRegionName; key queryGetCoords; string regionName; list coords; // to contain region coords as integers updateDisplay() { string output; if ( "" != regionName ) output = "Region: " + regionName + "\n"; if ( coords ) output += "Coords: " + llList2CSV( coords ); llSetText( output, <1.,1.,1.>, 1. ); } default { state_entry() { updateDisplay(); queryGetRegionName = llHTTPRequest( " https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=region&grid_x=1134&grid_y=1056 ", [], "" ); queryGetCoords = llHTTPRequest( " https://cap.secondlife.com/cap/0/d661249b-2b5a-4436-966a-3d3b8d7a574f?var=coords&sim_name=Wicktro ", [], "" ); } http_response( key request_id, integer status, list metadata, string body ) { if ( 200 == status ) { if ( queryGetRegionName == request_id ) { regionName = body; } else if ( queryGetCoords == request_id ) { coords = llJson2List( body ); } updateDisplay(); } else if ( 204 == status ) { llSay( 0, "Sorry, the region could not be found!" ); } else { llSay( 0, "Sorry, the SL map API is not available right now!" ); } } } This way no fancy parsing would be required anymore. No further waste of memory for unnecessary obstacles in the API responses.

Gesture chat spam in crowded areas is very disruptive and problematic for screen readers and translators. A simple toggle should be added to the viewer that filters chat instantiated by gestures from local chat.

To further optimize environment rendering and reduce the massive alpha-sorting overhead currently found in many Second Life regions, we could implement a native way to handle "decal" layers extremely efficiently. Currently, creators simulating stains, rust, signage, grime, and variations must place thin mesh geometry slightly offset from a surface using Alpha Blending. This forces the renderer to perform expensive transparency sorting calculations on every single frame tick to determine pixel draw order, while frequently introducing visual artifacts like z-fighting at mid-to-far camera distances, or even in high altitude skyboxes. Key Considerations: Optimized Alpha Pass Routing: By introducing a dedicated checkbox/flag in the Object Properties and/or Material panel to designate an asset or material-slot as a "Decal," the renderer can route the asset or slot through a specialized, high-efficiency shader pass, tailored to making decals both better performant & better looking. Elimination of Alpha Sorting and Z-Fighting: A designated decal shader pass allows the graphic pipeline to project or clip the texture directly onto the underlying static geometry buffer. This forces the decal to cleanly adhere to the surface below it without requiring continuous frame-by-frame alpha sorting depth checks, yielding superior visual quality and an immense performance lift especially in dense regions/builds. This is not a demand, just a logical suggestion IMHO, something you may have already been considering. It could be both relatively simple for you to implement (based on your choice of industry standard techniques), and bring considerable positive impact on looks and performance.