SDK Bug & Feature Requests

In the new SDK 3.7.6, it's now possible to build a world on Linux, but it is not possible to launch a local test with proton. Pls add proton support, similarly to: https://github.com/BefuddledLabs/LinuxVRChatSDKPatch

Please provide fallback shaders with VRCSDK and API to get them from material. There are multiple possible use cases like: To create avatar with exactly same look with and without Fallback - Currently, since we don't have fallback shaders, we cannot create avatar consistently looks same with and without fallback. To create Editor Extensions that shows the fallback-ed version of the avatar. - There are some editors exists but their implementation might can be different. - There is no documentation that explains the exact algorithm for parsing VRCFallback tag so we don't know which shader will be applied for wired VRCFallbackTag like ToonCutoutUnlit . To retrieve list of properties used in each fallback shader. - I want to get (current) list of properties supported in each fallback shader to remove unused properties from the material. - There are list of properties copied to fallback material on creator docs, but some fallback shader may not use some properties on the list (like Toon does not use most properties but _MainTex ).

Having to work on 2 different animator layers is becoming a bit of a chore, for example, if i want to switch the material of an avatar, i need to have 2 different animations, 1 for PC and another for Mobile (Assuming PC uses a non VRC Shader which is 99% likely) Multiply this for the number of materials, make this more annoying by having atlases and different skin mesh renderers, and it becomes spaghetti very quickly The “isMobile” parameter would be a boolean that is False when the avatar loads the PC Version, and is True when it loads a mobile version. Allows people to work on a single animator layer for both platforms

Please allow users to select another parameter as the value to set for a given parameter. This will simplify the process of designing systems that synchronize multiple parameter values. For example, this feature would enable variable assignment—such as setting ParamB as the value for ParamA—to make ParamA and ParamB have the same value.

This is a less "official" kind of report, and I sincerely apologize if I come across as rude or anything of the sort. But the removal of various avatar uploading features for quest is completely unwarranted. For example: Alpha Blended particles. I have personally used and uploaded Alpha Blended particles to VRChat for quest on numerous avatars with absolutely zero issue, they worked perfectly fine. If I'm correct, they were removed for performance reasons.. this makes absolutely no sense to me or any of my other avatar creator friends. The performance issue regarding the quest build has absolutely nothing to do with particles and everything to do with avatars bypassing security measures through 3rd party SDKs. The avatars from illegal uploading should not be used as an excuse to punish those who use the official SDK. And even if It is 100% certain that particles are the reason for performance reduction. You guys seem to have already fixed that! There is a particle count limit on the quest side. I tested this myself, the maximum an avatar can spawn at one time is around 100K particles from a single system. This test was me trying to crash myself and willing participants with over a dozen particle systems all spawning the integer limit's number of particles. It instantly crashed PC users, but quest users stopped noticing increasing lag at a mere 150,000 particles being on at once.. thus proving the existence of the hard limit for particle count on the quest platform. And so the question I have is, if there is already hard limits for that, why is Alpha Blended still incompatible? If it was truly removed because of performance, and that has been fixed by now, why not add it back? As for the other shaders in VRChat/Mobile, What I would like to request is VRChat/Mobile/Toon Standard (Outline) become quest compatible, specifically the outline feature. It is 100% possible to do this, I have seen numerous quest exclusive games that run on unity use shader based outlines. Additionally, I have seen some VRChat avatars on quest that were uploaded through an illegal SDK use that specific feature from the popular Poiyomi Shader. If I'm not mistaken, the entire concept of /Toon Standard and /Toon Standard (Outline), was almost entirely inspired from Poiyomi Shaders. So why is this not a feature even though its in the VRChat/Mobile shader pack? Respectfully, if performance complaints are truly the only reason as to why these features are not in the game, then that is not the game's fault/problem, it is the development team that is at fault. Instead of coddling the complaints of players that are too young to even play the game, maybe let them crash a few times to teach them to use YOUR features and hide an avatar or two. Its not the game's fault for an 8 year old entering a 40 person lobby, only to then MANUALLY show EVERYONE's avatar, and then REFUSE to hide them when they start lagging. The reason I point out the word "manually" is your game's DEFAULT safety settings literally prevent certain thresholds of avatar limits from being shown automatically. In order to change those thresholds you have to specifically go into your settings and mess with them manually. At that point is it really a performance issue if they literally ask for it? Take this for example: lets say hypothetically a massive game were to be fully released on mobile. Specifically meant for high end mobile devices, I then download it onto my cheap phone and crank the settings as high as they can go. That is an example of what the "performance" issue in VRChat is, its people refusing to optimize with features you give them. Instead of lowering the limits for quest every time some new crashing method gets figured out, maybe inform the people of the features specifically made to protect yourself from avatars? Lowering limits for uploading to the quest platform (which if I'm not mistaken is the larger side of the game's player base) is just making it worse. As much as many others would deny this, VRChat would be absolutely nothing without its creativity, its literally the entire game. Removing/Lowering creativity because people refuse to optimize is just bad business. There are always going to be crashers, there are always going to be laggers, there are always going to be people that ruin it for everyone else. That's just how gaming works. Punishing everyone else just because of a few bad actors is a good way of getting everyone to walk away from the game. All in All either remove the incompatible shaders from the /Mobile selection, or make everything in /Mobile compatible with quest. Its getting genuinely annoying when I make a cool looking avatar with cool looking effects only to be slapped in the face with it being incompatible with quest even though I am using /Mobile shaders.

Issue: Not too long ago players who are currently leaving have been made valid when using the VRCPlayerAPI.IsValid() check. While this allows using them during OnPlayerLeft etc, it has made knowing when you are dealing with a leaving player a lot more difficult. When you are for example manually checking who to move ownership of a system to, you have to cache your self that this player is in the process of leaving in OnPlayerLeft . Suggestion: Add a VRCPlayerAPI.IsLeaving check, this should return true if this player is currently in the process of leaving the instance and false if not. This should allow making systems like thew following easier to implement; public override void OnPlayerLeft(VRCPlayerApi player) { leavingPlayer = player; } /// <summary> /// Returns the <see cref="VRCPlayerApi"/> of a whitelisted player in the instance. /// Useful for getting a player to move ownership of an object to. /// </summary> /// <returns> /// A <see cref="VRCPlayerApi"/> of a whitelisted player in the instance, /// or <c>null</c> if none are present. /// </returns> public virtual VRCPlayerApi _GetPlayerInInstance() { var players = new VRCPlayerApi[VRCPlayerApi.GetPlayerCount()]; VRCPlayerApi.GetPlayers(players); foreach (var player in players) { if (!player.IsValid()) continue; if (!_IsPlayerWhitelisted(player)) continue; if (player == leavingPlayer) continue; return player; } return null; }

The contact system is limited to 60 updates per second, in scenarios over 60 fps, the contacts will maintain information from a prior frame, for systems expecting an update every frame, this leads to incorrect assumptions, which can break logic in unexpected ways. This can be prevented by adding a parameter to indicate whether contacts have updated this frame (i.e. ContactUpdate ), this would allow us to short-circuit every contact-based transition to only evaluate when we know contacts have up-to-date values, avoiding these problems. An inverse of the parameter (i.e. ContactUpdateSkipped) can currently be implemented by using a Proximity contact and setting it's value to non-0 every frame, on frames that the contact receives an update, the value will be overridden back to 0, adding the parameter as a boolean in the controller means that contacts have updated when the parameter is false (can undo the inverse behavior by adding an overlapping sender, but that adds another runtime component).

Add a animation parameter that allows users to adjust their floor position. This feature would be useful for offsetting toggles related to various footwear options, such as heels or bare feet, and could also enable more creative solutions. Without this parameter, users may experience issues like clipping or floating above the floor when toggling these parts. I first considered this functionality a long time ago, wondering, "Why isn't this possible?" Recently, I was reminded of it when a creator on Booth aimed to develop content for a broader audience, including not only full-body tracking (FBT) users but also half-body and desktop users. They expressed frustration at having to resort to less-than-ideal solutions due to the lack of this functionality. I'm open to discussing alternative solutions beyond just an animation parameter. Perhaps a component similar to a VRC parameter driver, or another approach, might be more suitable for this purpose. I’m interested in exploring different options that could effectively address the need for adjusting floor positions in various contexts. I’m not sure if any Asians will read this, but regardless, I’ll post the first paragraph in each language. ChatGPT 사용자가 바닥 위치를 조정할 수 있는 파라미터를 추가하세요. 이 기능은 힐이나 맨발 같은 다양한 신발 옵션과 관련된 토글을 조정하는 데 유용하며, 더 창의적인 해결책을 제공할 수도 있습니다. 이 파라미터가 없으면, 사용자는 이러한 부품을 토글할 때 클리핑이나 바닥 위에 떠 있는 문제를 겪을 수 있습니다. ユーザーが床の位置を調整できるパラメータを追加してください。この機能は、ヒールや裸足などのさまざまな靴のオプションに関連するトグルを補正するのに役立ち、より創造的な解決策も可能にします。このパラメータがないと、ユーザーはこれらのパーツをトグルする際にクリッピングや床から浮く問題が発生する可能性があります。 添加一个允许用户调整地板位置的参数。这个功能对于调整与各种鞋类选项（如高跟鞋或赤脚）相关的切换非常有用，并且还可以启用更具创意的解决方案。如果没有这个参数，用户在切换这些部件时可能会遇到如穿模或浮在地面上等问题。

Similar to other VRCTween extension methods, this would fill in the GameObject value of the VRCTween.DelayedSetActive(GameObject target, ...) value. Used like such: gameObject.DelayedSetActive(false, 3.0f);