✨ Feature Requests

Second Life presents itself as a creative platform, but the 'Destination Guide' currently surfaces mostly lifestyle‑oriented categories (beaches, clubs, homes, shopping, photogenic regions, etc.). This unintentionally frames SL as a lifestyle simulator for new residents, even though the platform supports far more imaginative and non‑realistic content. There is no clear place in the 'Guide' for: surreal or dreamlike environments, experimental or conceptual builds, impossible architecture, non-realistic worlds, creative experiences that don't fit in existing categories. These spaces do exist in SL, but they're basically invisible to newcomers because the 'Guide' doesn't signal that they're part of the platform's identity. This isn't a criticism of existing categories, just an observation that a major creative segment of SL isn't represented. A few new categories would make the 'Destination Guide' more accurate and more welcoming to the imaginative side of the platform. Thanks!

Please give us more Colour Picker save spaces, which is currently limited to just 32 saved colours. Double it to 64, or perhaps 128, or even 256?! I used up my 32 saved colour spaces years ago and have to physically store my newer colours on physical prims as my "Colour Palette" ! Thanks.

stop me if you've heard this one before... * you send your build to your partner to texture, they send it back all textured. you rez it on the ground to set permissions, but when you pick it up, it is NO COPY to you. * you want to use a particle effect you created for an alt. so you log in to your alt, set it back to full perm (so you think!) and hand it over. when your main links it to a build -- oops, there was a no transfer object inside the prim. now your whole build is NO TRANSFER, and the entire linkset is corrupted and you can't change it. PROPOSED SOLUTION: * when hitting LINK (ctrl-L), pop up a warning if linking this new thing to your build will change the whole build's permissions TO YOU. ie: --linking a no copy object to your build --throwing a no-transfer script or object into the contents etc. * when placing a texture on a build, warn if your texture permissions are NOT FULL PERM. because the texture perms suck. :/ * ditto when trying to throw on a material.

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.

The Second Life inventory library only contains 'legacy' environment settings. As a parcel owner, I have no way to change my parcel's day cycle to the "new default" that was added as part of the PBR release - only region owners can do that. Could the new environments, such as the "PBR Mid day" and the new PBR default day cycle be added as full permission resources in the SL library? That would allow us to more easily take the "new default" and make minor adjustments instead of starting from scratch.

Currently each mesh object can have 8 faces. However, if I link 255 together, that is effectively 8 * 255 = 2040 faces in that linkset. I think there would a lot of benefit if a single object could have a maximum of 2040 faces but be unlinkable or a linkset could be comprised of objects with more than 8 faces as long as the current maximum number of faces per linkset is not exceeded. This would give us more flexibility in structuring our mesh objects and give us the ability to eliminate workarounds that are inefficient. If the user tries to link another object into a linkset which would exceed the total number of faces for the entire linkset, then it would fail to link in the same way it fails to link if you try to link more than 255 objects together. Examples: * 1 object could have a maximum number of 2040 faces but then could not be linked to another object. * 5 objects could have 16 faces and another 20 objects could have 4 faces for a total of 160 faces which could all be linked and is equivalent to 20 objects in a linkset each with 8 faces. One area where this could be a benefit is mesh bodies with alpha cuts. Today they are linksets of about 25 objects so that there are about 200 faces for enough cuts. Each object brings extra overheads as well as the faces. With the scheme I outline here, one object would be able to have 200 faces and so a mesh body would not have to be cut up and linked. It would still be more efficient than a 25 object linkset. There are many other applications which would benefit from this scheme. NOTE#1: It may seem open to abuse to allow a single unlinked object to have this many faces but in reality if someone wanted that many faces today, they already could and the 255 object linkset would be far worse than a single object with the same amount of faces. NOTE#2: Obviously the number of total faces per object wouldn't have to be that high. There would still be a lot of benefit. The point is in adding the flexibility rather than what the actual per object maximum should be.

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.

Allow terrain textures to be set on own land. Terrain textures on my land have priority over those of the Region. This allows us to make better use of the terrain on the mainland and on the land we rent.

Using Blender and probably other 3D authoring tools, you can name the materials assigned to the faces of the mesh. These names are then included in the export to DAE and GLTF/GLB files. But as soon as it's uploaded to SL, this information is either lost or at least is unavailable to viewer and scripts. In SL we can only access the so-called "side number", which is used for various things such as tinting or applying a material asset with a script. It would be helpful if the material names in a mesh upload could be retained, such that it then can be accessed by scripts, and possibly by viewers too should it be desired in for example the toolbox window. I will file a separate ticket referencing this one, regarding how this could be used with scripts. It's now found at https://feedback.secondlife.com/scripting-features/p/get-list-of-assigned-material-names-for-mesh-sides I don't believe that this feature will have any negative consequences beyond increased data storage utilization.

If Gacha is coming back to SL in full force as Transfer items, I feel we need the following: A standard, required script that allows the user to click on the machine and receive the odds of each category of item. Merchants may continue to set their own percentages, and tiers of rarity. For example, the output might look like this: Common: 80% Rare: 15% Ultra rare: 4% Secret rare: 1% Or another machine might look like this: Common: 75% Uncommon: 25% And a machine you might not want to play could display this: Common: 99.9% Rare: 0.01% The above are simply an example and not a suggestion for setting a specific required percentage or tiers. I still believe we should leave that up to creators, but that the chances of getting an item you want shouldn't be a mystery. This is a disclosure commonly included in Gacha games or games containing Lootboxes. Many Gachapon machines are also beginning to display odds in real world spaces. If folks want their feedback on maintaining the ban, there is another feedback post for that. I humbly request we keep this one on topic so it doesn't get merged. ❤