World/Udon Bugs & Feature Requests

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.

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.

If you attempt to create an array of UdonBehaviours by naming the type VRCUdonUdonBehaviourArray, it does not get recognized as a valid Udon type and fails to assemble. The alternate special case type "VRCUdonCommonInterfacesIUdonEventReceiver" that's used in other places that takes the place of UdonBehavior doesn't have an array type of "VRCUdonCommonInterfacesIUdonEventReceiverArray" defined either. So at the moment we need to use arrays of Component to represent arrays of UdonBehaviours. This issue is probably related and seems like a workaround on the graph side or a bug that's hiding the issue: https://vrchat.canny.io/vrchat-udon-closed-alpha-bugs/p/udonbehaviour-variable-compiles-into-unityengineobjectarray-which-is-an-object

When making a method, and using an enum as a parameter, if a default value is set for that enum, UdonSharp spits out an error (full attached in errorlog.txt): [UdonSharp] Assets/TestCode.cs(7,0): System.ArgumentException: Type provided must be an Enum. Parameter name: enumType Making either the method or the enum does not solve this, using an integer in place of the default value does not solve this, and the error is only on the U# compiler side. The C# script is attached, and I'll repeat it here for completion: using UdonSharp; using UnityEngine; using VRC.SDKBase; using VRC.Udon; enum TestEnum {One, Two, Three} public class TestCode : UdonSharpBehaviour { void UdonEnumTest(TestEnum te = TestEnum.One){ Debug.Log(te); } } I love enums way too much to not use them like this:( tupper plz

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

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

As the PlayerData API doesn't support any¹ array types most creators resort to storing all their array elements as individual keys in PlayerData. This means most of the already strict data limit gets consumed by unnecessary and avoidable header. Please add all the UdonSync supported types to the PlayerData API. And for the love of all that is holy bitpack the bool array type before writing it to persistence. ¹ The only array type PlayerData currently supports is byte[] . The fact that we at least have this is great for experienced creators! But it leaves everyone else (who can't write their own serializer) in the dust. It's completely unreasonable to expect the average graph creator to "just" make their own serializer when they hit the currently claustrophobic persistence limits.

Allow world creators the ability to moderate their OWN worlds and issue their OWN bans. I'm tired of seeing crashers and exploiters in my worlds and kicking them is nothing. I want the ability to ban certain individuals from my worlds. There is absolutely no harm in doing this. Who is it going to hurt? The exploiters and cheaters. What if world creators abuse it and ban people from THEIR OWN worlds? Well it's their fault their world fails to gather a population. What else will this do? Allow world creators to suit the needs of their wanted audience. it will also help take the stress off of the actually game moderators. Thank you, Lucifer MStar - Creator of 30+ worlds including church of marriages. P.S. Communicate more with your community on what you are doing about these crashers and exploiters and maybe the heat and stress will die down. Honestly this is the most annoying thing communication.

Today, the most popular use case of the IVRCImageDownload is to share some picture with friends in VRChat. However, there is one big annoying behavior in IVRCImageDownload for this use case. That's 2048x2048 texture size limit. Therefore, I hope VRChat to have the feature that automatically scale the texture size down to 2048x2048. As described before, it's common to use IVRCImageDownload for sharing pictures with friends. There are several assets specifically designed for this use case such as Image Pad and ImageTablet . However, the 2048x2048 size limit is an annoying for this use case because today picture is likely to exceed this limit. For example, my iPhone 12 mini with default settings will take picture with 4032x3024 pixels and other modern smartphones also take high resolution image by default. In VRChat, I feel it’s common to choose take pictures in QHD, 4K, or 8K but none fits 2048x2048 limit. (FHD and HD fits 2048x2048 though we want to take high-quality pictures.) The texture downloaded with IVRCImageDownload become uncompressed RG, RGB or RGBA texture on the VRAM so It take huge VRAM. Therefore, I think it's reasonable to limit texture size on the VRAM. However, I think it's possible to resize texture down to 2048 off the main thread before loading to to the VRAM. That’s why I request VRChat to have the feature that automatically scale the texture size down to 2048x2048. 日本語要約 IVRCImageDownloadという Image Pad や ImageTablet のような画像を共有するためのアセットで使われている機能に対する要望です。 前述のタブレットではVRChatの制限により2048x2048より大きい画像を指定した場合にはエラーになりますが、エラーにする代わりに 2048x2048 以下に自動的にリサイズするオプションを追加してほしいという要求になります。 (技術的理由により2048x2048より大きい画像をそのまま表示するのは厳しいです) このオプションがあれば、Discordなどに上げた画像を共有するときにエラーが出て使えないという面倒事を減らせるようになります。

It will be nice to be able to use embedded video clips with the new video player system for things like video textures. Currently (on the open beta build 986) we can only load videos from external servers.