M
MattJones2k6
Guest
Hi,
I am one of the many followers of TUFs ideas
don't ban me, i'm just trying to share what he has to offer.
Counterstrike source netcode
- The final quirks.
Disclaimer
This article describes the current issues that the netcode still has underspecific clientside and serverside net related convars. This is NOT a repeat of any video that has been proven incorrectly 10 times over already, this is not a complaint about receiving poor hitreg, this is an article backed up by evidense and test scenario's for you to try out.
Index
1. Explanation of the current concept of the counterstrike source netcode.
2. Explanation of the current issues with the current implementation of this netcode.
Current netcode concept.
The counterstrike source netcode is made under the assumption of many worst case scenario's, however also with flexibility in mind. For example, the default setting of client interpolation delay is enough to support a connection losing 2 out of every 3 packets of data.
With that in mind I'll first link to a reference link of what valve has to say about the netcode:
http://www.valve-erc.com/srcsdk/gen...networking.html
Let's start explaining what many people here are simply reading past or not understanding.
First of all, to do it's work the "counterstrike source client netcode" (How your computer deals with all the stuff it receives from the server), uses a delayed interpolation system, now don't worry, I'm going to explain what that means to you. Because the source netcode is made for such worst case scenarios, it only assumes the player being abled to receive an update from the server approximately 30 times per second, now this might sound like a lot to you, but wour computer wants to know a lot more than this. For example, if you have an avarage of 50 frames per second, 30 updates per second is going to be 20 too few. For example, a player is running from the left side of your screen to the right side of your screen, with 30 updates per second at 50 frames per second, the player is going to move in 1 frame, and appear to be standing still in the next, this is definitly not what we want.
To counter this effect, your computer wont immediatly show you something as soon as you receive the data, instead it buffers the data for a short time delay (By default this is 0.1 seconds, however the duration of the time this data is being stored for before being displayed can be changed using your cl_interp command), during this time delay your computer will receive more information from the server, now once your computer starts displaying the information it received first, it already knows whats going to happen next, because your computer knows this, it can create a smooth transition between the 2 pieces of information.
This is basically what it all comes down to, waiting to receive more information so you can make an educated estimate of what happened in between these points in time.
Now most of this can be modified (and should be if you're planning to play in a competitive enviroment), I'll mention the most important: For good results, a lot needs to be modified, for example, a default server will only render the world events 33 times per second (tickrate), in order to increase your information throughput you need to increase the server tickrate. Now once the tickrate has been increased (maximum of 100, default of 33), you can change settings like the amount of datapackages you wish to receive from the server(cl_updaterate), the amount of bandwidth you're willing to set available for this(rate), the amount of datapackages you're willing to send to the server(cl_cmdrate), and how long you wish for your computer to wait and buffer information before actually displaying it (cl_interp), all of these convars need to be set with a good relation to one and eachother, for example if you wish to receive a lot of updates from the server, yet set a low amount of bandwidth available for this, you will receive 'choke'.
Now you may be thinking, if someone I'm seeing on my screen was actually there a little time ago, is that why I miss when I shoot him? The anwser is no, in most scenarios you just missed, in others there are more complicated issues that I'm not going to go through in the first post, however might go through if asked about. Why the anwser is no? The server keeps track of the relavant settings to netcode for each client, When you shoot a bullet, it doesn't just check when you shot it, it also checks how much network latency you're receiving on average, and it checks to see what you would have been seeing when you fired your bullet, in other words it looks at the time it received notice about you firing your bullet, than it goes back in time to where you shot your bullet on your computer (network/internet latency), than it checks your cl_interp value (or the time you were visually delayed by) and goes back in time that much extra, using this information the server can check whether the bullet you fired should hit anyone or not.
To all of those who've seen the "hitboxes are off" video's going around on the net, what these video's display is not faked, it will display like that, however the hitboxes you're seeing is not the hitboxes that the player has, the player has no hitboxes, only the server does, they are the hitbox locations of the server, this means that cl_interp will not delay them in any way, this also means that shooting them will do you no good, as the server will still reduce network latency and interpolation delay from your bullet firing time to make its hitregistration checks.
Issues with the current netcode implementation.
There are currently 2 large issues still present in the counterstrike source netcode, 1 of them only occurs with clientside interpolation entirely disabled (cl_interpolate 0, not default), and the other (however, far less significant) with interpolation enabled (default).
I'll start with the issue existing when interpolation is enabled, this all started when Drax, a former CAL - Invite player posted up his wishlist of what counterstrike source should become, it included a short video displaying evidense that when interpolation is enabled, the delay was actually a lot longer than the delay set by cl_interp. This can be found here:
http://www24.brinkster.com/draxus99/source/
Now a lot of people have questioned his method of synchronising both parts of the video, so have I, as a mather of fact, I went ahead and asked drax myself. His anwser? He used the in-game clock to synchronise them. Personally I'm not entirely sure of how accurate this clock is, so I conducted my own share of research.
Here's what I did, since we are testing clientside interpolation, something servers have nothing what-so-ever to do with, we can even test this in a listen server enviroment, and if you really need to, you could even use a bot to conduct this test (As for the purpose of this test, the results are exactly the same, interpolation simply works exactly the same). What I did was, I created a server, joined spectators, and had someone else join the counterterrorist team. I went to his side at a perfect 90 degree angle, enabled the 'hitboxes' (to display the server location of the player), and took screenshots of the player running forward in a perfect straight line, I took multiple samples so I could read the average, for the most accurate readings.
The results can be found here:
http://www.booom.co.uk/images/netcode/
I conducted this test for various settings of a the client interpolation delay setting (cl_interp), I started testing using cl_interp 0.01 to 0.04, now the results of these tests were all linear, the distance increased at the same rate from 0.01 to 0.002 to 0.03 to 0.04, so I drew the line much further ahead to 0.1, conducted the exact same test again, and received an accurate result where the calculated and the tested results were a fairly accurate match.
cl_interpolate 1; cl_interp 0.01
Average offset out of 9 samples; 107.89px
cl_interpolate 1; cl_interp 0.02
Average offset out of 9 samples; 122.00px
cl_interpolate 1; cl_interp 0.03
Average offset out of 9 samples; 136.78px
cl_interpolate 1; cl_interp 0.10
Average offset out of 9 samples; 233.11px
However if I were to draw the line back to the other side, to a cl_interp of 0 (currently not an option), I do not end up without a distance between server and client location of this player. So I went to calculate:
If an increment of 0.01 second lead to an increment of 14.11 pixels, a decrease to a theoretical cl_interp of 0 would match an offset of 93.78 pixels remainder, since we earlier calculated that 0.01 second translates into a distance of 14.11 pixels, we can tell that 93.78 pixels match ~0.066 seconds ( (93.78/14.11) * 0.01 = 0.06646).
To those that hadn't gotten it yet, this means that the delay used by your computer is not just your network latency and your cl_interp put together, there is also an extra of 0.066 seconds added on top of this (might not seem like much, but 'in-game' this translates into more time than you would imagine.
That pretty much describes the first issue (cl_interpolate 1), now to explain the cl_interpolate 0 issue;
This issue is a lot harder to really explain, however much easier to witness, and research is relatively easily conducted, first I'll explain how you can replicate the results of the test I conducted, the method I'm describing is NOT to be used as evidense, this is merely a 'try and see for yourself' walkthrough.
Create a listen server, add a bot, enable sv_cheats and enable bot_stop, get an accurate weapon (preferably the fiveseven), find the bot, mp_friendlyfire 1, type cl_interpolate 0 in console, and type 'bot_mimic_yaw_offset 360', and 'bot_mimic 1' in console, these will make the bot do exactly as you do. Start straving in a sideways fashion while facing the bot, put your crosshair on his head while straving, and shoot. Now put your crosshair slightly behind the head of the bot (if you're moving to the right side, put it at the left side of the head(besides the head)), strave again, and shoot, you should see a blood splatter apear. This is the problem at hand. You can replicate the exact same test on a regular dedicated server with humans, I did this aswell and received these results:
http://www.booom.co.uk/downloads/cl_interpolate0.zip
Personally I expect that this is related to the 0.066 issue existing with cl_interpolate 1, however I have no real evidense to back this up, its pure speculation. What I do know, and stands unquestionable in my mind is that there is an issue with the current hitregistration behaviour of the netcode when interpolation is disabled. For reference, there used to be a bug in the netcode that caused servers to be unaware of whether players use interpolation, this bug is currently fixed, the server will know when a client is not interpolating, and it will entirely ignore the value of a players cl_interp in hitregistration calculations when the player is not interpolating.
I am one of the many followers of TUFs ideas
don't ban me, i'm just trying to share what he has to offer.
Counterstrike source netcode
- The final quirks.
Disclaimer
This article describes the current issues that the netcode still has underspecific clientside and serverside net related convars. This is NOT a repeat of any video that has been proven incorrectly 10 times over already, this is not a complaint about receiving poor hitreg, this is an article backed up by evidense and test scenario's for you to try out.
Index
1. Explanation of the current concept of the counterstrike source netcode.
2. Explanation of the current issues with the current implementation of this netcode.
Current netcode concept.
The counterstrike source netcode is made under the assumption of many worst case scenario's, however also with flexibility in mind. For example, the default setting of client interpolation delay is enough to support a connection losing 2 out of every 3 packets of data.
With that in mind I'll first link to a reference link of what valve has to say about the netcode:
http://www.valve-erc.com/srcsdk/gen...networking.html
Let's start explaining what many people here are simply reading past or not understanding.
First of all, to do it's work the "counterstrike source client netcode" (How your computer deals with all the stuff it receives from the server), uses a delayed interpolation system, now don't worry, I'm going to explain what that means to you. Because the source netcode is made for such worst case scenarios, it only assumes the player being abled to receive an update from the server approximately 30 times per second, now this might sound like a lot to you, but wour computer wants to know a lot more than this. For example, if you have an avarage of 50 frames per second, 30 updates per second is going to be 20 too few. For example, a player is running from the left side of your screen to the right side of your screen, with 30 updates per second at 50 frames per second, the player is going to move in 1 frame, and appear to be standing still in the next, this is definitly not what we want.
To counter this effect, your computer wont immediatly show you something as soon as you receive the data, instead it buffers the data for a short time delay (By default this is 0.1 seconds, however the duration of the time this data is being stored for before being displayed can be changed using your cl_interp command), during this time delay your computer will receive more information from the server, now once your computer starts displaying the information it received first, it already knows whats going to happen next, because your computer knows this, it can create a smooth transition between the 2 pieces of information.
This is basically what it all comes down to, waiting to receive more information so you can make an educated estimate of what happened in between these points in time.
Now most of this can be modified (and should be if you're planning to play in a competitive enviroment), I'll mention the most important: For good results, a lot needs to be modified, for example, a default server will only render the world events 33 times per second (tickrate), in order to increase your information throughput you need to increase the server tickrate. Now once the tickrate has been increased (maximum of 100, default of 33), you can change settings like the amount of datapackages you wish to receive from the server(cl_updaterate), the amount of bandwidth you're willing to set available for this(rate), the amount of datapackages you're willing to send to the server(cl_cmdrate), and how long you wish for your computer to wait and buffer information before actually displaying it (cl_interp), all of these convars need to be set with a good relation to one and eachother, for example if you wish to receive a lot of updates from the server, yet set a low amount of bandwidth available for this, you will receive 'choke'.
Now you may be thinking, if someone I'm seeing on my screen was actually there a little time ago, is that why I miss when I shoot him? The anwser is no, in most scenarios you just missed, in others there are more complicated issues that I'm not going to go through in the first post, however might go through if asked about. Why the anwser is no? The server keeps track of the relavant settings to netcode for each client, When you shoot a bullet, it doesn't just check when you shot it, it also checks how much network latency you're receiving on average, and it checks to see what you would have been seeing when you fired your bullet, in other words it looks at the time it received notice about you firing your bullet, than it goes back in time to where you shot your bullet on your computer (network/internet latency), than it checks your cl_interp value (or the time you were visually delayed by) and goes back in time that much extra, using this information the server can check whether the bullet you fired should hit anyone or not.
To all of those who've seen the "hitboxes are off" video's going around on the net, what these video's display is not faked, it will display like that, however the hitboxes you're seeing is not the hitboxes that the player has, the player has no hitboxes, only the server does, they are the hitbox locations of the server, this means that cl_interp will not delay them in any way, this also means that shooting them will do you no good, as the server will still reduce network latency and interpolation delay from your bullet firing time to make its hitregistration checks.
Issues with the current netcode implementation.
There are currently 2 large issues still present in the counterstrike source netcode, 1 of them only occurs with clientside interpolation entirely disabled (cl_interpolate 0, not default), and the other (however, far less significant) with interpolation enabled (default).
I'll start with the issue existing when interpolation is enabled, this all started when Drax, a former CAL - Invite player posted up his wishlist of what counterstrike source should become, it included a short video displaying evidense that when interpolation is enabled, the delay was actually a lot longer than the delay set by cl_interp. This can be found here:
http://www24.brinkster.com/draxus99/source/
Now a lot of people have questioned his method of synchronising both parts of the video, so have I, as a mather of fact, I went ahead and asked drax myself. His anwser? He used the in-game clock to synchronise them. Personally I'm not entirely sure of how accurate this clock is, so I conducted my own share of research.
Here's what I did, since we are testing clientside interpolation, something servers have nothing what-so-ever to do with, we can even test this in a listen server enviroment, and if you really need to, you could even use a bot to conduct this test (As for the purpose of this test, the results are exactly the same, interpolation simply works exactly the same). What I did was, I created a server, joined spectators, and had someone else join the counterterrorist team. I went to his side at a perfect 90 degree angle, enabled the 'hitboxes' (to display the server location of the player), and took screenshots of the player running forward in a perfect straight line, I took multiple samples so I could read the average, for the most accurate readings.
The results can be found here:
http://www.booom.co.uk/images/netcode/
I conducted this test for various settings of a the client interpolation delay setting (cl_interp), I started testing using cl_interp 0.01 to 0.04, now the results of these tests were all linear, the distance increased at the same rate from 0.01 to 0.002 to 0.03 to 0.04, so I drew the line much further ahead to 0.1, conducted the exact same test again, and received an accurate result where the calculated and the tested results were a fairly accurate match.
cl_interpolate 1; cl_interp 0.01
Average offset out of 9 samples; 107.89px
cl_interpolate 1; cl_interp 0.02
Average offset out of 9 samples; 122.00px
cl_interpolate 1; cl_interp 0.03
Average offset out of 9 samples; 136.78px
cl_interpolate 1; cl_interp 0.10
Average offset out of 9 samples; 233.11px
However if I were to draw the line back to the other side, to a cl_interp of 0 (currently not an option), I do not end up without a distance between server and client location of this player. So I went to calculate:
If an increment of 0.01 second lead to an increment of 14.11 pixels, a decrease to a theoretical cl_interp of 0 would match an offset of 93.78 pixels remainder, since we earlier calculated that 0.01 second translates into a distance of 14.11 pixels, we can tell that 93.78 pixels match ~0.066 seconds ( (93.78/14.11) * 0.01 = 0.06646).
To those that hadn't gotten it yet, this means that the delay used by your computer is not just your network latency and your cl_interp put together, there is also an extra of 0.066 seconds added on top of this (might not seem like much, but 'in-game' this translates into more time than you would imagine.
That pretty much describes the first issue (cl_interpolate 1), now to explain the cl_interpolate 0 issue;
This issue is a lot harder to really explain, however much easier to witness, and research is relatively easily conducted, first I'll explain how you can replicate the results of the test I conducted, the method I'm describing is NOT to be used as evidense, this is merely a 'try and see for yourself' walkthrough.
Create a listen server, add a bot, enable sv_cheats and enable bot_stop, get an accurate weapon (preferably the fiveseven), find the bot, mp_friendlyfire 1, type cl_interpolate 0 in console, and type 'bot_mimic_yaw_offset 360', and 'bot_mimic 1' in console, these will make the bot do exactly as you do. Start straving in a sideways fashion while facing the bot, put your crosshair on his head while straving, and shoot. Now put your crosshair slightly behind the head of the bot (if you're moving to the right side, put it at the left side of the head(besides the head)), strave again, and shoot, you should see a blood splatter apear. This is the problem at hand. You can replicate the exact same test on a regular dedicated server with humans, I did this aswell and received these results:
http://www.booom.co.uk/downloads/cl_interpolate0.zip
Personally I expect that this is related to the 0.066 issue existing with cl_interpolate 1, however I have no real evidense to back this up, its pure speculation. What I do know, and stands unquestionable in my mind is that there is an issue with the current hitregistration behaviour of the netcode when interpolation is disabled. For reference, there used to be a bug in the netcode that caused servers to be unaware of whether players use interpolation, this bug is currently fixed, the server will know when a client is not interpolating, and it will entirely ignore the value of a players cl_interp in hitregistration calculations when the player is not interpolating.
