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 a
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 serve
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 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 curre
ders] 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 serv
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
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...
On 6/5/05, Jeff Fearn <[EMAIL PROTECTED]> wrote:
> On 6/4/05, Teddy <[E
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 wh
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
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 yo
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 <[EM
: [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 h
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 thin
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 prefer
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 w
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 w
lto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn
Sent: Tuesday, June 07, 2005 8:24 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live
I don't think it passes velocity, what Botman said was that it passes
the impulse keys and that the server
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
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 m
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 c
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 everyon
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
>
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 speedhac
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 se
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 vis
27 matches
Mail list logo
