Viewer Bug Reports

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.

Attach a Cat Avatar to your present avatar of any kind, by left clicking on the cat you wish to attach to your avatar, using interactive KittyCats Menu. You must be the owner of the KittyCat Click Interact Click Cat Avatar Click Continue A message box pops up saying it formed a folder called "KittyCats Avatar (right click & select "Replace Current Outfit") Find the Inventory folder in Recent, highlight the folder name and right click, and select Replace Current Outfit. The SL Viewer crashes instantly with no error messages. When you relog back in, your avatar is now the KittyCat, and your prior avatar is removed except for vital parts for any SL avatar needed to form the alpha system body. This is normal. It makes no difference whether you replace your outfit as a human, or other animal such as another cat. This occurs in the SL ExtraFPS release viewer, and also in the Firestorm ExtraFPS viewer, see FIRE-35022 I have had one occasion when using the KC designed procedure for attaching a Kittycat avatar, when using a human avatar to start the transfer on a new region, there was no crash. Subsequent trials all crashed. So you should repeat this more than once to confirm this bug. Note these crashes have never occurred before, with prior viewers, based on 12 years and over 2000 cat avatar transfers via Replace Current Outfit. This is a new bug for me. https://jira.firestormviewer.org/browse/FIRE-35022

I believe the hover issue at log-in, recently solved, inadvertently changed how wearing system shoes affect the sitting height. This change makes all previously sitting z-axis adjustments (AVsitter) on countless furniture etc, completely useless ! I have a set of system shoes of varying heights, and I pick one that works for different mesh shoes. Think of it like a set of custom hover adjustments. This is desirable because system shoes gets saved with the outfit. As long as i have avatar hover at zero, all my outfits have a 'custom hover' for each of my mesh shoes. To test this, sit on something and wear system shoes, you'll see the z-axis heigh change (assuming the system shoes have suitable height saved) - take them off and the sitting height reverts. This change was inadvertent i believe, and should be rolled back/fixed.

Been testing this and its a SEVERE bug you need to handle. To reproduce 1 - Create a material. Put a ANY BAKED BOM TEXTURE (i.e. UPPER) on the BASE color slot. 2 - Create a box. Apply material to it. 3 - Pick up the box. Give it to other avatars. 4 - Avatars wear it. Result The attachment on AGENT A shows baked texture on AGENT B and vice versa. Keeps changing when zooming in and out, or if any of the agents rebakes his maps or reattaches anything. Found this happening on my avatars after updating them to BoM. But after a simple test the bug is super easy to reproduce.

I noticed such an avatar bug, when another person's avatar sits on some object, it becomes invisible, as if invisible, but when it gets up it is visible or vice versa, the same when sitting on an object

I am unable to find this retired Jira bug on Canny. Same ways to reproduce as originally reported by Whirly. https://github.com/secondlife/jira-archive/issues/491 Quote: Steps to Reproduce Bug reproduces for me whether wearing a HUD based AO or no AO. Different AO's may affect results, so if you cannot reproduce when wearing an AO, take it off. Bug always reproduces when wearing the default male/female avatar too. Groundsit by either: Using ALT+SHIFT+S Or Me -> Movement -> Sit down. Click the Stand button Observed Behaviour Avatar is always running on the spot after standing from a groundsit. See attached gif. Expected Behaviour Avatar should not run on the spot when standing from a groundsit.

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.

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.

I've had this happen twice now within the last few months. First time was when I hard crashed out after being forced Teleported from a busy region. Second time it happened simply while teleporting around. Apparently, this issue has been happening for a long while now. I've found references from other users going back to 2018. The issue does not seem to be isolated to one viewer. There are a few theories, including scripts becoming deserialized during teleport and then not reactivating once in the new region. For modifiable objects, I can toggle the scripts back to a running state manually, but all settings are reset and lost. Anything non-modifiable needs to be redelivered and replaced. Considering how many stores have closed up within the last few years replacement may not be possible. I would be happy to provide any additional information or provide more detailed time stamps to allow for a Linden to review privately.

Testing on the newest Atlasaurus build 7.1.9.10326512121 it appears the reset skeleton does not appear to be working as intended. Wear an animation that changes bone position. Remove/stop animation. Note that doing Avatar>Reset Skeleton does not reset skeleton. Doing right click on own Avatar then Reset Skeleton does reset skeleton. Also introduced with I believe Maint-C was the ability for global reset where when you reset your skeleton, other people would received the reset command as well. Tested with both people on the above Atlasaurus build this does not appear to be working where when you reset your skeleton from the right click menu, only your self resets. Others do not get the reset command.