✨ Feature Requests

I'm a Premium member since forever, and I was delighted when semi-regular gifts got offered for Premium members. They often were from a home/garden or gadget category, which was perfectly fine. Later, when the Lab sought collaborations with popular designers and released designer branded gifts, they became more fashion and accessory oriented, but as such, still catered to all genders, with the collaboration partners usually offering 1 gift for female AND male avatars. This is what I expected from the inaugural event at ACCESS, but I got dearly disappointed. The number of participating designers was impressive, the number of gifts that could be used with male avatars was not. It was not even close to the roughly 40% in previous installments, but more in the range of 1-digit percentages. As a paying Premium member for almost 2 decades, with those gifts by now included among the officially announced perks of a membership, I felt duped. Sure, I did not become Premium because of those gifts. And I would stay Premium even if those gifts would vanish. But if you say (paraphrased) 'Premium members get cool gifts every now and then', then you should make sure that ALL Premium members should get those gifts. I'm not even expecting 50% (or 100%, like when the gifts were not primarily fashion items). SL is a rather feminime world when it comes to fashion, but I would have hoped for at least 30%, better 40%, of the gifts being usable for male avatars. And yes, the irony of suddenly being the disadvantaged gender does not escape me. You're preaching to the choir here. I have my doubts though that this was an intentional message, and merely assume an oversight, or negligence. So, please, more male fashion, or more gifts - like before - from gadget, landscaping, home and garden, vehicles, etc. Thank you!

I built 2 homes and as soon as I package them it shows no modify and no transfer and i check everything and everything I use is full perm and one of the other homes backup was deleted and it was not me who deleted the home and I am asking tech support to fix this and they did not fix it instead the backup home was not there can someone please contact me immediately cause I spent hours to finish the builds can someone please contact me in world to resolve this so I am able to put the homes for sale.

Feature Request: View Previously Used LOD Triangle Settings for Uploaded Meshes As a mesh creator, I frequently adjust the triangle limits/settings for each LOD level during upload in order to achieve the best balance between visual quality and reasonable land impact. The challenge comes when a mesh later needs to be corrected or updated and reuploaded. Currently, there does not appear to be any way to review the LOD triangle settings that were successfully used in the original upload. Unless creators manually document every upload externally, the original working values are effectively lost. This results in unnecessary trial-and-error reuploads, inconsistent optimization, and difficulty maintaining the same visual/LI balance across updated versions of a product. Suggested enhancement: Provide a way to inspect the previously used LOD settings for an uploaded mesh object. One possible implementation: * Right-click mesh object * Advanced / Developer submenu * “View Uploaded LOD Settings” or similar The displayed information could include: * High LOD triangle limit * Medium LOD triangle limit * Low LOD triangle limit * Lowest LOD triangle limit * Physics settings (if available) * Upload optimization method used This would greatly improve creator workflow efficiency, consistency, and asset maintenance, especially for creators managing large product catalogs.

This is a request to build a tool for users to transfer items to a known alt account, and automatically set all transferred items with the alt's name as creator. This is something that would benefit anyone who might import or create content, but then sell under a branded account. The account initiating the transfer would need to be any paid level of account as an encouragement to get on the paid ladder, and to make it worth the while to make the tool. It may also benefit people who wish to give out free and full perm content, without risking a fullperm root prim being abused.

Hello, I have been making Windlights/EEPs for photography and other purposes for some years now and have recently been looking into creating Day Cycles but one thing that is lacking in EEPs makes creating brighter, more colorful nights in day cycles difficult is the lack of the Glow Focus and Glow Size for the moon. In an EEP this is less of a problem as it is a single time of day where the sun and/or moon are in static positions and you can just position the sun where you want the moon to shine from and add a moon texture to the sun, but with day cycles the sun/moon move around the sky as the time of day changes and if you want them to move about organically you can not use the sun as a substitute or aid to the moon. Having these two sliders for both celestial bodies instead of only one would unlock far more potential for photographers, home owners, vendors and others to experiment with and create more and even better environmental settings.

Please allow us to use the voice moderation functions in LSL/Lua. Similar to https://releasenotes.secondlife.com/viewer/26.1.0.20139269477.html but able to be automated.

When will it be possible to make a minimum of 2 shops on the market, at least for premium plus?

There are times when the ability to convert to/from other than base 10 would be really helpful. We can already do this to some extent with hexadecimal: integer FLAG_A = 0x0400; // bit 10; in decimal 1024 However, there's no way to take that integer value of 1042 and display it in hex notation. most of us who script could probably do that one in our heads, but what about where you don't KNOW what the value will be? Or it's a value like, say 11,591? Similarly, if we want to enter a value in binary, there's no way to do so; nor is there a way to convert an integer to binary notation. Therefor I propose 3 functions: string llInt2Hex( integer value ) to accept an integer and output the hex representation; e.g., llInt2Hex( 11591 ) would produce '0x2D47' Similarly, I propose a binary notation - say leading with 0b instead of 0x - to allow entry of integers in binary form; and an llInt2Bin() function that would accept an integer value and output a string with the binary representation, preferably grouped in quads - e.g., llInt2Bin( 11591 ) would produce '0x0010 1101 0100 0111'

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

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.)