antiwh

[g0atz]

I have the anti-cham running. It's helped weed out the majority of inexperienced hacks who try. But some are using opengl32.dll,
so we still get a few everyday/night that the MPs have to take care of manually. Very frustrating.

Is there any defense against that type of hack? Does the patch's antiwh function prevent this type of exploit?
And if so, has the lag /blinking issue been fixed with Gamma when turning it on ?

Thanks

[James]

The patch prevents ALL kinds of chams and wallhacks including ghost chams, but no it's not yet optimized to work flawlessly without blinking. You would have to play around with the settings to determine which method works best on your server. We have discussed some options we may consider in a future update if feasible that may prevent wallhacks without blinking, but currently it's only a Proof of Concept.

[g0atz]

Thanks for the reply. What "settings" are you speaking of? There are only 2 (on/off) for the antiwh correct?

[James]

I thought there were 3 different types of antiwh settings that could be used. 1,2,3 or 0 to turn it off. 1-3 just use different detection methods.

[g0atz]

I see, so do any of the 3 choices offer the least occurrence of "blinking" and additional lag? Or is this just a "trial n error" type situation? I think "1" is bone prediction. Out of curiosity, what are the other 2 methods of detection?

[JoTo]

The newest is mode 4 which was introduced in latest release when Im not wrong.

[Midnight1138]

Indeed JoTo. I think setting number 4 work in conjuction with player PING.
Copied from the 2.5 Gamma releasenotes in the downloads section:

New AntiWH mode, with frame throttle based on players ping. You can use it by setting sv_antiwh CVar to 4.
New CVar for all AntiWH modes, sv_antiwhskipping, which skips AntiWH checks for players above given ping. Default is 400.

I haven't tried it yet, so don't know about blinking/skipping.

[Razo[R]apiD]

Mode number 4 sets all players visible at the beggining of the frame, and then only hides players to people that has ping below sv_antiwhskipping. (That doesn't count for spectators, I assumed that player with high ping will already have small advantage of using wallhack because he'll hardly be able to play and will die fast). Also frame throttle means that we don't repeat visibility checks each frame, but get players ping, take server fps from sv_fps CVar and see how many server frames he's behind a current server state. Then we set a time stamp of last visibility check, and delta time (based on his ping/time delay) after which a new visibilty check should be performed.

But we only reset time stamp and increase delta when player is visible, so it won't hide him for longer than needed. So if player is invisible at current frame, it won't set up any timer, but will re-check him at next frame and so on like we normally do in other modes.

This means that we can do visibility checks each 2-3 or 4 frames, and it'll still be accurate as other methods because of players ping that causes a time delay between current server state and what client actualy sees. (his state)

It should also reduce blinking when player is moving behind a fence or walls with thin gaps, because his visibility timer won't expire during movement and he will be visible.

The only drawback is that player will be visible behind a wall for a short time, until his visibility timer expires and new visibility check will be performed.

Mode 4 also introduces Monkey-on-back issue, because of the fact we re-show every entity at the beggining of the frame and later we don't check for non-player models to hide them and this will be fixed in RC3

Mode 4 won't also highly reduce blink issue when player moves around corners but it's being worked on, though it's not an easy task as we have to predict future frames and player movements which aren't so repeatable.

[g0atz]

I now have the antiwh set to "4" and it is disabling the ability to use the opengl.dll with the "blinking" & additional lag seeming acceptable.
Good!
But the Anti-Cham has stopped working. I can use any typical cham skin hack successfully.
I turned off the Anti-Cham hoping that using the antiwh alone would stop both with no success either as the cham skin hack can still be used.

Can these 2 not be used in conjunction with one another?
Does anyone have these 2 running together successfully?

[James]

The 2 shouldn't interfere with each other. Infact, I'm not even sure how it's possible. If you're referring to the anticham pk3, that just uses hud settings to draw a texture onto a clients screen, where as the patch uses traces to show\hide players. The 2 have absolutely nothing in common.

The anti cham (pk3) will NOT stop ogl hacks and certain clienthook hacks (unless those hacks load a custom texture & you have that texture in the huddraw pk3), otherwise it won't work. The patch isn't dependent on any variables whether it's ghost chams, pk3, openGL, rootkits, clienthooks, hybrids anything that renders a client visually through a wall WILL be stopped.

try doing an sv_restart or a vid_restart to see if that helps.