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
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
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
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
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
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
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.
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
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
: [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
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
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
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
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
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
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
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
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
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
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
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
: 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
On 6/3/05, Mike Dussault [EMAIL PROTECTED] wrote:
http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html
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
On 5/23/05, Andrew (British_Bomber) [EMAIL PROTECTED] wrote:
If the client says its game time A and I'm here, then, it's game time
B and I'm there, how is that in anyway difficult to calculate
distance/time? This is only a problem if the client doesn't send or
the server doesn't use the
If the client says its game time A and I'm here, then, it's game time
B and I'm there, how is that in anyway difficult to calculate
distance/time? This is only a problem if the client doesn't send or
the server doesn't use the idea of game time.
I would think that the issue is, that they
If the server knows that you are reloading and won't let you reload
any faster, why can't it stop you from walking or running, hell even
firing really fast? I know there are a lot of ambiguous cases like
teleporters and stuff, but still it seems a bit odd that you can haul
balls accross a map and
Sometimes a player will lag out for a couple seconds and then when his
posistion is updated he jumps to his actual location. It seems like
that would appear to be a speed hack if you weren't checking an
average speed for a long enough period of game history (10-20
seconds?).
I think the problem
: [hlcoders] Speed hack detection?
But then whoever writes the hacks would find that exploit and make it
so it tricks the server to make him think is ping was 400++ a lag
hack
On 5/18/05, Erling K. Sæterdal [EMAIL PROTECTED] wrote:
I dont know what LPBs firstly.
If someone has a constant ping of 400
On 5/19/05, LDuke [EMAIL PROTECTED] wrote:
Sometimes a player will lag out for a couple seconds and then when his
posistion is updated he jumps to his actual location. It seems like
that would appear to be a speed hack if you weren't checking an
average speed for a long enough period of game
] Speed hack detection?
On 5/19/05, LDuke [EMAIL PROTECTED] wrote:
Sometimes a player will lag out for a couple seconds and then when his
posistion is updated he jumps to his actual location. It seems like
that would appear to be a speed hack if you weren't checking an
average speed for a long
Yes, every speed hacker ive seen are zooming around the map.
I want it to catch them.
- Plasma
- Original Message -
From: Jeffrey botman Broome [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, May 19, 2005 1:06 AM
Subject: Re: [hlcoders] Speed hack detection
It's very possible to do that, but as Jeff said you will get a lot
more false positives just due to altering latencies rather than real
hackers. In theory it is sound but unless you have a decent thresh
hold on hacking speeds and just lagging speeds, a better way of doing
this without banning non
On 5/18/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote:
You would probably not have difficulty detecting a speed hack that was a
LARGE increase from the server's max speed (i.e. 2X speed, 4X speed,
etc), but trying to determine if someone is going 10% to 20% faster over
a small amount of
Jeff Fearn wrote:
Say one put a threshold of 50% or 100% speed up, how would you go
about detecting that in a server plugin?
What I would do is keep a list of players currently on the server (store
their edict as they connect along with their current location). The
player's location can be
, 2005 12:36 AM
Subject: Re: [hlcoders] Speed hack detection?
Jeff Fearn wrote:
Say one put a threshold of 50% or 100% speed up, how would you go
about detecting that in a server plugin?
What I would do is keep a list of players currently on the server (store
their edict as they connect along
-gaming.com
- Original Message -
From: Erling K. Sæterdal [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Wednesday, May 18, 2005 7:19 PM
Subject: Re: [hlcoders] Speed hack detection?
I have created a speedhack detector for amxmodx ( Not released publicy as
of yet ), and i encountered
r00t 3:16 wrote:
Does anyone know (please do not post it if you do know) how the speed hack
actually works?
It seems they are somehow changing a variable in memory ? Or are they
tricking the server somehow ?
Usually the client's system clock is running faster (slower?) than
normal, I can't
@list.valvesoftware.com
Sent: Wednesday, May 18, 2005 7:54 PM
Subject: Re: [hlcoders] Speed hack detection?
r00t 3:16 wrote:
Does anyone know (please do not post it if you do know) how the speed
hack
actually works?
It seems they are somehow changing a variable in memory ? Or are they
tricking
[EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, May 19, 2005 1:32 AM
Subject: Re: [hlcoders] Speed hack detection?
high ping kicking is mean and spiteful. I don't want to rant about it,
but lag comp nullifies any complaints LPBs have. (which should be
none, because HPBs don't
, 2005 1:32 AM
Subject: Re: [hlcoders] Speed hack detection?
high ping kicking is mean and spiteful. I don't want to rant about it,
but lag comp nullifies any complaints LPBs have. (which should be
none, because HPBs don't lag the game. if anything LPBs with
aggressive settings do.)
On 5/18/05
On 5/19/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote:
r00t 3:16 wrote:
Does anyone know (please do not post it if you do know) how the speed hack
actually works?
It seems they are somehow changing a variable in memory ? Or are they
tricking the server somehow ?
Usually the client's
:32 AM
Subject: Re: [hlcoders] Speed hack detection?
high ping kicking is mean and spiteful. I don't want to rant about it,
but lag comp nullifies any complaints LPBs have. (which should be
none, because HPBs don't lag the game. if anything LPBs with
aggressive settings do.)
On 5/18/05, Erling K
-gaming.com
- Original Message -
From: Jeff Fearn [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Wednesday, May 18, 2005 9:32 PM
Subject: Re: [hlcoders] Speed hack detection?
On 5/19/05, Jeffrey botman Broome [EMAIL PROTECTED] wrote:
r00t 3:16 wrote:
Does anyone know (please do
- Original Message -
From: r00t 3:16 [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, May 19, 2005 11:56 AM
Subject: Re: [hlcoders] Speed hack detection?
Yes, that is kind of crazy really.
But what is weird, if they are speeding up the clock would you foot alot
faster
PM
Subject: Re: [hlcoders] Speed hack detection?
Yes, that is kind of crazy really.
But what is weird, if they are speeding up the clock would you foot alot
faster and throw grenades faster etc?
I seen the speed hack only 1 or 2 times and didnt' remember seeing them
fire
faster but it might
Jennings [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Wednesday, May 18, 2005 10:22 PM
Subject: Re: [hlcoders] Speed hack detection?
Yes, speed hacks enable you to fire faster. With a 6x speed hack you can
empty a clip of the AK47 in practically no time. It doesn't let you reload
At 07:51 PM 5/18/2005, root 3:16 wrote:
but it should reload faster though cause reloading is tick based ?
Weird stuff...
Not wierd at all.
The server's clock is what determine's server tick rate and therefore
the timing of Think() functions.
Server alone decides when you have reloaded.
Michael A.
47 matches
Mail list logo
