[GoD-Tony]

Regarding today's update: If you get a chance to test it then let me know how it's working. It should be a lot smoother on large servers. In theory it should be able to handle 64 players at once.

[jacobleiter]

L 10/23/2011 - 13:00:06: [SM] Native "GetClientMins" reported: Client 2 is not i
n game
L 10/23/2011 - 13:00:06: [SM] Displaying call stack trace for plugin "smac\smac_
wallhack.smx":
L 10/23/2011 - 13:00:06: [SM]   [0]  Line 327, D:\srcds\css\cstrike\addons\sourc
emod\scripting\smac_wallhack.sp::OnGameFrame()
L 10/23/2011 - 13:00:06: [SM] Native "GetClientMins" reported: Client 2 is not i
n game
L 10/23/2011 - 13:00:06: [SM] Displaying call stack trace for plugin "smac\smac_
wallhack.smx":
L 10/23/2011 - 13:00:06: [SM]   [0]  Line 327, D:\srcds\css\cstrike\addons\sourc
emod\scripting\smac_wallhack.sp::OnGameFrame()
L 10/23/2011 - 13:00:06: [SM] Native "GetClientMins" reported: Client 2 is not i
n game
L 10/23/2011 - 13:00:06: [SM] Displaying call stack trace for plugin "smac\smac_
wallhack.smx":
L 10/23/2011 - 13:00:06: [SM]   [0]  Line 327, D:\srcds\css\cstrike\addons\sourc
emod\scripting\smac_wallhack.sp::OnGameFrame()
L 10/23/2011 - 13:00:06: [SM] Native "GetClientMins" reported: Client 2 is not i
n game
L 10/23/2011 - 13:00:06: [SM] Displaying call stack trace for plugin "smac\smac_
wallhack.smx":
L 10/23/2011 - 13:00:06: [SM]   [0]  Line 327, D:\srcds\css\cstrike\addons\sourc
emod\scripting\smac_wallhack.sp::OnGameFrame()
L 10/23/2011 - 13:00:06: [SM] Native "GetClientMins" reported: Client 2 is not i

sometimes spam with those error
windows css v67 server
sm 1.4.0-dev Build ID: 3416:7cb415ecd933-dev
17 "SMAC Anti-Wallhack" (0.7.1.0) by GoD-Tony, psychonic, Kigen

may be sourcetv or someclient not alive/not ingame

[GoD-Tony]

Originally Posted by jacobleiter sometimes spam with those error may be sourcetv or someclient not alive/not ingame

Strange I haven't seen this yet. Does it spam infinitely or does it stop after a second? Were there any errors right before the spam started? Are you able to reproduce it?

[jacobleiter]

Originally Posted by GoD-Tony Strange I haven't seen this yet. Does it spam infinitely or does it stop after a second? Were there any errors right before the spam started? Are you able to reproduce it?

not sure if i can reproduce those error, but it looks like error appear immediate after a map change(not every map change, just spam 3 times for me), may be a clue

(.nav file generation with some client disconnect after MapEnd and before MapStart ? but i fail in reproduce errors under that situation, so i dont know lol).

That error not happen for a few hours. if no one else has this problem may just leave it alone.

[kotek]

there is a bug in wh module, if You will turn it off in middle of the round then, Your will see that Your opponents dont have weapons and if You will die, then a person which eyes You see is left heand. Everything back to normal in next round

[GoD-Tony]

Originally Posted by kotek there is a bug in wh module, if You will turn it off in middle of the round then, Your will see that Your opponents dont have weapons and if You will die, then a person which eyes You see is left heand. Everything back to normal in next round

This also brings up another issue that wallhackers will be able to temporarily see weapons through a wall if it's enabled during a round. I'll fix these in the next version, thanks.

[ChocOrange]

GoD-Tony, Thanks for all the work on this plugin.

Ive been doing some heavy testing on the wall-hack module and before I post the results can you explain which points are tested for models. This will help me with some testing and suggestions I've got for the future.

Looking at the code it seems to check 2 rectangles, inner and outer, to see if players are visible or not, but it's hard to tell the exact points which are checked.

How close is this image to the points checked? ie the red dots.

http://**************/photo/my-images/39/wall01j.jpg

Is it more closely related to the model ie near the head or based on the model's position. How are the rectangles decided upon based on the model?

If you could repost the image with where the check points actually are for that player it would be very useful for my testing.

I've found circumstances where players 'disappear' that shouldn't and knowing where player's positions are checked will help me to provide exact details where issues occur.

Cheers.
[IMG]http://forums.alliedmods.net/%3Ca%20href=http://**************/photo/my-images/39/wall01j.jpg/%20target=_blank%3E[IMG]http://img39.**************/img39/3254/wall01j.jpg[/IMG][IMG]http://forums.alliedmods.net/[IMG]http://img39.**************/img39/3254/wall01j.jpg[/IMG][IMG]http://**************/photo/my-images/39/wall01j.jpg[/IMG]

[GoD-Tony]

Originally Posted by ChocOrange Ive been doing some heavy testing on the wall-hack module and before I post the results can you explain which points are tested for models. This will help me with some testing and suggestions I've got for the future.

I'm glad you made this post. I went in to test it with a screenshot to help explain, and then I realized that the points were off. Unfortunately my entire formula is based around the assumption that a player's origin is the exact center, but now I clearly see that it's right by their feet.



5 traces to check for a player's feet...



The rectangles are always rotated to face the player watching, and the weapon point stays with the weapon.

Originally Posted by ChocOrange How close is this image to the points checked? ie the red dots. http://**************/photo/my-images/39/wall01j.jpg

That's what it was supposed to be doing.

Originally Posted by ChocOrange I've found circumstances where players 'disappear' that shouldn't and knowing where player's positions are checked will help me to provide exact details where issues occur.

I can go ahead and fix the points, but if you have any immediate suggestions then let me know.

[ChocOrange]

Some suggestions:

Once a player is spotted, maybe ignore any checks on that player against players that spotted him for, say, 1 second (customisable for testing?). This may help prevent any 'flickering' of players and improve performance, especially on ramps. It's unlikely a wallhacker could use that time to much of an advantage. I'm guessing there will be points on some maps where checking rectangles on each frame will cause a player to flicker and disappear - it's unlikely enough points can be always checked to ensure a player can be seen. Disappearing/flickering players are bad and lead players to have little confidence in the server.

Ramps are probably going to have the most issues where only a tiny gap is peaked and a very limited portion of an enemy will ever be seen, so maybe increase the points checked when players are at different heights or allow server owners to determine number of points to be checked.

As player numbers reduce, use more checking points for models.
In smaller servers allow heavier checking of model positions Maybe allow the number of extra points to be customisable? And / or maybe code it so more points than just the corners to be checked as player numbers reduce?

Maybe more like:

[IMG]http://img153.**************/img153/9165/wall02s.th.jpg[/IMG]


I'll be honest here and say my primary reason I want this is for mixes/scrims where client-side anti-cheats aren't used. However, I do help run and admin one of the most popular UK public servers and totally appreciate the help it gives public admins.

I can see that checking model points will never be perfect unless someone writes and exceptionally efficient hit box detection routine and removes any players that can not be seen from being updated in the netcode (go on HPE/VALVE you know you want to...). However, the more points that can be checked the better.

Maybe allow another toggle so that only players from one team are checked to further reduce the number of checks necessary on each frame. This would be useful on large servers where a wallhacker is suspected on one team.

And finally something strange spotted while testing, on Dust2 for some reason it allows TS to see through the double doors whilst CT can't (using r_drawothermodels 2).

[GoD-Tony]

Originally Posted by ChocOrange Once a player is spotted, maybe ignore any checks on that player against players that spotted him for, say, 1 second (customisable for testing?). This may help prevent any 'flickering' of players and improve performance, especially on ramps.

This is a good idea. It should really help with flickering in double-doors situations. I'll add this in the next version to see how it works.

Originally Posted by ChocOrange Ramps are probably going to have the most issues where only a tiny gap is peaked and a very limited portion of an enemy will ever be seen, so maybe increase the points checked when players are at different heights or allow server owners to determine number of points to be checked.

There are already some changes when players are at different heights, and it basically expands the rectangles so that one point is always visible if a player is peeking. It may need some tweaks though.

Originally Posted by ChocOrange As player numbers reduce, use more checking points for models. In smaller servers allow heavier checking of model positions Maybe allow the number of extra points to be customisable?

As of recent versions it already does this, but in another way. In small servers players will be checked for visibility on every frame, but as the server grows it will start using prediction and only calculate every other frame or more.

Originally Posted by ChocOrange Maybe more like: [IMG]http://img153.**************/img153/9165/wall02s.th.jpg[/IMG]

The engine can only handle running so many traces in one frame that this would overload it. That's not a SourcePawn limitation either. Using just C++ it only brings a 5-10% speed advantage and that's only in the math. We would be better off assuming that we have to stick with 10 points and find the best configuration possible.

Assuming you're talking about a 5v5 situation, the absolute max with that amount of players would be 12 points.

Originally Posted by ChocOrange I'll be honest here and say my primary reason I want this is for mixes/scrims where client-side anti-cheats aren't used.

That's great, because I'd like this module to be working as best as it can.

Originally Posted by ChocOrange Maybe allow another toggle so that only players from one team are checked to further reduce the number of checks necessary on each frame.

This is an interesting idea. If you're running your own clan server, there is no point in processing your own team (assuming no one on your team is cheating).

Originally Posted by ChocOrange And finally something strange spotted while testing, on Dust2 for some reason it allows TS to see through the double doors whilst CT can't (using r_drawothermodels 2).

Interesting because I only tested this map with T's and didn't notice it. I'll have to look into that.