✨ Feature Requests

Overview - This proposal suggests implementing a modernized modular audio framework for Second Life, focused on: vehicles, ambient environments, weapons systems, and immersive scripted experiences. The current audio system is heavily limited by static forward-only playback and minimal runtime control. Expanding the sound engine with modern playback and modulation features would significantly improve immersion, realism, and creator capability without requiring major infrastructure changes or high performance costs. --- ** Core Features ** Modular Audio Architecture Introduce layered sound modules for objects and vehicles instead of relying solely on static looping audio files. Suggested capabilities: * Multi-layered audio playback * Independent sound channels * Runtime pitch, gain, and tone modulation * Script-controlled blending and transitions * Distance-aware attenuation * Dynamic audio state changes via LSL * Synchronization between audio and animations This would improve realism for: * Vehicles * Aircraft * Boats * Weapons systems * Machinery * Environmental ambience * Interactive roleplay and cinematic systems --- Advanced Runtime Playback Control The current sound system only supports basic forward playback. More advanced runtime audio control is necessary for modern simulation systems. Suggested additions: * Pause and resume functionality * Playback speed scaling * Reverse playback support * Arbitrary playback start positions * Runtime seeking within audio clips * Script-controlled loop regions * Loop in/out point definition * Multi-layer synchronization These features would allow creators to build systems previously impossible within the platform. Examples: * Time manipulation effects * Cinematic sequences * Dynamic environmental ambience * Interactive machinery * Realistic weapon cycling * Advanced vehicle sound simulation Currently, visual time manipulation can already be simulated in-world, but audio cannot properly synchronize with those effects due to playback limitations. --- Procedural and Parameterized Sound Modules Instead of relying entirely on pre-rendered loops, creators could optionally use procedural sound modules with script-adjustable parameters such as: * Pitch * Harmonic intensity * RPM scaling * Resonance simulation * Tempo synchronization * Dynamic filtering For vehicles, this would enable: * RPM-responsive engine behavior * Gear transition audio * Turbo and transmission whine simulation * Dynamic exhaust tone changes For environmental systems: * Adaptive ambience * Interior/exterior acoustic transitions * Dynamic reverb behavior * Mechanical and sci-fi audio systems --- Hybrid User Audio Support The system should support creator-uploaded audio combined with procedural layers. Example: * Base procedural engine tone * User-provided turbo samples * Environmental ambience layers * Mechanical sound overlays This preserves creator flexibility while reducing repetitive looping artifacts and excessive storage requirements. Importantly, this proposal does not require changing the current 30-second sound file limitation, as the primary improvements come from dynamic playback and layering rather than longer audio assets. --- Technical Considerations The proposed system would mainly involve lightweight runtime DSP-style processing: * Pitch shifting * Playback speed control * Runtime seeking * Parameter blending * Layered playback These operations are computationally inexpensive on modern hardware and audio systems, while remaining fully compatible with the custom-content synchronization and shared in-world experiences. The proposal also maintains backward compatibility with existing scripted content and current audio infrastructure. --- Benefits A modern audio framework would significantly expand creative possibilities for: * Motorsports * Aviation * Military simulation * Sci-fi environments * Horror-themed experiences * Cinematic storytelling * Immersive roleplay It would also positively impact the creator economy by increasing demand for advanced scripted assets, simulation systems, environmental sound packs, and immersive experiences. --- Conclusion - Adding modular audio systems, advanced runtime playback control, non-linear playback support, and script-driven sound parameterization would modernize Second Life audio framework while remaining technically realistic and performance-friendly. These improvements would greatly increase immersion, creator freedom, and the overall technical capability of the platform.

Block feature shoud go both ways. If, for example I block someone, I see them gray, but they are still able to see me. The purpose of blocking someone is to keep them out of our lives. If they can still see us, then this block is half achieved purpose. It should go both ways. If one block someone then both avatars should be gray. I have a friend that blocked someone and he can still see her and follow her in her usual spots. She sees the view crosses fixed on parts of her body even though he is blocked. This is making her uncomfortable and should not be allowed. Blocked people should not be able to see the person that blocked them. Thank you

This is a request to build a tool for users to transfer items to a known alt account, and automatically set all transferred items with the alt's name as creator. This is something that would benefit anyone who might import or create content, but then sell under a branded account. The account initiating the transfer would need to be any paid level of account as an encouragement to get on the paid ladder, and to make it worth the while to make the tool. It may also benefit people who wish to give out free and full perm content, without risking a fullperm root prim being abused.

Some kind of cloth simulation would be great, I think everyone agrees on that. Except that it's computationally very expensive, and while it's practical in a game where you've only got one main character and care can be taken to avoid much simulation happening at any one time, SL needs to render up to a hundred (sometimes more) "main characters" at a time. There's already a feature request in for some kind of cloth simulation tracked here: https://feedback.secondlife.com/feature-requests/p/weighted-clothing-material-with-collision -- in the thread people have discussed some things like collision volumes to stop the mesh intersecting, which was always a problem with the old flexi solutions too. All these things would be great, but maybe there's a computationally cheap way we can at least get part of the way? People have tried things using spare bento bones and animating, but that doesn't coincide with actual avatar movements, so it's really no more than a gimmick. I admit this is a bit beyond my wheelhouse, but I had a crazy idea, spoke to a few people about it, and they seem to find it intriguing, so I'm bringing it here. I call it "Velocity Bones". Imagine we have an extra (or maybe a few) bone in the skeleton, which mirrors existing bones, but all motion is delayed . When you move your avatar, the velocity bone starts moving a second behind the rest of your avatar, and stops moving a second after it. When you play an animation, the velocity bones will animate as per their mirror bones, but start a second later. This gives a bone that rigged mesh can be weighed to, which will be where you just were a second ago, and catch up with you when you come to rest. For example, imagine a ponytail with the end of the tail weighted to this velocity bone. You move left, the ponytail will trail to the right. You stop, the end of the tail catches up with you. You jump down from something, it bounces upwards. You dance, the end of the tail takes a little time to catch up with the top of the tail, giving a basic simulation of inertia. This doesn't solve collision problems, doesn't allow for things being moved by wind, but otherwise could provide us with something akin to what people used to use flexi for with attachments. We could have a cape flowing behind us, that moves dynamically as we fly. We could have moving hair. Clever people might even be able to put a bit of reasonably convincing movement into a dress with it. Best of all, it should be pretty computationally cheap. As I say it's beyond my technical wheelhouse -- I'm not sure how practical it would be to split-animate a skeleton in this way. However people have been crying out for flexi mesh or something for years, and since the idea occurred to me I thought I'd throw it out there and see if it gets any traction.

Would be great to allow for grouping / categorization of groups - not so much an issue when you have just a handful of groups, but when you have >20 or 30 - categorizing would make it easier to manage them. Could be helpful for CSRs of multiple groups as well. The categories should be user defined and it should be easy to move a group from one category to another. The default option would be that the group isn't categorized.

Hello, I have been making Windlights/EEPs for photography and other purposes for some years now and have recently been looking into creating Day Cycles but one thing that is lacking in EEPs makes creating brighter, more colorful nights in day cycles difficult is the lack of the Glow Focus and Glow Size for the moon. In an EEP this is less of a problem as it is a single time of day where the sun and/or moon are in static positions and you can just position the sun where you want the moon to shine from and add a moon texture to the sun, but with day cycles the sun/moon move around the sky as the time of day changes and if you want them to move about organically you can not use the sun as a substitute or aid to the moon. Having these two sliders for both celestial bodies instead of only one would unlock far more potential for photographers, home owners, vendors and others to experiment with and create more and even better environmental settings.

how about a decent editor in notecarda allowing things like columns and so on. Our notecard are pitiful

Optically you can see from a region to the next one - the sim border is invisible. Physically though the next region does not exist until you travel over the border between the recent region and the next one. Let's suppose you are traveling by boat. If you hit a pier in a region, your boat is bounced back. But if you hit a pier located on the next region reaching until the region's edge, your boat first travels over the sim border and suddenly gets caught in the pier bouncing like crazy. Suggestion: the physics engine of each region should also load (render?) the physical shapes of the neighbor regions borders, which are pointed to the region, so a vehicle is bounced back and does not enter the next region where it is blocked by some object. Advantage: physical experience would be far more natural, collisions on sim borders would not be special. Since it is very common to build right until the sim borders, this is issue not a trifle at all imo. Vessels that have a damage system responsive to collisions (to make sailing more challenging) use to sink immediately when hitting these sim edge builds (since being caught on an object causes plenty of collisions in a very short time), while they would only take some damage while hitting the same build from the other side. This particularly is annoying, if there is a very tiny or even invisible object on the sim border, so you have no chance to recognize it before your ship suddenly sinks for no obvious reason.

Some times avitar hover hight is used on furnature as a quick way to adjust self It would be neat to see a return to last known position button on avitar hover hight. And it be neat if more then one inventory folder can be opend to use a drag and drop sorting feature rather then a year of scrolling

The current method that SL uses to encrypt passwords for saved logins, specifically using Network settings, causes issues when switching between networks on a laptop. Please find a better way to encrypt the saved credentials, especially on systems where things like network configurations can be easily changed (in particular, laptops, but this applies to other systems that switch their network settings as well).