Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ex Valve dev on CS:GO’s codebase

twitter.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: Ex Valve dev on CS:GO’s codebase

#111

Post by smileybarry »

silicon2401 wrote: post #62
meibo wrote: post #23

Earlier quoted context omitted.

To be even remotely safe from this, you need to use a kernel driver, which is invasive and widely seen as unacceptable - at the moment anyhow. See Riot and Valorant from earlier this year. There was a lot of outcry and the response from the devs was basically "we don't give a damn". Other games, for example, scan window titles or signature for a variety of debuggers/hacking tools like IDA and x64dbg. There's many tec…

Is there a way to check what games/platforms install kernel drivers? I recently installed trackmania and after jumping through what felt like 10 hoops just to play the game (log in to epic, download epic games store, log into ubisoft, etc etc), I realized I have idea how much stuff is being installed on my pc after all these steps.

Most recent games install their anticheats from their own folder, so if you open something like Process Explorer and look at the loaded drivers list, you could tell by the path.

However, AFAIK nearly all games with anti-cheat (save for Valorant of course) load their anti-cheat when the game starts and unload it when the game closes. You can run something like Process Explorer/Monitor before running the game, then notice what drivers & services it's loading.

Re: Ex Valve dev on CS:GO’s codebase

#112

Post by chongli »

echlebek wrote: post #81
Jugurtha wrote: post #4

One of the best, and first, things we did when starting our machine learning platform was to design it using a plugin architecture. There's a lot of scar tissue and horrible experience through our previous ML products we built for enterprise. Namely, it was extremely hard to onboard new developers to work on the product. They had to understand the whole thing in order to contribute. Changing something was also hard,…

This is an implementation of the "ports & adapters" or "hexagonal architecture" pattern. Seems like you may have independently discovered it. :) https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa...

It’s also just a specific case of the more general idea of writing libraries and common APIs instead of monolithic applications. This can be seen in the Unix philosophy with standard IO and pipelines.

Re: Ex Valve dev on CS:GO’s codebase

#113

Post by smileybarry »

anonymousab wrote: post #42
laurentdc wrote: post #11

I still don't get why they can't make a basic anticheat or protect the process memory like most other games (even the Faceit AC client itself for CS:GO!). Is there some explanation like keeping compatibility with very low end PCs? You can get wallhacks in multiplayer by simply using WriteProcessMemory calls. [0] [0] https://github.com/Snaacky/Diamond/blob/master/diamond.py

Presumably, server sdmins, mods or players can votekick players who they think are cheating. If a player is cheating such that they are indistinguishable from another good player, then that's kind of mission accomplished and doesn't really matter if they stay. This general philosophy has been around in all CS games and has worked well IMO. Just gotta find an applicably well maintained server to play on first.

That only takes care of ragehackers (e.g.: blatant aimlocks) and throws very good players under the bus. Most cheaters toggle their cheats, make sure to not do too well, allow someone else to finish the kill (to not appear in the killcam), etc. It's common enough that most cheats out there have a strong disclaimer of "don't be obvious".

Re: Ex Valve dev on CS:GO’s codebase

#114

Post by smileybarry »

laurentdc wrote: post #27
exoque wrote: post #24

Earlier quoted context omitted.

Won't this hack be caught by VAC? And if not, what is VAC actually doing?

It's not caught by VAC. I changed the glow colour (which probably changed the signature), tested it a few months ago on local server and then played some Valve deathmatch on official servers, account is still good. I'd expect the game to at least throw me out of the server if I tamper with what objects should light up, but nope.

If you changed a known hack you might be scheduled for banning at a later banwave instead. Otherwise cheat developers would just make changes and test what gets them banned.

Re: Ex Valve dev on CS:GO’s codebase

#115

Post by nawgz »

XCSme wrote: post #104
eertami wrote: post #35

Earlier quoted context omitted.

>Valve has no excuse, they make crazy amounts of money, they can fund the development of a new engine from scratch easily. They just choose not to. It admittedly gets a bit more difficult when these hacks and quirks are part of what create the unique feel of your game engine. People have played CS at such high levels for so long that switching engine at all is likely going to introduce some difference in feeling, eve…

> It admittedly gets a bit more difficult when these hacks and quirks are part of what create the unique feel of your game engine Oh, the memories! I was so upset when bunny-hoping was mostly removed when CS:GO was released. I played the HNS (hide-n-seek) mode in CS 1.6 more than the normal game-mode. Most of the HNS mechanics were based on game bugs: bunny-hopping, long-jump (sync mouse movement with player movement…

CSGO still has bhops, longjumps, surfing, and jumpbug; I think jumpbug is harder and I'm not sure about edgebug. Was there really such reliance on jumpbug and edgebug in this game mode?

Re: Ex Valve dev on CS:GO’s codebase

#116

Post by XCSme »

tw102 wrote: post #109
XCSme wrote: post #102

Offtopic: I was checking his bio: "Entrepreneur at Binomial, open source dev. Previously SpaceX, Valve, and Ensemble Studios/Microsoft. SIBO survivor. From New Jersey. Opinions my own. He/him." At the end wrote "He/him". Anyone knows what does this mean and what is this trend? Is this to clearly state your gender and how you identify yourself?

there are plenty of people who, e.g. - don't want to show their face on the internet - people whose appearance is ambiguously gendered - people who are not the gender that people assume from pictures of them - people who used to be addressed as a different gender and, when addressed, want to be referred to correctly. for instance, i'll never show my face on the internet, but i like it better when someone says "_he_ w…

Thanks for the explanation, it makes sense!

Although this seems nice, I don't think it actually solves the bigger problem (if there actually is such a problem in the first place). You can not wear a label everywhere you go with your preferred pronoun, this would lead to people stuffing their bios with all their genes, preferences and believes (eg. gender, race, religion, political view, etc.).

The actual problems are:

1) People assuming someone's gender.

2) People getting upset when their gender is incorrectly assumed.

3) Not having a well established social protocol to ask someone their gender without one or both of the parties feeling uncomfortable.

4) In my opinion it further emphasizes that gender is something really important, that should be mentioned immediately as it changes the way you look at someone. I think the correct progressive way of thinking is to disregard gender entirely and assume everyone is "genderless" unless it actually matters. Does it really matter if he is a he or a she? Does it matter that much if a stranger on the internet uses the wrong pronoun?

5) Same issue applies for all other previously mentioned characteristics of an individual (race, religion, political views, etc.).

Re: Ex Valve dev on CS:GO’s codebase

#117

Post by Jugurtha »

yreg wrote: post #101
corytheboyd wrote: post #79

Earlier quoted context omitted.

Fully support those who want to use these tools, just don’t forget they are not a crutch. You can still write hard to work with code and know exactly who the SME is. That doesn’t make the code less difficult to work with, less error prone to change. That can only be solved by design and enforced through discipline.

Absolutely. This only helps to nerf the knowledge loss from teammates leaving the project, nothing more.

And nerf knowledge loss from ourselves after a couple of [weeks/months/years].

Re: Ex Valve dev on CS:GO’s codebase

#118

Post by Jugurtha »

The_Colonel wrote: post #75
leetcrew wrote: post #72

Earlier quoted context omitted.

you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface. otherwise, and especially if the plugin devs have access to the core code, they will say stuff like "hey, I see you have a very convenient function in the core, can you expose it for my plugin?". once you open the door to this, your encapsulation suffers death by a thousand cuts. you can end up with a de facto m…

> you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface. Of which the end result will be that the desired functionality will be somehow hacked within the plugin or will not be available at all. Problem with such plugin based architecture is that it relies on a well designed interface. Person which designs the interface needs to have very good idea of how that interf…

>Of which the end result will be that the desired functionality will be somehow hacked within the plugin or will not be available at all.

It depends on the scope of the functionality. For example, right now, authentication and token generation are in the core, but it's okay right now because authentication spans across the whole product.

We eventually will extract it out, so we could use it as a component in another product, but for now, it's not inappropriate to leave it in the core.

>When business requirements change, you then have the difficult dilemma - just insist on "no", introduce a minimal hack, redesign interfaces to support the use case in a clean way (possibly big task) etc.

Some days are easier than others.

>Yes, worst outcome of all. In reality, plugin based architecture is no silver bullet. It can be very counter productive, especially when you're figuring out what you actually want to build, as you build it.

That's why I talked with the scope and abstraction level. We tend to make the few and loose assumptions that get us a lot of leg work done automatically. We won't make further assumptions just for 1% advantage. And if we do, there's a fallback. For example, we say that a plugin has a certain structure and expects say an icon file. If it's not there, it's not there, the plugin is loaded but just not displayed. We issue a warning, in case it was by mistake, but the application does not break.

Very few and loose "specs" that one can go through quickly and easily without looking at a checklist or something.

Again, it's not a panacea. The underlying assumption in what I wrote is that neither I nor the reader believe in silver bullets. It's not a dichotomy. The question of course is not whether a plugin architecture solves all problems and makes bacon or solves nothing, and I may have been unclear in my message. My point was that it's one of the most useful things we have done because it reduced the amount of work we had to do. We still wake up and build product.

Re: Ex Valve dev on CS:GO’s codebase

#119

Post by Jugurtha »

leetcrew wrote: post #78
The_Colonel wrote: post #75

Earlier quoted context omitted.

> you need to have someone who is very comfortable saying "no" to be in charge of maintaining the interface. Of which the end result will be that the desired functionality will be somehow hacked within the plugin or will not be available at all. Problem with such plugin based architecture is that it relies on a well designed interface. Person which designs the interface needs to have very good idea of how that interf…

> When business requirements change, you then have the difficult dilemma - just insist on "no", introduce a minimal hack, redesign interfaces to support the use case in a clean way (possibly big task) etc. one thing I will add is that every new feature does not have to be a plugin just because you have a plugin interface. "implement it directly in the core" is a perfectly valid fourth choice. some things just aren't…

>one thing I will add is that every new feature does not have to be a plugin just because you have a plugin interface. "implement it directly in the core" is a perfectly valid fourth choice. some things just aren't suited to a plugin implementation.

Yes. Quoting my answer to your reply's parent:

""" It depends on the scope of the functionality. For example, right now, authentication and token generation are in the core, but it's okay right now because authentication spans across the whole product.

We eventually will extract it out, so we could use it as a component in another product, but for now, it's not inappropriate to leave it in the core. """

Re: Ex Valve dev on CS:GO’s codebase

#120

Post by rng_civ »

jrockway wrote: post #99
flohofwoe wrote: post #41

Earlier quoted context omitted.

The Source engine hails from the 90s, testing hadn't been invented back then ;) But on a more serious note, writing automated tests for game engines involves a lot more than just "duh, unit tests" (especially when testability wasn't a concern in the original design).

I am surprised that game engines aren't set up to test simple scenarios programmatically. I play a lot of Overwatch and the bugs / patch notes about fixing those bugs amaze me every time; they tell me a lot about how the software is designed and tested. There was one bug where a character has a deployable ability that doubles the damage and healing of all projectiles that pass through it. One day, the patch notes rea…

The only game I'm aware of with an extensive automated testing infrastructure is Minecraft:

https://youtu.be/vXaWOJTCYNg?t=993

Post reply on HN