World/Udon Bugs & Feature Requests

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.

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

In VRChat SDK 3.10.5, a NoVariableSync UdonSharp behaviour appears to cause other behaviours on the same GameObject to switch from Manual to Continuous synchronization. We encountered this issue in our world, “すーはー式ごいた”. The issue is now resolved in our world by explicitly setting all affected behaviours to Manual. This is a world-side workaround; we have not confirmed a fix in the SDK itself. The current version of our world therefore no longer reproduces the original issue. Affected setup Each game piece had three UdonSharp behaviours on the same GameObject: KomaScript : Manual ManualSync_suuhar : Manual UdonImageOwnerSpriteRenderer : NoVariableSync We observed piece object positions rolling back and a drop in FPS due to excessively frequent 'OnDeserialization()' calls. Diagnostic findings During approximately four minutes of testing, our logs recorded: Over 40,000 deserialization callbacks, including identical to the previous reception. Increasing send timestamps on all duplicate receptions. 62 explicit RequestSerialization() calls, but 1,856 OnPreSerialization() callbacks and 1,856 successful OnPostSerialization() callbacks. For one piece, two explicit serialization requests resulted in 58 serialization callbacks over approximately 14 seconds, with a median interval of 0.239 seconds. Changing UdonImageOwnerSpriteRenderer from NoVariableSync to Manual , so that all three behaviours explicitly use Manual, resolved the reported issue in our testing. Suggested reproduction Add a Manual-synced UdonSharp behaviour with synced variables to a GameObject. Add another UdonSharp behaviour marked NoVariableSync . A NoVariableSync behaviour should remain compatible with Manual behaviours on the same GameObject without switching them to Continuous. Environment World: すーはー式ごいた ( https://vrchat.com/home/world/wrld_a68a2924-fb2c-4860-adef-d687853e4b79/info ) Unity: 2022.3.22f1 VRChat Worlds SDK: 3.10.5 VRChat Build Number 1903 Currently, resolved in the world using SyncMode.Any

Writing a U# program like so, will fail with: Method is not exposed to Udon: 'texture.SetPixelData(d, 0, 0)'. Even though it is exposed as UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D U# Code: var texture = new Texture2D( 2, 2, TextureFormat.RGBA32, false ); uint[] d = new uint[2 * 2 * 4]; texture.SetPixelData(d, 0, 0); However it will compile in udon graph, but the data input will be a Object[], and will crash with anything passed to it. Manually writing some udon assembly will compile again, but will also crash at runtime udon assembly: .data_start .export tex .export arr .export num0 .export num1 .export f .export tex_format tex: %UnityEngineTexture2D, null arr: %SystemSingleArray, null num0: %SystemInt32, null num1: %SystemInt32, null f: %SystemBoolean, null tex_format: %UnityEngineTextureFormat, null .data_end .code_start .export Test Test: PUSH, num1 PUSH, num1 PUSH, tex_format PUSH, f PUSH, tex EXTERN, "UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D" PUSH, tex PUSH, arr PUSH, num0 PUSH, num0 EXTERN, "UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid" JUMP, 0xFFFFFFFC .code_end udon assembly crash: VRC.Udon.VM.UdonVMException: The VM encountered an error! Exception Message: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'. Parameter Addresses: 0x00000000, 0x00000001, 0x00000002, 0x00000002 Cannot retrieve heap variable of type 'Single[]' as type 'Object[]' ---------------------- Program Counter was at: 80 ---------------------- Stack Dump: ---------------------- Heap Dump: 0x00000000: (UnityEngine.Texture2D) 0x00000001: System.Single[] 0x00000002: 0 0x00000003: 1 0x00000004: False 0x00000005: RGBAFloat 0x00000006: UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D 0x00000007: UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid ---------------------- Inner Exception: ---> VRC.Udon.VM.UdonVMException: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'.

In UdonSharpBehaviour class, the available method for OnPersistenceUsageUpdated is: public virtual void OnPersistenceUsageUpdated() It has no parameters, so the following documented signature cannot be overridden: public virtual void OnPersistenceUsageUpdated(VRCPlayerApi player) Trying to override the documented version results in a compiler error. It would be helpful to clarify whether the no-argument version is intentional (i.e., always referring to the local player), or if the UdonSharp stub is missing the correct signature.

Ownership can permanently desync between clients in an unexpected way The included script can generate such a desync, please assign a TMP text field to view it, then join with 2 clients --- Of note for anyone experiencing this, I've had some success mitigating it by overriding OnOwnershipRequest and returning true public override bool OnOwnershipRequest(VRCPlayerApi requestingPlayer, VRCPlayerApi requestedOwner) { return true; }

This used to be not an issue before, but now if you have a Non-trigger Collider (set to a Unity or Custom layer, excluding the Walkthrough layer since it already does what it is supposed to do but that's beside the point) that is set to exclude the Player/PlayerLocal layer, the player will still "collide" with it and be able to "walk" on top of the collider's surface while slowly descending as if they were using a flying avatar. They'll still be able to go through the collider, but the problem here is that they can stand on top of the collider when they shouldn't be.