🪰 Viewer Bug Reports

Description: In 2025, an old bug is back. Edited a script in an attached object, hit Save over 150 times, compilation was successful. After teleport or crash, script reverted to an older version (1.8). Hours of work gone. Details: Object was attached (not rezzed). Multiple manual Saves, confirmed by compiler. After teleport or viewer crash → changes lost, script rolled back. This bug had been fixed years ago. It’s now back and happening again in 2025. Affects attached objects more often than in-world ones. Severity: Critical for developers. Fix needed: Asset save sync on attachments is unreliable. TP or crash = data loss. This should not still happen after 20+ years. WTH — I worked 2 hours HARD for nothing due to your stupid glitch. We're in 2025, and you still haven't fixed teleport issues? 23 years later and TP still sucks. Seriously?

Since the most recent SL Official Viewer and the recent (mid-June) Firestorm viewer, I get crashes shortly after logging in at my home location or other locations. If login is successful, I will crash shortly after beginning to move around or when remaining still but flycamming around. This is on Mac (intel) and AMD graphics as noted in the info block below. --also-- Logging in to my home region (Cape Poge) occasionally fails, especially after relogging following a crash as described above. When it does, I can usually log in to a mainland location (DeHaro or similar) and TP to my home location, but will usually be followed by the crash scenario. This does not seem to occur on my Apple Silicon M4Pro notebook, just my intel-based desktop machine, which is older but was working great up till the latest releases. Currently unusable on said hardware.

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

I would like to apply BOM AUX textures on the lashes of my mesh heads but I noticed annoying differences in their rendering when they are alpha (which is the case for lashes). Here is an example : https://gyazo.com/a46d41f4fbbbb8588a82c71d69892870 Above, the texture applied directly on the prim. Below, the texture applied through the BAKED_AUX2 texture. As you can see the rendering is different. The BAKED_AUX2 is "lighter". Why is it so ? For the moment I can not use the AUX textures for my lashes because of that difference...

Having made a few poses with Firestorm's Poser facility, I uploaded the resulting .bvh files to SL. During the upload preview, regardless of what priority I chose, the preview showed that there was interference by whatever standing animation was active - either my AO's or the default LL standing animations. This behaviour continued even after I've uploaded the pose, as the title suggests. I reproduced this behaviour with both Firestorm 7.1.13.78266 and the current version of the official viewer, which I downloaded and installed to be sure. I also tested by reuploading .bvh poses I had created with AnyPose - these were NOT affected. To be clear: in all cases I set my uploaded poses to priority 4.

The issue I reported probably like 10 years ago still exists: * Teleport to a new region * Source region sends circuit info of destination region to viewer * Viewer acknowledges circuit info being received * Simulator of source region transfers agent to simulator of destination region * Simulator of source region immediately closes circuit with agent's viewer * If for some reason to connection to the simulator of the destionation region fails, the viewer has no connection to either the old simulator nor the new simulator and gets logged out after 60 seconds The connection with the viewer must only be closed after the simulator of the destination region confirms the connection with the viewer has been established instead of relying on faith the handover will succeed without any problems.

When taking a snapshot with Screen Space Reflections (SSR) enabled in the viewer, reflections visible on reflective surfaces in the viewer window are not captured in the resulting snapshot. This results in a discrepancy between what the user sees in the viewer and the final saved image. Steps to Reproduce: Enable Screen Space Reflections in the viewer settings (Graphics -> Advanced Lighting Model -> Reflections -> Screen Space Reflections). Position your avatar in a location with reflective surfaces (e.g., near water, mirrors, or shiny objects). Ensure that reflections are clearly visible in the viewer window on those surfaces. Take a snapshot using the in-viewer snapshot functionality. Observe that the saved snapshot does not include the reflections that were visible in the viewer. Expected Result: The saved snapshot should accurately capture all visual elements present in the viewer window, including screen space reflections. Actual Result: The saved snapshot is missing the screen space reflections, resulting in a visually inconsistent image. Workaround: None known. Affected Versions: [Specify affected viewer versions] Attachments: Snapshot_001.png - Result of the snapshot showing the missing reflections. Viewer_Screen_Snip_Capture.JPG - Screenshot of the scene as seen from the viewer in-world, with reflections clearly visible.

The orientation of a prim is affecting its bump-map shadow effect (relief). An upside down prim seemingly inverts the effect, turning an emboss into an engrave. This is showing in Firestorm and LL viewer, which was updated moments ago. The effect is shown in the images below -First is a single prim 1m square -Second section is a 4x4 grid of 0.25m prims, rotated differently but textures aligned -Third and Fourth are the same things using Materials rather than Blinn-Phong, which do not have the issue The bug is the Second section showing differing relief amounts even though they are co-planar and same orientation. The difference here is the orientation of the prims themselves.

PARTICLE RENDERING: Please fix the system default particle rendering. Specifically, the white dot default particle in version 6 (pre-PBR) is perfect, but now in version 7 it shows up as a white center with a visible square outline. An alpha issue I believe. This is the system particle which is called by default when no texture is added to the emitter. It is the basis for so many generic particle generators. So it would be great if LL could just tweak this little one for us please and smooth away the edges :) ! https://gyazo.com/97e97aeb4f68771c3c0c9791d444da9c

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