Nibodhika

I don't, this has never been a possibility for me in the last 4/5 houses I've lived unless I specifically bought a 3m long USB cable. I'm sure plenty of people do, but I don't think it's 99%.

I have mixed feelings about this. On the one hand I like the idea of AA because if the controller dies mid-session you can just swap them and keep playing, on the other this is easily solvable by having a dock like the 8BitDo Ultimate, which makes it so that the controller is always fully charged when you pick it up, so the only advantage that the AA had disappears, and it's even more comfortable to have the controller always charged than having to get up in the middle of the play session to find new batteries. And the Steam controller has a charging puck, so it should never have the issue where AA are better. So my feeling that it would be better is not justified.

The other supposed advantage is longevity, since all batteries eventually die off, if it's an external battery you just buy new ones and are done. Being internal makes it more of a hassle. But Valve has been very open with the repaiedness of their devices, so I expect this to not be a big issue, as long as the batteries are still being manufactured by the time the one in the controller dies off (which should take a lot more time to happen than regular AA).

The short answer is because I'm lazy. I might lose 30 min during the system setup instead of 20, and now I have a system that I don't have to worry about until the hardware gives up.

Arch is a rolling release distro, which means it's unstable, which doesn't mean what you think, instead it means that you can update your system indefinitely without worrying about "versions". For example, if you had Ubuntu 20.04 installed on your server, in may you had to update it to 24.04, and that's something that can cause issues. And in 2029 you'll need to go through that again. Arch is just constant updates without having that worry. Which means no library is safe from updates, ergo unstable.

Also the AUR is huge, and I'm a lazy ass who likes to just be able to install stuff without having to add PPAs or installing stuff by hand.

Also there's the whole customize the system, I use a very particular set of programs that just won't come pre installed anywhere, so any system that comes with their own stuff will leave me in a system with double the amount of programs for most stuff which is just wasteful.

Finally there's the wiki, while the vast majority of what's there serves you in other systems, if you're running Arch it's wonderful, it even lists the packages you need to install to solve specific errors.

A couple of things, first no, I don't feel the latency of a Bluetooth controller. But also the steam controller will be able to pair to multiple devices, in one of the interviews one of the engineers said "The steam Machine has its own antena, but each controller comes with its own puck, we expect the common use case to be to plug that to your PC and use the steam controller in both devices"

Yes, it would be very difficult for the owners @outlook to create 10k accounts.

If an enemy is outside your vision, but makes a noise, you cannot give that information to the client without revealing the enemies position.

Sure you can, for starters audio is a lot less reliable to pinpoint location than video, so the server can randomize the position somewhat and still be accurate enough. Not to mention that sound bounces off walls, so it's not exactly wrong to give the point of origin of a sound as a wall nearby the origin or destination, and an even more advanced system could use ray tracing to calculate sound path and give you a fully accurate sound point that doesn't reveal the source exactly.

If a player kicks a bucket across the map, the bucket flying through your screen makes it trivially easy to calculate the point of origin - and you know something happened there / player was there.

But again if you're not sending the bucket position until it's in FoV that doesn't matter at all.

We'd be really really lucky if server side fog of war would be the kill-it-all solution to cheating.

It's not the end all, but it does take are of whole categories of hacks.

I'll reply to the server FoV there. Skill based matchmaking is hard to solve, but I think most games who have enough players to worry about anti-cheat to this level should have some level of skill based matchmaking in place, in my head that's way more important than anti-cheat because even with cheaters the games are fun for everyone, and cheaters end up bubbling up into their own group.

And then Microsoft or Sony would bulk buy 10k steam machines to use in their server rooms. They can't sell at a loss because the hardware is not locked, otherwise people could just buy these and use them for whatever and Valve wouldn't see a cent from those machines. At the very least they need to be sold at a neutral price point, but more than likely they're looking to get some profit over them.

Well, yes, but, let me counter with this:

You can completely remove wall hacks from the equation by doing some FoV calculations in the server, this completely solves that issue, there's no client side hack that would be able to show you enemies behind the wall because the server isn't sending them to you.

And to the other point, if the 20ms kill is bad but the 14ms kill is good, there's space to argue that the cheater is worse than the players so you don't really need anti-cheat so solve that, Skill based matchmaking takes care of that for you, he would eventually be placed with people who are better than him even with hacks.

Sure, server side anti-cheat can't capture everything, but neither can client side, but server side anti-cheat can make it so that your client side cheats are pointless, because they can't make you better than everyone, you have to remain averageish, and if you're consistently above average skill based matchmaking will bump you up and up until you're going to lose even with cheats or you will be playing against other people with the same cheats as you.

I don't think they mentioned ecological benefits, but accelerating and braking is a lot more inefficient than driving a constant speed. And since there's no way you'll be able to sustain any speed higher than 30 in most city areas in Ireland it makes sense.

Let's do some math here, they said:

More cheaters using Linux than legit users (...) .01% of all players base

Let's do a quick math. The maximum peak users for Rust was 259,646 concurrent users according to https://steamcharts.com/app/252490 . Let's assume 60% (more than half) of all the .01% users were cheaters, congratulations, you got rid of all those 16 cheaters... I haven't played much Rust, but I'm fairly confident that there's a bit more than 16 cheaters there.

And that's without getting into the whole client side anti-cheat doesn't work.

Your head is in the right place, but your example is very wrong. First, unless it's a very slow projectile that's not how bullets work in games, second movement takes place in the server, to do so in the client is nuts. Client sends inputs, sever moves, gives back player location, client adapts. While waiting for a reply the client simulates the movement expected, but sometimes the server doesn't receive the package and so tells you you haven't actually moved and you teleport back.

What's usually not done is calculate vision cone, instead the server gives you everyone's position and you calculate whether you can see them on your GPU. Which is why if you can get access to the GPU pipeline you can tweak it so it shows you objects through walls. If you move the LoS calculation to the server you completely eliminate wallhacks, however that is very expensive to do (although ray tracing GPUs might provide a good approach in the future)