World/Udon Bugs & Feature Requests

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!

Get what instance type you are in. Public, Friends, Friends+, Invite+, Invite Single node can return string Multiple nodes for each type can return bool

I would like to request support for passing values directly from uGUI to Udon, by providing public fields or properties in Udon for types commonly used by standard uGUI events. ## Background Currently, passing values from uGUI into Udon is not always straightforward. If the UI is static and predefined, this can be handled by assigning references from Udon to specific uGUI elements in advance. However, problems arise when UI elements need to be created dynamically. In my case, when dealing with such dynamic UI, I end up using workarounds such as: keeping references from uGUI to Udon, which still requires locating the relevant UI element from the Udon side identifying the calling object indirectly via MeshRenderer.probeAnchor (since Transform can be assigned from uGUI events) These approaches are technically possible, but they do not lead to a natural or scalable implementation. They often require indirect patterns or additional setup, especially when working with dynamically instantiated UI. Another possible approach is to attach a separate Udon behaviour to each UI element. However, using Udon components only to pass UI values introduces unnecessary overhead and does not scale well. ## Proposal I propose adding public fields or properties in Udon for types supported by standard uGUI events, such as: string (Input Field) bool (Toggle, ) int (Dropdown) float (Slider, Scrollbar) Vector2 (Scroll View) UnityEngine.Object This would allow a uGUI event to: write a value directly into a Udon behaviour call a CustomEvent let Udon read the value from the assigned input field or property ## Why UnityEngine.Object should be included I would also like UnityEngine.Object to be supported. This would allow a uGUI element to pass a reference to itself, making it much easier for Udon to identify the source of the event. Compared to current indirect methods, this provides a more direct and understandable way to determine which UI element triggered the interaction. ## Example of the intended flow A typical flow would look like this: A uGUI event assigns a value to a Udon behaviour The same event calls SendCustomEvent The Udon behaviour reads the value and handles it Conceptually: using UdonSharp; using UnityEngine; public class UiReceiver : UdonSharpBehaviour { // These are assumed to be provided by Udon itself // public string InputString { get; set; } // public UnityEngine.Object InputObject { get; set; } public void _OnUiTriggered() { Debug.Log(InputString); if (InputObject != null) { Debug.Log(InputObject.name); } } }

I would like to request a single, pre-defined static DataDictionary public field that can be freely used in Udon. (This is not a request to allow users to define arbitrary static fields in U#.) ## Background Currently, Udon (U#) does not allow defining static fields. As a result, sharing state or references across multiple components often requires alternative approaches. At least in my case, when trying to implement a singleton-like pattern, I tend to rely on search-based approaches such as GameObject.Find . This can lead to increased computational cost due to repeated search operations. ## Proposal I propose adding one shared static DataDictionary public field, provided by Udon itself. The idea is: Users do not define static fields themselves Instead, a single shared DataDictionary is provided by the system All Udon/U# scripts can access it By limiting this to a single DataDictionary, it keeps the scope controlled while still enabling many practical use cases. ## Benefits Having a shared DataDictionary would make it easier to: Avoid repeated GameObject.Find calls Share references across systems in a more flexible way ## Expected Behavior The shared DataDictionary is expected to behave as instance-scoped temporary storage: Initialized when joining a world Cleared when leaving the world ## Example Usage Example of registering a reference: using UdonSharp; using UnityEngine; using VRC.SDK3.Data; public class GlobalRegistry : UdonSharpBehaviour { private const string Key = "__global_registry_player_manager__"; private const string ObjectName = "__UdonGlobalRegistry_PlayerManager__"; public static GlobalRegistry Instance { get { if (!UdonSharedData.TryGetValue(Key, out DataToken token)) { GameObject obj = GameObject.Find(ObjectName); if (obj == null) return null; GlobalRegistry instance = obj.GetComponent<GlobalRegistry>(); if (instance == null) return null; UdonSharedData[Key] = instance; } return (GlobalRegistry)token.Reference; } } } Example of retrieving it: using UdonSharp; using UnityEngine; public class SomeSystem : UdonSharpBehaviour { public override void Interact() { GlobalRegistry instance = GlobalRegistry.Instance; if (instance != null) { Debug.Log(instance.name); } } }

A simple few bools that would add IsDesktop, IsPCVR & IsQuest to the VRCPlayerApi class. This would make life a lot better for world creators.

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.

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.

we want maxmimum 200 person instance could be selsect