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.

Viewers Tested: Alchemy Beta 7.1.9.2501 (64bit) Second Life Release 7.1.10.10800445603 (64bit) Firestorm 7.1.11 (76720) Nov 9 2024 02:03:12 (64bit / AVX2) All 3 of these viewers all exhibit the same issue where, if anything even a little graphically intensive starts to occur (busy sims, a second viewer is opened, this sort of thing), the viewers quickly start to flicker black across the entire viewers window, minus the windows surround and titlebar. I am currently using Firestorm 6.6.17 (70368) Dec 10 2023 18:36:33 (64bit / SSE2) as it is the latest pre-PBR viewer as my daily driver because it and any other pre-PBR viewers I try do not exhibit this issue. I don't exhibit any issues with other programs/games that I've been able to determine and you can see from the specs below I should have no problem with the requirements for PBR viewers. This issue seems to be exclusively the domain of the PBR renderer for SL as it is viewer agnostic. I have completely re-installed Windows twice both on Windows 11 23H2 and 24H2 updates, I have run memtest86 for hours with zero errors and I have borrowed my partners GPU and PSU all to no effect. I have taken videos of the issues in each browser and obtained the logs for each, however I'm unable to upload them to the ticket as the videos are too big and the logs are zipped up and that filetype is apparently unsupported so I've put them in my onedrive and attached the links below, if you'd like be to upload them elsewhere, just say where and I'll re-upload them. SL Logs: https://1drv.ms/u/s!Argy6Q-UWl9BpqdxVEIqu2sud0QkFA?e=FnChfU SL Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdubODgMVIK4RqS4w?e=hemGAv Firestorm Logs: https://1drv.ms/u/s!Argy6Q-UWl9Bpqdw0-q0kaa1AuAdvw?e=IrV7OQ Firestorm Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdsUNzCSdoVTKEh6w?e=mJDdli Alchemy Logs: https://1drv.ms/u/s!Argy6Q-UWl9BpqdvQa589QIX9y9NIw?e=a0xGcG Alchemy Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdtJcjY_gITIV70ow?e=lpmwn3

This problem started cropping up after the introduction of PBR. We have had many reports of this in Firestorm support, and it does repro on the official SL viewer. The problem generally involves letter/number displays that are scripted to change. Other parts of the object are not affected. Typically the scripted item will make its texture change, and the texture will rez, blur, rez, over and over, or simply remain in an unreadable, blurry state. Right clicking the item or putting it into edit mode will often cause the textures to completely rez. Once the item is deselected, it blurs again.

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.

Go to adjacent sim and walk on. The region textures will turn white

Blinn-Phong textures with alpha channels appear excessively transparent in the PBR client, with thinner alpha edges. Adjusting the exposure to the lowest setting or changing environment settings doesn't help. This issue affects many products, and the only solutions are to double the layer or make textures more opaque and have two versions of the same product included with the purchase. However, this causes inconsistency for users who don't use PBR, as they will see the items differently than PBR users.

Monitor the viewer logs while in world. Send a direct IM from one avatar to another Note in the viewer logs on the receiving end: 2024-11-20T17:48:05Z INFO # llmessage/llcorehttputil.cpp(275) LLCoreHttpUtil::HttpCoroHandler::onCompleted : Possible failure [Http_403] cannot POST url ' https://simhost-0a32da980e865990c.agni.secondlife.io:12043/cap/ca40190b-dd25-512f-0b89-42a749c1e4b5 ' because Forbidden 2024-11-20T17:48:05Z INFO # llcommon/llsdserialize_xml.cpp(409) LLSDXMLParser::Impl::parse : LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:You cannot join chat 2024-11-20T17:48:05Z WARNING #ChatHistory# newview/llimview.cpp(645) chatterBoxHistoryCoro : 17322f01-5b63-01b6-1788-a64d79fe7da0: Bad HTTP response in chatterBoxHistoryCoro, results: {'error_body':'You cannot join chat','headers':{},'message':'','status':i1,'success':0,'type':i403,'url':' https://simhost-0a32da980e865990c.agni.secondlife.io:12043/cap/ca40190b-dd25-512f-0b89-42a749c1e4b5 '} The viewer is requesting the chat history for this one-on-one direct IM chat, which will always fail because there is no session on the chat servers for direct IMs Better fix: don't do that

A regular texture without normal or specular maps applied to face and set to "fullbright" is rendered pretty much oversaturated when using an EEP for PBR (Reflection Probe Ambience > 0). I remember this was fixed at some point (by Runitai) in the past, but its back. You can easily notice the difference by switching between the old Midday ( RPA = 0 ) and new Midday ( RPA > 0 ). The way its rendered with the old Midday is the expected/correct behavior for regular textures applied to faces with full bright (which was fixed in the past). I'm attaching 4 snapshots... One with Midday, Another with old midday. Snapshot saved to disk compared to rendering with full bright. Processed file after Photoshop compared to rendering with full bright. See example at http://maps.secondlife.com/secondlife/Taber/110/186/3102 . ( I switched all textures on vendors to full bright to show how much they are oversaturated when using any EEP with Reflection Probe Ambiance > 0, change your EEP to the regular old Midday, you can see how they supposed to be rendered ) This was probably after the code implementing that sharpening (which is useless btw, sometimes it seems to fight with anti-aliasing in sharp edges which may show jagged.... ) and fiddling again with tone mapper. I really thought the focus was to fix bugs and improve performance.

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.