World/Udon Bugs & Feature Requests

Here is how the remote player collider looks: https://global.discourse-cdn.com/vrchat/original/3X/4/5/45bf8cf5343d645a5e99baab04cb6cf8dd8a1dde.png Here is how it should look: https://global.discourse-cdn.com/vrchat/original/3X/0/3/03401491f88a848f31438f482624ed0fa096e91a.png

As an example, if player A blocked player B, and player B enters a station, the OnStationEntered event is not triggered on player's A side. This can break some prefabs or worlds that rely on those events. There may be other events where it could cause some issues, but that's the one event I noted, I didn't tested other events like OnPlayerTriggerEnter.

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.

When a player is on a station, being moved outside the collision of a component with udon and the OnPlayerTriggerExit event, does not actually activate OnPlayerTriggerExit The same goes for OnPlayerTriggerEnter. It's possibly one of the most egregious udon bugs in VRChat, and it's been untouched for years.

I have encountered a problem related to Unity's DSP chain and Udon. I am planning to create an audio focused world, where I need to implement a custom DSP algorithm on audio that can respond to player behavior/controls in real-time. In the native Unity Mono framework, I can insert custom effects into the audio DSP chain by implementing the OnAudioFilterRead method in MonoBehaviour (see https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnAudioFilterRead.html ). In the UdonSharp documentation, I found that there is a method stub for OnAudioFilterRead in Unity events (see https://udonsharp.docs.vrchat.com/events/ ), so I should be able to implement it. However, it does not work in my Unity setup. I also saw a post on Canny mentioning that a component called OnAudioFilterReadProxy should be automatically added to the object if OnAudioFilterRead is implemented (See: https://vrchat.canny.io/udon/p/order-of-onaudiofilterreadproxy ), but this is not happening on my end. Any idea what could be going wrong with my script or configuration? Or it is a bug? My test code is like the following: using UdonSharp; using UnityEngine; using VRC.SDKBase; using VRC.Udon; public class SimpleSineGenerator : UdonSharpBehaviour { [SerializeField, Range(0, 1)] private float amplitude = 0.5f; [SerializeField] private float frequency = 261.62f; private double phase = 0; private double sampleRate = 48000; public void Update() { // verify that the script is running transform.Rotate(Vector3.up, 90f * Time.deltaTime); } public void OnAudioFilterRead(float[] data, int channels) { // DSP code double phaseIncrement = 2 * Mathf.PI * frequency / sampleRate; for (int i = 0; i < data.Length; i += channels) { phase += phaseIncrement; if (phase > 2 * Mathf.PI) { phase -= 2 * Mathf.PI; } float value = amplitude * Mathf.Sin((float)phase); for (int j = 0; j < channels; j++) { data[i + j] = value; } } } }

Instantiating GameObjects is causing the original to be dropped if it has a pickup, I noticed this change in behavior in my level editor where clicking is meant to copy the object in place for easy editing. To make sure there weren't additional factors, I created a fresh script on a block pickup which only contains "OnPickupUseDown -> Instantiate" Unsure which update this began happening

This has been broken for a long while, since I can remember, Auto Hold does not work for Oculus, or Index, but does work for Desktop, and (last I checked) Vive.

Currently, "Continuous" mode syncing syncs 100% of the time. However, in many cases, there are idle periods in which continuous syncing isn't needed, followed by periods in which smooth syncing is necessary. The VRC Object Sync component does this exact behaviour, going to zero bandwidth usage when not moving, and having the ability to do this for UdonBehaviour variables would be very useful. This is particularly the case when the UdonBehaviour is attached to an Object Synced object; right now, this results in greatly increasing bandwidth usage as the Object Sync data is no longer able to go to sleep.

Currently manual sync is significantly faster than object sync and RPCs. This is fine... until you are using manual sync to replicate e.g. a control for a particle effect bound to a held object. We need a way to get these back into sync. Some potential options include: If the object sync latency is fixed, provide a way to obtain this delay so we can apply it to manually synced values. Provide a way to attach synced variables that are transmitted on object synced updates, but do not prevent the object from sleeping when it's not being moved (see https://feedback.vrchat.com/udon-graph-upgrade-closed-testing/p/reliable-sync-feedback-please-add-a-way-to-sleep-a-continuously-synced-object )

SDK ver: 3.10.2 There seems to be certain conditions where the False output of a Branch does not update the value for the index of the loop properly, causing the loop to pass the incorrect value into "Get" nodes for arrays. This issue occurs in both ClientSim and in-game. I don't know if I fully narrowed it down, but I was assisting someone with Udon, and in the process encountered what appears to be a bug in the compiler. In my provided example, this graph should loop through an array of MeshRenderers, and then change the material depending on the value of the isToggled bool. see video in action: https://www.youtube.com/watch?v=VanIgAJRwoI The "True" side executes as expected, but when the Branch evaluates to "False", the loop executes the expected number of times, but it reuses the last value of the index instead of updating the index along with the loop. This makes is to the 4 cubes in the array change to red when isToggled is True, but when isToggled is false it sets the last cube in the array to blue 4 times in a row. Possibly the issue could be with the "MeshRenderer[] Get" node, as if its input "int" is not getting updated properly during the loop. As can also be seen in the video, for some odd reason, adding a "Debug Log" node with a "String Format" node that accesses the index prevents the unexpected execution from occurring. Curiously, it's specifically the "String Format" node that prevents the issue, as disconnecting it (but keeping the Debug Log) still has the issue occur.