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

Writing a U# program like so, will fail with: Method is not exposed to Udon: 'texture.SetPixelData(d, 0, 0)'. Even though it is exposed as UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D U# Code: var texture = new Texture2D( 2, 2, TextureFormat.RGBA32, false ); uint[] d = new uint[2 * 2 * 4]; texture.SetPixelData(d, 0, 0); However it will compile in udon graph, but the data input will be a Object[], and will crash with anything passed to it. Manually writing some udon assembly will compile again, but will also crash at runtime udon assembly: .data_start .export tex .export arr .export num0 .export num1 .export f .export tex_format tex: %UnityEngineTexture2D, null arr: %SystemSingleArray, null num0: %SystemInt32, null num1: %SystemInt32, null f: %SystemBoolean, null tex_format: %UnityEngineTextureFormat, null .data_end .code_start .export Test Test: PUSH, num1 PUSH, num1 PUSH, tex_format PUSH, f PUSH, tex EXTERN, "UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D" PUSH, tex PUSH, arr PUSH, num0 PUSH, num0 EXTERN, "UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid" JUMP, 0xFFFFFFFC .code_end udon assembly crash: VRC.Udon.VM.UdonVMException: The VM encountered an error! Exception Message: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'. Parameter Addresses: 0x00000000, 0x00000001, 0x00000002, 0x00000002 Cannot retrieve heap variable of type 'Single[]' as type 'Object[]' ---------------------- Program Counter was at: 80 ---------------------- Stack Dump: ---------------------- Heap Dump: 0x00000000: (UnityEngine.Texture2D) 0x00000001: System.Single[] 0x00000002: 0 0x00000003: 1 0x00000004: False 0x00000005: RGBAFloat 0x00000006: UnityEngineTexture2D.__ctor__SystemInt32_SystemInt32_UnityEngineTextureFormat_SystemBoolean__UnityEngineTexture2D 0x00000007: UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid ---------------------- Inner Exception: ---> VRC.Udon.VM.UdonVMException: An exception occurred during EXTERN to 'UnityEngineTexture2D.__SetPixelData__TArray_SystemInt32_SystemInt32__SystemVoid'.

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...)

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

If I want to pass a parameter when sending custom events with delay, and i want to be able to send many of them with varying results without having to add 200 specific events or variables attached. I think it will be useful and user friendly if parameter passing can be written directly in sender side SendCustomEvent node and receiver side CustomEvent node as a kind of syntax sugar. I copied part of the previous canny about this, as only the Networked event was covered and left us completely unable to make this sort of thing happen entirely locally despite the canny being marked as complete

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.

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

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.

After importing a dolly via Udon, the "Speed" value set in VRC Camera Dolly Point does not get translated correctly when the "Copy to Camera" button on the point gets used in-client. Anything set with speeds 1 or greater gets applied as 15.0 in-game (clamped limit) and 0.1 gets applied as 0.2 (clamped limit). Editor values tried: 0.15 editor -> 0.4 client 0.2 editor -> 0.5 client 0.25 editor -> 0.8 client 0.4 editor -> 3.0 client 0.6 editor -> 5.1 client 0.9 editor -> 11.5 client

Allow world creators the ability to moderate their OWN worlds and issue their OWN bans. I'm tired of seeing crashers and exploiters in my worlds and kicking them is nothing. I want the ability to ban certain individuals from my worlds. There is absolutely no harm in doing this. Who is it going to hurt? The exploiters and cheaters. What if world creators abuse it and ban people from THEIR OWN worlds? Well it's their fault their world fails to gather a population. What else will this do? Allow world creators to suit the needs of their wanted audience. it will also help take the stress off of the actually game moderators. Thank you, Lucifer MStar - Creator of 30+ worlds including church of marriages. P.S. Communicate more with your community on what you are doing about these crashers and exploiters and maybe the heat and stress will die down. Honestly this is the most annoying thing communication.