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.

When attempting to use String Loading to download a file through Udon, if for whatever reason the download never completes, neither the success or error functions will be called without any indicator or way to know what's going on. This is different with Image Loading where there's a progress float that tells us the progress of the download. https://creators.vrchat.com/worlds/udon/string-loading https://creators.vrchat.com/worlds/udon/image-loading This causes problems in practice because Udon will be waiting for a callback that will never be called, and we don't know if it's because of slow internet or a failure of the request that hasn't and will never thrown any error. Requesting parity for String Loading to be able to get the download progress, both so we can display the state to users as well as handle the scenario by providing fallback logic.

Components sometimes "break" in Unity 2022. They are collapsed, and expanding them reveals nothing. It affects different types of components, i.e. UdonBehaviours or MeshRenderers. It can be fixed by selecting a different game GameObject. In my world projects, it's caused by the following error: ArgumentNullException: Value cannot be null. Parameter name: unityObject VRC.Udon.Serialization.OdinSerializer.UnitySerializationUtility.SerializeUnityObject (UnityEngine.Object unityObject, VRC.Udon.Serialization.OdinSerializer.SerializationData& data, System.Boolean serializeUnityFields, VRC.Udon.Serialization.OdinSerializer.SerializationContext context) (at ./Packages/com.vrchat.worlds/Runtime/Udon/Serialization/OdinSerializer/Unity Integration/UnitySerializationUtility.cs:1031) UdonSharp.UdonSharpBehaviour.UnityEngine.ISerializationCallbackReceiver.OnBeforeSerialize () (at ./Packages/com.vrchat.worlds/Integrations/UdonSharp/Runtime/UdonSharpBehaviour.cs:272) UnityEditor.EditorApplication:Internal_CallGlobalEventHandler()

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.

I think it would be a nice idea to expose the player's currently set UI colors to Udon, so prefabs and Udon scripts could colorize things like accents, World UIs and even pickups, adding additional personalization that not only effects the players menu, but the world as well. It could also make the user experience more consistent, for example, If the user has a "Light Mode" type color scheme, the UI in things that use this feature would also be light themed. Or if your favorite color is Orange and your scheme uses different shades of orange, A pickup using this feature would change to that color when the user picks it up. Therefore, my point is I think this feature would be a nice and fun addition to Udon that would expand on the VRC+ only feature, and also make the feature more worth a benefit to get VRC+ for more personalization other then the QM/Big Menus.

I'm developing an asset in Udon that will allow players to teleport, send message, and perform other actions towards other players in the instance. I'd like the UI to not show players who are blocked by me, or players who are blocking me. I'd like Udon to provide a feature that can make such a determination. For example, something like VRCPlayerApi.IsBlocking. Such a feature would also help prevent accidents where two people who are blocking each other end up matching up in worlds that encourage random interactions between users.

I've found an issue with the Bounds.SetMinMax method in Udon. When using this method, it's expected that the Bounds object it's called on sets its min and max bounds to the supplied Vector3 values respectively. In testing, its values instead seem to stay completely unchanged. This issue does not appear when using the Bounds.min and Bounds.max setters directly. Below is a code snippet demonstrating the issue, along with the expected and actual log outputs. An UdonGraph screenshot is also included for completeness. Version info: Unity 2022.3.22f1 VRChat SDK - Base 3.10.3 VRChat SDK - Worlds 3.10.3 BoundsSetMinMax.cs: void Start() { var boundsTest = new Bounds(new Vector3(1, 2, 3), new Vector3(4, 5, 6)); Debug.Log($"New - {boundsTest}"); boundsTest.SetMinMax(new Vector3(1, 2, 3), new Vector3(4, 5, 6)); Debug.Log($"SetMinMax - {boundsTest}"); boundsTest.min = new Vector3(1, 2, 3); boundsTest.max = new Vector3(4, 5, 6); Debug.Log($"min, max - {boundsTest}"); } Output when executed as C#: New - Center: (1.00, 2.00, 3.00), Extents: (2.00, 2.50, 3.00) SetMinMax - Center: (2.50, 3.50, 4.50), Extents: (1.50, 1.50, 1.50) min, max - Center: (2.50, 3.50, 4.50), Extents: (1.50, 1.50, 1.50) Output when executed as U#: New - Center: (1.00, 2.00, 3.00), Extents: (2.00, 2.50, 3.00) SetMinMax - Center: (1.00, 2.00, 3.00), Extents: (2.00, 2.50, 3.00) min, max - Center: (2.50, 3.50, 4.50), Extents: (1.50, 1.50, 1.50) UdonGraph example:

Currently, PhysBone colliders field have a type of List<VRCPhysBoneColliderBase> . Which is not exposed to Udon. Maybe we can add a field with type of DataList , GetColliders() AddCollider() or other workaround.