✨ 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.

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.

People see the dots and a bot, and assume it's contributing to traffic then some people will actively avoid such a place. If there's such an option I'm unaware of it but I'd love to hear solutions!

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.

Feature Request: View Previously Used LOD Triangle Settings for Uploaded Meshes As a mesh creator, I frequently adjust the triangle limits/settings for each LOD level during upload in order to achieve the best balance between visual quality and reasonable land impact. The challenge comes when a mesh later needs to be corrected or updated and reuploaded. Currently, there does not appear to be any way to review the LOD triangle settings that were successfully used in the original upload. Unless creators manually document every upload externally, the original working values are effectively lost. This results in unnecessary trial-and-error reuploads, inconsistent optimization, and difficulty maintaining the same visual/LI balance across updated versions of a product. Suggested enhancement: Provide a way to inspect the previously used LOD settings for an uploaded mesh object. One possible implementation: * Right-click mesh object * Advanced / Developer submenu * “View Uploaded LOD Settings” or similar The displayed information could include: * High LOD triangle limit * Medium LOD triangle limit * Low LOD triangle limit * Lowest LOD triangle limit * Physics settings (if available) * Upload optimization method used This would greatly improve creator workflow efficiency, consistency, and asset maintenance, especially for creators managing large product catalogs.

The world map has become nearly unusable for discovery. Unless you already know the exact region name you're looking for, the map is mostly a noisy mass of private regions. When zoomed out, the rendered tiles stop being useful and become noise. Private regions should not automatically appear on the world map by default. Instead, region owners should have an option in the region menu that allows them to choose whether their region is visible on the world map. If a region owner enables map visibility, they should also choose a category for the region, such as Shopping, Roleplay, Clubs, Events, Residential, Art, Education, Sandbox, or Other. Regions could then be searched, filtered, and visually grouped by category. Linden-owned regions should be separated into their own official category so mainland, welcome areas, and Linden regions remain distinct from private regions. The world map interface should also include a searchable list of visible regions, allowing residents to search by region name, category, description, maturity rating, and mainland regions. This could also include region wide descriptions when a region is selected. Allowing estate managers to display an image, and descriptive information for the entire region similar to how parcels display in places. (Maybe using the existing covenant as the description) In addition parcels listed in search should also be categorized and visible underneath the regions description. This would not only benefit curated regions, but also benefit parcel owners. Allowing region owners to advertise their sim as a commercial shopping district for example. While listing parcel owners with search enabled underneath that regions description when selected on the world map. Making discovery via the world map not only possible, but much easier and in addition making individual parcel discovery possible via the world map as well. To avoid confusion and clean up the existing map, current private regions should eventually be hidden from the public world map unless the owner chooses to make them visible. This should only affect map visibility, not teleport access, landmarks, SLURLs, or private region access. The result would be a cleaner, more useful world map that helps residents discover active public destinations while giving private region owners better control over region visibility and privacy.

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.

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