SDK Bug & Feature Requests

Context: Parameter multiplexing systems have become widely used to support an ever-increasing number of features on avatars, and to make room for more than a handful of options once the VRCFT template was added. These systems have depended on the fairly consistent update rate of 10 times a second (0.1s interval) and so have been built with that documented behavior. Recent changes to how parameters are synced have made these systems less consistent, it was stated that these systems were never supported (despite the docs and consistent in-game behavior for years) but efforts are being made to not break these systems. I suggested versioning the Expression Parameters (just like physbones/raycast) so that new features (like bit width, signed/unsigned, etc) would only apply on new uploads, and that expression parameters "1.0" would sync as they have before, in my opinion that's still the best approach (guarantees that existing uploads would remain functional), that was unfortunately shut down "There will not be a compatibility shim, as we are making these changes to guarantee server stability and cost." -@pi . Regardless of expression parameter versioning or not, the multiplexing systems are unlikely to be going anywhere since many modern avatars often use 400-600 bits for their base features (VRCFT aside), and so we'd be encountering the same inconsistent interval issues (be it on all uploads, or only on "1.1" uploads if versioning is accepted as a solution) since the local avatar cannot tell when parameters are sent to remote, as our 0.1s interval no longer holds true, and for the lack of a better timing mechanism. So a parameter update clock is needed, for example ParameterUpdate as a bool, that simply flip/flops it's state once current parameter values are sent to remote users, the interval should be dictated by the "fastest" update a remote user sees (if one user is very close and should see the update in 0.1 seconds and another is very far and only receives an update in 1 sec intervals, it should be based on the closer user's 0.1 interval) as that's been what we've been operating on, though I would not oppose additional options like ParameterUpdateLast for the latest update and ParameterUpdateMedian for when most people would see the updated values. This clock could also be used to drive a local cue for a user for certain features, specially ones that require syncing with remote users, like world drops, by displaying an effect locally when the world drop should be active for nearby/most/all remote users, meaning that moving would not cause it to be misaligned.

Parameter interpolation allows us to avoid blendtree smoothing setups for parameters that share the same local/remote smoothing rates, but not for more advanced uses, so I'd like to request a few things: The option to set local/remote interpolation times independently The option to control interpolation times dynamically at runtime, through another parameter's value The option to define interpolated parameters for contact parameters (without adding them to expression parameters) The option to skip interpolation when a parameter is driven by parameter drivers (new toggle, default to true) Alternatively to adding the above to the interface which can add complexity, give us a parameter "namespace" that gives us access to interpolated values without having to manually configure them in expression parameters, for example Lerp/<duration>/<originalParameter> : Float parameter Val is changed from 0.5 to 1.0 (immediately) Float parameter Lerp/1.5/Val interpolates that change over 1.5 seconds Allow Lerp/1.5/Val to be driven by parameter drivers - if it does not match Val then interpolate from the new value to Val over 1.5 seconds. Driving the interpolation parameter and the <originalParameter> to the same value at the same time would skip the interpolation. Multiple interpolated parameters could be defined for one parameter, like Lerp/0.5/Val to interpolate the same parameter over 0.5 seconds, giving us the option to use one locally and one remotely, and for various other uses. To support point #2, special non-duration definitions could be added too: Lerp/<originalParameter> used locally/remotely with different rates, dictated by: Lerp/LocalRate/<originalParameter> to set the local interpolation rate for the parameter Lerp/RemoteRate/<originalParameter> to set the remote interpolation rate for the parameter Optionally support Lerp/LocalRate and Lerp/RemoteRate without a parameter, to act as a "default" interpolation rate when an explicit override for a parameter isn't set. When rates aren't set, default to the current interpolation rate (I believe that's 0.1 seconds if I'm not mistaken?) Interpolation rate of 0 should be acting as a mirror of the original parameter (no frame buffer), if someone desires a frame buffer they can use 0.0001 or some other impossibly low value that is greater than 0 . Originally posted on the forums here , corrected for local parameters being supported and adjusted Inter namespace to Lerp , in case you'd like to support additional interpolation modes with different "namespaces", though Inter works if you'd add Inter/<originalParameter>/Mode int or suffix the <duration> with the mode like Inter/0.5E/Val for exponential.

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

It would be nice to have "advanced" Parameter Driver operators to: Set/unset bits (if it’s one entry, it should display up to 32 bits as this may be used locally as well, and for synced parameters highlight the “synced” bits in some way like an alternate background) AND/OR bits between two parameters Add/subtract/multiply/divide one parameter with another Copy parameters from X bits to Y bits, this could be used, for example, to “pack” multiple parameters in multiplexing systems, or in save systems (saving multiple synced parameters into a single one since the local one is 32 bits, and loading from one into multiple). Right now without horribly inefficient animator logic it’s practically impossible to set every bit in an int by a bool or set multiple bools via int bits (it’s possible, but it spans multiple frames due to multiple transition evaluations, or requires defining hundreds of transitions, one for each possibility, instead of nesting them), requiring us to create multiplexing int(s) alongside multiplexing bool(s), with these options we could slow down updates to as little as 1 bit per parameter update regardless of type, or reduce wasteful allocations and instead allocate just the the largest bit width used, and fill it with smaller types when the “large” types aren’t currently being synced. An alternative to defining specific additional operations, though I suspect far less likely (especially since you don’t want to encourage further uses of animators for logic, but I’d hope that any alternative we get would support this in the future so this work could be translated whenever the animator exodus happens), maybe an expression/formula operator, where a parameter list is converted to variables (since parameter names aren’t always valid variable names conversion in some form would be necessary, I’m imagining A through Z), and an expression could be performed using them, for example: C = A + B; D = (B & (1 << 3)) != 0; E *= 3; This would give us access to a lot of mathematical operations that are either impossible, impractical, or require complex (blendtree) setups, and could carry forward to action drivers and other animator alternatives in the future. Originally posted on the forums here

They stop driving, but they don't return to 0. https://www.youtube.com/watch?v=3gAO7sRCa4U

I've always wanted to create a two point tied chain with physbones for stuff like gun slings, jean chains and such. I think an addition to the multi-child behavior to allow physbone effects to back propagate up toward the root (Reverse) and also a Bi-directional effect where the root and child bones effect toward the middle (or perhaps the physbone force is negated backwards), creating a sort of a normal distribution, would allow for physbones to seem like they have multiple points attached. It would still be limited to one physbone, so maybe a more advanced system would be to be able to attach two seperate physbones at their endpoints allowing for avatars to have a rope in one hand connecting to the other hand, sagging in the middle.

If you don't rename the hand gesture animations after copying them from the VRChat SDK, VRChat will keep using the default ones There should be a warning about that in the SDK when you use an animation with a name that starts with proxy_!

I developed (with use of AI) a simple lightweight script for copying VRCAvatarParameterDriver behaviours across animator states. It saves a lot of time when making avatars and it would be really nice if you added it to avatar SDK so that other people could experience this time saving tool without needing to download anything from 3rd party. I reliquish all rights to this script if you decide to add it. Feel fre to modify it if you do.

If you preview a blend shape and then swap to none, the value isn't reset to 0. It stays at 1. This makes it easy to miss that you've changed something that you don't intend to have changed. Since it saves the preview value to the default value on the mesh renderer on save. Which is not great One confusion moment for example. * Set Eye lids to blendshapes since you're unsure first time * Set up the mesh and the blendshape, click preview on blink * Realize your mistake, swap over to Face tracking. *Upload. The avatar is now uploaded with eyes closed. Since the preview doesn't clear.

With the SDK 3.10.2 update, the Avatar Expressions Menu editor received the following UX change: When targeting a Boolean parameter, the Value attribute is now hidden and is always treated as enabled, since that's the only valid option for a Boolean (true when activated, false when deactivated). While I understand the reasoning behind this change, it removed a useful workflow that was previously possible. Before this update, it was possible to create two menu controls targeting the same Boolean parameter: one with Value = True and another with Value = False. This allowed both controls to toggle the same parameter while only the control matching the current state would appear visually active. For example: Badge toggle (Value = True) Nameplate toggle (Value = False) When the Boolean is true, only the Badge toggle appears active. When it's false, only the Nameplate toggle appears active. This made it possible to represent two mutually exclusive states using a single Boolean while providing clear visual feedback in the Expressions Menu. Since the Value field is now hidden and always forced to true, this behavior is no longer possible. I'd like to see the Value option restored for Boolean parameters, even if it's tucked behind an advanced setting or warning. While the current behavior is simpler for most users, the previous implementation enabled legitimate use cases that are no longer possible.