World/Udon Bugs & Feature Requests

Starting with Build 1878 (Open Beta) and Build 1885 (Live), there's a change to pickup highlighting which relates to VRC_Pickup with SkinnedMeshRenderer. It is written that "We feel that the amount of content this affects is extraordinarily small", but I have some worlds which are affected by this change. Some of them are SDK2 worlds and it would be a lot of work for me to fix all of them. I guess that some world creators (including me) assumed that SkinnedMeshRenderers are completely ignored by pickup highlighting, and I used this property to control pickup highlighting: Shader-based gimmicks often change the appearance of the mesh. In SDK2, use of SkinnedMeshRenderer is convenient for hiding its internal mesh shape and expanding mesh bounds. To select the highlighting mesh of pickups containing multiple child renderers, sometimes I change some renderers to use SkinnedMeshRenderer. Also, I preferred using the (fallback) collider outline for pickup highlighting. In this SDK3 era, I basically agree with the changes because there's a correct way to fix the issues. But I guess some worlds may still use this old technique. I want to say: Some world creators really care about the shape of pickup highlights. If the highlighting reveals the strange internal shape, players' immersion will be broken. Please keep existing behaviour as it is. I feel component versioning (e.g. VRC_Pickup Ver 1.1) is a very good idea, and it should be used more! I propose increasing the VRC_Pickup version number and keeping the old highlighting algorithm for older versions. I'm really sorry for not checking or reporting during Open Beta. I've attached some screenshots of my worlds which show how the new highlighting unintentionally reveals the internal mesh. (To be honest, I might be the one who uses this bad trick the most, though...)

Tested with VRChat client build [1899]. VRCJson.TryDeserializeFromJson returns an incorrect string when valid JSON contains a supplementary Unicode character encoded as a UTF-16 surrogate pair. Reproduction code: string json = @"{""x"":""\uD83C\uDF63""}"; bool success = VRCJson.TryDeserializeFromJson(json, out DataToken root); Debug.Log("Success: " + success); if (success) { Debug.Log("Value: " + root.DataDictionary["x"].String); } Expected output: Success: True Value: 🍣 Actual output: Success: True Value: \uuDF63 The JSON is valid. \uD83C\uDF63 is the JSON surrogate-pair representation of U+1F363 (🍣). Deserialization reports success, but the resulting string does not match the value represented by the JSON.

The allowed world components page lists CharacterJoint as supported however, any attempt to use it in UdonSharp throws a TypeResolverException. The remaining Joint components do not throw an exception.

When calling SetLoops on a VRCTweenHandle created from VRCTween.DelayedCall, it is expected that the tween periodically invokes its callback according to the specified duration and loop count. In actuality however the tween invokes its callback once then terminates, as if SetLoops wasn't called at all.

Description When a mobile user interacts with a UI Canvas that has “Allow Focus View” enabled, clicking a teleport button does not teleport the player. The player remains in the same position until they manually exit Focus View. Expected Behavior Clicking a teleport button should immediately teleport the player, regardless of Focus View state. Suggested Fix Allow world creators to temporarily disable or override Focus View when necessary.

Defining a method parameter of a user-defined enum type with a default value causes the UdonSharp compiler to throw during binding. The same method compiles successfully when the default value is removed. This issue does not reproduce with Unity/SDK-defined enums (e.g., UnityEngine.HumanBodyBones , VRC_Pickup.PickupHand). Reproduction using UdonSharp; public class EnumTest : UdonSharpBehaviour { // Compile error public void TestMethod(TestEnum testEnum = TestEnum.ValueB) { } } public enum TestEnum { ValueA, ValueB, ValueC } Actual Behavior Compile fails with Assets/Main/Misc/Enum/EnumTest.cs(6,0): System.ArgumentException: Type provided must be an Enum. Parameter name: enumType at System.Enum.ToObject (System.Type enumType, System.Int32 value) at System.Enum.ToObject (System.Type enumType, System.Object value) at UdonSharp.Compiler.Symbols.ParameterSymbol..ctor (...) at UdonSharp.Compiler.Symbols.UdonSharpBehaviourTypeSymbol.CreateSymbol (...) ... (Full message attached below) The exception is thrown inside ParameterSymbol when UdonSharp tries to evaluate a parameter’s default value using Enum.ToObject(enumType, value) during compilation. For user-defined enums, this call receives an argument that is not recognized as a valid enum type for some reason, which causes System.ArgumentException: Type provided must be an Enum . Workarounds Avoid using default parameter values for enums and provide an overload as a pseudo-default instead public void TestMethod(TestEnum testEnum) { } public void TestMethod() => TestMethod(TestEnum.ValueA);

This can be an issue when using stations for vehicles with trigger zones. For example, i have a setup where i want audio to enable and disable based on the player location. This works fine with players, but to make it work with those vehicles i would need a second check for the vehicle.

ClientSim gathers the "PlayerPersistenceObjects" in ClientSimPlayer.cs before ClientSim removes objects that are tagged EditorOnly. This breaks the ClientSim initialization process, resulting in "_stackedCameraReady" never being set to true. This results in the menu's "ToggleMenu" function failing to close the menu, causing the user being unable to test their scene under this scenario.

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?

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.