World/Udon Bugs & Feature Requests

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

I would like to request support for efficiently converting byte[] data into Unity struct arrays in Udon, such as: Color[] , Color32[] , Vector2[] , Vector3[] , Vector4[] Ideally, this would be similar in spirit to System.Buffer , but extended to support Unity struct arrays. ## Background Currently, converting raw byte[] data into Unity struct arrays in Udon is not straightforward. While it is technically possible through indirect approaches, these require many Udon steps and become inefficient when handling large datasets. In an actual 3D model loader currently in use, this process may need to handle hundreds of thousands of elements, such as around 300,000 entries. ## Proposal Please add a way for Udon to convert byte[] data into Unity struct arrays, similar in spirit to System.Buffer . For example: Vector3[] vertices = new Vector3[size]; UdonBuffer.TryBlockCopy(byteData, byteIndex, vertices); This would make it possible to directly convert binary data obtained from external sources (such as data fetched from the web) into Unity struct arrays in Udon, without workarounds.

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!

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.

On the pride badge earned from the 2026 pride event, it would be nice to be able to change the pride flag to ones that help represent the user rather then just the rainbow pride flag

There should be a way to engage with a station without having to teleport the player; you would just remain at your current offset to the station. I tried to fake this in Udon by automatically moving the station's Enter Location transform right before calling UseAttachedStation, and it worked as far as the player's position is concerned, but at least in FBT, it would still always suddenly rotate my view: even if I made the Enter Location transform's rotation match the player's GetRotation before UseAttachedStation (like what worked for the position) even if I left the Enter Location transform's rotation as 0,0,0 even if the rotation of the station itself is also 0,0,0 Is there any existing way that I'm missing to make this happen; and if not, could it be added?

If you use an 'immobilize' station in FBT mode, you can still move around freely, until you travel a certain distance, at which point your avatar freezes in place. It would be nice if world creators could decide what this distance was, so FBT users could potentially wander a little more, while still not having their full movement/rotation controls on their joysticks.

Worlds can be set to "Align Room With Spawn Point", to make the virtual space line up with the real-world space of a VR player. This works great right up until the moment you touch one of your joysticks, at which point it's knocked out of alignment! There don't seem to currently be any workarounds for this: I tried disabling movement with functions like SetWalkSpeed, but that doesn't prevent right-stick turning I tried disabling both movement and rotation by using a station set to 'immobilize', but that caused my avatar to freeze as soon as I took a couple of steps away from spawn I'm not sure if it's even possible to disable the sticks themselves in SteamVR (their directional movements don't seem to be assigned to anything in the controller configurator), but I would like to leave them free to still be read by Udon scripts, for example Given the entire purpose of "align room with spawn point", it seems like it might make the most sense for it just to come with an option to entirely disable joystick movement and rotation when it's in use? (I know, "what would desktop users do", but, why would you be having desktop users in an "align room with spawn point" room in the first place?)

PlayerAPI already has controls for SetWalkSpeed, SetJumpImpulse, etc, which can be used to make the movement joystick do nothing (so it's free to control something in Udon instead). There should be a similar toggle to disable stick rotation as well, so both sticks can be used for Udon (and to prevent breaking the alignment in an "Align Room With Spawn Point" room).

This requests for the ability to create a variable of exposed enum types in UdonGraph. UdonGraph currently cannot make a variable of a variety of enum types such as: * EventTiming - For SendCustomEventDelayedSeconds and SendCustomEventDelayedFrames * QueryTriggerInteraction - For Physics > Raycast and similar * HumanBodyBones - For VRCPlayerApi > GetBonePosition and VRCPlayerApi > GetBoneRotation * VRCPlayerApi.TrackingDataType - For VRCPlayerApi > GetTrackingData UdonSharp is able to make variables of all of the listed enum types above and more.