✨ Feature Requests

I suggest an enhancement to the Bakes on Mesh (BOM) system by introducing an opacity option for BOM layers. As a designer, the current limitations of BOM force us to add additional mesh layers, particularly for makeup applications. This increases mesh complexity and necessitates the use of complex HUDs. Enabling opacity control on BOM layers could eliminate the need for extra mesh layers, thus optimizing mesh complexity and enhancing overall performance. Additionally, this would allow for greater flexibility and creativity, as BOM makeup layers wouldn’t be limited to one or two mesh layers (depending on the number of mesh layers created by a designer). With the recent introduction of 2k BOM textures, the capability to adjust blend modes directly on BOM layers would be highly beneficial for both designers and users. It would offer more customization options and improve the user experience. It would positively impact the creative community and contribute to a more streamlined and efficient design process.

BOM layers that can glow. Would be quite nice and remove onion layering for mesh models and help save on resources. I know PBR is a thing but it does not allow the flexibility of BOMs. I have species that have different glowing markings and bioluminescence on their bodies that I'd love to be able to do in SL. My team and I heavily utilize BOMs so our customers can make rather unique pattern and color combinations. Shiny BOM layers would also be really nice.

I've thought for years that there should be some sort of bonus or perk for someone who has been active in SL for ten years (and more after 20! years). It could be a discount in the membership fee, additional land, a bump in the monthly stipend or just a one-time (or maybe annual) "Happy Rez Day!" deposit of L$. There should be some sort of "minimum activity" requirement in there so the perk doesn't go to dead accounts. Those of us around this long (16 years for me) are not just Residents; in RL we're Ambassadors. We're the folks out there actually trying to explain what this crazy place is and why they should try joining us. The Old Av Bonus would recognize that good work.

I'd love to be able to have the body and my head shapes be separate. Right now the shapes are tied together as one shape. I would love to be able to say, purchase a head shape someone has created and be able to apply it without changing my body shape as well.

🔴 Summary 🔴 Second Life has come a long way, but OpenGL is becoming outdated. To ensure SL remains visually competitive and runs smoothly on modern hardware, I propose that Linden Lab begins development on Vulkan support as a long-term goal. This transition would greatly improve performance, reduce crashes, and allow SL to take full advantage of modern GPUs. 🟡 Why Vulkan? 🟡 ✅ Better FPS & Performance – Vulkan is optimized for multi-core CPUs and modern GPUs, meaning higher frame rates and less lag in complex environments. ✅ More Stability & Fewer Crashes – Vulkan manages memory more efficiently than OpenGL, reducing viewer crashes and graphical glitches. ✅ Future-Proofing Second Life – OpenGL’s development has slowed, while Vulkan is the industry standard for new and upcoming graphics engines. ✅ Improved Graphics Potential – Vulkan supports advanced rendering features that could enhance lighting, shadows, reflections, and materials in SL. 🟢 How This Transition Could Work Smoothly 🟢 Instead of a sudden shift, I suggest a gradual development plan (2025-2030): 1️⃣ 2025-2026: Linden Lab researches Vulkan feasibility and starts experimental development. 2️⃣ 2027-2028: An optional Vulkan beta mode is introduced for testing and optimization, running alongside OpenGL. 3️⃣ 2029-2030: Vulkan becomes the default renderer, with OpenGL as a fallback for older systems. 4️⃣ Community Engagement: Regular updates from Linden Lab on progress, plus support for third-party viewers adapting to Vulkan. 🔵 Why Start Now? 🔵 Even though this transition will take years, starting early ensures SL stays ahead rather than falling behind other virtual worlds. A well-planned Vulkan integration could attract new users while making SL smoother for current residents. If you agree, please upvote and share your thoughts in the comments! Let’s show Linden Lab that the community is ready for a modern and optimized Second Life! 👍 💬 �

Yet another day of begging bots hitting many groups and asking for 100L. It's deeply tedious for group moderators, and users are being scammed. For whatever reason this is a problem that has plagued SL for years without any sign of resolution. A common solution has been to put a L$1 sign up fee for groups. This is less than ideal because it creates a barrier to users who have no money at that moment. Also it's no longer working, as I've seen a begging bot kicked out of such a group today. We had a big discussion about solutions in the "Friends of Philip" group, and finding any solution that doesn't create problems of its own seems hard. However I'd like to suggest that when people join a group, they are presented with a challenge-response problem. The issues with Captcha itself are well documented, but some simple challenge that's easy for users and hard for bots (perhaps based on the "honeypot" method?) could dramatically help with this. Maybe this should be a separate entry, but it would also be immensely helpful to have an alternative to group bans, allowing us to temporarily ban a user. Currently these bots get banned, vanish, and are still clogging up the group ban list. If we had temporary (say 1 month) bans as an option, they'd get cleared out of the group ban list.

Currently, a specific animation priority level must be specified by the creator and after uploading it to SL, that priority level cannot be altered. However, the priority level of each animation should be user adjustable in SL.

Note: I know this was suggested before and it's tracked. I know this will be merged. That's okay, I wanted to give more suggestions on implementation and answer "why" beyond that it would just be a nice feature. Problem: You don't want to see stuff made by a certain creator on the marketplace. There may be a variety of reasons for this. Here are a few examples. You have the shop owner in game block due to harassment, drama, or other personal reasons and don't want to accidentally give this person money. The vendor is selling rips. The seller has a business model you don't want to support. Maybe you don't want to buy clothes that are no mod, maybe they have shady business practices that involve over-editing their ads, or using AI on their ads resulting in false advertising. Maybe the seller's content makes you deeply uncomfortable such as selling adult products but the models scream childlike and you don't want to see that. The seller is flooding the marketplace with thousands of generative AI textures to make a quick buck, making it impossible to find high quality textures. This is a growing problem that needs urgent addressing. Solution: Allow us to block the shop and/or the owner of the shop. Owner might be better in case the marketplace someday expands to let a single user have more than one storefront. Or both. Blocking a particular product may also have its place. Implementation: Beneath the flag listing link there would be additional links: Block this shop Behavior: Browsing and searching omits all products from the store. Adds shop to a block list. They can be removed from block list if needed. Block this seller (<--- Alternative, or TBI if multiple storefronts ever becomes a thing.) Behavior: Browsing and searching omit all products from any and all products from the store. A popup that asks, "Do you want to block this person from your shop as well?" may be a good move in some circumstances. They can be removed from block list if needed. Hide Product Behavior: Omits an individual product from search and browsing. Unhide Product Behavior: Removes product from hide. How would you find a listing if it was hidden? Give people a checkbook to show hidden products in search and browse. By giving us the tools to better curate our experience with the marketplace you will empower users to find what they want without having to wade through things they don't want to see, increasing the likelihood of them spending money instead of getting frustrated and giving up on the search.

With massive inventories in the >> 80k items range, especially for older residents, there are a lot of folders that are basically stuff a resident does not use frequently. Stuff you would move to the attic in RL. This slows down searching and finding items and causes UX issues when the inventory UI slows to crawl or search is super slow. Examples include pristine copies of items only kept as backup in case the active item breaks down. Legacy stuff that fell out of fashion, but is too good to simply delete. Tons of other things. It would be useful to mark such folders with some "attic" or "archived" category to get them out of the way. Those items should not show up in the default inventory list, should not be found by the default search and should be treated as basically non existant unless explicitly requested. They should not be wearable or attacheable in that state. Those attic / archived items should be de-prioritized for inventory loading. The inventory could be considered fully loaded for all important purposes even with all archived items still missing. This would speed up initial avatar loading in some cases. The items should also not simply be display filtered but put in an entirely different structure (maybe extra tab in the UI) to have performance gains in search and browsing. A bit like those infinite chests in games, where all the loot gets put thats not useful but still worthy of keeping.

Current character limit (~512) is really restrictive, especially if you're trying to put, for example, more than one url / slurl in there. (Yes, I know about URL shorteners, they're timebombs; and I know you can attach landmarks. I'm just using these as an example) We can use notecards as an attachment in the notice as a workaround, but that takes up the singular notice attachment slot, which isn't super ideal if you have something that isn't fullperm (and therefore notecard-able) you want to send out too. New character limit doesn't have to be novel-length; even just doubling it to 1024 would help a ton.