✨ Feature Requests

Allow us to have regions with 10K LI.

I believe that, with the economy in the way it is, it would be beneficial towards the health and longevity of Second Life for Linden Labs to offer discounted incentives for private regions who run not-for-profit communities on this game, much like educational Institutions and charitable institutions are able to do. These should be regions that do not monetize or commercialize their estates, and also not be a private region (family/personal residence). They must have a focus on a community/project. This would be a great incentive to bring back exploration sims, more roleplay regions, combat/game sims, as the price of these regions is large and entirely unforgiving towards people's passions. Especially with how the economy is right now. To apply to this, the project would need to be pitched to a team to ensure the project does not encroach upon IP and would meet the standards needed for the discount to be approved. I have seen many sims vanish due to a lack of sufficient funding, and this would help in the long run of things. There would likely need to be rules on store vendors, rentals, and donations, but that is manageable.

PBR has knocked a lot of us out of SL due to unusable frame rates of 4-6fps or worse. The choice to do a cut-over to PBR with no backwards comparability option available for people with older computers was clearly a mistake. If Phillip Linden needed to personally email us all to test the new viewer version it means we lost a lot of Residents. By the way, the new viewer Phillip asked us to try is still giving the unplayable 6fps for me. Secondlife is NOT Fortnite; Our residents are not hardcore Gamers with the latest hardware. Secondlife was the game that until recently was still playable on 20 year old graphics hardware, which helps greatly with player retention. Lets not lose that inclusiveness! The SL Viewer has always been able to turn off features that are overly taxing for people's computers and should retain that functionality going forward, even if it means we need to include two graphics engines for a few years while people upgrade.

Motivation: Second life is full of information and very often you have to display some information dynamically: Radars, navigation signs, fancy menus, information boards, HUD applications. And that is a rough listing. For doing this we have prepared textures, MoaP, hover text. Textures can use a wast number of faces if you want to display an arbitrary text. MoaP is doable but has problems with transparency. And security concerns. Hover text works well but it can not be limited to a certain area. Like not at all. SVG Canvas tries to counter these issues and to give a way to create simple graphical information dynamically (but it will be much richer then a simple hover text). Basic idea A SVG canvas is a container for a SVG image and provider of its content: The container is created by a script, it has an own UUID which can be applied to any prim face like a regular texture. To display this image the viewer receives the SVG content from this container. The SVG canvas is stored within the heap memory of the script created it (parent script). As long the script is available, the region can provide the SVG content to the interested viewer. Thus, the SVG canvas is best used on HUDs and in-world objects also running the parent script. The canvas is created via the call key llSVGCanvas(list options); The options list defines the <?xml> header (the only way to set the <?xml> attributes). The result key is used in the following commands and is also applied to prim faces. To check the current status of the canvas we use the function integer llSVGStatus(key canvas); The function checks if the key is a SVG canvas, if it was created by the same script, if it is stil valid etc. Result is 0 or error code. Since SVG is a XML dialect, to build/draw the SVG image we use DOM commands, but a non-OOP way. The commands can only be called within the parent script (for now). integer llSVGGetElementByID(key canvas, string id); This command finds the element having the given "id" attribute and returns its number. Each SVG element is addressed by a distinct number maintained internally, which can but must not be saved in the "id" attribute explicitly. For example we can use the order in which the elements were added while the top-level <svg> node has the element number 0. integer llSVGSetAttributes(key canvas, integer element, list attribs); integer llSVGUpdateAttributes(key canvas, integer element, list attribs); list llSVGGetAttributes(key canvas, integer element); The commands set or read attributes of the SVG element given by the number. The attributes are given by name and value (alternating). The .Set. command replaces the element attributes, the .Update. command only changes values of named attributes. Both return a negative value on error and the (same) element number on success. integer llSVGSetXML(key canvas, integer element, string xml); string llSVGGetXML(key canvas, integer element); This command sets and retrieves the XML content of the given element. This is used to change the text of the <text> element but also allows to draw the <svg> image at once when desired this way. integer llSVGAddElement(key canvas, integer parent, integer sibling, string tag, list attribs, string XML); This call creates a new SVG element with given tag, attributes, and content and places it is as child element of the given parent element after the element given by sibling when it is an element of the parent element. Otherwise the new element is placed after all child elements of the parent. The result is the number of the new element or negative on error. This operation may change numbers of some elements. The top-level <svg> node exists by default and must not be created. integer llSVGRemoveElment(key canvas, integer element); This operation removes the SVG element having the given number. The top-level <svg> node can not be removed. Extensions Besides the simple elements (path, text etc.) we can also have commands for drawing of UI elements. The commands will provide only logical definition while the viewer will render the elements with respect of the current skin. This will allow to create apps with a look and feel of viewer floaters while they will operate on scripts running on the region. Since some of these elements must be clickable, the elements can be added proprietary attributes working like interaction listens and eg. on touch triggering the event on_svg_event(key object, key canvas, integer element, integer action) Within this event one could call then llDetected... functions for further information. Instead of creating the feature for SVG only we can first create the framework for building and updating a XML documents and use this to define SVG images among other uses. Example follows in a comment.

In the interest of positive change and discouraging misuse and abuse of the Second Life platform, I want to propose the following changes to Second Life's policy on scripted agents. Scripted agents must be linked to a botmaster "main" account, this would work like a partnership request such that the scripted agent account dashboard would let you pick the botmaster account, and that association must be accepted by way of an email confirmation or dashboard interaction on the human operated account. Botmaster accounts may have multiple scripted agents associated, and they can view this list on their account dashboard at any time. Failure to have a linked botmaster prevents the scripted agent from logging in. To be eligible to be a botmaster, a human operated account must complete a short terms of service quiz similar to the mesh IP upload exam. Payment information must be on file for an account before it can be botmaster for a scripted agent account. Profiles of scripted agents contain the "scripted agent" account type rather than "resident", and have a clickable SLURL to the profile of their linked botmaster that any observer of the profile can view and navigate through. Before completion of the scripted agent setup process, a text field must be populated with the justification and/or purpose of the scripted agent, e.g. "Region moderation", or "Group chat monitoring". These changes would ensure several things, most notably instilling a sense of accountability and transparency around the concept of scripted agents. Benefits of these changes would include but aren't limited to: Residents encountering a scripted agent may without any difficulty identify the resident who is responsible for the scripted agent, and contact them if necessary which may due to a malfunction, or misunderstanding of the scripted agent's purpose. Scripted agents would become detectable by the viewer, so that they can be identified differently and with notice banners on profiles, agent interactions, and messages. The provided justification and/or purpose for the scripted agent can be included on messaging in the viewer which reduces overall confusion.

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.

I would like to see optional additional windlight orbiting bodies in addition to the Moon and Sun. I was floating the idea around of using the moon texture and replacing it with asteroids or some other fictional planet. It would be really cool to add more bodies with a custom texture, Azimuth, Elevation, and Brightness

I think there needs to be more value added to the regular Premium. With the recent addition of 2K uploads I think this subscription tier needs to be reevaluated to include a tiered fee system for uploads. If Premium plus has most uploads for free why can't the middle tier have a reduction in upload fees as well. Free Accounts/Plus Accounts: --- 10L$ - Up to 1K Uploads plus sounds/animations --- 50L$ - 2K Uploads Premium --- 5L$ - Up to 1K Uploads plus sounds/animations --- 25L$ - 2K Uploads Premium Plus: --- 0L$ - Up to 1K Uploads plus sounds/animations --- 10L$ - 2K Uploads Giving Premium 1/2 price uploads vs. what Free/Plus is paying would give Premium more value and would be a great incentive to join for mid-level creators that can not afford a Premium Plus plan. The above is just a suggestion from semi current standards of upload fees. I strongly feel that Premium needs more value since the Plus tier basically have about all the features Premium used to have back in the day. So Premium got zero bonuses other than extra land when changes were made to add Plus. With SLs Bday coming it would be nice to see a nice present for those of us that have a premium account. I currently have a Premium and a Premium Plus account.

Currently, a private region allows 20,000 land impact, and you can pay x amount of money a month to get 10,000 more land impact, which is great. However, I know that some large busy sims that are at 29k and in a constant state of prim crisis. In these sims, we're stifled when it comes to not being able to do temporary event builds and other innovation. I stopped by the official Welcome Hub and noticed that it's got 45k land impact used and a 58k total land impact. What this says is that it's possible to go higher. So I'm suggesting allowing users who have already upgraded to 30k and are actually using at least 25k of it be able to purchase an additional 10k. By making it this way, people will still want to be efficient because money is money, but, give them the ability to get some breathing room if they feel they need it enough to spend the extra money.

We know that official RLVa support is "on the roadmap" but also not coming any time soon. I'd like to propose something that could be done immediately that would add a small measure of "official RLV support" that would extend the functionality without interfering with any existing stuff, leaving plenty of space for "the rest" at a future time. Simply, the viewer could hold an official new data field, the "RLVa version" (or whatevs we want to name it), and a new scripting command llGetRLV() would cause the simulator to ping the viewer of the object's owner and get the string. It's that simple. What this gains for us: Trivially, the Second Life Viewer can set this to "" for now, since there's no RLV(a) support. Other viewers could set this string to the appropriate version. Future scripts could find out RLV enabled status just by checking this string, with no need for the message protocol. Nothing existing today breaks/changes in any way, but suddenly all future scripts could use this instead of current methods, which tend to spam the chatboxes of anyone without RLV enabled. The back-and-forth script dance of version checking is such that currently, many makers of RLV items simply assume that if you've worn an RLV-possible item, you knew to have RLV on. This single official step would help RLV scripters get their stuff working, and help RLV abstainers be spammed less in the future!