🪰 Viewer Bug Reports

upon initial log in after installing the block list is fine block list is empty upon a new log in every log in after that the block list remains empty even after adding avatars to the block list again after clearing cache block list comes back but empties once relogging and letting inventory load completely also happens on the latest firestorm release edit: cannot update to add photo of empty block list

1: Stand in front of a wall or object. 2: Move your camera around to look at the front of your avatar. 3: Press the 'walk forward' key. (up arrow or w.) In previous versions of the viewer, the avatar would turn around and walk in the direction the camera was facing. In the current version, the camera moves and you walk the direction the avatar was facing. Use Case: I use this when performing in plays, when my character has to deliver a line, and then turn around and walk to a new position. It takes too long to manually (via keyboard or mouse) to turn the avatar all the way around. Extra Note: Firestorm 7.1.13 (78266) Jun 14 2025 21:43:13 (64bit / AVX2) still exhibits the old behavior (the avatar turns around). except when using a camera control hud. (it used to work with or without a camera control on.)

Description: When importing a Collada (.dae) file from Blender into Second Life, one or more objects within the mesh linkset frequently get renamed incorrectly, even though all object names are clearly and uniquely set in Blender prior to export. This issue occurs systematically: All objects are properly named in Blender. The .dae file is verified to contain the correct object names. However, upon import into Second Life, at least one object's name is arbitrarily replaced by the name of another object in the linkset. This results in duplicate names in the final imported mesh, despite no such duplication existing in the original .blend or .dae. This bug makes it extremely difficult to manage and script mesh components reliably, especially when using scripts that rely on precise object names via llGetLinkName(). Steps to Reproduce: Create a multi-object mesh in Blender with uniquely named objects. Export to Collada (.dae) using SL-compatible settings. Import into Second Life using the Mesh Uploader. Observe that one or more objects are renamed incorrectly during or after import. Expected Behavior: Each object should retain its unique name exactly as defined in Blender. Actual Behavior: At least one object name is replaced by another object's name, leading to incorrect duplication. Notes: This happens regardless of naming conventions (e.g., simple vs. complex names, underscores, numbers, etc.). It's not caused by Blender's export; inspecting the .dae shows correct names. The issue seems to originate during SL’s import processing stage. Please investigate and correct this persistent and highly disruptive behavior. Just a final note: it's been this way for years. It's annoying having to check each object name one by one just to find the one that's not named properly.

Enable full screen mode in preferences. Reboot client. off topic, i can get alchemy, the app data folder from an older version on alchemy, to work fullscreen at 5120x2880. But all the modern clients, i run into this error. I need Fullscreen support to record my machinima work, as the work around tend to steal away FPS or compromise color output.

In daily use, for some months, the image in the viewer ramps to blinding bright and back again to normal. The duration of the brightness is < 10 seconds. The brightness isn't a flash, it ramps up and down. I am generally in default midday (SHIFT+CTRL+y), so I see it there, but also on various other EEPs.

Viewers constantly fail to load block list

within logging in crashing on my viewer. can see others typing in local but what i type does not go through

This weekend (particularly Sunday 6/22), I experienced disconnects every handful of teleports using SL Viewer, Firestorm, and Alchemy viewers alternately. While that's an immediate inconvenience and concern, it's not the root of the problem: The problem is that I don't even know there's a problem. As is always the case with networking issues, "everything else" was working fine; video streaming in web browsers, connections to SL and other websites, Discord servers etc so I was not having an overall internet outage... but then, I can't really do anything here. If there's a problem on my end, I can't tell; if the grid is struggling, I can't send you anything to determine what might have been bottle-necking. When I have a viewer crash, at least I get a bugsplat thing, right? But what happens when I go to teleport to a new region, and 20% of the time, I get a progress bar just sitting still at "Requesting region capabilities" or region handshake? What's really happening under there? I know that after 60 seconds, it'll time out and "Quit" the viewer, but that leaves me with nothing to tell you about what has happened. Nothing crashed and yet, something's wrong~ I've heard many (including Lindens) refer to region changing as an indecipherable and scary mess of spaghetti code, but this is the lifeblood of the platform, and it seems to have phases where error rates go through the roof (anecdotally, during the half-day I had these issues, various group chats indicated I was not alone). A thousand little cuts in silence, and it's hard to know what to report and how. The request here is a bit nebulous, I apologize, but that's because I don't even know what LL needs, but please add something to the viewer to log region changes in some way that is meaningful to you, and that presents itself when the viewer times out and disconnects. You know that screen where I can choose to view IMs offline or Quit, when I have a timeout? Add something there, please, to open the region change log folder. (And pls make a region change log, even just to track the most recent change; it sounds as though this one area of SL activity could use better investigation). That way, when things are acting up, there's something to send to support that hyper-focuses on the specific region-change that caused the problem. I could attach that here, or send it to customer support etc.

http://maps.secondlife.com/secondlife/Pattaya/229/218/21

The current midday eep is GRAY.