Bug Reports

If you are age-verified and have any of the related badges displayed on your profile, the badge may occasionally default to "Get Age-Verified" when viewing your own profile. This seems to be a purely visual bug within the client, as refreshing your User Profile—by closing and reopening it or similar actions—corrects the issue. From my observations, this bug does not appear to affect how other users' profiles age-verified badges are displayed, as far as I can tell anyway when comparing profiles between the client and website.

VRChat crashes when entering a world or loading an avatar. This problem is not an individual issue, but rather an event that is thought to occur in everyone. The likelihood of crashing varies from user to user, and some are not affected at all. The inability to return to the original instance or the interruption of conversation and play in the first place can cause intense stress and anxiety for users. * Most crashes occur upon entering an instance. * Crashes can also occur when loading your avatar, causing others to crash as well. * There are very few cases reported before November. * This can happen even if there is only one person in the instance. * It may be triggered by CPU, GPU, VR, or network load, but we can only speculate. * The VRChat client itself will be killed. > Application Error, bad_module_info, unknown, Exception code: 0x00000000 * The last log output is as follows. Nothing is logged after that. > Warning - Recovered 129 Network IDs from Avatar The crash was accidental and everyone thought it was their own problem. However, when I asked users in the community around me, some of my friends experienced more than 10 crashes in an hour. we should hurry to find out the cause and fix the inexplicable crashes of the VRChat client. Translated with www.DeepL.com/Translator (free version) ワールドに入るか、アバターロード時にVRChatがクライアントごと落ちます。 この問題は個別の問題ではなく、誰しもに発生していると考えられる事象です。 ただし、ユーザーによっては、まったくクラッシュしない人もいます。 元いたインスタンスに戻れなくなることや、そもそも会話や遊びが中断されることは、強いストレスと不安によりユーザーから楽しみを奪います。 ・クラッシュの多くはインスタンスに入ったときに起こります。 ・自身のアバターロードにより、他人をクラッシュさせることもあります。 ・11月以前の報告例は、ほとんどありません。 ・インスタンス内の人数が1人であっても起き得ます。 ・CPU, GPU, VR, ネットワーク負荷がトリガーかもしれませんが、分かりません。 ・強制終了時、Windowsのイベントログには、次のようなイベントが残っていました。 > Application Error, bad_module_info, unknown, Exceotion code: 0x00000000 ・クラッシュ直前、次のようなログが最後に出力されます。以降は何も記録されません。 > Warning - Recovered 129 Network IDs from Avatar 偶発的であり、誰もが自分自身の問題であると考えていました。しかし、私の周囲のコミュニティのユーザーに聞くと、中には1時間に10回以上のクラッシュを経験したフレンドもいます。速やかに、VRChatクライアントの不可解なクラッシュの原因究明と修正を希望します。

WorldSDK Version: 3.7.5 When defining a RuntimeAnimatorController as a field in UdonSharp, as shown in the code below, and assigning an AnimatorController to this field, all references to fields in the Udon script are lost during runtime in VRChat. public class TestParameter : UdonSharpBehaviour { public RuntimeAnimatorController m_controller; public Transform m_testParam; [SerializeField] public void Start() { Debug.Log($"TestParameter: m_controller is {Utilities.IsValid(m_controller)}"); Debug.Log($"TestParameter: m_testParam is {Utilities.IsValid(m_testParam)}"); } } In the sample code, if an AnimatorController is assigned to m_controller, the references to both m_testParam and m_controller are lost during runtime in VRChat. If no value is assigned to the m_controller field, the reference for the m_testParam field remains intact. This issue does not occur in ClientSim.

5.1MB is over HALF of the 10MB allotted file size for Quest uploads. the Toon Lite is 56KB which is far more normal and expected. Shader files are just text and that should be compressing down to next to nothing. i whatevers bloating up the Standard Lite needs attention.

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]]

easy to reproduce in: https://vrchat.com/home/world/wrld_765d95e9-c9f6-4906-af91-7968aa935ef6 World is using this script: https://github.com/jetdog8808/Platform-Link To reproduce the issue on desktop. Stand on a platform and set the fps cap to be higher then your screens refresh rate, or to unlimited. seams to be a issue when the fps is higher then the fixed update rate. I've also noticed a similar behavior in vr but its been harder to reproduce consistently. a temp fix i found was to only teleport the play on fixedupdate, but that will cause stuttering which could make people sick.

On index controllers the wrists are rotated significantly differently than before the update. Everything attached to the wrists is now off, including any props. Included is a photo showing how the axies differ. The in menu wrist rotation does not fix the issue.

in VRChat open either the streaming camera or a personal mirror. enable finger trails or a spring joint with a trail on it.

When opening the main menu in a seated station. The parameter IsGrounded is getting changed to False, so the VelocityY decrease and the VelocityMagnitude increase. Seen to happen on all seated station tested including sdk2, but not this map from 2020 or the default home. https://vrchat.com/home/world/wrld_72e69c2a-f812-405a-bdaa-c63c4da5c796 No sure what is the correlation.