🪰 Viewer Bug Reports

Summary: After the most recent forced update to the official Second Life viewer (August 2025), the Left Mouse Button (LMB) behavior has changed. When set to “Interact,” LMB no longer triggers weapon scripts that rely on CONTROL_LBUTTON. This breaks functionality for multiple no-mod weapons from different creators that previously worked without issue. Steps to Reproduce: Use the official Second Life viewer (latest version as of August 2025). Equip any scripted weapon that uses llTakeControls() and listens for CONTROL_LBUTTON. Ensure LMB is set to “Interact” in Preferences > Controls. Attempt to fire the weapon using LMB. Expected Behavior: Clicking LMB should trigger the weapon’s firing script, as it did in previous viewer versions. Actual Behavior: Clicking LMB does not trigger the weapon. Instead, it appears to be intercepted by the UI or treated as a generic “Interact” action, preventing the script from receiving the input. Additional Notes: Issue affects multiple no-mod weapons from different creators. Rolling back to the previous viewer version restores functionality. Firestorm viewer does not exhibit this issue—LMB still triggers weapon scripts correctly. No workaround is available within the official viewer, as “Interact” cannot be disabled or reassigned to raw object click. Suggested Fixes: Allow users to reassign LMB to “None” or “Click Object” instead of “Interact.” Add a toggle to disable UI-level interception of LMB. Restore legacy behavior where LMB input is passed to in-world scripts unless explicitly overridden by HUD/UI elements.

When at an event and clicking on to to demo sign. It opens the map. There is no button on the map to teleport

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

If I search for an attachment in the ouftits/avatar window, I get no results, but if I expand the list for the outfit I'm looking the attachment for in, it does show up on search, but at that point I have essentially found it manually, rendering the search kind of useless.

Environment Second Life Release 7.2.0.16729091892 (64bit) Description Gesture sounds still be played even if you uncheck the "Enable sounds from gestures" checkbox in the sound volume pane that appears when you click the speaker icon on the right side of the main menu of the viewer. Reproduction steps Teleport to the region where the script is available. Click the speaker icon on the far right of the viewer menu to display the sound volume pane. Set the "Sounds" trackbar to its maximum. Uncheck the "Enable sounds from gestures" checkbox. Perform a gesture that generates a sound.

Run Script default { state_entry() { llSetTextureAnim(ANIM_ON|LOOP|SMOOTH, ALL_SIDES, 0, 0, 0, 0, 1.0); } } Set PBR Material with visible emissive mask. (Preferably <1.0,1.0,1.0> Color) Set Glow to 1.00 Set Alpha mode "blend" Setting Opaque or Mask works as expected, setting Blend causes emissive part of the material to snap to zero and not animate. https://cdn.discordapp.com/attachments/1259105650776997908/1259105650932191312/image.png?ex=668bca84&is=668a7904&hm=6e2d81e302f4d2cad40492db69839ab253528e092862fad88e7c6e4024f42308&

when i rez a wood box i can't blank it out or apply materials or textures to it or anything else firestorm latest veiwer to date

Textures in every viewer since the PBR update have now been unloading and reloading, often times failing to do so, and remaining blurry. I have tried everything suggested such as whitelisting viewers and their features, but I know I'm not the only one experiencing this. This is completely game breaking and as a texture artist it's near impossible to have a consistent workflow when half the time my textures aren't loading in. I have a new GPU and plenty of RAM to spare and then some so it's not my computer. I have been able to go into the EDIT menu and have it load in, but it does this for the diffuse texture only, and when exiting the menu it will go back to attempt its reloading cycle with multiple failures. PLEASE FIX THIS.

hi, i have a weird issue. At crowded places the viewer is using 12GB RAM sometimes higher and then i end up crashing with Out of memory message. and i dont know what to do at this point because i visit few corwded place then i crash. lowering graphic settings doesnt help. it keeps using 12GB + I tried on Firestorm viewer too and on Firestorm Beta too and same result. i would be so thankful if someone could tell anything that could help

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.