kuberoot

I don't think OOP's nature makes them necessary, so much so as it enables them and popular programming principles encourage them. I think they're a good thing, especially if there's a way around them in case you can't get the public interface changed and it doesn't work for you, especially for performance reasons, but that should be done with care.

Funny story, when modding Unity games using external modloaders you're writing C# code that references the game's assemblies. And with modding you often need to access something that the developers made private/protected/internal. Now, you can use reflection for that, but a different trick you can use is to publicize the game's assemblies for referencing in your code, and add an attribute to your assembly that tells the runtime to just... Let you ignore the access checks. And then you can just access everything as public.

If it was a single question, that does sound lame, my other thought was that those "online polling tools" might not be viable because you can't put internal company communications into them... But if it's stuff like food choices or something, then that might also not be a problem.

That said, my point still stands - what you describe does sound like what I'm saying. If you make a sheet with a dedicated field to put the answer into, it should be possible to reliably automate pulling out answers from all the files with excel-level knowledge, and without any additional sites or servers, just spreadsheet editing software and email.

Am I getting it correctly that the excel sheet was basically a form to fill in, with fields and labels, but as a spreadsheet? If so, that sounds pretty clever to me - there're many better ways to do this, but if everybody working there has excel anyways, that's a fast and easy way to get the data in a unified and automatable format without any extra infrastructure.

Unless something changed, players who don't own DLC can't play as the DLC characters. I believe they can interact with all the rest of the content normally, just locked to the vanilla character selection (which is still broad and fun enough, and further expandable with mods).

You literally used the word "should" in your previous comment 😉

dont call children twinks, otters, or femboys.

You know, I never thought about how old Link and Zelda are in the games. Never really had a need, of course, but in some games it's made obvious (literally switching between child link and adult link), I'm not sure if it's explicitly stated for wind waker but just look at him... But then, in BotW there's implications of past romance, and this being the last Zelda game I played might have primed me to not think of Link as a kid.

Ah, sorry, I confused you for the original commenter. The first sentence is a bit nonsensical, it is a bit rude and snarky, but I meant it as a joke, since I had the wrong impression the person having issues with flatpak steam is asking about issues with flatpak steam.

I don't have a reference, but I've been seeing random individuals asking for help and finally saying they fixed their issue by switching away from flatpak, so... You, I guess? Your.problem might be a perfect example of one of the many problems that keep popping up, that seem to only happen on the flatpak version.

I think you're wrong about one thing - it's not about compute cost, but about complexity of accounting for latency. You could check if the player can see the enemy they're claiming to have shot, but you really need to check if they feasibly could've seen the enemy on their computer at the time they sent the packet, and with them also having outdated information about where the enemy was.

The issue gets more complex the more complex the game logic is. Throw physics simulation into the mix and the server and clients can quickly diverge from small differences.

Ultimately, compensating for lag is convoluted, can still cause visible desync for clients (see people complaining about seeing their shots connect in CS2 without doing damage), and opens up potential issues with fake lag.

More casual games will often simply trust the client, since it's better for somebody to, say, fly around on an object that's not there for other players, than for a laggy player to be spazzing out and rubberbanding on their screen, unable to control their character.

I suppose the thing I'm worried about is more general Linux SteamVR support than the streaming itself... But duh, the headset can run games on Linux standalone, so they've gotta have SteamVR working well. The only question is, am I behind on the news, or have they been holding back the updates internally?

I do believe they called out that the steam machine is designed to work with the frame, right? I'd have expected to see Linux SteamVR updates leasing up to this, to get it fully fixed up and tested ahead of time, though I might also have missed something...

Both java and go seem excessively complex at runtime for fundamental system utilities, featuring garbage collection. Rust, on the other hand, keeps the complexity in the compiler and source, keeping the runtime code simpler. And of course it's doing that while trying to make it easier to manage memory and harder to make mistakes, without forcing extra runtime logic on you.