🪰 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.

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.

For many years selecting rigged mesh with edit tools or right click menu has been unreliable, only working in a small handful of cases, this also applies to the camera. Alt camming/focusing on rigged mesh is a coinflip over whether or not it will work, often sending the users camera through the target avatar and into whatever's behind them. This can lead to confusion and frustration for new residents getting to grips with SL's camera.

While Edit window is open, right/left click on an avatar and it will often select through them. This often includes your own avatar, especially if it's the base body (like BoM). Right click out of Edit will pretty consistently bring up the correct item for inspection. This is a typical way I check to see what another person is wearing, and it's especially useful if I need to check links for particular names or features. More often than not, this is for moderation or when a friend is asking for help.

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

"If the 2D don't work, the 3D don't work". I was at Sci Fi Con 17. All day long, no matter how many or how few avatars were on a region, textures took ruddy ages to load. Now one might say "There are so many textures at a big event it just takes a long time." But I'd walk into an enclosed room... where textures should be limited, yet the vendors on the wall just sat there and sat there and sat there. Textures RIGHT NEXT TO ME fail to load. One can stand there and stand there and stand there... and they still don't rez. I would click on a texture and tell it TEXTURE REFRESH... and it would ignore that instruction. I first reported texture issues and bottlenecks back in 2005. Now my computer and graphics card is hundreds of times more powerful... and textures still load at a snail pace. I will say the same thing I said back then: There is a texture bottleneck on SL. (Or, several texture bottlenecks, and it affects EVERYTHING.) With respect, I'm not asking for an explanation, nor excuses. I'm making a simple observation: After 22+ years online, Second Life should be able to very quickly load 2D textures in an enclosed room. Is this not correct? I suspect there will be people all too ready to give reasons why textures load slowly. To any and all such reasoning, I have one answer: Second Life needs to make textures load quickly. There's no argument, debate, discussion or excuse to that simple statement. Users need textures to load quickly enough that we don't get bored standing in a store (waiting for vendor textures to load)... and decide to go do something else. Like Netflix. ;D Because that's what it is: Second Life vs Netflix. Users have options on how to spend their time. When Netflix can stream entire videos realtime, surely Linden Lab should be able to send 2D textures across the Internet... yes? As a note: I'm not going to debate nor discuss or argue with those who are always ready to argue on these feedbacks. The feedback is posted, I've said what I came to say... and I have to believe the vast majority of SL users will agree with this: textures on SL need to load faster.

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.

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.

I spent days trying to find the bug in my flight physics code that was causing this, only to discover that it was the viewer camera all along. The problem is that sometimes the aircraft flies "visually" smoothly at any speed up to 100 meters/sec; and other times it's visibly jerky, appearing to "vibrate" (change in apparent size many times/sec) as though the camera was acting like a spring instead of being fixed in place behind the vehicle. I'm using the eye/offset calls: llSetCameraEyeOffset(eye); llSetCameraAtOffset(offset); This is because the "newer" (21 years old instead of 23) follow cam is missing features that would be necessary to produce the same behavior, and I find it unsatisfying and confusing to use for aircraft. I instrumented my vehicle with code that captures llGetVel() and llGetOmega() 20 times/sec (rotated into the local reference frame), then uses llSetText() to display mean, standard deviation, and range once per second. What I discovered: Sigma (standard deviation) for local X can be very low (0.0 to 0.02) in level, unaccelerated flight regardless of whether the visual apperance is jerky or not. There is no difference. When it's visually smooth, sigma can actually be quite a lot higher, closer to 1, and it still looks totally smooth. This happens during accelerating and turning. Local Y's sigma is typically very close to 0 in either case. Local Z's sigma is typically very close to 0 in either case. All three axes of llGetOmega() are always zero unless the aircraft is turning, climbing, descending, or yawing. If the statistical analysis is not enough of a smoking gun, here's another: When the aircraft is flying smooth, and I refocus the camera on my avatar, it starts getting jerky, like the camera is damping at some wild speed. Single-frame jumps of tens to hundreds of pixels along the axis of motion. The attached screenshot is the llSetText() stats output when the camera was jerky. Zero standard deviation in this regime + jerky visuals, vs. standard deviation WAY higher during maneuvers when the camera is smooth, provides strong evidence that this is a viewer bug. My code is invariant either way. My stats are invariant either way. When flying smoothly, refocusing the camera makes it do the jerky rendering thing. And sometimes it does the jerky rendering thing whether I do that or not.

Since the 7.1.9 viewer, every time I log in and edit an object I receive an erorr: "SLPlugin.exe has stopped working." Windows Activity Viewer blames Faulting module name: libcef.dll_unloaded. I've attached the corresponding snippet of the cef_log and the Windows event. This error happens, without fail, every time I log on and try to edit an object. It then repeats sporadically, but frequently, throughout the sesssion. I posted a thread about this on the forum where several other people have reported the same: https://community.secondlife.com/forums/topic/515510-constant-slpluginexe-has-stopped-working-errors-firestorm-ll-second-life-release-719/ I understand this has been an intermittent problem for some, and there was a related JIRA on the previous system. For me, this issue is directly related to the new viewer. If I downgrade, it never happens.