World/Udon Bugs & Feature Requests

all the physbone related structs are undefined, this is the latest release version of the base and world SDK (3.10.2)

This has been broken for a long while, since I can remember, Auto Hold does not work for Oculus, or Index, but does work for Desktop, and (last I checked) Vive.

Calling Camera.Render() on a camera in LateUpdate() or PostLateUpdate() will either crop the sides of or completely erase the contents of the current quick menu tab. When you open the menu the sides will be cropped. If you switch to a different tab the contents there will display normally. If you move to a different tab then close the menu and open it again, the menu will be completely empty. The problem does not occur when called in Update(). Camera component settings do not matter. The problem only occurs in VR. There are a few other reports about avatars breaking when rendering cameras in LateUpdate/PostLateUpdate that have gone unresolved for years, but no mention of the menu breaking. The problem has been present for at least half a year. PC VRChat build: 1801 SDK version: 3.10.2

I've been using VRCPhysBones for dynamic elements such as antennas and mud flaps on drivable vehicles since November, 2025 without issues, but some VRChat client update in January 2026 suddenly broke VRCPhysBones attached to vehicles in worlds, causing violent shaking when driving. PhysBones still behave normally in Unity Editor when testing using ClientSim, but when in game, all bones begin to violently shake back and forth, as if fighting against the linear motion of the vehicle. The issue was first discovered in a world that had been fully functional for weeks, when suddenly in January the stuttering began in all versions of the world. The vehicles use Rigidbody and VRCObjectSync at the root and Unity WheelColliders for wheels.

I'm aware SDK2 is no longer supported, but I wanted to bring this up as it breaks so many great worlds and seems like it may be a straightforward fix. In SDK2 worlds, OnPlayerTriggerEnter is no longer working for players when entering a trigger collider. This breaks core functionality in many worlds. A good example is this classic, "Fever Dream": https://vrchat.com/home/world/wrld_4137b868-771b-4dd1-ac76-a138d56dbd41/ Steps to reproduce: Enter the first room and turn the corner. The next area no longer turns on when entering the trigger collider.

On the documentation page for Input Events ( https://creators.vrchat.com/worlds/udon/input-events/ ) "InputDrop" is said to be true for releasing the grip buttons on controllers other than vive wands or some WMR controllers. I've been doing a few tests with the input mappings to see how they behave between players using Vive wands and other controller types. So far, I've found that the "release grip" condition for InputDrop becoming true is only the case (for a single frame, which is good) when using Hand Tracking on Quest standalone, but I was unable to trigger it from releasing grip any other way. Oculus controllers - both from PCVR through SteamVR via Virtual Desktop, and on the standalone version - from my testing cannot fire InputDrop at all. Index controllers also can't fire it all either. I feel as though either this needs to be changed in the client or the documentation needs to be updated... With this in mind though, currently a usable workaround is to just do the "release grip" check on our own via Udon, using the InputGrab event and checking for False. P.S: I also found that the OnInputMethodChanged event always says SteamVR2 when playing from PCVR, regardless of the actual input type, but this was already reported in another post. Also, The input method for Hand Tracking on Android returns a value of 19, which is not documented as the highest value shown on the website is 18. My IDE says that it does exist however with an enum called "VRCInputMethod.Count" instead of using "VRCInputMethod.QuestHands"? Still strange.

I'm trying to add shadows to my world Test Pilots and it works fine on desktop mode but in VR I'm getting severe shadow acne. I've attached two images, one showing desktop and one showing VR. I have messed with the following settings (and there are sliders to change them in the world): Near/Far clipping plane Directional light's Bias and Normal Bias None of them seem to help much, so I'm wondering if there's an internal VR setting that has been overlooked that is causing this issue. My settings are as follows: Near: 0.05 (max allowed in VRC) Far: 50000 I realize these settings are extreme, but I can't see a reason why there'd be such a huge difference between VR and desktop. I've uploaded a barebones version of the world for testing at: https://vrchat.com/home/world/wrld_6a5d6107-25a1-4152-9eb2-0b110ae23432/info To see the issue go in VR and either fly up in the air using jump + left trigger OR click on the 'Teleport To Light Control' button and look towards the large grey structure. Note there is a day/night cycle in the world so sun angle may change if you stay too long. Hit the 'Set Day' button at spawn to freeze it. Issue has been observed on Index and Quest 3

If you use a Slider and set onValueChanged to go to UdonBehaviour.SendCustomEvent, it will always send 0 even though your custom event implemented a float parameter. The reason for this is that SendCustomEvent takes a string parameters, not a float parameter, and is therefore shown under the static section, and not under the dynamic floats section. As a result, we can't actually get the float value from the callback, leaving the Slider onValueChanged event basically useless if we want to know what value it is. A workaround would involve passing in the Slider as a public variable, then using the callback with SendCustomEvent, and grabbing the value from the Slider component. Not entirely sure of a good solution to the problem as SendCustomEvent would always require a string parameter so it knows where it's going. Even if custom parameters were added so you can call the function with parameters, this probably still wouldn't fix it Not sure whether you can consider this a bug or not due to the cause, but it kinda effectively behaves like a bug

Gravity and Kinematic flags on VRCObjectSync components don't sync correctly right now and also cannot be set correctly while holding the pickup. To set gravity or kinematic flags, VRChat added two new methods for us: https://udonsharp.docs.vrchat.com/vrchat-api/#vrcobjectsync (they are supposed to behave like a synced variable) There are two bugs related to this: ~ Bug 1: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component with an external button after claiming ownership. Then you let different people in the world pick up the pickup and drop it (to show their own local state). In my tests, this resulted in a pickup where the gravity flag is wildly different on each client and only syncs occasionally or not at all. They would see the pickup drop on my end, but when they pick it up it has no gravity for them. ~ Bug 2: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component in OnPickupUseDown() . In my tests, this resulted in a pickup where the gravity stays enabled after the first OnPickupUseDown() and I am unable to turn gravity off again. To check gravity, the pickup is dropped. You can also just test it out here: Right setup: Bug 1 / Left setup: Bug 2 https://vrchat.com/home/world/wrld_9cefd5ec-4492-43c5-8cd3-05036c494556 Additional note: Since we only got a setter and not a getter method, we are left in the dark here when it comes to analyzing the problem. Reading out the local rigidbody state doesn't give us access to the real synced state. A getter method should be added.

It seems like the operator ">=" acts like ">" and therefore gives wrong results. But only when one of the comparisons is a variable. I think the example below explains it better than words. Define Example enum: public enum TestEnum { ONE, TWO } Then call: var max = TestEnum.TWO; max >= TestEnum.TWO; The result will be FALSE, and not TRUE like it should be. Conversely, this results in TRUE correctly: (int)max >= (int)TestEnum.TWO; And this works too: TestEnum.TWO >= TestEnum.TWO;