Avatar Bugs & Feature Requests

There could be an option to include an "Extended Range" variant of Radial Puppets that allow players to use a float for its full precision range. As far as I am aware, floats only have 256 possible values when networked in avatar parameter terms, meaning that each step of a float cover about ~0.3% per step (assuming dividing 1/256) which is great! Until... you consider that Radial Puppets only go from 0 to 1, and floats entire range is from -1 to 1. Because of this, a lot of avatars are wasting half of their float precision being used for most of the time, nothing. In MOST cases this is fine (Nobody has complained about this so far...) but it still only leaves you with ~0.7% per step (dividing 1/128) and that is nearly 1%. Depending on your setup, animations and more, this can look pretty jagged and 'stepped' through the network to other players. Either as a variant or a toggle on the current Radial Puppets. This also means that most people wouldn't have to worry about turning off this feature and instead has to be manually selected when making your Avatar Menus.

Found an issue w/ box contacts where some setups of box contacts, specifically thin but large ones, may fail to register contact with long but small radius capsule contacts. Link to a public test avatar that reproduces the bug: https://vrchat.com/home/avatar/avtr_26c7bcfd-7035-4087-a4c2-d7d6522775de The public test avatar has meshes that are accurate to the contacts which also react to the contacts touching. Steps to reproduce: Add a box contact Receiver which is long and wide but thin on one axis. Add a capsule contact Sender which is long with a small radius With the contact overlay open move the contacts around and test contact between the two Observe that it works when the capsule is touching the edges of the box contact but sometimes does not register contact when the capsule is placed in the middle of the box contact and rotated so that it is not perpendicular to the surface of the box contact. The contacts correctly register collision in these circumstances: * Capsule is touching an edge of the box contact * Tip of capsule is touching any part of box contact * Capsule is contacting somewhere in the center of the boxes face and is perpendicular to the face Contacts do not register collision in this circumstance: * Capsule is contacting the box in the middle of the capsule, capsule is NOT perpendicular to the face(s) it is intersecting with, Tips of the capsule are not touching the box. My best guess as a hobbyist dev based on what I'm seeing here is that the math for detecting the closest point on the line defined by the capsule contact might be returning an incorrect value. Attached Files: The attached file is a video showcasing the bug. Note the contact stops working when the capsule is inserted into the middle of the box contact at an angle

hello ive been having issues when recording in vr, ever since the recent update why does some avatars jitter when they are dancing? its really frustrating. tried checking on servers and changing it on different instance, its getting better but not really solve the problem. definetly not my OBS because i checked that twice. the thing is one of my dancers are from EU region and when we change it to EU region the jitter is less obvious. BUT ITS STILL THERE. it wasnt like this before the unity 6 trial update because i think i heard you guys are slowly transitioning to unity 6. now there has been more than 10 encounters to this problem and somehow it all happened in different ways. for an example, avatar A was okay with the tracking on day one. and then on day 2 avatar A is having the jitter on recording. does that make sense? does Server choice matters to this problem?

In many scenarios, we could reduce the number of contacts required for systems by a factor of 8x or more if receivers exposed more information about the current collision. This is very necessary to avoid the undocumented vrchat "hard nearby contact limit." This additional information could be exposed as parameter suffixes, just like _Stretch on physbones. Specifically, these parameters would be very, VERY useful, and allow for an ENORMOUS reduction in contacts: * X, Y, Z offset of the nearest collision in world units but LOCAL rotation (for example, z should be "forward" of the contact) * Whether the nearest collision is self or others (or world?) * Velocity of the proximity (change in collision proximity since last contact update / time delta, this is very difficult to calculate in animator since contacts do not always update every frame) * Velocity of the sender (change in sender position since last contact update / time delta) * Matching tags of the nearest collision. This could possibly be exposed as multiple bools <receiverparam>_Tag_<tagname> = 0,1

The "Reset Avatar" option takes up far too much space in the top menu of the Expressions radial. -- With it being an option to completely reset all params of the avatar, I've found myself frustrated at how often I would accidentally reset myself when attempting to change an item or emote. Placing this option around the same area as the AV3 Debug would feel much more at natural.

the reset button on the expressions wing is right where the back button is when in a sub menu. I have now multiple times already hit it by accident when trying to go back up, I guess I could get used to it and be more careful, but I think moving the button to the main section would be helpful. Especially since I could see myself using the button even when I'm not actively changing the expressions.

Syncing has been a major issue between VRChat avatars for many years. Ensuring that other people see parts of your avatar in the same place—regardless of whether they’ve just turned your avatar on, joined late, or are looking in the mirror—is one of the biggest challenges for anyone creating complex avatars. The lack of a reliable way to sync avatars stifles creativity and limits what users can do. What we need is a "Freeze to World" and "Rebake Offset" option on VRC constraints, or a new command that allows game objects or bones to be synced over the network. Community-built workarounds for these issues have helped a lot (VRLabs has done some great work on this), but they come with their own performance costs and animator complexities, making them unsuitable for all situations. World objects are cool, but not every situation needs a world-droppable campfire or DJ deck. For example, I want to be able to take the helmet off my avatar, leave it on the table, and have everyone who joins see it there.

Currently the only way to see what "Version" the Avatar you're uploading is, is through the SDK Builder Panel. I think this should be actually used in-game, with a line added in your Avatar Details showing what the Version Number of your Avatar is returning. In addition, I would like to see a feature where it would be possible to make that same version number be inserted automatically in your Avatar's Name (at the user's discretion) through a text argument in the SDK Builder Panel. Something like <!version>, which would insert the Avatar Version number in place of that argument. Example: An Avatar named "Dragon v1.0.<!version>" that has the Version 4 in the SDK, would return as "Dragon v1.0.4" in-game.

I would like to have a proper way of updating the PhysBones integration forces within an animation while the PhysBone is running. This would make it possible to implement some avatar features, such as being able to remove an item (such as glasses or a hat) and drop it into the world. At present, the documentation specifically calls out the integration forces as not being animatable, and suggests an unsupported workaround of toggling the component off and on, but doing that causes other problems with the interaction. Ideally, any change to the integration parameters would automatically cause the physics to update internally, although if some other signal is required to tell it to update the simulation (such as toggling a property from the animation) that would also be acceptable.

We'll be adding a new feature to Toon Standard for recoloring the base texture with a 4-channel mask. Here's how it will work: Each channel has a separate color to use for recoloring. Recoloring is done by first converting the masked area of the main texture to grayscale and then applying the color, meaning you don't need to author your main texture in grayscale to apply recoloring. This is similar in concept to hue shift, but a direct recolor instead of a shift from one color to another. Masks can also be used for emission through an emission slider for each channel. There are two options for blend modes: Multiply and additive. - In the multiply blend mode, the grayscale version of the main texture is multiplied by the color. - In the additive blend mode, the chosen color is added on top of the grayscale version of the main texture.