World/Udon Bugs & Feature Requests

Allow world creators the ability to moderate their OWN worlds and issue their OWN bans. I'm tired of seeing crashers and exploiters in my worlds and kicking them is nothing. I want the ability to ban certain individuals from my worlds. There is absolutely no harm in doing this. Who is it going to hurt? The exploiters and cheaters. What if world creators abuse it and ban people from THEIR OWN worlds? Well it's their fault their world fails to gather a population. What else will this do? Allow world creators to suit the needs of their wanted audience. it will also help take the stress off of the actually game moderators. Thank you, Lucifer MStar - Creator of 30+ worlds including church of marriages. P.S. Communicate more with your community on what you are doing about these crashers and exploiters and maybe the heat and stress will die down. Honestly this is the most annoying thing communication.

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

Today, the most popular use case of the IVRCImageDownload is to share some picture with friends in VRChat. However, there is one big annoying behavior in IVRCImageDownload for this use case. That's 2048x2048 texture size limit. Therefore, I hope VRChat to have the feature that automatically scale the texture size down to 2048x2048. As described before, it's common to use IVRCImageDownload for sharing pictures with friends. There are several assets specifically designed for this use case such as Image Pad and ImageTablet . However, the 2048x2048 size limit is an annoying for this use case because today picture is likely to exceed this limit. For example, my iPhone 12 mini with default settings will take picture with 4032x3024 pixels and other modern smartphones also take high resolution image by default. In VRChat, I feel it’s common to choose take pictures in QHD, 4K, or 8K but none fits 2048x2048 limit. (FHD and HD fits 2048x2048 though we want to take high-quality pictures.) The texture downloaded with IVRCImageDownload become uncompressed RG, RGB or RGBA texture on the VRAM so It take huge VRAM. Therefore, I think it's reasonable to limit texture size on the VRAM. However, I think it's possible to resize texture down to 2048 off the main thread before loading to to the VRAM. That’s why I request VRChat to have the feature that automatically scale the texture size down to 2048x2048. 日本語要約 IVRCImageDownloadという Image Pad や ImageTablet のような画像を共有するためのアセットで使われている機能に対する要望です。 前述のタブレットではVRChatの制限により2048x2048より大きい画像を指定した場合にはエラーになりますが、エラーにする代わりに 2048x2048 以下に自動的にリサイズするオプションを追加してほしいという要求になります。 (技術的理由により2048x2048より大きい画像をそのまま表示するのは厳しいです) このオプションがあれば、Discordなどに上げた画像を共有するときにエラーが出て使えないという面倒事を減らせるようになります。

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.

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

It will be nice to be able to use embedded video clips with the new video player system for things like video textures. Currently (on the open beta build 986) we can only load videos from external servers.

Events that are delayed are useful, but also tricky to use because they cannot be invalidated if the context of the delay is no longer valid (for example, a game timer that lasts ten seconds, but the game is terminated after five seconds). The event delay function(s) should return some sort of thin object that can invalidate the delayed event or fire it immediately, or return a reference to the unique delayed event ID so that a function can accept that ID as an argument so it can be invalidated.

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

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.