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.

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

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.

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.

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.

Please let us access the position of the name plate, to let us add world-specific UI icons to it. Currently, we can estimate the position of the name plate from the player's position. @bobystar discovered that: > it may have something to do with the avatar's main bounding box (all bone sizes are 1m): I've attached bobystar's screenshot. So a workaround might be to access the player's avatar bounding box - if we have access to that 🤔

This will allow maps to have a day night toggle (or change the lighting in other ways) while still using backed lighting.

All flavours of SmoothDamp implementation in Udon Graph are completely broken What Unity SmoothDamp does In Unity source, Mathf.SmoothDamp has a parameter ref float currentVelocity which updates itself every frame. Note the ref . The Udon Graph situation Currently in Udon Graph, the Mathf.SmoothDamp node has a currentVelocity input and output. (Should also apply to similar functions that uses SmoothDamp, like Vector3.SmoothDamp and Mathf.SmoothDampAngle.) You can apparently plug in a variable for the input, and set the same variable with the output. However, because you cannot set more than one variable at the same time, once you have updated the currentVelocity dummy variable, when you try to get the current value float output, it will count as a second calculation using the updated currentVelocity meant for the next frame. So this cannot work. (See image) If you try to set variable of the current value first, and calculate the currentVelocity second, it will calculate using the newly updated current meant for next frame. Again, it cannot work. Trying to manually jiggle variables around for this frame and next frame does not work, the output current will somehow overshoot the target. Looking at the Unity source code again, this should not be possible. Something spooky is happening, and the only thing spooky is what Udon Graph might be doing with a ref parameter. (Idk what is going on) (See image) If the currentVelocity input and output is left unplugged, the node works. However, currentVelocity does not get updated every frame in-game, and will remain 0. The effect is that, the movement becomes hugely framerate dependant in a weird way, when it shouldn't. In Unity's original implementation, the overall time to reach a certain point should be about the same for different framerates, regardless of how many steps it takes. Testing I have confirmed these using some custom python code to simulate the duration to reach 0.95 when going from 0 to 1. Test 1 - measurements using Unity source code (This is what should happen) By simulating various framerates, the overall duration using Unity's original code (and making sure the currentVelocity is updated as it should). Notice it is largely framerate independent, except some small errors probably attributed to step sizes in the last frame: Time to reach 95% of the target at 15 FPS: 0.2667 seconds Time to reach 95% of the target at 30 FPS: 0.2667 seconds Time to reach 95% of the target at 60 FPS: 0.2500 seconds Time to reach 95% of the target at 120 FPS: 0.2417 seconds Time to reach 95% of the target at 150 FPS: 0.2400 seconds Time to reach 95% of the target at 200 FPS: 0.2400 seconds Time to reach 95% of the target at 240 FPS: 0.2417 seconds Time to reach 95% of the target at 280 FPS: 0.2393 seconds Time to reach 95% of the target at 300 FPS: 0.2400 seconds Test 2 - measurements using a modified source matching in-game results (This is what happens in-game if the currentVelocity input and output are left unplugged) Another simulation, this time the currentVelocity is manually sabotaged to not be update. The results matches the in-game obeservations. Simulated results: Time to reach 95% of the target at 15 FPS (without updating velocity): 0.4667 seconds Time to reach 95% of the target at 30 FPS (without updating velocity): 0.6667 seconds Time to reach 95% of the target at 60 FPS (without updating velocity): 1.1000 seconds Time to reach 95% of the target at 90 FPS (without updating velocity): 1.5667 seconds Time to reach 95% of the target at 120 FPS (without updating velocity): 2.0333 seconds Observed results in-game: 15 FPS, ~466 ms 30 FPS, ~666 ms 60 FPS, ~1100 ms 90 FPS, ~1567 ms 120 FPS, ~1.9 seconds Comments In my opinion, if Udon Graph implemented this correctly, currentVelocity should not be exposed (as input and output) at all, but should be run under the hood of Udon Graph, which is out of my hands. I guess , under the hood, Udon Graph just needs to make sure there is a variable put aside for each individual instance of these nodes to be used for saving and reading currentVelocity . But I don't know how it works under the hood so I will let the devs figure this out. I don't know if Udon Sharp has the same problem. References and how to replicate The world I used for testing is here: https://vrchat.com/home/world/wrld_8df1ce44-319d-4c67-b253-90f5bd1894b5 Unity source for reference: https://github.com/Unity-Technologies/UnityCsReference/blob/master/Runtime/Export/Math/Mathf.cs I also attached the two pieces of simulator codes, in Python. I ran the codes using Jupyter Notebook: https://jupyter.org/try-jupyter/notebooks/?path=notebooks/Intro.ipynb

When a player leaves the instance or enters a station, OnPlayerTriggerExit does not fire for any trigger colliders that they were in. This will break any system trying to count the players in an area. It is known that Unity will not fire OnTriggerExit when either deleting the collider or disabling colliders, but you must move the collider out of the area. Example world: wrld_d3e81903-54d6-4562-a968-2223c368906e World has a blue trigger area and will display when a player enters or exits. There is also a chair in the area. Test case 1: Have two or more players in the room. Have one player enter the area Have that player leave the instance. Note that a player exit trigger message is never displayed. Expected result would be that OnPlayerTriggerExit fires, which would then display the message Test case 2: Have one player enter the blue area. Have that player sit in the chair. Notice that player exit area does not fire. Have the player exit the chair. Notice that player enter does fire and the count is now off by one. Expected result would be that on entering a station (which disables the player collider), Player trigger exit fires.

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.