World/Udon Bugs & Feature Requests

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

Allow world creators the ability to moderate their OWN worlds and issue their OWN bans. I'm tired of seeing crashers and exploiters in my worlds and kicking them is nothing. I want the ability to ban certain individuals from my worlds. There is absolutely no harm in doing this. Who is it going to hurt? The exploiters and cheaters. What if world creators abuse it and ban people from THEIR OWN worlds? Well it's their fault their world fails to gather a population. What else will this do? Allow world creators to suit the needs of their wanted audience. it will also help take the stress off of the actually game moderators. Thank you, Lucifer MStar - Creator of 30+ worlds including church of marriages. P.S. Communicate more with your community on what you are doing about these crashers and exploiters and maybe the heat and stress will die down. Honestly this is the most annoying thing communication.

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.

Get what instance type you are in. Public, Friends, Friends+, Invite+, Invite Single node can return string Multiple nodes for each type can return bool

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

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

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