World/Udon Bugs & Feature Requests

If an avatar of a remote user is muted by calling VRCPlayerApi.SetAvatarAudioFarRadius(0) during OnPlayerJoined(), you cannot restore that avatar audio later by calling VRCPlayerApi.SetAvatarAudioFarRadius(40) under certain conditions. The avatar audio stays muted for you. The remote user can even disable and enable the audio toggle again, but it will still not be audible to you. Contrary to that, if the user joins and you don't call .SetAvatarAudioFarRadius(0) during OnPlayerJoined(), you can always toggle their audio on and off later without any issues. The issue also depends on the avatar setup: if the avatar audio is manually toggled via an animation after joining the world (e.g. a VRCFury toggle), the audio will never play, even if that animation is toggled again after unmuting the avatar. if the avatar audio is always-on, the audio behaves as expected, there is no issue. Avatars for testing: (VRCFury toggle) -> Bug happens https://vrchat.com/home/avatar/avtr_8897aa55-4877-4aac-bac2-1e3280e950f4 (OnLoad audio) -> Works fine https://vrchat.com/home/avatar/avtr_e77f5414-63b3-4d1b-aa7a-4b25cd299d48 World for testing: https://vrchat.com/home/world/wrld_717f7988-3503-4616-90b5-9d492d043b87/info Attached is the only script that is in the world and a screenshot of the decompiled VRCFury toggle. How to replicate: Join the world https://vrchat.com/home/world/wrld_717f7988-3503-4616-90b5-9d492d043b87/info Let a remote user with that avatar join ( https://vrchat.com/home/avatar/avtr_8897aa55-4877-4aac-bac2-1e3280e950f4 ) Let that user toggle their avatar audio on (via the expression menu) confirm that you can toggle their audio on/off with the button in the world toggle their avatar audio off with the button in the world let them rejoin let them toggle their avatar audio on (via the expression menu) confirm that you cannot hear their audio if you click the button in the world confirm that you cannot hear their audio, even if they toggle it off and on again (via the expression menu)

% operator (Remainder operator) is not exposed to Udon. This makes some operations impossible! I can't believe that this has been neglected since 2020. (I know https://feedback.vrchat.com/udon/p/long-remainder but it has been neglected since 2020 so I created new issue.)

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

Environment: Unity version: 2022.3.22f1 VRChat SDK Worlds: 3.10.3 VRChat SDK Base: 3.10.3 UdonSharp included with SDK Project uses Prefab Mode / PrefabStage with UdonSharpBehaviour components YamaPlayer package present: net.kwxxx.yama-stream 1.5.18 Observed: When opening or editing prefabs containing UdonSharpBehaviour components in Prefab Mode, Unity logs repeated ArgumentNullException errors from OdinSerializer UnitySerializationUtility. Error: ArgumentNullException: Value cannot be null. Parameter name: unityObject VRC.Udon.Serialization.OdinSerializer.UnitySerializationUtility.SerializeUnityObject(...) UdonSharp.UdonSharpBehaviour.UnityEngine.ISerializationCallbackReceiver.OnBeforeSerialize() and similarly: UnitySerializationUtility.DeserializeUnityObject(...) UdonSharp.UdonSharpBehaviour.UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() Trigger: Open a prefab containing UdonSharpBehaviour in Prefab Mode Move a child object or let PrefabStage autosave run Errors repeat, sometimes dozens/hundreds per save Expected: PrefabStage autosave should not throw if a Unity pseudo-null UdonSharpBehaviour or serialized target is encountered. It should skip invalid objects or handle UnityEngine.Object pseudo-null safely. Additional finding: For diagnosis only, I temporarily tested a local guard around the SDK serialization path. The test indicated that the affected object was not a normal C# null reference, but behaved as null through Unity's overloaded UnityEngine.Object null comparison. With that guard in place, the exception stopped. I am not using this as a permanent workaround and do not intend to publish content with a modified SDK. This observation is included only to help identify the likely failure path. Additional observation: I have encountered this issue twice. In both cases, once the issue started occurring in the project, checking out older repository commits did not reliably make the issue disappear. This suggests that the trigger may involve Unity Library/cache/generated SDK state or some project-local serialized state, not only the currently checked out asset files.

VRCSDK 3.7.5 Steps to Reproduce: Attach the VRC Enable Persistence component and VRC Player Object component to an object. Attach the following UdonSharp script to the same object. Execute Interact() in ClientSim. --- using UdonSharp; using UnityEngine; using VRC.SDKBase; using VRC.Udon; [UdonBehaviourSyncMode(BehaviourSyncMode.Manual)] public class VRCURLPersistenceTest : UdonSharpBehaviour { [UdonSynced] private VRCUrl testUrl; public override void Interact() { RequestSerialization(); } } --- Observed Error: When running the script in ClientSim, the following NullReferenceException occurs: --- NullReferenceException: Object reference not set to an instance of an object VRC.SDK3.ClientSim.Editor.VisualElements.Fields.FieldFactory.GenerateField[T] (System.String fieldName, T data) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/VisualElements/Fields/FieldFactory.cs:79) VRC.SDK3.ClientSim.Editor.VisualElements.EncodeDecodeEditors.ClientSimUdonEncodeDecodeEditor.GenerateFields (UnityEngine.MonoBehaviour component, VRC.SDK3.Data .DataDictionary data) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/VisualElements/EncodeDecodeEditors/ClientSimUdonEncodeDecodeEditor.cs:30) VRC.SDK3.ClientSim.Editor.VisualElements.ClientSimNetworkHolderInstanceElement.GenerateDataElements (System.Int32 index) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/VisualElements/ClientSimNetworkHolderInstanceElement.cs:72) VRC.SDK3.ClientSim.Editor.VisualElements.ClientSimNetworkHolderInstanceElement.UpdateData (VRC.SDK3.ClientSim.Editor.ClientSimPlayerObjectWindow+PlayerObjectData data) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/VisualElements/ClientSimNetworkHolderInstanceElement.cs:94) VRC.SDK3.ClientSim.Editor.ClientSimPlayerObjectWindow.UpdateCurrentPage (VRC.SDK3.ClientSim.ClientSimOnPlayerObjectUpdateEndedEvent e) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Editor/Windows/ClientSimPlayerObjectWindow.cs:259) VRC.SDK3.ClientSim.ClientSimEventDispatcher.SendEvent[T] (T clientSimEvent) (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Runtime/Events/ClientSimEventDispatcher.cs:62) VRC.SDK3.ClientSim.Persistence.ClientSimPlayerObjectStorage.LateUpdate () (at ./Packages/com.vrchat.worlds/Integrations/ClientSim/Runtime/Player/PlayerPersistence/ClientSimPlayerObjectStorage.cs:172) --- Workaround: Setting an initial value for the synced VRCUrl variable prevents the error: --- [UdonSynced] private VRCUrl testUrl = VRCUrl.Empty; --- Possible Cause & Suggestion: It seems that ClientSim does not handle null values properly when processing synced variables. Adding proper null handling for synced variables, especially for VRCUrl, may help prevent this error.

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.

Maybe this has been the case since VRChat supported SteamVR Input 2.0. Regarding the OnInputMethodChanged(VRCInputMethod inputMethod) argument, on smartphones and desktop PCs, it has the expected values such as VRCInputMethod.Touch and VRCInputMethod.Keyboard. Touch and VRCInputMethod.Keyboard. On the other hand, many VR controllers seem to have unified to VRCInputMethod.SteamVR2. This means that there is no longer a way to distinguish mainstream Vive Wand/Quest/Pico/INDEX controllers, etc. from Udon. This means that automatic tuning according to the characteristics of each controller is impossible. Are there any plans to fix this?

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.

This later results in errors when using the variable, as Unity complains you can't cast Object[] to UdonBehaviour[]. It stores UdonBehaviour as %VRCUdonUdonBehaviour It stores UdonBehaviour[] as %UnityEngineObjectArray

There is an undocumented limit on Network IDs. If you assign a Network ID beyond 10 000 to a PlayerObject its persistence features will break while the UdonBehaviour itself still functions and syncs. ClientSim throws the following error: ran out of player persistence view ids In-game testing results in Removed some Player Persistence metadata that had invalid IDs. errors. Apparently there is a limit of 100 000 for Network IDs in general, its way less likely to hit this, but this also seems undocumented. The difference in limit for PlayerObjects and standard UdonBehaviour objects is confusing and the provided errors don't accurately explain how to solve this issue. The Network ID Utility also does not seem to take this limit for Player Objects into account and does not warn or ensure a lower ID is assigned to the persistent objects. Furthermore, the Network ID Utility crashes on projects with this many Network IDs, but this was already documented here: https://feedback.vrchat.com/sdk-bug-reports/p/network-id-utility-has-massive-performance-issues