World/Udon Bugs & Feature Requests

Physbones is really cool. In particular it has a performant set of tools that allow for avatar-avatar interaction. Please port the Physbones code so we can use it in Worlds too! It would make making many Worlds things far easier, like buttons and levers.

EventTiming has options for sending delayed events with Update and LateUpdate timing, please also add the option for FixedUpdate (and PostLateUpdate, but that's already another canny).

There is no way currently to tell whether a variable exists on an udon behavior right now without potentially crashing Udon. Add a safe option to test the waters. Or, if there is, document it .

Place "Snap points" for prints in your world, so you can put snap points on walls and stuff, and players can mount prints on them for others to see. This is because it is hard to get prints to stay in a certain place because they are floaty and don't collide with stuff reliably. I see people in my worlds trying to place prints on tables, objects, frames, floors, etc

https://vrchat.com/home/world/wrld_9b540ed9-6aca-4172-9e33-f75cb756a9f5/info This world measures how many times by adding a force every frame and checking if Rigidbody.GetAccumulatedForce() is larger than one frames worth. My result with one client is 28-32. My result with two clients: Master: 28-150~ Nonmaster: 180-300~ The numbers are going to be much higher in more complicated worlds that take longer to load and have more networked/physics objects. This is problem for anyone working with physics, because applied forces will add up and cause the object to suddenly spring away with all the accumulated force once the simulation starts actually running. Personally, it caused the suspension forces on my cars to build up and cause them to shoot in the air and explode. The number of frames is much greater if two players join a new instance at the same time, leading to confusing problems for developers. The number of frames seems to be directly related to how long the loading screen is shown for, in the case where two players join a new instance at the same time, the loading screen is shown for much longer. Solution: It might actually be quite complicated because this delay way probably added for a good reason. I don't think it's as simple as not running FixedUpdate() until the delay is over, because Update() etc is also already running. Maybe delay all Udon activation until this time? There's no way for me to know without knowing VRC's code. A workaround fix could be to add a PhysicsReady() event for when physics actually activates.

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.

On local test world, there are log outputs claiming to play untrusted URL but it is YouTube URL which should be registered as the trusted domains list. Additionally, while the log contained error about untrusted URL, video playback was normally started. Error - You are playing an untrusted URL (Domain: www.youtube.com) in a local world. If this URL is needed for the world to work, the domain needs to be added to the world's Video Player Allowed Domains list on the website.

Today, the most popular use case of the IVRCImageDownload is to share some picture with friends in VRChat. However, there is one big annoying behavior in IVRCImageDownload for this use case. That's 2048x2048 texture size limit. Therefore, I hope VRChat to have the feature that automatically scale the texture size down to 2048x2048. As described before, it's common to use IVRCImageDownload for sharing pictures with friends. There are several assets specifically designed for this use case such as Image Pad and ImageTablet . However, the 2048x2048 size limit is an annoying for this use case because today picture is likely to exceed this limit. For example, my iPhone 12 mini with default settings will take picture with 4032x3024 pixels and other modern smartphones also take high resolution image by default. In VRChat, I feel it’s common to choose take pictures in QHD, 4K, or 8K but none fits 2048x2048 limit. (FHD and HD fits 2048x2048 though we want to take high-quality pictures.) The texture downloaded with IVRCImageDownload become uncompressed RG, RGB or RGBA texture on the VRAM so It take huge VRAM. Therefore, I think it's reasonable to limit texture size on the VRAM. However, I think it's possible to resize texture down to 2048 off the main thread before loading to to the VRAM. That’s why I request VRChat to have the feature that automatically scale the texture size down to 2048x2048. 日本語要約 IVRCImageDownloadという Image Pad や ImageTablet のような画像を共有するためのアセットで使われている機能に対する要望です。 前述のタブレットではVRChatの制限により2048x2048より大きい画像を指定した場合にはエラーになりますが、エラーにする代わりに 2048x2048 以下に自動的にリサイズするオプションを追加してほしいという要求になります。 (技術的理由により2048x2048より大きい画像をそのまま表示するのは厳しいです) このオプションがあれば、Discordなどに上げた画像を共有するときにエラーが出て使えないという面倒事を減らせるようになります。

There are many camera settings that would be really nice to have access to after runtime. An interface could be provided for this via some proxy in the VRCGraphics class. (and maybe one for the hand camera as well!) Ideally this proxy would contain everything the normal Camera class has that doesn't pose a security risk. Some examples of very handy use cases for this: Change farclip dynamically to minimize perf overhead from unnecessarily drawing distant avatars/objects Safe access to culling masks for user-created layers to make a lot of common visibility tricks much easier Set depth texture to be generated without needing a shadow-casting dir light Get FOV to use for unique world mechanics Access to a lot of useful camera matrices like cameraToWorldMatrix, worldToCameraMatrix, projectionMatrix, etc... Access to stereo separation for more advanced world features ...and more I'm probably not thinking of!

We're working on a new character controller for VRChat worlds. It works mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going up stairs and slopes is smoother. Players can get pushed around by the colliders. It's better at getting players unstuck from geometry. Udon has greater control over the character controler. ... And more! This feature is still in development and subject to change.