I remember back in the day ATI Tray Tools also injected itself into processes and caused bans. I don't know what's with AMD and their complete incompetence in matters of software.
What does that have to do with incompetence, though? Incompetence would imply that the feature either didn't work or broke things, which it didn't. It triggered a very specific anti-cheat mechanisms of one specific and relatively new game.
The game still worked as intended, though.
It's not one game. And remember they enabled it on very few multiplayer games, yet all of them have reported issues. CoD just crashes when it detects antilag+, while apex actually handed out tons of bans
"What does that have to do with incompetence, though?"
They've made this same mistake before, didn't learn their lesson, and repeated the same mistake. That's pretty incompetent. Like Cisco-level incompetent.
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.
"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.
> 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.
Two similar bugs over multiple decades is an utterly routine occurrence in software development.
Graphics cards and drivers are a marvel of engineering and maths. They work miracles, and are the product of thousands of specialists along the production chain. It’s hardly a damning indictment that they didn’t place compatibility with the anti cheat engines of competitive multiplayer games at the top of their priority list.
Almost certainly there are quite a few different firmware and software engineers working there now, but I agree, and I recall that one thing AMD and ATI had in common even before the merger was being strong on hardware and weak on software.
Where's the hate for valve's anticheat being buggy and too aggressive and unable to identify benign code from cheating code?
I'd be happy to argue the semantics of the mistakes made by AMD, and I probably could be convinced they fucked up. But the ethics of guilty until proven innocent that comes with anticheat software, are so appalling that I'm angry valve isn't getting roasted for saying "we're not going to do anything until after AMD does.
IMO, if your accusations can "ruin lives" (even if it is just a gaming life) you don't get to make mistakes if you're going to ignore them until it's convenient to.
This isn't unique to anticheat, anti-virus and EDR aren't immune to detect a suspicious behavior that many malwares engage in as a false-positive, and flagged a normal process doing something unusual as malicious by mistake.
