Bug Reports

I run an event that fills up pretty quickly once we announce that guest doors are open. We open the the instance as a group instance with instance queue enabled. After we get all of the staff into the world for the event, we announce on discord and in group pings that the instance is now open for guests to join. Guests should be joining and starting up a queue at the announced time. What they can currently do is use the "Show Go Button on Load" setting to preload the world and reserve their spot in the instance. We can't tell what guests are doing this because they don't load into the world, we have no idea who hass connected early. They simply join the world with everyone else once the ping has gone out. You can test this easily with 2 other people. 1) Create a group instance with a queue for a world with 2 max slots. Just the two of us works well. 2) Have the instance owner join first and load into the world. 3) Have the person who will use the "Show Go Button on Load" join the instance, but not press the join world button. At this point, the person inside the instance does not see anyone else in the world. The person in the load screen has reserved their spot in the world. 4) Have a third person attempt to join the instance. They will either be placed in queue, or receive an error related to needing to join a queue but it will not place them in a queue. From the perspective of the person inside the instance, no one has joined. The third person cannot join the instance and MAY be able to queue. The second person that is waiting to join can join freely at any time. I do not know how long this instance slot reservation lasts, but it is causing significant issues with group instances with queues.

Once your friend count exceeds 2,000, it takes a very long time to load instances. I’ve been playing VRChat for nearly six years. I look forward to visiting various public instances every day. However, since my friend count increased, I’ve started experiencing a wait time of about 3 to 5 minutes every time I move to a new instance before it loads. I suspect that the system reloads the entire friend list every time the instance list is displayed, so I’d appreciate it if there were a better way to resolve this. Alternatively, I think a feature that allows users to bulk-manage friends they haven’t seen in years or have only met once could help prevent friend counts from growing excessive Translated with DeepL.com (free version)

Now that Scalers are possible through OSC (essentially using the same system that Scaling worlds use), this is a bug that's been bugging me ever since the scaling world features came out. Whenever you scale past 20 meters, it is exceptionally noticeable. 1) Go to any World scaler (Jet-Dog's Prefab world is a good place to look at it. Otherwise Little Big Town) 2) Scale up to 100 meters 3) Check your Personal Mirror (or camera), move your head around and watch your eyes go cross-eyed. What is happening (As I understand it): Avatars have a fake-gaze target that the eyes will point at when no face tracking is available. When you scale to larger and larger sizes, that Fake-gaze position gets closer and closer to the avatar. The distance to that fake gaze target stays the same distance, but the avatar itself is larger. Meaning that the fake-gaze target does not scale along with an avatar. To put what's happening into words for example: At 2 Meters -> Fake gaze target is 4 meters away (Not sure if this is the actual number but it's just for example's sake) At 5 meters -> Fake gaze target is 4 meters away At 10 meters -> Fake gaze target is 4 meters away (unnoticeable) - This is equivalent to something being about 80 centimeters away At 20 meters -> Fake gaze target is 4 meters away (Barely unnoticeable) - this is equivalent to something being 40 centimeters away from your face At 50+ meters -> Fake gaze target is 4 meters away (VERY noticable) - this is equivalent to something 20 centimeters away from your face up to looking at your nose and being crosseyed. Very annoying and long-standing bug, I wish it were fixed. (Cannot confirm or deny if this happens on Quest, I only play on an Index and see it on PC)

To be more precise: once you see an avatar in an instance and load in its assetbundle, the limits set with Maximum Download Size and Maximum Uncompressed Size won't apply to it for some reason as long as that assetbundle is in memory. STR Open VRC Set your Maximum Download Size and/or Maximum Uncompressed Size to something tiny like 0-10MB join an instance with other people, observe their impostors select a person with an impostor, force-show them, and see their full avatar disable the force show (set avatar display back to the shield) what should've happened: the avatar should reload and show the impostor again what happens: the avatar 'reloads' (becomes a blue diamond thing for a sec), but loads back in fully visible This isn't strictly related to force-showing people, it also happens if you lower your settings while in an instance with people that you can already see - no matter how you set these settings, they're gonna keep being visible. You'd need to hide everyone, or they all would have to change to different avatars, for over a minute to get rid of their assetbundles to see the proper impostors after un-hiding/them switching back. hiding avatars by performance rank works fine. noticed it first earlier today on build 1836, and now confirmed it still happens on 1837.

Opening Action menu and going in Looks part, i noticed there is no 'Disable Look' option. So i am forced to add extra slot for setup without anything on it. That is just extra slot wasted. Should add button (just after Back button) so your avatar will normal again without anything on it. This can be confusing for new players why they cannot reset / remove it. It's weird they are forced to make new one without accessories on it. Also good reason because the picture is very small to find one without accessoires on it. A text button is quicker read too, less frustration. I made mine as example and you can see it's very small picture to find one without... bruh. Can you see which one has nothing on it? Please add it. Much easier!

The number of animation layers heavily affects performance due to unnecessary inverse kinematic calculations. Even blank animation layers with zero weight in the FX layer can trigger this behavior. The offender is seen in the profiler as Animators.IKAndTwistBoneJob. It runs as many times as the currently loaded animation controller with the largest number of layers. Although the individual run time is small, they very quickly add up. Slower CPUs seem to be more adversely affected by this. The time taken by these extraneous calculations quickly grows larger than all normal animator activity. This behavior only happens on animators that have a unity avatar/armature. When that is removed, this behavior goes away and the number of layers ceases to be a significant cause of lag. Most FX layers do not have any interaction with the armature, so it is likely that this behavior can be fixed for almost all FX layers. However from debugging the unity editor in visual studio, it appears the this happens in a native unity function named Animator::UpdateAvatars. It is likely that in most if not all cases, these calculations are completely wasted on FX layers and provide no benefit at all while consuming significant amounts of main thread time. Somehow these calculations need to be only run for layers that require them. Additionally providing a way to get parameters in sub animators would allow logic to be moved out of the main animator completely sidestepping this problem. They would not have a unity avatar associated with them, so this problem would not occur. It would also allow completely disabling animators when not in use. Please attempt to find a way to prevent this behavior or consider convincing your Unity contacts to implement a fix. This seems to be one of the largest contributors to animator lag. I have a full write-up with more profiler images and further explanations. https://docs.google.com/document/d/1SpG7O30O0Cb5tQCEgRro8BixO0lRkrlV2o9Cbq-rzJU

When Collision Mode was set to "Hit Players" or "Hit Worlds And Players," my own avatar was hit, but other players' avatars were not. When using "Hit World" or specifying "Pickup" in "Hit Custom Layers," the target was hit correctly. Do other players' avatars also need to be running SDK 3.10.3?

VRChat using absurd amount of RAM, more likely on longer sessions (around 2-4 hours). I haven't played around with it too much to figure out things that could be causing it, but I have noticed that the longer the play session, the more likely it is to happen. Ends up using all of my available RAM, causing freezing and stuttering which can only be solved by restarting VRChat. Does not reset on world/instance rejoin, or going to a new world. I have noticed that RAM usage will be stable, then at some point, it just starts to pile on more and more. ONLY happens on VRChat, every other VR application and non-VR application doesn't do this. Don't know if the results are different on Desktop. This has been happening for a while now and I first started noticing it with the release of the Lunar New Year items update. Maybe could be something that happened there?

Enable MSAA in graphics settings (not sure if relevant) Visit https://vrchat.com/home/world/wrld_ee4e888c-4ae1-48b1-b50c-6a2263e31caf/info which uses the latest https://github.com/MichaelMoroz/VRChatGaussianSplatting prefab (without the workaround) Try taking a picture - picture is not saved and the error is printed in logs instead Workaround: https://github.com/MichaelMoroz/VRChatGaussianSplatting/pull/7 Bug found by LogMeIn Hamachi The error from logs: Error - RenderTextureDesc msaaSamples must be 1, 2, 4, or 8. Parameter name: desc.msaaSamples System.ArgumentException: RenderTextureDesc msaaSamples must be 1, 2, 4, or 8. Parameter name: desc.msaaSamples at UnityEngine.RenderTexture.ValidateRenderTextureDesc (UnityEngine.RenderTextureDescriptor desc) [0x00000] in <00000000000000000000000000000000>:0 at UnityEngine.RenderTexture.GetTemporary (UnityEngine.RenderTextureDescriptor desc) [0x00000] in <00000000000000000000000000000000>:0 at ÏÏÏÍÌÍÏÏÍÏÍÎÍÎÎÏÏÍÌÎÍÍÍ.ÏÎÏÏÍÏÍÏÎÏÌÌÎÎÎÏÎÎÎÍÍÍÌ (UnityEngine.Camera ÌÎÎÌÎÎÍÏÌÌÎÎÏÌÌÌÏÏÍÎÏÏÎ, System.Int32 ÏÍÍÎÎÎÌÏÏÏÌÎÏÏÌÏÏÌÎÎÍÎÏ, System.Int32 ÍÎÍÍÏÌÌÌÏÍÎÎÌÏÎÎÍÎÍÍÌÌÍ, ÎÎÌÏÍÎÍÎÍÍÏÍÌÍÌÏÌÏÍÏÌÎÌ ÌÍÏÌÏÏÏÏÍÎÎÌÍÎÎÎÎÎÏÏÍÎÍ, System.Boolean ÏÌÎÍÏÍÎÍÎÍÌÍÎÎÎÍÍÌÍÎÎÎÏ, System.Nullable`1[T] ÌÌÍÎÏÍÎÍÎÎÌÎÍÌÌÍÏÌÎÎÌÎÏ, System.Action`2[T1,T2] ÏÌÎÏÏÎÏÌÎÎÌÏÎÍÌÌÎÌÌÎÏÎÍ, System.Boolean ÌÎÌÌÏÏÍÌÏÏÌÎÌÍÎÍÌÌÎÌÍÌÍ, System.String ÌÌÍÏÌÎÏÌÎÍÏÍÏÍÌÍÍÏÏÏÍÏÍ, System.Int32 ÏÏÌÏÍÎÏÏÌÍÏÌÌÎÌÎÍÎÏÌÎÎÏ, System.Boolean ÏÎÌÌÌÎÏÌÍÏÍÏÏÏÏÌÏÍÍÍÍÌÏ, System.Boolean ÌÎÎÌÍÍÎÌÌÎÍÌÍÎÎÎÍÏÏÍÎÏÎ, ÌÌÏÏÎÏÎÏÎÏÌÌÎÏÎÌÌÏÏÎÌÎÏ ÎÍÍÌÎÌÌÎÎÌÎÌÏÌÍÌÎÎÎÎÍÏÌ) [0x00000] in <00000000000000000000000000000000>:0 at Cysharp.Threading.Tasks.UniTaskCompletionSourceCore`1[TResult].TrySetResult (TResult result) [0x00000] in <00000000000000000000000000000000>:0 at Cysharp.Threading.Tasks.UniTask+WaitForEndOfFramePromise.System.Collections.IEnumerator.MoveNext () [0x00000] in <00000000000000000000000000000000>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00000] in <00000000000000000000000000000000>:0 --- End of stack trace from previous location where exception was thrown --- at Cysharp.Threading.Tasks.UniTaskCompletionSourceCore`1[TResult].GetResult (System.Int16 token) [0x00000] in <00000000000000000000000000000000>:0 at Cysharp.Threading.Tasks.CompilerServices.AsyncUniTask`1[TStateMachine].GetResult (System.Int16 token) [0x00000] in <00000000000000000000000000000000>:0 at Cysharp.Threading.Tasks.UniTaskExtensions+<>c.<Forget>b__16_0 (System.Object state) [0x00000] in <00000000000000000000000000000000>:0 at Cysharp.Threading.Tasks.UniTaskCompletionSourceCore`1[TResult].TrySetException (System.Exception error) [0x00000] in <00000000000000000000000000000000>:0 at ÏÏÏÍÌÍÏÏÍÏÍÎÍÎÎÏÏÍÌÎÍÍÍ.ÏÎÏÏÍÏÍÏÎÏÌÌÎÎÎÏÎÎÎÍÍÍÌ (UnityEngine.Camera ÌÎÎÌÎÎÍÏÌÌÎÎÏÌÌÌÏÏÍÎÏÏÎ, System.Int32 ÏÍÍÎÎÎÌÏÏÏÌÎÏÏÌÏÏÌÎÎÍÎÏ, System.Int32 ÍÎÍÍÏÌÌÌÏÍÎÎÌÏÎÎÍÎÍÍÌÌÍ, ÎÎÌÏÍÎÍÎÍÍÏÍÌÍÌÏÌÏÍÏÌÎÌ ÌÍÏÌÏÏÏÏÍÎÎÌÍÎÎÎÎÎÏÏÍÎÍ, System.Boolean ÏÌÎÍÏÍÎÍÎÍÌÍÎÎÎÍÍÌÍÎÎÎÏ, System.Nullable`1[T] ÌÌÍÎÏÍÎÍÎÎÌÎÍÌÌÍÏÌÎÎÌÎÏ, System.Action`2[T1,T2] ÏÌÎÏÏÎÏÌÎÎÌÏÎÍÌÌÎÌÌÎÏÎÍ, System.Boolean ÌÎÌÌÏÏÍÌÏÏÌÎÌÍÎÍÌÌÎÌÍÌÍ, System.String ÌÌÍÏÌÎÏÌÎÍÏÍÏÍÌÍÍÏÏÏÍÏÍ, System.Int32 ÏÏÌÏÍÎÏÏÌÍÏÌÌÎÌÎÍÎÏÌÎÎÏ, System.Boolean ÏÎÌÌÌÎÏÌÍÏÍÏÏÏÏÌÏÍÍÍÍÌÏ, System.Boolean ÌÎÎÌÍÍÎÌÌÎÍÌÍÎÎÎÍÏÏÍÎÏÎ, ÌÌÏÏÎÏÎÏÎÏÌÌÎÏÎÌÌÏÏÎÌÎÏ ÎÍÍÌÎÌÌÎÎÌÎÌÏÌÍÌÎÎÎÎÍÏÌ) [0x00000] in <00000000000000000000000000000000>:0 at Cysharp.Threading.Tasks.UniTaskCompletionSourceCore`1[TResult].TrySetResult (TResult result) [0x00000] in <00000000000000000000000000000000>:0 at Cysharp.Threading.Tasks.UniTask+WaitForEndOfFramePromise.System.Collections.IEnumerator.MoveNext () [0x00000] in <00000000000000000000000000000000>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) [0x00000] in <00000000000000000000000000000000>:0

There seems to be an unexpected behavior regarding the accessory feature. Specifically, for accessories that have been scaled down extremely using the accessory feature, the situation is as follows: The accessory disappears from view depending on the viewing angle and distance. However, it does not disappear from the user's own perspective, nor does it disappear when viewed through the user's own camera, even if the distance or angle is changed. If possible, I would appreciate it if this behavior could be investigated. Thank you very much.