World/Udon Bugs & Feature Requests

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.

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.

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.

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.

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.

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 feature request is asking for a way for established world creators to earn expanded access to networking APIs (dynamic URLs, lower rate-limit floors on VRCStringDownloader and VRCImageDownloader , and related capabilities) that are currently only available to partner organizations like Furality (and I want to say Popcorn Palace, since it seems they query way faster than every 5 seconds according to VRCX). The pathway would be based on objective criteria such as published world count, total visits, account standing, and/or a verification process. For context, attached is a video from Alofoxx at Furality, talking about how they have less-restrictive API access as a Partner. I acknowledge that the scope of Furality is very different from a small world creator. However, I believe that more dynamic web API access could unlock so many more possibilities, especially as related to cross-world functionality that was never possible before. Current state VRChat's networking restrictions exist for good reasons: VRCUrl fields must be pre-baked at world upload; dynamic URL construction isn't allowed VRCStringDownloader has a 5-second floor between requests per URL VRCImageDownloader has similar throttles These protect against IP-grabber worlds, runaway request loops, and abuse from poorly-written or malicious Udon These are sensible defaults. They prevent a lot of harm. But they also wall off entire categories of integration that would otherwise be straightforward. Anything that talks to a live external service (a content backend, music sync, a leaderboard, an event hub) runs into them quickly. The gap Partner organizations get expanded access for exactly this reason: their events depend on it. But there's no clear path for a regular creator to reach a similar tier, even if they've shipped multiple stable worlds in good standing and are building something legitimate that needs the same capabilities. The current model is effectively binary: locked down, or partner. Precedent: the pieces already exist VRChat already has multiple pieces of this in production. When joining Furality worlds, users see a permission prompt asking whether to allow that world's expanded API access, and the user confirms before anything elevated happens. On top of that, VRChat has built OAuth2 integration that Furality and others can use, letting users authenticate into external systems using their VRChat account. The consent UI exists. The backend gating exists. OAuth2 issuance and identity bridging exist. The trust model has been working at scale for major events. What doesn't exist is any public-facing version of any of it. There's no documented policy, no application process, no published criteria. As far as creators can tell, it's all private agreements case by case. It would be reasonable to assume this might eventually open up more broadly, but VRChat hasn't communicated anything about that, so creators have no way to plan around it or work toward it. Proposal Introduce a middle tier (or tiers) accessible to creators who meet objective criteria. Possible gating signals: A minimum number of published worlds in good standing (e.g., 3+ public) Cumulative visits or unique users across the creator's worlds Account age and clean community guidelines history An optional verification step (Existing ID, organization confirmation, or a simple application) Per-world or per-capability grants, rather than all-or-nothing Capabilities could be granular: a creator might earn dynamic URL access without changing rate limits, or earn lower rate limits without dynamic URLs, depending on the use case. Safeguards Expanded access is per-creator (or per-world) and revocable on TOS violations Network activity remains attributable for audit The existing user-consent prompt (already used for partner worlds) continues to apply Worlds using elevated capabilities could be flagged in metadata so users can see what they're entering The initial bar can be set conservatively and adjusted as the system proves out Why this matters A lot of the most interesting work people are trying to build in VRChat (community hubs that reflect live state, music and audio tools that integrate with external services, persistent event spaces, integrations with platforms creators already use) is currently blocked, made awkward, or restricted to the closed garden of partner orgs. Opening a path to expanded access for trusted creators would unblock a significant amount of legitimate work without removing the protections that keep new and unproven worlds safe by default.

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.

Allow us to make http requests so we can join our owns API.