World/Udon Bugs & Feature Requests

Tested with VRChat client build 1896. I would like to report an issue with VRCJson.TryDeserializeFromJson. There appear to be cases where valid JSON fails to deserialize when an object is nested two or more levels deep and a string inside the nested object contains a brace character ( { or } ). The exact behavior appears to depend on the nesting depth and the brace character. It is not the case that every brace inside every nested object fails. For example, a closing brace ( } ) inside a string at the third nesting level can deserialize successfully. Braces inside JSON strings should always be treated as ordinary string characters and should not affect the surrounding object structure. The following valid JSON objects fail to deserialize: { "x": { "y": "{" } } { "x": { "y": "}" } } { "x": { "y": { "z": "{" } } } Reproduction code: string json1 = @"{ ""x"": { ""y"": ""{"" } }"; bool success1 = VRCJson.TryDeserializeFromJson(json1, out DataToken result1); Debug.Log(success1); Debug.Log(result1.ToString()); // Expected: true // Actual: false // // UnableToParse: Unable to Deserialize from Json: // Found end of string before finishing object string json2 = @"{ ""x"": { ""y"": ""}"" } }"; bool success2 = VRCJson.TryDeserializeFromJson(json2, out DataToken result2); Debug.Log(success2); Debug.Log(result2.ToString()); // Expected: true // Actual: false // // UnableToParse: Unable to Deserialize from Json: // Found unexpected character '"' while looking for character ',' string json3 = @"{ ""x"": { ""y"": { ""z"": ""{"" } } }"; bool success3 = VRCJson.TryDeserializeFromJson(json3, out DataToken result3); Debug.Log(success3); Debug.Log(result3.ToString()); // Expected: true // Actual: false // // UnableToParse: Unable to Deserialize from Json: // Found end of string before finishing object // Control case: this valid JSON deserializes successfully. string control = @"{ ""x"": { ""y"": { ""z"": ""}"" } } }"; bool controlSuccess = VRCJson.TryDeserializeFromJson(control, out DataToken controlResult); Debug.Log(controlSuccess); Debug.Log(controlResult.ToString()); // Expected: true // Actual: true This may be related to the previously reported issue: "VRCJson.TryDeserializeFromJson may still incorrectly parse arrays when strings contain brackets" ( https://feedback.vrchat.com/udon/p/vrcjsontrydeserializefromjson-may-still-incorrectly-parse-arrays-when-strings-co ) That report is marked complete, but similar parsing failures remain reproducible with braces inside string values in nested JSON objects in client build 1896.

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);

% 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.)

This is problematic in a few situations, and this other issue makes it even worse: https://vrchat.canny.io/vrchat-udon-closed-alpha-bugs/p/playerapi-humanbodybones-do-not-have-a-consistent-rotation-every-avatar-is-diffe 1) It is, as far as I can tell, completely impossible to get the correct rotation of a remote user's head without syncing an object's position/rotation. 2) generic avatars will give you positions at 0,0,0 3) desktop users tracking data locally will give you hand positions out in front of the camera, in the position that the object would be if they were holding a pickup. This is a useful emulation and doesn't function for remote clients.

When attempting to use String Loading to download a file through Udon, if for whatever reason the download never completes, neither the success or error functions will be called without any indicator or way to know what's going on. This is different with Image Loading where there's a progress float that tells us the progress of the download. https://creators.vrchat.com/worlds/udon/string-loading https://creators.vrchat.com/worlds/udon/image-loading This causes problems in practice because Udon will be waiting for a callback that will never be called, and we don't know if it's because of slow internet or a failure of the request that hasn't and will never thrown any error. Requesting parity for String Loading to be able to get the download progress, both so we can display the state to users as well as handle the scenario by providing fallback logic.

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.

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;

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?

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