✨ Feature Requests

All platforms with user generated content of video/music feature loudness normalization, to prevent sudden volume jumps or differences between content. Loudness normalization adjusts the overall volume of an audio track to match a target standard, which is measured in LUFS (Loudness Units Full Scale). This algorithm evaluates the human perception of average volume across an entire file. Currently residents in Second Life cope by reaching for the sound slider, turning it way down. This kills their shared experience with unbalanced volume. TPVs implemented a Sound Explorer and derender tools to aid in dealing with auditory issues. Loud sounds also travel further, the engine fades sound with distance, so a sound that is twice as loud is heard twice as far away. So every platform with user audio has already solved with this loudness normalization. YouTube and Spotify measure each audio track once and level it. Second Life could do the same. However it is not enough to gate loudness across the entire audio engine -- that is a bandaid that still ruins the shared experience by silencing most sounds across the board towards silence. So what you have to do is fix it from the source, which are the individual sound assets. Ideally users should process sounds in Audacity first with the Loudness Normalization filter and other processing before uploading their asset, but that is an additional tedious step on top of format and other limitations. I've been there and done that. What I am proposing is a Viewer-side only feature: Measure each sound's loudness once, while it is being decoded. The measurement rides inside the existing Vorbis decode loop. A full 30s may only take a single digit ms more off-thread. Store the measurement/correction in a small index in the sound cache Apply the correction as a multiplier on the source gain at play time. The sound is never rewritten, nothing clips or loses bit depth. How much do we correct? Not all the way. A whisper and an explosion are different. So we only apply half the correction. It is also limited so a sound is never turned up more than 12 dB, or down more than 24 dB, and never turned up so far that it distorts. Many SL sounds are under one sec. Loudness is typically averaged over a whole track. This goes wrong on short clips, where silence after the sound gets averaged in. So the sound for a 'click' reads quieter if the creator leaves a longer gap after it. For short clips we measure simply the loudest 400ms of the clip, which gives the same answer however much silence follows. Suggested defaults, all user-adjustable: Target, between -15 to -25 LUFS Strength: 0.5, e.g. half the correction in dB; At full strength every sound lands on exactly the LUFS target -- this means that 50% is closer to creator intent of an uploaded sound Clamp the correct to +12 / -24 dB and cap any boost so the clip's sample peak stays under -1 dBFS. What that means is that transient sounds read far below target while already peaking near full scale, as boosting them to target only drives them into the limiter A toggle in Preferences > Sound I am currently experimenting with this in a private TPV fork ( https://github.com/Martin-Pitt/Alchemy-Skooma/tree/feature-audio/loudness-normalization ), and I also measured every sound in a viewer cache, about 3.5k. Most are already mastered loud, so the usual correction across the board is a gentle turn down. 5/6 sounds come down a little, 1/6 goes up a little. The gap between the loudest and quietest roughly halves. This is really an accessibility feature turned into a good user experience. Like how a significant number of people leave subtitles on YouTube. --- Note I am NOT an audio engineer, I'd really like to hear ones opinion on this, particularly game audio engineer or engineer who has done game accessibility stuff. Expert chiming in and steering this would be a lot better.

When a user has selected multiple objects and accidentally deselects them, provide a command and/or keyboard shortcut to restore the immediately previous selection. The viewer could retain the UUIDs of the previous selection until a new selection is made. Why this would be useful: A lot of the time, when moving store content around or building, it is very easy to lose your selection of objects. You can then spend quite a bit of time having to manually re-select everything. It can also happen when moving parts of a build. Sometimes, due to lag, moving something too quickly, or other unexpected behavior, the entire selection can become deselected. If you were working with a large number of objects, you then have to go back and find and select everything again. A “Reselect Previous Selection” option would make building, organizing, and moving content significantly faster and less frustrating. I know you can drag a selection box around objects to select multiple items more quickly, but this isn't always practical. On regions with dense builds, dragging a selection box can select all kinds of unrelated objects. You then have to manually deselect the things you don't want and reselect anything that was missed. Having the ability to simply restore the previous selection would avoid all of this. For example: Select 30 objects > accidentally deselect > press a keyboard shortcut > the same 30 objects are selected again. Even keeping the last 3 selections in a small selection history would be extremely useful for builders, content creators, and residents. Thanks

This would define a new read/write parameter for regions, default value 100. Most weapons in SL combat inflict 100 damage, which is fine for "hardcore" shooty games where one shot is one kill. However, some regions may want a more arcade game or FPS feel, where people can take a few shots before being killed. Being able to set the region to a level where all the classic old weapons can be used without rescripting them, but without insta-killing everyone, would allow non-scripter region owners to fine tune just how hardcore they want combat to be when they enable combat, without having to severely lock down what weapons are allowed.

Adding the .gif files to the allowed list to upload, letting us create animated particles, textures without the classic LSL moving into the same framed image

If Gacha is coming back to SL in full force as Transfer items, I feel we need the following: A standard, required script that allows the user to click on the machine and receive the odds of each category of item. Merchants may continue to set their own percentages, and tiers of rarity. For example, the output might look like this: Common: 80% Rare: 15% Ultra rare: 4% Secret rare: 1% Or another machine might look like this: Common: 75% Uncommon: 25% And a machine you might not want to play could display this: Common: 99.9% Rare: 0.01% The above are simply an example and not a suggestion for setting a specific required percentage or tiers. I still believe we should leave that up to creators, but that the chances of getting an item you want shouldn't be a mystery. This is a disclosure commonly included in Gacha games or games containing Lootboxes. Many Gachapon machines are also beginning to display odds in real world spaces. If folks want their feedback on maintaining the ban, there is another feedback post for that. I humbly request we keep this one on topic so it doesn't get merged. ❤

1) vertex/face snapping: Being able to either select a Vertex/face on an object then snap to another object's vertex/face or once activated just snap any vertex/face to another object. There are many use cases for this like, Prim snapping, modular parts for structures, road, path, walls and fence sets, could even be used for clothing and wearables on avatars. 2) Pivot snapping: Being able to move the (translation gizmo) pivot point to any vertex on an object, this would be useful for adjusting anything that rotates in XYZ, like a door or window. These two features could be part of a snapping tool set.

As a long-time business owner in Second Life, managing operations efficiently is crucial. Recently, enforcement of the TOS on account sharing led to the deletion of our entire marketplace with over 2000 listings, severely disrupting our business. Deathrowdesigns (DRD) serves over 10,000 customers and manages more than 3,000 items, making single-person management infeasible. I propose creating a system for obtaining written consent to share business accounts among trusted individuals, specifically for business operations. This would help businesses like ours continue to thrive without compromising account security. Additionally, it would ensure compliance with the TOS while providing a practical solution for businesses that need to share account responsibilities.

We can already embed landmarks, images, and other full-permissions assets within notecards, yet even the most simple formatting of text relies on access to third party tools to employ Unicode trickery (with spotty implementation across various third party viewers and operating systems). I suggest the addition of some basic formatting, Bold, Italics, Indents, and making hyperlinks clickable (perhaps using the standard [<url> Link Text] employed in other places within the viewer. Even Canny supports formatting of text. Why doesn't the single most common method of providing information and product instructions within SL? Heading bold italicized bold italicized Ordered Lists Unordered Lists code It even has hyperlinks

Long lamented on the SL forums, and anyplace SL users congregate, "the death of collaborative inworld building' is seen as a major social issue for many creatives and collaborative efforts. Reducing the inherent 'land impact' of the 'basic-building-blocks-of-sl' would make prim-building more of a viable activity, both as a social/collaborative outlet in sandboxes and limited impact private builds, but also as a path toward helping new users function in the user-generated-content economy. A reasonably modeled and textured prim-built end-table will often have many fewer vertices than an imported mesh counterpart, yet through trickery of LOD generation and physics models, the uploaded mesh can achieve land impacts that make the prim-built version completely non-viable in most cases. Reducing the land impact of primitives also has the upshot of encouraging simple lighting, the placing of more reflection probes, and so on.. which our shared world desperately needs to encourage in a 2026 version of SL, with more and more PBR avatars' butts reflecting the blue sky outside.

Allow terrain textures to be set on own land. Terrain textures on my land have priority over those of the Region. This allows us to make better use of the terrain on the mainland and on the land we rent.