Re: [hlcoders] Removing items at level start
Fixed. It was not freeing the memory correctly. Dave - Original Message - From: Dave R. Meyers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 03, 2002 1:08 PM Subject: Re: [hlcoders] Removing items at level start The exact error I get is : ED_Alloc: no free edicts and it seems to happen around the time the items should be respawning? On a side note, what does decals must hit mod_brush mean? Dave ___ 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
Re: [hlcoders] access keyword
It looks to be just a check to make sure the file exists. The thing is though that it allows for up to ten more files of the same name + X. crossfire.dat crossfire1.dat crossfire2.dat then it is supposed to figure out how many files there are, then generate a random number, and pick one. I don't have multiple files yet, so I can't test that it works?? Dave ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] EfxAPI
Hello, I've used the Efx API to create a temp entity. I draw a sprite. My question is quiteshort : How can I change the color of the rendered sprite (like SPR_Set does). Is it possible ?? I've tried numerous functions (R_LookupColor...) but it did nothing :( (I repost with a bigger font...) CortexHL Albator coder mapperwww.hlalbator.fr.stICQ : 71548738 - Original Message - From: Neale Roberts To: [EMAIL PROTECTED] Sent: Thursday, January 03, 2002 8:52 PM Subject: Re: [hlcoders] EfxAPI What an enormous font you use :) - Original Message - From: Cortex To: coders Sent: Thursday, January 03, 2002 7:28 PM Subject: [hlcoders] EfxAPI Hello, I've used the Efx API to create a temp entity. I draw a sprite. My question is quiteshort : How can I change the color of the rendered sprite (like SPR_Set does). Is it possible ?? I've tried numerous functions (R_LookupColor...) but it did nothing :( CortexHL Albator coder mapperwww.hlalbator.fr.stICQ : 71548738
[hlcoders] HLTV Spectator
Hi, I've just merged my mod with the full sdk2.2 and I'm trying to get it to work with HLTV. I start a server, run HTLV ont he same PC, connect 127.0.0.1. The proxy shows up as a spectator on the server and everything seems fine. I then browse the game from another PC and see the 'eyeball' icon entry and the real game entry. I join the 'eyeball' game. My games starts to load, 'spooling demo' etc, it get's to the loading sky console message (just before rendering starts I think) then just crashes to the desktop. I ran the joining client under the debugger and it's crashing in HL.exe. Any ideas on helping diagnose the problem? What does the proxy send to the client that could crash it? Or what is my cl_dll missing that could crash HL? I've made sure the FL_PROXY flag is preserved on the server and checked general spectator/overview code for merge problems but I haven't touched any of that code, as you'd expect. I've attached my hltv.log below, doesn't say much unfortunately. I've tried it with an overview test bmp in overviews dir and with it nothing in there. Thanks, Mark. WON initialized. Challenging 127.0.0.1:27015 (1/3). Get challenge (HASHEDCDKEY) Connecting to 127.0.0.1:27015 (1/3). Connection accepted by 127.0.0.1:27015 BUILD 1769 SERVER (0 CRC) Server # 1 Added 444 resources. Received baseline with 12 entities. Activated director module. Spectator connected (192.0.0.1:27005). Client 192.0.0.1:27005 timed out. Spectator disconnected (192.0.0.1:27005) WON shutdown. Demo module shutdown. Multicast module shutdown. Disconnected. Server module shutdown. World module shutdown. Master module shutdown. Proxy module shutdown. Network shut down. __ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] HLTV Spectator
I forget what info_ thingy it looks for, but Opera had the same problem and they wrote a nice little fix for it. Are you using custom maps that might not have this entity in it? Just a thought. Dave - Original Message - From: Mark Gornall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 12:27 AM Subject: [hlcoders] HLTV Spectator Hi, I've just merged my mod with the full sdk2.2 and I'm trying to get it to work with HLTV. I start a server, run HTLV ont he same PC, connect 127.0.0.1. The proxy shows up as a spectator on the server and everything seems fine. I then browse the game from another PC and see the 'eyeball' icon entry and the real game entry. I join the 'eyeball' game. My games starts to load, 'spooling demo' etc, it get's to the loading sky console message (just before rendering starts I think) then just crashes to the desktop. I ran the joining client under the debugger and it's crashing in HL.exe. Any ideas on helping diagnose the problem? What does the proxy send to the client that could crash it? Or what is my cl_dll missing that could crash HL? I've made sure the FL_PROXY flag is preserved on the server and checked general spectator/overview code for merge problems but I haven't touched any of that code, as you'd expect. I've attached my hltv.log below, doesn't say much unfortunately. I've tried it with an overview test bmp in overviews dir and with it nothing in there. Thanks, Mark. WON initialized. Challenging 127.0.0.1:27015 (1/3). Get challenge (HASHEDCDKEY) Connecting to 127.0.0.1:27015 (1/3). Connection accepted by 127.0.0.1:27015 BUILD 1769 SERVER (0 CRC) Server # 1 Added 444 resources. Received baseline with 12 entities. Activated director module. Spectator connected (192.0.0.1:27005). Client 192.0.0.1:27005 timed out. Spectator disconnected (192.0.0.1:27005) WON shutdown. Demo module shutdown. Multicast module shutdown. Disconnected. Server module shutdown. World module shutdown. Master module shutdown. Proxy module shutdown. Network shut down. __ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. ___ 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
RE: [hlcoders] HLTV Spectator
Hi, I found the util on The Opera webby. I'm sure I downloaded it when David Flor first wrote it but seem to have lost it. I'll give it a try tonight and see if it fixes my problem. Thanks, Mark. __ This mail has been scanned for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Removing items at level start
On a side note, what does decals must hit mod_brush mean? Dave decals must hit mod_brush means that you are trying to spray a decal on a surface that's not a World BSP brush (perhaps you are trying to spray a decal on a player or other entity). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] EfxAPI
(I repost with a bigger font...) Cortex You might want to consider posting in plain text instead of HTML, that way you don't have to set a font size, and people using non-HTML e-mail applications will be able to read your posts without all the HTML junk. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] access keyword
It looks to be just a check to make sure the file exists. The thing is though that it allows for up to ten more files of the same name + X. crossfire.dat crossfire1.dat crossfire2.dat then it is supposed to figure out how many files there are, then generate a random number, and pick one. I don't have multiple files yet, so I can't test that it works?? Dave If you have 1 file, just make multiple copies of it and change the filename. To count the number of files, the should have something that adds the number to the end of the filename then use access() to see if that file exists. When they get to a number that doesn't exist, they know how many files there are (i.e. in your example crossfire3.dat doesn't exist, which means there are 3 files). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Items.cpp (MyTouch)
And how in pray tell would that be accomplished? Could you lend an example in the SDK for me to haggle over? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Reedbeta Sent: Friday, January 04, 2002 1:26 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Items.cpp (MyTouch) --- omega [EMAIL PROTECTED] wrote: you can still use findentityinsphere. thats what entity-IsPlayer() is for. so you can distinguish between them. Of course you can, but the method I used seems cleaner, faster, and less error-prone to me. BTW I forgot to mention in my previous email that if you want to affect only the players in a 600-unit radius, you need to add a distance check just before you do the traceline, so you don't waste time doing tracelines for players that are too far away. ---Reedbeta __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.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
Re: [hlcoders] Items.cpp (MyTouch)
Of course you can, but the method I used seems cleaner, faster, and less
error-prone to me. BTW I forgot to mention in my previous email that if
you want to affect only the players in a 600-unit radius, you need to
add a distance check just before you do the traceline, so you don't
waste time doing tracelines for players that are too far away.
---Reedbeta
And how in pray tell would that be accomplished? Could you lend an
example in the SDK for me to haggle over?
If you are using UTIL_FindEntityByClassname() for player then you can
subtract the origin of the player and the origin of the entity (grenade)
then use the Length() function on that vector to find the distance...
float distance = (pPlayer-pev-origin - pev-origin).Length();
if (distance 600.0) // is this player close enough to be effected?
{
// do UTIL_Traceline() to see if they are behind a wall or not...
UTIL_Traceline(...stuff...)
if (tr.flFraction = 1.0) // did traceline complete?
{
// do damage here
}
}
Jeffrey botman Broome
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Items.cpp (MyTouch)
if( vector.Length( ) 600 ) - Varlock - Original Message - From: Yacketta, Ronald [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 1:36 PM Subject: RE: [hlcoders] Items.cpp (MyTouch) And how in pray tell would that be accomplished? Could you lend an example in the SDK for me to haggle over? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Reedbeta Sent: Friday, January 04, 2002 1:26 AM To: [EMAIL PROTECTED] Subject: Re: [hlcoders] Items.cpp (MyTouch) --- omega [EMAIL PROTECTED] wrote: you can still use findentityinsphere. thats what entity-IsPlayer() is for. so you can distinguish between them. Of course you can, but the method I used seems cleaner, faster, and less error-prone to me. BTW I forgot to mention in my previous email that if you want to affect only the players in a 600-unit radius, you need to add a distance check just before you do the traceline, so you don't waste time doing tracelines for players that are too far away. ---Reedbeta __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ogc required to play??
Wallhack cheats wouldn't be possible if stuff on the other side of the wall isnt sent to the client :P -av Reedbeta wrote: Perhaps we should just make the clients dumb terminals. The server does the rendering, streams the video to the client, and the client's input commands get sent back to the server. This would eliminate all known forms of cheating./sarcasm Seriously, as long as there is game logic of any kind operating on the client side, it is vulnerable to cheats and hacks. Even if the only thing to be done client-side was rendering and input collection, wallhack type cheats would still be possible. --- leming [EMAIL PROTECTED] wrote: The idea is out there.. if anything is to be done, the main part of it has to be done server side. Anyone can break their client side software, but to break something server-side, the admin of the server (or account) is the one responsible, and if he isnt responsible, well, there are laws (in the US atleast) that will put those people off of computers for a good duration of time. But as far as any implimentation goes towards any methods used to stop things like ogc, it is my personal belief that Valve themselves are going to have to take a serious approach to stopping cheating. PunkBuster guys had a good idea, but there again was external client side software. Any decent programmer can not only program, but rip apart programs. Its all a big vicious loop of making a program work the way you want it to. And if the anti-cheat is all server side, the players cant do a whole lot in the way of breaking it, unless there are flaws in the server-side patch. -- leming At 23:04 1/3/2002 +, you wrote: reply below.. - Original Message - From: Nicolai Haehnle [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 03, 2002 3:31 PM Subject: Re: [hlcoders] ogc required to play?? Am Mittwoch, 2. Januar 2002 22:56 schrieben Sie: Then the hook only need to listen on the network and it will get the key... It won't do any good to get hold of the public key. That's the beauty of the public key system. You need both the private key and the public key to decrypt the message. The private key is never sent over the network. Actually, that's no problem. Remember you're man in the middle? There's a tool (ettercap) that can automatically log all SSH sessions on a switched (!) networked from an intruding PC. All that's required is that you're listening in the initial phase, so that you can replace the keys used. This is obviously the case for a cheater proxy. Now you're all forgetting another problem with the HL protocol. Protocols like ssh, https, etc... are stream-oriented which is crucial for the common advanced encryption algorithms. Because the internal state of the algorithm changes with the data, it cannot be applied to a packet-oriented protocol like HL's - packets can be dropped or delivered out of order, which would obviously mess up the algorithm. Game Programming Gems has a nice little section on network protocols and gives a few ideas of how to deal with the out of order problem, as well as getting around all but the most hardcore of packet sniffers by adding some random data to the end of your network packets tomake it a varible lenght and other handy stuff. ___ 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 __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - [DRP]Avatar-X SillyZone Homepage: www.thesillyzone.com SillyZone Forums: forum.thesillyzone.com My Homepage: www.cyberwyre.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ogc required to play??
Am Samstag, 5. Januar 2002 02:22 schrieben Sie: Wallhack cheats wouldn't be possible if stuff on the other side of the wall isnt sent to the client :P -av Which would immediately lead to problems if a lagged player walks around corners because entities don't appear immediately. You can see this effect on the TFC map well when you enter the flag room from the lower level of your base, even if your ping isn't too high. Normally, this doesn't happen because the PVS extends a bit around corners, but it looks like this particular place in well has good visblocking ;) cu, Prefect ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ogc required to play??
An idea might be that the half-life game itself (valve guy stuff) would do more of a security check on the mod being loaded. The game is provided the location of the .dll (or .so) to load, so why not do something like a CRC on the mod, compare it do a crc of the actual distributed file by the mod authors, and if it matches, let it load. If there is something in the way like admin mod (or a hack), it wont load the game, or the client will report to the server that there is something in the way of the mod being loaded, and the server can then decide what to do. Of course I myself could make a list of the flaws of this idea, but its just a base of something that could be improved upon. Throw out some suggestions people, I know there are more people than myself that want to see cheating gone, or atleast controlled. -- leming At 02:33 1/5/2002 +0100, you wrote: Am Samstag, 5. Januar 2002 02:22 schrieben Sie: Wallhack cheats wouldn't be possible if stuff on the other side of the wall isnt sent to the client :P -av Which would immediately lead to problems if a lagged player walks around corners because entities don't appear immediately. You can see this effect on the TFC map well when you enter the flag room from the lower level of your base, even if your ping isn't too high. Normally, this doesn't happen because the PVS extends a bit around corners, but it looks like this particular place in well has good visblocking ;) cu, Prefect ___ 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
Re: [hlcoders] Items.cpp (MyTouch)
If you are using UTIL_FindEntityByClassname() for player Or if you're using any other method of locating players. The point is, subtract the grenade's origin from the player's origin and take the length of the resulting vector. __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ogc required to play??
Wallhack cheats wouldn't be possible if stuff on the other side of the wall isnt sent to the client :P Which is exactly why we should do all rendering on the server and then just stream the video to the clients :P (yeah yeah, I know, bad joke) --Reedbeta __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ogc required to play??
Executable code downloaded and run is a spawning pool for viruses, but good idea nonetheless. Maybe have my original idea of a checksum being used on the client dll that was loaded by the game client-side, and compare it to a checksum that the server the player is playing on had. If the checksums dont match, the client is intervening with the loading of the proper mod, and/or the server has things messed up. Also an idea would be to not only stop at checking the client dll being loaded, but to also do a check on the memory that the mod was loaded into. This would prevent client-side hacks from changing around the executable memory to do what they wanted to do. A little extra temporary overhead, but the process can be run low-profile on the system, thus consuming less processing power, leaving more for the game rendering etc etc (I wouldn't want to suggest something that would leave the kids losing 3 fps to check if they are cheating...) -- leming At 13:49 1/5/2002 +1100, you wrote: hopefully Valve have some better ideas ;) The client should be treated as untrusted and the server trusted (if the server is untrusted also then you are screwed :) So you just need to implement some checking on the client. My idea would be to have executable code be downloaded from the server to the client to be run (ala PB), this make a hackers life hard. However, it can lead to vunerabilities in the client if the server does go bad :( Other models can use Valve (WON,Sierra,etc) as a trusted third party for the codelets, but it means more infrastructure for them... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ogc required to play??
I do agree that downloadable code produces a virus potential, but it depends on how you structure the process. You did download the hlds binary right, how do you know that it didn't have a virus? Through careful use of digital signatures you should be able to secure this process (to a reasonable degree). I haven't though about the overheads of this process, but they can't be too demanding. The problem with a checksum (say MD5 or SHA) is that its a static check. Break it and the client is hacked forever. What cheat detection needs is dynamics. It needs to be agile with respect to the time frame of the hacks so they can be countered. And this means it needs to be able to change hourly... Right now server ops are in a bad place. For ever new hack or update to an existing hack they need to grab a new version of an anti-hack tool. This places a great burden on server ops. The writers of the anti-hack tools also have a hard time keeping up. What is need is some way of removing the overhead from the server ops. In my model Valve (or some subsiduary...) produces anti-hack codelets. These codelets are distributed to servers when they start up (and on map change) (with digital signatures of course :). A server only needs a selection of codelets, a random set, so that the odds of picking up any hack are good over a few days. Then the server sends the codelet to the client and waits for a response (within tight timelimits). The client can verify the codelet with a CA to make sure its not a virus and then execute it. The output can then be returned to the server and checked against expected values. When a new hack comes out, propagate a new codelet to detect it. When one is overcome remove it from the pool of possible codelets. You can use various methods to make the codelets themselves dynamic. This model is similar (if not the same?) as PB's, and while I do not know the details of how PB works I have chatted with tony about some aspects of it... Now, this scheme can be broken by hacked servers. It can't corrupt (put viruses) on clients but it can allow cheating clients without others knowing. The scheme also has some vunerabilities that you need to code around (like hyjacking DNS for eg) BUT it will provide a low overhead, dynamic (agile) anti-cheat tool :) leming wrote: Executable code downloaded and run is a spawning pool for viruses, but good idea nonetheless. Maybe have my original idea of a checksum being used on the client dll that was loaded by the game client-side, and compare it to a checksum that the server the player is playing on had. If the checksums dont match, the client is intervening with the loading of the proper mod, and/or the server has things messed up. Also an idea would be to not only stop at checking the client dll being loaded, but to also do a check on the memory that the mod was loaded into. This would prevent client-side hacks from changing around the executable memory to do what they wanted to do. A little extra temporary overhead, but the process can be run low-profile on the system, thus consuming less processing power, leaving more for the game rendering etc etc (I wouldn't want to suggest something that would leave the kids losing 3 fps to check if they are cheating...) -- leming At 13:49 1/5/2002 +1100, you wrote: hopefully Valve have some better ideas ;) The client should be treated as untrusted and the server trusted (if the server is untrusted also then you are screwed :) So you just need to implement some checking on the client. My idea would be to have executable code be downloaded from the server to the client to be run (ala PB), this make a hackers life hard. However, it can lead to vunerabilities in the client if the server does go bad :( Other models can use Valve (WON,Sierra,etc) as a trusted third party for the codelets, but it means more infrastructure for them... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Alfred Reynolds [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] ogc required to play??
I like this idea, however I can this this problem with this approch. You are still relieing on code executed on a client which could be hacked, and u need a function to call that code, what is to stop a hacked client from downloading the code, not running it and just returning the data that that codelet is designed to return? The problem is, when ever ya use a DLL based loading system you have to leave the function table open for the DLL to link to the existing code, that to me is the major secuirty hole in the whole MOD system. This is used to full effect with the OGC hack, which sets up a new function call table (this is going of a quick over look, however this is how I would do it) to point to it's adjusted routines. Now, to get around this you could come up with some kind of striping down system to remove the function table to another file or location, but then you have to inculde this program with any SDKs that are released so the MOD authors can make the compatible code, which then means the hackers can get there hands on it. In fact, based on this, you can not trust any code in any imported DLLs because they maybe hacked, so this stuff has to be handled in the orignal exe file (in this case HL.exe which, if I'm not mistaken handles all the dll loading/unloading), however, that too can still be hacked. I dont pretend to know the solution to the problem, but these are some of the problems that I myself can see which I dont recall having been brought up before. (I hope the english and ideas make sense, I'm a bit tired and my thinking is eratict at the best of times) - Original Message - From: alfred [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 5:32 AM Subject: Re: [hlcoders] ogc required to play?? I do agree that downloadable code produces a virus potential, but it depends on how you structure the process. You did download the hlds binary right, how do you know that it didn't have a virus? Through careful use of digital signatures you should be able to secure this process (to a reasonable degree). I haven't though about the overheads of this process, but they can't be too demanding. The problem with a checksum (say MD5 or SHA) is that its a static check. Break it and the client is hacked forever. What cheat detection needs is dynamics. It needs to be agile with respect to the time frame of the hacks so they can be countered. And this means it needs to be able to change hourly... Right now server ops are in a bad place. For ever new hack or update to an existing hack they need to grab a new version of an anti-hack tool. This places a great burden on server ops. The writers of the anti-hack tools also have a hard time keeping up. What is need is some way of removing the overhead from the server ops. In my model Valve (or some subsiduary...) produces anti-hack codelets. These codelets are distributed to servers when they start up (and on map change) (with digital signatures of course :). A server only needs a selection of codelets, a random set, so that the odds of picking up any hack are good over a few days. Then the server sends the codelet to the client and waits for a response (within tight timelimits). The client can verify the codelet with a CA to make sure its not a virus and then execute it. The output can then be returned to the server and checked against expected values. When a new hack comes out, propagate a new codelet to detect it. When one is overcome remove it from the pool of possible codelets. You can use various methods to make the codelets themselves dynamic. This model is similar (if not the same?) as PB's, and while I do not know the details of how PB works I have chatted with tony about some aspects of it... Now, this scheme can be broken by hacked servers. It can't corrupt (put viruses) on clients but it can allow cheating clients without others knowing. The scheme also has some vunerabilities that you need to code around (like hyjacking DNS for eg) BUT it will provide a low overhead, dynamic (agile) anti-cheat tool :) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
