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.

In comparison to DOTween's corresponding methods, VRCTween.Tween(Local)Rotation and Tween(Local)Path skips RotateMode/PathMode parameters. With original DOTween we can tweak subtle behavior of rotation amount and look-at direction respectively. Current VRCTween does not have them so we have to use Virtual Tweens to interpolate in that way (e.g. rotate Transform beyond 360°). Are they intentionally omitted? If so, what is the reason for that, for performance or API complexity? It may make VRCTween more attractive to export these types and take as parameters (in last position).

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.

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.

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.

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 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.

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.

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.

Hello VRChat Devs and World Creators, For a better formatted & More In Depth Version of this Feature Request that includes Images and Descriptions of each node, please go to my post on the Dev Forum: https://ask.vrchat.com/t/feature-request-give-udon-u-access-to-instance-information-group-information/27923 Due to the character limits on canny, I cannot put the full post here, Again, Please refer to the dev forum post linked above I propose adding the following Nodes: InstanceInfo IsUserInGroup DoesUserHaveRole GetGroupRules GetGroupDescription GetGroupBanner Now let’s go over some examples for how these nodes will benefit world creators. Determining the Instance Type is super useful as world creators can choose to enable/disable certain features of a world depending on the instance type. For example: In a Public instance I would make sure the permissions system is disabled and all staff objects will be disabled, While in a Group Public instance we would enable all the permission systems and enable staff objects. A notification could appear in front of the player when joining any Group Instance, informing them that they have joined a group instance and Groups can set their own rules. Using the “GetGroupDescription” and “GetGroupRules” Nodes, we can put the rules and description inside the world to make it easier for people to see the rules (cause lets be honest, nobody reads group rules before joining a group public) The “OnInstanceClosed” Event can be used to turn off an open sign at the entrance of a store or bar. The “IsUserInGroup” and “DoesUserHaveRole” Nodes can save world creators and group owners a huge amount of time and hassle, because groups can assign roles to players in the group and have those roles affect what abilities they have within the worlds, eliminating the need for world creators to create super convoluted permission systems for manually assigning roles to players. It can also be useful for things like Patreon/Paid Perks in a world, A lot of people still don’t use/don’t have access to the Creator Economy, or they simply use both. World creators need to set up an external GitHub.io site or a pastebin containing the usernames of paid supporters, and keeping track of people changing usernames and what not is very annoying, Remote string loading also poses the risk of people spoofing URLS to include their name in the list (and yes even though UDON Code Signing has been released, this is still an issue). Being able to access a Main Group for the world and checking if the player has a specific role will eliminate all these issues: * It doesn’t matter if a player changes their username as we won’t be comparing usernames from a list anymore. * Bad actors cannot spoof URLS since we are no longer loading URLS anymore. * Skilled Programmers can set up API applications to automatically add & remove players from roles depending on certain factors (like if they subscribed/unsubscribed) * Since we aren’t relying on external services like GitHub or pastebin anymore, we don’t need to worry about services going down or some people not having Untrusted URLS enabled. This is why I have included the “GroupID” Variable in the GroupAPI nodes, as having access to external groups would make that possible. Quick note: I have thought about people potentially abusing the GroupAPI to spy on players and see what groups they are in, but the amount of time this would take as well as the fact that the player actually has to be IN the world for the GroupAPI to check makes me think that people won’t go through all this trouble. Besides, you can see what groups people are in by simply visiting their profile. If you are really worried about it, you could just make it so if the user has the group hidden from everyone on their profile, it will not show them in the GroupsAPI. GetGroupBanner can be used for automatic decoration of a group instance, like changing a banner above the entrance to the group’s banner. Getting the GroupID of the group hosting an instance is crucial not only for the rest of the nodes but also having verification, What I would do is have a list of group ID’s that correspond to groups I know follow the guidelines set in place by us, and that they follow the VRChat TOS. If the current group ID is on the list then I can show a little “Trusted Group” Icon somewhere to inform new users that they can trust the group.