Re: [hlds] rate toggle
I understand it just fine, I'm not the one stating something and then pointing to a document that doesn't come close to stating the same thing as proof... On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I think you clearly misunderstand the document I refer to -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] Some how I doubt you have even bother to read it On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: I understand it just fine, I'm not the one stating something and then pointing to a document that doesn't come close to stating the same thing as proof... On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I think you clearly misunderstand the document I refer to -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
doubt all you like, the document clearly spells out what cl_interp is/does. It's got to do with you and your view of the server's data. Your view of the server data has nothing to do with my view of the server data. You can alter *your* 'delay' all you like, it doesn't affect me, as I have my own setting, and my own communication with the server. It's the same thing as saying that because you have a 500ms ping that I also have an effective 500ms ping, even though I actually have a 25ms ping. Your ping is your business, not mine, and it doesn't change anything with my communication with the server. It only affects you. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Some how I doubt you have even bother to read it -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] Look, it is quite clear that you haven't even bothered to look at the dicument let alone read the section I specifically quoted What part of *command execution* don't understand? On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: doubt all you like, the document clearly spells out what cl_interp is/does. It's got to do with you and your view of the server's data. Your view of the server data has nothing to do with my view of the server data. You can alter *your* 'delay' all you like, it doesn't affect me, as I have my own setting, and my own communication with the server. It's the same thing as saying that because you have a 500ms ping that I also have an effective 500ms ping, even though I actually have a 25ms ping. Your ping is your business, not mine, and it doesn't change anything with my communication with the server. It only affects you. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Some how I doubt you have even bother to read it -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
Can two take this pissing contest somewhere else please, it got old about 6 posts ago. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
I've read and understood it. You, obviously, have done one of those. Your client is not my client. Read that last sentence about 100 times. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Look, it is quite clear that you haven't even bothered to look at the dicument let alone read the section I specifically quoted What part of *command execution* don't understand? -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
once again you fail to understand what's going on. I'm not disputing what you're saying about client view interpolation. I'm trying to point out to you that this only affects communication between *you* and the server. The communication between *me* and the server isn't affected by *you* one iota. That's the point here, Elvis. Why are you so mad, cuz you're wrong? heh. Calm down. Kids these days. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Clayton you are once again being your usual arguing for the sake of it fucktard self You said quite specifically: I thought cl_interp only affects that client's view, and not anything to do with actual network communication, no? Once again for the dummy: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side exploits, it is quite clear from that explanation, the server takes into consideration the clients interpolation. This means each and every clients interpolation settings has an effect on when the server decides an action takes place and is a core component of the of the Source netcode. Clayton do I need to make the words *Client View Interpolation* larger, more bold or a different colour before you will pay attention to them and accept the fact it is a key component to Client Server communications for Source, or do you want to continue to deny its existence? You made a statement, the statement was incorrect. I politely at the time corrected it, but rather that accept your mistake you persist on arguing the point regardless. You cannot even bring yourself to quote from the source material I am using to back up your incorrect point of view, because you know you are wrong! Usually Clayton your arguments on this list are you taking some sort of grey area position where there is some 5% wriggle room for you to give yourself an excuse to have an argument, in this case there is no wriggle room for you, you are incorrect, and everybody on this list can see the proof for themselves and judge accordingly. This is not the first time you have tried to pull this shit, but I here to make sure people are well aware of who you are and what you attempt to do, each and almost everytime you reply to this list. For the record, I am not here for a pissing contest, I'm just sick and tired of this Clayton dickhead polluting threads on this list with misleading, or flatout incorrect information for whatever perverted reason he has for doing such things. On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: I've read and understood it. You, obviously, have done one of those. Your client is not my client. Read that last sentence about 100 times. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Look, it is quite clear that you haven't even bothered to look at the dicument let alone read the section I specifically quoted What part of *command execution* don't understand? -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
You both have each others email addresses, why not leave the rest of us out of this one? On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: once again you fail to understand what's going on. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
[rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side exploits, it is quite clear from that explanation, the server takes into consideration the clients interpolation. This means each and every clients interpolation settings has an effect on when the server decides an action takes place and is a core component of the of the Source netcode. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] Hey I agree with you James. My stupidity allowed me to get sucked in to Claytons baiting tactics. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: [rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side exploits, it is quite clear from that explanation, the server takes into consideration the clients interpolation. This means each and every clients interpolation settings has an effect on when the server decides an action takes place and is a core component of the of the Source netcode. ___ To unsubscribe, edit your list preferences, or view the list
Re: [hlds] rate toggle
I am interested to hear opinions over the viability of client rate regulation at the server side by means of server regulated client view extrapolation. Would this be a better solution?, or does it simply produce too much regulation on the low rate client? On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Hey I agree with you James. My stupidity allowed me to get sucked in to Claytons baiting tactics. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: [rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players are moved back to their original position. On a listen server you can enable sv_showimpacts 1 to see the different server and client hitboxes: Since the server is the final arbiter of what happen excluding Cheats or Client Side
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] But I cannot see what the technical problem (other than maybe it might be computationally intensive for the server) would be to automate the clients various rate settings, to best suit the clients connection and the servers settings. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: I am interested to hear opinions over the viability of client rate regulation at the server side by means of server regulated client view extrapolation. Would this be a better solution?, or does it simply produce too much regulation on the low rate client? On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Hey I agree with you James. My stupidity allowed me to get sucked in to Claytons baiting tactics. On 7/25/05, James Tucker [EMAIL PROTECTED] wrote: [rant] My god, two days after a message - how pathetic. Yes, client interpolation DOES have to do with netcode, and here is the REASON that neither of you seem to have the decency to produce for each other. [/rant] Interpolation does several things which effect netcode, these will be summarised here: - Sets the data drop time for incoming packets. - derived - Sets the data collision resolution time. - derived - Sets time to extrapolation on the client. -derived - Sets minimum time to client view regulation. -derived - Sets delay on gameworld data rendering. - Generates intermediary data using _known_ data, _if_available_. What it does not do: - change packetrates - alter the rate of incoming data from other clients - generate new data for clients with low packetrates When you see another client lagging, most peoples reaction seems to be a kick. If you turn up your cl_interp value, your client will have more time to wait until the next update arrives for the laggy player. At 30 packets per second you would get away (on an ideal network) with cl_interp 0.033. If a client is only capable of sending 10 packets per second however you will need cl_interp 0.1, again on an ideal network. Data rates can also be important, particularly on slow speed connections - latency for packets is one thing, but they take time to transmit as well, and the larger they are... Remember your time frames too. Client A with 100ms of latency plays game data on defaults, 100ms of interpolation and a packetrate of 20 packets per second. Client B has 'optimised' and is running with a client packetrate of 60 packets per second and 40ms of interpolation with a latency of 30ms. Client A attacks B and the packet arrives at the server 100ms later (neglecting to take into account the potential 50ms wait until the next packet is due for sending). The server rolls back 200ms and generates data. The server is trying to send 60 packets per second, the next packet will be sent within 16ms. Client B receives the update at 230ms to 296ms. Clearly this is well outside of client B's interpolation time, and is not a 'problem' with the 'netcode' settings but will give that appearance on the client. I have come to the conclusion that SRCDS is not affected with it's latency compensation by false pings generated through improper rate settings. I am not sure about HLDS. I have not built any system to test this however, but am merely aware that the scoreboard ping is not what is examined by high ping kicker tools. No, interpolation does not directly change the netcode, it is calculated on the server to regulate client view to server view - and in this regard it is significant in netcode also as it is responsible for the variables of the system stated above. There is no reason to deny it's significance in this discussion as proper cl_interp values can be used to compensate all clients for poor network performance - this is entirely what it was designed for. If client variables are mis-adjusted (VERY VERY COMMON) then you cannot make judgements about the functionality of the systems which they effect. Sorry if I missed anything, but hopefully this will get the discussion back on to something that matters, and exists. On 7/25/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] [snip-unnecessary-crap] http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation The lag compensation system keeps a history of all recent player positions for a time span of about one second (can be changed with sv_maxunlag). If a user command is executed, the server estimates at what time the command was created. This command execution time is calculated as followed: *Command Execution Time* = Current Server Time - Client Latency - *Client View Interpolation* Then the server moves all other players back to
Re: [hlds] rate toggle
again, that won't affect me and my view of the world if you have changed your value. It will change how things behave for your view of the world and your commands sent to the server. It won't affect the communication between me and the server at all. It only makes your view worse, doesn't change anything on my side. It's user-specific. The user that's changed this setting sees a difference according to that change. Other clients don't see what you see. Other clients see what the server tells them. On 7/23/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] If I read this correctly http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking cl_interp is a key component to whether you hit something or not according to the server! http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation *Command Execution Time = Current Server Time - Client Latency - Client View Interpolation* -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] You said: I thought cl_interp only affects that client's view, *and not anything to do with actual network communication*, no? It is patently clear that *cl_interp* *IS* critical to network communications, and is used by the server to decide how the in game world is represented back to all players on the server, which does affect you! On 7/24/05, Clayton Macleod [EMAIL PROTECTED] wrote: again, that won't affect me and my view of the world if you have changed your value. It will change how things behave for your view of the world and your commands sent to the server. It won't affect the communication between me and the server at all. It only makes your view worse, doesn't change anything on my side. It's user-specific. The user that's changed this setting sees a difference according to that change. Other clients don't see what you see. Other clients see what the server tells them. On 7/23/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] If I read this correctly http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking cl_interp is a key component to whether you hit something or not according to the server! http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation *Command Execution Time = Current Server Time - Client Latency - Client View Interpolation* -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
then you clearly misunderstand the document you referred to. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] It is patently clear that *cl_interp* *IS* critical to network communications, and is used by the server to decide how the in game world is represented back to all players on the server, which does affect you! -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] I think you clearly misunderstand the document I refer to On 7/25/05, Clayton Macleod [EMAIL PROTECTED] wrote: then you clearly misunderstand the document you referred to. On 7/24/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] It is patently clear that *cl_interp* *IS* critical to network communications, and is used by the server to decide how the in game world is represented back to all players on the server, which does affect you! -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
I disagree however, the fact that people are turning their cl_interp values down is a large part the cause of the low rate users warping or being harder to hit. It is no doubt however that there is an impact to model placement accuracy with cmdrate set so low, whether by lack of human compensation or algorithmic, or simply not enough data. You can see players on 56k connections running low rates and high cl_interp values having a really good gaming experience at times - it just takes some common sense. This problem has been going on for quite some time, and the few rate checking plugins I have seen floating around were built very inefficiently. On 7/21/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Alfred Online, if people drop their rates low cl_cmdrate, cl_updaterate, rate etc They get a really low consistent scoreboard ping (Although I have to say that it is not necessarily always the case that a low scoreboard ping = low rates) See pic here: http://whisper.ausgamers.com/pictures/sourcepings/de_dust_pcg0003.jpg BUT, they (the players with extremely low rates) are extremely choppy on other peoples screens, making them very difficult aim at and even harder to hit It would be good if sv_minrate and sv_minupdaterate enforced the equivalent client side miniums So an sv_minrate of 3000 would mean a client could could not set their rate setting lower than 3000 and sv_minupdaterate = 30 meant that clients cl_cmdrate and cl_updaterates also could not be lower than 30 regardless of whatever setting the client may try to have, either by exec'ing a config, manually typing in the commands or using some sort of alias that tries to by-pass it. Does that make sense and help ? Cheers On 7/22/05, Alfred Reynolds [EMAIL PROTECTED] wrote: Could I have a synopsis of the problems you are seeing please. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of K2 Sent: Thursday, July 21, 2005 11:39 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle I've been getting my fair share of cl_cmdrate exploiters as well, using the Mani admin plugin to check up on suspected exploiters has been a big help. I haven't seen any undue impact on server performance due to clients using a cmdrate that low... if anything, you'd think it'd actually help (client not requesting as much data from the server per tick). Suggestion - Valve should set a minimum/maximum range on cl_cmdrate and other cvars; there's no good reason that I can think of for the client to drop their cl_cmdrate setting below default (30). Whatcha think Alfred, can Valve lock down or set a min/max range on some of these settings we're discussing here? - K2 http://www.hardfought.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris K Sent: Thursday, July 21, 2005 8:22 AM To: hlds@list.valvesoftware.com Subject: Re: [hlds] rate toggle I get 'em every day with the 5 pings. I use Mani and just toggle cmdrate back to 30. I don't know about stopping people from EVER toggling, doubt you can do that. Since you brought up rates, I have been wanting to ask. Does cl_cmdrate 0 on a client really impact server performance? I would love to hear any good arguments for or against. I cannot seem to find any good info in the forums. On 7/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] is there any way to stop people from rate toggling , kid had a 1 ping in my server last night. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] cool -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
I thought cl_interp only affects that client's view, and not anything to do with actual network communication, no? Why would it affect anything on my side if you changed cl_interp on your machine? On 7/23/05, James Tucker [EMAIL PROTECTED] wrote: I disagree however, the fact that people are turning their cl_interp values down is a large part the cause of the low rate users warping or being harder to hit. It is no doubt however that there is an impact to model placement accuracy with cmdrate set so low, whether by lack of human compensation or algorithmic, or simply not enough data. You can see players on 56k connections running low rates and high cl_interp values having a really good gaming experience at times - it just takes some common sense. This problem has been going on for quite some time, and the few rate checking plugins I have seen floating around were built very inefficiently. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] If I read this correctly http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking cl_interp is a key component to whether you hit something or not according to the server! http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Lag_Compensation *Command Execution Time = Current Server Time - Client Latency - Client View Interpolation* On 7/24/05, Clayton Macleod [EMAIL PROTECTED] wrote: I thought cl_interp only affects that client's view, and not anything to do with actual network communication, no? Why would it affect anything on my side if you changed cl_interp on your machine? On 7/23/05, James Tucker [EMAIL PROTECTED] wrote: I disagree however, the fact that people are turning their cl_interp values down is a large part the cause of the low rate users warping or being harder to hit. It is no doubt however that there is an impact to model placement accuracy with cmdrate set so low, whether by lack of human compensation or algorithmic, or simply not enough data. You can see players on 56k connections running low rates and high cl_interp values having a really good gaming experience at times - it just takes some common sense. This problem has been going on for quite some time, and the few rate checking plugins I have seen floating around were built very inefficiently. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
I get 'em every day with the 5 pings. I use Mani and just toggle cmdrate back to 30. I don't know about stopping people from EVER toggling, doubt you can do that. Since you brought up rates, I have been wanting to ask. Does cl_cmdrate 0 on a client really impact server performance? I would love to hear any good arguments for or against. I cannot seem to find any good info in the forums. On 7/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] is there any way to stop people from rate toggling , kid had a 1 ping in my server last night. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
I've been getting my fair share of cl_cmdrate exploiters as well, using the Mani admin plugin to check up on suspected exploiters has been a big help. I haven't seen any undue impact on server performance due to clients using a cmdrate that low... if anything, you'd think it'd actually help (client not requesting as much data from the server per tick). Suggestion - Valve should set a minimum/maximum range on cl_cmdrate and other cvars; there's no good reason that I can think of for the client to drop their cl_cmdrate setting below default (30). Whatcha think Alfred, can Valve lock down or set a min/max range on some of these settings we're discussing here? - K2 http://www.hardfought.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris K Sent: Thursday, July 21, 2005 8:22 AM To: hlds@list.valvesoftware.com Subject: Re: [hlds] rate toggle I get 'em every day with the 5 pings. I use Mani and just toggle cmdrate back to 30. I don't know about stopping people from EVER toggling, doubt you can do that. Since you brought up rates, I have been wanting to ask. Does cl_cmdrate 0 on a client really impact server performance? I would love to hear any good arguments for or against. I cannot seem to find any good info in the forums. On 7/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] is there any way to stop people from rate toggling , kid had a 1 ping in my server last night. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
Could I have a synopsis of the problems you are seeing please. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of K2 Sent: Thursday, July 21, 2005 11:39 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle I've been getting my fair share of cl_cmdrate exploiters as well, using the Mani admin plugin to check up on suspected exploiters has been a big help. I haven't seen any undue impact on server performance due to clients using a cmdrate that low... if anything, you'd think it'd actually help (client not requesting as much data from the server per tick). Suggestion - Valve should set a minimum/maximum range on cl_cmdrate and other cvars; there's no good reason that I can think of for the client to drop their cl_cmdrate setting below default (30). Whatcha think Alfred, can Valve lock down or set a min/max range on some of these settings we're discussing here? - K2 http://www.hardfought.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris K Sent: Thursday, July 21, 2005 8:22 AM To: hlds@list.valvesoftware.com Subject: Re: [hlds] rate toggle I get 'em every day with the 5 pings. I use Mani and just toggle cmdrate back to 30. I don't know about stopping people from EVER toggling, doubt you can do that. Since you brought up rates, I have been wanting to ask. Does cl_cmdrate 0 on a client really impact server performance? I would love to hear any good arguments for or against. I cannot seem to find any good info in the forums. On 7/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] is there any way to stop people from rate toggling , kid had a 1 ping in my server last night. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
Hi! only a restriction is needed, that clients are not allowed to set their cl_updaterate and cl_cmdrate lower than 10 or 20. Like in CS 1.6 Cu, Sir D. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] rate toggle
-- [ Picked text/plain from multipart/alternative ] I think there should be 3 minimum settings (rate, cmdrate, updateratre) that are set server side that is enforceable on the client as well as something that makes it not possible for somebody to continously change their rates, i.e. Only when they fire. On 7/22/05, Marco Hombach [EMAIL PROTECTED] wrote: Hi! only a restriction is needed, that clients are not allowed to set their cl_updaterate and cl_cmdrate lower than 10 or 20. Like in CS 1.6 Cu, Sir D. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
This is a multi-part message in MIME format. -- does anyone know what causes choke. While in game I'll have good ping and no choke but every few minutes I'll get a stutter and my choke will jump up to like 5 and then go back down. I was also wondering what kind of rates should you use for CL_cmdrate CL_updaterate and rate, for both client and host end? Also if any one has any suggestions to squeeze out even more bandwidth from a CSS dedicated service I would like to here it. Thanks. From: [EMAIL PROTECTED] on behalf of Chris K Sent: Thu 7/21/2005 8:22 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] rate toggle I get 'em every day with the 5 pings. I use Mani and just toggle cmdrate back to 30. I don't know about stopping people from EVER toggling, doubt you can do that. Since you brought up rates, I have been wanting to ask. Does cl_cmdrate 0 on a client really impact server performance? I would love to hear any good arguments for or against. I cannot seem to find any good info in the forums. On 7/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] is there any way to stop people from rate toggling , kid had a 1 ping in my server last night. -- [ winmail.dat of type application/ms-tnef deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
Hrm, they shouldn't be able to go below the default values (30 for cmdrate and 20 for updaterate). Even a player using a cmdrate of 20 is too choppy/too hard to hit. Whisper - good explanation, saved me the trouble ;) - K2 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marco Hombach Sent: Thursday, July 21, 2005 9:12 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle Hi! only a restriction is needed, that clients are not allowed to set their cl_updaterate and cl_cmdrate lower than 10 or 20. Like in CS 1.6 Cu, Sir D. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
Why not just lock the client to match the servers tickrate? Are these variables that really need to be adjustable anyways? If they are is there any way to make them self-tuning according to network conditions? Rick Payton, IT Support Morikawa Associates (808) 572-1745 http://www.mai-hawaii.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Grimstead Sent: Thursday, July 21, 2005 8:53 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle The problem is, people are exploiting the game by setting lower rates. This makes that player alot more difficult to hit without them losing any sorts of performance to their bullet registry. The thing that needs to be seen really is the ability to control the cl_cmdrate and the cl_rate just like the cl_updaterate and rate commands. For example (cl_maxcmdrate and cl_maxclrate), or at least the ability to see what a clients cl_cmdrate and cl_rate is using the status command as you can see their rate and cl_updaterate. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
Cant do that, people on isdn and 56k would just lag completely, choke it up and get flush entity packets all over the place. The ability to control the cl_cmdrate and cl_rate would be better then forcing it, to allow change for isdn and 56k players. Controlling it though isnt as important as knowing what a clients cl_cmdrate and cl_rate actually are. If we at least know what all their rates are we can then force them to change them to a more reasonable level. If this is added to Source, please do it for HL1 aswell. I also see that cl_rate has been removed from Source, perhapse this can be done for HL1 too? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rick Payton Sent: 21 July 2005 21:38 To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle Why not just lock the client to match the servers tickrate? Are these variables that really need to be adjustable anyways? If they are is there any way to make them self-tuning according to network conditions? Rick Payton, IT Support Morikawa Associates (808) 572-1745 http://www.mai-hawaii.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Grimstead Sent: Thursday, July 21, 2005 8:53 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle The problem is, people are exploiting the game by setting lower rates. This makes that player alot more difficult to hit without them losing any sorts of performance to their bullet registry. The thing that needs to be seen really is the ability to control the cl_cmdrate and the cl_rate just like the cl_updaterate and rate commands. For example (cl_maxcmdrate and cl_maxclrate), or at least the ability to see what a clients cl_cmdrate and cl_rate is using the status command as you can see their rate and cl_updaterate. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/54 - Release Date: 21/07/2005 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
So how about self tuning then, based on connection speed / latency / choke / fps(?) / packet loss? I didn't take into consideration isdn 56k players, so maybe self tuning would be the way to go, or is something like this not possible yet? Rick Payton, IT Support Morikawa Associates (808) 572-1745 http://www.mai-hawaii.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Grimstead Sent: Thursday, July 21, 2005 10:49 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle Cant do that, people on isdn and 56k would just lag completely, choke it up and get flush entity packets all over the place. The ability to control the cl_cmdrate and cl_rate would be better then forcing it, to allow change for isdn and 56k players. Controlling it though isnt as important as knowing what a clients cl_cmdrate and cl_rate actually are. If we at least know what all their rates are we can then force them to change them to a more reasonable level. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
Nicely written, although I can correct you on one thing, I have tried and tested this. The sv_maxupdaterate sv_minupdaterate sv_maxrate sv_minrate do actually work at capping clients to what they are set at. But the client still displays their manually set rate, not the capped rate. For example: sv_maxrate 2 sv_minrate 1 sv_maxupdaterate 100 sv_minupdaterate 60 If a client sets: cl_updaterate 40 rate 6000 the status will display thoes ammouts, but they will actually be on: cl_updaterate 60 rate 1 I tested this by setting a max and minrates on my own server to maxup 100 minup 100 maxrate 2 minrate 2. I joined with 20 up and 1000 rate, but my net graph was showing 5.7kBps down (cl_cmdrate had to be set to 101 to get the correct download rate as lower cl_cmdrate lowers the downrate) My explanation may be difficult to understand, but im sure youll work it out :P -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Suck. Sent: 21 July 2005 22:46 To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle This is the best that I can explain it. I'm sure you're aware of much of this Alfred, but this should help inform those of you who don't know what's going on: The major client-side commands for different rates settings are rate cl_updaterate, and cl_cmdrate. The former two are difficult to exploit, in that they affect how much info the client is receiving and processing. cl_cmdrate, however, affects the rate that the client is sending data to the server. Players exploit this by turning it down to 10 or below (although anything below 20 starts to become a problem). Rates abusers are able to receive all the data they need to play relatively normally, but because they're reporting their own data to the server so infrequently, for the other players, they skip around and their actions come in bursts. This makes them extremely hard to hit for one, but also causes instant deaths from nowhere as a rates exploiter appears on top of you. A side-effect of this is that for some reason, scoreboard ping drops extremely low for players doing this, often around 5. There are server-side cvars designed to set the max and min cl_updaterate, but they don't work, as well as cvars to set max and min rate, although I'm not sure of the efficacy of these. There are no such cvars addressing cl_cmdrate. -Grant. -Original Message- From: [EMAIL PROTECTED] On Behalf Of Alfred Reynolds Sent: Thursday, July 21, 2005 1:46 PM Subject: RE: [hlds] rate toggle Could I have a synopsis of the problems you are seeing please. - Alfred ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/54 - Release Date: 21/07/2005 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] rate toggle
Thanks guys, we will check it out. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Whisper Sent: Thursday, July 21, 2005 12:02 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] rate toggle -- [ Picked text/plain from multipart/alternative ] Alfred Online, if people drop their rates low cl_cmdrate, cl_updaterate, rate etc They get a really low consistent scoreboard ping (Although I have to say that it is not necessarily always the case that a low scoreboard ping = low rates) See pic here: http://whisper.ausgamers.com/pictures/sourcepings/de_dust_pcg0003.jpg BUT, they (the players with extremely low rates) are extremely choppy on other peoples screens, making them very difficult aim at and even harder to hit It would be good if sv_minrate and sv_minupdaterate enforced the equivalent client side miniums So an sv_minrate of 3000 would mean a client could could not set their rate setting lower than 3000 and sv_minupdaterate = 30 meant that clients cl_cmdrate and cl_updaterates also could not be lower than 30 regardless of whatever setting the client may try to have, either by exec'ing a config, manually typing in the commands or using some sort of alias that tries to by-pass it. Does that make sense and help ? Cheers On 7/22/05, Alfred Reynolds [EMAIL PROTECTED] wrote: Could I have a synopsis of the problems you are seeing please. - Alfred Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of K2 Sent: Thursday, July 21, 2005 11:39 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] rate toggle I've been getting my fair share of cl_cmdrate exploiters as well, using the Mani admin plugin to check up on suspected exploiters has been a big help. I haven't seen any undue impact on server performance due to clients using a cmdrate that low... if anything, you'd think it'd actually help (client not requesting as much data from the server per tick). Suggestion - Valve should set a minimum/maximum range on cl_cmdrate and other cvars; there's no good reason that I can think of for the client to drop their cl_cmdrate setting below default (30). Whatcha think Alfred, can Valve lock down or set a min/max range on some of these settings we're discussing here? - K2 http://www.hardfought.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris K Sent: Thursday, July 21, 2005 8:22 AM To: hlds@list.valvesoftware.com Subject: Re: [hlds] rate toggle I get 'em every day with the 5 pings. I use Mani and just toggle cmdrate back to 30. I don't know about stopping people from EVER toggling, doubt you can do that. Since you brought up rates, I have been wanting to ask. Does cl_cmdrate 0 on a client really impact server performance? I would love to hear any good arguments for or against. I cannot seem to find any good info in the forums. On 7/21/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] is there any way to stop people from rate toggling , kid had a 1 ping in my server last night. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
