✨ Feature Requests

The feature to have baggy pants and shirts on default LL bodies has been removed, and there is no way to enable it. Why? It used to be in the graphics settings as 'Avatar cloth' with a checkbox next to it. It's gone now. In the debug menu (RenderAvatarCloth), it cannot even be re-enabled, and says 'DEPRECATED'. I would like to see it again. For people who still enjoy using the old-school LL body, having cuffs on your pants or being able to make your shirt baggy brought unique character to your avatar. I can completely understand that the default LL body is old and outdated, and that many people don't use it anymore, but please don't remove that joy for the few that are left. I simply just can't understand why it was removed in the first place. The avatar wavy cloth function wasn't hurting anything, or anyone. EDIT: To add onto this, YES you can still use the sliders, but other users will not be able to see the effect on your avatar. Tested this by having a friend look at my avatar while I was using using "pants cuffs" sliders. He couldn't see them. The friend logged into default viewer and got the same result. This was an intentional removal.

Improve the 'show only friends' feature and allow us to see everyone or only friends without having to teleport to see everyone again (previously this was done by changing groups, but it no longer works)

Due to bodies and heads now being split into separate items by different creators across Second Life, newer Residents are finding things more of a challenge when it comes to their base needs, such as skins and shapes. More documentation needs to be provided when it comes to the Welcome Pack and the Senra and library assets to communicate that there are different UVs being used. We are seeing a lot of new users with the wrong skins on mesh or having difficulties with shapes and content also sold on marketplace that is much older and will not work with any of the library/welcome pack assets. This can lead to frustration as well as wasted purchases because the items do not work with what they need them to work with. More documentation as well as perhaps information on how to join the groups/support of those items directly could help new users, and by having assistance from the stores involved, could lead to loyalty and the desire to stay in world. This was discussed at the latest CCUG meeting

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.

I'd like to request a special type of BOM layer which in itself is a container, a set, of BOM layers laid out in a specific order for easy and reliable inclusion in outfits. Of course the ordering is still subject to the layer ordering rules, such as a skin layer being forced to the bottom. When editing this layer, you drag and drop the layers, and then reorder them as needed. When done, you can wear and unwear the set like any other layer, the order of the layers included in the set is kept relative to each other within the set, layers not part of the set can fall in between them when worn, due to the ordering rules. This is perhaps a variant of the idea laid out in https://feedback.secondlife.com/feature-requests/p/ability-to-combine-group-bom-layers

I like to have the privacy of keeping me age confidential. Just like in RL. Age should not matter. I think I speak for many.

38 attachments is not enough these days! I am constantly having to remove this to add that. Avatars are more evolved nowadays than they were in 2008. We wear multiple HUDs, mesh bodies' heads, ears, teeth, eyes, accessories, spankers, AOs, Dance HUDs, naughty bits.. the list goes on. Why limit us to just 38 attachments when we are not limited to how many system layers we can wear?

When your viewer crashes (which seems very common these days especially when teleporting) all attachments revert back to a state when attached or logged in (if attached when logged out). This is a pain for upgrades etc as you may have paid for them & the upgrade is lost. An Avatar menu item to checkpoint attachments (i.e. saving script states, attachment positional information etc) would be most useful saving the need to log out & back in. What would, for me (scripter), be even more useful is to allow this through a LSL function (with the obvious ownership checks etc). So an upgrader which the customer has rezzed checkpoints having upgraded the scripts etc.

I am been wishing SL support this feature loong time ago. "Support custom bone setup" like VRchat does. After that, Support physic bone feature would be lovely too. Performance issue can be handle by optimizing mesh. 2024 now and I really wish SL support this feature :( Dev show they can implant PBR shading system in SL. I think you guys can implant this feature in SL as well.

Make it possible to click an avatar/animesh, select "Sit on ..." and get a list of skeleton targets that the avatar/animesh has enabled to be sat on. This would make the sitting avatar follow the skeleton as if they were an attachment. Needs permissions handling for avatars. The avatar/animesh can define a (limited?) number of skeleton targets like "Head", "Spine", etc. by script with an offset and rotation for each.