✨ Feature Requests

In official viewer when I select a prim or mesh it gets ghosted as if having 100% transparency, and only see the border highlights (when that is enabled). How to prevent items from looking full transparent upon selection? If not possible please add a toggle for this.

Since PBR came out, I've essentially been almost PBR-exclusive with my store creations, mainly because PBR is just so much easier to work with for texture HUDs than Blinn-Phong (aka non-PBR textures, classic textures, legacy textures, traditional textures, etc). Part of this is because all of the textures involved are bundled into materials that are a single object with all of the settings saved rather than having to put everything in manually like non-PBR. It would really help creators offer both options and cut down workload by a TON if we could also bundle blinn-phong textures as materials. I don't know about other stores but I like to really tweak the specular settings and often the specular colors as well for metallic and generally more realistic effects rather than leaving everything white for all colors, and coding that into the HUD is fankly, a gigantic pain in the ass. Even if they were called something different like texture bundle or something to avoid confusion for people who sell them and to differentiate in our inventories that would be fine. I know we would not be able to upload them together the same way as PBR because it involves separate files, but there's no reason we shouldn't be able to create the material in-world manually on a cube or something and save it the same way. Bonus if double-sided can be an option for blinn-phong too! It would cut down on geometry needed on a mesh if we don't want it to be one-sided since we could simply check that on like on PBR materials, rather than needing to solidify a mesh (and essentially double its geometry) in order to get the same look. PLEASE let us manually create blinn-phong material bundles that include diffuse, normal, specular, alpha, glow, shininess, environment, shine color, full bright, and blending mode settings. It would make the jobs of creators working with blinn-phong in any capacity much easier, coding HUDs would be easier, and if double-sided can be an option it would also cut down on mesh complexity since people wouldn't need to solidify or fake edges on their meshes to hide that it's just a plane.

I think crypto casinos could be a popular feature on SL...if LL has problems with Californian law, they can always register in Malta and apply to the Malta Gaming Authority for approval. I'd personally love to spend an evening playing poker and blackjack against other residents, with a few hundred DOGE at stake : D

Considering that boating, sailing, and diving are among the very few activities in Second Life that function reliably but also continue to attract an engaged, creative community, it’s honestly baffling that the Community Islands in the Blake Sea have been left untouched for — what is it now? — 17 years? Seventeen. That's not just a long time in virtual-world terms, it's practically a digital ice age. Meanwhile, the Blake Sea remains the central artery of Second Life — the core maritime network connecting the continents, and arguably one of the only places where the grid feels alive, immersive, and socially dynamic. Yet the infrastructure looks like something out of 2007 — because, well, it is. With all the advancements in mesh, environment systems, and scripting tools, it’s not as if the technical limitations are insurmountable. In fact, a small, focused team could probably refresh the entire set of islands in a week or less. So it raises the question: Why hasn’t this been done? Is there a fear that improving one of the most consistently active areas of the grid might accidentally make the user experience too enjoyable? Or is it just easier to roll out shiny new products and ignore the parts of the platform that people actually use and love? The Blake Sea isn’t just some peripheral backwater — it’s a living, breathing hub of user-driven content and activity. If anything deserves a little attention (and perhaps a modern texture or two), it’s this space. Or do we have to wait until Second Life’s silver jubilee for someone to dust off the prims?"

Multiple Projectors/Lights from single prim. 1 LIGHT PER each face. This could allow for better area effects/light and less LI usage.

A tick box (on prim properties) to cancel light in an area, or use dark to black similarly to way that the light/projection system handles light. It could have the same or similar parameters.

Now that we have a way to partially hide water, it would be nice to be able to click through water excluding surfaces. This is where 2-sided materials come into play, as only one side registers clicks. On the image below some of the clickable controls of the vehicle are now unreachable, being hidden behind the water excluding surface, which forces me to choose between keeping the interactivity in, or keeping the water out. Please address.

We know that official RLVa support is "on the roadmap" but also not coming any time soon. I'd like to propose something that could be done immediately that would add a small measure of "official RLV support" that would extend the functionality without interfering with any existing stuff, leaving plenty of space for "the rest" at a future time. Simply, the viewer could hold an official new data field, the "RLVa version" (or whatevs we want to name it), and a new scripting command llGetRLV() would cause the simulator to ping the viewer of the object's owner and get the string. It's that simple. What this gains for us: Trivially, the Second Life Viewer can set this to "" for now, since there's no RLV(a) support. Other viewers could set this string to the appropriate version. Future scripts could find out RLV enabled status just by checking this string, with no need for the message protocol. Nothing existing today breaks/changes in any way, but suddenly all future scripts could use this instead of current methods, which tend to spam the chatboxes of anyone without RLV enabled. The back-and-forth script dance of version checking is such that currently, many makers of RLV items simply assume that if you've worn an RLV-possible item, you knew to have RLV on. This single official step would help RLV scripters get their stuff working, and help RLV abstainers be spammed less in the future!

I would like to see optional additional windlight orbiting bodies in addition to the Moon and Sun. I was floating the idea around of using the moon texture and replacing it with asteroids or some other fictional planet. It would be really cool to add more bodies with a custom texture, Azimuth, Elevation, and Brightness

To compile a script & associate with an experience you need to have mod perms to the script itself. I want to distribute scripted products that may be associated with the buyers experiences but not give them access to view my scripts themselves. eg: 1. integer llAssociateExperience(key UUID of experience) 2. list llAssociateExperience(key UUID of experience) or: 3. key llRequestExperienceAssociation(key UUID of experience) Associates the experience with the script (overriding what may already be there) exactly as if the script was recompiled associated with it. The same checks are performed that "Use Experience" does. Option 1 Delivers true if UUID corresponds to an experience the owner of the object the script is running in has appropriate permissions Option 2 Delivers the same information as llGetExperienceDetails (after association of course) Option 3 delivers data Server event or similar with results As llGetExperienceDetails is immediate & doesn't require an event I prefer option 1 or 2.