World/Udon Bugs & Feature Requests

I'm trying to add shadows to my world Test Pilots and it works fine on desktop mode but in VR I'm getting severe shadow acne. I've attached two images, one showing desktop and one showing VR. I have messed with the following settings (and there are sliders to change them in the world): Near/Far clipping plane Directional light's Bias and Normal Bias None of them seem to help much, so I'm wondering if there's an internal VR setting that has been overlooked that is causing this issue. My settings are as follows: Near: 0.05 (max allowed in VRC) Far: 50000 I realize these settings are extreme, but I can't see a reason why there'd be such a huge difference between VR and desktop. I've uploaded a barebones version of the world for testing at: https://vrchat.com/home/world/wrld_6a5d6107-25a1-4152-9eb2-0b110ae23432/info To see the issue go in VR and either fly up in the air using jump + left trigger OR click on the 'Teleport To Light Control' button and look towards the large grey structure. Note there is a day/night cycle in the world so sun angle may change if you stay too long. Hit the 'Set Day' button at spawn to freeze it. Issue has been observed on Index and Quest 3

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.

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.

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

Create 2 scripts "BugHolder" and "Bug" public class BugHolder : UdonSharpBehaviour { public Bug[] list; void Start() { var result = GetBugFromList(0).PerformBug(this); Debug.Log("Result: " + result); } public Bug GetBugFromList(int i) { return list[i]; } } public class Bug : UdonSharpBehaviour { public int id; public int PerformBug(BugHolder h) { h.GetBugFromList(1); Debug.Log("Returning ID: " + id); return id; } } Attach the bug holder and 2 bug components put them into the list and give them unique non-zero ids. Press play. The printed result will be incorrect. This happens because Udon does not support return values, so it stores the return value in a variable (let's say {FunctionName}_result). Then when the code is compiled it gets turned into something like this (pseudocode): void Start() { this.GetBugFromList(0) this.GetBugFromList_result.PerformBug(this) var result = this.GetBugFromList_result.PerformBug_result } The issue is that calling PerformBug calls GetBugFromList which overrides the value of the GetBugFromList_result variable and then the next statement gets the wrong result. A potential fix could be to have the compiler create a local variable for you storing the result of the function. This bug was very difficult to debug.

% 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 was reported as fixed in 2024.4.1p3 but it looks like the problem crept back in and exists in SDK 3.8.2 / 2025.3.1 (haven't tested any other versions). Since the previous canny was closed out as complete, thought I'd open a new one. Prior bug report on this issue: https://feedback.vrchat.com/udon/p/braces-inside-strings-in-vrcjson-can-fail-to-deserialize // This works if(VRCJson.TryDeserializeFromJson("\"{\"data\":\"test\"}", out DataToken token2)) Debug.LogError("Failed to deserialize JSON"); else Debug.Log("Successfully deserialized JSON"); // This fails. Only difference is the braces after the word test in the JSON string. Number of braces or their configuration doesn't seem to make a difference. if(VRCJson.TryDeserializeFromJson("{\"data\":\"test{}\"}", out DataToken token1)) Debug.LogError("Failed to deserialize JSON"); else Debug.Log("Successfully deserialized JSON"); Thanks! -Tea

Requesting serialization on an object and immediately disabling it prevents the serialization request. Setup: Manually synched object with several synched variables Remote player is owner Remove player leaves instance Master takes ownership Master resets various variables and requests serialization Master disables GameObject Expected: Serialization succeeds (This is what happened before the OSC update) Actual: OnPreSerialization and OnPostSerialization are not called, the variables are not reset. ------------- Since the OSC update, there seems to be a new issue when requesting serialization. I have only seen this bug occur in CyanLaser's object pool prefab. It is caused by disabling an object shortly after requesting serialization. If I don't disable the GameObject , serilization succeeds (but the script loses functionality) https://github.com/CyanLaser/CyanPlayerObjectPool/blob/main/Cyan/PlayerObjectPool/UdonSharp/CyanPlayerObjectAssigner.cs#L676

Modulo against 2 long values is not correctly whitelisted. This is borked in all cases except with 2 constants inline, in which case C# just optimizes this away before it hits U#. Untested if other methods are also unavailable. Sample code: long a = 10L; long b = 20L; long c = a % b; Result: Method is not exposed to Udon: 'a % b' SDK: Worlds 3.7.2 Unity: 2022.3.22f1

If you name your GameObject PlayerManager , then execution of SendCustomNetworkEvent is blocked. This behavior newly started from build 944 or 946 without any notice. I made a world for reproduction: https://vrchat.com/home/world/wrld_f17d2b37-2f60-47d2-b280-e4489ba29368 --- I use identical Udon program for two GameObjects. You'll see logs for the failure case (named PlayerManager ) like this ("naqtn" is my user name): [Network Processing] RPC called PlayerManager:UdonSyncRunProgramAsRPC:All and 10 bytes [VRC_EventDispatcherRFC] SendRPC/AlwaysUnbuffered on PlayerManager blocked for naqtn (local master owner) --- On the other hand, the log success case (named Foo ) is like this: [Network Processing] RPC called Foo:UdonSyncRunProgramAsRPC:All and 10 bytes [VRC_EventDispatcherRFC] Will execute SendRPC/AlwaysUnbuffered on Foo (UnityEngine.GameObject) for naqtn: S: "UdonSyncRunProgramAsRPC" I: 0 F: 0 B: Unused (local master owner) [Network Processing] RPC invoked UdonSyncRunProgramAsRPC on Foo for naqtn [UdonSync] Foo executing echo at the behest of naqtn --- I guess "real" PlayerManager exists somewhere (perhaps in hidden player object) and the system wants to block malicious incoming messages. It might reach with adjusted network id. But I think blocking by the name is not reliable and is not good way to do that. Because VRC_EventDispatcherRFC must be able to get the object reference of real PlayerManager internally. I'm not sure this is a bug or intended feature. If this is a feature, please describe in the document and announce to Udon creators.