I would definitely recommend explicit code-based solutions to potential exploits. Although we'd all like to believe in a nice free egalitarian society to receive our code, that's just not how the real world is. When writing any public online software (game or otherwise) you've always got to operate under the assumption that every client that joins is a potential hacker/spammer/cheater/racist. Everything should be completely tamper-proofed and tested for security as thoroughly as possible, and all possible logic attacks (not to mention "real" security issues such as buffer overflows and such) should be suppressed before they can occur. Sometimes even accepted features that can be used perfectly legitimately by players have to be sacrificed for this, though -- take the MIRV-grenade reduction in TFC, for example.
On the other hand, there is such a thing as overdoing it. The worst example of this that I've seen is "non-passive security" systems (some built into mods, others added as "wrapper" DLLs) -- systems that immediately ban people for "suspicious activity", code that automatically blocks, punishes, and/or writes canned responses to keywords like "lag" and "hack" or even some swear words. These always seem to end up activating inappropriately more often than they actually block legitimate troublemaking. Regarding that CS exploit, are you sure that it's actually an exploit and that they didn't just add some kind of tracking *after* they realized that someone could just reconnect to avoid the round timer? I've never been a fan of Counter-Strike, so I'm not familiar with the behaviour of the mod before that time. As to the myg0ts, you could try hardcoded IP bans (or even the whole damn subnet if they're really that persistant and annoying), and a server admin education campaign of some sort. ------------------------------------------------- Ryan "Professional Victim" Desgroseilliers Administrator, TFMapped (http://tf.valve-erc.com/) ----- Original Message ----- From: "Pat Magnan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 17, 2002 1:29 PM Subject: [hlcoders] How do you guys deal with players harrasing other players? > I know this sounds OT for a coding forum, bear with me for a sec. > > We've been publically released for a very very short time, and most of > our servers seem to have been targetted by a group of annoying little > players that call themselves 'myg0t'. http://www.myg0t.com if you want > to see more about these annoying children. > > I'm sure we're not the first mod to experience this, but if we were as > big as CS or something, they would get lost in all the noise. > > Do you guys recommend implementing things in your codebase to cause > them havoc back? Has anyone learned little things to watch out for in > terms of exploits they commonly use that we can all benefit from? > > I know we learned a couple things the hard way, and we now have to put > things like 'spam control' on our voice comm, so that these idiots > can't overflow all the players on their team and disconnect them. That > was possibly just poor design on our part, we forgot that all gamers > aren't nice, well adjusted people, who just want to have fun. :( > > I know some of this is the server admin's realm, but if we can give > them tools to make it easier, then we will. > > Can we formally request a 'format annoying little punks hard drive' > engine command from valve? :P > > Also, does anyone know if that exploit that allowed players in the CS > beta 4 days to constantly reconnect (avoiding the round timer when > dead) still works (they're using it on us, so it seems to work in an > unmodified SDK)? Am I missing a fix that I should be using when clients > reconnect, that breaks that exploit? How does it work anyway.. etc. > > I guess we're just feeling a little harrassed by these guys, and if all > of us can benefit from sharing 'tips' to avoid letting any one player > be annoying, so much the better. > > Cheers, > > > > Pat 'sluggo' Magnan > Tour of Duty mod > http://www.tourofdutymod.com > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
