Hi guys,
Since a number of TE members are quickly becoming CS: S players, I thought of writing this guide about how exactly Source lag compensation works. The purpose of doing this is because w/o the proper idea, some people repeatedly think that source is bugged and/or they were killed by a hacker.
Ok here goes: :hap2:
Rates/Tariffs/Paisa
You guys must hv seen me talking about correct rates in the servers. WTH are these rates actually about? Money that you have to pay to play?
Or something else. You guessed right, its something else.
Rates are defined by 5 "main" variables. And these matter only during online gameplay, because in official tournaments like WCG etc, the rates are fixed to certain values (25000 101 101 1 0.01) by server side plugins so as to ensure a level playing field.
These 5 variables are:
rate
This decides how much bandwidth the client is allowed to use for the game. Without having to elaborate much, this is like the first RATE you should fine tune. Suppose you have a 256K connection. That means your connection is rated for continuous througputs of upto 32KBps. Because these are not dedicated lines, say we get around 90% of the speed most of the time. Then its preety safe to use the "rate" cvar (client variable) at the value of 25000 (which roughly translates to 25000/1000 = 25KBps, remember when calculating speed, we divide by 1000, not 1024) Now this value is recommended because:
So dont think you would be saving bandwidth or improving ping by reducing this figure. Just set it to a good ball park figure of:
cl_cmdrate
This is the next most important "rate setting" you will come accross. This dictates the number of updates the source client will be sending accross to the server. Enuf said. So this decides:
So to enjoy a proper game, its is quintessential to have the cl_cmdrate set to atleast 33. If you can have it more (upto the TICKRATE of the server) then even better. But just remember, setting this to anything higher than the tickrate does bullocks for your game. Infact it has no effect at all. The game only sends as many commands as the servers requests it to and it can never be more than the tickrate the server is running at. cl_cmdrate again only gives a ceiling value.
cl_updaterate
This is the diametric opposite to cl_cmdrate. cl_cmdrate decides how many updates the client sends to server per second. This determines, how many updates you can request the server to send to you, per second.
So basically, by reducing this quantity, you are crippling your game more than you can imagine. Just get this..... say you are playing on a 33 tick server. So thats one actual server frame (configuration of the game world) every 1000/33 = 30.33 millisec. Thats a virtual 33 fps cap. Now by reducing the cl_updaterate even below 33, you are limiting the ability to recieve packets even more. The source engine does a fair enough job of interpolating between the discreet packets it recieves and giving a smooth motion to the end user (this happens in the client side) So by reducing the cl_updaterate, you are asking the client to interpolate (make up frames) between 2 very distant and different "real" frames. Many a times the interpolation is not perfect (as it has to be done real time) and thus you end up believing that you were shooting the guy but he didnt die because CSS sucks. What happened was that the character was not present where you thought he was present. In the server's eye, you were infact shooting thin air. Its actually you who were responsible for it happening because you used bad rates. I hope some of the above tricked into your head
cl_interpolate and cl_interp
Now we are definitely descending into murky waters. Its quite probable that this will make no sense to you in the first read. Hell i had to quite a lot of probing to understand this myself. So i am writing this down so as to help out fellow sourcers understand this faster.
cl_interpolate and cl_interp go hand in hand. cl_interpolate is like a boolean switch. It decides whether the client does interpolation or not. To see if I am speaking out of my wrong end, just join any server (non CSP authenticated i.e.) and turn cl_interpolate to 0. You will suddenly see the screen starts to jerk. Dont worry, your computer wasnt suddenly downgraded. What happened was you instructed you client to NOT interpolate the frames it was recieving and to show them as it was recieving them. So its obvious, with proper rates, a 33 tick server will frame the most. 66 tick server will be playable with cl_interpolate off. 100 tick server will be the smoothest of all and will give the best gaming experience as there will be no "false" firing from your side because:
Now onto cl_interp. When cl_interpolate is turned on, this value is not considered. Its is when you disable interpolation that this value comes into play. And setting improper values to this cvar is called a "interp" hack. Why's that? Because, supposably, if you set this to a value of 0.1s, you can shoot people 0.1s in history. What happens is, the server traces the target (when you are shooting) back 0.1s in time and then calculates if your bullet hit or not. Obviously, this can be used to enact some very disastorous shots. Consider the following example:
Mid double door in de_dust2
More often than not, when the counter terrorists jump accross the gap when going towards B, they travel so fast that it is humanely impossible to shoot them when they are crossing the small gap between the doors. There are 2 solutions, either you improve you aim to such a extent that you get them when they are past the door by approximating and shooting them through the door, or else use the interp hack. Just set cl_interp to 0.1s. Keep your crosshair right in the middle of the door. Shoot as soon as you see the guy. More often than not the guy would have passed completely then you would have shot. Well in this case the same thing happens. What really messes the matter up is the server translocates the target 0.1s back in history, conviniently placing him SQUARELY in the middle of the double door, the place where you actually shot the bullet. So you get the kill, even without shooting at him.
Hope you guys understood what I am saying.
TICKRATE
This is the holy grail of all rates. The tickrate. Basically, it doesnt make a difference if your uber leet graphics card can put out a gazillion frames per second. You are still being limited by the number of server frames you are being sent by the server you are playing in. So avoid playing in 33 tick servers at all costs. 66 tick and 100 tick are not that much different from each other (100 being only slightly better and preety useless anywhere except lan because of the latencies involved. So you will ask, why dont all servers run 66 tick? Because, honey, the CPU utilization doubles/triples compared to a plain/jane 33 tick server. Its like turning on Soft Shadows in F.E.A.R. except that the improvements are not just cosmetic, they are real. The same applies to CS1.6 also. But some of the not-so-acquainted admins are not even aware that there is a tickrate concept in 1.6. Avoid playing in 30 tick 1.6 servers at all cost. Thats now how a real 1.6 game should be like.
Hit Detection
I have been typing for quite long now and need to go work on my end sem project. Need to wrap this up fast.
Hit detection is a very complex procedure in any game. Any what makes it even more complex in a game like Source is:
So what gives?
To ensure a fair play for both low pingers and high pingers, Valve implemented a very novel concept. For example, suppose a high pinger comes out of a corner and spots a enemy just entering a room, shoots and gets a kill (supposing a Headshot) it is not necessary that the guy who died was at that shop in his own screen. He could have very well entered the room .1 sec before he got killed. It is just that the Source engine was impartial. Doesnt matter if you were in the room. When the opponent came up behind u, he shot you in his screen just outside the door as you were entering. If he didnt have that lag, he would have still shot you, hence its considered a +ve hit. So basically what is done is the guy is teleported back by the amount which the server thinks the shooter is behind in terms of game lag. Also remember, the latency between two people is equal to Latency of player A to server + Latency of player B to server.
This leads to some very interesting scenarios.....
Suppose you hear a guy coming up from behind the right wall. You have a sniper and conviniently zoom in and keep it right next to the wall so as to get him as soon as he shows his face. You wait. But what happens? You die as soon as you see him. Was it that you had slow reflexes and the other guy super human reflexes that he aimed and shot you even before you could just shoot the bullet. Na, this is the falacy of online play for u. What happened was, he actually strolled out quite a bit far, saw you, took aim and then killed you. But in you screen, he has just appeared. This happened because, between you and him, you had say a 300 ms lag (considering 150 ms average pings between the both of you.) so him coming out of the wall would appear 300 ms after it actually happened. And for a good player, .3 sec is more than enough to get a easy headshot. In lan with 100 tickrates, this is not gonna happen cuz the effective lag between the both of you is around 5-10ms and this is too low to make any difference. Hope i got accross my thought process to you effectively.
Well guys, I spent a good 1 hour typing this out. Always wanted to write this article, but figured it would go awaste. Now that our very own TE server is up and running, and many people have taken a interest to Source, I hope this article helps you all (helps me as well, you know green bars 
) Also please forgive me for any typos that could have occured.
Regards,
Karan Misra
------------------
Source: NA, original guide baby
Since a number of TE members are quickly becoming CS: S players, I thought of writing this guide about how exactly Source lag compensation works. The purpose of doing this is because w/o the proper idea, some people repeatedly think that source is bugged and/or they were killed by a hacker.
Ok here goes: :hap2:
Rates/Tariffs/Paisa
You guys must hv seen me talking about correct rates in the servers. WTH are these rates actually about? Money that you have to pay to play?
Or something else. You guessed right, its something else.Rates are defined by 5 "main" variables. And these matter only during online gameplay, because in official tournaments like WCG etc, the rates are fixed to certain values (25000 101 101 1 0.01) by server side plugins so as to ensure a level playing field.
These 5 variables are:
- rate
- cl_cmdrate
- cl_updaterate
- cl_interpolate
- cl_interp
- TICKRATE
rate
This decides how much bandwidth the client is allowed to use for the game. Without having to elaborate much, this is like the first RATE you should fine tune. Suppose you have a 256K connection. That means your connection is rated for continuous througputs of upto 32KBps. Because these are not dedicated lines, say we get around 90% of the speed most of the time. Then its preety safe to use the "rate" cvar (client variable) at the value of 25000 (which roughly translates to 25000/1000 = 25KBps, remember when calculating speed, we divide by 1000, not 1024) Now this value is recommended because:
- the client will not use it unless its required. Its like a upper ceiling to the bandwidth.
- the client will only use that much as is required to transmit the in and out packets (more on this later)
So dont think you would be saving bandwidth or improving ping by reducing this figure. Just set it to a good ball park figure of:
- 25000 (if you have a 256K connection. People settng this to 30000 or above are just doing something which will be having no effect. Read my previous paragraph. It will only use as much as is required to transfer the updates and IT NEVER exceeds 23KBps. 25000 is just a ball park accepted figure.)
- 15000 (if you have a 128K connection.)
- 9999/10000 (if you have a 64K connection. Dont use 7500, cause that is actually giving you choke. Just set it to something higher to avoid choke.)\
cl_cmdrate
This is the next most important "rate setting" you will come accross. This dictates the number of updates the source client will be sending accross to the server. Enuf said. So this decides:
- if you movements (meaning ur characters ingame) are updated to server and at what frequency (remember, these rates are per sec values.)
- how often do your bullet fires get sent to the server for hit detection. Thats right. People who think they are very smart and set cl_cmdrate to 10 to get lower pings are not only hurting themshelves (lower bullet hit registry) but also majorly pissing off others because they will teleport in other people screens. Next time someone teleports in your screen, just think that one of the main possibilites is that he is using a very low cl_cmdrate.
- as I just mentioned, this value can be used as a ping exploit. Because of the way, the Source engine calculates ingame latency, setting this value lower will show a "false" low ping in the score TAB. remember, it just shows a lower value, the real ping can still be known by typing "status" in the console area.
So to enjoy a proper game, its is quintessential to have the cl_cmdrate set to atleast 33. If you can have it more (upto the TICKRATE of the server) then even better. But just remember, setting this to anything higher than the tickrate does bullocks for your game. Infact it has no effect at all. The game only sends as many commands as the servers requests it to and it can never be more than the tickrate the server is running at. cl_cmdrate again only gives a ceiling value.
cl_updaterate
This is the diametric opposite to cl_cmdrate. cl_cmdrate decides how many updates the client sends to server per second. This determines, how many updates you can request the server to send to you, per second.
So basically, by reducing this quantity, you are crippling your game more than you can imagine. Just get this..... say you are playing on a 33 tick server. So thats one actual server frame (configuration of the game world) every 1000/33 = 30.33 millisec. Thats a virtual 33 fps cap. Now by reducing the cl_updaterate even below 33, you are limiting the ability to recieve packets even more. The source engine does a fair enough job of interpolating between the discreet packets it recieves and giving a smooth motion to the end user (this happens in the client side) So by reducing the cl_updaterate, you are asking the client to interpolate (make up frames) between 2 very distant and different "real" frames. Many a times the interpolation is not perfect (as it has to be done real time) and thus you end up believing that you were shooting the guy but he didnt die because CSS sucks. What happened was that the character was not present where you thought he was present. In the server's eye, you were infact shooting thin air. Its actually you who were responsible for it happening because you used bad rates. I hope some of the above tricked into your head
cl_interpolate and cl_interp
Now we are definitely descending into murky waters. Its quite probable that this will make no sense to you in the first read. Hell i had to quite a lot of probing to understand this myself. So i am writing this down so as to help out fellow sourcers understand this faster.
cl_interpolate and cl_interp go hand in hand. cl_interpolate is like a boolean switch. It decides whether the client does interpolation or not. To see if I am speaking out of my wrong end, just join any server (non CSP authenticated i.e.) and turn cl_interpolate to 0. You will suddenly see the screen starts to jerk. Dont worry, your computer wasnt suddenly downgraded. What happened was you instructed you client to NOT interpolate the frames it was recieving and to show them as it was recieving them. So its obvious, with proper rates, a 33 tick server will frame the most. 66 tick server will be playable with cl_interpolate off. 100 tick server will be the smoothest of all and will give the best gaming experience as there will be no "false" firing from your side because:
- interpolation is turned off so the client is only showing the frames it is recieving.
- because the server is 100 tick, it is processing 100 frames per second and thus the updates the client is recieving are preety close by to each other. Therefore no framing.
Now onto cl_interp. When cl_interpolate is turned on, this value is not considered. Its is when you disable interpolation that this value comes into play. And setting improper values to this cvar is called a "interp" hack. Why's that? Because, supposably, if you set this to a value of 0.1s, you can shoot people 0.1s in history. What happens is, the server traces the target (when you are shooting) back 0.1s in time and then calculates if your bullet hit or not. Obviously, this can be used to enact some very disastorous shots. Consider the following example:
Mid double door in de_dust2
More often than not, when the counter terrorists jump accross the gap when going towards B, they travel so fast that it is humanely impossible to shoot them when they are crossing the small gap between the doors. There are 2 solutions, either you improve you aim to such a extent that you get them when they are past the door by approximating and shooting them through the door, or else use the interp hack. Just set cl_interp to 0.1s. Keep your crosshair right in the middle of the door. Shoot as soon as you see the guy. More often than not the guy would have passed completely then you would have shot. Well in this case the same thing happens. What really messes the matter up is the server translocates the target 0.1s back in history, conviniently placing him SQUARELY in the middle of the double door, the place where you actually shot the bullet. So you get the kill, even without shooting at him.
Hope you guys understood what I am saying.
TICKRATE
This is the holy grail of all rates. The tickrate. Basically, it doesnt make a difference if your uber leet graphics card can put out a gazillion frames per second. You are still being limited by the number of server frames you are being sent by the server you are playing in. So avoid playing in 33 tick servers at all costs. 66 tick and 100 tick are not that much different from each other (100 being only slightly better and preety useless anywhere except lan because of the latencies involved. So you will ask, why dont all servers run 66 tick? Because, honey, the CPU utilization doubles/triples compared to a plain/jane 33 tick server. Its like turning on Soft Shadows in F.E.A.R. except that the improvements are not just cosmetic, they are real. The same applies to CS1.6 also. But some of the not-so-acquainted admins are not even aware that there is a tickrate concept in 1.6. Avoid playing in 30 tick 1.6 servers at all cost. Thats now how a real 1.6 game should be like.
Hit Detection
I have been typing for quite long now and need to go work on my end sem project. Need to wrap this up fast.
Hit detection is a very complex procedure in any game. Any what makes it even more complex in a game like Source is:
- the latency involved. people with different latencies (ranging from 10 ms to 300 ms) paying in the same map in the same server at same time.
- recoil patterns of different guns depending on the movement and orientation of the guy shooting it (in game i.e.)
- etc, etc, etc.
So what gives?
To ensure a fair play for both low pingers and high pingers, Valve implemented a very novel concept. For example, suppose a high pinger comes out of a corner and spots a enemy just entering a room, shoots and gets a kill (supposing a Headshot) it is not necessary that the guy who died was at that shop in his own screen. He could have very well entered the room .1 sec before he got killed. It is just that the Source engine was impartial. Doesnt matter if you were in the room. When the opponent came up behind u, he shot you in his screen just outside the door as you were entering. If he didnt have that lag, he would have still shot you, hence its considered a +ve hit. So basically what is done is the guy is teleported back by the amount which the server thinks the shooter is behind in terms of game lag. Also remember, the latency between two people is equal to Latency of player A to server + Latency of player B to server.
This leads to some very interesting scenarios.....
Suppose you hear a guy coming up from behind the right wall. You have a sniper and conviniently zoom in and keep it right next to the wall so as to get him as soon as he shows his face. You wait. But what happens? You die as soon as you see him. Was it that you had slow reflexes and the other guy super human reflexes that he aimed and shot you even before you could just shoot the bullet. Na, this is the falacy of online play for u. What happened was, he actually strolled out quite a bit far, saw you, took aim and then killed you. But in you screen, he has just appeared. This happened because, between you and him, you had say a 300 ms lag (considering 150 ms average pings between the both of you.) so him coming out of the wall would appear 300 ms after it actually happened. And for a good player, .3 sec is more than enough to get a easy headshot. In lan with 100 tickrates, this is not gonna happen cuz the effective lag between the both of you is around 5-10ms and this is too low to make any difference. Hope i got accross my thought process to you effectively.
Well guys, I spent a good 1 hour typing this out. Always wanted to write this article, but figured it would go awaste. Now that our very own TE server is up and running, and many people have taken a interest to Source, I hope this article helps you all (helps me as well
, you know green bars ) Also please forgive me for any typos that could have occured.Regards,
Karan Misra
------------------
Source: NA, original guide baby
hyeah: