🪰 Viewer Bug Reports

It seems that now we have deterministic link order when uploading multiple meshes in a DAE or GLTF/GLB file, however even though it puts the first object as root, based on alphanumerical order, it puts the rest of the links in reverse order. Test this: Create a DAE or GLTF file where each mesh is named A through E. Confirm that the file has the meshes listed in order of A....E by opening it in a text editor (doesn't work for GLB, obviously, but does for GLTF or DAE) Upload 'as you do' Check link order, and find them to be in the order A, E, D, C, B where A is root.*** *** In the case of DAE, this seems to be true for uploading in the latest FS Beta (7.2.0.78879), but besides root being 'A' in all my tests, the other links seems to end up random when uploaded with the SL Viewer, not even just in reverse order. Expected behaviour is to have all links in alphanumerical order, where A is root and is then followed by B, C, D, E, regardless of GLTF or DAE. Related Canny, which can be closed: https://feedback.secondlife.com/bug-reports/p/random-root-object-assignment-upon-upload-of-multi-object-dae-file

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.

Tldr: I used wireshark to dig into the requests and saw multiple requests for the same file. I figured this might be buggy behavior. Where's the cache? Background: Ive been using nginx through privoxy as an alternative to secondlifes caching because 20GB can fill on just driving through 4 sims, presuming you actually wanted to look around in each of them. Anyways... I noticed repeat requests and figured maybe I was mis-serving things to the viewer and causing problems. Then, I got wireshark and tried without my proxy/cache, just the viewers native one. Issue: Assuming i can read these logs (debatable)... it appears the same files are being http-requested multiple times even when they should be served from cache (as in, there is room and there has been time since last request for it to get saved. While I do have a 20 minute wireshark capture, its 500MB so I found one texture that was re-downloaded 13 times within that 20 minutes and I'm giving that as an example. This particular texture seems to be someones jacket, so no jumpscares. The image attached shows a search was for "Range: bytes" which is showing the Range request bytes and Content-Range response bytes, so you can see what requests were made, and what was served. The viewer is requesting upper ranges of null, 180631, 704919, and 2802071 (I want to guess these are relevant to discard levels). It even once asked for 98181-2802071 which is outside of the range of the file. This is why I'm most suspicious of an issue, because asking for byte 98181 in a 98182 byte long file is asking for the last byte of the file, plus more - which it should know doesn't exist. So, the server rightfully gives it 1 byte and reminds the viewer that the file is 98192 long. Unless that one byte was being used for a check, it seems odd to knowingly request it - so as a programmer I want to guess there's a one-by-one error somewhere. Sorry for being rant-ey but I don't know enough about general network diagnostics in order to give this information in a clear and concise manner.

Existing scripted object with llParticleSystem now rendering particles differently/incorrectly. Item makes use of PSYS_PART_BLEND_FUNC_SOURCE,PSYS_PART_BF_ONE_MINUS_DEST_COLOR, PSYS_PART_BLEND_FUNC_DEST,PSYS_PART_BF_ONE_MINUS_SOURCE_COLOR, to render view behind the particles in inverse colors. A recent update has caused the particles to render the inverse view extremely bright. It is no longer a simple invert.

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

Textures are extremely slow to render. This is happening to about myself and a dozen friends of mine. For some reason over the last two weeks textures in SL irregardless of if they are 1k or 2k are taking forever to render a great amount of the time. It also seems to be affecting performance of each viewer as well. I can provide images and video recordings if requested. Clean installing, clearing cache, increasing cache size limits, etc. all do not change the issue.

Traditionally, when Camera Constraints were deactivated in the SL viewer, it was possible to move the camera in all directions and heights without restrictions, even below sea beds which had a 0 metre altitude. Disabling Camera Contraints was a useful method for finding and retrieving lost prims and objects trapped below the normal field of view deep underneath a region. But in Viewer 7, with Camera Constraints deactivated, the camera can no longer be moved below 0 metre height, the camera absolutely refuses to move beneath 0m altitude of a region terrain any longer. This makes retrieving lost prims and objects much more difficult, or even impossible. Please restore the fully unlimited Camera Constraints feature to how it previously performed in earlier v6 SL (& third party) viewers, so that we are able to move a camera below 0m altitude again. Thanks.

In the past, crouch would effectively be instantaneous; you press pg down, you squat, you let go, you get back up, with no delay. You could tap pg down to make your avatar do this little jig, and if you tap it fast enough, there'd be practically no visual indicator at all, especially if you're wearing an animation override. All of which was actually rather useful for some fun interactions, including some I've scripted myself, which is then why it's so annoying that for some reason, this behaviour appears to have changed. Now if you tap pg down, you crouch for a whole second before getting back up, which does ruin some of those gadgets where it's supposed to be invisible or at least instantaneous so you could do it quickly in a rapid succession. I'm at least assuming this change in behaviour isn't intentional, because this only happens while you're standing still; if you're in the middle of another animation (walking, turning) or even in the middle of transitioning from any of those other states to standing, it still demonstrates the classic behaviour.

There's a visual glitch when using more than one BOM texture layer on a Universal Aux channel if there's partial transparency in the texture using Blinn-Phong textures. I've made BOM textures with partial transparency for rigged fairy wings, so that customers could layer a stripey texture on top of the main wing texture. However, it's as if there's an outline of 100% transparency around the edges of the upper stripey texture that punches a hole straight through the underlying wing texture as well. It shows up the most when in front of a bright background. I tried making the stripe texture completely black with a 100% transparent background by converting it to a vector and then converting it back into a raster image in Photoshop, and this minimizes the issue so that it's only visible if you're very zoomed in, but this means there can't be layered BOM textures with blended edges at all on the Aux channels. I had envisioned being able to make add-ons like colorful peacock 'eye' spots, faded edges, etc so people could really customize their wings' look, but this doesn't seem to be possible right now.It happens whether the files are PNG or TGA, with or without an alpha channel.Since the main wing textures have partial transparency, changing the blend mode to alpha mask would not solve the issue. Hopefully you can see the problem in the screenshots. You might at first think it's the white outline 'halo' issue but no, it's actually that the edges have an outline that are completely clear so the background shows through.

If you use the Replace Links feature to replace a BOM texture, the "new" texture is placed at the top of the list. Because list order is essential to the proper baking of textures, especially body and head textures, this causes every outfit to failure to bake correctly. Having searched for a global way to reorder textures (and finding none, not surprisingly) this places the user in the unenviable position of individually manually editing potentially hundreds of outfits.