Bug Reports

When Collision Mode was set to "Hit Players" or "Hit Worlds And Players," my own avatar was hit, but other players' avatars were not. When using "Hit World" or specifying "Pickup" in "Hit Custom Layers," the target was hit correctly. Do other players' avatars also need to be running SDK 3.10.3?

When stretching or squishing a physbone that has angle limits applied, the physbone will still stretch and squish based on the direct distance from your hand to the physbone, even if the physbone cannot move in that direction due to angle limits. This results in physbones that can be stretched downward while being pulled upward, for example. The expected behavior is that physbone stretch and squish are applied with a weight based on the difference between the angle of the physbone and the angle of the direction from the physbone to the hand when the physbone is meeting the angle limit. For example, a physbone with an angle limit of 0, when pulled at a 45º angle to the physbone, should be stretched to sin(45) in degrees. I've attached diagrams for current and expected behavior, The blue is the physbone at rest, green is the stretched physbone, and magenta is the player's hand + distance from the first bone.

When reporting someone's print while in VR, tooltips don't seem to work. So when wanting to see who printed said print while not having physical access to it, you can't see who printed it. But the tooltip works on desktop mode.

The number of animation layers heavily affects performance due to unnecessary inverse kinematic calculations. Even blank animation layers with zero weight in the FX layer can trigger this behavior. The offender is seen in the profiler as Animators.IKAndTwistBoneJob. It runs as many times as the currently loaded animation controller with the largest number of layers. Although the individual run time is small, they very quickly add up. Slower CPUs seem to be more adversely affected by this. The time taken by these extraneous calculations quickly grows larger than all normal animator activity. This behavior only happens on animators that have a unity avatar/armature. When that is removed, this behavior goes away and the number of layers ceases to be a significant cause of lag. Most FX layers do not have any interaction with the armature, so it is likely that this behavior can be fixed for almost all FX layers. However from debugging the unity editor in visual studio, it appears the this happens in a native unity function named Animator::UpdateAvatars. It is likely that in most if not all cases, these calculations are completely wasted on FX layers and provide no benefit at all while consuming significant amounts of main thread time. Somehow these calculations need to be only run for layers that require them. Additionally providing a way to get parameters in sub animators would allow logic to be moved out of the main animator completely sidestepping this problem. They would not have a unity avatar associated with them, so this problem would not occur. It would also allow completely disabling animators when not in use. Please attempt to find a way to prevent this behavior or consider convincing your Unity contacts to implement a fix. This seems to be one of the largest contributors to animator lag. I have a full write-up with more profiler images and further explanations. https://docs.google.com/document/d/1SpG7O30O0Cb5tQCEgRro8BixO0lRkrlV2o9Cbq-rzJU

The Video Player has accumulated quite a few small bugs and inconveniences over time. If technically possible, I would greatly appreciate it if these issues could be addressed. --- Black Flickering Issue with AVPro Player This problem started occurring shortly after the switch to Unity2022. The latest versions of iwaSync and YamaPlayer include their own workarounds, but older versions of iwaSync/YamaPlayer (when using AVPro) as well as players without custom fixes such as TopazChat Player still suffer from black flickering. --- Video Stuttering During RTSP Playback in Specific Conditions Especially in crowded instances on lower-spec PCs, When streaming RTSP at 60fps while VRChat is running at around 20fps, the video becomes noticeably choppy. Although switching the RTSP stream to 30fps currently avoids the issue, many users set OBS to 60fps because the TopazChat Player distribution page states that 60fps minimizes audio delay. --- Request to Move Video Player Processing to a Separate Thread Especially in crowded instances on lower-spec PCs, video playback often freezes for a moment due to various other processes. With RTSP streams, these interruptions cause playback delay to accumulate. The main causes include: Loading process when someone joins or when an avatar is changed Photo capture processing Display/hide toggling when culling is enabled Loading of stage effects on world VRChat's current CPU processing relies heavily on specific thread performance. On modern CPUs, specific thread often maxes out at 100% usage while the remaining threads (including E-cores and CCD1) stay underutilized. Separating the Video Player's processing into its own unrelated thread could potentially resolve these stuttering and lag issues. It may also allow better utilization of currently idle CPU cores.

I run an event that fills up pretty quickly once we announce that guest doors are open. We open the the instance as a group instance with instance queue enabled. After we get all of the staff into the world for the event, we announce on discord and in group pings that the instance is now open for guests to join. Guests should be joining and starting up a queue at the announced time. What they can currently do is use the "Show Go Button on Load" setting to preload the world and reserve their spot in the instance. We can't tell what guests are doing this because they don't load into the world, we have no idea who hass connected early. They simply join the world with everyone else once the ping has gone out. You can test this easily with 2 other people. 1) Create a group instance with a queue for a world with 2 max slots. Just the two of us works well. 2) Have the instance owner join first and load into the world. 3) Have the person who will use the "Show Go Button on Load" join the instance, but not press the join world button. At this point, the person inside the instance does not see anyone else in the world. The person in the load screen has reserved their spot in the world. 4) Have a third person attempt to join the instance. They will either be placed in queue, or receive an error related to needing to join a queue but it will not place them in a queue. From the perspective of the person inside the instance, no one has joined. The third person cannot join the instance and MAY be able to queue. The second person that is waiting to join can join freely at any time. I do not know how long this instance slot reservation lasts, but it is causing significant issues with group instances with queues.

There is an inconsistency in how x.com social links are handled between the VRChat website and the in-game client UI. While the website correctly identifies x.com links and shows the X/Twitter logo, the in-game UI fails to do so, displaying a generic link icon instead. Links using the older twitter.com domain display correctly in-game. In-Game ( x.com ): Generic link icon displayed. In-Game ( twitter.com ): Correct X/Twitter icon displayed. Website ( x.com ): Correct X/Twitter icon displayed. The VRChat client UI should be updated to recognize the x.com domain and display the associated X/Twitter social icon for user-added links, matching the functionality of the VRChat website.

Video players in VRChat are failing to play YouTube web,web_safari 1080p formats and are falling back to android_vr extractor for a premuxed 360p format ( -f 18 ). This is because yt-dlp 2026.03.03 has a broken web,web_safari extractor which returns The page needs to be reloaded. errors. As a result, the video quality of YouTube videos in VRChat is worse than usual (360p). Expected behavior: 1080p web_safari formats (M3U8), 1080p YouTube video playback in VRChat video players. (IIRC, a M3U8 playlist format is playable in VRChat.) Fallback to 360p android_vr formats in VRChat for YouTube playback in case web_safari breaks in the future. Actual behavior: 1080p web,web_safari unavailable, fallback to 360p android_vr formats in VRChat for YouTube playback. Test URL: https://www.youtube.com/watch?v=kEAC8eeQWcg (A soothing AI reads stories to you in Thad Tiny Library by Thad Gyther) Diagnosis: https://ask.vrchat.com/t/avpro-player-vizvid-plays-low-resolution-yt-videos/48357/4 Bug resolution: Update VRChat's yt-dlp fork to the latest stable yt-dlp release, in this scenario 2026.03.17 (yt-dlp-ejs 0.8.0). 1080p web_safari M3U8 formats are available there. Steps to reproduce: PS C:\Users\linda.LINDALAP\AppData\LocalLow\VRChat\VRChat\Tools> .\yt-dlp.exe --version 2026.03.03 PS C:\Users\linda.LINDALAP\AppData\Local\Temp\yt-dlp_upstream_2026.03.03> .\yt-dlp.exe --extractor-args "youtube:player_client=web_safari" -F https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] Extracting URL: https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] kEAC8eeQWcg: Downloading webpage [youtube] kEAC8eeQWcg: Downloading web safari player API JSON ERROR: [youtube] kEAC8eeQWcg: The page needs to be reloaded.. The page needs to be reloaded. Deno version 2.7.13 is installed for JS player formats with winget install DenoLand.Deno for testing. Upstream yt-dlp 2026.03.17 used for testing from: https://github.com/yt-dlp/yt-dlp/releases/tag/2026.03.17 PS C:\Users\linda.LINDALAP\AppData\Local\Temp\yt-dlp_upstream_2026.03.17> .\yt-dlp.exe --version 2026.03.17 PS C:\Users\linda.LINDALAP\AppData\Local\Temp\yt-dlp_upstream_2026.03.17> .\yt-dlp.exe --extractor-args "youtube:player_client=web_safari" -F https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] Extracting URL: https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] kEAC8eeQWcg: Downloading webpage [youtube] kEAC8eeQWcg: Downloading player 8456c9de-main [youtube] [jsc:deno] Solving JS challenges using deno [youtube] kEAC8eeQWcg: Downloading m3u8 information [info] Available formats for kEAC8eeQWcg: ID EXT RESOLUTION FPS CH │ FILESIZE TBR PROTO │ VCODEC ACODEC ASR MORE INFO ────────────────────────────────────────────────────────────────────────────────────────── sb3 mhtml 48x27 2 │ mhtml │ images storyboard sb2 mhtml 80x45 1 │ mhtml │ images storyboard sb1 mhtml 160x90 1 │ mhtml │ images storyboard sb0 mhtml 320x180 1 │ mhtml │ images storyboard 91 mp4 256x144 30 │ ~ 1.21MiB 170k m3u8 │ avc1.4D400C mp4a.40.5 93 mp4 640x360 30 │ ~ 4.98MiB 696k m3u8 │ avc1.4D401E mp4a.40.2 18 mp4 640x360 30 2 │ ≈ 3.64MiB 510k https │ avc1.42001E mp4a.40.2 44k 360p 300 mp4 1280x720 60 │ ~25.50MiB 3566k m3u8 │ avc1.640020 mp4a.40.2 301 mp4 1920x1080 60 │ ~39.47MiB 5518k m3u8 │ avc1.64002A mp4a.40.2 Fixes: https://feedback.vrchat.com/feature-requests/p/update-to-yt-dlp-20260313-yt-dlp-ejs-070-to-improve-youtube-playback-compatibili Screenshots: 360p in VRChat (world: Coze Isle by Shinyflvres), 1080p in YouTube web browser.

Reopening https://feedback.vrchat.com/bug-reports/p/local-players-dont-cast-shadows-caused-by-lights-in-avatars-on-cameras Expected behavior Objects comprising local players cast shadows in cameras similar to a player's view. Actual behavior Objects comprising local players do not cast shadows on cameras. "Cameras" means both photo camera and Camera components in avatars. Description / How to reproduce 1. Open test world I prepared a world for testing culling behavior: https://vrchat.com/home/world/wrld_8d64c603-280f-4dd9-811e-d1db875676ad This world contains spheres for each layers. (see also: https://feedback.vrchat.com/bug-reports/p/culling-mask-for-lights-in-avatars-modified-unexpectedly ) 2. Switch to the test avatar Switch to the test avatar that has a light with shadow. 3. Check casted shadow In the first-person view, the sphere in PlayerLocal layer is casting shadow. In the camera view, the sphere in MirrorReflection layer should cast shadow but actually not. It is tested with world object for easy observation, but meshes in the local avatar behaves similarly. Environment VRChat build 1392

Summary Since around February 28, 2026, connecting through Cloudflare WARP (VPN mode) prevents logging in or properly using VRChat across all platforms — the website, Unity SDK, and the VRChat client app. This is problem, because VRChat's own help pages explicitly state that Cloudflare WARP is allowed: > "As a last resort for connection issues, try using a VPN. Cloudflare's WARP is allowed , but some other VPNs may be blocked." — VRChat keeps crashing or has issues launching properly > "Try using Cloudflare's WARP tool"— Troubleshooting Connection Issues with VRChat Symptoms (all with WARP enabled) 1. VRChat Website ( vrchat.com ) Login appears to succeed momentarily, then immediately redirects back to the login page. This loops indefinitely. (recording attatched to this post) 2. VRChat SDK (Unity Editor) Login fails with the following errors: (screenshot attatched to this post) - Unauthorized, try logging out and in again - "Missing Credentials" - NullReferenceException at VRCSdkControlPanelAvatarBuilder.cs:1491 Stack trace points to VRCApi.cs:288 in MakeRequestWithResponse 3. VRChat Client App (PC) Login itself succeeds. Immediately placed in the Error World. Cannot navigate to any other world — always sent back to Error World. VRChat is effectively unusable. All three services work normally when WARP is disabled. WARP was working fine with VRChat until approximately February 26, 2026. This timing coincides with the API and Social/Friends List maintenance on Feb 26–27 (per https://status.vrchat.com ). Why This Matters: Many Users Need WARP Many users, including myself, rely on Cloudflare WARP because without it, VRChat times out when loading other players' avatars , making multiplayer sessions impossible. The symptoms without WARP: Avatar loading for other players stalls completely → other players' movement/voice freezes → timeout → "VRChat is not responding" Occurs reliably with 10+ players in an instance; does not occur when alone Own avatar loading and world loading are unaffected This is a well-documented, long-standing issue reported by many users (see Related Reports below) The current situation means VRChat is completely unusable either way: WARP off → avatar loading timeouts in any populated instance WARP on → cannot log in / stuck in Error World Environment OS: Windows 11 Home CPU: 13th Gen Intel Core i7-13700F GPU: NVIDIA GeForce RTX 4070 RAM: 32GB ISP: Katch Network (Japan) Connection: Wi-Fi VRChat Build: Build ID 22116304 VRChat SDK: 3.10.0 Unity: 2022.3.6f1 Cloudflare WARP: 2026.1.150.0 (VPN mode) Attachments Video: Website login loop (to be attached) Screenshot: Unity SDK "Missing Credentials" error (to be attached) Related Reports WARP/VPN connection issues (same or similar problem): "World is incompatible with current platform" when using VPN and Cloudflare Warp Connection issues through Cloudflare's WARP Avatar loading timeout (the reason WARP is needed): Connection timed out or VRChat stopped responding error (too often) Recent increase in timeouts, disconnected, and not responding messages Frequent disconnections Connection Issues to VRChat (Possible Routing Problem to Photon Server) VRChat connection interrupted while downloading Avatars/Worlds Update: Output log analysis I compared output_log.txt captured with WARP ON vs WARP OFF. With WARP ON, every API call after login is rejected with 401 "Missing Credentials". The log reveals the reason: "authToken doesn't correspond with an active session" — and the source IP address (Cloudflare WARP IPv6) changes between requests. This may mean VRChat's API is binding sessions to IP addresses, but WARP rotates its exit IP on every request, so the server treats each subsequent call as an invalid session. This session-IP validation likely became stricter with the Feb 26–27 maintenance, as the same setup worked fine before that date. I have submitted a support request with full output log and details on VRChat Help Desk.