🪰 Viewer Bug Reports

• Use concise, precise descriptions• Do not include sensitive information. • Create a support ticket at https://support.secondlife.com for individual account issues or sensitive information.
my.secondlife.com user image assets (Groups/Picks) and SL Events images failing to load
Images hosted through my.secondlife.com are no longer loading. This appears to affect user Groups and Picks images and is impacting multiple residents, not just my account. In addition, club/event images displayed in Second Life Events are also failing to load, which may indicate a broader issue with image hosting or delivery rather than isolated account data. Expected Behavior: * Group and Picks images should load correctly on my.secondlife.com . * Images associated with Second Life Events should display correctly. Actual Behavior: * Most Groups and Picks images on my.secondlife.com appear as broken image links or fail to load. * Club/event images in Second Life Events are also broken. Scope: Based on discussions with numerous residents, this appears to be a widespread issue affecting multiple users across different accounts and platforms. Troubleshooting Performed: * Relogged into Second Life and my.secondlife.com . * Tested using Safari, Chrome, Firefox, and private/incognito browsing. * Tested over LTE, Wi-Fi and Cable connections. * Tested on multiple devices. * Confirmed by multiple users on Windows PCs, Apple computers, and mobile devices. The consistency across browsers, devices, operating systems, networks, and multiple user accounts strongly suggests this is a service-side issue rather than a client-specific problem. Please see screenshots on ticket 2530985 showing broken image links (if needed).
2
¡
Linden Content
Unsupported bones permanently affect subsequent animations
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.
7
¡
SL Viewer
¡
tracked
BOMs and Alphas Removing Previously Applied BOMs and Alphas
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!
0
¡
SL Viewer
Viewer-side scale interpolation does not finish
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).
2
¡
SL Viewer
¡
tracked
Load More
→