World/Udon Bugs & Feature Requests

Since GoGoLoCo has become more prevalent and embedded in more and more avatars, the fundamental incompatibility between GoGoLoCo and VRCStations on vehicle (and other) systems is now commonplace enough that it has made debugging of station ergonomics as complicated as possible - which actively deters world devs from considering accessibility in their systems. This has been going on for several months at least, and it's out of control. The issue seems to be that GoGoLoCo has unstoppable and extremely inappropriate access to the Station's animation controller variable and blocks it, preventing the player from being able to move normally (or even be upright in some cases), and preventing scripts from doing anything to fix it. This is just my guess, so it may even be more complicated than that. We don't know. We don't have the source code, so who knows? But this can be reproduced across different worlds, different avatars, same parameters. This breakdown usually renders whatever the station is attached to inaccessible to the player because it defeats all attempts to make it accessible and the world dev and player are both powerless to stop it. At this point in time, this makes worlds using vehicle prefabs entirely inaccessible to players who do not know about this issue and understand that GGL is 100%, hopelessly and irrevocably incompatible with VRCStations. You can't expect casual or new players to discover this instantly, and this is having an effect on the perceived viability of afflicted systems going forward, which deters their development and adoption of new SDK features. There is simply no reason to sink time and effort into developing vehicle systems or other things which move the player since GoGoLoCo is allowed to run rampant all over the Worlds SDK, ruthlessly enforcing its own, unintentional, and unofficial rules over VRChat's own. Allowing GoGoLoCo to dictate what players can and cannot interact with is shaping the platform and eliminating options for gameplay which previously existed, and creates the impression that VRChat does not have control over the SDK. Normally, this wouldn't have been allowed to get this far. Now it's too late to fix this by any means other than fixing VRCStation to harden it against this attack. At this point, I cannot continue to develop anything around VRCStation, or advise anyone to do so until VRCStation has been fixed to prevent GoGoLoCo from hijacking it. Obviously you can't ban GoGoLoCo because that would brick like half of the avatars on the platform, so the only option is to fix VRCStation. Fix VRCStation. Fix VRCStation. The unthinkable task: Fix VRCStation. Please do something before we give up on you.

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. Pressing 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 investigated in 2022.4.1p2 (build 1260) . When vrCurlInputField.activateInputField () is executed, various VRChat shortcut keys are broken. The mute button (V) and quick menu (R) will not work in desktop mode. Similarly, the mute button (B button) and quick menu (hold down the B button) will not function in VR mode. This bug appears to have started with 2022.4.1p2 (build 1260) .