World/Udon Bugs & Feature Requests

Checking the equality/inequality of a system-defined enum with equality/inequality operators ( == / != ) will fail. As a result, this example codes in the document don't work as expected: https://creators.vrchat.com/platforms/android/android-best-practices/#2-detect-mobile-players-in-your-world-automatically public override void OnInputMethodChanged(VRCInputMethod inputMethod) { if (inputMethod == VRCInputMethod.Touch) { // Run code for touch input } else { // Run code for non-touch input } } (The UdonGraph version (attached image) also has an identical issue.) Workaround Cast to underlying values and compare them. if ((int)inputMethod == (int)VRCInputMethod.Touch) Analysis UdonSharp compiles the expression inputMethod == VRCInputMethod.Touch into EXTERN, "SystemObject.__Equals__SystemObject__SystemBoolean" Although Object.Equals(Object) is overridden by Enum.Equals(Object) , which the inputMethod may have, with comparing underlying value, this EXTERN seems to call the Object.Equals directly (maybe via reflection API), and it returns the unexpected result (by only comparing the referencing instances). The EXTERN, "SystemObject.__Equals__ comes from here https://github.com/vrchat-community/UdonSharp/blob/22307065bd408dfd163fe46b0b8b701a4efcbc00/Packages/com.vrchat.UdonSharp/Editor/Compiler/Binder/BoundNodes/BoundInvocationExpression.cs#L420 And replacing the System_Object of this line with System_Enum doesn't work because the Enum.Equals is not exposed. Suggestions Temporary, rewrite the example codes using cast operator Expose System.Enum.Equals And replace the EXTERN with System.Enum.Equals

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.

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のバージョンを最新に保っていただきたいです。

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.

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!

World persistency would increase usability since old in-world settings could load automatically when the user re-visits the same world later. As worlds get more and more complex, this is no longer a "nice to have" feature - it is now absolutely needed to make a more complex world playable (such as playing a long story through like "The Devouring" for people who don't stay 4+ hours in a single world in VR or in case VRChat crashes while playing it). But it is also needed for grinding mechanics and worlds where you can build something and farm resources - something we are currently working on. Tl;dr, either VRChat gives us a [StoreToDisk] string datatype (without a weird character limit) that saves to disk when it changes and loads again when the user joins the same world or we'll have to implement our own open-source solution reading debug log files and a third-party application running on people's PCs to send Ctrl+V to the window handle (as other world creators have already done it). But either way, we definitely can't go on without a solution here and the current "ask a VR user to copy+paste a string" is not a good way to do it - especially since it's not crash-safe, so users lose all progress when VRChat disconnects the user randomly. But also since we still don't have a "Copy to clipboard"/"Paste from clipboard" function next to a TextInput field for whatever reason, something that would be extremely useful for VR users in general anyway. Ideally, an instance could also specify to only load the progress from whoever created it, since it's not possible right now to know who's the instance creator in Udon, but that's only a minor follow-up issue.

Lightmap settings is a method that allows the configuration of lighting probes via LightmapSettings.lightProbes.bakedProbes This allows the lighting conditions to be swapped for movable objects without the use of dynamic lighting. EG Daytime, nighttime toggle. Offering a preferable performance result compared to realtime lights, with no extremely noticeable difference visually. It also includes some other lightmap related features that may be useful for creating optimised worlds, I have not personally checked into anything except the probes. It may feature some way to adjust the lightmaps themselves, but I have only explored achieving that through editing the renderers, which works quite well already. I've attached an image of my discovery that it isn't exposed, just to be clear which function it is that I think would be useful.

Udon 2 is VRChat's upcoming replacement for Udon. "Udon" is a feature of the VRChat's Worlds SDK. It allows users to write custom scripts with the Udon Graph and UdonSharp. Udon 2 runs WebAssembly instead of UdonAssembly. Programs are compiled into C# script assemblies using Roslyn and run within VRChat using the same runtime as Blazor. This means that... Most C# features are supported, such as Lists, Dictionaries or Actions. Scripts in worlds uploaded with Udon 2 will generally perform better. Existing worlds will continue to work as before. Udon Graph programs are compiled into C# instead of UdonAssembly.

PlayerId can be obtained at VRCPlayerApi. This will be given a unique ID in the order of join, including players who have joined in the past. Details: Unlike the PlayerId above, this request is for a unique ID to be assigned to the currently joined players. Example: There are A to E. At this time, IDs are assigned as follows. “A:1 B:2 C:3 D:4 E:5” Here, when A and D are left and F, G, and H join, I would like it to be assigned as “B:2 C:3 E:5 F:1 G:4 H:6” Reason: This is useful when granting objects to be synchronized to a player, such as game worlds. The current PlayerId is not enough to determine exactly which objects are available at the time of Join. * PlayerId cannot be assigned an Index of a finite number of objects, because PlayerId is infinitely increasing. * If two people who enter the room at the same time get the owner of the same object, it will not be determined until the resolution is completed. With this UniqueID, it can be used as the Index of an object at Join time, eliminating the need to deal with the difficulties of synchronization. It would be good if it could be obtained by VRCPlayerApi in the OnPlayerJoin and OnPlayerLeft arguments. ======================= Original text: VRCPlayerApiにて、PlayerIdを取得できます。 これは、過去にJoinしたプレイヤーを含めて、Join順にUniqueなIDが付与されていると思います。 詳細： 本リクエストは、上記PlayerIdと異なり、現在Joinしているプレイヤーの中でUniqueなIDを付与してほしいというものです。 例： A～Eさんがいます。このとき、IDは以下のように付与されています。 "A:1 B:2 C:3 D:4 E:5" ここで、A、Dさんがいなくなり、F、G、HさんがJoinしたとき、 "B:2 C:3 E:5 F:1 G:4 H:6" と付与してほしいです。 理由： ゲームワールドなど、プレイヤーに対して同期するオブジェクトを付与する時に有用です。 現在のPlayerIdだけでは、Join時にどのオブジェクトが使用可能であるか、厳密に判断できません。 * PlayerIdは無限に増加するため、有限のオブジェクトのIndexを割り当てることはできない。 * 同時に入室した2人が同じオブジェクトのオーナーを取得する場合、その解決が終わるまでは確定しない。 今回のUniqueIDがあればJoin時にオブジェクトのIndexとして使用できるため、同期の難しい対応をする必要がなくなります。 OnPlayerJoin、OnPlayerLeftの引数のVRCPlayerApiにて取得できれば良いと思います。

Having the ability to dynamically change these values via Udon would allow for large performance gains in worlds and make world optimization far easier. https://docs.unity3d.com/ScriptReference/Camera-layerCullDistances https://docs.unity3d.com/ScriptReference/Camera-layerCullSpherical Visual example of how these values work: