🪰 Viewer Bug Reports

Make a notecard and set all permissions in Properties to Next Owner can Modify, Copy, and Transfer. Also check all boxes user Permissions, including Group Share. Write any text in the notecard. Create a simple prim on your Deeded Land. Check that the object is also in the land group. Copy above notecard to Content tab of prim object. Before deeding the prim to the land, you can read and edit the notecard, as the owner of the land and the owner of the prim object. Click Share and Deed buttons to deed object to land group. Go back to notecard in contents, and you will not have permission to read or modigy the notecard. Note the notecard had full perms before transfering to the object. You, as the owner of the group cannot delete the notecard. If you then check the perms of the notecard in Content, the Share box was unchecked. Trying to change perms with Permissions button gives an error message, cannot add perms. If you try to add any object, script,or notecard to Contents, one deeded, you will be blocked with red block icon when trying to drag from inventory to Contents. This makes group members with perms to edit a deeded object impossible to change anything. A deeded radio for instance cannot change or update station urls in the notecard. Note I am the owner and creator of the object, the notecard, and the land group and the land. Other group members with edit permissions are also restricted from modify of deeded objects. This BUG was first noticed in the Second Life Release 7.2.2.17774206511 (64bit) viewer, and also the Firestorm Firestorm 7.2.2 (79281) Sep 9 2025 18:02:30 (64bit / SSE2) (Firestorm-Beta). In all versions before this, one could both read and modify notecards that had full perms in Contents, and well as being able to add more scripts, notecards, and objects to Contents with only Edit permissions for group objects.

on viewer 7.2.1.17108480561 - Default sculpted prims do not upload correctly. the image shows the exact same texture represented 3 ways. On the left, the model was uploaded prior to the version release. In the center, uploaded after the update. On the right, used as a local texture from my HDD.

Light sources including projections cause issues with alpha blended textures. Alpha Blended textures often appear much brighter than Masked, or Opaque textures.

Export from Blender as "gLTF separate" ( https://i.gyazo.com/353470ee8a3bb81f7f290f272372d061.png ), give it a filename with a space in it (e.g. "My Mesh") Try to upload, get https://i.gyazo.com/654fb82d7ff068a5f6aba2a1ff2a37b3.png If you open the .gltf file in a text editor you will find: https://i.gyazo.com/f65665874e923e41314103861103ebe6.png If the %20 is replaced with a space in the file, the GLTF uploads successfully. Conclusion: either Blender is doing wrong by making the space %20 in the .gltf file, or the uploader is not doing what it should to handle the URL encoding. This problem exists in both SLV (info attached) and the current FS Beta (7.2.2.79281).

The emoji's are showing up as the same color as my name tag. Last year at Halloween, they were showing up as the orange pumpkin, white ghost, etc. Now they won't show up like that at all.

Old-style "System Clothing" skirts when worn with an avatar now have an alpha glitching bug in all PBR viewers, especially noticible when standing near water or in front of PNG textured objects; a transparent "aura" around the full length of the lower body appears and looks terrible. Steps to replicate: Create a skirt of any length. Then stand near some water or in front an object textured with PNG Alpha textures. Watch what happens! Please eliminate this weirdness, it ruins the appearance of our beloved classic avatars and system clothing.

Our region is participating in the webRTC Beta program. We are having frequent issues where our participants lose voice and have to TP out or relog to get it back. It is region wide. It seems to usually be immediate or after about 10 - 15 minutes. Yesterday Madori was never able to get her mic to work, but could hear us fine. http://maps.secondlife.com/secondlife/VWEC%20Eduverse/192/159/29

Copying and Togging of existing Reflection probes does nothing and does not reactivate them, creation of a completely new one will work but existing ones no longer work (troubleshooting steps) -Cleared contents of folder from "C:\Users\WorkBOY\AppData\Local\SecondLife" -relogged -reset graphic settings to default -teleported to different sims and back to this one -copied the probe by shift drag -picked up and respawned from inventory -Toggled off and back on when i do this, the options below become deactive, almost like the object lost it's ability to be a reflection probe

(this might be a refresh of https://feedback.secondlife.com/bug-reports/p/202503-viewer-intense-stutter-on-a-nvidia-windows-laptop ) in certain places like this : http://maps.secondlife.com/secondlife/Itame/51/46/84 The viewer can show important stutter on Windows and NVidia gpus, specially after spinning around. The issue doesn't seem to occur on the integrated AMD graphics. I also have the issue in megapahit, which i could try on Linux, and on Linux it's perfectly smooth. So it seems to be specific NVidia + Windows. The issue happens in my both PC laptops (gtx 1660ti / rtx 3080m both with an AMD cpu). (in my setting i have reflection coverage to manual only, hdr & emissive on, only show friends to avoid avatars interferences). Also the issue doesn't seem to be related to avatars, because i tested crowded sims and it wasn't too bad.

This has happened twice to me today when returning home after travelling elsewhere on the Grid. The ambient light from the HDR EEP I've set up here breaks, resulting in areas without local lights going dark. The lighting returns to normal after I relog. Screenshots attached to this report, and here's SLURL of my home parcel if anyone's interested in trying to reproduce it: http://maps.secondlife.com/secondlife/Sawdel/173/9/107 I've not been able to trigger this bug in Megapahit or any other viewer so far.