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

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!

Create/Apply a glTF Material with a bake layer as the BaseColor to an object. Add/Wear object Create/Apply any editable clothing/skin layer. Attempt to edit the applied layer. Note: BOM bakes and displays properly outside of Edit Layer.

As a result of the new update, the avatar does not move and with its arms open, there is no display on the screen at all

In Pony Play we have something called "Quick Jump" this is where you put a tick in the setting "Preferences > Move & View > Movement > Disable waiting for pre-jump and landing". As a ponygirl this is absolutely banned. However, I see the quick jump motion from time to time even though I don't have this option ticked. It usually happens if I'm doing a series of jumps in a row. This occasional missing of the prejump and landing animations can be seen in SL Viewer, FireStorm viewer Kokua viewer and Alchemy viewer. I see it least often when using the SL official viewer, however the fact that this occurrs in all viewers suggests it is a bug in the under lying code. Observations in the Pony community suggests that this has got much more worse since the PBR update. The time when it is seen is when you hold the jump key to do a series of jumps. This bug has also been reported in Firestorm: https://jira.firestormviewer.org/browse/FIRE-34049 Videos have been made of the motion: Not working as expected https://youtu.be/1r5fyyj847g Now working as expected https://youtu.be/5noQgxkKM7Q No change in preference were made during this test. Video recorded using Firestorm 7.1.9.74746 I repeat the same motion can be seeing using SL Viewer, Alchemy Viewer and Kokua Viewer.

when i come off my land everyone ends up all gray or deformed.

When I edit my shape and move/undo sliders, my head and body will distort and glitch. Video attached for reference.

before the 31st of Oct this bug did not appear i use an AMD Graphics card and going 1000m in all sims causes the avatar face/LelutkaHead or clothes to visually bug out with shadows

Hello. I am using one of the avatars from the welcome pack. Everytime I type in the general chat, the avatar's mouth remains opened, the animation freezes. I made many tests with one of the FS Gateway support staff member and we found no way to fix the animation. The AWP Female animation controller seems broken. Best Regards.

This is a problem specific to the old system avatars like Ruth. The Facial Definition and Body Definition layers should apply white highlights. The Rosy Complexion and Lip Pinkness layers should apply red and pink colors to the face and lips. Instead, these layers are being rendered with their colors replaced with black. Steps to reproduce: Wear the Ruth avatar from the system library (Library/Clothing/More Outfits/Ruth) Crank up Facial Definition, Body Definition, Rosy Complexion, and Lip Pinkness on Ruth's skin Ruth's skin is shaded black in spots where highlights should be, and on her lips and cheeks Additional information: These layers use grayscale TGAs as a layer mask, which are being promoted internally to four-channel textures with black fill. When the layer colors are multiplied against black, the result is black. If you replace the grayscale TGAs with four-channel versions that have a white fill color, you'll be able to see the colors render correctly on your own avatar.