World/Udon Bugs & Feature Requests

There is an undocumented limit on Network IDs. If you assign a Network ID beyond 10 000 to a PlayerObject its persistence features will break while the UdonBehaviour itself still functions and syncs. ClientSim throws the following error: ran out of player persistence view ids In-game testing results in Removed some Player Persistence metadata that had invalid IDs. errors. Apparently there is a limit of 100 000 for Network IDs in general, its way less likely to hit this, but this also seems undocumented. The difference in limit for PlayerObjects and standard UdonBehaviour objects is confusing and the provided errors don't accurately explain how to solve this issue. The Network ID Utility also does not seem to take this limit for Player Objects into account and does not warn or ensure a lower ID is assigned to the persistent objects. Furthermore, the Network ID Utility crashes on projects with this many Network IDs, but this was already documented here: https://feedback.vrchat.com/sdk-bug-reports/p/network-id-utility-has-massive-performance-issues

When adding [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] to an udon# class, It will just continue using the last setting. For example if you add [UdonBehaviourSyncMode(BehaviourSyncMode.Continuous)] and then compile, then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] and compile again, you get the expected behavior, and calling SendCustomNetworkEvent() works. If you then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.None)] and compile, then change it to [UdonBehaviourSyncMode(BehaviourSyncMode.NoVariableSync)] and compile again It will continue to behave exactly as if it's still set to None. SendCustomNetworkEvent() does not work. This is on an object that doesn't have any other scripts on it. I haven't tested the case with other scripts. You can look at the debug inspector to confirm that this is what is happening. From the documentation: "NoVariableSync: Enforces that there are no synced variables on the behaviour, hides the sync mode selection dropdown, and allows you to use the behaviours on GameObjects that use either Manual or Continuous sync." It seems like the case where a script using NoVariableSync being used on an object that doesn't have another script on it may have been overlooked. Since I'm updating a script in a prefab I'm releasing from None to NoVariableSync because I want to use network events now, it's not going to work for anyone updating to the new version. I am forced to set it to Continuous. Does anyone know if it makes any difference to bandwidth usage?

I noticed this bug when I tried to set a value that could not be represented as a float. Shader.SetGlobalInt() is cast to float internally, so Shader.SetGlobalInteger() needs to be used.

The error can't be reproduced with 100% guarantee, nor have I found anything that seems to cause it, though I think it happens most often with The Black Cat? It seems to happen with both public and private worlds, empty and busy worlds, if the portal has a custom name or not doesn't seem to matter, etc. However, I can get it to happen most often from this test world, which may suggest that the world the portal is in has some affect on whether it will break or not: https://vrchat.com/home/world/wrld_a077bb01-5d07-44db-a1fc-cdc95eca2a16/info Sometimes the error pops up but then it loads you into the world anyway. But if it doesn't load, the portal is then "frozen" and can't be entered anymore unless you rejoin the instance. Reproduction steps: Join test world Walk into portal. if the error doesn't pop up, let it load the world, then join it again and try again until it happens (Yes, it HAS to be the Black Cat because I think it happens most often with this world) Output log is attached, with the relevant error at 2025.01.23 03:59:10. In this session I booted into a new instance directly using the VRC Quick Launcher. Walked into the portal, loaded into the Black Cat, pressed Go Home to go back to my home world, then made a new instance of the test world, joined it, and walked into the portal. This time it gave the error and didn't send me to The Black Cat.

Gravity and Kinematic flags on VRCObjectSync components don't sync correctly right now and also cannot be set correctly while holding the pickup. To set gravity or kinematic flags, VRChat added two new methods for us: https://udonsharp.docs.vrchat.com/vrchat-api/#vrcobjectsync (they are supposed to behave like a synced variable) There are two bugs related to this: ~ Bug 1: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component with an external button after claiming ownership. Then you let different people in the world pick up the pickup and drop it (to show their own local state). In my tests, this resulted in a pickup where the gravity flag is wildly different on each client and only syncs occasionally or not at all. They would see the pickup drop on my end, but when they pick it up it has no gravity for them. ~ Bug 2: ~ All you need is to create a pickup that has no gravity and then toggle the gravity flag on the VRCObjectSync component in OnPickupUseDown() . In my tests, this resulted in a pickup where the gravity stays enabled after the first OnPickupUseDown() and I am unable to turn gravity off again. To check gravity, the pickup is dropped. You can also just test it out here: Right setup: Bug 1 / Left setup: Bug 2 https://vrchat.com/home/world/wrld_9cefd5ec-4492-43c5-8cd3-05036c494556 Additional note: Since we only got a setter and not a getter method, we are left in the dark here when it comes to analyzing the problem. Reading out the local rigidbody state doesn't give us access to the real synced state. A getter method should be added.

If you use VRCPlayerApi.SetVoiceDistanceFar() or VRCPlayerApi.SetVoiceDistanceNear() The the value seems to get clamped to a maximum of 10000. I would like the maximum range to be as high as possible for stuff like aircraft radios.

I noticed that VRCObjectSync has started to not sync rotation perfectly. I don't know when this started, but it definitely didn't used to happen. The owner of the object will get the exact correct rotation, of course, but others will get rotation that is slightly off. In my testing, when the owner had (0,0,0) rotation, others had (359.89, 359.89, 359.89) rotation. That's enough to cause slight alignment issues in my situation, which is how I noticed it. How to reproduce: Create a world with an object that has VRCObjectSync. It doesn't need to have a pickup component. I've attached a screenshot of my "obj". Make a button somewhere that has a script like this: using UdonSharp; using UnityEngine; using VRC.SDKBase; using VRC.Udon; using VRC.SDK3.Components; public class resetpos : UdonSharpBehaviour { public VRCObjectSync obj; public override void Interact() { Networking.SetOwner(Networking.LocalPlayer, obj.gameObject); obj.Respawn(); } void Update() { Debug.Log($"pos: {obj.transform.position} --- rot: {obj.transform.eulerAngles}"); } } And assign the VRCObjectSync object to "obj". I've attached a screenshot of my "resetpos" button. Build and launch two VRChat clients. Have each client click the button a few times and see that when ownership is transferred between players, sometimes the non-owner will get a slightly off rotation value. It doesn't always happen immediately after clicking, and sometimes it takes a few clicks in a row for it to happen. Notice that when the object is misaligned, and you click the button to take ownership, the object does visibly rotate slightly as it goes back to the correct rotation. I've attached a screenshot of my console log showing the pos and rot values logged from the script shown above. In my test, the magenta object is the "obj" and the white post is the button.

My world has a layered camera setup and requires for the reference (main) camera of the world to be set to render with Clear Flags set to Depth only and only render from players eyes up to 1000 meters in order to maximize performance. Secondary camera of the world is set to render only a low quality copy of the terrain and surrounding mountains in the horizon from 1000 meters all the way up to 4000 meters before the main camera of the world renders the scene. Despite the player's POV looking perfectly normal on desktop and in VR, the in-game camera, steadycam and personal mirror all break because they inherit all applicable properties of the reference camera and don't properly clear the render, resulting in unacceptable ghosting in the sky. I'm asking for the VRCSDK to include an option to set the camera properties of VRChat's in-game user cameras independently from the reference camera, e.g. fields for Clear Flags, Near Clip, Far Clip on the VRCSceneDescriptor so they can still keep functioning without the world author having to provide a completely custom camera solution from the ground up in order to mitigate this issue. If exposing the properties in the SDK is too big of an ask, at least ensure that the in-game cameras do not have their Clear Flags set to Depth Only or Don't Clear. Thank you. P.S. This issue could also be fixed by allowing the world to set the Clear Flags of the player's main camera during runtime with Udon, related post: https://feedback.vrchat.com/udon/p/give-us-an-interface-to-the-main-camera-via-the-vrcgraphics-class

VRCSDK3-WORLD-2021.03.09.13.57_Public Unity 2018.4.20f1 When many Midi Events are received, references outside the buffer range will occur. Log IndexOutOfRangeException: Index was outside the bounds of the array. VRC.SDKBase.Midi.VRCPortMidiInput.Update () (at Assets/VRCSDK/SDK3/Runtime/Midi/VRCPortMidi.cs:71) VRC.SDK3.Midi.VRCMidiHandler.Update () (at <5d3e9f7f72234587a2c25e98f82b4f27>:0)

It works fine on UnityEditor, but when I build to VRChat's OfflineTest, I get an error that the TextMeshProUGUI attached to the Instantiated GameObject is null. Does the SerializeField get stripped when Instantiated for VRChat use? I would like to know if you know how to solve this problem. [UdonSharp][Unknown] Assets/**/Scripts/Presentation/**.cs(19,43): VRChat client runtime Udon exception detected! An exception occurred during EXTERN to 'TMProTextMeshProUGUI.__set_text__SystemString__SystemVoid'. Parameter Addresses: 0x00000003, 0x00000009 Object reference not set to an instance of an object.