🪰 Viewer Bug Reports

Create a simple cube (mesh or prim) and scale it to 0.3, 4.0, 4.0. Create another cube, scale it to 4.0, 4.0, 0.3 and place it on top of the first one. Set the sun azimuth so that it shines onto the wide side of the first cube. Move away from the objects and observe that the shadow changes; there is now a fully lit band of light directly underneath the second object. This seems NOT to be not related to: • Materials/PBR -- adding a PBR material does not change this behavior. • Geometry -- the objects are watertight. • LOD -- a mesh cube with all LODs using the full geometry behaves the same. • Physics Shape Type -- Convex Hull and Prim behave the same. I have found only two factors that affect this: Top object thickness -- the effect kicks in farther away with thicker objects. The Draw Distance -- the effect kicks in farther away with lower distances. Interestingly, moving the top object up so that there is a gap between the two object changes the behavior and reduces the effect; see the attached image. PS: I realize that this may not technically be a "light leak" -- but I couldn't think of a better term. PS 2: I have tried to think of ways of designing around the issue, but I don't think there are any realistic options. Most non-trivial structures will encounter this issue in some form or other.

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.

If you use the Replace Links feature to replace a BOM texture, the "new" texture is placed at the top of the list. Because list order is essential to the proper baking of textures, especially body and head textures, this causes every outfit to failure to bake correctly. Having searched for a global way to reorder textures (and finding none, not surprisingly) this places the user in the unenviable position of individually manually editing potentially hundreds of outfits.

Not necessarily a bug as it's likely working as "intended", but I suspect this feature might do more harm than is ideal currently. The original request for this feature was meant for those who essentially wish to opt-out of the client driving the LookAt animations for their avatar, but in its current state, residents may consider using this feature for one of the following reasons that it is not intended for. DisableLookAtAnimation: Turns off all LookAt animations locally, including those of other avatars who may actually want to use LookAt for its intended use (looking at things) DisableLookAtAnimation does NOT: Hide LookAt animations when viewed by others Prevent LookAt from being broadcast This is fine for debugging purposes, but for those meaning to use it to disable LookAt animations for their avatar permanently (including when perceived by others) it's not ideal. It also "breaks" the LookAt feature for others entirely who do intend to use it for its intended use.

We have a page that lists recent published viewers at https://releasenotes.secondlife.com/categories/viewer.html which is handy for reading old Release notes or debugging when a bug came into existence. A link to that page should be added to the sidenav of https://releasenotes.secondlife.com/ Alternately, add a link to this page from https://releasenotes.secondlife.com/index.html which already has a link to (very) old viewers.

After login or teleport, it often happens that some objects (usually large props like parts of buildings, landscaping stuff) are not displayed until I (accidently) rightclick on them. In older viewer-versions you could toggle wireframe off/on to force all objects to be shown and there are other tricks to 'unhide' those objects. That issue is well known for many years, for example, look here: https://community.secondlife.com/forums/topic/459592-problem-larger-mesh-props-remain-invisible/ and its a mystery to me why it gets no attention from the devs. Its extremely annoying, almost a showstopper for me. It just happens a lot to me, no matter what viewer I'm using (FS and LL), what PC I'm using and how fast my connection is. I'm not using any exotic hardware or settings. After almost every teleport I'm standing on invisible floors, bouncing against invisible walls and looking at party rezzed buildings.

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.

Please, make the viewer icon follow the standard size for MacOS icons.

I recently upgraded Firestorm from v6, noticed certain unicode characters in chat and hover text exhibit the bug, installed LL's viewer, saw the same issue. I was told by Monty Linden in the last server meeting to file a bug report for the viewer to get a font pack update. Here are a few out of many problem characters: [2025/04/29 05:36:35] llOrd(textbox): llOrd('🗕',0) = 128469 (0x1f5d5) [2025/04/29 05:36:46] llOrd(textbox): llOrd('🗙',0) = 128473 (0x1f5d9) [2025/04/29 05:36:51] llOrd(textbox): llOrd('🞁',0) = 128897 (0x1f781)

Log in, many of not most of the objects on my mainland estate fail to rez, requiring me to continually clear cache and relog to have an acceptable virtual experience