Last time I checked discord accounts have numbers assigned to them, and VRChat has GUID, which is also numeric and immutable. If someone has either account stolen or replaced, that’ll be something to handle. OAuth would make this easier yes, but I’m not sure if VRChat would want to offer this.
I think for an OAuth time scale, keep an eye on the creator economy, first announced three years ago and when it’s brought up again there is lots of discussion.
Knew about discord IDs, didn’t know VRChat had guids. That helps a bit but is still kind of annoying
Would this be why you’ve also done away with most icon selection buttons, like the ones that were available for avatar blocking by performance rank, portal drop behavior and for chatbox position? The chatbox position icons remained in the quick menu following the big menu redesign, which I hoped meant the out-of-place looking black bars with cycle arrows were temporary, but now you’re bringing them to the quick menu too and removing the icons that remained, it feels less accessible to me that I have to cycle through options to figure out what they are when previously icons (and their descriptions on hover) showed all the options at once.
Edit: Nameplate/Hud visibility and other settings have/had icons for all the options and they all appeared at once too, the more options there are to cycle through the more clicks it might be to reach the one you’d like to use for a given situation, I tend to change hud visibility quite often and personally I find the way the setting is listed now with the generous button sizes is way faster and easier to use and understand while in VR.
any plans on ever adding a desktop mode/vr mode indicator?
would be neat to see if all your friends are in desktop or in vr on the website before you launch vrchat
i’ve actually made a canny about this:
Is there any desire to have hard limits on constraints like there are for the physbone components? Having just a few avatars push you over the constraint performance cliff is annoying in clubs and other large worlds.
The interesting thing is that there isn’t just one cliff, there are multiple, almost assuredly all at values equal to 1/3 of powers of 2 (342, 683, 1366, etc).
I’m just excited for impostors so we don’t have to think about quest compatibility that much.
Another reason why I wish granular safety settings were a thing. If you could just set your constraint limit to something specific, there is a much higher chance you won’t hit that falloff but can still show “very poor” avatars.
I notice that you say the following:
It seems that the frame time of PhysBones is mostly reliant on how many transforms they animate
Does this imply that having, for example, 8 physbones components on hair is more performant than making a single component on a hair root?
It is indeed mainly based on Transforms rather than checking collision points.
This is because the hotspot is on the requesting Unity component
Due to the problem of data structure, some processing and conversion costs are required.
Did not see the official distance and cache for physbone to avoid repeated requests
Although I said cache, the main problem is not the locality of the data, but the large workload derived after the request.
This is because the implementation of components is essentially list and tree, with dense branches and load and store instructions, and the IPC is not high.
Be careful not to compare lists etc. in C#, because it is actually an array.
Due to the specific implementation of the instruction, this kind of related work is almost good if the IPC can be maintained at around 1. Secondly, these components do not use job, although the physbones use job.
This leads to bottlenecks that cannot be simply counted in PB.
It also leads to a lot of bone-related work, high frequency and better IPC, especially for the critical path to make the hit cycle shorter, and the architecture with a large cache cannot improve much IPC.
Therefore, the official must effectively increase the degree of parallelization, or provide more mechanisms and methods to save workload.
But this openbeta is a bit disappointing to me, just one more 256 limit?
In addition to the displayed bones will not move, the bones on itself are still all moving?
Can the official explain why more than 256 still incurs a large amount of overhead?
What exactly is optimized?
For all this talk about efficiency, lets not forget that having 256 physbones is kind of conceptually nuts. Most of the time the performance fault lies in the avatar creator for sub-diving their hair/tail/clothes/whatever bones to needlessly absurd levels.
Your whiskers don’t need twenty physbones each 
. There are almost-always ways to handle these things well with few physbones.
VRChat aren’t going to (and shouldn’t) divert resources optimising systems to absurd levels when there are better options available to the few that would benefit, even if it’s theoretically possible to do so.
The number of bones is obviously different from the number of components
The benefits of reducing the number of components in the current situation are not high
… wait, I think I may have misunderstood. Does this new 256 limit apply to the number of transforms influenced by the physbone component, or the actual physbone component itself?
component
Holy moly 256 physcomponents is so many that I thought they must have been referring to influenced bones. Genuinely curious to know what anyone could possibly need more than 256 physcomponents for.
Maybe they want to have more then 256 strands of hair?
On that line of thought I hope enough avatars have their input data preserve so we can compare like 2017 avatar with 2027 and whatever we have in 2037
Kinda off topic, but id be cool if vrchat had an official avatar pickup. Since the ones in lets say worlds is pretty delayed. Of some kind of official limb pickup. Like being able to pick someones hand up . c:
Hey tupper,
My friends and I want to express our disappointment with the latest VRChat update, specifically the 2023.2.3, Build 1309 release. Unfortunately, this update introduced a significant problem with the Social Menu, making it unreliable and causing invites and requests to go unnoticed.
The Social Menu fails to update after around 20–30 minutes of gameplay, leaving us unable to stay connected with friends. Instead, we are forced to use the VRChat website to manually check for any pending notifications, disrupting the experience.
I urge the VRChat development team to prioritize fixing this issue promptly. The Social Menu is a vital component of VRChat, enabling us to connect and communicate. Its current dysfunction greatly impacts our ability to enjoy the game.
This is a known bug! Don’t launch VRChat using a shortcut, especially ones that use parameters that launch to specific instances or worlds. Launch directly using steam.
This also affects when you launch from the website using the “Launch” button.
This isn’t exactly the place to post about issues like this, but in this specific case I thought it would be useful to post openly.
I’m still confirming, but I think a fix for this was put into 2023.2.4, the build currently in open beta.
I think this is the bug report in question
Personally I have the VRChat website open most of the time, because the website will tell me if someone is loading a world. In game it says they’re in private instance when they’re “in between”.
