The 64hz fetish

[Captain Hollywood]

I really cannot figure out why the entire fps scene, during the century, has always tried to push the top server hz possible, even Battlefield 4 Pro Mode ran at 144hz ( 144 !!!! ), meanwhile Valve and part of cs community still have the 64hz fetish. Faceit, Esea, everyone will push the server hz. If you try to have an argumentation with Valve it will simply reply " 64hz IS WAY ENOUGH". Sure... that's why they pushed the sub-tick insted to invest on a 128hz architecture wich could have resolve the 90% of the csgo network problems natively, without adding nothing to the base code.

[Ben Lubar]

So now we essentially have infinite ticks per second for shooting, moving, crouching, jumping, etc.

What is wrong?

[Captain Hollywood]

Originally posted by Ben Lubar:

So now we essentially have infinite ticks per second for shooting, moving, crouching, jumping, etc. What is wrong?

The wrong part is: you have infinite ticks on your CLIENT. But the SERVER records the data at 64hz, always.

[Ben Lubar]

Originally posted by ↪-C0D4-Frezptz↨t↨clfhf®:

Originally posted by Ben Lubar:

So now we essentially have infinite ticks per second for shooting, moving, crouching, jumping, etc. What is wrong?

The wrong part is: you have infinite ticks on your CLIENT. But the SERVER records the data at 64hz, always.

I don't know how CS2 works, but if I were to implement a system like this in Alien Swarm, I would record at what point between ticks an action was taken and send that as part of the usercmd message. Then, on the server, when rewinding for lag compensation, I would rewind to a position that is not just a certain number of ticks back but between ticks as well.

Since the other players don't compute where your shots go (the server tells them), the two parties that matter (the acting player and the server) are the ones that are running at essentially infinite ticks.

[Captain Hollywood]

Originally posted by Ben Lubar:

Originally posted by ↪-C0D4-Frezptz↨t↨clfhf®:

The wrong part is: you have infinite ticks on your CLIENT. But the SERVER records the data at 64hz, always.

I don't know how CS2 works, but if I were to implement a system like this in Alien Swarm, I would record at what point between ticks an action was taken and send that as part of the usercmd message. Then, on the server, when rewinding for lag compensation, I would rewind to a position that is not just a certain number of ticks back but between ticks as well.

Since the other players don't compute where your shots go (the server tells them), the two parties that matter (the acting player and the server) are the ones that are running at essentially infinite ticks.

That's the problem bro. You need to introduce, like Valve did, tons of checks, tons of calculation, tons of math, which will always be less accurate than a native infrastructure which runs at the double speed.

edit: Alien Swarm has 128hz servers.

[Ben Lubar]

Originally posted by ↪-C0D4-Frezptz↨t↨clfhf®:

Originally posted by Ben Lubar:

I don't know how CS2 works, but if I were to implement a system like this in Alien Swarm, I would record at what point between ticks an action was taken and send that as part of the usercmd message. Then, on the server, when rewinding for lag compensation, I would rewind to a position that is not just a certain number of ticks back but between ticks as well.

Since the other players don't compute where your shots go (the server tells them), the two parties that matter (the acting player and the server) are the ones that are running at essentially infinite ticks.

That's the problem bro. You need to introduce, like Valve did, tons of checks, tons of calculation, tons of math, which will always be less accurate than a native infrastructure which runs at the double speed.

edit: Alien Swarm has 128hz servers.

No, it has 60 hertz servers. You can run it at a higher tick rate, but the code isn't 100% compatible with that.

For examples from Half-Life 2:

https://www.youtube.com/watch?v=cyYk9hUDdj8
https://www.youtube.com/watch?v=UMI43G5vtzg