World/Udon Bugs & Feature Requests

World creators currently have no way to prevent avatars from using collider-based flight (GoGo Loco, OpenFlight, etc.). The problem: Avatars can fly anywhere using collider exploits, bypassing intended world boundaries and progression. This also allows anyone to cheat in PVE/PVP games. World creators have zero Udon or SDK-level control to detect or prevent either of these Proposed solution: Add a World Descriptor toggle or Udon node to disable avatar collider-based flight (strip or ignore avatar colliders that interact with the player capsule) Add an option to block avatars from introducing new physics colliders at all. Expose these as per-world settings so social/hangout worlds can leave them enabled while game worlds can lock them down. This would be similar to how world creators can already disable avatar scaling — just extending that same philosophy to avatar physics exploits.

Attempting to add OnContactEnter and/or OnContactExit events via UdonSharp will cause CS0246 if you add ContactEnterInfo/ContactExitInfo parameters even if VRC.SDK3.Dynamics.Contact .Components is in the script. Without those parameters OnContactEnter/OnContactExit works fine. Tested on SDK 3.10.2 and 3.10.3-beta.1.

When a local user loses internet, the WebsocketPipeline Websocket immediately "explodes". A bool or callback function similar to OnPlayerLeft to detect this locally, as a way to differentiate whether networked events are coming from an illegitimate source spamming the function (such as someone using a modded client), or simply because the receiver was having connectivity issues and events were piling up. Using the WebsocketPipeline Websocket explosion seems like the most obvious implementation, but any bool and/or callback that can detect whether the local player has lost internet access would work. Fires when the local player's connection is lost: public override void OnLocalPlayerConnectionLost() { } Fires when the local player's connection is restored: public override void OnLocalPlayerConnectionRestored() { } Accessible bool: Networking.LocalPlayer.isConnectionStable

It'd be helpful for world creators to know how many people are entering their world as well as how often users are coming back.

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 do not know whether this is a bug or missing feature, but we cannot use Get function on Avatar Audio properties. If we can Set properties on them, shouldn't we be able to Get values from them too? What's missing: GetAvatarAudioGain() GetAvatarAudioFarRadius() GetAvatarAudioNearRadius() GetAvatarAudioVolumetricRadius() GetAvatarAudioForceSpatial() GetAvatarAudioCustomCurve() Side note: Player Audio's Documentation does not mention anything about GetVoice...() functions. Link: https://creators.vrchat.com/worlds/udon/players/player-audio

Try it out in this world: https://vrchat.com/home/world/wrld_0d5aae29-9ff4-4230-9697-cea19a896b79 When standing at the edge of a Box Collider (I have not tested other types of Colliders), .InPlayerGrounded() remains false incorrectly, while the player is still being held up by the Collider. The resulting chain of effects: Player retains velocity as if in mid air, thus creating a sliding effect along the direction the player was moving. While in this state, player cannot jump, just like in mid air. While in this state, player can move and change direction of the sliding (again, as if in a pseudo state of free falling mid air). While in this state, player is also continually being affected by gravity therefore can accumulate an infinite amount of downward velocity (minus Y) while in this sliding state or "gravity riding" state. When the player eventually exits this state (when his capsule is no longer being held up by the collider, or if he steps onto the collider properly), the massive downward velocity will snap the player to whatever floor surface is below the player in an instant, rather than the expected effect of start free falling with an initial zero downward velocity and slowly becoming faster like you would stepping off a high platform. Further testing or related bugs: The player capsule behaves differently while walking into different types of Colliders (e.g. Box Collider, Capsule Collider, Mesh Collider etc) so this effect might or might not appear with other colliders. But it certainly does with Box Colliders (test it in the above world).

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!

Current problem: Some worlds use an AudioListener-based workaround to simulate moving the user's ears to another point in the world, for example for dummy-head ASMR style effects. However, on Desktop, when the listening position is moved this way, distance and volume appear to follow the moved listening point, while directional localization (left/right directionality) still remains tied to the player's original viewpoint. As a result, the gimmick does not work correctly on Desktop. The same gimmick works as intended in VR. I have also confirmed a difference in PPC° between VR and Desktop in the Audio Sources Debug View. I can provide screenshots and other supporting material if needed. Use cases ASMR / dummy-head style "ear-level" audio presentation using a listening point placed in the world Observer camera / special viewpoint gimmicks where the visual viewpoint and listening point should be separated Audio-driven experiences where distance and direction should be designed around a specific in-world ear position Requested change Instead of relying on unsupported AudioListener-based workarounds, I would like an official and safe way for worlds/Udon to control the local user's listening position and orientation (listener transform). Requirements: It should work consistently on both Desktop and VR Directional localization should update correctly, not just distance attenuation / volume It only needs to affect the local user Network synchronization is not required Why the current workaround is insufficient AudioListener is not part of the allowlisted world components, so it is not an officially supported component for worlds Because of that, platform differences (such as Desktop vs VR) and future breakage are difficult to avoid VRChat already has official functionality such as Audio from Camera, which changes where audio is heard from For that reason, it would be very helpful to have a similarly official and safe way for worlds to specify a local listening point Scope / non-goals This is not a request to bypass normal audible range, occlusion, or existing voice distance rules This is not a request to force other players' listening positions to change A local-only solution is sufficient This is not intended for eavesdropping or expanding what a player is allowed to hear beyond normal rules Possible safety constraints would be fine, for example: Explicit per-world opt-in Local-only behavior Existing distance attenuation and audibility rules remain unchanged Minimal repro Minimal repro world: https://vrchat.com/home/world/wrld_c84d1e3b-d5bb-410d-b407-064b49fb56db Repro steps: Join in VR → the gimmick works as intended, with both distance and direction matching the moved ear/listening position Join on Desktop → distance / volume follows the moved listening position, but directional localization still remains based on the original player viewpoint If needed, I can also provide the following on request: A VR vs Desktop comparison video Debug View screenshots (Audio Sources: PPC°, Dist, lG/rG dB, d) VRChat version / build number

Suggestion: Option 1: In class VRCPlayerApi, create a bool method SetVisibility(bool) which defaults to true, for toggling the overall visibility of a particular player, which includes their avatar and nameplate and any chat box they may create. Option 2: Alternatively, create multiple toggles to control each element individually, such as SetAvatarVisibility() SetNamePlateVisibility() SetChatBoxVisibility() SetStickerVisibility() SetItemVisibility() etc. In my opinion the second option offer better granularity of control and allows a more creative use. Reason 1: Currently if we need to hide a remote player without changing their actual position, we need to exploit a desync station to achieve this effect. Surely that is not the intended use of a station and is in fact a bug. We should be allowed to modify a remote player's visibility with Udon, directly, without exploiting a bug. Meanwhile, world creators can transition to this method, thus allowing the station bug be fixed without affecting worlds that utilize it. Arguably this feature is a prerequisite of eventually fixing the station. Reason 2: We can already control the audibility of a player, via SetVoiceDistanceFar etc. Combining SetVisibility(false) with SetVoiceDistanceFar(0f) and SetAvatarAudioFarRadius(0f) you can make someone completely disappear. Or, alternatively, make someone invisible but can still be heard.