✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
Allow Harassment Reports to be submitted via Support Tickets
Currently, Abuse Reports for harassment in Second Life can only be submitted inworld, where the interface allows little more than a short paragraph and offers no practical way to attach supporting evidence. Reports can also be initiated through the Boxy chatbot, but that method is similarly limited and does not allow residents to fully document coordinated harassment. This makes it difficult to report situations that might also originate off-platform but result in a great degree of inworld disruption. Additionally, Linden Lab’s Support Ticket system only allows Abuse Appeal submissions, which occur after enforcement actions may already have been taken, leaving residents with no prior way to submit detailed context or evidence explaining the initial abuse. Allowing harassment reports to be submitted via Support Tickets with adequate space and evidence attachments would benefit residents by enabling clearer, better-documented reports, while also supporting Linden Lab’s ability to review reports submitted by residents concerning harassment directed at Linden Lab staff. This would help Governance more efficiently investigate coordinated or bad-faith harassment campaigns affecting residents, staff, and the broader Second Life community, improving accuracy, fairness, and community safety. If there are other methods to submit a detailed harassment report to Linden Lab with supporting evidence that will be investigated, then please include those methods in a reply or comments. Thank you for considering an improved reporting process that enables more thorough review of harassment.
12
Request: Script crash logging
basically a webhook for script errors -- Nexii Malthus, summarizing what we need You develop scripts for Secondlife. You start hearing people reporting that your scripts are crashing. Now what? Unless it's a very reliable crash, you're kind of in unexplored territory. SL is vast, many unique and hard-to-reproduce situations could be happening. The crash log is seen by your end user, not by you. The developer cannot know how widespread the problem is, whether it's a bug in a SL Server update, whether it's an edge case in their own programming... Possibly avenue to a solution: An unmodified, compiled script has consistent bytecode, and if I understand it right, an internal asset id corresponding. The simulator knows when this item has crashed (and currently only generates a message to the owner on a message channel). Perhaps a developer could "flag" scripts for logging "that script", or the set of scripts for a project that is in the wild and reporting problems. The developer could view (on the web? in the viewer?) a simple log, aggregating the crash reports from the currently-logged scripts, grid-wide for each flagged script. Perhaps some bit of information like the simulator version/memory use/event queue at time of crash. The simulator knows all sorts of things about what happened; Any log improves the current total black-box situation. Eg, "hearing that scripts are crashing on region restart? start logging now and see what comes in". This would be a limited utility. The number of scripts we can flag and limit how many log entries each script holds would be small. This would not be a performance monitoring tool; it would be turned on when a problem is suspected, to capture what's happening "out there." Acknowledged implications: Plenty of privacy concerns abound. To avoid adding new means of tracking users, gaining access to personalized data etc: The developer should not be able to find out what specific region the script was in when it crashed The developer should not be able to view the script's memory The developer should not be able to view who was running the script Might be useful: What type of crash list of events queued simulator version number region status Anything else that could be useful without opening bad implications? Any other implications that need calling out?
1
·
Performance
Load More