devtrackers.gg → Psyonix_Cone
Psyonix_Cone

Psyonix_Cone



14 Aug

Psyonix pls?

Comment

Originally posted by BlueRajasmyk2

As a developer with experience in game networking, I'd be interested in hearing a more technical explanation of what /u/Psyonix_Cone meant, because I find it hard to believe they invented their own lossy compression algorithm for this.

I think more likely what he meant was "the data is compressed, but also, packets can be lost"

It is lossy compression. Position vector components (float XYZ) get rounded to the nearest integer. Angular and Linear velocity get scaled and rounded. Rotation gets snapped to certain degree angles.

To correct other things I see in this thread: The compression is not for replays, it's for sending the data over the network. Replays are just a recording of the network data. The compression isn't to save money, it's to save client download bandwidth. We want to get as much information as possible to the client without overloading them. The information isn't sent at a "variable bit rate" in the audio/video encoding sense of the phrase. The server creates network packets 60 times a second, but not ever replicated actor will have a chance to write to every outgoing packet. Then the packets suffer from your usual internet jitter (variable latency from A to B). Then we only write to the replay at 30 FPS (to save disk space).

In OP's link, the replay records a snapshot righ...

Read more

27 Jul

Someone PLEASE tell me what is happening in this clip! (In-Game vs Replay Comparison)

Comment

Originally posted by HoraryHellfire2

In the game clip. Your client predicted that the players touched the ball, but server side they did not. When your client predicted wrongly, very soon after the server corrected your client.

In the saved replay clip, the client-side prediction happens again (don't ask me why replays have client-side prediction). However, instead of the replay correcting your client, it doesn't correct your client until the ball begins to move as new information is sent.

/u/Psyonix_Cone, might want to force updates on a still ball in replays? Kind of like what you did with in-game client predicting, but now vice versa for replays.

 

A very, very similar issue was present long ago. What happened was clients in-game predicted the touch, but the server saw there was no touch. So the majority of the clients in the game predicted the touch. Usually except for one player, who's client knows their car didn't touch the ball (as they're the ones w...

Read more

might want to force updates on a still ball in replays

indeed


28 Apr

Octane glitch UPDATE with new evidence! Not server lag!

Comment

Originally posted by [deleted]

Can you give a source them being 64 tick? Because I read on reddit that guy traced the server to 30 tick.

Replays are recorded at roughly 30 tick, then upscaled to 60 tick with artificially filled gaps. Most, if not all, companies record the replays for their game at a lower tickrate than what happens to the server. It's cheaper. CSGO has 64-tick servers, but 32-tick demos.

But I don't have a source, and you didn't link those reddit threads. /u/Psyonix_Cone, are Rocket League game servers 64-tick?

Yes, and server lag is caused by the server.

Okay, you got me there. But your problem isn't a result of server lag.

Client side prediction in RL is poorly made, judged by some people that are game developers and programmers and netcode is poorly made as well.

  1. You don't know those game developers and programmers at all. I k...

Read more

Man this is a bigass thread, I'm sure this comment will get lost. Servers run physics at 120hz, just like clients. They actually "tick" at 60hz, which means on average they run 2 physics frames per tick. This is also true for clients that are running at 60 fps.

Replays are recorded at 30hz. Replay playback tries to fill in the gaps as best it can using a combination of prediction and interpolation. Client replays are not the exact same data that is recorded in server replays. It's a recording of the data that the server live-streamed to the client. This means it doesn't record the really bad stuff from client prediction, but it's also not a perfect copy of the server's data. The server's data arriving on the client suffers from compression, network jitter, and dropped packets, so there is a loss of information. Ideally the replays that clients save would just be a copy of the server's replay, but that would require downloading the replay from the server at the end of the ma...

Read more

18 Apr

"How does physics synchronization and lag compensation work in Rocket League?"

Comment

Originally posted by [deleted]

  • Client runs the simulation based on player input and latest information from server. Whatever you do is reflected instantly on your client so there's no input latency, but the overall state is an estimation.

  • The server runs a simulation on it's own based on the latest inputs from both clients, this is the one true state that can trigger things like goals and boost pickups.

  • The properties for the cars, ball, boosts etc. is communicated back to the clients, which match them against their own estimation.

  • If the state differs, the corrections are applied bit of a transition animation so things kinda rubber band around instead of blinking, which can be unnoticeable with very low latency

  • To compensate for the latency, the client keeps rendering the other players doing whatever they did in the last tick. E.g. accelerating forward.

  • As long as ticks come reliably at a fast pace, there shoul...

Read more

I am not aware of anything on the server that would cause you to turn without having pressed turn recently. If you have a really bad connection the server will zero-out your inputs to limit how far you move while disconnected.


28 Mar

20 Disconnect's a game... Everyone else is fine?

Comment

Does your IP address change from before the disconnect? Next time you play, refresh https://www.whatismyip.org/ before and after disconnect, I'm curious if it's changing.