狐小百合: This problem is present because the camera position you load into when joining the world instance is what loads the instant the world renders, if there are far too many avatars (e.g. great pug) at the spawn location, your game will kick you out of the instance as soon as you join. A solution to this (For VR users) is to look straight up or down as the world instance loads, as not to overwhelm your cpu and ram when you start up the world.

danly: Keep us updated on your findings if you can. :)

CurtisVL:

There was a bug in both the baseline calculation, and in some sync behaviour calculation, that could inflate the time.

I'm still working on it. :)

danly: Finding what is likely the cause is a great start!

Keep up the good work. :p

danly: In build 793 there appears to be a new issue when users load in. They may load into a position that is incorrect for all users. Their capsule hitbox and nameplate are in the correct position but their actual avatar and voice are off by some arbitrary amount, probably somewhere in between spawn and the interpolation to where they actually are. This offset was seen by all players that were standing around the user.

Along the same area of loading avatars I have had people get stuck in desktop mode after loading even though I know they are in vr. (The time it takes to go from loading avatar to seeing hand movement is also still too long and seems to be causing issues.)

The fix for both of the above issues is to hide and then unhide their avatar to have them reload correctly. As soon as the blocked avatar appears both their position and hand movement are instantly corrected. Unhiding then just appears to show their personal avatar correctly as expected.

Observer.: Make a separate Canny for this if one doesn't already exist! :p

danly: Correct me if I'm wrong, but the 'inaccuracy' issues people are witnessing (What feels like low sync interval), are they caused/affected by the stuff you're working on too?

It feels like it smooths/interpolates too much between syncs, I thought that might have been due to the delay causing it to still be setting the last pose when a new one is received or something.

CurtisVL: The avatar sync is slower, yes. I'm working on improving it, but that will be a while yet; there's constraints that are difficult/hard to move that we have to work within.

Observer.: yes, this is a known bug; thank-you for reporting it anyhow. :)

danly: Thanks for the info!

From my tests:

My ping: 165

Other person's ping: 80

Hugo Zink: Thanks, that helps narrow it down.

While pings in this game are quite a big issue, that is certainly not the cause of the delay here. It was fine before the networked IK happened.

My ping is 160 and the other person's ping was 80. There is no reason for the delays to be two seconds long. This only happened after the networked IK update. Before that, the delays were large for us Europeans but still tolerable. The delays still seem to be large between two north americans, too.

Here's a video which demonstrates that the issue is indeed on VRChat's end: https://streamable.com/6tip9

The audio in the external application is arriving FAR sooner than the action ingame. Obviously this isn't acceptable for a social VR game.

danly: Ping is not the root issue here. On the previous IK there was a delay as noted due to ping, update rate and interpolation, etc. This new newtorked IK has increased the total delay significantly making it unable to be ignored. We have gone from acceptable delays which was noticeable but manageable, to a horrible ~2.0+ second delay right now and further delay issues with things such as loading. In some cases its not just a delay but outright incorrect which are other things to be solved later.

To purely blame ping and connection quality when we are already directly comparing the IK changes to our unchanged connections is very dishonest.

There was a change elsewhere in the release of network ik that impacted simulation delay; the ik change itself adheres to that calculated delay and shouldn't apply additional delay.

You're seeing that in the loading delay et al.

Which is to say, I know it's the client; but knowing the state of your connection helps to determine _what_ about the client it is, so that I can improve it.

danly: What exactly do you need to know from us when reporting this? Your original comment appears very patronizing in regards to just brushing off the delays as user connection issues.

I presume now you wanted to know if it was a ping related issue. Is there anything else we can tell you based on our tests that could help narrow things down for you?

Observer.: My apologies! Sometimes I just spew out technical thoughts and I don't think about how it might be perceived by a reader.

One other thing that occurred to me that would cause this: every room can set its "update rate" in the Scene Descriptor. That _directly_ effects the latency that one would experience.

danly: It might be entirely possible that world creators are increasing the update interval to 150ms thinking it would do the opposite and be the updates frequency rather than the update delay. Or just that the default 66ms interval is too slow as a default with this new system.

Does one of the debug menus in vrchat display the update interval of the world, because it would be good to know for worlds that I consistently visit and have noticed these issues to compare.

Observer.: Yup!

Send Interval, in Debug Menu 4.

danly: If it helps to know, voice is still normal, and doesn't appear to have any noticeable packet loss/connection quality issues. It's only IK that gets behind.

From talking to others, it seems the delay is affected most by ping as there's no EU servers, but it's clearly more than 180ms~

I guess if internal testing is done within the office, or at least with other US developers/play testers, this issue wouldn't have been found easily. :p

I'll create a little SteamVR overlay stopwatch and see if I can get some rough numbers for the delay I witness, though human reaction time comes into play so they will be very rough numbers!

danly: What would you recommend the update rate be set to in the scene descriptor and why did this setting not affect simulation delay before the networked IK?

Additionally, can you please go into further detail on what exactly is going on behind the scenes and what you think is/was causing the 2-4s delay in replication that we see on live servers?

CurtisVL We've got a repro case built internally now, but thanks. :)

Rak it's really only meant to be fiddled with if you are targeting low-performance connections or similar. It's a vestige from days past.

The Simulation Delay scales linearly with your Ping, Quality, and Update Rate. At 180ms ping with perfect quality and standard update, I'd expect a simulation delay of 560ms or thereabouts.

The Sim Delay exists largely to avoid corrections, which cause nausea for VR players. We interpolate, we don't extrapolate.

danly: Prior to the network IK update, with my ping of 90ish the total delay was closer to 300ms, right now(haven't checked in 2019.2.3 yet) the total delay is 3000-4000ms. That is completely unacceptable and makes VRChat feel like a turn based strategy game. Honestly you guys should be aiming towards a 200ms delay + user ping, anything more than that starts to ruin interaction between players.

Anyway, what I was really asking is, what was/is causing the 3-4k ms delay?

Rak: that sounds like a bug; which it is!

A 90 ms ping ought to have a delay of about 200ms.

Yes, it is indeed pretty much identical to live.

After the last beta update (Build 785), the delay is still quite noticeable (0.8 seconds), but not as bad as it was.

Hugo Zink: Yes, I haven't stopped working on it and fiddling.