🪰 Viewer Bug Reports

Two new notifications have invaded the SL viewer for reasons that baffle me as they are distracting, unnecessary, disruptive of work flow, and potentially privacy-busting. The notification that you have typed an invalid character now pops up in the precious upper-right hand corner of the screen usually reserved for far more important notifications such as payments and announcements from the region owners or Lindens. It does not appear as a hover or toast or message at the workspace itself while editing. You can already tell you have an invalid character as you look at the object window or other type of editing window you are working with because your work STOPS. You already know it is invalid because your prompt STOPPED. You don't need your eye dragged up to the upper right-hand space for an invasive, duplicatory message. The notification that you have taken a screenshot that saved to your computer's inventory folders now also invades the upper right-hand corner. You already know that you took a screenshot because...you set up the location of where screenshots go when you selected the settings in Preferences. You do not need a distracting constantly repeating notice of this event happening each time when...you selected this option permanently -- and could change that location at will. The notice displays to the owner of the browser only, but if you copy room chat to make transcripts of office meetings, other various community and public resident meetings, you will see the notice then included -- outing the name you have used to label your system folders on your own computer, which might even be your full real name -- that you have to painstakingly edit out. These are features no one among the general user base asked for to my knowledge. They have the feel of technologists' perfectionism in systems like CAPSLOCK notices which you already can see because you already have capital letters. The "invalid notifications" proposal was suggested here and simply immediately passed through without debate -- but does not have some mass community demand: https://github.com/secondlife/viewer/issues/961 (I will provide a screenshot of "invalid characters" when I can catch the next one) If these intrusive notifications cannot simply be removed, then provide the user with the option to mute them in Preferences. Currently they DO NOT APPEAR in Preferences as an option to mute.

The animation uploader currently allows animations to include additional Bento body bones that are not part of the supported body animation skeleton for standard human avatars, such as Spine1–Spine4. Because these bones are not reset by Second Life's default animation system, they remain in their last animated state after the animation ends. As a result, subsequent, perfectly valid animations can appear broken, even though the problem actually originates from a previous animation. This makes the issue extremely difficult to diagnose and causes creators of correct animations to receive support requests for problems they did not create. Because the animation uploader accepts these unsupported body animation bones without any warning, creators may not even realize they are exporting animation data that can affect subsequent animations. This is not just an issue for individual animations. Full-perm animation packs are widely reused by furniture creators throughout Second Life. A single incompatible animation pack can therefore affect a large number of products created by different people, while the resulting support requests are often directed at the wrong creator. Possible solutions Reject unsupported body animation bones during upload. Warn creators when unsupported body animation bones are detected during upload. Automatically reset unsupported body animation bones when an animation ends. Addressing this would significantly improve compatibility between animations from different creators.

It is possible for a vehicle to be in a state where it "settles" in a way that sends no more viewer updates. When that happens, the viewer will try to interpolate the last tiny omega value forever. To reproduce this, you need a vehicle that does not resend llSetMotorParams on a forever loop. (Some vehicles will spam a speed of 0 while stopped, which will make them slide in slopes and effectively prevents this bug from happening). The 777 2PM freebie from a previous shop n hop is one of the vehicles that can reproduce this bug. (I also have an old version of a vehicle Ive worked on that can suffer from this, if you want, I can provide a trimmed version for testing purposes) Then the repro steps is: Stop in a slope at an angle That's it! You will notice a stutter happen (this is the movement interpolation fighting the real state of the object), it corrects itself when the object refreshes, but sometimes it will forever interpolate until you right click or refresh in some other way: https://gyazo.com/3c3670b25577d23a168e74b4de890a09 Side note, to prove this is interpolation-related: altering the InterpolationPhaseOut setting affects that stutter, a value of 0s will guarantee you have a spinning moment, the default of 1s makes it stutter, having it at something like 0.001s completely kills the stutter and feels as it should, you dont get a bunch of micro stutters: https://gyazo.com/de896f5d97fa8eb2e249aa30385a0953 Multiple people on multiple viewer may see a different spinning state based on when they last got an object update. Ive had cases where I see it spinning and a friend doesn't, and vice-versa. This bug happens both on the LL viewer and Firestorm and Alchemy. Another case here: https://gyazo.com/a23fde28fb036c85bb5c066946261cd2 now 3 minutes later: https://gyazo.com/0bf78e44ad27ec2892de41ced7babb3e right clicking, or otherwise interacting with the vehicle in some ways makes it reset upright as you would expect: https://gyazo.com/2288c60146f75541bedf4c2a6f3e6801 From my troubleshooting with my own vehicles scripts & some viewer tinkering, the engine/scripts sees the car in its "true" orientation. I've managed to "fix" this quirk by forcing object updates in my lsl script. (Like by changing some invisible hovertext), but the real fix would be to adjust viewer interpolation for vehicles to prevent them from spinning endlessly.

Since a recent Windows update I can no longer select text with the mouse in single-line edit controls used by the viewer. Expected behaviour: While renaming an inventory object I should be able to drag the mouse to highlight only part of the object's name. I should also be able to select part of the text in the Inventory Search field. Actual behaviour: Clicking places the text cursor correctly. As soon as I drag with the left mouse button, the selection is cancelled and the caret jumps to the end of the text. No text remains highlighted. Keyboard selection (Shift + Arrow keys) still works correctly. Mouse selection works normally in multi-line text boxes (Profile/About, Notecards, etc.). Mouse selection also works normally in Windows applications such as Notepad. The problem affects: Inventory object rename Inventory Search field The problem does NOT affect: Notecards Profile/About text Windows applications such as Notepad Troubleshooting already performed: Cleared Firestorm cache. Reinstalled Firestorm. Tested the Official Second Life Viewer (same behaviour). Changed Firestorm skins. Disabled SteelSeries GG software. Checked Windows mouse settings. Mouse drag works normally outside Second Life. Dragging inventory items works normally. Keyboard text selection works normally. System: Windows 11 Version 25H2 (Build 26200.8894) Additional information: The issue has been reproduced in both Firestorm 7.2.4.80712 and the Official Second Life Viewer, suggesting the problem may not be Firestorm-specific.

Unable to rez on water surface or initiate an alt-cam action through the water surface in Second Life RC LeTigre 2026-06-25.28189172152 (e.g. Kiva, Plafil Waters).

The new PBR Nacon environment settings that were recently added to the inventory library are set to no transfer, this prevents them from even being moved out of the inventory to edit them I assume this isn't intentional, and if not I think they should be changed to be full perms like all of the other environment settings

When performing a scripted object scale change, the visual interpolation does not finish properly: the object never reaches desired size until it is selected, or some other kind of change happens to force it to update. If the object is selected already as the scripted command goes through, the object just snaps to the correct size since selected objects do not viewer-side interpolate. This could be a bit of a hassle for resize scripts and the like. Can't reproduce the problem with position/rotation, only scale interpolation. Problem can be reproduced in release 26.2 and FS 7.2.4 but NOT in Cool VL Viewer 1.32.4. Reproduction script below: float STEP = 0.125; vector BASE_SIZE; integer flag; default { state_entry() { BASE_SIZE = llGetScale(); } touch_start(integer _) { flag = !flag; llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SIZE, BASE_SIZE+flag*<STEP, STEP, STEP>]); // uncomment these lines to use a fullbright toggle to force proper visual scale update //llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_FULLBRIGHT, ALL_SIDES, TRUE]); //llSleep(0.5); //llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_FULLBRIGHT, ALL_SIDES, FALSE]); } } Drop the above into a prim cube with size 0.5, 0.5, 0.5. Make a second cube to use as a visual comparison aid with either the initial size, or the target size 0.625, 0.625, 0.625. Uncomment the lines to use a fullbright on/off to force a visual update and awkwardly sidestep the problem. Included demo image also shows the issue: the z-fighting confirms the white cube (scripted) is the same height as the red cuboid (height = 0.5) initially, and same as the green cuboid (height = 0.625) at the larger size. However, when performing a scripted change, the size never reaches 0.625 or 0.5. Problem might be somewhere in LLDrawable::updateXform since it uses an exponential damping factor that can never reach 0 or 1 exactly (unsure why that wouldn't interfere with position or rotation though).

When rendering the timestamps in the compact chat history, the width of the timestamp varies and produces an unsettled, disturbing list of chat messages (see screenshot). This is caused by the new default font Inter, which renders numbers at variable width by default. It should be possible to select rendering of special tabular numbers from within the Inter font by optionally activating the font feature setting "tnum" where useful. That way, all numbers will use a special glyphs with fixed width.

I have a new Acer Aspire laptop with AMD radeon graphics and since I started using SL on this laptop, I crash constantly. I have tried both SL and Firestorm viewers and am getting AMD crash reports but no fix. I have already had a ticket with support but they were unable to help. I have included a screenshot of the error report from AMD Thanks

Title. I've blocked this event owner who has absolutely SPAMMED me with invites over the past few weeks. It was ridiculous it was something like 3 or 4 notecard invites per day, every time I'd log on I'd have multiples. I blocked the owner and I blocked the object they were being sent from. They've apparently since created a new object and SL isn't giving me the object name this time for some reason so I can't block it. Why on earth are users we've blocked still able to send us things via object? Why aren't all of their objects blocked by default too? Blocking is supposed to block all interaction with them not just direct messages. Please fix this, it's really really irritating and I keep having to delete tons of notecards from this person. They're already blocked, I should see absolutely zero items from them in my inventory.