Bug Reports

In the VRChat 2025.1.3 update (Build 1606), a new feature was introduced where a blue indicator is displayed for five seconds when using the camera’s timer function. However, this indicator currently appears within the camera view during photo capture, resulting in it being visible in the final photo. While the visual countdown is a very useful feature, the indicator's presence interferes with the captured photos. Additionally, the default camera mask settings enable "Local User," "Remote User," and "World," while "GreenScreen" and "UI" remain disabled. Therefore, we would greatly appreciate it if you could consider the following improvements: Ensure that the indicator does not appear in the captured photo. Since there may be cases where users want to enable UI while taking photos, please handle the indicator as a separate layer so that it is not included in the camera output. 【日本語訳】 VRChat 2025.1.3（ビルド1606）のアップデートにおいて、カメラのタイマー機能使用時に青色のインジケータが5秒間表示される仕様が追加されました。 しかしながら、写真撮影時にこのインジケータがカメラ映像内に映り込んでしまうため、撮影した写真にも表示が残ってしまうという問題がございます。 視覚的なカウントダウンは非常に便利な機能ではありますが、インジケータが映りこむことで撮影した写真の妨げとなります。 また、カメラのマスク設定は、デフォルトの「Local User」「Remote User」「World」が有効、「GreenScreen」「UI」が無効の状態となっております。 つきましては、以下の改善をご検討いただけますと幸いです： ・撮影した写真にはインジケータが表示されないような仕組みにしていただきたい。 ・UIを有効にして撮影したいケースもあるため、インジケータを別のレイヤーとして扱い、カメラ出力に含まれないようにしていただきたい。

anything with a long strand of bones Use them. I'm a virtual Flow artist and after the new update, pysbones are now acting choppy and jittery. Below is a gif of me using my cyber flows that I listed a couple weeks ago and the movement they made. The video on the other hand is after the new update that brought the drone and dolly. this affects me as a dancer. while it's most noticeably seen on flow toys it is also seen on tails and hair to some extent. We have also noticed choppiness on a piece of clothing such as a Kimono and long dresses. Adding on, Included the ID of the Feline avatar with the same flow toys to test along with several other flow toys that have also been affected avtr_82990eea-2f71-4495-8b11-434afda801a7

=Using machine translation == Issue: When a group instance is created, the instance is visible from friend locations even though role restrictions are in place. Details: Groups have a function called Roles, which allows you to create instances that can only be accessed by users who are members of the group and who have been granted a certain role. This function is very useful when you need to hold a meeting or world validation only for the staff members who will conduct the event. However, with the current specifications, when a group instance with role restrictions is created, it does not appear in the group instance list, but for some reason the instance with role restrictions is visible in the friend locations. There is a button to Join the instance, but I get an error and cannot enter. This is a bit odd in light of the behavior of Friend instances and Friend Plus instances. If it is an instance that cannot be entered, it would be normal for it to be marked as a private instance. =日本語= 問題： グループインスタンスを作成した時、ロール制限をかけていてもフレンドロケーションからインスタンスが見えてしまいます。 概要： グループにロールと呼ばれる機能があり、これを使うことで「グループに入っていて、かつ所定のロールが付与されたユーザーだけが入れるインスタンス」を作成することができます。 この機能はイベントを行うスタッフだけを集めて会議・ワールドの検証を行う際などに非常に重宝されます。 しかし、現在の仕様だと、ロール制限をかけているグループインスタンスを作成した時、グループのインスタンス一覧には出てきませんが、フレンドロケーションでは何故かロール制限があるインスタンスが見えてしまいます。 インスタンスにJoinするボタンはありますが、エラーが出て入ることはできません。 フレンドインスタンスやフレンドプラスインスタンスの挙動に照らし合わせてみると、これはちょっと奇妙です。 入ることができないインスタンスであれば、プライベートインスタンスの表記になるのが正常だと思われます。

Open VRChat and load a reasonably complex world Example: An old Neon Divide map that hasn't been updated in 2 years (This also occurs with more modern maps, but this map's performance is so bad it's a useful test case) https://vrchat.com/home/world/wrld_9c4d7b7c-4ada-4df3-b4ce-de03cbd3c582/info Stand somewhere in the map, and watch performance degrade sharply over a few minutes This seems to be a CPU issue, CPU usage increases over time On some hardware configurations, performance may jump back up again and then start degrading. Something to do with threads getting overloaded and new ones being spun up

When transitioning between worlds, the duration of the black screen before the initialization screen is prolonged much more then it used to be on previous builds.

Regardless of which avatar you attempt to load (only personal uploaded should work) it will instantly reject the request to download and refuse to load from cache if already in cache. Tried clearing cache and downloading from regular live client (which works fine in live). Optional cleaning for test Clear content cache in live client. Restart live client and allow avatars you've uploaded to load. Steps Launch Build & Test by any means into a test world. Instantly shows error robot and presents the attached error for any attempts at loading avatars.

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.

Issue: When using a Text Mesh Pro Input Field the "On End Edit" event does not fire in client, in client sim however it does. This is even weirder to me as the VRC URL Input Field does fire the "On End Edit" event, even in client. Expected Behaviour: "On End Edit" on a Text Mesh Pro Input Field should fire in client.

When I upload my model after the update, my particles appear without their texture under the Shapes tab inside the particle system. Instead of displaying the texture as they should, they appear as if no texture was ever applied. I noticed that when I uploaded using "Build & Test Offline," the particles appeared correctly. However, when I uploaded normally to VRChat, the texture was removed, and the particles appeared without it. This issue only started happening after the latest update (2025.1.1). It was not occurring in previous uploads before the update. I checked the patch notes for VRChat, but there was no mention of changes related to the particle system, the SDK, or the upload process. To help illustrate the issue, I will provide images showing: What my particle system looks like in Unity before uploading. What it looks like after uploading. A comparison of the affected particle system property. An example of how the particles appear in Unity when no texture is applied (which is how they look in-game). Keep in mind that everything was working fine before the 2025.1.1 update.

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