World/Udon Bugs & Feature Requests

ParticlePhysicsExtensions has various methods for getting particle collision data. Currently these methods are not exposed yet, so we cannot retrieve that data. Examples: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnParticleCollision.html

While spending time in my (private) world with a bunch of friends, some started crashing, and we noticed that VRC is using huge amounts of RAM. I traced the issue to a script that frequently recreates a UI list, where every entry is an instantiated object with an UdonSharpBehaviour script controlling the UI contents. As it turns out, using Destroy() on an object with an UdonSharpBehaviour does not seem to free the memory - my guess is that the overarching Udon system is still keeping references to every instance of a script that ever existed (for example to run their Update()s?). The memory gets freed shortly after leaving the world, so it's not the end of the world, but i would still appreciate fixing it. As a workaround (and, frankly, just a better/more performant solution) i no longer destroy the entries, but reuse the old ones, and just hide the ones that are not needed, but that doesn't change the fact that it's a bug that other people may be affected by. It may be the reason behind many other unspecified memory leak reports here. I created a world that presents the issue https://vrchat.com/home/world/wrld_edc6dd3e-f111-48c8-a907-7da43a98b9fb Functionally, it just performs Destroy(Instantiate(template)); 100 times per an execution of a FixedUpdate() when the cube/button gets activated (green). The template of the left button is just an empty GameObject, while of the one on the right contains an additional empty UdonSharpBehaviour.

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.

Issue: Currently it's not possible to react to a players voice at all. We don't know when someone is talking or how loud they are for example. This limits us from making games where someone needs to be quiet to hide from an enemy for example. For security reasons it makes sense that we can't just listen to a player voice, which is why I think only giving limited access to it would be fine. Suggestion: Add an isTalking bool to the VRC Player API which is true when voice is detected and false when not. Add a loudness float to the VRC Player API which is a value between 0 and 1 depending on how loud a player is. (Basically how the current Voice parameter works on Avatars) Add a viseme integer to the VRC Player API which would indicate what viseme is currently used. (Basically how the current Viseme parameter works on Avatars) These would allow world creators to integrate player voice into game play while also not just directly giving them access to player voices for security.

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.

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

This will allow maps to have a day night toggle (or change the lighting in other ways) while still using backed lighting.

Teleporting players with an offset rotation, 180 degrees being the most drastic, will twist and contort players in a very unsettling and horrific manner. Also, when trying to make more seamless (hidden) transitions using player teleporting, physbones completely reset, also giving the transition away. Using quaternion math, teleporting players with offsets for their local view is easy in Udon and would be perfectly immersive and unnoticeable with this capability. Prevent players contorting right as they're teleported. Optionally preserve physbone offsets and velocity between the teleport locations. This kind of teleport would allow for easy: Audio separation between floors of a world's building Manual occlusion of areas and players normally behind animated objects, like doors that may only show the transitioning player and not everything else behind them elevator-esque locations teleporting players immersively between locations Non-euclidean effects to create unique navigation or experiences

It would be useful if we could get Terrain methods in Udon. Specifically, methods and properties in https://docs.unity3d.com/ScriptReference/TerrainData.html and https://docs.unity3d.com/ScriptReference/DetailPrototype.html .

Please allow us to directly manipulate transform of the local player and of his playspace transform in Udon. Abusing teleport for this is not only misleading, but also not very efficient. The coolest stuff that people do with Udon uses teleport in every update and there are lots of performance issues doing that. We want to create flying-scripts, locomotion-scripts and better "chairs" for vehicles, doing this with teleport is inefficient. Also reading and manipulating the playspace transform is important for us as well, e.g. to know where the player is relative to his playspace.