Bug Reports

  • No off-topic posts
  • Don't report more than 1 issue at once
  • For isolated issues or customer support visit help.vrchat.com
Thanks for your bug report!
Severe Cursor Jitter on World UI Elements When "Forced Camera Near Distance" Is Enabled at Long Distances from World Origin
Affected Versions: Live and Open Beta (All Worlds) Platforms: Occurs in both Desktop and VR modes Summary: Cursor movement becomes unstable and jittery when interacting with UI elements in worlds located far from the Unity world origin (0,0,0), specifically when “Forced Camera Near Distance” is set to either Dynamic or Forced . The issue persists even after a full VRChat reinstallation and clearing of all local data. Description: When “Forced Camera Near Distance” is active, UI interaction (via raycast) experiences significant jitter proportional to the player's distance from the world origin. At approximately 500m from (0,0,0), the jitter becomes noticeable, and by 1000m+ it becomes severe enough to make UI interaction nearly impossible. Additionally, mild cursor snapping occurs on some VRChat system menu interfaces (less critical, but possibly related). Steps to Reproduce: Load or create a world containing a UI canvas (using vrc_ui_shape) positioned at least 800m from the (0,0,0) coordinate. Teleport the player to the UI location. In the VRChat settings, set "Forced Camera Near Distance" to either "Dynamic" or "Forced". Attempt to interact with the UI — observe severe cursor jitter on new raycast/movement. Observed Behavior: Cursor jitters heavily on UI elements. The effect intensifies with increased distance from the world origin. Example: At position (0,0,2000), jitter is extremely pronounced (see attached video). Expected Behavior: Cursor should remain stable and accurately track raycast movement regardless of distance from the world origin or camera near-distance settings. Workaround: Setting "Forced Camera Near Distance" to "None" eliminates the jitter almost entirely.
1
·

tracked

Hidden Avatars Not Displayed Correctly
I always play Murder 4 in public instances, and I often encounter cheating or hacking. Recently, I started seeing cases where players use invisible avatars while holding knives or revolvers. However, after investigating, I found that these were not cheats, but rather a bug in VRChat. I first encountered this bug about 1–2 weeks ago. At that time, a player who was the Murderer stood still at the entrance to the cellar but was remotely killing Bystanders with the knife. I was convinced it was cheating, but surprisingly, no one else seemed to suspect that player. Out of curiosity, I unhide that player’s avatar, and suddenly their avatar disappeared from in front of me. Then, I saw them walking around elsewhere in the world, fully visible. In other words, this bug can be described as: “When a user’s avatar is hidden, it is not displayed correctly.” The player’s movements and interactions (such as holding a knife or firing a revolver) are processed globally as normal. However, the hidden avatar itself remains stuck at a fixed point in the world locally instead of following the player’s actual movements. Put simply, the “internal” state (user interactions) and the “external” state (avatar position and hitbox) become desynchronized. For details, please see the attached video. https://drive.google.com/file/d/13eUVpceSsPTjAfKH3dYgLJj2yXNXwpVO/view?usp=drive_link This bug is having a severe impact on game worlds like Murder 4. For example, imagine you are the Murderer and must eliminate all other players. If a user with a hidden avatar is stuck in the lobby, which is outside the play area, their avatar and hitbox remain there—but their actual player is still participating in the game. This means they can shoot you with the revolver, yet you cannot stab or eliminate them, because their avatar and hitbox remain in the lobby. This creates an unwinnable situation. I have personally lost over 5 games due to this bug. Since I only play Murder 4, I have not tested other game worlds, but I believe this issue likely occurs elsewhere as well. In fact, since this is a VRChat-level bug, it can happen in any world as long as there are users whose avatars are hidden. To clarify, this is not a bug specific to Murder 4. Murder 4 has not been updated in the last 1–2 weeks, so it is natural to conclude that the bug lies in VRChat itself. Even if Murder 4 did have issues, it would be unlikely that the Hide/Show Avatar feature of VRChat itself would malfunction in this way. This is a critical bug that can make gameplay impossible. The cause should be identified and fixed immediately, and measures should be taken to ensure it never happens again.
11
·

tracked

‘Dynamic’ Forced Camera Near Distance not working as intended
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.
1
·

tracked

Load More