✨ Feature Requests

Currently, we can attach a maximum of 38 attachments, but since objects attached to the "HUD" position are also counted in the total, it's sometimes impossible to wear more. This phenomenon is particularly noticeable for furry users. After equipping the necessary furry parts, there are often only 5-6 attachment slots left, along with some commonly used HUD adjustments for body or other parts, leaving almost only 1-2 slots, or even none, for clothing. I hope there can be a separate limit on the number of objects attached to the HUD position, independent of the attachment count.

I would like to get more avatar followers for Premium and Premium Plus members. That would be really an advantage, because I always packed my avatar full of stuff!

So., many years ago when I played Runescape (long long time ago) at some point there were many people abusing the game, or griefing people like I often encounter in Second Life as well. Both in random places, as well as new residents landing spots and the firestorm help sims. At a certain point they introduced Player Mods, in order to assist the Jagex employees to act faster on this kind of behavior, those player mods had limited powers compared to the company employees, but could still do some direct action to solve issues with griefers. I imagine that perhaps this would be interesting for SL as well, as I come past griefers almost daily at random places, and it seems to take a long time for LindenLabs to track/react to all abuse reports submitted by dozen of people, sometimes 40 times about the same griefer. A Player Moderator (PM) would be able to handle this faster, and with a PM abuse status / temp. ban it would be easier for LindenLabs to deal with this kind of behavior faster? (not sure what category this goes too... so I picked avatars)

How about this: on the page to offer partnership to someone ( https://secondlife.com/my/partners.php ) let's add an option to offer to share your last name with your partner. If your partner accepts the proposal, their last name will be replaced with the last name of the offering partner. The partner having their last name replaced will keep this new last name as long as they remain partnered and will have their last name fall back to their previous last name if and when unpartnered. Using this option will add extra cost to the partner offer, about the same as what is paid to change last our own last name. Will be paid by the offering partner. At any time, any partner can decide to break the partnership. The one who does the break will have to pay as much for having their previous last name back or they can select an cheaper option to break the partnership and revert back to a regular Resident last name.

As an applier creator for body materials and tattoos for mesh bodies using the SLUV - it is tiring and quite redundant to program applier scripts for each body (and heads) that I would like to support. It would be an infinately more efficient system overall for all bodies if they could simply utilize a specified UUID channel that grabs those textures from a BOM wearable to get directly applied as materials on the rigged mesh wearable. Something like additional AUX layers that had multiple channels for normal and specular (or even PBR materials) for head/body UV in them. Almost all mesh body wearers have updated to BOM skin for bodies and heads, and often struggle with adding and removing materials in HUD based systems. Implimenting a system like this would make changing materials on bodies easier for base line consumers who are about to experience materials for the first time when all viewers have updated to PBR. Along with this request, I need to stress the importance of 2K bakedown service for these materials to be worth making a BOM asset. The payoff being - bodies would not need to add another stack of scripts to compensate for PBR materials on their mesh bodies and heads, which consumers are already wanting. Addressing 2K BOM requests with the ability for materials to also be BOM would greatly combat an increase in constantly running scripts in bodies and heads, and would make the entire community much happier for it!

Second Life as a platform is unique in that it is user driven and user built. There should be no doubt that when approaching an avatar that it's directly controlled by a human. While it is undeniable that scripted agents provide utility and amusement, they should not exist in any form that allows them to be confused with a human controlled avatar. Ideally there should be no task in SL that needs fully fledged antonymous scripted agent to accomplish and LSL needs to be expanded to remove these edge use cases. Survey and traffic bots are an annoyance, likely privacy breaching and often operating in ways that break ToS. Self identification of accounts as bots has broadly been a failure and cop-out on the part of Linden Lab. LL need to be marking bots as bots automatically. It doesn't even need fancy AI to accomplish. Metrics such as teleports per hour, time spent in the same location, viewer channel, etc etc etc. Confusion over what is behind an avatar has created a trope in SL that unresponsive avatars are in fact bots, that clubs and venues aren't occupied by individuals, the direct implication being that SL isn't a real place made and populated by real people. No one wants to waste time trying to be be social with a bot. AI chat bots are novelty and not a substitute for real people. At the very least name tags should be flagged in some way that makes it obvious an agent is scripted in some way. Participation in local chat should be equally differentiated. profiles should be limited, etc etc.

(Full disclosure, first feature request I have done) Facelights and other worn lights are a contentious topic, loved by some, hated by others. We do have the ability to not render worn lights, this solves the problem for you, but not for others, especially photographers trying to capture a scene, or venue hosts who want their guests to experience the atmosphere as intended. There are places where builders have taken great care to ensure a lovely ambiance, until somebody waltzes in with what often can be pretty obnoxiously bright worn lights. And I guess extra light sources could make slower machines work even harder rendering what's on the screen, which might explain why some people complain about FPS drops at crowded events. Today this issue has to be handled through either asking them to manually check each of their attachments for something with 'light' in the name, or looking for them visually. Getting people to abide by rules set for a venue has a tendency to often end up in displeasure for the "offenders" and arguing, while with a scripted function, there's nobody to argue with. It's just automated venue management that could maintain carefully crafted atmospheres without confrontation. This could even help avatars who forgot they left their facelight on, with venues giving them a gentle automated reminder rather than public callouts in chat. I'm no coder, so exactly how is way beyond me, but could it be possible to make llGetAgentInfo() provide this info? sort of like it does today for scripts and attachments? This is stuff that's already implemented and accepted by the users, so I guess it shouldn't be problematic "politically"? All one would really need is to be able to know if an attachment is a light source and get the name in return, if one would want to be fancy with it, one could also get info such as the intensity and/or radius of the light source as well, to accomodate an acceptable level of personal lights. I have no idea how this would be done without breaking existing stuff, I am just putting the idea out there as something that could make SL a better place 😊

I suggest an enhancement to the Bakes on Mesh (BOM) system by introducing an opacity option for BOM layers. As a designer, the current limitations of BOM force us to add additional mesh layers, particularly for makeup applications. This increases mesh complexity and necessitates the use of complex HUDs. Enabling opacity control on BOM layers could eliminate the need for extra mesh layers, thus optimizing mesh complexity and enhancing overall performance. Additionally, this would allow for greater flexibility and creativity, as BOM makeup layers wouldn’t be limited to one or two mesh layers (depending on the number of mesh layers created by a designer). With the recent introduction of 2k BOM textures, the capability to adjust blend modes directly on BOM layers would be highly beneficial for both designers and users. It would offer more customization options and improve the user experience. It would positively impact the creative community and contribute to a more streamlined and efficient design process.

Currently, we are allowed to have 38 attachments total, this includes HUDs and mesh/prim objects. To some degree, we can link objects together, especially rigged objects, to help manage it. However, sometimes we're stuck using objects that are no mod, meaning we cannot link them together to better manage our attachment points. For example: Lelutka heads often come with several items that we wear, such as the head, teeth, beard, ears, the lel hud or point hud for animations. These can wind up taking away a chunk of items. Now consider that some of us may also be using some gachas, and some clothing creators just still choose to no mod for whatever reason. We wind up with a large amount of objects we're wearing that can't be linked or managed. By making it a 3:1 ratio you're throwing people a bone without encouraging people to make or intentionally seek out more no-copy things, but allows us to suffer a little less with the incidental no copy objects we already have.