World/Udon Bugs & Feature Requests

Ideal for events and presentations for ensuring the user in the zone is seen by everyone and not hidden by culling. Other safety settings still apply.

The current SDK is able to track players' heads and hands using TrackingData, but not their legs. GetBonePosition can do this but it's less reliable between avatars since it relies on bones rather than controllers. It'd be nice if TrackingData could also access left/right feet and waist/hip.

I'm currently making some custom mirrors with my own cameras using the eye position and rotation retrieved from the VRCCameraSettings. The mirrors work, but if I have the update loop in PostLateUpdate, the images are clearly lagging behind when I move my head in VR (on desktop it works fine). Using the rotation from the tracking data of the head does seem to have the same issue. I worked around it by updating the transform in OnPreCull instead, but isn't the intention of PostLateUpdate to have all tracking data up to date for the current frame?

When a networked custom event is sent with over 1kb of data to NetworkEventTarget.Self, the next networked custom event sent from that client does not send. Instead, the 1kb+ event is replayed, but to the new event target. For example if I send a 1.5kb event MyEvent on BehaviourA to NetworkEventTarget.Self, then send an event OtherEvent on BehaviourB to NetworkEventTarget.Owner (other player), instead, the owner of BehaviourB will receive MyEvent on BehaviourA with 1.5kb of data. Here is an example world where this can be seen: https://vrchat.com/home/world/wrld_451e102f-0087-4e14-a1c0-362a26a2594b

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.

Would allow world creators to dynamically adjust parameters such as: -spawns & spawn radius -object respawns & respawn height -user portals at runtime, instead of being permanently set at world upload.

VRC supports various languages itself, however world are only limited to one language for the world details. VRC should provide a way for world creators to have different world name/description depending to the user language settings which would provide a better accessibility and tell the player that the world support their language

Suggestion: Option 1: In class VRCPlayerApi, create a bool method SetVisibility(bool) which defaults to true, for toggling the overall visibility of a particular player, which includes their avatar and nameplate and any chat box they may create. Option 2: Alternatively, create multiple toggles to control each element individually, such as SetAvatarVisibility() SetNamePlateVisibility() SetChatBoxVisibility() SetStickerVisibility() SetItemVisibility() etc. In my opinion the second option offer better granularity of control and allows a more creative use. Reason 1: Currently if we need to hide a remote player without changing their actual position, we need to exploit a desync station to achieve this effect. Surely that is not the intended use of a station and is in fact a bug. We should be allowed to modify a remote player's visibility with Udon, directly, without exploiting a bug. Meanwhile, world creators can transition to this method, thus allowing the station bug be fixed without affecting worlds that utilize it. Arguably this feature is a prerequisite of eventually fixing the station. Reason 2: We can already control the audibility of a player, via SetVoiceDistanceFar etc. Combining SetVisibility(false) with SetVoiceDistanceFar(0f) and SetAvatarAudioFarRadius(0f) you can make someone completely disappear. Or, alternatively, make someone invisible but can still be heard.

In the public world 'a-lin', photos taken using the player camera fail to display vegetation, trees, terrain, and similar environmental objects. These photos ignore objects rendered via VRCGraphics.DrawMeshInstanced. DrawMeshInstanced objects are ​​completely absent​​ from camera photos despite being visible during gameplay and in SteamVR (F12) screenshots. This bug ​​severely disrupts​​ the player photography experience. How can this be fixed?

There is to many methods, features missing from C# in udon that need to be address. There is so much limitations in the current SDK that makes me want to by-pass udon safety to use basic features. Like in TextMeshPro; Method is not exposed to Udon: 'scrollingText.preferredHeight' I need more direct features regarding rendering as well, not just TextMeshPro, to create fully better worlds with more user friendly features comes at the cost of hacks currently to get what I need to work in udon, but even that doesn't ensure safety of everyone. VRC Worlds are stalling and there hasn't been many updates to the WorldSDK at all.