Bug Reports

Each player's voice chat stutters (barely understandable). There are also connection problems when entering a world. All systems outside work perfectly: No network issues, no hardware issues, no software issues. In-game sound also works, only the voice chat stutters.

Go to a video player world and it gives an error

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.

Basically every time I attach an image or a message to an invite, the preview doesn't update to reflect those changes until I open the message menu a second time. I don't have time to collect media or write a proper description for this but wanted to report it regardless.

This behaviour is inconsistent with the Main Menu, which takes precedent of the cursor over personal mirrors that are closer to the player than it. Some simple repro steps: Enable immersive mode in personal mirror settings (so that it uses a pointer rather than grab highlight). Open the personal mirror. Bring the personal mirror close enough to you that it's in front of where your Main Menu would appear. Open the Main Menu. Attempt to navigate. Notice that the user is able to interact with the Main Menu just fine despite the personal mirror technically being "in front" in physical space. Open the chatbox keyboard. Attempt to navigate. Notice that the user is unable to naturally interact with the chatbox keyboard, because the pointer is hitting the personal mirror before reaching the keyboard. This is frustrating because I will sometimes assume that doing this is okay because it's fine for the Main Menu, only to remember it isn't specifically for the chatbox. So I have to close the chatbox, close my mirror, then begin typing again to be able to properly use the keyboard. I don't have time to collect media for this but wanted to report it regardless.

An artist named TuxedoPato (Martin, https://x.com/TuxedoPato ) is currently developing a custom locomotion animation set for VRChat. During testing, we encountered a significant issue: the animation behaves differently on the local machine compared to how it appears to remote users. Specifically, the remote version appears unnaturally smoothed, losing much of its intended nuance. We conducted several tests to isolate the problem. Below are key findings and comparisons: Animation complexity directly affects the severity of the issue. Simpler animations show minimal discrepancy, while more intricate ones suffer noticeable degradation. We tested three locomotion sets: - Studio Moca’s Standard Motion for Women ( https://moca-studio.booth.pm/items/5064825 ): Minimal quality loss, likely due to its relatively simple movement. - VRSuya’s Wriggling Locomotion ( https://vrsuya.booth.pm/items/4995578 ): Exhibited moderate degradation, especially in its exaggerated, erratic motions. I also discussed this with the creator, Levin, who confirmed similar concerns. - TuxedoPato’s Custom Animation: Experienced the most severe quality drop. It features numerous subtle movements and a complete overhaul of the locomotion system, making the smoothing effect particularly disruptive. Additionally, we observed that animation fidelity is significantly better in VR mode compared to Desktop mode, where the degradation is much more pronounced. This leads us to suspect that the issue may be tied to VRChat’s polling rate, server tick rate, or network layer behaviour. It appears that locomotion animations are being transmitted over the network rather than executed locally on each client. Despite extensive testing, we were unable to bypass this network behaviour. Several community members echoed our findings, noting that animation data seems to be filtered or compressed during transmission—despite the fact that such data arguably shouldn’t require network mediation at all. At this point, we’ve reached our limit. We’re hoping for insight into whether this behaviour is intentional, a side effect of network optimization, or a bug in how locomotion animations are handled across clients. For testing purposes please check the following avatars that have the locomotion created and setup for your convenience. Full version Locomotion test (walk, run, crouch, crouch run, prone, idle jump, crouch jump, prone jump). https://vrchat.com/home/avatar/avtr_d794808e-6321-400e-b010-8ac9261b9c9f Stripped down version (walk, run, idle jump). https://vrchat.com/home/avatar/avtr_ade7fbe1-707e-4a22-82d5-05e6de7baeac Stripped down version of the locomotion system is downloadable from the link below. This file is stripped down and simplified heavily to narrow down the scope and reduce errors from other factors. https://drive.google.com/file/d/1xRSV3HTQQEBWUAy2_jLnRODdlcQnzM2t/view?usp=sharing Video example between local and remote users. https://youtu.be/86a_RUFllxY

Some simple notes about this issue: This issue doesn't always occur, but when it begins occuring, it continues to happen consistently until the player moves/the chatbox is moved/a new world is loaded before occuring again later. I think this might occur when there's a canvas behind the keyboard that the pointer is attempting to reach from between the keys but I'm not 100% sure. This issue might be influenced by dynamic/grabbable and unlocked menu options being enabled. This issue might be influenced by the keyboard being tilted/facing a weird angle as I often encounter this when typing while lying down. This issue may be influenced by the use of horizon adjust, as I also use this often. I don't have time to collect media or write a proper description for this but wanted to report it regardless.

Hi, Unsure if you're currently tracking this internally: https://github.com/yt-dlp/yt-dlp/issues/14404 Quoting the linked issue: """Beginning very soon, you'll need to have Deno (or another supported JavaScript runtime) installed to keep YouTube downloads working as normal. Why? Up until now, yt-dlp has been able to use its built-in JavaScript "interpreter" to solve the JavaScript challenges that are required for YouTube downloads. But due to recent changes on YouTube's end, the built-in JS interpreter will soon be insufficient for this purpose. The changes are so drastic that yt-dlp will need to leverage a proper JavaScript runtime in order to solve the JS challenges. """ This will almost certainly affect the VRC builds of yt-dlp.

The ‘Dynamic’ Forced Camera Near Distance mode has been billed as a solution that “ avoids most but not all problems ” with having a very small near clip distance. However, in my experience, the Dynamic mode actually causes problems with the far clip plane remarkably often . Crucially, it causes these problems in worlds that have quite modest far clip planes to begin with, and worst of all, it often causes problems in worlds where the author has carefully set a far clip plane that is just right for their specific content. Two Example Worlds I used DebugAvatar by ScruffyRuffles to discover the author-set far clip plane, and also measure the observed far clip distance with different Forced Camera Near Distance settings in these worlds: The Nestled Glade Background forest cards get clipped from various viewpoints with Dynamic mode. Author’s far plane: 700 m Measured far plane (Off): 693 m Measured far plane (Dynamic): 531 m Measured far plane (Forced): 531 m Inner City Backstreet At spawn, skyscrapers and atmospheric glow get clipped with Dynamic mode. Author’s far plane: 1200 m Measured far plane (Off): 1180 m Measured far plane (Dynamic): 787 m Measured far plane (Forced): 683 m I think these results demonstrate that setting the near clip plane to a very small value causes the observed far clip distance to be reduced in peculiar ways, even though the far clip plane was supposedly not altered in Dynamic mode. (Please comment if you have any insight as to why this peculiar behaviour occurs.) Two Solution Ideas 1. Add a ‘Conservative’ Forced Camera Near Distance mode This would be similar to the existing Dynamic mode, but use more conservative values, such as: Either target a near clip plane of 1 cm (0.01 m) instead of the current 1 mm (0.001 m) Or use a factor of the far clip plane equal to one hundred thousand (100,000) instead of the current one million (1,000,000) This conservative mode would be much more suitable for most VRChat users with average-sized avatars (1 meter or taller). In my experience, a near clip plane of 1 cm is close enough for head pats and cuddles when using typically scaled avatars. I want a setting that I can set and forget ; a setting that will do its best to reign in the near clip plane while reliably maintaining the world author’s far clip plane. The Dynamic mode’s near clip target is too aggressive, and the default near clip plane of 5 cm is too relaxed. I’m tired of having to switch between Dynamic and Off so often. 2. Research ways to make the current Dynamic mode more robust As noted earlier, when you set a very small near clip plane, it appears that the observed far clip distance is significantly reduced below its programmatically set value. By testing many scenarios, it might be possible to figure out a pattern for this behaviour and establish a ‘magic number’ to counteract it. Let’s say, for example, that we use 1.4 as our magic number. The new behaviour for the Dynamic mode would be as follows: Multiply the author’s far clip plane by 1.4 and set it as such. For Nestled Glade, this would be: 700 x 1.4 = 980 For Inner City Backstreet, this would be: 1200 x 1.4 = 1680 Set the near clip plane within a factor of one million of the new far clip plane. For Nestled Glade, this would be: 980 / 1000000 = 0.001 (result clamped) For Inner City Backstreet, this would be: 1680 / 1000000 = 0.002 (result rounded up) Hopefully, by increasing the far clip plane in this way, it would counteract the peculiar reduction, and the observed far clip distance would end up about the same as the author’s originally intended setting. This is especially important for worlds where the author has carefully set a far clip plane that’s just long enough to encompass the longest sight line, but neglected to set the near clip plane to 0.01.

A new instance should not be considered to be renamed before it is ever joined. A new Group/Group+ instance being created for the first time is unable to be named using the VRC+ exclusive naming system, as the instance is considered to be "renamed" at that point (see "Instance rename failed" in the screenshot. This means that my group members are unable to create new named instances (despite subscribing to present a named lobby) without being able to also close any group instance. This is the only relevant permission, which affects all instance types for that group: Manage Group Instances Allows role to rename or close a group instance.