ec-
What about adding anti wallhack cvar?
Recently I made an anti wallhack function on the server side, in the engine in my fork, which does not send to the client those players that the client should not see.
This feature slightly reduces server performance, but increases client performance and speeds up gameplay since the packets do not contain players who are not visible.
I am ready to make a pull request with this feature, and also this feature does not break compatibility with mods, but makes the game fairer and faster.
And yes, I created a cheat to make an anti-cheat for it.
I am against anti-cheat systems that work on the client and act aggressively, and this "anti-cheat" is completely on the server and does not contain closed parts.
An anti-wallhack fix sounds quite interesting. I expected a such thing to be a gamecode thing, how can we sure it doesn't break any mod (like those which deviate from standard gameplay a lot)?
What does it do about the noises from the hidden players? (It reminds me about this: https://github.com/OpenArena/engine/issues/79) On one hand, one would say that footsteps etc should still be audible; on the other hand maybe they may let open the risk for new wallhacks taking advantage of their data and convert them into visual clues?
PS: Wondering wheter it may be controlled by some cvar or be automatically disabled while loading a map with devmap/devspmap, as looking at maps and bots with r_showtris enabled is a step mappers should do to check their VIS optimization is working properly.
An anti-wallhack fix sounds quite interesting. I expected a such thing to be a gamecode thing, how can we sure it doesn't break any mod (like those which deviate from standard gameplay a lot)?
What does it do about the noises from the hidden players? (It reminds me about this: OpenArena/engine#79) On one hand, one would say that he footsteps etc should still be audible; on the other hand maybe they may let open the risk for new wallhacks taking advantage of their data and convert them into visual clues?
PS: Wondering wheter it may be controlled by some cvar or be automatically disabled while loading a map with devmap/devspmap, as looking at maps and bots with r_showtris enabled is a step mappers should do to check their VIS optimization is working properly.
Since this is server-side, the owner/admin of the server could enable or disable this if it breaks any mod or changes the way the game should be played in that server
What does it do about the noises from the hidden players?
players can't make sounds when they are invisible, but shooting sounds are audible but from the point of impact.
Wondering wheter it may be controlled by some cvar
Yeah, sv_antiwallhack cvar
Since this is server-side, the owner/admin of the server could enable or disable this if it breaks any mod or changes the way the game should be played in that server
Yeah! Players are identified by the ET_PLAYER class
Wondering, does it consider both structural and detail brushes or structural only?
Just for the sake of completeness, as one can see in the second screenshot, a wallhack would still show the whole body or hitbox of characters which should be only partially visible, as being only partially covered by a wall. I don't think one can really do a lot about this server-side (and changes client-side might be overriden by the hacker), and it's a smaller problem... I mention this just for people to be aware that edges could still be giving away your position more than you think.
Wondering, does it consider both structural and detail brushes or structural only?
Just for the sake of completeness, as one can see in the second screenshot, a wallhack would still show the whole body or hitbox of characters which should be only partially visible, as being only partially covered by a wall. I don't think one can really do a lot about this server-side (and changes client-side might be overriden by the hacker), and it's a smaller problem... I mention this just for people to be aware that edges could still be giving away your position more than you think.
because it is a solid model, the server cannot determine which polygons of the model to draw and which not, the server only checks the coordinates and the hitbox
and changes client-side might be overriden by the hacker
a hacker can't turn off the anti-cheat because it's on the server side and the server makes it so that the client doesn't even know about the existence of players behind the wall, and the position is taken directly from the player, not from the camera, so the only way to get new entities is to move forward on the server
and changes client-side might be overriden by the hacker
a hacker can't turn off the anti-cheat because it's on the server side and the server makes it so that the client doesn't even know about the existence of players behind the wall, and the position is taken directly from the player, not from the camera, so the only way to get new entities is to move forward on the server
My fault, I wasn't clear. With the "changes client-side" part I meant something like "even in case we add in the client another level of not drawing partially covered character models, before or after the renderer does its standard job at drawing a wall in front of them (Z buffer, I think?), an hacked client could still ignore that too and draw the entire model again". As in "I guess there is no way to prevent an hacker from completely seeing the first character of the left of your second screenshot (instead of just his right arm as a legit client would), however it's not a big problem. The feature is still very, very cool!"
However, I'm curious to know whether you tested it with both structural and detail brushses, and with uncommon shaders like glass, mirrors, fog...
However, I'm curious to know whether you tested it with both structural and detail brushses, and with uncommon shaders like glass, mirrors, fog...
it's work with all structural and detail brushes but not work on am_lavaarena with boxes because it's non colide models with weapon bot and player clip... and it's transparent shaders and this not wall... if it was autoclip or just caulk, this will worked... sorry for my bad english...
this feature work for all bsp solid geometry but "trans" surfaceparm also work. players will be visible via mirrors, fogs etc^^. and this work with network delay
https://github.com/etlegacy/etlegacy/blob/master/src%2Fserver%2Fsv_wallhack.c
If the code is anything like this code then I'm not convinced as it's got plenty of flaws.
If the code is anything like this code then I'm not convinced as it's got plenty of flaws.
No, my code is 30 lines of code
If the code is anything like this code then I'm not convinced as it's got plenty of flaws.
https://github.com/noire-dev/sourcetech/blob/1afb42c81f7a2d46aa856f8fcd674fbc4d91ab10/code/server/sv_snapshot.c#L449C3-L488C4 my code
Just wondering... do you think it may (be easy to/useful to) apply also to other kinds of entities? Like preventing wallhack cheaters know whether a quad damage or a megahealth is available in another room? It's just a random thought I just had, I have no idea whether wallhackers are usually interested into such extra stuff or just into players.
I'm no good at reading C code and I don't know where the "see/don't see" calculations use hardcoded hitbox size or read them from elsewhere (e.g. crouching hitbox is a bit shorter), so how much flexible could this stuff be.
On a side note, do you think the fact that during certain animations, some character models may end up quite outside their intended bounding box, might be a problem? https://www.ra.is/unlagged/faq.html#IJRAMBIHOIJRAHBIM like https://www.ra.is/unlagged/images/bbox7.jpg Like a character jumping laterally from behind a wall might appear like spawing mid-air out of nowhere?
Like a character jumping laterally from behind a wall might appear like spawing mid-air out of nowhere?
it's can changed with hitbox modifier and yeah, this func uses entity hitbox size.
Just wondering... do you think it may (be easy to/useful to) apply also to other kinds of entities?
it's work for items already but disabled by default. sv_ace_wallhack 3 for items and players and 2 for players with accurate hitbox checking and 1 for fast hitbox checking
Did it will work properly with grates (entities placed behind alpha-channel tested surfaces) etc.?
