SDK Bug & Feature Requests

Right now we have to set the eye rotation values quite high to get decent eye movement using eye-tracking after the recent native face tracking update. Due to having high values, now players without eye tracking have to deal with somewhat extreme movement which can go against the creators intent for the avatar. It would be good if we could instead be able to decide separately the rotation values for when eye tracking is enabled and disabled.

I want to be able to lose precision for the local user for radial menu items, to keep consistency with the remote user, this is for body customization options that will use very low precision. Ex. If the parameter width is 8 bits, the radial should move in steps of 12.5%

Requesting a function for facetracking parameter behaviors to simplify mapping a tracking key from one range to another. Arity-5 version allows specifying both the input and output ranges: map(key, in_start, in_stop, out_start, out_stop) Arity-3 version assumes 0 and 1 as the input range (basically the same as lerp ): map(key, out_start, out_stop) Performs this equivalent operation: out_start + (out_stop - out_start) * ((key - in_start) / (in_stop - in_start)) I'd also suggest providing a version which additionally clamps the result to the output range, maybe called cmap . One use-case for this is to be able to easily remap tracking keys to bias them in certain ways while allowing the user's facial movements to still contribute to the expression's livliness. For instance, in a "Sad" blendshape set, you might want to remap the "BrowInnerUp*" tracking keys to the range of 0.7 to 1.0 to force a sadder look. How this function would be used to accomplish this example: Apply to Blendshape, "BrowInnerUpRight", Custom Blendshapes Set: "Sad" Expression: map(BrowInnerUpRight, 0.7, 1) It reads a lot better than (BrowInnerUpRight * 0.3) + 0.7 to get the same result and I don't have to work out the math for each range I'm trying to target. I foresee this also being used a lot to bias eye dilation/constriction for a lot of different emotions.

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

Currently, when multi-editing contact receivers, you can enable "Write to Materials" but cannot edit any properties. For a number of systems, it makes sense to allow for multi-editing the "Target Renderers" and "Write Matching Tag Bitflags" sections. The "Shader Parameter Override" would also be useful, but would have to come with a warning about clashing if multiple renderers have the same tag set, as it will behave unpredictably (an additional canny will be posted for this)

Currently, when editing shader parameter overrides in the "Write To Materials", if you attempt to write the same material property to the same renderer, if enabled it will only display one of them and won't be predictable as to which. While there is a valid case to allow it to happen from multiple receivers to the same mesh (when only one is enabled at a time) this can cause unpredictable behaviour if you're not looking out for it. It would be beneficial to, in the info box on the receiver, flag up if you attempt to write the same property to the same mesh over multiple receivers as potentially unpredictable and warn you should do this "only if you know what you are doing".

Issue: The current Advanced Parameters are set based on the sender with the closest proximity to the receiver. This makes sense for most of the advanced parameters but I would like to argue that Constant Contacts could benefit from being able to return a combination of matching tags from all currently contacting senders, not just the one with the closest proximity. Specifically, there are cases where you may have multiple senders in contact range you want to get the tags from but the limitation of only grabbing the tags from the closest sender forces you to continue to use multiple stacked receivers the old fashioned way. Usecase: In the attached screenshot is an example of where this could be useful. Multiple Receivers are needed in order to detect multiple contacts within range. i.e. all the fingers and hand contacts on a hand. A single Advanced Parameter Reciever would only detect and return the tags one of the 6 contacts on a hand. Another usecase I've seen in the past was a Contact based PVP system where each damage zone needed an additional receiver for each damage type. Multiple damage sources could be affecting a damage zone at a time so the new Advanced Parameters would also fail here as again they would only prioritize the closest sender. Hypothetical Usecase. Say a user has a sword that can switch elements. They have a SharpWeapon contact that is always active cause it is a sword, but also have fire, water, etc. contacts that they toggle on/off as they switch elements. A receiver with the Collision Tags Advanced Parameter currently will likely only return either the SharpWeapon or the Element contact but not both. (In this case it be solved by including the SharpWeapon tag on each of the element tags but the underlying problem still remains)

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.

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