World/Udon Bugs & Feature Requests

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.

World creators currently have no way to prevent avatars from using collider-based flight (GoGo Loco, OpenFlight, etc.). The problem: Avatars can fly anywhere using collider exploits, bypassing intended world boundaries and progression. This also allows anyone to cheat in PVE/PVP games. World creators have zero Udon or SDK-level control to detect or prevent either of these Proposed solution: Add a World Descriptor toggle or Udon node to disable avatar collider-based flight (strip or ignore avatar colliders that interact with the player capsule) Add an option to block avatars from introducing new physics colliders at all. Expose these as per-world settings so social/hangout worlds can leave them enabled while game worlds can lock them down. This would be similar to how world creators can already disable avatar scaling — just extending that same philosophy to avatar physics exploits.

This provides an easy way to convert dynamic colors to html for use in tmp as tmp allows users to use tags to adjust aspects of the text. https://docs.unity3d.com/ScriptReference/ColorUtility.html

Now that web connectivity will likely require some form of consent from the user when using Udon, I think it's a reasonable request to ask for an actual unique user ID that we can use to identify users. This could be used to do things like enable a debug console in the world, or when web connectivity is back, save progress or settings in a world. Right now people are using display names as "unique" identifiers which isn't good and already has issues since it's a display name. One issue is https://vrchat.canny.io/vrchat-udon-closed-alpha-bugs/p/onplayerjoined-doesnt-get-full-displayname-for-steam-users Another issue is that "special" characters like "." get replaced in the display name with lookalikes which breaks string comparisons. Relying on display name to "uniquely" identify people will become more prevalent as time goes on and people make commonly used systems that depend on them. You should expose this sooner rather than later to avoid this issue. The potential for abuse is obviously possible, but there's no reason to kneecap the systems and introduce potential issues by leaving only display names visible. Right now I can reasonably target people with just their display names, it's just possible that there will be some more people with the same name that get targeted. Worlds abusing names to harass people is something that should be reported on a world basis.

The new auto-hold feature for Pickups is great! From what I have heard from players throwing staffs around while casting magic is that they accidentally trigger the drop event way more often than they wished for, most toggle it off for this reason and are back to the fatigue of holding it all the time. I have some ideas that could make it harder to trigger unintentionally while in action: A quick double grab to drop. If the Pickup is held and stuck in auto-hold and a new grab event is registered but keeps being held for a while, make it stay again. Only a short grab while in auto hold drops the Pickup. If the Pickup is held and stuck in auto-hold, the user has to grab it and hold it until a progress bar is complete and then it drops when the grip is released.

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.

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.

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.