✨ Feature Requests

Let's invent a label - something simple, like "GenAI was used in whole or part in this object's manufacture" and then /require/ creators/vendors to label all of their relevant sales items with it. Let this label also be a tag or flag as part of an object's or sales vendor's properties, so that Residents don't have to struggle to know if an object is GenAI-"containing." Let this also be a tag or flag on the MP and in any other searchable interface where it makes sense to exist, so that Residents may include or exclude GenAI items in their search results. GenAI is not going anywhere. The ethics of its use are a separate matter. But Residents have a right to be informed of the tool's use in the creation of their purchased items, just as we have a right to know whether a food IRL has been genetically modified. Let Residents be advised of the use of GenAI to create purchasable goods, and thereby purchase according to their own preference. Please disregard, and accept my apology, if this issue has already been discussed/addressed. Thank you.

The alignment tool is very useful for aligning objects to an axis, but it doesn’t work on linked prims, forcing us to unlink them first. What about enabling alignment for selected linked prims when the ‘Edit linked’ checkbox is checked?

The current llGetBoundingBox function returns the bounding box with the root objects axes being used to define it. A globally based one in region co-ordinates could be useful. I've just had to put a function together to achieve this to find suitable co-ordinates for a llTriggerSoundLimited call. list GetGlobalBoundingBoxFromKey(key targetKey) { list info = llGetObjectDetails(targetKey, [OBJECT_POS, OBJECT_ROT]); list bbox = llGetBoundingBox(targetKey); if (llGetListLength(info) != 2 || llGetListLength(bbox) != 2) { // Invalid input return []; } vector rootPos = llList2Vector(info, 0); rotation rootRot = llList2Rot(info, 1); vector localMin = llList2Vector(bbox, 0); vector localMax = llList2Vector(bbox, 1); list corners = [ <localMin.x, localMin.y, localMin.z>, <localMin.x, localMin.y, localMax.z>, <localMin.x, localMax.y, localMin.z>, <localMin.x, localMax.y, localMax.z>, <localMax.x, localMin.y, localMin.z>, <localMax.x, localMin.y, localMax.z>, <localMax.x, localMax.y, localMin.z>, <localMax.x, localMax.y, localMax.z> ]; vector globalMin = <255.0, 255.0, 4096.0>; vector globalMax = <0.0, 0.0, 0.0>; integer i; for (i = 0; i < 8; ++i) { vector localCorner = llList2Vector(corners, i); vector worldCorner = localCorner * rootRot + rootPos; if (worldCorner.x < globalMin.x) globalMin.x = worldCorner.x; if (worldCorner.y < globalMin.y) globalMin.y = worldCorner.y; if (worldCorner.z < globalMin.z) globalMin.z = worldCorner.z; if (worldCorner.x > globalMax.x) globalMax.x = worldCorner.x; if (worldCorner.y > globalMax.y) globalMax.y = worldCorner.y; if (worldCorner.z > globalMax.z) globalMax.z = worldCorner.z; } return [globalMin, globalMax];

As a long-time business owner in Second Life, managing operations efficiently is crucial. Recently, enforcement of the TOS on account sharing led to the deletion of our entire marketplace with over 2000 listings, severely disrupting our business. Deathrowdesigns (DRD) serves over 10,000 customers and manages more than 3,000 items, making single-person management infeasible. I propose creating a system for obtaining written consent to share business accounts among trusted individuals, specifically for business operations. This would help businesses like ours continue to thrive without compromising account security. Additionally, it would ensure compliance with the TOS while providing a practical solution for businesses that need to share account responsibilities.

Hi can you please increase ocean depth to 12288 meters for sailing, submarines and aquatic gameplay 256 x 48 = 12288 meters The ocean's average depth is about 3,682 meters (12,080 feet). The deepest point, Challenger Deep in the Mariana Trench, reaches approximately 10,994 meters (36,070 feet). The ocean is divided into several depth zones, including the abyssal and hadalpelagic zones, with the latter being the deepest. Depth zones of the ocean - World Ocean Review World Ocean Review Here's a more detailed breakdown: Average Depth: The average depth of the ocean is around 3,682 meters (12,080 feet). Deepest Point: The Challenger Deep, located in the Mariana Trench, is the deepest known point in the ocean, reaching approximately 10,994 meters (36,070 feet). Depth Zones: The ocean is divided into different zones based on depth: Abyssopelagic Zone: Also known as the abyssal zone, it extends from 4,000 to 6,000 meters (13,100 to 19,700 feet) and is characterized by near-freezing temperatures. Hadalpelagic Zone: This is the deepest zone, extending from 6,000 meters (19,700 feet) to the ocean floor, with constant temperatures just above freezing. https://www.google.com/search?q=ocean+depth&sca_esv=3d1e29cf7e253e0e&source=hp&ei=BvyMaNzFMJDawN4Pm-Gn-AE&iflsig=AOw8s4IAAAAAaI0KFo01jzOl-MnFXk7SYTjNEa_d3fXd&ved=0ahUKEwjc4PqElOqOAxUQLdAFHZvwCR8Q4dUDCA8&uact=5&oq=ocean+depth&gs_lp=Egdnd3Mtd2l6IgtvY2VhbiBkZXB0aDILEAAYgAQYkQIYigUyBRAAGIAEMgUQABiABDIFEAAYgAQyBRAAGIAEMgUQABiABDIFEAAYgAQyBRAAGIAEMgUQABiABDIFEAAYgARItAVQAFgAcAB4AJABAJgBcKABcKoBAzAuMbgBA8gBAPgBAvgBAZgCAaAClwGYAwCSBwMwLjGgB_UEsgcDMC4xuAeXAcIHAzQtMcgHIQ&sclient=gws-wiz

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

The 'Skin' body part inventory type should support PBR materials. In other words, add PBR to the skin baker. Many of my characters have non-human skins such a fur, scales, metal (robots), stone (statues), wood, or other interesting and fantastical materials. Opening up avatars to PBR materials would allow these to be used directly without relying on appliers. As an initial release, PBR could be added to just the "skin" rather than clothes, tattoos, and the 'universal' clothing type. Any "legacy" clothing worn layers worn over top would be treated as "Base Color" and set the normal, roughness, metalness, occlusion, and emissive maps to "default" values (where not transparent) so the skin material doesn't shine through. Alternately, PBR skins could disable all legacy clothing. Whatever gets us PBR skins fastest. Later on, PBR clothing could be added with different blend modes. A "robotic" or "doll" tattoo, for example, could blend a normal map onto the skin to create different looks for the base skin.

I would like to ask if it would be possible to add the option to limit a PERMISSION_DEBIT request, as in the script, can request a pool of money, it's allowed to pull So in place of any system that is requesting to be able to pull money from a user, having to always ask for access for any amount, you can set a pull amount it's allowed to take, making the ability more limited, allowing for a safer use of it when there is no need pull endlessly For one example, the HUD vendor systems request permission when you try to buy something, it be nice if in that case, it were limited to only take the amount marked and not more (without opening a new request)

Hello Linden Lab Team, We build audience-interaction wearables (e.g., tip-triggered animation/sound). Today, auto-reacting to a supporter’s payment without HUDs or rezzed proxies isn’t possible because attachments receive no payment event and CLICK_ACTION_PAY is ignored while worn. Could you consider these minimal, safe additions? Attachment payment event event avatar_money(key payer, integer amount, key txid) in scripts of the paid avatar’s worn attachments. • Read-only; no debit; viewer shows a one-time disclosure; rate-limited. Pay on attachments Treat CLICK_ACTION_PAY on worn items as “Pay the wearer” to open the standard Pay Resident dialog. Amount-aware Pay URI secondlife:///app/agent/<avatar_uuid>/pay?amount=100&memo=SpankBank so attachments can present the official pay UI with a preselected tier (still user-confirmed). (Optionally) A read-only llGetLastPayment() or an Experience callback covering the same ground. These changes enable modern, creator-friendly interactions (performances, charities, club tools) while preserving user consent and platform safety. We’re happy to provide test content and help QA. Thank you for considering this—many creators would use it immediately. Best, Blews Daniels, Embraced Designs

I’d love to see support for channel-packed textures in the importer so multiple maps can be combined into one file, along with a multi-tint system available in the object edit window and avatar appearance editor. I hope it's okay to put two suggestions in one (never posted on this feedback thing before), since I sort of hope for them to work in tandem. RGBA Channel-Packed Textures: Allow the texture importer to pack maps (e.g., normal, emissive, ambient occlusion, etc. - or - channel information to specify "tinting zones") into the Red, Green, Blue, and Alpha channels of a single image. Multi-Tint Support: Add the ability to apply up to three color tints (based on the packed RGB channel information) within the object edit window and avatar appearance editor. Packing maps into a single texture reduces uploads and texture bloat, which improves performance for everyone. Multi-tinting would make it easy to offer better customization options directly in-world without needing as many separate textures; giving both creators and users more creative flexibility with less complexity.