-- [ Picked text/plain from multipart/alternative ] VAC works very well on HL1 mods I have tested it with 7 different accounts and they were all banned within a month after using XYZ,flautz,and asuswall hacks. Vac also caught 3 different types of aimbots. My last test was about a month ago. I went tino my server which was vac secure with an aimbot turned on with one account. And then entered with another account with a wallhack on. Almost one month to the day later both of those accounts were banned.
Vac is working and working well. I just wish they would ban instantly. This would stop 97% of all hacking. -------Original Message------- From: Wayne Date: 04/09/06 17:18:28 To: [email protected] Subject: RE: [hlds] CS1.6 Servers all bound to 1 CPU? I'd go as far as to say not questionable, but utterly pointless having VAC on 1.6. Clearly, IMO, VALVe have dropped VAC updating for 1.6 and with good reason - the game is old. The only place you can have a safe game of 1.6 is at LANs where the machines are provided and you are unable to load anything onto the machines. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Harrison Sent: Monday, 10 April 2006 9:52 AM To: [email protected] Subject: Re: [hlds] CS1.6 Servers all bound to 1 CPU? I wholeheartedly agree with Steve here; we're managing too many servers to make setting processor affinity ourselves a really workable solution. I'd personally rather lose VAC and not have to worry about this issue until a fix is in place. Based on the comments I see around the traps VAC's effectiveness in CS1.6 is questionable anyway so I'd rather the problem not be mine to fix. -- dave ---- Original Message ---- From: "Dustin Tuft" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, April 10, 2006 9:07 AM Subject: Re: [hlds] CS1.6 Servers all bound to 1 CPU? > Well I guess you have a limited imanigation. The first place I would > start is your process where an admin clicks to start a new server or > shut > down a server. I asume that you have an existing structure in place > that > manages this now? so maybe I gave you to much credit, If you have a > structure > in place then the ease of making it a smarter process is an addtion to > your exsiting function on that given server to check the load of all > CPU's > and set affinity, even say not this server go to the next server in > the > list. > I didn't say anything about recoding the schedular for windows, I only > express that I have felt the pian in multi threaded applications that > have critical events dependent on proper timing, and in most cases > your > have to have one threaded process monitor all threads to get anywhere > close to > correct timing, but that again could lead to lag here, lag being the > reality that your waiting for something before you move on..... > > Dustin Tuft > > >> From: "Steven Hartland" <[EMAIL PROTECTED]> >> Reply-To: [email protected] >> To: <[email protected]> >> Subject: Re: [hlds] CS1.6 Servers all bound to 1 CPU? >> Date: Sun, 9 Apr 2006 22:39:07 +0100 >> >> If you know how to statically determine a dynamic process then please >> let us all know as Im sure that would be a great breakthrough in >> computer science. >> >> Your basic solution of round robin would be unworkable as there are >> too many dynamic variants. You may be running your two servers quite >> happily but we are talking about many hundreds of servers across may >> hundreds of varying spec machines running multiple varying games >> that can change at any second triggered by an admins click. >> >> Its no surprise that one of the most difficult tasks in an OS is the >> scheduler >> and as such I dont believe reinventing the wheel to satisfy the >> temporary needs of one game is something we should be wasting >> resources on do you? >> >> Steve >> >> ----- Original Message ----- >> From: "Dustin Tuft" >>> Just as a suggestion, you might try re-evaluating your process. It >>> seems clear that the way your creating your servers does not allow >>> flexable programing to control affinity, since your way out side of >>> what I am sure Valve would consider standard deployment it might be >>> faster for you to build >>> a smarter dynamic process, possibly a program that trackes the >>> diffrent servers and sets affinity based on the current CPU load. >>> Then you could round robin the servers as they start up taking the >>> CPU with the lowest load, you might even think about leaving CPU0 >>> out of the mix so the windows >>> OS doesn't have any complication or get over loaded durning peak >>> game play. >>> >>> I have been running a dual CPU box from the beging of DOD and I have >>> always >>> found that setting the affinity greatly increases the game server's >>> stablity >>> even before they patched the server to set affinity by it's self. >>> >>> CPU's get bussy and when your busses are bussy with I/O a CPU can >>> fall behind and there is nothing to correct that not even a better >>> built timer. if you take in the whole system all the way to client >>> Hard drives over the network, chances are your server CPU spend >>> more time waiting to process data >>> then any thing else. >> >> >> ================================================ >> This e.mail is private and confidential between Multiplay (UK) Ltd. >> and the person or entity to whom it is addressed. In the event of >> misdirection, the recipient is prohibited from using, copying, >> printing or otherwise disseminating it or any information contained >> in it. In the event of misdirection, illegible or incomplete >> transmission >> please telephone (023) 8024 3137 >> or return the E.mail to [EMAIL PROTECTED] >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list >> archives, please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds __________ NOD32 1.1466 (20060331) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
