World/Udon Bugs & Feature Requests

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'd be helpful for world creators to know how many people are entering their world as well as how often users are coming back.

I would like Udon Input to stop when the VRC camera is in a movement input state (middle-clicking the mouse, Fly mode, drone, etc.). Alternatively, a property that can detect when the VRC camera is in a movement input state could be exposed in VRCCameraSettings.photoCamera. This would allow gimmicks that make the player Immobile and use unique movement controls with InputMove, especially gimmicks that move the player while seated in a VRC Station, to coexist with camera/drone.

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!

Currently when a world loads, for example all VRCImageDownloader have to redownload their content, with a 5 second period between each. This both puts strain on hosts and also limits what we can do with worlds in a nice way since all non-bundled content has to be redownloaded every time. Not to mention it puts pressure on bandwidth for users. Ideally there should be a parameter on these functions to make a cached download request, at the very least for images/video, so it can be decided on a case-by-case basis (as this would of course not be desired for all cases where a URL is input by a user or is frequently changing on the source server.). If caching is enabled on the request and a local copy exists, you skip sending a request to the server and skip the 5-second cooldown on this downloader type, simply loading it from disk. This avoids the security concerns since no contact is made to the server. ----------------------------------------------------------- The cache could be stored as a sub-folder of a specific world, being shared across instances, which would make sense, and would make cleanup simple. But even more gains could be had from it being a global cache, so if I pasted the same URL in another world, it could instantly load it from my cache and any others who already have it cached, avoiding duplication of data. A simple dictionary file can be maintained and loaded on VRChat load to avoiding having to scan the cached files each time, as the amount of files could definitely grow pretty big. But a global cache like that isn't essential and would gladly give it up if it means implementing this request is more likely. Also, having an option to set the "TTL" (time to live) of the cached file would be a nice benefit too, though not an essential feature to have from the start. But would be pretty simple to add it as a saved property in the cache record data and compare it to the creation date and just do a redownload. (The local data should be encrypted using existing world encryption systems to prevent modifying the files and so there's no concern about illegal/awkward media ending up in a person's cache).

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 has been broken for a long while, since I can remember, Auto Hold does not work for Oculus, or Index, but does work for Desktop, and (last I checked) Vive.

We already have NetworkCalling.CallingPlayer, I think we should also be able to know which script is currently the entry point for a network call. This will enable defensive guarding against network calls in event methods without requiring the _ prefix. Not requesting a legacy change, just an extra data point to handle logic with. Semantically this would probably be more valuable for U# devs, but equally useful for UGraph devs too. This is how I would use it: public void MyNetworkProtectedAPIEvent() { // Guard against being called directly via SendCustomNetworkEvent if (NetworkCalling.InNetworkCall && NetworkCalling.CalledBehaviour == this) return; // beyond this, code continues as normal } This would enable making the method protected against _direct_ network calls, BUT still allows OTHER scripts to call the public API from _within their own network called scripts_. This effectively replicates the _ prefix conditions, but allowing for more proper C# naming convention at the cost of 3-4 additional externs. I imagine there are a few other uses such a data point would enable, but I haven't brainstormed that far just yet.

VRChat exists because creators build it. Worlds, avatars, systems, and tools only exist because people invest time, skill, and money into making them. Right now that foundation is being damaged by widespread asset ripping. This is not community drama. This is a platform enforcement and tooling problem. Asset ripping harms creators, weakens the Creator Economy, and reduces trust in VRChat as a platform. Reporting systems alone are not enough. What is needed is technical deterrence that makes ripping harder, traceable, and risky. Practical solutions VRChat can implement: Mesh and Asset Watermarking VRChat can mark uploaded meshes, textures, and animations in ways that are not visible in-game but remain after re-uploading or minor edits. This allows VRChat to identify re-uploaded ripped assets and track repeat offenders without affecting normal creators. Degradation of Unauthorized Exports Assets taken through unofficial extraction methods could become unreliable to reuse. This could include mesh issues, broken shading, animation problems, or other errors that do not affect legitimate uploads but make ripped assets undesirable. Creator-Controlled Protection Options Creators should be able to choose protection levels for their work. Paid or Creator Economy assets can use stronger protection, while free or open assets remain unaffected. Protection should be optional and creator-driven. Re-Upload Detection Beyond File Names Detection should not rely on simple file checks. VRChat can compare geometry, textures, and animations to identify stolen assets even if they are renamed, converted, or slightly modified. Automatic Enforcement for Repeat Offenders Once assets are flagged, enforcement should escalate. This can include upload restrictions, content locks, and permanent bans for repeat or large-scale ripping. Ripping should be higher effort and higher risk than creating. Clear Feedback for Creator Reports Creators need to know their reports matter. Report status tracking and confirmation when action is taken would increase trust and reduce frustration. Public Commitment to Creator Protection A clear public stance matters. VRChat should publish its approach to anti-ripping efforts and show that creators are actively protected. VRChat does not need perfect prevention. It needs consistent enforcement and real deterrence. Creators are the platform. Protect them. END VRCHAT RIPPING.

Directly loading media from servers or streaming endpoints is currently delayed by nearly 2 whole seconds due to everything being piped through yt-dlp regardless of whether it needs it or not. This causes unwanted delays when trying to use externally stored audio or video for various world interaction content (this is also why video content loading on Quest was so much faster before it gained the ability to use (or was forced to use) yt-dlp). Please provide a way for video players at the world level to bypass the yt-dlp lookup and just pass the URL directly to the respective video engine.