World/Udon Bugs & Feature Requests

Imposters are amazing, but they can clash with many creative and interesting effects world creators can use within VRC. Projectors and camera effects show them as opaque, or invisible. Often times imposters generate impossibly huge, ruining experiences for everyone in the space when their outside bounds are visible. Please give us the freedom to disable them per-world, or even per-instance. Giving this option to world creators would expand creativity, and would not complicate the end-user experience any further. Alternatively, give imposters their own unity layer so they can be rendered separately.

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.

The ability for worlds to have sub-instances to save on performance at the cost of a loading screen. Basically a portal or Udon function pointing to another world ID that creates a child instance, kinda like a linked list. Moving to a child instance should of course have a prompt to avoid world creators using it as a void dimension for people they dislike. (maybe even add a button to return to the parent instance) Rec Room has had a similar feature for a while, it allows for larger worlds without needing to fit everything in one scene. (especially useful for RAM-limited headsets like Quest)

Players and world creators would appreciate a new character controller for VRChat worlds. It should work mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going upstairs and slopes is smoother. Players can get pushed around by the colliders. It's better at getting players unstuck from geometry. Udon has greater control over the character controller. ... And more!

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 have been testing EventTiming.PostLateUpdate in SendCustomEventDelayedSeconds and SendCustomEventDelayedFrames, and it is never called. The logs only show those that are using FixedUpdate. (3.10.2) void Start() { SendCustomEventDelayedSeconds(nameof(TestPostLateUpdateS), 1, EventTiming.PostLateUpdate); Debug.Log("SendCustomEventDelayedSeconds called"); SendCustomEventDelayedSeconds(nameof(TestFixedUpdateS), 1, EventTiming.FixedUpdate); Debug.Log("SendCustomEventDelayedSeconds called"); SendCustomEventDelayedFrames(nameof(TestPostLateUpdateF), 1, EventTiming.PostLateUpdate); Debug.Log("SendCustomEventDelayedFrames called"); SendCustomEventDelayedFrames(nameof(TestFixedUpdateF), 1, EventTiming.FixedUpdate); Debug.Log("SendCustomEventDelayedFrames called"); } public void TestPostLateUpdateS() { SendCustomEventDelayedSeconds(nameof(TestPostLateUpdateS), 1, EventTiming.PostLateUpdate); Debug.Log("test called in postlateupdate"); } public void TestFixedUpdateS() { SendCustomEventDelayedSeconds(nameof(TestFixedUpdateS), 1, EventTiming.FixedUpdate); Debug.Log("test called in fixedupdate"); } public void TestPostLateUpdateF() { SendCustomEventDelayedFrames(nameof(TestPostLateUpdateF), 1, EventTiming.PostLateUpdate); Debug.Log("test called in postlateupdate frames"); } public void TestFixedUpdateF() { SendCustomEventDelayedFrames(nameof(TestFixedUpdateF), 1, EventTiming.FixedUpdate); Debug.Log("test called in fixedupdate frames"); }

VRChat is working on an improvement to Udon, VRChat's scripting system. Currently, World creators can write code in two different ways: Udon Graph UdonSharp VRChat is introducing a third way: Soba Creators can write Soba scripts in C#, similar to UdonSharp. Soba scripts are compiled to Microsoft's Common Intermediate Language (CIL). This allows Soba to use a variety of features that are not available in the Udon Graph or UdonSharp.

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.

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.

Many worlds have various small textures that could be higher or lower resolution depending on user preference. If users could opt-into having higher/lower resolution textures, then Quest builds could start out smaller (so as to meet the Quest world size limit), and users would have more control over their performance & experience in any given world. Players could also download new textures related to some optional add-on feature in the world. This can somewhat be achieved with image downloading, however that solution doesn't solve this problem for a couple reasons: The 5-second rate limit means you're incentivized to download large atlases for multiple textures, which is something some worlds can't feasibly do. But even if that were always feasible, if hundreds of textures need to be downloaded, the user would have to wait multiple minutes just for the world to initialize. Downloaded images can't be ASTC compressed, so they can't be as small as compressed local textures can be. If I could just upload one bundle of textures at a different resolution than those in the world to begin with, and set compression parameters to have the textures in the bundle compressed to ASTC, then have users download the entire thing at once for Udon to process at runtime, then all of those issues could be avoided. This would also be beneficial for downloaded text, not just images. You could even open this feature up to file types like audio clips or mesh files to give creators even more freedom/potential to create experiences they otherwise wouldn't have been able to before.