Trailing Hitboxes
Sarisel
.::' ( O ) ';:-. .-.:;' ( O ) '::. Join Date: 2003-07-30 Member: 18557Members, Constellation
.::' ( O ) ';:-. .-.:;' ( O ) '::. Join Date: 2003-07-30 Member: 18557Members, Constellation
<div class="IPBDescription">An explanation for the masses</div> The hitbox trailing three feet or so behind the target is not a result of lag or a bug in the game, as is the popular belief.
It is instead related to Half-Life netcode and the majority of ns servers being run with a maximum updaterate of 30. In addition, NS is faster than most other HL mods out there - if not the fastest.
A vanilla skulk alone starts at a maximum running speed of about 300 units/s. With a maximum updaterate of 30 frames/s*client from the server. Because the way the server updates the client about position is not a fluid continuous motion (unlike what you see while playing), the frames that you get will be inaccurate. In fact, the skulk will actually be warping from one point to the next, with one point being 10 units apart from the next per each frame (300/30).
What you see on your screen is simply the smoothed out interpolated/extrapolated motion, which is client side only and doesn't really matter for hit detection. It is doubtful if you would enjoy playing HL or any of its mods if the server information was transfered directly to your client - in other words, everything would teleport and look ridiculous for a client playing on the average server with its low FPS and maxupdaterate.
In addition to the warping motion of the target, the server has to receive information from that target client - which depends on their cmdrates. My take is that, if the target client sends only 15 updates per second (which is the default rate for cmdrate as far as I remember), then half of the server's updates (running at maxupdaterate of 30) to the other clients will not involve the corrected positions of that player with the low cmdrate. That means that the average skulk's hitbox could trail up to 20 units behind/frame before it gets updated.
To see if my calculations are reasonable, I went and checked what 300 units meant. Then I divided that distance by 10 to get around 30 units. I checked the distance in-game and this is what I found - a comparison to distance on ns_origin so you can get an idea for what the distance scale is. It looks pretty reasonable.
<img src='http://img100.exs.cx/img100/9069/300units.jpg' border='0' alt='user posted image' />
Remember, all these calculations are for the average skulk's lagged hitbox - which would be 10 to 20 units behind it's model (1/3 or 2/3 of 30 units on image). For other lifeforms, you can use similar calculations to find the average lag of the hitboxes behind the player. When I say "behind", I mean in the opposite direction of the player's motion - the exact calculation in complex motions may vary.
Perhaps I am wrong with some of the calculations, but this seems to make sense.
It does not have to do with lag compensation, which is felt by the player being attacked by the client who gets the compensation. For lower pings, I'd pin the issue on this.
This is just a rough idea, so I'll go over it later to see if it is completely ridiculous. Or somebody can point it out to me. Either way, the topic is meant to help people understand why the hitboxes lag behind the players. It is not the developers' fault, it is not a bug in the game. It has to do with the netcode, rates, server quality, and connection speeds.
edited: the distance on the image may not be exact, since the distance from the point of view to the line creates the effect of decreasing the size of the line. Think of it like looking down a corridor - where further down the corridor the heights and widths of the walls, floors, and ceiling decrease.
It is instead related to Half-Life netcode and the majority of ns servers being run with a maximum updaterate of 30. In addition, NS is faster than most other HL mods out there - if not the fastest.
A vanilla skulk alone starts at a maximum running speed of about 300 units/s. With a maximum updaterate of 30 frames/s*client from the server. Because the way the server updates the client about position is not a fluid continuous motion (unlike what you see while playing), the frames that you get will be inaccurate. In fact, the skulk will actually be warping from one point to the next, with one point being 10 units apart from the next per each frame (300/30).
What you see on your screen is simply the smoothed out interpolated/extrapolated motion, which is client side only and doesn't really matter for hit detection. It is doubtful if you would enjoy playing HL or any of its mods if the server information was transfered directly to your client - in other words, everything would teleport and look ridiculous for a client playing on the average server with its low FPS and maxupdaterate.
In addition to the warping motion of the target, the server has to receive information from that target client - which depends on their cmdrates. My take is that, if the target client sends only 15 updates per second (which is the default rate for cmdrate as far as I remember), then half of the server's updates (running at maxupdaterate of 30) to the other clients will not involve the corrected positions of that player with the low cmdrate. That means that the average skulk's hitbox could trail up to 20 units behind/frame before it gets updated.
To see if my calculations are reasonable, I went and checked what 300 units meant. Then I divided that distance by 10 to get around 30 units. I checked the distance in-game and this is what I found - a comparison to distance on ns_origin so you can get an idea for what the distance scale is. It looks pretty reasonable.
<img src='http://img100.exs.cx/img100/9069/300units.jpg' border='0' alt='user posted image' />
Remember, all these calculations are for the average skulk's lagged hitbox - which would be 10 to 20 units behind it's model (1/3 or 2/3 of 30 units on image). For other lifeforms, you can use similar calculations to find the average lag of the hitboxes behind the player. When I say "behind", I mean in the opposite direction of the player's motion - the exact calculation in complex motions may vary.
Perhaps I am wrong with some of the calculations, but this seems to make sense.
It does not have to do with lag compensation, which is felt by the player being attacked by the client who gets the compensation. For lower pings, I'd pin the issue on this.
This is just a rough idea, so I'll go over it later to see if it is completely ridiculous. Or somebody can point it out to me. Either way, the topic is meant to help people understand why the hitboxes lag behind the players. It is not the developers' fault, it is not a bug in the game. It has to do with the netcode, rates, server quality, and connection speeds.
edited: the distance on the image may not be exact, since the distance from the point of view to the line creates the effect of decreasing the size of the line. Think of it like looking down a corridor - where further down the corridor the heights and widths of the walls, floors, and ceiling decrease.
Comments
I don't believe the cl_cmdrate is really a correction. The whole point of the explanation is that low cl_cmdrates would force the server to deal with that player's cmdrate and this could cause more hitbox lag. The server gets less information per second about the player's positions, thus it has less information to send out about that palyer's position.
The FPS factor is something I forgot to mention, but I assumed that an average server had more than 30FPS on average throughout the game. I don't have the details about that, but perhaps other people do. Fluctuations in server FPS cause fluctuations in how hits are registered, as you can tell on large servers when hitting fast moving players becomes a nightmare.
You could probably come up with an equation to represent the perceived hitbox lag depending on server to client updaterate, target to server cmdrate, target's speed, and ex_interp of client.
The ex_interp cvar is only used for network code, but not for a player's model displayed on a client's screen. When the client receives the other player's position from the server, it will smooth out his hull and hitboxes' movement for "<i>ex_interp value</i>" second(s) towards the latest position of the player that the client has received from the server considering the speed and direction that the player had in the first update. This is like the player going from point A to point B (those points are the 2 last updates received from the server). If he goes at 300 units/second when the client received the update of point A, it will be the speed his hull and hitboxes will go at towards point B <u>after point B has been received</u> by the client.
Then, ex_extrapmax cvar will do a prediction of the position of the other player's hull and hitboxes' position for "<i>ex_extrapmax value</i>" second(s). That prediction will be based on the player's speed and direction from the latest update received from the server.
But the moving player models that you can see on your screen have their position determined by other client cvars: cl_smoothtime (0.1) and cl_vsmoothing (0.05), which I'm entirely sure of the way they work. The cl_smoothtime cvar would, I believe, act just like ex_interp, except that it would set the position, speed and direction of the <u>player's model</u> on the client's screen depending on the last 2 updates received from the server (just like ex_interp). I'm really not sure about the cl_vsmoothing cvar, but I would imagine that it is a kind of completion to cl_smoothtime that is sequenced for the next update received from the server after cl_smoothtime, as if both were sequenced one after the other to update more quickly, but I don't really have an idea. You could try setting these two cvars to lower or higher values and keeping the default 2:1 ratio between them. I'm guessing that lower values of these two cvars would be better for low ex_interp values.
Now we can understand that all of these cvars depend on cl_updaterate and cl_cmdrate. The predictions are supposed to compensate for the low amount of updates that certain players may send or receive, but this could be the cause of this problem.
Bad values of these could perhaps explain some kind of "lag" with player models and hitboxes... that is if my theory is right. I myself don't think that I am currently experiencing this problem, but I believe that since everybody can have different values from these cvars, the problem possibilities are multiple depending on many circumstances such as the server's latency, the server FPS, the player's latency... his cl_cmdrate? I'd say very possibly, but I could likely be wrong too.
Right now I can't really think of any other way for the hitboxes to "lag". The only way I can see it happening would be if the server's recorded position for the target's hitboxes is behind the client-side predicted location of the target's hull & hitboxes.
This is the only scenario that seems to make immediate sense, since slower targets would have smaller predicted position changes while faster targets will have larger predicted position changes - which is what is observed with laggier hitboxes belonging to faster moving players.
So, the smoothing variables could have something to do with it. Perhaps extrapolation is a factor. However, all of these simply try to smooth out the game so that it doesn't hurt your eyes to play it. If you set ex_interp to 1/cl_updaterate and ex_extrapmax to 0 (if I remember correctly, this should stop any smoothing, right?) then you should see the exact locations of the hitboxes as provided by the server's updates to the client. If you manage to connect with those hitboxes before the server receives a new update from the target (a cmdupdate) and updates it to a different position, you'd cause damage. With smoothing, where you aim is not necessarily the best place to aim.
<a href='http://www.unknownworlds.com/forums/index.php?showtopic=82358' target='_blank'>http://www.unknownworlds.com/forums/in...showtopic=82358</a>
Hopefully some of my experience over the past few months can help:
I am very picky on hits actually registering and have been watching and looking at how different variables (server side and client side) effect the "hit box lag" and have found that the major factors in this are:
1. Server performance under load (FPS)
2. cl_updatrate
3. cl_cmdrate (of yourself)
4. cl_cmdrate (of the player you?re engaging)
At one time the combat server I run had 20-22 slots and when it became about full I noticed that everyone?s pings where about 10-25 higher than when there were fewer people. Also server fps dropped to about 40-70. Now the funny thing is the server ran fine, there were no spikes to 300+ so it seemed to be running fine, except for the appearent lagging hitbox. Slowly I began to remove slots until fps of the server was consistantly 90+, this was at 16players. This combined with an uncapped cl_updaterate seemed to have helped a bunch, though still at the mercy of those who have a low cl_cmdrate.
Now I'm <b>not at all</b> saying this is an answer but it may provide some additional information.
I'm very willing to help you test this/provide a server for testing.
*EDIT*
Head crab you are correct about how the server cannot effect a players cl_cmdrate. Although I have asked a dev for this and it has been added into mantis. <a href='http://www.natural-selection.org/bt/bug_view_advanced_page.php?bug_id=0000742' target='_blank'>http://www.natural-selection.org/bt/bug_vi...?bug_id=0000742</a>
Sarisel if you want to remove client prediction I believe it is cl_lc 0. Though what you have proposed should have the same effect.
You could come up with optimal settings for an NS server and advertise that, since most of the servers currently running are not configured well. With your current testing, you already have data about the effects of the rate variables. Whether you want to go further than that and learn more is up to you.
As far as I am concerned, this will be my final post in my final thread. My future is elsewhere.
Pretty much the feeling almost everyone is getting when it comes to the future of natural selection.
Head crab you are correct about how the server cannot effect a players cl_cmdrate. Although I have asked a dev for this and it has been added into mantis. <a href='http://www.natural-selection.org/bt/bug_view_advanced_page.php?bug_id=0000742' target='_blank'>http://www.natural-selection.org/bt/bug_vi...?bug_id=0000742</a> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
The reason valve has not allowed a server to set a limit directly on cl_cmdrate is because lower values of it should not penalize any other player than the player with a low value himself.
It's just like when a player "lags out", as if he were not sending any update to the server for a few seconds : you can still shoot him and kill him, while he has no idea of what is happening, and then he will find out that he is dead after a few seconds.
If he is not sending the update quickly enough, as if he had a cl_cmdrate of 10, the server will still send you his "theoric" position with the prediction system, which is accurate <u>from the server's point of view</u>, and the server's point of view is all that should count for you.
On the other hand, if a player is not sending updates quickly enough in a situation where 2 players would shoot themselves at the same time (one with a low cl_cmdrate and one with a high cl_cmdrate), from a reality point of view, not from the netcode, the one with the fastest cl_cmdrate will register the kill first and the server will not recognize the the shot of the dead player. That's just another disadvantage
Sarisel: goodbye (again?), but I'd just note that I do believe that this "problem" is specific to what values each client use. That would mean that it's up to them to find what is best for them by doing tests on their own and by playing on servers that are responding well to their configuration.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> the server will still send you his "theoric" position with the prediction system<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The server doesn't send theoretic positions, it only sends you the known position which is updated at the frequency of cl_cmdrate. The gaps inbetween the updates is what the client predicts which can be very different once the next update has been recieved from the server.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->The reason valve has not allowed a server to set a limit directly on cl_cmdrate is because lower values of it should not penalize any other player than the player with a low value himself.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
This is also because none of the games that valve supports has hitboxes/players moving at the speed of a leaping celerity skulk. The maximum speed of a DOD/CS player isn't anything more than a vanilla skulk which rarely has this problem.
I have tested the effects of having a low cl_cmdrate and have seen that hit registration doesnt occur how it should. I am willing to show you.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->but I'd just note that I do believe that this "problem" is specific to what values each client use. That would mean that it's up to them to find what is best for them by doing tests on their own and by playing on servers that are responding well to their configuration.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I am with you on this, it isn't the fault of valve or NS dev team but rather the players education on these values and how to properly set them. Though I think this responsibility should be handed to the server operators.
What might be worthwhile is to make a set of config files, one for every type of connection (good cable, saturated cable, good ISDN, etc.), and put the correct settings for it inside. All a player would have to do is exec the file, and it would take the guesswork out.
Anything you can do from server side is even better, but this should help.
Are you sure about that? What would lag compensation, being server-side, do then? I would believe that the server is sending both theoric coordinates of a player taken from the lag compensation system and also his latest coordinates that he has sent to the server. That would be because players have the choice to turn off lag compensation if they wish. But remember our friend called the PSHB ( <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html//emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif' /><!--endemo--> ), the server did not send the right lag compensated position of the player with the last slot, but it only sent the position he was sending to the server.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This is also because none of the games that valve supports has hitboxes/players moving at the speed of a leaping celerity skulk. The maximum speed of a DOD/CS player isn't anything more than a vanilla skulk which rarely has this problem.
I have tested the effects of having a low cl_cmdrate and have seen that hit registration doesnt occur how it should. I am willing to show you.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Yes, but how could that example be representive of this "problem" considering that you use a specific ex_interp, ex_extrapmax, cl_smoothtime, cl_vsmoothing and that the server you had played on had a specific sv_maxupdaterate, sv_maxrate and that it had a certain amount of FPS at the time that you have played.
This whole system can only work correctly if both the server and the client has the required resources to work the way it was planned to work. What would be the point of having a cl_updaterate of 50 on a server that has its limit set to 30? Or even what would be the point of having a cl_updaterate of 30 when the server doesn't even get 30 FPS? When you are in a situation like that, some problems are to be expected, it's just like I couldn't run Call of Duty on my 4.86 for all the reasons of the world...
taboofires: we just can't set a default value for everyone simply because they won't all play on the same servers and they don't have the same amount of bandwidth and the same amount of FPS when playing... The only solution that would work is a built-in system that would be both server-side and client-side that would consider the amount of bandwidth set by the player in a most simple as possible configuration window and his amount of FPS, but the problem is that these are not always stable. The client's configuration would then have to be set automatically considering the server's limits. But that won't happen anyhow, why would valve lose their time on something that will not give them profits...
I think this is a good idea. There should be a choice in the installation program that determines which config is used by default. It wouldn't be perfect, but it would be a whole lot better than the default settings.
I went back to check up on that fix that valve did for PSHB bug and the news item is gone. I'm not sure why, but the update occured between 8/1/04 - 8/15/04.
Maybe your are correct but I'm pretty sure the PSHB bug was't a HLDS update but rather a client update. I could be wrong because I'm unable to find the news item.
Maybe someone with a bit more knowlege can weighin on this subject.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->taboofires: we just can't set a default value for everyone<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Isn't that what is currently happening?
Edit: oh and yes... the PSHB was updated via a Steam update for servers. If I remember correctly, it was at the beginning of August. But it created a lot of confusion considering that HLDS servers were not automatically being updated by Steam, as opposed to Steam servers. So HLDS servers had to update using the update tool provided with the installation files, but some servers had not updated and remained outdated with the PSHB. At the time, I had made a whole well explained post about it, but I doubt more than 10 persons actually saw it.
Edit 2: here are even some of my rather unsuccessful attempts to make people understand why the PSHB remained on some servers:
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=1&t=77529&hl=&view=findpost&p=1187289' target='_blank'>Thread: Pshb Gone.</a>
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=1&t=77594&hl=&view=findpost&p=1190751' target='_blank'>Thread: Pshb Not Gone?</a>