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.

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.

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

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.

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.

Make an Udon graph with your windows system language set to Swedish and place in a float with a decimal, say "0.3". Change your system language to English and open the same graph and it will remove the comma and convert the float to "3". The change is permanent and does not revert if you change the system language back.