✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
Urgent Issue with Gacha Exploit – No Copy Item Duplication via Sim Crash
To Linden Lab, With the reintroduction of Gachas to Second Life, I am concerned about an unresolved and critical exploit that has long impacted artists work and livelihoods. The Bug: No Copy Gacha Duplication via Sim Crash A longstanding exploit allows users to duplicate No Copy Gacha items by: Rezzing a No Copy Gacha item in-world Picking the item back up Forcing a sim crash Upon region restart, the item can appear both in the user’s inventory and rezzed inworld effectively duplicating it. This method enables malicious users to mass copy limited items and resell them on the Marketplace at the expense of the original creator. These listings often do not show the “(Limited Quantities Available)” tag, indicating they were not legitimately obtained through the original Gacha machines. __ Impact on Creators: As a creator, it was devastating to spend weeks or months designing an entire Gacha set for events like The Arcade or Epiphany, only to see duplicated copies flood the Marketplace mere hours after the event opens. Worse still: Linden Lab's support response times (especially on weekends) have historically been too slow to address DMCA claims before significant financial damage is done. Exploiters often profit thousands of Linden Dollars before listings are even reviewed. __ Documented History & Community Efforts This issue has been widely reported over the years via: Jira reports Blogs A dedicated Discord server ("Creators Against Theft") where we actively supported each other in identifying and reporting exploiters. For reference, this 2017 blog post documents the exploit and includes a quote from Simon Linden stating: “We haven't solved all the problems outright, but we're making good strides.” https://nwn.blogs.com/nwn/2017/10/linden-lab-second-life-duplication-bug-sl.html __ Thank you for taking the time to review this request. We all want Second Life to thrive but artist must be protected if that’s to happen. Sincerely, A Concerned Creator
23
·

tracked

PBR Re-Education
Linden Labs, Users do not understand PBR technology and they see it as a negative based on the implementation that has transpired over the last year. PBR doesn't work for users on lower-end computers. Color mapping has changed and many do not understand this or even know that it has happened. It is important that you, Linden Labs, do your due diligence to make sure users are educated and understand PBR so that creators are actually able to make the transition to PBR without angering a portion of our user base. We hear things like, "Even on PBR viewers, I don't like how colors look." "I don't like PBR so I won't by any PBR items." "PBR should never be used on clothing." "PBR is just to make things shiny." My suggestion to combat this is for Linden Labs to produce a series of short, easily digestible to the public, tips or videos on PBR & ACEs color mapping. This will not only help users understand the reasons for the change and the purpose but why PBR is a good technology. Even asking users for tips to submit and have a place where people can view these tips to try to be able to use PBR. To be fair, I think this should start with a heartfelt apology to the community for the poor implementation of PBR and lack of education on your part. I think you'd be surprised to see how many still are not on the PBR hype train. There are many creators who have not done a single PBR release. They are still hanging on to Blinn-Phong. I suspect they worry about sales, knowledge on how to transition from BP to PBR, etc. These are all things that could be helped or solved with Linden Labs actually explaining what happened and how they are working to fix it and education on PBR and how it will help lift Second Life into the next decade.
33
Animation Sequencing Timing Discrepancy - Request for Clarification and Support
Please note: I'm not asking for anything to be changed, quite the opposite. I'm just looking for information on how sequencing timing actually works, so I can work with it more precisely. SL has had a long-standing issue with animation sequencing. It’s been consistent over the years (I’ve been animating in SL since 2010 and aware of the problem since 2012) and shows up across all major animation systems used so far. (MLP, Perfect System, AvSitter). Types of animation sequences: In SL, animation sequences are used in two ways: Standalone animations arranged into a scene ('quasi' sequences) True sequences, where one long animation is split into smaller, timed parts. I'm specifically talking about the second type, the true sequences. Problem: Individually, the animations play for their intended duration, but when scripted into a sequence, there's a consistent mismatch in timing. • Animations are played for slightly less time than their actual length. • For example, an animation that is exactly 46 seconds long in playback wait time must be set to 44.5 seconds in the sequence to function correctly. • Only animations that are exactly 60 seconds in length appear unaffected. • It’s like sequencing scripts are using their own internal timing system. What It Is Not: Through extensive testing, I have ruled out several common variables: • The issue is not caused by the animation format (both .bvh and .anim are affected). • It is not related to framerate. I’ve tested it with random FPS between 10–30, but the problem exists regardless of FPS. • It does not depend on whether the animation is looped or non-looped. • The presence or absence of easing in/out settings does not affect it. • This issue isn’t limited to just one animation system. It has appeared in all systems that use animation sequencing: MLP and Perfect Sitter in the past, as well as AvSitter today. • Also, this behavior is consistent throughout different viewers. The Challenge: Because there is no documented formula for adjusting timing, animators are left to rely on trial and error to determine the correct values when sequencing animations. This becomes an enormous time sink, especially when working with complex animations. I tried calculating the needed adjustment as a percentage of the original animation length, but it didn’t hold up. It seems to follow some kind of logic that’s beyond my grasp. What I’m asking for: I’m not asking for any changes to how sequencing currently works on the grid or in the viewer; changing that would break existing content, and that’s not the goal. What I’d really appreciate is just some clarity - either: A clear explanation of why animation timing gets distorted during sequencing. A method - or even just a formula - animators can use to accurately adjust/recalculate animation lengths when sequencing. If that’s not possible, then some kind of tool or viewer feature that shows the “sequencing-effective” length of an animation would be a huge help. Just having access to this information would save hours of trial and error and make it much easier to create polished, smooth sequences. Why this is important With relatively little effort on your side, this could unlock new potential for immersive experiences across Second Life. Tool for fixing the timing issue could actually open up a whole new creative space. Properly timed animation sequences allow for smooth coordination with props, scene changes, and multi-character interactions. It would make advanced visual storytelling more accessible to animators and designers, and that would seriously enrich what's possible for interactive and immersive content in SL. I believe this is an opportunity for improvement that can happen relatively fast if LL provides information. Please, let's not miss it.
6
·

tracked

Load More