Bug Reports

OscQuery requires each node is capable of responding HTTP requests pertaining to the OSC methods that it's able to read/write to/from. VRChat should then only send to these addresses due to it now knowing what addresses the node needs. Despite this, VRChat sends all values to the client over OSC anyway. This has been an issue since OSCQuery's launch. For example, I only need to receive information about avatar changes (/avatar/change), and my HTTP server responds with that single address as a read/write string value, yet it sends all values anyway, and I need to parse every single one of them to find the correct one. Fixing this would improve performance both on VRChat's side not having to encode all that unused OSC data, and on the app's side only having to decode the relevant data to find the data it actually needs.

When sending avatar parameters rapidly, there is a chance that upon avatar switch, there will remain parameters from the old avatar in all future returned OSCQuery JSON until the game is restarted. So far, I've been able to filter these erroneous parameters out by just ensuring all parameters have a type tag (which the ghost parameters consistently lack). Attached is a preview of one of these occurrences. The avatar loaded in the attached image doesn't even contain this parameter anywhere.

If you turn OSC off and then back on in game, VRChat stops sending packets to any ports that were previously connected via OSCQuery. If a new port number is used for the oscquery connection, it works fine, but even returning to the old port afterward remains broken.

When launching the same account more than once using the Quick Launcher (using a local world), all PhysBones and Contacts do not work. However, when using two separate accounts, the functionality of PhysBones and Contacts works

I don't even own a oculus, i have an index, but in Unity there seems to be something wrong in the "packages/com.vrchat.base/integrations/oculusspatializer/audiopluginoculusspatializer.bundle" It's doing an infinite import loop. I would appreciate if this would be looked into.

I noticed this because I optimized everything on my avatar, I noticed with 3 different avatars and even worlds, in which everything worked fine before the update, well after the update the game goes wrong. I lost around 20-30 fps max... PS: I would add that I optimized everything on my avatar, I have a download size of 21 MB, and I used the DarkPlayer that vrchat recommends for optimization. and I don't have a texture in 4k because I hate it especially since it's useless.. (I'm at 80 mb of texture memory) with the objects that I can put on my hands, and my clothes (and when I look into space, I run at 115 fps, whereas before the update I ran at around 150 fps, and sometimes I drop to 80 fps for no reason).

When testing on both the beta and current released versions of VRChat on Desktop, we encountered an issue with player locomotion being affected by the framerate. Steps to Reproduce: 1) Join a world where you can achieve a full framerate (> 144fps) for optimal testing conditions. 2) Navigate to VRChat settings and set the FPS cap to "Unlimited". 3) Perform a jump, then immediately attempt to move forward without sprinting. Observe that the player does not move forward. 4) Adjust the FPS cap to 90 fps. 5) Repeat the jump and immediate forward movement without sprinting. Notice that the player now moves forward. Player movement should remain consistent regardless of the framerate setting.

After the recent update which introduced the VRCAnimatorPlayAudio behavior to the SDK, I along with a number of others have noticed an issue that seems to occur when these components are loaded into certain worlds. In some worlds when audio is played back after the avatar is loaded, it comes out as extremely glitchy and is apparently audible to anyone in the world that has the avatar loaded and visible. This occurs even if the audio is not set as 2D and is appropriately spacialized. The only consistent workaround I have found for the problem currently has been swapping out of and back into the avatar after switching instances if the issue occurs, though this is not a workable solution to the problem long-term as people who join the instance after swapping still seem to experience the issue. It does not always occur in every world the user is in, but from what I've observed it tends to happen in older worlds more often than not. I've provided a link to a world that I've seen this issue occur in repeatedly as an example: https://vrchat.com/home/world/wrld_e4fe02ec-3ca7-45cf-a801-251848023370 Feel free to reach out if more information is needed.

Description: While controllers are idle, the user's avatar's hands will go to a default position, as if controllers were not connected. This can be triggered in one of two ways: System Menu: Open the system menu (Oculus or Pico button) Wait a few seconds The avatars hands will switch position, away from where Steam VR says the controllers are This itself does not effect gameplay, however the following does Controllers Going Idle: (Tested only on Pico 4) Place controllers down and keep your head relatively still Pico 4 controllers will stop tracking their position after approx 15 - 30 seconds of little movement The avatars hands will switch position, away from the controllers This has a large impact on the game play experience, as if you are sitting with the controllers in your lap, or not moving much (like when watching a movie), the avatars hands will switch positions after a short period, once this occurs they can switch back and forth between the default pose for the avatar and the position they should be in. Expected Behavior: The hands of the avatar should always be where Steam VR is reporting the controllers to be, this was the case before Build 1304.

1.) Search for people 2.) sometimes they dont show up, even though they are very there.