Bug Reports

While holding the camera in a moving station (The faster the more apparent), some form of camera stuttering begins to occur as if the camera's position lags behind every few frames. Letting go of the camera fixes this issue, but anytime grabbing and holding the camera, it starts again. Worlds with fast moving vehicles such as 'Test Pilots' are the most noticeable locations to see this happen. This issue may have popped up sometime between early October 2024 and late December of 2024. I have only been able to test on PCVR.

The recently used avatars category is getting its sorting mode set to whatever the last tab you looked at's sorting mode was. Repro: View Recently used avatars category in MM, see that sorting mode is set to recently used. Click any Uploaded avatar category, take note of Last Updated sorting mode. 3 Click back to Recently Used category. Actual Result: Recently Used avatars category sorting is now set Last Updated. Expected result: The sorting mode should be Recently Used (or whatever the Recently Used category was originally set to before switching). w 2025-2.2-24dbdbc947- steam Branch: internal-beta

When ever someone updates their avatar or world the old cache doesnt get overwritten or deleted and stacks. easy to reproduce. upload a world load it update the world load it again and you got 2 cached versions. Possible solution: Check if there is a old cached version when downloading an avatar/world and delete it.

Open VRChat, Join a world with an Index controller user Have them make a series of hand gestures and see if they are able to properly articulate their fingers individually or if the quest handshapes are shown. I've noticed over the past few weeks, alongside a few other friends, that the hand IK is having some issues when displaying handshapes to other users. It seems to primarily be affecting Index controllers. Locally I will see what I am doing fine, but others report that I am doing a different gesture. I have seen this issue happen with other users as well. An example I have from a Helping Hands class for VRASL: the teacher was showing a sign which I knew was done with another hand shape, but I saw the teacher using a "C" hand, which is the sort of cupped hand shape that Quest controllers usually have. I knew the teacher used Index controllers so I was confused and tried hiding his avatar and showing it, fixing the issue in this instance. Hiding and showing seems to fix the issue in most instances but having to do that every time is a huge hassle, if you can even identify that the bug is occurring. This issue is a big detriment to clarity in communication between people in the sign language community, as it's very difficult to tell if the issue is occurring until you've communicated for a while and realize that what they're saying makes no sense. It is also frustrating for users to have differences between what they're seeing and what others are seeing in general.

World tags should not be case sensitive. There is no reason why "chill" and "Chill" should be considered two different tags.

I created a texture synchronization system, but faced a situation where OnDeserialization was not running randomly. This was a random event where the result could change each time the same person rejoins, but it could tend to happen if the number of people who have joined or currently exist in the instance is large, or if there is a lot of data to be synchronized. However, this can also happen in instances where there are only two people, or instances with a small number of data (although a larger number than usual, since two or three 512x512x2bytes of data are synchronized). The following code was used for testing. (It is a bit complicated because it is the code of an actual application.) [1] https://github.com/Narazaka/SyncTexture/blob/b0a209acfbcf334fb04ef861312bb6c6f341271c/SyncTextureData.cs In the normal flow, when OnDeserialized is called, ApplyReceiveData() is called, and the [SyncTexture] ... ApplyReceiveColorsPartial() [ReceiveEnabled=True] is logged. This is indicated by the following data restore and apply logs that follow after join and before OnPlayerJoined in normal.txt. [2] 2024.12.11 01:46:07 Log - [Behaviour] All 8 bunches for SyncTextureData0 collected, now restoring. 2024.12.11 01:46:07 Log - [SyncTexture] ApplyReceiveColorsPartial() [ReceiveEnabled=True] 2024.12.11 01:46:07 Log - [SyncTextureShaderDXT] SyncTextureShaderDXTCamera.OnReceiveApplied 2024.12.11 01:46:07 Log - [Behaviour] All 8 bunches for SyncTextureData1 collected, now restoring. 2024.12.11 01:46:07 Log - [SyncTexture] ApplyReceiveColorsPartial() [ReceiveEnabled=True] However, in the abnormal case, OnDeserialized is not called after data restoration. To solve this, the callback TryApplyReceiveDataFromStart() , which is called 3 seconds after Start(), calls the same process if data is found and writes logs like [SyncTexture] ... Trying to get data and found non null data! [3] https://github.com/Narazaka/SyncTexture/blob/b0a209acfbcf334fb04ef861312bb6c6f341271c/SyncTextureData.cs#L64 The not-fired.txt is the log when this situation occurred, and the following data restore log is flowing before OnPlayerJoined, but [SyncTexture] ... ApplyReceiveColorsPartial() [ReceiveEnabled=True] that should flow when OnDeserialized is called is not flowing. [4] 2024.12.11 03:09:07 Log - [Behaviour] All 8 bunches for SyncTextureData2 collected, now restoring. 2024.12.11 03:09:07 Log - [Behaviour] All 8 bunches for SyncTextureData3 collected, now restoring. 2024.12.11 03:09:07 Log - [Behaviour] All 8 bunches for SyncTextureData4 collected, now restoring. After OnPlayerJoined, there is a log that flows during the countermeasure callback, and the data application log is also flowing. [5] 2024.12.11 03:09:10 Log - [SyncTextureData] (SyncTextureData36) Trying to get data but not received. 2024.12.11 03:09:10 Warning - [SyncTextureData] (SyncTextureData52) Trying to get data and found non null data! 2024.12.11 03:09:10 Log - [SyncTexture] (-1210292) ApplyReceiveColorsPartial() [ReceiveEnabled=True] 2024.12.11 03:09:10 Log - [SyncTextureShaderDXT] SyncTextureShaderDXTCamera.OnReceiveApplied 2024.12.11 03:09:10 Warning - [SyncTextureData] (SyncTextureData25) Trying to get data and found non null data! 2024.12.11 03:09:10 Log - [SyncTexture] (-892658) ApplyReceiveColorsPartial() [ReceiveEnabled=True] From this it can be said that there are cases where OnDeserialized is not called even when data is restored. This problem has happened in the past and VRChat is aware that it has been resolved, but it still seems to be happening. [6] https://feedback.vrchat.com/bug-reports/p/1537-ondeserialization-fires-without-any-networked-data-changes-for-late-joiners -------------------- 私はテクスチャ同期システムを作りましたが、OnDeserializationがランダムに実行されない状況に直面しました。 これは同じ人でもrejoinの度に結果が変わりうるランダムな事象でしたが、インスタンスにこれまでjoinした人数、または現在存在する人数が多いか、あるいは同期されるデータが多いと起こりやすくなる傾向がある可能性があります。しかしたった2人だけしかいないインスタンスや、データ数のすくない（とはいっても512x512x2byteのデータが2、3個同期されているので通常よりは大量ですが）インスタンスでも起こりえます。 テストに使ったのは以下のコードです。（実際のアプリケーションのコードなので少し煩雑ですが） [1] 通常のフローではOnDeserializedが呼ばれると ApplyReceiveData() が呼ばれ、この先でデータを描画する時に出る [SyncTexture] ... ApplyReceiveColorsPartial() [ReceiveEnabled=True] というログが流れます。 これはnormal.txtでjoin後OnPlayerJoinedより前に以下のようにデータリストアと適用のログが続いていることに示されています。 [2] しかし異常ケースだとOnDeserializedがデータリストア後に呼ばれません。この対策のためStart()のあと3秒後に呼ばれるコールバック TryApplyReceiveDataFromStart() が、もしデータが見付かった場合同様の処理を呼び、 [SyncTexture] ... Trying to get data and found non null data! といったログを書くようにしました。 [3] not-fired.txtはこの状況になった時のログで、OnPlayerJoinedの前に以下のデータリストアのログが流れていますがOnDeserializedが呼ばれると流れるはずの [SyncTexture] ... ApplyReceiveColorsPartial() [ReceiveEnabled=True] が流れていません。 [4] OnPlayerJoinedの後になってから対策コールバック時に流れるログが出て、データの適用ログも流れています。 [5] このことから、データがリストアされてもOnDeserializedが呼ばれないケースが存在することが言えます。 この問題は過去にもあって、VRChatは解決済みと認識していますが、相変わらず起きているようです。 [6]]

OS: Windows 10 VRChat Version: 1623 open-beta Headset: Valve Index Hardware: RTX 2070 super, Ryzen 7 5800X3D SteamVR: 2.9.6 Unity Version: 2022.3.22f1 (Through creator companion v2.4.2) VRChat SDK: 3.8.1-beta.1 First off: I'm usually one to gripe on things but for this one, thank you. We've recently been given the absolute grace that is DepthTextureMode read/write access, including the DepthNormals flag for cameras. This feature alone massively extends what shaders can do, while removing the expensive and inaccurate methods used to approximate a "normal pass." Before this update, you could choose between using a unity projector, or a bunch of normalized cross product math to get faceted normals from the depth buffer, a look everyone complains to me about. The addition of the DepthNormals flag enables the _CameraDepthNormalsTexture which stores both the depth and normal data in one texture, making shaders even more efficient assuming one decodes the depth from there as well. The problem: Sadly, it seems like a major amount of existing shaders are not rendered to the DepthNormals buffer when enabling DepthNormals. Some personal digging and previous work on this matter, my current best guess is the Internal/DepthNormals shader which is built into Unity (but overridable!) having specific RenderType targets is disregarding common shaders like poiyomi and such. Some avatar shaders show up fine in the texture, assuming they are targeted by the given RenderTypes here https://github.com/TwoTailsGames/Unity-Built-in-Shaders/blob/master/DefaultResourcesExtra/Internal-DepthNormalsTexture.shader Recreation: You could recreate this problem by Create a new vrchat world project creating a udon script that enables the DepthNormals pass in Start() like so: VRCCameraSettings.ScreenCamera.DepthTextureMode = DepthTextureMode.Depth | DepthTextureMode.DepthNormals; Creating a shader that samples the _CameraDepthNormalsTexture (which ill include the ones I made for my testing) Create a material with that shader and put it on a cube or something (make sure the RenderQueue is well above whatever shaders you would be previewing) Build and/or upload the world Use avatars with a variety of shaders and view them through the shaders display From here you should see some avatars working fine (like the VRChat base avatars) but most avatars i've tried that use custom shaders are hit and very miss for showing up. A possible solution path (assuming this isn't a skill issue on my part): The internal DepthNormals shader can be exchanged for a custom shader through Edit > Project Settings > Graphics > Built-in Shader Settings > Depth Normals The replacement shader targets are given in the internal shader, which shaders with RenderTypes in that list seem to work just fine. If we create a custom shader that implements the same functionality as the internal one but instead targets all RenderTypes, theoretically this could solve the problem. I've been wanting this feature for years and it's absence hinders a lot of my projects. It would mean the world to me and my projects/lighting systems if we could have this functionality work for all to use. I will happily expand on this problem if needed

In the group public instance linked below, Items are somehow enabled despite the fact that they are disabled by the world author. Any attempt to spawn an item though will be unsuccessful. https://vrchat.com/home/launch?worldId=wrld_a61cdabe-1218-4287-9ffc-2a4d1414e5bd&instanceId=45260~group(grp_d89f8c56-c299-4203-afd2-d3d0554f95be)~groupAccessType(public)~region(use)

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

Hello VRChat team, I’d like to report a critical inconsistency in how group bans are handled when issued through the VRChat website or third-party tools utilizing the API (e.g., VRCX). Observed Behavior When a user is banned from a group via the website or an API-based tool, the ban does not take effect in real-time if the user is currently inside a group instance. Despite being technically banned, the user is: Not removed from the current instance Still able to interact with group members Still enjoying group-related privileges The ban only fully takes effect after the user leaves and attempts to join a new instance, at which point access is correctly denied. Why This Is a Problem This delay has serious implications for moderation: In urgent cases, moderators cannot remove problematic users in real-time. There's currently no mechanism to trigger a forced update or kick based on a group ban alone. It undermines group security, allowing banned users to linger and potentially cause further disruption. This gap in enforcement stands in contrast to other website/API actions such as avatar changes which do propagate instantly in-game. This suggests real-time updates are technically possible, but simply not implemented for group bans. Suggested Improvement To ensure consistent and secure moderation: When a user is group-banned via the website or API, the system should immediately remove (kick) them from any group-owned instance they are currently in. Implementing this would close a loophole in group moderation tools and align the behavior of group bans with the expectations of real-time enforcement. Thank you for your attention. Resolving this would greatly enhance group management capabilities and improve the overall safety of VRChat communities.