✨ Feature Requests

When uploading in bulk, all the uploaded content is just dumped into the main inventory at root level. When a bulk upload sends a folder from the client machine, a corresponding folder should be created in inventory. Folders within folders should, of course, be uploaded maintaining the folder structure. With glTF coming in, uploading textures and meshes at the same time is more useful, so more structures is needed. (My own interest is that I need to upload a large number of of textures for region impostors, and they all end up in my root folder. I need subfolders.)

So I think it would be cool if objects could be linked at a greater distance. And also create groups so that way people that make things like trains or large Houses can keep them all linked together. And unlinking groups of objects, instead of just individual one.

When you modify an object, scaling along the X, Y or Z axis allows for a minimum of 0.01m. I propose allowing negative scales, which would otherwise mirror an objects geometry. Symmetry tools are standard in most 3D creation environments. Adding mirroring functionality would modernize Second Life’s in-world building tools and support both new and experienced creators. To have this work fully, SecondLife would have to support both negative scales and flipping the physics mesh layer on the server. Some use cases for this: Creating symmetrical architecture/furniture. Mirroring avatar attachments. Adjusting mesh without requiring multiple uploads for each different mirror axis. I've made a bit of a mock-up video which hopefully explains this feature request a LOT better! (this displays stretching an object, as well as 'mirror' checkboxes for each axis)

In firestorm there is a tool to export prim builds as collada files, I'm not sure if a similar tool is available in the official viewer at all. But this functionality is extremely useful for mesh creators to create scale mockups of their builds that can later be imported into 3D software like blender. However, since blender is removing collada support as of Blender 5.0 a new tool such as this is needed. The GLTF uploader is great, but without a GLTF exporter it will complicate and hinder mesh creation in many ways. I don't know exactly which viewers has had this features in the past or if it was only firestorm that had it, but it is something that would be useful and/or needed on all viewers, which is why I think it would be great if this was implemented in the SL viewer first since that will naturally spread the feature to third party viewers over time. Personally I depend on exporting mesh in my workflow, so I will have to stay on Blender 4.5 until a new export tool is available that supports GLTF.

I would like to request the following: 1) a command to insert a debugging note of the scripter's choice, but prefixed with useful information such as the script, state & event / custom function, and line number. It would chat privately the same way llOwnerSay() does. Example usage in a script: llDebugSay("At this point we are switching modes.") Output would look like: [12:18:33] Test Object: DEBUG [NewScript, default, state_entry (43)]: At this point we are switching modes. Since custom functions are defined prior to the start of the default state, and a function always takes at least the form of functionname(), it should be possible for the compiler to identify the name of the function and use that instead of the state & event, as follows: // this is a custom function that does something string customfunction( integer foo string bar ) { ... a bunch of code... llDebugSay("At this point the framistan should have blogulated."); ... more code... return somestring; } Output would look like: [12:18:33] Test Object: DEBUG [NewScript, customfunction() (12)]: At this point the framistan should have blogulated. Everything from (and including DEBUG) to the colon after the square bracket should be generated by the function itself, not something the scripter has to type in. 2) a command to insert a debugging variable dump of specified variables (up to a reasonable maximum; if more are needed, scripter can always use a second command). It would be able to report any variable known to the script scope at that point. Again, it would chat privately the same way llOwnerSay() does. Example usage in a script: llDebugVarDump([MENU_TIMEOUT, ModifiedColorVal, collar_prefix]); Output would look like: [12:18:33] Test Object: DEBUG variable dump: MENU_TIMEOUT: type=float, value= 15.0 ModifiedColorVal: type=vector, value=<0.72,0.2,1.0> collar_prefix: type=string, value=rh 3) A command or meta-variable or script editor command to enable/disable those commands. The idea is that it would not be necessary to remove the llDebug* commands; they simply would not execute UNLESS a box was checked (similar to the □Run and □Mono checkboxes), or there was a command that had to be the VERY FIRST executable line (so it could follow a bunch of comments, but would have to be before ANY variable declarations, function definitions, or start of the default state); something like this: // initial comments in script DEBUG; // all llDebug* commands will function If that line with the one word, DEBUG, was absent, all llDebug* commands would be treated as comment lines, possibly even to the extent of being coloured the same as comments. If this 3rd part isn't possible, at least the other two commands could be easily found and deleted or commented out just by searching for llDebug

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.

Right now, SL has great pieces of history and exploration culture scattered around, but nothing that functions as a home for hidden gems, little-known places and especially Mole secrets. Other MMOs have “Explorers’ Guilds” that celebrate discovery and the MMOs history. I’d love to suggest a very lightweight version of that idea for Second Life; something focused entirely on exploration for residents who enjoy wandering off the beaten paths. The talented and busy Moles hide fun details in their work, but there’s no official list, no hints, and no “start here” point. Discoveries spread by word of mouth or Flickr. Some bloggers collect “strange places,” but they’re not maintained long‑term, and none of them are official. Many new and even long-term residents aren't aware that the Moles exist and are a real team with a long history or that SL has lore, inside jokes, and environmental storytelling scattered everywhere. An explorers guild home base would help surface that history in a fun and low-pressure way. There is more to SL than meets the eye! An in‑world Explorers Guild homebase, built by the Moles, could offer clues or hints, giving explorers a place to start. Something that piques interest. No new systems or gamification are required. It might also help to add an “SL Hidden Gems and Little-Known Places" category to the destination guide on SL's website to make this kind of content more visible. Thanks!

Let us import a mesh with multiple uv maps so we can swap the uvmap in the texture tab instead of having to import multiple meshes if we want to support multiple uvmap sets. Am sure the performance would improve vastly, I see many products with multiple meshes combined so we can choose which UV set we like (mostly heads in this case) but there's many products that come with multiple UV versions (per example, to support multiple texture placements on the BODY for a BOM tail), thank you.

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.