🪰 Viewer Bug Reports

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.

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

I am submitting this feedback ticket on behalf of my friend, account name VileCxrpse, who is having some issues with accessing the support forum but this issue is very strange and we need assistance in getting it resolved. This issue may not be reproduceable for anyone but I am a fairly new resident in Second Life (account is less than a week old) and I have been running into this issue since day one. The issue is this: when applying a BOM or an Alpha, it removes the most recently applied BOM or Alpha that I put on my avatar. I had a friend of mine log into my account and she did not have this issue and was able to get multiple BOMs applied without issue but for some reason, on my side, doing the same exact thing, I run into this problem. Here are the things we have tried in an effort to resolve the issue: Recreated the avatar from scratch/default and rebuilt it entirely Rebaked BOMs Reset all attachments Uninstalled and reinstalled Firestorm entirely (we tried the standard launcher as well and the issue was also present there) Ensured that the correct LEL head alpha was applied (BOM Head + Body with APPLIER eyes) and a few other miscellaneous things but we have tried so many things to try and resolve this. I am including a video of this occurring so that you can see in real time what is happening (apologies in advance for the discord link, it was the only way I could get the video from my friend). https://cdn.discordapp.com/attachments/1524205835641815170/1525289403864580186/2026-07-10_19-36-35.mp4?ex=6a52d7f4&is=6a518674&hm=f0411a1a69404f2b44b2b91a54cbe41c90175a61b9f92bc5517837718a8965d1& Please help! Thank you!

Created a folder in outfits Accidentally moved it to another location Not allowed to move it back

System Details: RTX 5080 CPU 9950x3d RAM 64GB DDR5 6000mhz Issue: When logged into the viewer, after a seemingly random time the application just force closes, there are no Viewer Logs BUT Windows Event Viewer logs; Faulting application name: SecondLifeViewer.exe, version: 26.2.0.48334, time stamp: 0x69fa16a3 Faulting module name: nvoglv64.dll, version: 32.0.16.1074, time stamp: 0x6a469d4b Exception code: 0xc0000409 Fault offset: 0x00000000010cba3d Faulting process id: 0x59CC Faulting application start time: 0x1DD0F127FE6A01A Faulting application path: C:\Users\x\AppData\Local\SecondLifeViewer\current\SecondLifeViewer.exe Faulting module path: C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_b26cc1edfbb8f4d0\nvoglv64.dll Report Id: 11c2dfe4-8828-494e-a930-458ff0b7f4e2 Faulting package full name: Faulting package-relative application ID: There is a directly related OpenGL driver crash that always comes at the same time: The description for Event ID 1 from source NVIDIA OpenGL Driver cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: Unable to recover from a kernel exception. The application must close. Error code: 3 (subcode 7) (pid=22988 tid=22492 secondlifeviewer.exe 64bit) Visit http://www.nvidia.com/page/support.html for more information. The system cannot find the file specified ________________________ I have done some extensive testing on my Machine to rule out any System instability or other hardware issues, I have run a full memory test on the GPU and the system + CPU. No errors were found with my system. A full reinstall of Windows was done, and various versions were tested. Studio driver, rolling back to version 580.x. I have tried several driver versions rolling back to even 580.x to no avail. There must be something in the way the most recent NVIDIA cards use the OpenGL driver in a way the secondlife Viewer does not like. Now the reason that strongly suggests that this is a Driver issue with the newer Nvidia cards kis this; I tested another Install from the same windows11 ISO on a PC system with the following specs: RTX 3080 TI CPU I9-12900K RAM 32GB DDR4 3600mhz Both have the most recent NVIDIA game ready driver installed which are 610.x The Viewer however does not crash on the system with the 3080TI, this suggests that something must bite itself with the driver of the more recent cards.

About chat translation, I found two bugs. Using the new Azure API will result in a 401 error. Because the current Azure API has too many characters, it exceeds the viewer’s API character limit. https://learn.microsoft.com/en-us/answers/questions/2147198/speech-service-api-keys-too-long-to-use Another bug was discovered earlier (at that time, the Azure API was still 32 characters). If the text sent to Azure contains emoji or other non-ASCII characters, the translation will become garbled. I mistakenly submitted it under feature requests before, and I’m very sorry.

Single stray flash observed at initial emission when PSYS_PART_FOLLOW_SRC_MASK flag is set, and the PSYS_SRC_BURST_RADIUS rule is therefore disabled, i.e. zero, as per the wiki, no matter whatever value is found in this latter parameter. Perfect coding practise would see the radius explicitly set to zero, but in the event that the the value has been left non-zero and simply relied upon as being disabled, there is a single emission at initial burst which results in a flash at a distance of the radius set. When a timer is running this will occur once at each tick of the timer. Ideally, the radius should indeed be set to zero, which removes the problem, but as the radius value is disabled for the case where the PSYS_PART_FOLLOW_SRC_MASK is set, and correctly does so generally, the initial flash emission should not be happening either and is likely causing visual glitches in-world. To Repro : Drop a simple particle emission into a prim such as: default { state_entry() { llSetTimerEvent(0.25); } timer() { llLinkParticleSystem(LINK_THIS, [ PSYS_PART_FLAGS, 0 | PSYS_PART_EMISSIVE_MASK | PSYS_PART_INTERP_COLOR_MASK | PSYS_PART_INTERP_SCALE_MASK | PSYS_PART_FOLLOW_SRC_MASK | PSYS_PART_FOLLOW_VELOCITY_MASK, PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_EXPLODE, PSYS_PART_MAX_AGE,0.5, PSYS_PART_START_COLOR,<1.0, 1.0, 1.0>, PSYS_PART_END_COLOR,<1.0, 1.0, 1.0>, PSYS_PART_START_SCALE,<0.5, 0.5, 1.0>, PSYS_PART_END_SCALE,<0.8, 0.8, 1.0>, PSYS_SRC_BURST_RATE,0.1, PSYS_SRC_ACCEL,<0.0, 0.0, 0.0>, PSYS_SRC_BURST_PART_COUNT,1, PSYS_SRC_BURST_RADIUS,0.5, PSYS_SRC_BURST_SPEED_MIN,0.1, PSYS_SRC_BURST_SPEED_MAX,0.2, PSYS_SRC_TARGET_KEY,(key)"", PSYS_SRC_INNERANGLE,0, PSYS_SRC_OUTERANGLE,0.5, PSYS_SRC_OMEGA,<0.0, 0.0, 0.0>, PSYS_SRC_MAX_AGE,0.00, PSYS_SRC_TEXTURE, "dcab6cc4-172f-e30d-b1d0-f558446f20d4", PSYS_PART_START_ALPHA,1.0, PSYS_PART_END_ALPHA,0.0, PSYS_PART_START_GLOW,0.0, PSYS_PART_END_GLOW,0.0 ]); } } Observe the stray emission at each tick of the timer: https://gyazo.com/5f8a6b9a8e4c5a657d3d3d0aaa13ce36 Set PSYS_SRC_BURST_RADIUS = 0.0 Observe correct behaviour https://gyazo.com/1a5612c42c44afb0f50ec06b79fe262d

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