✨ Feature Requests

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.

I’d like to know if there is currently any way to link CasperVend vendors with Marketplace listings — meaning, when I add a new product to the Second Life Marketplace, it would automatically appear in one or more of my CasperVend inworld vendors. My idea is to create an inworld gallery-style store, where all products available on the Marketplace are also visibly displayed inworld using CasperVend vendors. Ideally, I’d love to be able to: 💡 Automatically sync my Marketplace inventory with selected CasperVend vendors. 💡 Choose which products appear on each vendor (e.g., categorizing them by theme, product type, etc.). 💡 Allow customers to buy directly from the vendor inworld, while still being counted as a Marketplace sale (or at least maintaining stock/pricing consistency). Why this would be useful: 💡 Creators wouldn’t have to duplicate every product manually between the Marketplace and inworld stores. 💡 Promotes better inworld shopping experiences, while benefiting from Marketplace organization. 💡 Keeps product info, prices, and availability consistent across platforms. 💡 Encourages hybrid shopping behavior — browsing inworld, buying wherever is more convenient. 💡 Saves time for merchants who manage large catalogs. If something like this already exists, I’d appreciate some guidance on how to set it up. If not, I think it could be a powerful feature worth considering for future development, especially as Second Life continues to support both inworld and web-based commerce. ♥ Thank you! ♥

Can we possibly get the ability to use Linden water, or its unique visuals, on surfaces such as a prim in the future? Existing attempts at prim water are decent, but all lack the distortion element provided by the Linden water which adds immersion and realism.

I want to suggest to add the possibility to add alpha masks for Mesh like the Alpha layer functions on BOM Mesh. I am mostly working with Blinn-Phong, like many other creators i do still prefer that system, since PBR is simply not where it should be to be integrated in SL. When one creates a Mesh and then goes into edit of textures we have 3 slots : Diffuse Normal Specular I would like to see a 4th Slot for an alpha mask slot. This Mask would then allow to control opacity - Black for not visible at all to White 100% visible. It would react with grey scale. Programs like Substance Painter do it and make creation super convinient and time-saving instead of consuming. This would allow also for an easy integration in already existing HUD systems. Scripters would just have to add the new slot as button options. Cutting faces on Mesh and adding materials ( face slots) is a tiresome process. It also takes more render capacity on PC. With this Method in the most optimistic situation one would have one mesh and could affect the opacity in different areas with simply changing the alpha Mask texture.

Light cast by projector lamps leak on the other side of walls, floors, ceiling. This happens both on prim and mesh surfaces. Attached picture shows light leaking on ground floor ceiling from light cast by a ceiling projector lamp in first floor in a linden home. To avoid this only solution seems to dial down the intensity of the lamp, which eliminates the cool lit floor effect ◑︿◐

Currently we can't update animesh size and have to upload multiple versions of the mesh in different sizes, and upload all animations for each size. I did some research in the viewer's code, and it appears to me that it's extremely easy to add a feature to adjust the global size of an animesh by modifying the llcontrolavatar.cpp file. Here is the current setGlobalScale() function: void LLControlAvatar::setGlobalScale(F32 scale) { if (scale <= 0.0) { LL_WARNS() << "invalid global scale " << scale << LL_ENDL; return; } if (scale != mGlobalScale) { F32 adjust_scale = scale/mGlobalScale; LL_INFOS() << "scale " << scale << " adjustment " << adjust_scale << LL_ENDL; // should we be scaling from the pelvis or the root? recursiveScaleJoint(mPelvisp,adjust_scale); mGlobalScale = scale; } } And here is a modified version that currently takes into account the X size of the main prim: void LLControlAvatar::setGlobalScale(F32 scale) { if (scale <= 0.0) { LL_WARNS() << "invalid global scale " << scale << LL_ENDL; return; } scale *= mRootVolp->getScale().mV[0]; if (scale != mGlobalScale) { F32 adjust_scale = scale/mGlobalScale; LL_INFOS() << "scale " << scale << " adjustment " << adjust_scale << LL_ENDL; recursiveScaleJoint(mRoot,adjust_scale); mGlobalScale = scale; } } Note that I replaced mPelvisp by mRoot because using mPelvisp does not correctly adjust the animesh's movement during the animation." It works wonderfully. Of course, this modification as it stands could affect many existing animesh objects, so we need to add a parameter to the object, 'ANIMESH_SCALE_FACTOR', which would be set to 1 by default, adjustable via script and by manual editing of the object. We would then have something like this: scale *= mRootVolp->getAnimeshScaleFactor; Here is a gif, you can take a look, the 4 dogs are all the exact same animesh, I only changed there main prim X scale : https://gyazo.com/de2dc2904bcb4e6b8737514aa7db7d2c

This feature would allow creators to negatively flip an object. So if you wanted to mirror an object, like a corner of a building, you would copy the objects and type in the editor XYZ SIZE window - (negative) before the number to flip it. Very useful with structures and would save a lot of time on imports and texturing.

Adding the .gif files to the allowed list to upload, letting us create animated particles, textures without the classic LSL moving into the same framed image

Currently, scripted updates to PBR materials using PRIM_GLTF_BASE_COLOR require supplying the albedo texture UUID, even when the texture is not being changed. This creates significant issues for content creators: Scripts cannot retrieve the UUID of the albedo texture on copy/no-mod items due to asset permissions. Without the UUID, any attempt to change the color results in the texture being stripped or reset. This severely limits the usefulness of scripted HUDs and color changers for PBR-enabled items. Request: Add a new function: llSetPBRColor(integer link, integer face, vector color, float alpha); This would allow a script to tint a face that already has a PBR material, without having to re-specify the texture UUID or overwrite the material. Alternatively, allow PRIM_GLTF_BASE_COLOR to accept a special value (e.g., NULL_KEY or "*" or USE_EXISTING_TEXTURE) that tells the function to preserve the current texture. Why this matters: Improves usability and parity with Blinn-Phong materials (llSetColor). Empowers creators to build dynamic, color-customizable content with PBR. Removes technical roadblocks and permission conflicts when selling no-mod items. Thank you for considering this — it would greatly improve PBR scripting workflows for the creator community.

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.