World/Udon Bugs & Feature Requests

While local strings allow storing from range \u0000 to \uffff , any synced strings are forcefully encoded with UTF-16, making any characters within range \ud7fff to \udfff be truncated to \ufffd . It seems like internal serializer or deserializer is treating all strings as UTF-16 encoded texts, no matter what their purpose is. I do know strings require terminators like \0 to be memory safe, or for some other features like support for emojis via utilizing surrogate pairs, but in raw memory side, string can be treated just like other containers, and I'm utilizing for maximum productivity and memory&network efficiency. (For example, treating each character as 2 bytes, or even go further, 4 hexadecimal numbers) I see this becomes important, due to VRChat's network bandwidth limitations and Udon's performance compared to normal C# codes. Just like gameboy-era old games did, I need to squeeze out all the possible bytes to make the code both performance and network-efficient. Maybe treat string just like byte[] when serialized? or maybe adding a special attributes like NonEncoded to the string variable so that the variable is treated just like another data container?

Fairly simple request. Half of what makes Contacts what they are is currently missing. We can only contact from Avatar to World to trigger something in the World. What we need is the ability to send parameters from World to Avatar to trigger effects on the Avatar. An example of this would be a weather system. You stand inside a contact for rain and it will send a inRain parameter to the Avatar which then can implement something in their animator layer to do something with this, such as enabling shader effects to look rained upon or wet. This could be used for many effects, sandy in the desert, muddy in swamp, wet in rain/water, damaged/bloody in games with health and so on. Allowing communication from the World to an Avatar would open up endlessly more ways to interact with the World in a variety of ways.

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.

Spline editor and components is one of most exciting new feature for Unity 2022. Now our project has been migrated to 2022, So we are ready to use it! Please expose those components for world creation and Udon VM: ・Spline ・SplineAnimate ・SplineExtrude ・SplineInstantiate It would be better if the Spline package is automatically added to the project when the SDK is imported so that these features are easily accessible.

At present, PhysBone is not supported in the World SDK, so Dynamic Bone must be used to implement physics-based animations. However, the version of Dynamic Bone used in VRChat is already quite outdated—likely version 1.2.1, whereas the latest available version is 1.3.4. The contents of the Dynamic Bone component included in the component whitelist have also changed, with new parameters such as "Roots" and "Blend Weight" being added. Naturally, these parameters that do not exist in the older version do not function in VRChat. On the Asset Store, only the latest version of Dynamic Bone can be downloaded. The discrepancy between the available version and the version used in VRChat could lead to confusion when setting up worlds, especially since the version of Dynamic Bone used in VRChat is not documented anywhere. To test with the same version as VRChat, we now have no choice but to transfer an older version of Dynamic Bone that was downloaded when that version was still available. If the World SDK plans to continue using Dynamic Bone in the future, I strongly urge that the version of Dynamic Bone used in VRChat be kept up to date. --- 現在のVRChatランタイムで使用されているDynamic Boneのバージョンは既にダウンロード不可能です。 現在、WorldSDKではPhysBoneがサポートされていないので、揺れものの実装にはDynamicBoneを使用する必要があります。しかし、VRChatのランタイムで使用されているDynamicBoneは既にかなり古く、おそらく1.2.1だと思われますが現在の最新バージョンは1.3.4です。コンポーネントホワイトリストに含まれている、DynamicBoneコンポーネントの内容も変化しており、例えばRootsというパラメーターやBlend Weightというパラメーターが新たに追加されています。これらの古いバージョンにないパラメーターは当然VRChat上では動作しません。 アセットストアではDynamic Boneは最新バージョンしかダウンロードすることができません。利用可能なバージョンと動作バージョンの違いはワールドをセットアップする上で混乱のもとになるでしょう。VRChat上でのDynamicBoneのバージョンがどこにも明記されていないからなおさらです。私たちが現状でVRChatと同じバージョンのDynamicBoneで検証するには、そのバージョンがリリースされていた当時にダウンロードしていた古いバージョンのDynamic Boneを移植する以外に方法がなくなりました。 今後もワールドSDKではDynamicBoneを使い続ける予定であるのであれば、せめてVRChatのDynamicBoneのバージョンを最新に保っていただきたいです。

This would potentially be able to reproduce the Combat System in Udon and make it obsolete. Also would be pretty cool in general :^)

It appears that there is a threshold that must be met when scrolling the content of a world space ScrollView which is not adjusted based on the size of the scroll view. This makes it impossible to scroll sufficiently small ScrollViews (if there are no scrollbars). In Client Sim, there is no such threshold. In-Game example: https://i.imgur.com/yQ6Fj0c.mp4 Editor example: https://i.imgur.com/Ry1QZk6.mp4

I want to be able to store references to components as a Behaviour type within an array, so I can loop through them and toggle the 'enabled' property on them as needed by the script. Because Behaviour is the most generic type for many Unity types that has the 'enabled' property, it should be exposed so we don't have to explicitly cast check for other subtypes derived from Behaviour, which would cost extra EXTERN calls. Specifically what I'd like exposed is: Behaviour Type Behaviour[] Type Behaviour.enabled property (get/set) Behaviour.isActiveAndEnabled property (get) Other related post that specifically referred to isActiveAndEnabled https://feedback.vrchat.com/vrchat-udon-closed-alpha-feedback/p/expose-behaviourisactiveandenabled

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.

MonoBehaviour scripts will break U# compiler when guarded by pre-processor directives while containing multiline text with a line starting with #, making world fail to compile with it Here is minimal example that will reproduce the bug reliably: Broken example (# in the string): #if UNITY_EDITOR && !COMPILER_UDONSHARP using UnityEngine; public class MyCoolScript : MonoBehaviour{ public string text = @" # this will break it "; } #endif will cause the following error to appear: [<color=#FF00FF>UdonSharp</color>] Assets/MyCoolScript.cs(6,3): error CS1024: Preprocessor directive expected Working example (no # in the string): #if UNITY_EDITOR && !COMPILER_UDONSHARP using UnityEngine; public class MyCoolScript : MonoBehaviour{ public string text = @" this won't break it "; } #endif Entire area is guarded from U# to be able to do default unity editor code, yet U# compiler seems to see # as a start of a pre-processor directive. Found when making presets for my in-editor annotation utility.