World/Udon Bugs & Feature Requests

World creators currently have no way to prevent avatars from using collider-based flight (GoGo Loco, OpenFlight, etc.). The problem: Avatars can fly anywhere using collider exploits, bypassing intended world boundaries and progression. This also allows anyone to cheat in PVE/PVP games. World creators have zero Udon or SDK-level control to detect or prevent either of these Proposed solution: Add a World Descriptor toggle or Udon node to disable avatar collider-based flight (strip or ignore avatar colliders that interact with the player capsule) Add an option to block avatars from introducing new physics colliders at all. Expose these as per-world settings so social/hangout worlds can leave them enabled while game worlds can lock them down. This would be similar to how world creators can already disable avatar scaling — just extending that same philosophy to avatar physics exploits.

Current problem: Some worlds use an AudioListener-based workaround to simulate moving the user's ears to another point in the world, for example for dummy-head ASMR style effects. However, on Desktop, when the listening position is moved this way, distance and volume appear to follow the moved listening point, while directional localization (left/right directionality) still remains tied to the player's original viewpoint. As a result, the gimmick does not work correctly on Desktop. The same gimmick works as intended in VR. I have also confirmed a difference in PPC° between VR and Desktop in the Audio Sources Debug View. I can provide screenshots and other supporting material if needed. Use cases ASMR / dummy-head style "ear-level" audio presentation using a listening point placed in the world Observer camera / special viewpoint gimmicks where the visual viewpoint and listening point should be separated Audio-driven experiences where distance and direction should be designed around a specific in-world ear position Requested change Instead of relying on unsupported AudioListener-based workarounds, I would like an official and safe way for worlds/Udon to control the local user's listening position and orientation (listener transform). Requirements: It should work consistently on both Desktop and VR Directional localization should update correctly, not just distance attenuation / volume It only needs to affect the local user Network synchronization is not required Why the current workaround is insufficient AudioListener is not part of the allowlisted world components, so it is not an officially supported component for worlds Because of that, platform differences (such as Desktop vs VR) and future breakage are difficult to avoid VRChat already has official functionality such as Audio from Camera, which changes where audio is heard from For that reason, it would be very helpful to have a similarly official and safe way for worlds to specify a local listening point Scope / non-goals This is not a request to bypass normal audible range, occlusion, or existing voice distance rules This is not a request to force other players' listening positions to change A local-only solution is sufficient This is not intended for eavesdropping or expanding what a player is allowed to hear beyond normal rules Possible safety constraints would be fine, for example: Explicit per-world opt-in Local-only behavior Existing distance attenuation and audibility rules remain unchanged Minimal repro Minimal repro world: https://vrchat.com/home/world/wrld_c84d1e3b-d5bb-410d-b407-064b49fb56db Repro steps: Join in VR → the gimmick works as intended, with both distance and direction matching the moved ear/listening position Join on Desktop → distance / volume follows the moved listening position, but directional localization still remains based on the original player viewpoint If needed, I can also provide the following on request: A VR vs Desktop comparison video Debug View screenshots (Audio Sources: PPC°, Dist, lG/rG dB, d) VRChat version / build number

Recently, the number of sophisticated world gimmicks has increased, along with the increasing number of controls and settings. This has forced world creators to design their own UI menus and implement unique methods for accessing them. Especially in large worlds, users need to be able to access the UI menu from anywhere. For example, in VR, they can double-click the trigger, hold down the right stick, or use a gesture. On desktop, they can press the E or Esc keys. These methods can even interfere with the controls of the VRChat client, which has seen an increase in functionality in recent years. For example, pressing up on the right stick causes Vive Wand players to jump. Pressing the E key interferes with camera control. (One reason for this is that Udon cannot receive menu button inputs.) Meanwhile, users often become confused by or even fail to notice the different ways to access UI menus in each world. World creators must always provide guidance on how to access the UI menu. I know that in the past, development of a Udon UI accessible from QM was underway, but that work was suspended. https://ask.vrchat.com/t/developer-update-16-february-2023/16474#p-33374-udon-ui-in-the-quick-menu-14 https://ask.vrchat.com/t/developer-update-16-march-2023/16950#p-34625-update-on-udon-ui-9 https://ask.vrchat.com/t/vrchat-sdk-roadmap-may-2024/24243 From my perspective, a significant factor in this was the amount of time spent supporting smartphone platforms. Smartphone platforms have already been released for both Android and iOS. Now is the time to reboot development of Udon UI! --------------------原文-------------------- 最近、更に高機能なワールドギミックが増えて、その操作や設定も増える傾向にあります。そのため、ワールド作者はUIメニューを独自に設計し、独特な手段で呼び出す実装を強いられています。特に広域なワールドでは、ユーザーはどこからでもUIメニューを召喚できる必要があります。例えば、VRならトリガーをダブルクリックであったり、右スティックを下に長押ししたり、あるいはジェスチャーをしたり…デスクトップならEキーを押したりEscキーを押したり… これらは、近年機能の増えたVRChatクライアントの操作と干渉することさえあります。例えば、右スティックの上入力ではVive Wandのプレイヤーはジャンプしてしまいます。Eキーではカメラを操作しようとする時に干渉します。(理由の一端に、メニューボタン入力を Udon から取得できないのもあります) 一方でユーザーは、ワールドごとに呼び出し方の違うUIメニューに戸惑い、あるいは気付かない事もしばしば起こっています。ワールド作者は、常にUIメニューの呼び出し方を案内する必要があります。 私は、過去にQMからアクセスできるUdon UIを開発していて、しかし中断している事を知っています。 私の認識では、スマートフォンプラットフォームの対応に工数が取られていた事も重要な一因です。既にスマートフォンプラットフォームはAndroid, iOS共にリリースされています。今こそUdon UIの開発をリブートする時です！

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!

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.

gets if local player is has moderation perms (ie: world creator, instance creator, group moderator). I want my moderator room to available to members of any group that visits my world, as opposed to a static whitelist which unfairly favors my group's moderators (for clarification: by "moderator room" I mean "a small private meeting room used by moderators to have private conversations without having to leave the instance")

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.

The scientific notation for things like CPU frame time in the performance profiler make it almost impossible to quickly read values from it. Please change things like frametime to be represented in milliseconds as normal floats instead of currently nanoseconds in scientific notation

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.

Summary Large VRChat productions such as festivals, concerts, award shows, and panels increasingly operate like live broadcast environments. In these events a single world instance functions as the stage, while moderators, camera operators, DJs, presenters, and performers coordinate the show inside that instance. If a staff member crashes during a show, quickly returning to the stage instance is critical. Additionally, many performers and presenters join the stage hours after the event begins for their scheduled segment. Currently, reconnecting requires the normal world join flow, which depends on UI navigation and multiple API calls. During degraded platform conditions (API latency, matchmaking issues, networking outages), this process can become slow or unreliable. This proposal suggests a Stage Instance Recovery and Scheduled Access system allowing authorized users to securely rejoin or join a stage instance using tightly scoped tokens while preserving existing permissions and API validation. Problem Large VRChat events have operational requirements similar to live broadcast productions. A single stage instance may run for many hours while operators and performers must maintain continuous access. If a crash occurs, recovery currently requires: Restarting the client Resolving the world and instance through APIs Navigating UI or launch links Rejoining through normal matchmaking If services are degraded, this process may fail or take too long for live production needs. In addition, scheduled participants (performers, presenters, panelists, etc.) may need to join the stage instance hours after the event begins. Proposed Solution Introduce a Stage Instance Recovery and Scheduled Access system for designated event stage instances using two token types. Stage Recovery Tokens Issued when an authorized user joins the stage instance. The token is tied to: user ID world ID instance ID group ID group role session timestamp If the client crashes and restarts within a short recovery window, the client can present "Resume Stage Session" and attempt reconnection using the token before falling back to the normal join flow. Stage Access Tokens Issued to scheduled participants before their segment begins. These tokens are tied to: user ID world ID instance ID group ID participant role time window This allows performers and presenters to join the stage instance when their segment begins even if the event has been running for hours. API Behavior Under normal conditions, reconnect attempts still perform standard API validation. During a short recovery window, recovery tokens could allow the client to skip certain non-critical lookups and attempt direct reconnection to the existing stage session. If validation fails, the system falls back to the normal join flow. Role-Based Access Operator Recovery group admins moderators stage technicians camera operators DJs / event hosts Participant Access performers presenters panelists speakers award recipients Audience Audience members would not receive tokens. Security Recovery and access tokens remain tightly scoped: short expiration windows token system only available for event type main stage instance bound to one user and one instance role validation on reconnect/join server-side revocation rate limited reconnect attempts Tokens do not grant new permissions; they only allow users to resume or join sessions they are already authorized for. Benefits faster crash recovery for event operators reliable entry for scheduled participants improved resilience during partial service outages better support for large festivals, concerts, and live shows As VRChat continues hosting larger productions, stage-oriented recovery and scheduled access would help the platform support professional-scale events more reliably.