World/Udon Bugs & Feature Requests

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.

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?

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.