World/Udon Bugs & Feature Requests

Please let us access the position of the name plate, to let us add world-specific UI icons to it. Currently, we can estimate the position of the name plate from the player's position. @bobystar discovered that: > it may have something to do with the avatar's main bounding box (all bone sizes are 1m): I've attached bobystar's screenshot. So a workaround might be to access the player's avatar bounding box - if we have access to that 🤔

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.

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!

The scientific notation for things like CPU frame time in the performance profiler make it almost impossible to quickly read values from it. Please change things like frametime to be represented in milliseconds as normal floats instead of currently nanoseconds in scientific notation

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.

Imposters are amazing, but they can clash with many creative and interesting effects world creators can use within VRC. Projectors and camera effects show them as opaque, or invisible. Often times imposters generate impossibly huge, ruining experiences for everyone in the space when their outside bounds are visible. Please give us the freedom to disable them per-world, or even per-instance. Giving this option to world creators would expand creativity, and would not complicate the end-user experience any further. Alternatively, give imposters their own unity layer so they can be rendered separately.

Summary Large VRChat productions such as festivals, concerts, award shows, and panels increasingly operate like live broadcast environments. In these events a single world instance functions as the stage, while moderators, camera operators, DJs, presenters, and performers coordinate the show inside that instance. If a staff member crashes during a show, quickly returning to the stage instance is critical. Additionally, many performers and presenters join the stage hours after the event begins for their scheduled segment. Currently, reconnecting requires the normal world join flow, which depends on UI navigation and multiple API calls. During degraded platform conditions (API latency, matchmaking issues, networking outages), this process can become slow or unreliable. This proposal suggests a Stage Instance Recovery and Scheduled Access system allowing authorized users to securely rejoin or join a stage instance using tightly scoped tokens while preserving existing permissions and API validation. Problem Large VRChat events have operational requirements similar to live broadcast productions. A single stage instance may run for many hours while operators and performers must maintain continuous access. If a crash occurs, recovery currently requires: Restarting the client Resolving the world and instance through APIs Navigating UI or launch links Rejoining through normal matchmaking If services are degraded, this process may fail or take too long for live production needs. In addition, scheduled participants (performers, presenters, panelists, etc.) may need to join the stage instance hours after the event begins. Proposed Solution Introduce a Stage Instance Recovery and Scheduled Access system for designated event stage instances using two token types. Stage Recovery Tokens Issued when an authorized user joins the stage instance. The token is tied to: user ID world ID instance ID group ID group role session timestamp If the client crashes and restarts within a short recovery window, the client can present "Resume Stage Session" and attempt reconnection using the token before falling back to the normal join flow. Stage Access Tokens Issued to scheduled participants before their segment begins. These tokens are tied to: user ID world ID instance ID group ID participant role time window This allows performers and presenters to join the stage instance when their segment begins even if the event has been running for hours. API Behavior Under normal conditions, reconnect attempts still perform standard API validation. During a short recovery window, recovery tokens could allow the client to skip certain non-critical lookups and attempt direct reconnection to the existing stage session. If validation fails, the system falls back to the normal join flow. Role-Based Access Operator Recovery group admins moderators stage technicians camera operators DJs / event hosts Participant Access performers presenters panelists speakers award recipients Audience Audience members would not receive tokens. Security Recovery and access tokens remain tightly scoped: short expiration windows token system only available for event type main stage instance bound to one user and one instance role validation on reconnect/join server-side revocation rate limited reconnect attempts Tokens do not grant new permissions; they only allow users to resume or join sessions they are already authorized for. Benefits faster crash recovery for event operators reliable entry for scheduled participants improved resilience during partial service outages better support for large festivals, concerts, and live shows As VRChat continues hosting larger productions, stage-oriented recovery and scheduled access would help the platform support professional-scale events more reliably.

Right now VRChat's networking model relies on Photon Pun (or Fusion in shared mode, not really sure), in which there is no dedicated server authority, meaning players handle the synchronization and logic of the networked gameobjects. This was fine for a social platform, but VRChat is increasingly hosting competitive games, persistent RPG's, and complex experiences. The client authoritative model is becoming a serious bottleneck. Some of the current issues are: Ownership fragility: If a player crashes or has a bad connection, their owned gameObjects undergo a halt, meaning no data is processed, and no data is synced. A single disconnect can cascade into a broken game state for the entire instance. No real anti-cheat is possible: Right now VRChat relies on Easy Anti-Cheat, script integrity checks and relying on creators to make their Udon functions non-networked, essentially stopping the player's machine from lying. EAC is very weak and bypassable with enough determination and skill, meaning that in a client authoritative model where all clients are trusted this is going to be and is a nightmare for some world makers. The industry figured this out years ago: every competitive multiplayer game of scale (CS2, Valorant, Fortnite, Apex and even Minecraft) uses server authority as the primary defense, and use client side anti-cheat mostly as a supplement. Small Bandwidth: These limits exist because the relay fans data through individual client connections. As worlds get more complex, creators constantly hit these walls, needing creator intervention to load balance the ownership. Latency: If the master or gameObject owner lives very far away, it will cause slow response times for players near the relay server who are expecting low latency. This of course is a highly difficult task the way Udon works and everything is architected, it won't be easy, but I think with some modifications this could be possible: Keep current ownership with abstraction If instances became server hosted, keep the user ownership model with abstraction to make it work, this way legacy worlds keep working fine. Or keep them client authority with an optional way to opt in for server authority. Server owned gameObjects This essentially replaces the master, the master by default is the server. Let's say that in the UdonBehaviour you can tick an option called "isServerOnly", meaning that this gameObject when an instance is created, is owned by the server, and the server handles the syncing and serialization, because the server will be in charge of the game logic. The ownership can never be transferred to a client. Server validated persistence writes Currently PlayerData is written by whatever the client reports. With server authority, persistence writes for server owned data go through server logic where validated operations get committed. This eliminates the entire class of persistence manipulation exploits, since the client can never decide what data is committed to VRC servers. As a bonus this can increase write resiliency since it can handle data commits even if the client leaves the instance VRChat's client authoritative model was a pretty good starting point, but it feels like a bottleneck for serious games who want to make VRChat their platform of choice. Every UGC platform at VRChat's scale (Rec Room, Roblox, Fortnite and Core) use a server authoritative model, and I think this is the way forward for VRC's future.

With the Remote string loading and image loading, we should be able to dynamically construct endpoint url's to cater to different scenarios and offer more flexibility. I know other posts about this do exist, but I feel like VRChat won't really pay attention without there being more volume and input from the end users. Please upvote relevant requests and share your thoughts. I'm using this post to potentially share my feedback and idea, and offer a starting point for us to discuss on. I want to be able to kickoff my project in VRChat and the string loading with dynamic URL's will play a major role in making it a reality. I am assuming this was not possible because of "security" concerns, but let's face it that we offer users to block untrusted URL's as is and give them warnings. VRChat is not only a social platform, but a sandbox for creators in terms of avatar, world, and scripting content. I've developed essential tools on Garry's Mod and other sandbox games, and they had no problem letting scripts make API calls, despite the community having a dangerous and toxic userbase. This allowed me to let my clients configure "roles" and preferences from an external web portal. Are you afraid of data exfiltration? There are ways to do that already. Malicious URL calls? Anything on the internet can be malicious as is. We can't keep having this "Carebear" security mindset and keep it locked tight that severely limits our creativity, but look for accountability and flexibility. The security concern is admired, but now its necessary to send dynamic URL's for search queries when we deal with remote strings or images, otherwise we have no choice but to dump the entire dataset. I will just have to create hundreds of VRCURL's and just do a bunch of if/else's and download the entire "database" instead of feeding search queries to get specific datasets to save bandwidth and filter through the data set on the server side. Maybe to meet in the middle, we can be transparent of the requests to be made. Add a prompt to the end user stating that "This World is requesting permission to let your game send/receive content to and from http://xyz.com " and it would be whitelisted to that user individually. Any new URL's not on the list will prompt another permission request. It would Only apply to the domain name, and Subdomain only. Maybe prevent changing the domain/subdomain of the URL entirely. This can also allow the user to feel more confidence knowing that their "Untrusted URLs" is no longer a wildcard, but can consult a list to see which untrusted URL's they're permitting on their client. With your upcoming "Udon" menu implementation, it could be considered to have VRChat built-in user preferences specific to the worlds, and include the whitelist there of URLs the World has requested to communicate with.

When OSC was added for avatars a long time ago, it was promised to also add it for worlds, but world creators are still waiting for it to be added. Just like with Physbones, this hasn't happened yet and I'm afraid that world creators won't get OSC support because the focus seems to be fully on avatars. Is this still on the roadmap? OSC for worlds / Udon would allow concepts like speeach recognition, tracking world objects / pickups with Steam trackers (e.g. an IRL broom in a world where you can fly on a broom), DMX / light controllers in DJ worlds etc. MIDI is all we have in worlds right now and it's too limited and hard to implement for anything other than a music instrument.