Psyonix_Cone

Does this mean that the client is constantly showing an extrapolated version of the ball / other players? (And then using smoothing techniques when the server ends up disagreeing with the client rather than having an instant jittery correction.)

For example, if my client has 50ms of latency (25ms in either direction):

The server is at time 100ms

My client has received game-state for time 75ms.

If my client sends an input now, the server will receive and execute that input at time 125ms (ignoring the buffer that causes the server to wait a little before executing the inputs).

Because of this, my client uses the past game-state values to extrapolate game-state (ball / other players) for time 125ms (while the client only has state up to 75ms).

Yep that's exactly right!

And how does that input buffer on the server affect this? If this input buffer is causing inputs to be delayed ...

I have never heard of GSVP, MNDP , or FP-Mux. We just send regular UDP packets to the operating system. Perhaps the Xbox OS is compressing them after that? Or wireshark is misinterpreting our packets?

The ball is 1/6th the mass of the car, but we don't translate mass in the game to any real-world unit of measurement.

Swap is moving players across the field but the cars are still locked to their original position via a 2d constraint, so that's just physics sliding them back to where they should be.

I *think* the accelerate on respawn issue is fixed in next patch, I remember looking in to it a while ago.

will add for next patch

If the stick is perfect, then holding a perfect diagonal would give X and Y values of about 0.707 each. These values are multiplied by Sensitivity. So our math would be:

0.707 * Sensitivity = 1.0

Sensitivity = 1.0 / 0.707

Sensitivity = 1.41 (theoretically)

Yes, very minor. We basically just use the physics engine for resolving intersections. Restitution is mostly disabled (between the car and ball).

Ping for other players are still a multiple of 4 (to save bandwidth). Your own ping is uncompressed.

You are correct, the ends of longer cars have a higher velocity than shorter cars when dodging. However the bulk of the impact force between the ball and the car comes from the extra forces that we add after the collision response is calculated by the physics engine, and these extra forces depend entirely on the relative linear velocity between the car and the ball. Angular velocity does not factor into the extra forces.

You can try disabling Steam controller integration for Rocket League. https://steamcommunity.com/groups/SteamClientBeta/discussions/1/144512942758259979/

It does not spin more freely on workshop maps.

Looks like a little over 450 degrees

Many workshop maps don't set the correct physical material for the ground, so it's lacking the constant downward force that keeps the car planted to the ground. Without that force the car is able to jump higher than it should, which gives it more time to turn in the air before hitting the ground. Workshop maps that use the correct physical material for the ground behave the same as the normal game.

If supersonic and max speed were the same value, it would be very difficult to maintain supersonic. The car would constantly be fluctuating in and out of supersonic if it did anything besides driving in an uninterrupted straight line. The lower supersonic speed is to give some wiggle room to maintain supersonic.

Rocket League does not use variable timesteps.

We now send the rotation as a quaternion using 18 bits per component instead of 16. Implementation learned from https://gafferongames.com/post/snapshot_compression/ "Optimizing Orientation" Here's snippets of the code for deserial...

If that is true, then does that mean the server accepts inputs from some players later than others? That doesn't sound too fair to me. Or does your statement mean, that the client simulates even further ahead to create a bigger buffer for the inputs?

What it means is, if a player is averaging packets arriving anywhere between 100 and 125 ms of latency (25 ms of jitter), they have (ideally) 25ms of input buffer to ensure they always have enough inputs in the buffer to last until they next packet comes in. This keeps the input buffer as small as possible so we aren't adding too much extra delay to processing their inputs.

If another player has very high jitter (packets taking anywhere between 100 and 150 ms), they need a 50ms input buffer to handle the 50ms of possible lull between incoming packets.

Great video as always! I wanted to clarify some things mentioned in the video:

• Input buffer size is not the same for everyone. It tries to grow or shrink depending on network jitter (variance in latency).
• We allow up to 10 frames of input history to be sent on every outgoing packet. We don't send inputs that the server has already confirmed. You were probably only seeing 4 inputs because you had a low ping and the server had already confirmed the older inputs. If you increase your ping, you will see the game sending more inputs per packet.
• The networking options currently don't work because we chose to disable them via the backend while we narrow down server issues stemming from the last update. The networking options will be re-enabled shortly after the next update goes out.
• A fix was just checked in to our dev build a few days ago that coincidentally fixes the scoreboard ping issue too. The issue you are seeing is not the actual ping going...

Hello! Thank you for this investigation. The heavy car issue is an elusive beast and we appreciate any community help in resolving this matter. Connecting to PsyNet with high latency should not have any effect on player input, but I'll try it out on Monday to see what happens. To aid in your investigation, here are some points regarding things mentioned in this post:

• PC has only been using websockets since April 24. Prior to that communication with PsyNet has been through stateless https requests. So unless your issues just started in the last few days, I wouldn't assume websockets are the culprit.

• ConnectionQualitySave just tracks your latency, packet loss, etc to the game servers over multiple matches. This information is used to display a pop-up linking to a support document if a user has recurring connection issues. It is not used to affect your connection settings.

• The PsyNet.ServiceCalls metric is just metrics we record that me...

AI writer here. Great job everyone! https://imgur.com/a/3MZOn