World/Udon Bugs & Feature Requests

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.

VRChat finally implemented Steam Audio ! And it's a lot easier to hear other players now.🥳 However, Steam Audio can do a lot more! Here's how Valve describes it on their website: > Go Beyond HRTF > Use fully-featured spatial audio attuned to the physical attributes of your in-game geometry. Combine accurate occlusion, reflection, reverb and HRTF effects for natural sounding immersion. The worlds SDK currently does not yet support Steam Audio, so none of the features above are available in VRChat yet. Please implement Steam Audio into the worlds SDK, or allow users to import it into the worlds SDK.

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.

VRChat currently assumes that all synchronized positions exist in a single global coordinate space. This approach works well for small and medium-sized worlds, but becomes a significant limitation for large-scale environments such as flight simulators, space simulations, vehicle worlds, and open-world experiences where players can travel far from the world origin. As synchronized objects and players move farther away from (0,0,0), floating-point precision gradually decreases due to inherent limitations of standard floating-point representation. This leads to visible jitter, unstable rendering, reduced spatial accuracy, and degraded VR comfort, especially in fast-moving environments. In VR, these issues become noticeable much earlier than on traditional flat-screen applications. Existing Demand and Workarounds The need for large-scale coordinate management is already demonstrated by existing world implementations. Several world developers have created custom systems that apply local coordinate offsets, player relocalization, or proxy-based movement systems in order to mitigate precision issues at large distances. These approaches often rely on re-parenting players, manipulating seat or attachment systems, or building custom synchronization layers on top of VRChat’s networking model. While these solutions demonstrate clear demand for improved large-scale spatial handling, they are inherently complex, fragile, and costly to maintain. They require per-player tracking, custom smoothing logic, edge-case handling for interactions with existing VRChat systems, and careful synchronization management. Even then, they remain partial workarounds rather than robust, general-purpose solutions. The fact that multiple independent world creators have converged on similar workarounds indicates a real and recurring need that is not currently addressed at the platform level. Proposed Solution Introduce a client-side Global Sync Offset that is applied uniformly to all synchronized spatial data. The offset exists only on the local client and does not modify any networked or server-stored data. VRChat’s networking model remains unchanged and continues to operate in a single consistent global coordinate space. Conceptually: Incoming synchronized positions: LocalPosition = NetworkPosition - Offset Outgoing synchronized positions: NetworkPosition = LocalPosition + Offset This ensures that all relative distances between objects and players remain identical, while allowing each client to maintain numerical stability by keeping relevant geometry closer to a local origin. The offset is applied strictly as a final transformation step after simulation and interpolation, but before rendering. Benefits Enables proper floating-origin systems for Udon worlds Improves stability for large-scale and high-speed environments Reduces floating-point precision issues far from the world origin Eliminates the need for complex per-player synchronization workarounds Preserves all existing networking assumptions and relative spatial consistency Requires no changes to server-side synchronization logic Important Note This system does not modify simulation, physics authority, ownership, or networking behavior. It only affects local client-side spatial representation of already-synchronized data. Potential API Example SetGlobalSyncOffset(Vector3 offset) GetGlobalSyncOffset() This feature would allow world creators to build significantly larger and more complex environments while remaining fully compatible with VRChat’s existing networking architecture.

When calling SetLoops on a VRCTweenHandle created from VRCTween.DelayedCall, it is expected that the tween periodically invokes its callback according to the specified duration and loop count. In actuality however the tween invokes its callback once then terminates, as if SetLoops wasn't called at all.

This might not be possible with the way the nodes work, but a Switch node of some kind would allow easier conditional selection within complex states.

It is currently not possible to construct VRCUrl at runtime. This makes it difficult to generate video URLs that require dynamic input to function, such as playing a video based on an arbitrary search query, or generating video URLs that utilize token based access or are limited by other conditions. Data leakage concerns are already mitigated with the Allow Untrusted URLs option.

For world creators: I'd like the ability to specify a property on a vrcstation (seat) or triggerbox that makes an entering avatar's physbones simulate relative to that local space rather than world space with the option to fully disable them as the extreme case. Ideally with optional per-chain targeting. This would help immersion on moving seats and platforms. Physbones currently simulate in world space, so when the platform moves, inertia drags the bones backward, they clip or flail even though the avatar isn't actually moving relative to the seat. Implementation could work similarly to contact receivers, but I'm open to whatever approach fits best. I'm creating a world with a moving vehicle, and multiple playtesters have reported their hair and clothing being dragged out while it was in motion. Another case: in worlds like Test Pilots, an avatar with a physbone-enabled skirt has the skirt flailing in front of the camera, badly hurting visibility.

Log the bool "value" argument for InputUse. Click your mouse and release. Expected: receive "True" once, receive "False" once Actual:

Add a setting for changing the player collider height. Including a setting to change the player collider to be based on the avatar user is wearing instead of the set base height set. If nothing is set then it would just default to the old 2m height. Possibly even have this to be able to be changed with Udon in game.