Valve also implemented this on CS:GO back in 2015 [0], and enabled by default in competitive servers, so I would consider it absolutely tenable (FACEIT, the platform used by competitive variants, had their own hand-rolled SMAC implementation, before using the 1st party solution, albei,t that solution was buggy). Why Valve didn't port this over to CS2, I will never know.
I don't know if I'd agree with the adage about gamers wanting full control. A subset of gamers, absolutely.
But this excludes the entire console population. This arguably excludes most Steam Deck customers, who picked it because Valve made the Linux experience seamless, so they don't have to pay attention to the details. This excludes many of the PC gamers I know, that do not care beyond whether their computer is capable of playing the games they want to. They won't even reformat their Windows to remove OEM bloat.
I'd like to make some points more explicit about my philosophy.
1. Yes, everything has a maintenance cost. Some choices have less. For instance, electing to choose Todoist instead of org-mode for my todo list means I no longer have to worry about syncing, merge conflicts, or whether the mobile app I've chosen fully conforms to the spec (well, whatever attempt at creating a spec existed at the time).
Of course, I am paying a very literal cost for convenience, and offloading maintenance to the Todoist engineers.
2. Emacs is a cool piece of software, and I am glad others have figured out how to leverage it, in such a way they have a configuration for life. I spent a lot of time marvelling over the set up that Protesilaos had for his writing [0]. It just wasn't for me.
3. For Emacs, if I want to use it like I wanted to, I have a couple of options. Install a package like Doom Emacs, which gives me most of what I want, with a whole lot of cruft I don't. And I have to keep that up-to-date, and worry about random community plugins breaking. Or figure out what set of plugins (after first picking a package manager) to incorporate. Or figure out the Elisp to do it myself. And my writing config would differ from my software engineering config.
No shade on the people who want to do this, but I just... don't? I can use Zed, or VSCode, and I'm 90% of the way there. Install (or configure) the Evil mode equivalent, and I'm happy.
4. One of the smartest engineers I worked with couldn't touch type until about 20 years into his career. The idea that everyone is ricing everything they do, is unrealistic.
Less about the capabilities of LLM software, but more about my willingness to spend time to deploy them, debug them, etc.
I don't want to spend time on dealing with change. Hence why I'd rather purchase tools, where I pay for the developer to a) prepare for any maintenance, and b) will perform the maintenance needed.
(Of course, the maintainability of software with current generation LLMs depends a lot on how well your architecture them. I've got pure vibe coded slop, that can be very difficult to wrangle.)
I've absolutely engaged in making personal software [0] thanks to the age of LLMs.
But to be honest, my time using Emacs didn't teach me to "build personal software". My Emacs set up was extremely brittle, and it was a nightmare when I tried to use it across Windows & macOS. My university project was written using an unholy combination of org-mode & some workflow to create a beautiful LaTeX file, and I couldn't tell you how to recompile it (if I were to try, I'd probably get an LLM to literally translate it to LaTeX).
I want my life to have as little maintenance as possible, and making my own software for everything isn't always compatible with that.
"VAC" is a catch-all term for all of Valve's anti-cheating mechanisms.
The primary one is a standard user-mode software module, that does traditional scanning.
The AI mechanism you're referring to is these days referred to as "VAC Live" (previously, VACNet). The primary game it is deployed on is Counter-Strike 2. From what we understand, it is a very game-dependent stack, so it is not universally deploy-able.
One of my recent thoughts is that Claude Code has become the most successful agent partially because it is more of a black box than previous implementations of the agent pattern: the actual code changes aren't shoved in your face like Cursor (used to be), they are hidden away. You focus more on the result rather than the code building up that result, and so you get into the "just one more feature" mindset a lot more, because you're never concerned that the code you're building is sloppy.
Anecdata here, but the last times I tried to use VISA/MasterCard in a shopping mall meant to serve people from all over the world, it just did not work. UPI was flawless, though.
(And then as pointed out, anyone smaller straight up doesn’t support anything outside of UPI.)
Worth noting that part of the packet size appears to be due to animation data, which they’ve begun the process of transitioning to a more efficient system. [0]
With that being said: totally agree on the netcode.
CS2 is 64 tick under the hood, with interpolation between the ticks. In the beta, server operators could modify the tick rate by patching the server binary, but when that revealed inconsistencies (which was meant to be avoided with the "subtick" system), they hard coded the client side tick rate to 64 [0].
[0]: https://www.reddit.com/r/GlobalOffensive/comments/35zwwy/opt...