Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: I can see how exploiting lag compensation could allow you to speed up by a factor or two, but the hacks I have seen have been measured in magnitudes. I don't believe lag compensation has any visual (rendering) component to it. It's solely used on the server to determine if my bullets hit anyone at the time I said I fired my gun on my client. There's nothing in lag compensation that would effect where a player appears to be (rendered) on a client. The only thing that would effect where a player appears to be on the client would be client side prediction. Speed hacks aren't exploiting lag compensation or client side prediction. Speed hacks are telling the server that my client is moving at a faster rate than the client side movement code would normally allow (because my client's clock is running faster than the servers). If distance is calculated using velocity * time, and I increase either the velocity or the time, the distance I have moved will increase. This distance is passed as the forwardspeed or sidespeed floats in the UserCmd packet between the client and the server. I think maybe you are trying to over-analyze this a little too much. Perhaps you should download a speedhack, start up a LAN dedicated server with a mod built using the SDK and log the received UserCmd data to a text file. Also log the amount of time elapsed between each tick on the server. -- 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] Speed hack detection, was new SDK version is live
On 6/10/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeff Fearn wrote: I can see how exploiting lag compensation could allow you to speed up by a factor or two, but the hacks I have seen have been measured in magnitudes. I don't believe lag compensation has any visual (rendering) component to it. It's solely used on the server to determine if my bullets hit anyone at the time I said I fired my gun on my client. There's nothing in lag compensation that would effect where a player appears to be (rendered) on a client. The only thing that would effect where a player appears to be on the client would be client side prediction. Speed hacks aren't exploiting lag compensation or client side prediction. Speed hacks are telling the server that my client is moving at a faster rate than the client side movement code would normally allow (because my client's clock is running faster than the servers). If distance is calculated using velocity * time, and I increase either the velocity or the time, the distance I have moved will increase. This distance is passed as the forwardspeed or sidespeed floats in the UserCmd packet between the client and the server. I think maybe you are trying to over-analyze this a little too much. lol have you been talking to my boss? ;) Perhaps you should download a speedhack, start up a LAN dedicated server with a mod built using the SDK and log the received UserCmd data to a text file. Also log the amount of time elapsed between each tick on the server. I wish I had some spare time, I'd definately do this ...I will do it, might have to wait a few weeks to get the time though :( Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
To have a concept of future time you have to synced clocks. The engine does have a svc_time event the server can send, this event is not adequate to compensate for network lag (and does not need to be). You would not be guaranteed the clocks were exactly in sync. That is why (and rightfully so) the calcs use deltas in time rather than absolute time comparisons. I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist. Even low ping players could still speed hack. Some one with a ping of 40 could speed hack and move at twice the speed of everyone else and appear to the server as a player with a ping of 80. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Wednesday, June 08, 2005 1:43 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live Two things, first wouldn't lagged players be sending you older packets/times not future ones? Second, I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist. Jeff ___ 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] Speed hack detection, was new SDK version is live
On 6/8/05, Deadman Standing [EMAIL PROTECTED] wrote: To have a concept of future time you have to synced clocks. The engine does have a svc_time event the server can send, this event is not adequate to compensate for network lag (and does not need to be). You would not be guaranteed the clocks were exactly in sync. That is why (and rightfully so) the calcs use deltas in time rather than absolute time comparisons. I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist. Even low ping players could still speed hack. Some one with a ping of 40 could speed hack and move at twice the speed of everyone else and appear to the server as a player with a ping of 80. Clearly I am missing some fundamental understanding of how the lag compensation works because I don't get how you come to this conclusion from this scenario. Can you recommend a good discussion on lag compensation? Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: Clearly I am missing some fundamental understanding of how the lag compensation works because I don't get how you come to this conclusion from this scenario. Can you recommend a good discussion on lag compensation? Lag compensation basically allows the server to move everyone back in time to the point when I fired my weapon to see if I hit anybody. That's how people can run around behind cover and still get killed by somebody that they just hid from. The multiplayer networking tome does a pretty good job of explaining this... http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html (scroll to the bottom, see the pretty pictures). -- 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] Speed hack detection, was new SDK version is live
On 6/9/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeff Fearn wrote: Clearly I am missing some fundamental understanding of how the lag compensation works because I don't get how you come to this conclusion from this scenario. Can you recommend a good discussion on lag compensation? Lag compensation basically allows the server to move everyone back in time to the point when I fired my weapon to see if I hit anybody. That's how people can run around behind cover and still get killed by somebody that they just hid from. The multiplayer networking tome does a pretty good job of explaining this... http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html (scroll to the bottom, see the pretty pictures). hmmm I suppose what I need is a discussion of the flaws and exploits of such a system, because I still can't get how the server can allow someone to say I did this at tick 4000 and have the server process that at server tick 2000. I can see how exploiting lag compensation could allow you to speed up by a factor or two, but the hacks I have seen have been measured in magnitudes. Let's say a player shoots at a target at client time 10.5. The firing information is packed into a user command and sent to the server. While the packet is on its way through the network, the server continues to simulate the world, and the target might have moved to a different position. The user commands arrives at server time 10.6 and the server wouldn't detect the hit, even though the player has aimed exactly at the target. This error is corrected by the server-side lag compensation According to this it should be time based, if I speed up my comps time I'm sending commands from the games future, how the hell do these get processed when no one else is at that time? How would setting sv_unlag 0 affect a speed hack? Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/9/05, LDuke [EMAIL PROTECTED] wrote: Imagine that the client lags out for 5 seconds, then an update gets through. From the tick before the update to the tick after the update, the client moves 5 seconds * maxspeed. At a max speed of 320, that's 1600 units in less than a tenth of a second. How does the server know if this is a speedhack or a lagging client? You need to construct the entire scenario, else you miss the parts that make no sense ... to me ;) 1: Client joins server at tick 100 2: Client starts playing 3: Client gets lagged at tick 200 4: Server gest tick 200 at tick 205 5: Server back tracks, player moves faster as ticks 200-205 are corrected See how when you are lagged the server recieves your tick from the past, the server should never process ticks from the future. I'm pretty sure that the speed hacks make your client tick faster and thus send ticks from the future, i.e. at server tick 200 client tick 205 is being processed. Somehow it would have to average the speed over a period of time. How far back would you have to check? How much processing time would it take to check that far back? The server defaults to 1 second of lag compensation, so you should only be able to speed a little by fooling lag. Also it should only work in short spurts as you have to catch up for time you missed, which you actually have to miss at some point. I'm still interested in knowing if turning off lag compensation, sv_unlag 0, breaks speed hacks. It probably breaks HPB's ;) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/6/05, Deadman Standing [EMAIL PROTECTED] wrote: It is based on world time, not # of commands. A speed hack is essentially an exploit of the server's lag compensation. Number of commands is irrelevant. A speed hack would still work if you were to only send a packet a second. I think you are wrong, Botman said this earlier: On 6/3/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeff Fearn wrote: Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? Yes, I believe that is correct. The player sends movement commands to the server and the server says H, okay you are moving in this direction, let me calculate your new velocity and location based on where I think you were before and which way you were going before and then I'll send that information back to you. The client doesn't even specify HOW MUCH they moved (i.e. the distance during that update). The client only says I'm moving THIS way now. So now I'm stuck, do I believe Botman or Deadman! Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
Ask someone at Valve :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Fearn Sent: 07 June 2005 08:37 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live On 6/6/05, Deadman Standing [EMAIL PROTECTED] wrote: It is based on world time, not # of commands. A speed hack is essentially an exploit of the server's lag compensation. Number of commands is irrelevant. A speed hack would still work if you were to only send a packet a second. I think you are wrong, Botman said this earlier: On 6/3/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeff Fearn wrote: Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? Yes, I believe that is correct. The player sends movement commands to the server and the server says H, okay you are moving in this direction, let me calculate your new velocity and location based on where I think you were before and which way you were going before and then I'll send that information back to you. The client doesn't even specify HOW MUCH they moved (i.e. the distance during that update). The client only says I'm moving THIS way now. So now I'm stuck, do I believe Botman or Deadman! Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders * This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods Group Limited or its subsidiaries. Please note that e-mail communications may be monitored. The Registered Office of Littlewoods Group Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Group Limited is 5059352. * This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
LOl, it is the same thing. The movement command is based on time, that is why velocity not position is passed. Keep in mind velocity is a measurement of distance over time. If you advance time it thinks you traveled farther. You can look at the old quake code to get a fell how this is done. Also look on the web, there are some open source hacks out there. They basically speed time up for the program. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Tuesday, June 07, 2005 3:37 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live On 6/6/05, Deadman Standing [EMAIL PROTECTED] wrote: It is based on world time, not # of commands. A speed hack is essentially an exploit of the server's lag compensation. Number of commands is irrelevant. A speed hack would still work if you were to only send a packet a second. I think you are wrong, Botman said this earlier: On 6/3/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeff Fearn wrote: Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? Yes, I believe that is correct. The player sends movement commands to the server and the server says H, okay you are moving in this direction, let me calculate your new velocity and location based on where I think you were before and which way you were going before and then I'll send that information back to you. The client doesn't even specify HOW MUCH they moved (i.e. the distance during that update). The client only says I'm moving THIS way now. So now I'm stuck, do I believe Botman or Deadman! Jeff ___ 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] Speed hack detection, was new SDK version is live
On 6/7/05, Deadman Standing [EMAIL PROTECTED] wrote: LOl, it is the same thing. The movement command is based on time, that is why velocity not position is passed. Keep in mind velocity is a measurement of distance over time. If you advance time it thinks you traveled farther. I don't think it passes velocity, what Botman said was that it passes the impulse keys and that the server calculates your velocity from your existing velocity and the effect those impulse keys have on that velocity. Are you saying that the server is ticking along and the client is ticking at say twice as fast and the server processes ticks from the client that the servers knows are in future? It would seem that if the client sends it's game time with it's packets then it really is trivial to stop speed hacks. It becomes very simple to calculate velocity/time and compare that to sv_maxspeed. It also becomes trival to simply ignore any packet from the future. It's also fairly simple to modify that to handle teleporters and such, which aren't used in most mods anyway. It's a little more difficult, but not hugely so, to include the effects of known environmental effects, like explosions and vehicles etc. You can look at the old quake code to get a fell how this is done. Also look on the web, there are some open source hacks out there. They basically speed time up for the program. This is an easy fix, ignore packets from more than a few seconds in the future. This wouldn't completely remove such hacks, but it would certainly limit them significantly. I suppose what I'm trying to find out is why this is hard to fix, I haven't heard any reason I would consider a blocker to significantly reducing the effectiveness of these hacks. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/7/05, McCormack, Chris [EMAIL PROTECTED] wrote: Ask someone at Valve :) Good idea, I hear there is another email list where some of the guys for Valve join in the discussion, I'll go post there ;) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeffrey botman Broome wrote: Use the source Luke... src\game_shared\usercmd.h (see the CUserCmd operator = function) src\game_shared\usercmd.cpp (see the WriteUserCmd ReadUserCmd functions) UserCmd is what's passed from the client to the server when a client moves, jumps, ducks, fires weapon, etc. Any magic that happens will happen in side there. :) Doooh! I hit Send to quick. You'll notice that forwardmove and sidemove are 'floats' so I was wrong. The total amount of movement is passed from the client to the server saying I've moved THIS much during the last tick.. Now it becomes obvious how sending packets with I've moved X amount during the last Y seconds can cause the player to move faster than normal on the server if the client lies about how much the client has moved or how long/short the time interval was. -- 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] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: On 6/7/05, McCormack, Chris [EMAIL PROTECTED] wrote: Ask someone at Valve :) Good idea, I hear there is another email list where some of the guys for Valve join in the discussion, I'll go post there ;) Use the source Luke... src\game_shared\usercmd.h (see the CUserCmd operator = function) src\game_shared\usercmd.cpp (see the WriteUserCmd ReadUserCmd functions) UserCmd is what's passed from the client to the server when a client moves, jumps, ducks, fires weapon, etc. Any magic that happens will happen in side there. :) -- 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] Speed hack detection, was new SDK version is live
On 6/8/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeffrey botman Broome wrote: Use the source Luke... src\game_shared\usercmd.h (see the CUserCmd operator = function) src\game_shared\usercmd.cpp (see the WriteUserCmd ReadUserCmd functions) UserCmd is what's passed from the client to the server when a client moves, jumps, ducks, fires weapon, etc. Any magic that happens will happen in side there. :) Doooh! I hit Send to quick. Two mistakes, you are HUMAN! ;) You'll notice that forwardmove and sidemove are 'floats' so I was wrong. The total amount of movement is passed from the client to the server saying I've moved THIS much during the last tick.. Now it becomes obvious how sending packets with I've moved X amount during the last Y seconds can cause the player to move faster than normal on the server if the client lies about how much the client has moved or how long/short the time interval was. It still is not obvious, to me at least, why solving or at least highly limiting the spoofing of this is difficult. I don't have the SDK at work, so I can't check anything atm, but I am still working on HL1 so I'm wondering if there has been any major changes to the networking code for HL2. I think it's at least as spoofable as people seem to have similar issues. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/8/05, Deadman Standing [EMAIL PROTECTED] wrote: Based on the quake code here is what the move command passes: BYTE 3 (means move) FLOAT time (Used to calculate lag, ping, and movement) ANGLE viewangle X ANGLE viewangle Y ANGLE viewangle Z // The next three are the velocity of the player SHORT forward_movement SHORT sideway_movement SHORT up_movement BYTE bits (for attack and jump) BYTE impluse I don't have the SDK at work, so I can't check anything atm, but I am still working on HL1 so I'm wondering if there has been any major changes to the networking code for HL2. I think it's at least as spoofable as people seem to have similar issues. As martino wrote about HL2 lag compensation: The extra lantency caused by lower update rates is part of the general client latency. The actual code uses timestamps send with the user commands to set the execution time. These timestamps are checked against the average latency and if they are within a valid range, these timestamps are used since they are more precise then the calculation as stated in the doc. We can't fully rely on these timestamps since speedhackers could alter them. It appears HL2 has some level of detection for this, just do not know to what extent. Where did you get that from? Not saying you're wrong, just want to read the whole thing :) It would seem that if the client sends it's game time with it's packets then it really is trivial to stop speed hacks. It becomes very simple to calculate velocity/time and compare that to sv_maxspeed. It also becomes trival to simply ignore any packet from the future. sv_maxspeed is irrelevant. Calcs for maxspeed are already part of the velocity calculation and are correct. The key is the differences in the time stamps between packets compared to differences in real world time of when the packets arrived. If you compare the delta's of the message embedded times to the delta's of the real world times of when the packets arrived it should work (in theory). So if embedded delta's of the last two messages are 100 yet the real world delta's of when the packets arrived is 5 you would know something was up. The danger is a laggy player could appear as a speed hacker if you make the detection too sensitive (since network lag and UDP packet loss really do happen). So that leaves a window where some speed hacking will always be possible. Two things, first wouldn't lagged players be sending you older packets/times not future ones? Second, I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
On 6/6/05, Teddy [EMAIL PROTECTED] wrote: Have a dig around in CBasePlayer::PhysicsSimulate() to see how it runs the player commands (#2779 of /dlls/player.cpp). It only runs the physics once per frame. Increasing the number of commands per packet won't change this... A: The engine is what controls this not the mod dll. B: Please explain how you can get a speed hack from the client without sending more packets and/or commands. I don't mind being proven wrong, however that may require you provide an alternate explanation instead of just saying I'm wrong. Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Speed hack detection, was new SDK version is live
It is based on world time, not # of commands. A speed hack is essentially an exploit of the server's lag compensation. Number of commands is irrelevant. A speed hack would still work if you were to only send a packet a second. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Monday, June 06, 2005 3:53 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live On 6/6/05, Teddy [EMAIL PROTECTED] wrote: Have a dig around in CBasePlayer::PhysicsSimulate() to see how it runs the player commands (#2779 of /dlls/player.cpp). It only runs the physics once per frame. Increasing the number of commands per packet won't change this... A: The engine is what controls this not the mod dll. B: Please explain how you can get a speed hack from the client without sending more packets and/or commands. I don't mind being proven wrong, however that may require you provide an alternate explanation instead of just saying I'm wrong. Jeff ___ 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] Speed hack detection, was new SDK version is live
On 6/4/05, Teddy [EMAIL PROTECTED] wrote: I don't think you can speed hack by increasing your cl_cmdrate. Of course not, simple maths would lead anyone to that conclusion. Client sends X packets a second with Y commands per packet. If you double cl_cmdrate you get X*2 packets each containing Y/2 commands. The number of packets changes but the number of commands per second remains the same ... or at lest pretty damn close. Check out this bit of networking doco valve published recently: The client creates user commands from sampling input devices with the same tick rate that the server is running with. A user command is basically a snapshot of the current keyboard and mouse state. http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html Unfortunately you didn't quote the most useful part of that paragraph: This means two or more user commands are transmitted within the same packet. Increasing cl_cmdrate would decrease the number of commands contained in a packet as the packets get sent more often. So sending more snapshots is still only telling the server you're holding down the forwards button. And the server dosen't add your velocity every time it gets the user commands, it does it once per server frame. I believe this is wrong, if it were right, there would be no client side speed hacks. Assuming the server processes one packet per tick (we don't know this, the document does not say this is so, it may have a buffer of packets and process all packets in the buffer), each packet can contain multiple commands and each and every command in a packet will get processed by the server. By increasing your packet rate or increasing the number of commands per packet or combinations of both, you will be able to speed hack the server. This is how most of the hacks appear to work, they speed up the OS and send more packets per second and keep the commands per packet the same. The server processes these extra packets and the cheater gets to speed. What I'm suggesting is that the admin be able to set how many client commands the server should process per tick and that any extra commands for a player be dropped or use every X command to get a spread of commands from those supplied. e.g. if the max commands was 5 and the client sent 10, 10/5 == 2 so every 2nd command would be dropped. I await the appearance of the Valve team with their dreaded guns of we know what we are doing sonny to shoot me down in flames as this appears way to damn easy ;) As I said to a boss once If it appears easy, you just don't understand the problem well enough! :P Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
Jeff Fearn wrote: Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? Yes, I believe that is correct. The player sends movement commands to the server and the server says H, okay you are moving in this direction, let me calculate your new velocity and location based on where I think you were before and which way you were going before and then I'll send that information back to you. The client doesn't even specify HOW MUCH they moved (i.e. the distance during that update). The client only says I'm moving THIS way now. But note that the client is also simulating this movement update purely client-side (it just isn't authoritative since the server is the only one that keeps track of where everything REALLY is as far as collisions and bullet hits, etc.). -- 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] Speed hack detection, was new SDK version is live
On 6/3/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeff Fearn wrote: Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? Yes, I believe that is correct. The player sends movement commands to the server and the server says H, okay you are moving in this direction, let me calculate your new velocity and location based on where I think you were before and which way you were going before and then I'll send that information back to you. The client doesn't even specify HOW MUCH they moved (i.e. the distance during that update). The client only says I'm moving THIS way now. But note that the client is also simulating this movement update purely client-side (it just isn't authoritative since the server is the only one that keeps track of where everything REALLY is as far as collisions and bullet hits, etc.). Except the server can be fooled if you send it lots of updates because it doesn't seem to validate how often you send updates ... assuming that's how the speed hack actually works :) Jeff ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Speed hack detection, was new SDK version is live
One method I know about is speederxp to speed hack search google for it... It speeds up the applications and such. r00t 3:16 CQC Gaming www.cqc-gaming.com - Original Message - From: Teddy [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, June 04, 2005 1:11 AM Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live I don't think you can speed hack by increasing your cl_cmdrate. Check out this bit of networking doco valve published recently: The client creates user commands from sampling input devices with the same tick rate that the server is running with. A user command is basically a snapshot of the current keyboard and mouse state. http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html So sending more snapshots is still only telling the server you're holding down the forwards button. And the server dosen't add your velocity every time it gets the user commands, it does it once per server frame. On 6/4/05, Jeff Fearn [EMAIL PROTECTED] wrote: On 6/3/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote: Jeff Fearn wrote: Am I correct that a player does not actually state their position in the world but simply gives impulses (buttons), and therefore it's the number of impulses per second that allows speed hacking? Yes, I believe that is correct. The player sends movement commands to the server and the server says H, okay you are moving in this direction, let me calculate your new velocity and location based on where I think you were before and which way you were going before and then I'll send that information back to you. The client doesn't even specify HOW MUCH they moved (i.e. the distance during that update). The client only says I'm moving THIS way now. But note that the client is also simulating this movement update purely client-side (it just isn't authoritative since the server is the only one that keeps track of where everything REALLY is as far as collisions and bullet hits, etc.). Except the server can be fooled if you send it lots of updates because it doesn't seem to validate how often you send updates ... assuming that's how the speed hack actually works :) Jeff ___ 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
