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.

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

Clip Demonstrating Behavior: https://youtu.be/LuTbgsij74M Additionally, it appears that the texture alignment overlay is always tied to the transforms of the Blinn-Phong material. To Reproduce: Rez two prims and place them next to each other. Place a glTF material on adjacent faces on prims. Set texture mode to Planar Ensure both texture transforms of both faces do not match. Click Align Planar Faces Checkbox

The viewer tends to crash, mostly after a moment when the app is on the background. It seems related to llvertexbuffer The same is happening on multiple Mac configurations Here is a partial crash log: Thread 0 Crashed:: Dispatch queue: OpenGLMT 0 <translation info unavailable> 0x10c14f978 ??? 1 libsystem_platform.dylib 0x7ff80361beb3 _sigtramp + 51 2 AppleMetalOpenGLRenderer 0x123ec49b3 GLDContextRec::testFence(GLDFenceRec*, int) + 27 3 GLEngine 0x7ffa21b5c76e gleTestSync + 149 4 GLEngine 0x7ffa21acd471 glWaitSync_ListExec + 22 5 GLEngine 0x7ffa21b4e80a gleCmdProcessor + 80 6 libdispatch.dylib 0x7ff80343f7e2 _dispatch_client_callout + 8 7 libdispatch.dylib 0x7ff80344c8f2 _dispatch_lane_barrier_sync_invoke_and_complete + 60 8 GLEngine 0x7ffa21abd580 glDeleteBuffers_ExecThread + 25 9 Second Life Release 0x103ef5e08 delete_buffers(int, unsigned int*) + 392 10 Second Life Release 0x103efbec6 LLAppleVBOPool::free(unsigned int, unsigned int, unsigned int, unsigned char*) + 54 11 Second Life Release 0x103ef5040 LLVertexBuffer::~LLVertexBuffer() + 176 12 Second Life Release 0x103ef570e LLVertexBuffer::~LLVertexBuffer() + 14 13 Second Life Release 0x1028ba2cf LLPointer<LLVertexBuffer>::unref() + 79 14 Second Life Release 0x103ea8bbd LLFontVertexBuffer::reset() + 77 15 Second Life Release 0x103f2738d LLComboBox::setCurrentByIndex(int) + 221 16 Second Life Release 0x103f266bc LLComboBox::add(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, EAddPosition, bool) + 236 17 Second Life Release 0x102f68c91 LLFloaterTools::updatePopup(LLCoord<LL_COORD_TYPE_GL>, unsigned int) + 1281 18 Second Life Release 0x103a18673 LLViewerWindow::updateLayout() + 307 19 Second Life Release 0x103a15cac LLViewerWindow::updateUI() + 11532 20 Second Life Release 0x102a1d5a9 LLAppViewer::idle() + 1561 21 Second Life Release 0x102a1b89e LLAppViewer::doFrame() + 1918 22 Second Life Release 0x102a1acc7 LLAppViewer::frame() + 55 23 Second Life Release 0x1029c5fcf -[LLAppDelegate oneFrame] + 15

* Details When chatting, received Japanese messages are sometimes garbled. Garbled messages will display correctly when you select the string. However, if the selection is deselected, the string reverts to a garbled state. If the chat window is closed and reopened, the garbled text will not display properly. Receiving other messages may cause garbled messages to appear normal. * Steps to Reproduce We do not know if this phenomenon occurs only in Japanese or in other languages as well. Also, the only known way to reproduce it is to keep chatting for a long time (more than about 30 minutes). This is only happening with ExtraFPS, not with viewers up to DeltaFPS. There seems to be a problem with the processing changed in ExtraFPS.

Group notices that are received before any group chat window for that group has been opened get logged into "group_name.txt" instead of "Group Name (group).txt". Once you open the chat session they are logged into the correct file together with the group chat. Possible reproduction steps: Receive a notice (either on login or later) Open the group chat Receive another notice Both notices are logged into different files.