euan Ill answer this point for point ^^

Point of note is, this issue affects remote view of the users avatar. The users that are affected will see their own avatars in mirrors completely fine locally but remote users cannot see any changes that the user sees in local view.

So I could change my hair from white to black for example, I would see it myself locally but nobody else would be able to see it until hours later when instance population drops lower.

If a user were one of the early ones into the instance, their avatars would work fine, but if they were to leave by crashing or disconnecting and then rejoin later again through the queue system then their avatar would also be affected and be seen as "default state".

Has to be mentioned, this issue did not occur in the earlier months before the mentioned period while being the same social event and through the same avatar(s).

It seems to affect any late joiners' avatar, so it is not related to one specifc avatar and is more of a broader issue. I just listed my own avatar to answer the question directly.

Early joiners who were present before the world was full/capped seems to be unaffected by this.

A user joining late would also see early joiners fine but late joiners would be the ones affected.

Frajs: For the information (especially date and time) I need exact details so I can cross reference things server side. Regarding the usage of the parameter compressor I would try uploading a version which does not use this, if you encounter the issue again try using that version and see if the issue persists. This would highlight the issue being the compressor or rule it out (which would be quite useful to know)

euan To be sure you can check sunday august 9, 10AM CEST as that was the most recent. We were there for hours so anything around that timeframe is relevant.

World: Just B Club 4.0 #59296

On the topic of parameter compressors I had to do a double check on my avatar and it appears it should not utilize the compressor component of vrcfury as the total parameter usage of the avatar should not exceed 256 (it only applies if parameters surpass that limit, had to do a little checkup on that) as my avatar is relatively simple with limited options.

However, this still seems to affect avatars that also do utilize this feature though. Unless the user was present in the world before it was full

Frajs: I double checked the avatar you mentioned "avtr_f5de67ae-cede-40a7-a652-7eecec03d8d7" and it does appear to have parameter compressor logic on it. Regarding the instance and time you mention it's hard to confirm based just off an hour range rather than minute but it does seem there was upstream issues at the time you mention for the server that instance was on, that could be a notable factor

euan hmm, interesting. That should not have been the case from the info I've been given but oki.

But as mentioned, this is happening across a large range of avatars and not just my own. This happening is fairly recent and the issue repeats every single week so there is definitely some kind of issue that has recently surfaced that was not present in the past before the summer.

I can see I was there for a bit more than an hour but this was mostly cause these gatherings are frustrating to deal with due to so many users being negatively affected by this issue so people end up leaving.

As the problem appears to be systematically happening repeatedly so I would appreciate if this would be looked into as it is definitely having a very negative effect on social gatherings.

Normally I can look past small things that arent noticeably affecting us, but this issue is causing people to become upset and frustrated to the point where they simply leave so I am making this report for a good reason.

Frajs: This issue has been looked into for some time, and was thought to be resolved some weeks ago as reports stopped coming in. The issue with solving this has been a lack of reports with actionable details, in order to investigate and resolve an issue like this various specific details are needed and optimally reliable reproduction steps. Although you and others have given reproduction steps we haven't been able to reproduce it, it seems there's more to the issue which has yet to be worked out.