[ImPostingOnHN]

Unless either tool was actually a cheat, the mistake in both cases was made by the anti-cheat software: a false positive.

Users should be free to play without cheating and not worry that the a anti-cheat will falsely think they are.

"but wait!" one may protest, "the tool is similar to a cheat if they detect using [technique X]!"

Well, I'm not forcing them to use [technique X], and they aren't entitled to exclusively use it, if it returns false positives. Sounds like they need to think of better techniques. And if they can't, and it turns out they don't know how to solve the problem without hurting innocent people, they aren't entitled to exist, either.

[lightedman]

"Unless either tool was actually a cheat, the mistake in both cases was made by the anti-cheat software: a false positive."

No, they should know injecting/hooking into the engine .DLL would trigger this from VAC. It happened to them before. It is well known in the exploit scene you don't go directly-jacking into things, you always proxy or you're going to be found in extremely short order.

AMD has no reason to be doing this. Let the game engine handle timing and latency. Stick to your hardware and driver stack and focus on making those top-class instead of what they are now.

[ImPostingOnHN]

> they should know injecting/hooking into the engine .DLL would trigger this from VAC.

More importantly, Valve should have known that triggering based on only this would cause false positives, and picked a better thing to trigger on, and/or acquired better confirmation that the tool was a cheat, before banning.

> AMD has no reason to be doing this

Maybe, maybe not, but that doesn't justify Valve VAC banning people for cheating who aren't actually cheating.