Originally posted by Baker
View Post
Originally posted by Baker
View Post
This is however of no consequence on darkplaces hosted servers that utilize the sv_cullentities_trace 1 feature, which makes wallhacks completely useless and reduces network traffic by up to 11x in outdoor maps as dpdm2, note this feature works even with the sv_protocolname QUAKE feature (which serves up normal quake protocol).
I consider server-side prevention of wallhacks to be a better method of 'cheatfree', especially as it reduces network traffic, note this also means that pak2 hacked player models don't show up until they are directly visible, so content hacks can only change the appearance of something, not whether it is visible when it should not be.
This is damage control.
Originally posted by Baker
View Post
The worst that can happen is an entire player appears when his head bobs out of the water a little bit, no gameplay impact.
This was a known 'issue' with using glquake with vispatched maps on servers that do not have vispatched maps, it's nothing new.
That said, if the client has vispatched maps, they can get a slight advantage by being able to aim at the cave in e1m4 from the wooden platform, simply because they can see it, even if they don't know if anyone is there - but I do not consider this a significant cheat.
Originally posted by Baker
View Post
Originally posted by Baker
View Post
- wallhacks, these can be prevented by the sv_cullentities_trace 1 feature. danger: high.
- aimbots, the most blatant wallhacks can be spotted, the subtle ones ('aiming aids' as they're often called, when they use only a small cone of autoaim, and can be turned on/off voluntarily) are basically impossible to detect. (Note: wallhacks are often part of an aimbot client, particularly for tracking people about to come out of a hallway, tracking them until the right moment to fire a rocket and catch them off-guard as they exit the hallway, but this is prevented as mentioned above) danger: extreme.
- textureless maps, these can actually harm a player's spatial awareness due to the lack of texturing and detail, but improve reflexes slightly. danger: low.
- fullbright players/items, these are universally helpful in dark maps, otherwise insignificant. danger: low - maps should not be dark to begin with.
- powerup respawn timers, these are often just modified sound files with a countdown near the time the item would respawn, they help newbies significantly but offer little benefit to veteran players who are already aware of when powerups will respawn. danger: low among veterans, high among newbies.
- straight shaft, this could almost be considered an upgrade, as the normal shaft is silly, but this poses little danger among veterans. danger: low.
- glowing player models with huge spikes sticking out of them in various directions, this poses less of a threat than a full wallhack but is similar in nature, similarly prevented by sv_cullentities_trace 1. danger: high.
My summary is: aimbots are dangerous, wallhacks are preventable, and everything else is minor.
qsecurity.dll does not prevent wallhacks because of the opengl32.dll wallhacks (some of them commercial).
qsecurity.dll does not prevent aimbots because they can be written as opengl32.dll hacks.
qsecurity.dll does prevent pak2 stuff.
qsecurity.dll can be bypassed.
All you can do on the technical side is try to prevent the newbie cheaters from playing with cheats (the determined cheaters are unstoppable), but this usually comes with consequences for the entire community, such as lack of engine diversity, as illustrated by this very discussion.
As I've said before, cheating is a social problem, not a technical one, ban cheaters for their actions, don't restrict everyone else.
Furthermore there are griefers (determined to ruin the game) and trolls (determined to spam the game with retarded messages, often hate speech), these can not be prevented by technical means, they can only be banned.
Comment