✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
llAvatarOnSitTarget reports incorrect agent on sit target after disconnect
This is a super old bug that I want to bring back to light, I could not find a canny on this. This bug alone, is responsible for several vehicle woes, often requiring vehicles to be re-rezzed. Old archived posts referencing this issue: https://forums-archive.secondlife.com/54/11/317331/1.html https://github.com/secondlife/jira-archive/issues/8363 Summary: In short, when an agent crashes and disconnects uncleanly, the sit target remains occupied. Other viewers will still show the (now gone) avatar on the seat, scripts who call llAvatarOnSitTarget or related functions will be told that the sit target is occupied by the avatar who got disconnected. What makes this particularly evil for scripts? This stale state survives script resets, since it's a simulator state issue. The stale sit target survives sim crossings Even worse, you can unlink and relink the link with the sit target, and the simulator will still report that the disconnected avatar is sitting on that sit target once you relink. If the disconnected avatar relogs to a different region, and teleports back to the region the vehicle is in, when they resit, the avatar will now occupy two sit targets. Side note: If a linden wants help reproducing this bug, I'm happy to help. It can be reproduced easily if we stress test and try to crash on purpose; by having a multi-avatar vehicle with several avatars running several scripts.. we can make ourselves crash onto sim corners.
10
·
tracked
Add a rule against signing up users to "subscription" marketing messages without their consent.
Like many other users, I periodically get spam notecards and IMs from SL business owners advertising their new products. I have NEVER signed up to any notecard mailing list, I have always been added automatically without my knowledge. There's already a feedback post here about the ability to block these objects: https://feedback.secondlife.com/feature-requests/p/blocking-an-avatar-should-also-block-blacklist-all-of-their-rezzed-objects however I think that is only a band-aid solution. Signing users up onto your "subscription" service without their consent should not be allowed in the first place. It falls under spam, yet every time I have submitted a report against these objects, & explained in the report that they are spamming me (and others) without my consent and sometimes without a way to opt out, nothing seems to come of it. So I can only assume that, currently, this isn't against the SL TOS, or for some reason the reports are falling on deaf ears. Every time this has happened to me, the ads I get are from a brand that I don't recognize. This is because every time this happens it's nearly always happens one of two ways: I was added to the mailing list because I bought ONE item from the store in question; often a long time ago, sometimes years or more, from the Marketplace. This implies that the store owner is manually adding all Marketplace customer usernames to a mailing list or automating the process somehow. I visited the sim one time, and my mere presence was enough to get me on their mailing list. I need to stress that not only do these users add you to lists extremely easily, but they often make unsubscribing very difficult. At best, it'll be through a system like "KioskNet" - which at least has an inworld location you can go and get a HUD from, and unsubscribe from any mailing lists using that system. But if they use their own system, you're often out of luck. Some tell you "unsubscribe in the mainstore" but when you go there, there's no unsubscribe button, no matter how you look. Others say "contact me to unsubscribe", meaning that you have to actually talk to the person to convince them to take you off. And even if you find a way to unsubscribe, some will automatically put you back on their list later! I periodically check the KioskNet thing because every 6 months or so, a store has added me back as a "subscriber." As the other thread on this issue says, though, blocking either the user or their mailing object usually doesn't work because they tend to rezz multiple copies of the object, and keep going. Once you're in their system, you will be contacted by any object they rez going forward. I ask that Linden Labs considering making these unprompted spam subscriptions disallowed on the platform, and actually punishable. You should ONLY be able to get a "subscription" by opting in. Intrusive ads we did not ask for are spammy, disruptive, and extremely annoying.
16
·
tracked
Prevent Banned Avatars from Using llDamage on Restricted Parcels
Avatars should not be able to use llDamage against agents or objects on parcels where they are banned or otherwise do not have access. This should also extend to objects that have been deeded to a group by said avatar. Currently, if a parcel has damage enabled, a banned avatar can still use llDamage to affect targets within that parcel. This effectively allows them to bypass parcel bans and continue interacting with residents or objects despite being explicitly denied access by the land owner. This behavior undermines the purpose of parcel access controls. If a land owner bans an avatar, that decision should prevent all forms of hostile or disruptive interaction originating from that avatar, including scripted damage. Parcel owners rely on access controls such as bans and group restrictions to manage their land and protect the experience of people within it. Allowing banned avatars to continue affecting the parcel through llDamage removes control from the land owner and weakens their ability to enforce boundaries. By permitting damage interactions across parcel bans, the platform effectively overrides the land owner’s explicit decision about who is allowed to interact with their space. Preventing llDamage from working across parcel bans would restore the intended autonomy of land owners to control interactions within the environments they manage. A secondary request would be adding a flag to the region settings that can be set TRUE or FALSE to allow damage to be dealt from sources to targets on different parcels as a region wide setting and default it to FALSE
20
·
Permissions
·
tracked
Load More