World/Udon Bugs & Feature Requests

There should be an option to set the world to 18+ by default and restrict it to only that. Any other instance, whether its a group, invite only, etc will be defaulted to 18+ This is an option that could be toggled by the creator in the SDK or WebGUI that no one else can change

When OSC was added for avatars a long time ago, it was promised to also add it for worlds, but world creators are still waiting for it to be added. Just like with Physbones, this hasn't happened yet and I'm afraid that world creators won't get OSC support because the focus seems to be fully on avatars. Is this still on the roadmap? OSC for worlds / Udon would allow concepts like speeach recognition, tracking world objects / pickups with Steam trackers (e.g. an IRL broom in a world where you can fly on a broom), DMX / light controllers in DJ worlds etc. MIDI is all we have in worlds right now and it's too limited and hard to implement for anything other than a music instrument.

As a world creator, you may have found yourself in need of a way to make an object always face the local player, sometimes called Billboarding. Doing this with transforms requires update loops in Udon, which are expensive. We’re adding native support for this to make it easier and more performant to implement! Three new methods will be available! (Note: always subject to change until release!) VRCBillboard.Register(Transform target); // upright, tracks yaw only (side-to-side) VRCBillboard.Register(Transform target, bool allowTilt); // allows up-and-down pitch changes as well VRCBillboard.Unregister(Transform target); // cleanup is automatic but can be triggered manually

Allow world creators to choose where portals can and can't be dropped. This would help prevent "trolling" in public instances where someone might be forced into a portal against their will, some game worlds may have the player flying forward for example so they are unable to react fast enough or unable to act if a 2nd user places a portal in their path. Right now the only options we have is entire world allows a portal or the entire world prevents portal dropping. A middle ground between these 2 extremes would be appreciated where a creator could have a designated area where portals can be dropped. Outside that and it would function the same as "too close to spawn". As a world creator I don't want to remove the players choice of dropping portals but I would like some control over it to prevent unpleasant experiences for users visiting the world, as too many occurences like this can have a detrimental effect on public perception of a world.

Since bone transforms aren't exposed, we can't parent objects to players and need to use expensive and complicated update loops for such a basic task, which also results in ugly/janky object movements and low performance. Please give us a simple function like .SetParent(Transform t, Boolean b) for .GetTrackingData(VRCPlayerApi.TrackingDataType.x) and .GetBonePosition(HumanBodyBones.x) and for VRCPlayerApi.GetPosition

It'd be helpful for world creators to know how many people are entering their world as well as how often users are coming back.

Tested with VRChat client build [1899]. VRCJson.TryDeserializeFromJson returns an incorrect string when valid JSON contains a supplementary Unicode character encoded as a UTF-16 surrogate pair. Reproduction code: string json = @"{""x"":""\uD83C\uDF63""}"; bool success = VRCJson.TryDeserializeFromJson(json, out DataToken root); Debug.Log("Success: " + success); if (success) { Debug.Log("Value: " + root.DataDictionary["x"].String); } Expected output: Success: True Value: 🍣 Actual output: Success: True Value: \uuDF63 The JSON is valid. \uD83C\uDF63 is the JSON surrogate-pair representation of U+1F363 (🍣). Deserialization reports success, but the resulting string does not match the value represented by the JSON.

Starting with Build 1878 (Open Beta) and Build 1885 (Live), there's a change to pickup highlighting which relates to VRC_Pickup with SkinnedMeshRenderer. It is written that "We feel that the amount of content this affects is extraordinarily small", but I have some worlds which are affected by this change. Some of them are SDK2 worlds and it would be a lot of work for me to fix all of them. I guess that some world creators (including me) assumed that SkinnedMeshRenderers are completely ignored by pickup highlighting, and I used this property to control pickup highlighting: Shader-based gimmicks often change the appearance of the mesh. In SDK2, use of SkinnedMeshRenderer is convenient for hiding its internal mesh shape and expanding mesh bounds. To select the highlighting mesh of pickups containing multiple child renderers, sometimes I change some renderers to use SkinnedMeshRenderer. Also, I preferred using the (fallback) collider outline for pickup highlighting. In this SDK3 era, I basically agree with the changes because there's a correct way to fix the issues. But I guess some worlds may still use this old technique. I want to say: Some world creators really care about the shape of pickup highlights. If the highlighting reveals the strange internal shape, players' immersion will be broken. Please keep existing behaviour as it is. I feel component versioning (e.g. VRC_Pickup Ver 1.1) is a very good idea, and it should be used more! I propose increasing the VRC_Pickup version number and keeping the old highlighting algorithm for older versions. I'm really sorry for not checking or reporting during Open Beta. I've attached some screenshots of my worlds which show how the new highlighting unintentionally reveals the internal mesh. (To be honest, I might be the one who uses this bad trick the most, though...)

The allowed world components page lists CharacterJoint as supported however, any attempt to use it in UdonSharp throws a TypeResolverException. The remaining Joint components do not throw an exception.

Attempting to join a build of my world with a VRC Enable Persistence component will immediately send me back to my home world and print the attached logs. The world will successfully build and upload but is inaccessible in-client. Removing the VRC Enable Persistence component allows the world to be accessible again in-client.