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.

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()

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.

Recently, the number of sophisticated world gimmicks has increased, along with the increasing number of controls and settings. This has forced world creators to design their own UI menus and implement unique methods for accessing them. Especially in large worlds, users need to be able to access the UI menu from anywhere. For example, in VR, they can double-click the trigger, hold down the right stick, or use a gesture. On desktop, they can press the E or Esc keys. These methods can even interfere with the controls of the VRChat client, which has seen an increase in functionality in recent years. For example, pressing up on the right stick causes Vive Wand players to jump. Pressing the E key interferes with camera control. (One reason for this is that Udon cannot receive menu button inputs.) Meanwhile, users often become confused by or even fail to notice the different ways to access UI menus in each world. World creators must always provide guidance on how to access the UI menu. I know that in the past, development of a Udon UI accessible from QM was underway, but that work was suspended. https://ask.vrchat.com/t/developer-update-16-february-2023/16474#p-33374-udon-ui-in-the-quick-menu-14 https://ask.vrchat.com/t/developer-update-16-march-2023/16950#p-34625-update-on-udon-ui-9 https://ask.vrchat.com/t/vrchat-sdk-roadmap-may-2024/24243 From my perspective, a significant factor in this was the amount of time spent supporting smartphone platforms. Smartphone platforms have already been released for both Android and iOS. Now is the time to reboot development of Udon UI! --------------------原文-------------------- 最近、更に高機能なワールドギミックが増えて、その操作や設定も増える傾向にあります。そのため、ワールド作者はUIメニューを独自に設計し、独特な手段で呼び出す実装を強いられています。特に広域なワールドでは、ユーザーはどこからでもUIメニューを召喚できる必要があります。例えば、VRならトリガーをダブルクリックであったり、右スティックを下に長押ししたり、あるいはジェスチャーをしたり…デスクトップならEキーを押したりEscキーを押したり… これらは、近年機能の増えたVRChatクライアントの操作と干渉することさえあります。例えば、右スティックの上入力ではVive Wandのプレイヤーはジャンプしてしまいます。Eキーではカメラを操作しようとする時に干渉します。(理由の一端に、メニューボタン入力を Udon から取得できないのもあります) 一方でユーザーは、ワールドごとに呼び出し方の違うUIメニューに戸惑い、あるいは気付かない事もしばしば起こっています。ワールド作者は、常にUIメニューの呼び出し方を案内する必要があります。 私は、過去にQMからアクセスできるUdon UIを開発していて、しかし中断している事を知っています。 私の認識では、スマートフォンプラットフォームの対応に工数が取られていた事も重要な一因です。既にスマートフォンプラットフォームはAndroid, iOS共にリリースされています。今こそUdon UIの開発をリブートする時です！

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!

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 from the relay server, 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.

I use an Oculus Quest 3S for my VRChat, and every time I attempt to put in a URL or watch a video it doesn't work. I've tried every method I can think of to fix or solve the issue, but none have worked. If you could please have it fixed for 3S and other VR users like me, that'd be amazing. I want to be able to watch videos on VRChat, but I can't if the video/media player situation remains unfixed. Thanks, have a great day/night

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); } } }

There is zero documentation on how the outline is even generated right now, so we can only guess and hope. Often times VRChat takes the pickup outline not from the attached collider, but from a random sub mesh. At the same time, the "selectable area" of a pickup is taken from the collider instead. This results in a counter-intuitive outline that doesn't match the expected grabbing area. Solution: We should be able to set the outlines ourselves so that it matches our desired outline. Ideally by assigning a mesh to the Pickup component. We should also be able to change this visible outline at runtime (via Udon) by assigning a different mesh when needed. This is needed for any pickup that can change its shape, e.g. a book that can be opened or closed. We should also be able to disable the outline entirely. People are already using PhysBones on Avatars to have "Pickups" that don't have an outline, so worlds should be able to do the same when needed. There are some other requests related to Pickups that are as old as Udon, but are worth being mentioned here: We should be able to set the pickup into the local player hand ourselves via Udon. We should also be able to disable "drop", so the pickup stays in the player's hand. Similar to how you can "disable exit" on a station. There are countless games where the player needs to hold an item the entire time and never drop it, and actually needing to hold it yourself is not very nice.

ParticlePhysicsExtensions has various methods for getting particle collision data. Currently these methods are not exposed yet, so we cannot retrieve that data. Examples: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnParticleCollision.html