[2020] Octane glitch UPDATE with new evidence! Not server lag!

I created a post few days ago stating there is an issue with how Octane handles after challenges and jumps. It looks and feels identical too the after goal explosion that flips your car unnaturally.

Link here

Most of the comments were that it is server lag and not a glitch.

Since most of us debating whether replays saved in your game are server or client sided, I hope this examples can provide some proof of that.

Example 1

In this example you can see the game as I saw it recorded with Radeon Live. You can clearly see the unrealistic movement of the car when I pressed absolutely nothing on my keyboard (I play KBM).

In that same example on the server side of the replay the movement is gone!

Example 2

This is the replay I saved in my game. Still the movement is gone, so replays saved are server side and not clientside as many were writing in the comments.

And lastly here is some side by side comparison between what I saw and the replay saved.

Example 3

I hope we can bring this issue to Psyonix so it can be fixed as soon as possible because it is really affecting the competitive games with one of the most popular cars in the game. Please leave a comment saying I did something wrong so I can finally can get to the bottom of this. Does it happen with other cars? I didn't find a problem with Dominus, maybe other cars have it too.

External link →

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.

You don't know those game developers and programmers at all. I know a friend who writes code. He's technically a programmer, but it doesn't make anything he says about writing code valid compared to a game developer who has had a decade of experience on working in online game.

Not only that, you don't know if they are actually proper game developers or programmers. Have you seen their credentials, achievements, and experience? No.

What I'm really dying to know is how the netcode is bad. Specifically. Go into full detail. And not an answer of "It's just bad because rubberband hits happen" or "It's not working as intended".

Just like PSyonix screwed the walls and physics in Hot Wheels update.

An accidental event, and has nothing to do with lag/netcode.

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 match. Hopefully one day we'll be able to do that, or maybe even something better.

Just glancing at the linked gifs - looks like the behavior when a high-latency client mis-predicts the out come of a collision. Due to latency the client just simply didn't have all the information he needed to make a correct prediction. This is always especially bad on kickoffs where the outcome is pretty unpredictable in general, and made worse by players drastically changing their input moments before impact. I'm curious what the latency is in "Example 1", just counting in my head it looks like 200-300 ms.

Recent Rocket League Posts

Rocket League’s Festival of Football Celebrates Football + RL’s Ninth Birthday

Rocket League's Festival of Football Celebrates Football + RL's Ninth Birthday!

Changes to Rocket League’s Competitive Rank System for Better Matches

Changes to Rocket League's Competitive Rank System for Better Matches