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 <[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 > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
