🪰 Viewer Bug Reports

Voice cutting out after a few second. works again when I refresh voice in preferences and click ok, then it drops out again. This issues has been happening for over 3 weeks and never happened before. My mic works fine on other platforms like discord, zoom etc it is purely a recent SL issue.I know all my settings are correct and the support ticket I filed suggested this was a bug. I am using the latest firestorm release but have also downloaded firestorm Beta and the latest sl viewer and this issue occurs in all of these. It also happened in any sim I visit, not just one sim. I am using a Mac and Firestorm 7.2.3 (80036) although I tried Bets and the new SL viewer as I said.

See attached picture. This appears next to the SLURL Bar on a fresh account

I am experiencing ongoing spam from the account ChristophNaumova33, which appears to be a bot. The account is already blocked on my end, however I am still receiving approximately 40 daily spam attempts. While the block prevents messages from being displayed, the system still logs each attempt (including ad-hoc conference/group invite attempts). This is flooding my chat history and impacting my ability to use chat logs for Second Life business purposes. Key issues: Account is blocked but spam attempts continue daily Block does not prevent conference/group invite attempts being logged Chat logs are being heavily spammed despite no visible messages Ongoing impact on usability of chat history due to volume of entries The bot was originally encountered within the Fifty Linden Friday group. After continued spam, I asked in the group whether others were experiencing the same issue, and several users confirmed they were also being targeted but had successfully blocked the account. I am unsure why blocking is not fully preventing the same behaviour in my case. I have reported this issue daily, but the account remains active and the behaviour continues. Reference evidence: https://gyazo.com/66369e0ddd647ef2c7f6300df406d63f https://gyazo.com/400f8b9cb56b2acf4950a19e149adfcc Requesting investigation and mitigation of blocked-user invite/logging behaviour.

As you can see in my last comment added here on 30 March 2026 which was ignored ever since: https://feedback.secondlife.com/bug-reports/p/alpha-mask-highlight-vanishes-under-alpha-blend-highlight-when-highlighting-tran After the "fix" for the previous issue by RyeMutt in the SL Viewer 2026.02 preview, as well as in a Firestorm preview that has already imported the supposed fix. The alpha mask highlight issue is gone now indeed, but the other aspects got much worse: 1: Transparency highlight from HUD attachments is completely missing. 2: The transparency highlights got even much brighter than before. Screenshots: Firestorm 7.2.3.80036 (same behavior as in SL Viewer 2026.01), dark: https://prnt.sc/nXv-RBS9g8NK Notice how bright the red highlight on the trees inworld is compared to the red highlight on the HUD. It is very similar to the difference "fullbright" makes on textures inworld. All highlights used to be as dark as on the HUD in this picture before V7. Firestorm 7.2.3.80036 (same behavior as in SL Viewer 2026.01), daylight: https://prnt.sc/TpXjUSOph4il Notice how bright the red highlight on the trees inworld is compared to the red highlight on the HUD. It is very similar to the difference "fullbright" makes on textures inworld. All highlights used to be as dark as on the HUD in this picture before V7. Firestorm Nightly Preview 7.2.4.80397 (same behavior as in SL Viewer Preview 2026.02), dark: https://prnt.sc/DiNdfzWFrn6X Notice that the HUD has no alpha highlight at all. Alpha mask blue highlights show through now as intended but the entire highlight overlay got even brighter, a lot. SL Viewer Preview 2026.02, daylight: https://prnt.sc/dPFeb5oWR3ck Notice that the HUD has no alpha highlight at all. Alpha mask blue highlights show through now as intended but the entire highlight overlay got even brighter, a lot. This can be a showstopper for creators who make HUDs or adjust HUDs for their products, I think I'm not the only one who first assembles the HUD links rezzed inworld, then adjusts the parts while wearing it on the HUD. Editing parts with transparency will be nearly impossible with the highlights missing. The other problem is this excessive brightness on the highlights. If most people were fine with how bright it already was, and only some of us got headaches from this, now this is at least 4 times brighter and it is going to burn out more people's eyes while trying to work with transparent objects. This is apparently because the alpha debug overlay is included in the HDR exposure pipeline which increases the brightness of these textures, it also makes the red and blue alpha highlight visible on reflections on objects when "highlight transparent" is enabled. This shouldn't happen, the highlight shouldn't be included in reflections and it should be rendered separately so that it wouldn't be affected by lighting and it wouldn't affect reflections. Now that the missing transparency highlight on HUD attachments will be in the next Firestorm release, creators and anyone else who edit HUDs and need to see their transparent parts will have to revert to 80036. While there was a workaround for the vanishing alpha mask highlight, there is apparently no workaround for the missing HUD attachment highlight.

I first noticed this in the latest Firestorm Beta when building, when i cammed away from my ava to build an item and then returned my ava was invisible , could see my name /group tag but no ava, to recover i had to physically move my ava and it was only after about 2 steps that the ava reappeared.

Bug was found by Lucia Nightfire in the Firestorm Preview group On the LL viewer, using Websearch , search groups for the term Hentai Observe there are many results Now switch to Legacy search via top menu -> World -> Legacy Search, and search Groups for the term Hentai Observed Behaviour Legacy group search on the LL viewer returns zero results for the term Hentai This bug also reproduces on the Firestorm Beta when using LL's Legacy Search implementation. On the Firestorm Beta, setting the debug setting FSUseFSLegacySearch to TRUE, which uses Firestorm's Legacy search rather then LL's, the bug no longer reproduces.

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 am not sure if this is the right place to post this so if it's not please somebody recommend a more specific form recently we had both of our regions converted over to web RTC. We did this understanding that this is the future and we might as well get used to it now and avoid the rush when the world converts. However there are a few things that I have noticed that are concerning. There are times when you're in world and ones voice can sound quite robotic almost like it's dropping packets. The temporary fix seems to be unclick your voice key scroll way out from the distance hit the escape key to return to normal view and then re toggle on your voice. I have no idea why this works but it seems to fix it temporarily. Web RTC also seems to use a very different calibration of voice levels whereas when you can hardly hear somebody their voice brackets are in bright red in in a regular SIM would be over modulated. I am not sure are these things that LL knows about or who to talk to regarding these concerns. The individual individual volume control for other specific users do not function. The Voice waves are not correct

## Summary GLB/GLTF uploads can produce different rigged mesh deformation than DAE uploads from the same source model when the model uses a bind pose that differs from the viewer skeleton rest pose. ## Context Bind pose support is not directly exposed by Blender itself, although other tools such as Maya support this workflow. Both Collada/DAE and GLB/GLTF can represent bind-posed models through inverse bind matrices. The Avastar Blender add-on explicitly adds bind pose support and collada support to Blender-5, so this issue can be reproduced and tested using Blender-5 with Avastar. ## Steps to Reproduce in Blender In Blender, create or open a rigged mesh that uses a bind pose different from the default viewer skeleton rest pose. typical use case: A-posed models with A-Pose as restpose. Export the same model from Blender as DAE. Export the same model from Blender as GLB/GLTF. Upload/import both files into the viewer. Compare the imported results at the vertex/deformation level. ## Actual Result The GLB/GLTF import can deform differently from the DAE import, even though both files were exported from the same source model. Visible differences can include child joint twists. ## Expected Result DAE and GLB/GLTF exports from the same bind-posed source model should import with equivalent vertex-level deformation. Mesh edges may differ depending on exporter triangulation, but the rigged vertex positions and deformation should match. ## Test Notes This was tested with Blender using Avastar bind pose support by exporting the same bind-posed model as both DAE and GLB/GLTF, then comparing the uploaded viewer results.

I present the same model (a small avatar accessory) with 2 different sets of LOD models. In each case the lowest LOD model has been 'zeroed out' to 18 tris as is typical in this use case. Triangle counts are as follows. * Model 1 - High 63040 (36k virts), Med 15760, Low 3940 * Model 2 - High 15760 (10k virts), Med 3940, Low 3940 Both of these models are visually indistinguishable in use. The DAE files prior to upload are sized as follows. * 63040 tris - 9.2mb * 15760 tris - 2.2mb * 3940 tris - 500kb Working on the dae sizes alone ... * Model 1 - 11.9mb * Model 2 - 4.9mb However .... * Model 1 - Download weight 0.7 * Model 2 - Download weight 3.1 When worn ARC is equally broken (as reported in firestorm) * Model 1 - ARC 319 * Model 2 - ARC 672 Objectively Model 2 is better for performance. Duplicating the mesh for 2 detail levels is punished to the point that using a sub division surface modifier to generate an insane 63k tris high model results in 'better consumer numbers' at intended object scale (it's also cheaper to upload). In addition to model duplication being unnecessarily punished, the scale component of Li accounting is fundamentally flawed and pushes creators into a situation where large items need to be low poly and tiny (often worn) items are best high poly! No wonder everyone's avatar is solid in wire-frame. This model is a small avatar accessory. Obviously the example mesh is over detailed, 'unoptimized' and created using techniques best suited to slow rendered content rather than real time. The point is why should anyone bother with 'low poly' when this gets the-job-done and is predictably rewarded.