🪰 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 I zoom out far from my own avatar at a club or other texture-heavy areas, say to simply look around, when I return the camera to my own avatar a lot of the textures on my avatar - including materials - are lowered drastically in resolution and it takes the viewer upwards of 20-30 seconds before they go back to full. A resident's own avatar should never have the textures lowered in resolution unless it's specifically set in graphics > advanced, and should always take priority in staying at max quality according to graphics settings. Go to a club that is avatar heavy, so lots of textures are around - shopping events will probably work here too Wait for the viewer to load everything it can do - draw distance was 128 with textures at 2k maximum for this When your own avatar has loaded fully, alt+cam onto yourself and zoom out about half way to the clip plane - just looking around the area for a few seconds will work here too Return the camera to your avatar Lots of your avatar's textures, excluding BoM, are now super blurry, and will take ages to load back again Image 1 shows how my avatar is supposed to look > image 2 is how far I zoomed out (just across the room at this club) > image 3 shows how blurry my avatar's textures become after zooming back in, which stay like this for 20-30 seconds.

Testing PR for align planar faces for PBR materials https://github.com/secondlife/viewer/pull/5347 in viewer 26.2 it appears to only align the base color textures and not the other textures normal/ORM. Also side note reviewing the github notes it looks like it was only ever tested with a base color texture so it might be needed to add a full material (Basecolor/ORM/Emissive/Normal) to QA testing.

Using the Firestorm viewer 7.2.4 (80712) I created a New Skirt from the dropdown menu New Clothes. I wear the skirt, then when I go to edit the skirt, I immediately crash. I've tried the FS viewer and the SL viewer, and other people have not had an issue. What is causing my viewer to crash when I try to edit the skirt? I tried to upload the logs, but it says its too big.

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.

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.

I've become aware of a texture rendering issue that impacts textures when on a face. It's not so much an issue that only impacts PBR textures, but it is exponentially worse and makes certain designs as mastered in Substance unusable as PBR. I'm not enough of a rendering brain to understand what is going on here, but it's my belief this is not correct and is a bug. I hope that this will get in front of the right people to be evaluated and hopefully fixed. This is being demonstrated with a 0-25% gray bi-linear gradient, however anything that uses color and gradients near this will exhibit the same obvious defects. A single example using real-world art is included for reference. Texture UUIDs Dark gradient lossy: cac83520-08b2-500f-b683-1ede13d4e052 Dark gradient lossless: bd66f42c-6b56-780e-c183-3307151f8292 Raw files, non-anotated screenshots, and sample items shown are available upon request but I don't think they will be necessary. As I was sharing this around with creator friends moments before submitting this I was made aware this may be or have been a known bug, and can be alleviated entirely on the material side by setting the alpha mode selector to blended. Masked and opaque do still exhibit the shown issues. This made me frown. There is no alpha channel on the textures shown.

I open profile yourself tab view Feed or from people to check view tab Feed same text issues cant see and cant upload photo share Feed profile...

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.

i needed to export my project, and noticed that since a week now some scripts simply refuse to export, it does not appear to effect all scripts however the more lines, the more likely a fail, there is no error either, not in the viewer or windows error logging, tried error tracing as well, the server doesn't appear t answer back with a file to save. attempted to reproduce with multiple viewers and 2 different pc's.