World/Udon Bugs & Feature Requests

This has been broken for a long while, since I can remember, Auto Hold does not work for Oculus, or Index, but does work for Desktop, and (last I checked) Vive.

This is hard to demonstrate in a screenshot, but: if you put a button on a wall, and then point your cursor at it, the "interaction text" tooltip that appears will always be behind the wall, causing an uncomfortable stereoscopic depth conflict (because it's drawn on top even though its position would be hidden behind the wall if it respected the Z buffer). Looking at this, my assumption would be that the tooltip is meant to hover above the button, rather than behind it? Or possibly even hovering in front of the button, precisely to avoid any possibility of it awkwardly sinking into the wall depending on the view angle.... but the current state, where it's like the interaction text is trying to get away from you, and will always cause a depth conflict as it does so, seems like it can't be intentional.

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.

Log the bool "value" argument for InputUse. Click your mouse and release. Expected: receive "True" once, receive "False" once Actual:

NavMeshAgent-controlled NPCs are unable to traverse NavMesh Links in the live VRChat client. The NPCs approach the beginning of the link, walk in place for a while, and eventually abandon their movement. The issue occurs even with a single NPC, so it does not appear to be caused by crowd avoidance. The same behavior was observed with the legacy OffMeshLink component. The issue has also been reported by another user following the October 2026 VRChat update. Environment Unity Editor: 2022.3.22f1 VRChat Worlds SDK: Updated to the latest available version ClientSim: Works correctly Live VRChat client: Traversal fails Steps to Reproduce Create two NavMesh surfaces at different heights. Connect them using a NavMesh Link. Configure a NavMeshAgent to move between the surfaces. Test in ClientSim: The NPC traverses the link successfully. Upload the world and test in VRChat: The NPC gets stuck at the beginning of the link. Expected Behavior NavMeshAgents should traverse NavMesh Links in the live VRChat client, as they do in ClientSim. Actual Behavior NavMeshAgents get stuck at the link entrance, walking in place without traversing it. Additional Information I have tried adjusting the link positions and width, enabling Auto Traverse Off Mesh Link, and updating the Worlds SDK, but the issue persists. Since the same issue occurs with both the legacy OffMeshLink and the newer NavMesh Link, this may be related to changes in the VRChat runtime following the Unity 6 migration. I would appreciate it if this could be investigated.

When a player leaves the instance or enters a station, OnPlayerTriggerExit does not fire for any trigger colliders that they were in. This will break any system trying to count the players in an area. It is known that Unity will not fire OnTriggerExit when either deleting the collider or disabling colliders, but you must move the collider out of the area. Example world: wrld_d3e81903-54d6-4562-a968-2223c368906e World has a blue trigger area and will display when a player enters or exits. There is also a chair in the area. Test case 1: Have two or more players in the room. Have one player enter the area Have that player leave the instance. Note that a player exit trigger message is never displayed. Expected result would be that OnPlayerTriggerExit fires, which would then display the message Test case 2: Have one player enter the blue area. Have that player sit in the chair. Notice that player exit area does not fire. Have the player exit the chair. Notice that player enter does fire and the count is now off by one. Expected result would be that on entering a station (which disables the player collider), Player trigger exit fires.

In some cirmustances when long text is pasted to to InputField and copied to clipboard, it in some situations got truncated to 200 characters. When debugged with "Inputfield.text" the text was the same, however when inputfield was interacted in VRChat the 200 character truncated text was shown. Changing the Input Field's linetype from "Single Line" to "Multi Line Newline", fixed the bug for me. This only started to happen in VRChat recently and I had no problems in Unity Play Mode.

Manual synchronization stops updating synced variables on non-owner clients with certain field configurations, despite the owner reporting successful serialization. In the failing cases, the non-owner receives OnDeserialization, but the synced fields remain at their initial values. ENVIRONMENT ──────────────────────── Unity: 2022.3.22f1 VRChat Worlds SDK: 3.10.4 Tested with actual VRChat clients in the same instance STEPS TO REPRODUCE ──────────────────────── Attach the provided Float20SyncProbe and Double20SyncProbe scripts to separate GameObjects. Assign a separate TMP text display to each script. Upload the world and join the same instance with two players. The owner assigns new values and calls RequestSerialization() every 10 seconds. Compare the owner's values with the non-owner's values on the displays and in the logs. Both scripts use Manual synchronization. Only the owner writes the synced fields. Neither script uses FieldChangeCallback or calls Networking.SetOwner. Despite their filenames, the attached scripts currently contain: Float20SyncProbe: 27 synced floats. Double20SyncProbe: 14 synced doubles and 1 synced int. EXPECTED RESULT ──────────────────────── The non-owner's synced fields should update to match the owner's serialized values. ACTUAL RESULT ──────────────────────── With the failing configurations, the non-owner's fields remain at their initial values. Reducing the number of synced fields restores normal synchronization. TEST RESULTS ──────────────────────── All configurations below were tested without FieldChangeCallback. 2 doubles : Worked 2 floats : Worked 13 doubles : Worked 26 floats : Worked 14 doubles : Worked 27 floats : Failed 14 doubles + 1 int : Failed 20 doubles : Failed Earlier tests also reproduced the issue with 20 doubles using FieldChangeCallback, while 20 floats worked. Removing FieldChangeCallback did not resolve the double20 failure. The results suggest that the amount or layout of synced data may be involved, but the exact cause is unknown. POSSIBLY RELATED REPORTS ──────────────────────── A single UdonSharpBehavior with VRC Enable Persistence cannot store more than 108 bytes of the same variable type https://feedback.vrchat.com/persistence/p/a-single-udonsharpbehavior-with-vrc-enable-persistence-cannot-store-more-than-10 PlayerObject Persistence Fails to Respect Sync Mode https://feedback.vrchat.com/persistence/p/playerobject-persistence-fails-to-respect-sync-mode Those reports concern Persistence restoration. This issue occurs during ordinary owner-to-non-owner synchronization within the same instance. REPRODUCTION MATERIALS ──────────────────────── The attached scripts reproduce the issue independently and display each client's local synced values, receive count, consistency check, and serialization result.

Client becomes unresponsive after opening the Net Tools view in the World Debug Menu when there are a large amount of UdonBehaviours in the scene. The UdonBehaviour foldout does not have to be opened for this to occur. Tested with 10,000 UdonBehaviours. Ideally, the Net Tools view would implement lazy loading for the UdonBehaviours when the foldout is opened, and not query for them when closed.

Summary The UdonSharp compiler compiles T[] declarations inside generic methods to an incorrect array type instead of the array type corresponding to the type argument. This issue occurs when T[] is used only within the method body and does not appear in the method's return type or parameters. Steps to Reproduce Create a UdonSharp script using the code below. Compile the script and inspect the generated Udon assembly, focusing on the code corresponding to each generic method invocation. Expected Result The array type should correspond to the specified type argument: GenericMethod<int>() : SystemInt32Array GenericMethod<float>() : SystemSingleArray GenericMethod<string>() : SystemStringArray Actual Result SystemInt32Array is used for all invocations. The corresponding array types for float[] and string[] are not generated. Reproduction Code using UdonSharp; public class GenericsArrayTypeBug : UdonSharpBehaviour { void Start() { GenericMethod<int>(); GenericMethod<float>(); GenericMethod<string>(); } public static void GenericMethod<T>() { T[] array = new T[0]; } } Generated Udon Assembly With SDK 3.10.5, the generated assembly uses SystemInt32Array for all three invocations, as shown in the following variable declarations: __lcl_array_SystemInt32Array_0: %SystemInt32Array, null __lcl_array_SystemInt32Array_1: %SystemInt32Array, null __lcl_array_SystemInt32Array_2: %SystemInt32Array, null The array constructor calls also use SystemInt32Array in all three cases: EXTERN, "SystemInt32Array.__ctor__SystemInt32__SystemInt32Array" Therefore, even when float or string is specified as the type argument, the array is compiled as the equivalent of int[] . Additional Observation When T[] is included in the method's return type or parameters, this issue does not occur, and the array type is generated correctly. Environment VRChat Worlds SDK: 3.10.5 Unity: 2022.3.22f1