On 10/11/05, Whisper <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Here is a short list of things that should be part of a server by default > Anti-cheat software that is pro-active, i.e. Speed Cheats and No-Recoil > should be easy to detect and prevent if built into the game engine from the > very beginning and not as an after thought. eg. How there os no check on a > player moving from spawn to the opposition spawn on a regular map within 5 > seconds of the round starting makes you scratch you head, or people who > adjust their cross-hair back to center in under 10ms for each and every > shot, really should not be that difficult to code for, surely?
That depends. What else in the gameworld can create a player vector besides player movement? How should this be limited? Should energy be dropped from the world? In this case, what happens with player damage? What about now hacking this system in reverse if there are energy penalties? there is a maximum forward speed.......... (fill in the rest youself :) > A real pure server option that is difficult to compromise and easy to fix > if designed with the assumption that whatever you do it is going to get > cracked in some method. Not necessarily. Register a DEP protected module specifically for handling a client security handshake. The limitation now is still in either local code security (the actual exe or dll files) or in IP communications (which can be easily locally intercepted). The solution being the module must include a known-endpoint, must ensure it's not being watched or intercepted locally (still an issue with routers) and must encrypt it's communications as a minimum. RSVP+SSL+DEP is a good start for technology choices that are available NOW. > Anti-Cheat software that works, period!! This is no-where-near as easy as you think. See my other mail on virtual player hacks. With hack cam development taking seemingly forever, it may be time to start building this ourselves. If you know anyone with experience in inference engines that might be interested, contact me. This kind of project is too big to do on my own. A great many rule editors and rule designers will also be required. If HackCam's claims are anything to be really listened too, they have a database set containing roughly 700mb of data. If these are inference rules accross a few hundred variables, you're still looking at hundreds of thousands of rules. > Server watcher that actually watches the server and will correctly reboot > the server when it crashes as well as produces useful server statistics, > uptime, player count, stay time, unique ID's, rejoins, team changes, map > changes and map times, cpu usage, bytes/second/player IN/OUT, total > bytes/second, fps, memory per player, total memory load. As I'm sure you're aware, there are things that can do this independantly, but not amalgamated. I'm game for producing something, but it would only be worthwhile if the team are aiming suitably high, such as generic game support (there are ways of inferring alot about most games out there right now, from many places). > Player stats that are not mixed in with the day to day server logs. see stats server plugins as opposed to just the daemons. > Logging that does not dump everything into one file. Linear logs are preferable for certain styles of logging system. In particular the CS logs are very easily parsable. > Player Actions in one > log, chat in one log, rcon usage in another, errors & other stuff in > another, etc etc. But, you can parse this from one file.... Logs are best read by computers and "presented" to humans, not the other way around. > With options to allow it to be dumped to one file if you > wish, but have the other options available. A suitable system would simply use a server plugin to manage data flow. The option to immediately lift all this data off of the game server to somewhere else (even if it's another process on the local box) is essential for reasonable server load and thus game performance. > Proper Multi-CPU, multiple server process support on the one box so it is > easy to run 6 Server processes of the same game on the one box that has the > CPU resources to do so, without stuff triping over itself in some form or > manner. The issues that many people have with this are more to do with their operating system configuration than the management apps they use, but of course, we should make it easy for the end user if the system is to be comprehensive. > A friendly fire option where the only person who is damaged by friendly > fire is the Team Attacking Offender and not the innocent bystander. Same > skill as required by normal FF servers, absolutely no retard angst caused by > stupid team attacking fucktards. This feature alone would raise the bar in > CS/CSS immensely without the tears. I can see by the colourful language you hold this one close to heart, so I'll be careful. By all means, include this kind of thing. I don't suffer this problem, and I suspect it may be the kind of communities I play around. FF damage is a key aspect of teamplay IMHO. I think that the CS community at large has severely lacked originality with ways of dealing with this problem. Damage changes are not the only things you can do, and to change the nature of FF simply negates it's primary purpose. I'm very suprised that no "sin-bin's" yet exist for CS. You can be creative with methods of entry and exit. This is one such "new" idea. just $0.02. :) _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
