Feature Requests

Premium badges show on profiles and some don't want people knowing they pay for that. Not everyone wants people to know they are praying for an account. Some in SL don't want people to know they have a home. Some don't want other rl members to see they actually paid for a virtual account. There are many reasons. It should be a choice of whether you want to show that. I know I will not pay for that to be displayed.

In preferences we have the ability to unchecked a box to prevent accidentally TPing to an Adult region. The current options are G, GM, and GMA, but there is no option for either M or MA without G. It would be nice to have the option to block G regions if one is only in SL for adult activities and dresses that way. A warning pop-up letting a person know that the region they will be landing in is not in their safe region rating and asking if they want to TP anyway or cancel the TP would also work. Give us the option to prevent an accidental TP if we have inappropriate clothing on for the land rating. Gotta keep Grandma happy!

There is a vast amount of content available where the object itself is modifiable, but the scripts or other content it contains are no mod. It is possible to rename such objects or change their description by rezzing them in world, renaming and then taking back into inventory. It is not possible however to rename the same objects directly in inventory, or when attached. This limitation makes the process of renaming modify objects unnecessarily difficult.

Do we really need to ask for permission to teleport when the script is being worn from inventory by the resident? I have customers complaining that it is annoying having to answer this popup permission request, but the only way to bypass this behavior is to have a dedicated script hold that permission that is never reset; which would wastes region resources. According to the wiki Temp attachments are not permitted to teleport people which was the only real avenue for abuse back in the day, so I don't see a need to be granting this permission explicitly anymore. I think it is time for it to become like the other permissions that are auto-granted when an object is attached from a resident's inventory.

Aviation in Second Life can be a deeply frustrating experience. While ban lines aren't a problem except at low altitude, as during takeoff or landing, security orbs can affect you at all altitudes. If you trigger an orb with a short fuse or a longer timeout on a large parcel that takes longer than its timeout to cross, you're removed from your vehicle and sent elsewhere - but your vehicle isn't, so it merrily flies along until it goes offworld or finds a no-object-entry parcel or crashes. There's no way to know this will be a problem before you get to the parcel. I would like to see a change, either in scripting of llEjectFromLand() and llTeleportAgentHome() or else in mainland policy, to restrict a security orb's ability to separate you from your vehicle or to limit the altitudes over which it is effective to some vertical distance from the orb. I have no desire to invade anyone's privacy; I just want to go flying without getting ejected from my airplane without any way to avoid it.

If the online status is set to "hidden", it should not be able for scripts (i.e. "Online monitors") to reveal the avatar. An exception could be made if the scripted item and the avatar are in the same parcel (for shopping reasons etc.).

When setting an in-world object to sale, add a section/marker to only allow a specific avatar or member of a specific group to buy the object.

I get the need to turn off "Allow Rez" for the mainland public areas. To prevent griefing and such. But it would be safe to say that if you're a premium member, you would be less likely to commit a grievance since you're paying for your account and getting banned from it is an incentive for good behaviour. As such, allowing premium members to rez on "Public Linden Areas" (with an auto return 5mins) would make life easier for those of us who enjoy traveling on the roads or seas with vehicles. Especially if we hit one of those dreaded banlines/zero second security orbs returning our vehicles and forcing us to spend the next few minutes trying to find a tiny square to rez a new vehicle.

Aviation in Second life can be a deeply frustrating experience. The other big issue besides unlimited-height security orbs is no object entry parcels. Unlike ban lines, no object entry applies to the parcel at all altitudes. If you encounter a no-object-entry parcel, your vehicle stops immediately, and its physics are altered to remove any motion or forces applied to it. The practical effect of this is that an airplane stops in midair, and there's no way to get it flying again: even editing it so that it would move away from the no-entry parcel just makes it hang in midair, so you wind up having to unsit and delete it. As with security orbs, there's no way to know in advance that you're about to have this problem. I would like to see the no object entry attribute limited to the same effective height as ban lines. Ban lines can be seen in advance and avoided at altitudes where they are effective (especially with some third party viewers that show nearby banned parcels on the minimap). If I'm flying above the ban line height limit, this would no longer be an issue with that change in place.

Please make animations usable with their UUID like many other asset types already are. Currently animations are a lone wolf in that they cannot be referenced by UUID when they intuitively should be. Currently with scripts: Textures able to be displayed with their UUID Sounds can be played with their UUID Notecards can be read with their UUID Materials, a brand new asset type, is able to be displayed with UUID Animations: 🙃 llGetInventoryKey and llGetPrimitiveParams/etc already implement protection against obtaining UUIDs without the proper asset permissions. I do not think that an arcane limitation like "no animations by UUID" is appropriate especially with the upcoming improvements to animated mesh with the GLTF project, and to server-side scripting with the Lua VM project.