World/Udon Bugs & Feature Requests

When building a world, the SDK validator may attempt to read and "validate" editor-only scripts which do not include any reference to UDON or VRC. What's worse, is the "validator" will misinterpret a larger number of explicitly non-UDON scripts over time. This has been a problem since at least the start of using Unity 2022, but it appears to get worse over time without updates, suggesting it is an issue that has gone ignored for some time and somehow "leaks" something and now it's causing issues in long-term maintenance of worlds.

Under certain conditions that I can't reproduce reliably, all network events stop working for a player. It looks like it always happens when the owner/master changes. This causes big issues in high frequented instances where the master changes a lot. World where it happens to me: https://vrchat.com/home/world/wrld_3fb6208d-54d7-4a9f-9cf9-11341fa36037 All objects are active and never get deactivated. Serialization and Deserialization works fine for all players. The network is not clogged and is happy. The network events stop working completely for the client that experiences this behavior regardless of the target (All, Owner) and they don't send or receive any events anymore. The behavior never recovers. If another client tries to send a network event directly to that player (owner) the event gets blocked. I verified that the code works by executing the methods on the client with the bug by hand. (Thanks BobyStar) The code sends maybe 3 events in 20 seconds on multiple UdonSharpBehaviours. I attached some code examples that don't get executed from the network event, but if I execute them by hand it works. The error that's after the rpc call was captured on a non-owner client that tried to send a network event to the owner who was experiencing the behavior described above. This was after I pressed a button that executes the "StartLobby" method. In the code example with the Debug logs I see the first log "All players finished race!" but I don't see the "OnGame Done!" on any client.

Networking.GetServerTimeInMilliseconds returns a possitive value for about half the players in the world, and the rest of the players get a negative value counting towards zero. When servertime is used for syncing events players dont all sync up. If you get a possitive number it will be possitive through out your stay in that world, and if you get a negative value it will stay negative. If you rejoin the world you will get a possitive or negative number by chance. I include two logfiles showing examples of possitive and negative servertime.

It seems as though avatars are not affected by occlusion culling. It seems like it would be a great benefit for maps which are broken up into distinct rooms to be able to stop wasting draw calls and physics calculations on avatars that a simple check would guarantee cannot be seen? If it isn't possible to use Unity's native occlusion culling this way for some reason, maybe an even better idea would just be to give the ability for Udon scripts to decide for each user, which other users should appear to them as "culled diamonds"? (As in, in a script that would purely run locally, with each user's machine making separate decisions about how the other users will appear.) So a script could detect that the local user is standing in room A, and automatically diamondize all the avatars in room B, until the user walks into another room. (This status would of course be "or"ed with whether an avatar was already diamondized for whatever automatic reasons are already set in that user's settings.)

The capsule seems to be positioned at the bottom of player instead of the middle, which causes any OnPlayerTrigger events to trigger below the player. Which is very unreliable for OnPlayerTrigger events that needs to be triggered by non-local player since the capsule won't go even as far as above the waist of an average size avatar/player.

Support ticket #356154 The content is the same as the title.

When a player hits the world respawn height, they are always sent to the original respawn point in the world, no matter if it's been moved or not. Comparatively, when hitting the respawn button, it always sends the player to the current respawn point position. Example world: https://vrchat.com/i/quaff-canadatiny-77aa2

VRCUrlInputField.ActivateInputField() breaks various shortcut keys in VRChat. Mute button (V) and Quick Menu (R) will not work in desktop mode. Similarly in VR mode, the mute button (B button) and quick menu (press and hold B button) will not function. This bug seems to have been introduced in 2022.4.1p2 (build 1260) . VRCUrlInputField.ActivateInputField() を実行するとVRChatの様々なショートカットキーを壊す。デスクトップモードではミュートボタン(V)やクイックメニュー(R)が機能しなくなります。VRモードでも同様にミュートボタン(Bボタン)やクイックメニュー(Bボタンの長押し)が機能しなくなります。この不具合は 2022.4.1p2 (build 1260) から入ったようです。

Delay flow from being executed until a duration has passed.

Both the "Set Destination" nodes links to wrong documentation page. Both links under here is from the two nodes that exists in Udon. https://docs.unity3d.com/2018.4/Documentation/ScriptReference/NavMeshAgent-destination.html https://docs.unity3d.com/2018.4/Documentation/ScriptReference/NavMeshAgent.SetDestination.html Correct would be https://docs.unity3d.com/2018.4/Documentation/ScriptReference/AI.NavMeshAgent.SetDestination.html