World/Udon Bugs & Feature Requests

VRCStations which are on game objects attached to PlayerObjects do not work because PlayerObject instances don't exist at upload time and are instantiated at run time, and stations must exist in the hierarchy at upload time to function. This makes PlayerObject completely incompatible with VRCStation (and I doubt it's fixable, so I won't even ask), but this limitation is not mentioned anywhere in the PlayerObject documentation. Please add this important piece of information.

If you use VRCPlayerApi.SetVoiceDistanceFar() or VRCPlayerApi.SetVoiceDistanceNear() The the value seems to get clamped to a maximum of 10000. I would like the maximum range to be as high as possible for stuff like aircraft radios.

VRChat Version: VRChat SDK - Worlds 3.7.5 VRChat SDK - Base 3.7.5 Description of the bug: When using the params keyword in U# extension methods, the first argument is missing. Steps to reproduce (how did you encounter the bug?): It can be reproduced by executing the following code. public class SampleUdon : UdonSharpBehaviour { void Start() { this.SampleMethod("test0", "test1"); } } public static class SampleUdonExtensions { public static void SampleMethod(this SampleUdon self, params object[] args) { Debug.Log($"ArgsLength: {args.Length}"); for (var i = 0; i < args.Length; i++) { Debug.Log($"Args[{i}]: {args[i]}"); } } } Output ArgsLength: 1 Args[0]: test1 Expected Output ArgsLength: 2 Args[0]: test1 Args[1]: test2

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.

It seems like the operator ">=" acts like ">" and therefore gives wrong results. But only when one of the comparisons is a variable. I think the example below explains it better than words. Define Example enum: public enum TestEnum { ONE, TWO } Then call: var max = TestEnum.TWO; max >= TestEnum.TWO; The result will be FALSE, and not TRUE like it should be. Conversely, this results in TRUE correctly: (int)max >= (int)TestEnum.TWO; And this works too: TestEnum.TWO >= TestEnum.TWO;

Both of these solutions always return false, a friend tested using HTC Vive + Vive Wands bool viveWorkaround; public override void InputDrop(bool isTrue, UdonInputEventArgs args) { Debug.Log(viveWorkaround); } Attempt 1: void Start() { viveWorkaround = InputManager.GetLastUsedInputMethod() == VRCInputMethod.Vive; } Attempt 2: public override void OnInputMethodChanged(VRCInputMethod inputMethod) { viveWorkaround = inputMethod == VRCInputMethod.Vive; }

Setting a synced array to be null causes serialization to fail.

Currently the VRCObjectPool component allows the user to return a specific Game Object from the pool via the Return(Gameobject obj) method. However it does not allow the user to spawn a specific Game Object from the pool via the TryToSpawn() method. It would be beneficial to users to provide a lightweight option to spawn a specific object using the VRCObjectPool component. This would make it easier for new and experienced World Creators to spawn specific objects, in a simple manner, without having to rely on complex systems to manually synchronize the active states of objects.

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?

Since GoGoLoCo has become more prevalent and embedded in more and more avatars, the fundamental incompatibility between GoGoLoCo and VRCStations on vehicle (and other) systems is now commonplace enough that it has made debugging of station ergonomics as complicated as possible - which actively deters world devs from considering accessibility in their systems. This has been going on for several months at least, and it's out of control. The issue seems to be that GoGoLoCo has unstoppable and extremely inappropriate access to the Station's animation controller variable and blocks it, preventing the player from being able to move normally (or even be upright in some cases), and preventing scripts from doing anything to fix it. This is just my guess, so it may even be more complicated than that. We don't know. We don't have the source code, so who knows? But this can be reproduced across different worlds, different avatars, same parameters. This breakdown usually renders whatever the station is attached to inaccessible to the player because it defeats all attempts to make it accessible and the world dev and player are both powerless to stop it. At this point in time, this makes worlds using vehicle prefabs entirely inaccessible to players who do not know about this issue and understand that GGL is 100%, hopelessly and irrevocably incompatible with VRCStations. You can't expect casual or new players to discover this instantly, and this is having an effect on the perceived viability of afflicted systems going forward, which deters their development and adoption of new SDK features. There is simply no reason to sink time and effort into developing vehicle systems or other things which move the player since GoGoLoCo is allowed to run rampant all over the Worlds SDK, ruthlessly enforcing its own, unintentional, and unofficial rules over VRChat's own. Allowing GoGoLoCo to dictate what players can and cannot interact with is shaping the platform and eliminating options for gameplay which previously existed, and creates the impression that VRChat does not have control over the SDK. Normally, this wouldn't have been allowed to get this far. Now it's too late to fix this by any means other than fixing VRCStation to harden it against this attack. At this point, I cannot continue to develop anything around VRCStation, or advise anyone to do so until VRCStation has been fixed to prevent GoGoLoCo from hijacking it. Obviously you can't ban GoGoLoCo because that would brick like half of the avatars on the platform, so the only option is to fix VRCStation. Fix VRCStation. Fix VRCStation. The unthinkable task: Fix VRCStation. Please do something before we give up on you.