[CS 1.6 and CS:CZ] Lag issue in any multiplayer game

[tequin17]

@kisak-valve @mikela-valve

Animation lag ( firing, jumping etc.) appears in CS 1.6 and CS:CZ multiplayer game (Online and LAN). Gameplay isn't smooth as other GoldSrc games.

When I set cl_lw to "0", the lag disaapears but i heard this command isn't a legal command in multiplayer servers.

This maybe a netcode (client and server rate values) problem. But the rate values are same in all GoldSrc games :/

I am sure this is a "client-server" issue because other GoldSrc games don't have this problem.This happens only in CS 1.6 and CS:CZ multiplayer server.

Note: I tested in vanilla games (without any mods, cfgs etc.). Also, i tried everything (formatting pc, scanning virus, tested compatibility modes, running as admin, updating drivers etc.).

[metita]

Remove @alfred-valve as he is not working with Valve anymore.

[tequin17]

Remove @alfred-valve as he is not working with Valve anymore.

okay

[SamVanheer]

Can you provide some videos to show this behavior?

[tequin17]

Can you provide some videos to show this behavior?

I have a gameplay video but it is quite difficult to understand in videos. I recommend you compare (between CS 1.6+CS:CZ and other GoldSrc games) yourself.

Also, i am used half-life dedicated server tool for testing LAN server.

Anyway, i provide a gameplay video: ( please watch 720p at fullscreen)

https://www.youtube.com/watch?v=3z3Cy4Ciexo

[tequin17]

It is hard to explain problem but i can say it looks like a "screen lag". Lag appears clearer in jumpings especially.

[SamVanheer]

I ran a test using this config:

alias toggle_lw_off "cl_lw 0; alias toggle_lw toggle_lw_on; say lw off"
alias toggle_lw_on "cl_lw 1; alias toggle_lw toggle_lw_off; say lw on"
alias toggle_lw toggle_lw_on
bind del toggle_lw

And fakelag 100 to simulate ping.

What you're seeing is the weapon prediction code trying to play the animations locally when you issue the commands. When you turn off cl_lw the server issues the animation changes so it'll be in sync with any server-only events.

This is just how prediction works. It isn't perfect and especially given how CS's crosshair is affected by shots fired it might not be 100% the same with it turned on when compared to it turned off.

I think part of what makes it look weird is that the method CBasePlayerWeapon::KickBack is only implemented on the server side, so weapon prediction won't adjust the punch angle the same way. While the animation plays back immediately, the punch angle is only adjusted when the server has run your command and sent back the adjusted values.

Standard HL weapons code does adjust punch angle on the client side, but CS does not use this approach.

That can't really be fixed because GoldSource's prediction code is too primitive to fully simulate what the server does.

Maybe you could hack it up to adjust the client's punch angle but the code relies on the random number generator from the engine, so when the server's version comes in it'll be different. That would be less of a problem if the code were to use the shared random seed but then the results could change from what people have come to expect.

I would suggest making an attempt to implement the Kickback method on the client to see if that improves prediction behavior, but i doubt it will work since it's hard to get right.

[tequin17]

I ran a test using this config:

alias toggle_lw_off "cl_lw 0; alias toggle_lw toggle_lw_on; say lw off"
alias toggle_lw_on "cl_lw 1; alias toggle_lw toggle_lw_off; say lw on"
alias toggle_lw toggle_lw_on
bind del toggle_lw

And fakelag 100 to simulate ping.

What you're seeing is the weapon prediction code trying to play the animations locally when you issue the commands. When you turn off cl_lw the server issues the animation changes so it'll be in sync with any server-only events.

This is just how prediction works. It isn't perfect and especially given how CS's crosshair is affected by shots fired it might not be 100% the same with it turned on when compared to it turned off.

I think part of what makes it look weird is that the method CBasePlayerWeapon::KickBack is only implemented on the server side, so weapon prediction won't adjust the punch angle the same way. While the animation plays back immediately, the punch angle is only adjusted when the server has run your command and sent back the adjusted values.

Standard HL weapons code does adjust punch angle on the client side, but CS does not use this approach.

That can't really be fixed because GoldSource's prediction code is too primitive to fully simulate what the server does.

Maybe you could hack it up to adjust the client's punch angle but the code relies on the random number generator from the engine, so when the server's version comes in it'll be different. That would be less of a problem if the code were to use the shared random seed but then the results could change from what people have come to expect.

I would suggest making an attempt to implement the Kickback method on the client to see if that improves prediction behavior, but i doubt it will work since it's hard to get right.

Thanks for testing and explaining.

I found this update note from 27/03/2013 and 01/04/2013: "Improved firing behavior in Counter-Strike, Counter-Strike:Condition Zero and Half-Life Deathmatch, it is no longer dependant on client or server frame rate. This change needs both your client and server updates to see the improvements. "

Does this have an effect? Can it be related to this?

also i discovered, when i use these client and server rate values, lag is significantly reduced:

rate "20000" cl_cmdrate "105" cl_updaterate "100" cl_cmdbackup "2"

sv_minrate 0 sv_maxrate 20000 sv_lan_rate 20000 sv_minupdaterate 30 sv_maxupdaterate 60

so, these rate values are legal?

Which one should I prefer? these rate values or default rate values?

[djdallmann]

I was always curious about what that update meant, doesn't depend on frame rate....

[SamVanheer]

82 covers the issue with not predicting punch angle on the client.

See also #1128, which covers the CS specific recoil issue.