Bug Reports

PhysBone freezes if parents scale is zero on enable then become non-zero, and isAnimated is set to false. Summary A PhysBone will become frozen (does not sway and unable to grab) if the all of the following conditions are met: The parent of the PhysBone has a scale of zero when the PhysBone become enabled, and then scale is set to non-zero. The Is Animated option is set to false. Details First of all, The documentation of PhysBone does not mention that PhysBone will freeze in some cases. Therefore, freezing is not expected behavior (for us). Secondly, the documentation of Is Animated option says: > Allows bone transforms to be animated. Each frame bone rest position will be updated according to what was animated. This must be enabled in order for any bone in the PhysBone chain (Root bone included!) to respect animations applied to it. Therefore, there is no mention for parent scale or any other behavior related to Is Animated flag, and there is no mention for freezing. If both or either of the behaviors are expected, please update the documentation to mention that. Steps to reproduce this gist is a minimal assets to reproduce the issue. Download the zip and unzip it to anywhere in Assets, then open the Test Scene.unity . You'll see single Avatar with a PhysBone with Is Animated set to false under "Parent" GameObject, and an "Indicator" that shows the "Angle" Animator Parameter of the PhysBone. Set the "Is Animated" of the PhysBone to false. Select the "Parent" GameObject and set the scale to (0, 0, 0), and make it inactive (uncheck the checkbox). Enter Play Mode. Activate the "Parent" GameObject. (This will also make the PhysBone enable) Set the scale of "Parent" to (1, 1, 1). Problem 1: The "Angle" parameter of the PhysBone become 0.5 and will not change. Problem 2: When you try to grab the PhysBone on the scene view, it will not able to grab. When you set the "Is Animated" to true, both problem will not happen. When you enabled the PhysBone after setting scale to 1,1,1 (swapping step 4 and 5), both problem will not happen.

The Forced Camera Near Distance setting is inconsistent with the value shown in the menu and the value actually applied. For example, the setting may appear to be Off, but Forced is actually applied, or vice versa, the setting may appear to be Forced, but is actually Off. The result seems to be different when switching with the right arrow and when switching with the left arrow.

Some of you may have recived this error "[Disconnected] VRChat is not responding." or "[Disconnected] Your connection has timed out." every few minutes or so. The experience you will have is one way trafic from VRChat to you but you stop sending to VRChat. Example: You are talking to a freind, And they ask you a question. You answer their question and they say "hello? you still there?" with in a few seconds of them saying that you get the error. The most likely reason for this is due to a thing called route changes. Route changes is when your ISP changes ISPs internally giving you a new/better route online. These are normal and a often occurrence. But for those who have wireless internet your route may change constantly (Starlink and Verizon are two well known companies who do this) No matter if you follow VRChats troubleshooting steps you will run into the same issue even with Cloudflare warp. A theory I had is that VRChat servers don't accept a different IP in the route causing the client to "retry" but the mapping back to your IP does not change (They can send through different routes and not care because they wont see that packet) In one instance, I received a "[Can't Travel] You are not allowed to travel to that location. (Code: 403) [Okay]", a "[Disconnected] VRChat is not responding. [Okay]" error, and an ISP induced route change at the same moment. Sometimes I would hear multiple ping sounds when disconnecting and it kind of hurts the ears. (>o<) If VRChat would like to have all the little details that I gathered please message me and I will send graphs and data of what's gathered. If anyone has any questions or ideas please list them below.

When using the ATOK IME (Input Method Editor) for Japanese input in VRChat, the Easy Anti-Cheat (EAC) system blocks the "ATOK35DE.DLL" file, making it impossible to type in Japanese. This issue occurs consistently and prevents users from communicating in Japanese within the game. Switching to another IME, such as Microsoft IME, may resolve the issue temporarily, but ATOK users face significant inconvenience due to this incompatibility. an IME is software commonly used in non-English speaking regions to input complex characters like kanji, hiragana, or katakana. In Japan, ATOK is a widely used alternative to Microsoft IME. However, EAC appears to misidentify certain DLLs associated with ATOK as potentially harmful or unapproved, leading to this problem. Please investigate whether this is a false positive by EAC and consider allowing ATOK's DLLs to function properly within VRChat. This would enable Japanese users to communicate effectively without switching IMEs or encountering errors. If additional details are needed, feel free to ask!

When using Horizon Adjust in combination with Height Adjust, changing worlds or switching avatars causes Height Adjust to revert to default. ~Steps to Reproduce~ Enable Horizon Adjust. Use Height Adjust to raise yourself higher. Change to a different world or switch to another avatar. In my use case, while lying down and using Horizon Adjust and Height Adjust, whenever I switch worlds or change avatars, Horizon Adjust persists but my height adjustment resets and I'll be in the ground.

A considerable amount of playback failures in VRChat is reported by players in Japan, within the week. Some claimed to resolve the problem by either disabling IPv6, or using a proxy service e.g. Cloudflare WARP. Essentially people are being banned as a bot using yt-dlp via VRChat. I wonder if VRChat can allow players to pass certain arguements to yt-dlp to provide their cookies (--cookies) or disable IPv6 (-4) Because to my observation, it does not work even if you create yt-dlp.conf in %userprofile% or the same folder with the yt-dlp.exe installation under VRChat.

Open a profile Log Snippet (output_log_2025-04-28_13-44-33.txt): 2025.04.28 21:04:10 Debug - [API] Requesting Get users/usr_40be82e7-f7d5-4548-b314-3fc7b26d22ee/groups/permissions {{"groupIds":"grp_29a2a427-c09e-47ef-9818-f45781980e9f, grp_bad8ba0b-34cf-4ea3-8680-c99f5f980783"}} retryCount: 2 2025.04.28 21:04:10 Debug - [API] [1820] Sending Get request to https://api.vrchat.cloud/api/1/users/usr_40be82e7-f7d5-4548-b314-3fc7b26d22ee/groups/permissions?groupIds=grp_29a2a427-c09e-47ef-9818-f45781980e9f , grp_bad8ba0b-34cf-4ea3-8680-c99f5f980783 2025.04.28 21:04:10 Error - [API] [1820, 400, Get, 2] Request Finished with Error! No Exception {{"error":{{"message":"groupIds array entry errors˸ ［ groupIds entry must be an ID˸ ' grp_bad8ba0b-34cf-4ea3-8680-c99f5f980783' ］","status_code":400}}}} 2025.04.28 21:04:10 Debug - [API] groupIds array entry errors˸ ［ groupIds entry must be an ID˸ ' grp_bad8ba0b-34cf-4ea3-8680-c99f5f980783' ］ 2025.04.28 21:04:10 Error - [API] [1820, 400, Get, -1 https://api.vrchat.cloud/api/1/users/usr_40be82e7-f7d5-4548-b314-3fc7b26d22ee/groups/permissions?groupIds=grp_29a2a427-c09e-47ef-9818-f45781980e9f , grp_bad8ba0b-34cf-4ea3-8680-c99f5f980783] Abandoning request, because - groupIds array entry errors˸ ［ groupIds entry must be an ID˸ ' grp_bad8ba0b-34cf-4ea3-8680-c99f5f980783' ］ 2025.04.28 21:04:10 Error - groupIds array entry errors˸ ［ groupIds entry must be an ID˸ ' grp_bad8ba0b-34cf-4ea3-8680-c99f5f980783' ］

Using the VRC Avatar Parameter Drive to copy an animated parameter in an animator to a VRC Parameter does not work. Tested copying VRC parameter to another VRC Parameter, and that works. Tested copying an animated parameter to VRC Parameter in Unity editor using gesture manager and that works too. Tested on an otherwise empty avatar without any VRCFury or other addons modifying the upload process. To create a test, follow these instructions: * Create a VRC Parameter component with the following 3 parameters and add to an empty avatar. VRC_Input (Float), VRC_Output (Float), VRC_InRadial (Bool). * Create a VRC Menu component and add two radials. Name one Input, and set parameter to VRC_InRadial, and rotation to VRC_Input. Name the other Output and set rotation to VRC_Output * Create a Unity animator with all 3 VRC parameters as well as a new "Animated Property" float parameter. * Create an animation animating the "Animated Property" from 0 to 1. Have this animation as the only animation in its own layer in the animator, and set the Motion Time to VRC_Input (Thus the Input Radial in our menu will animate the "Animated Property" parameter). * Create another layer with two states, name one "In Radial" and the other "Outside of Radial". * Create a transition from "In Radial" to "Outside of Radial" and set the condition to VRC_InRadial == False. Then create another transition back to "In Radial" with the condition VRC_InRadial == True. * Finally add a VRC Avatar Parameter Driver to the "Outside of Radial" state, set the type to Copy, the Source to Animated Property, and the Destination to VRC_Output. Upload and test. Expected behavior: Adjusting the Input radial will update the animated property, and when exiting the input radial, the animated property is copied onto the Output parameter and thus visible on the output radial menu item. Actual behavior: The VRC_Output parameter is not updated when exiting the Input radial. Adjusting the VRC Avatar Parameter Driver on "Outside of Radial" state to copy from VRC_Input instead of Animated Property, then re-uploading the avatar, shows that copying from VRC parameters works. NOTE: It may appear that the Animated Property is not being adjusted by VRC_Input if you view the Debug Menu ingame. However, creating a third layer with an animation that animates anything visible on the avatar (lets say the scale of a cube or color of a material) and then setting the motion time on that animation to Animated Property proves that the value is still updated. This strange behavior might point to the cause of this bug.

This issue has been present for a long time and still hasn't been fixed. There is a mismatch between remote and local hand tracking, which is especially important for sign language communication. In the first picture (remote view, as seen by a friend), I am making the "C" sign. However, in the second picture (my local view), the hand pose is completely different and looks like I'm making a "duck" gesture instead. Accurate hand tracking across both views is essential for consistent gestures and sign language interpretation.

Depending on the FoV value the user sets, several elements of the UI change: Main Menu's Height Cursor Highlight Position Avatar Model (this issue existed before 1623)