Having trouble accessing the forums? Try logging out of the forums completely - clear cache, cookies, and temp files - then restart the browser and log in. Thanks!

Hit Detection

Comments

  • stuwooster
    260 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    VBALL_MVP wrote: »
    stuwooster wrote: »
    As an interesting side note, my skill level seems to have risen 40-50 points in the past week along with an increase in SPM, could this be related?

    Skill is 60% calculated from SPM.

    I was more meaning related to things feeling better for me performance wise
  • Rev0verDrive
    3665 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    mmarkweII wrote: »
    mischkag wrote: »
    @Rev0verDrive: The next patch will lower the FHT for soldiers from 125ms to 100ms and above 100ms, server side hit detection is performed for High pingers which is way more powerful than clamping the frame history. With this recent patch i changed the server side arbitration so that hits on your client on extrapolated soldiers will still count unless you are a high pinger.

    I'm really curious as to what the "Studio" considers to be a high ping? It's absolutely different for each platform do to the tickrate. To me it's when player data is not received by the server and processed with in 2-3 cycles, excluding packet loss. The less extrapolation the client has to do the better the overall performance. Same for the server when authenticating hits.

    I'm guessing there are differences of opinion about what constitutes as "high ping" from everyone from MS/Sony, to publisher (EA), to dev (DICE, ubisoft, Activision, etc) to players around the world. Not having a go with you at all, just trying to help others understand the issues, as you have always brought forth great insight for discussions. Cheers :)

    There will always be differences in opinion on what a high ping is. It varies between games and genres. But from a technical standpoint in relation to a very specific way a piece of software calculates outcomes, there has to be a predefined ceiling. I don't expect DICE to come out and say what they consider a high ping to be. The answer would alienate a large sector of the purchasing community and potential purchasers. Regardless of what it is. But the tickrate in itself says a great deal, as does the FHT.

    The entire purpose of increasing a tickrate is to increase the accuracy in player positioning on screen. The more updates a second you get about a players position, the smaller the adjustments in that position you have to render, thus lowering the amount of extrapolation (prediction).

    As the tickrate goes up, the client latency must go down for there to really be an optimum improvement. Regardless of latency, there is an improvement, yet it's very marginal if the latency of the majority isn't in sync with the tick.


    The client time logs your actions (WASD, paddle forward, jump etc) and sends them to the server. The server processes them (logs them in it's timeline) and sends them in the next update to the other clients. Your client gets the update containing the latest "received" actions of all the other players. It syncs them in its version of the timeline and renders corrections and then extrapolates the future actions of each player. The extrapolation is based on the very last received action of said player. If it was "W"/"Paddle Forward" it will continue assuming a "Forward" movement in the last known direction. The following update get's received and corrections are made. etc and so forth.

    I mentioned "cycles" in my previous post. These are the ticks. You know this but some might not, so I'm going to explain it.

    30Hz means 30 updates a second. There are 1,000 milliseconds (ms) in a second (s). The amount time between ticks is known as the tick interval.

    1000 / 30 = 33.3333ms (30Hz tick interval)
    1000 / 60 = 16.6666ms (60Hz tick interval)

    With a 30Hz server, a tick update is sent every 33.3333ms. The time it takes to get from you to the server is based on your distance from the server and the route the packet takes to get there. Your "Ping" is a representation of that "round trip" travel time, from you (client) to the server and then back. Tick updates are one way, thus the travel time is only 50% of your ping time.

    A 200ms ping has a 100ms packet/update travel time (UTT). A 30ms ping has a 15ms UTT.

    Server Ticks (30Hz): 0.00ms ~ 33.33ms ~ 66.66ms ~ 99.99ms ~ 133.32ms ~ 166.65ms ~ 199.98ms ~ 233.31ms ~ 266.64ms ~ 299.97ms ~ 333.3ms .... etc

    If I have a 30ms ping, data sent at 0.00ms gets to the server 15ms later, and is processed, then sent in the very next tick at 33.33ms (tick 2).

    If I have a 200ms ping, data sent at 0.00ms gets to the server 100ms later, and is processed, then sent in the very next tick at 133.32ms (tick 5).

    Note with the above that the 200ms player will receive the 30ms players first update info at the 133.33ms mark in the timeline. Whereas the 30ms will receive the 200ms players first update info at the 148ms mark.

    Yes, That's correct even though it doesn't make first-glance sense. The high ping players view (extrapolated rendering) of the low ping player is technically/mathematically more accurate than the lows view of the high.

    This, in my opinion, is the reason why the Infantry FHT is being tweaked in the manner that it is. A hard clamp would make multiplayer unaccessible to a large majority of players. Yet, at some point DICE will have to explain this change in detail and in layman's so the majority understand it correctly.
  • mischkag
    135 postsMember, Developer
    @Rev0verDrive: Nice writeup :) Mostly it is correct.
    As far as the tickrate goes. Higher tickrate means:
    Upside:
    - More fidelity and accuracy for the game sim
    - Higher input sampling and therefore faster response time (less sluggishness)
    - More networking update frequency and therefore faster send of your inputs to the server as well as faster receiving of any state change (hits, damage, players..)
    -> Like you said: less in game latency on top of your networking latency
    Downside:
    - More stress on the server performance (higher networking send rate, higher game sim rate)
    - More stress on the client performance (30 vs 60: 60 sim frames vs 30 sim frames and 30 interpolation/visual frames)
    - Therefore it cannot run for 64 players on consoles :(
    - More requirement of stable pings of all players
    - We need to ideally always receive one input per tick per player, once we miss them, my buffering comes into play but it also means less updates for all other players -> extrapolation

    There is a differentiation of vehicles and soldiers in the game as far as extrapolation and missing input handling goes. But in general you are right, when data is missing you assume no change and extrapolate with it (for vehicles there is some 2nd order extrapolation but thats beside the point here).
    Bottom line is: 60 Hz makes it much more responsive but is more error prone to high pingers :( Also server spikes have a higher negative impact as more (ideal/expected) frames are affected.

    Therefore it is not as easy as just enabling 60 across the board. You dont want to make it worse.
    As far as the FHT goes. Basically we have client side hit detection and server side arbitration. So simiplified: the server simulates a given bullet at the same time the client simulated a given bullet resulting in a certain damage hit. That very time is clamped. So a high pinger shooting at 150ms latency, gets its bullet simulated at clamped 100ms on the server. That means the world was already 50ms further ahead in terms of time, than the bullet was simulated with at the high pingers client. However, the server does a very coarse arbitration test which will see the clamping of FHT almost to no effect up until 300ms latency. To counter this, i implemented full server side accurate hit detection for anything beyong 100ms. So instead of running client side hit detection, they run server side hit detection with whatever is currently the state of the world on the server. So they have to extrapolate in their head and lead the shot. That also eliminates shooting around corners as the shot will be blocked. It does not fully switch from 100ms to 0 latency and rather interpolate softly, but it should be a major milestone and discourage players over 100ms to deliberately play OOR.
  • KingTolapsium
    4525 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member
    edited March 17
    Will the serverside hit detection have any effect on a high pingers "peeking advantage"?
  • Rev0verDrive
    3665 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    mischkag wrote: »
    @Rev0verDrive: Nice writeup :) Mostly it is correct.
    As far as the tickrate goes. Higher tickrate means:
    Upside:
    - More fidelity and accuracy for the game sim
    - Higher input sampling and therefore faster response time (less sluggishness)
    - More networking update frequency and therefore faster send of your inputs to the server as well as faster receiving of any state change (hits, damage, players..)
    -> Like you said: less in game latency on top of your networking latency
    Downside:
    - More stress on the server performance (higher networking send rate, higher game sim rate)
    - More stress on the client performance (30 vs 60: 60 sim frames vs 30 sim frames and 30 interpolation/visual frames)
    - Therefore it cannot run for 64 players on consoles :(
    - More requirement of stable pings of all players
    - We need to ideally always receive one input per tick per player, once we miss them, my buffering comes into play but it also means less updates for all other players -> extrapolation

    There is a differentiation of vehicles and soldiers in the game as far as extrapolation and missing input handling goes. But in general you are right, when data is missing you assume no change and extrapolate with it (for vehicles there is some 2nd order extrapolation but thats beside the point here).
    Bottom line is: 60 Hz makes it much more responsive but is more error prone to high pingers :( Also server spikes have a higher negative impact as more (ideal/expected) frames are affected.

    Therefore it is not as easy as just enabling 60 across the board. You dont want to make it worse.
    As far as the FHT goes. Basically we have client side hit detection and server side arbitration. So simiplified: the server simulates a given bullet at the same time the client simulated a given bullet resulting in a certain damage hit. That very time is clamped. So a high pinger shooting at 150ms latency, gets its bullet simulated at clamped 100ms on the server. That means the world was already 50ms further ahead in terms of time, than the bullet was simulated with at the high pingers client. However, the server does a very coarse arbitration test which will see the clamping of FHT almost to no effect up until 300ms latency. To counter this, i implemented full server side accurate hit detection for anything beyong 100ms. So instead of running client side hit detection, they run server side hit detection with whatever is currently the state of the world on the server. So they have to extrapolate in their head and lead the shot. That also eliminates shooting around corners as the shot will be blocked. It does not fully switch from 100ms to 0 latency and rather interpolate softly, but it should be a major milestone and discourage players over 100ms to deliberately play OOR.

    Nice! Thanks for the reply. I tried to keep it as layman as possible.
    We need to ideally always receive one input per tick per player, once we miss them, my buffering comes into play but it also means less updates for all other players -> extrapolation
    There's always extrapolation. To what degree, "How much" from my understanding is based on the current game time and last received "known" data about X player. If there's nothing for 3 ticks I have to extrapolate for 3 ticks client-side. Thus, my hard clamp point. If we are getting "one input update per tick, per player", wouldn't this improve performance overall?

    Single item input per player. Only so many commands can be input by a player in 16.66ms. Less processing of inputs in the packet. One input command is easier to process (less resources needed) vs 2-4 per packet. Thus, Less read/write, and smaller packets size sends. I get that if you are doing a lookup for a player it's smarter to pack as much data as possible into the update while you have the ID queued. Say from the point of an array update. But overall isn't 64 calls/lookups every 16.66ms, adding 1 input faster and less resource intensive than the alternative?

    As far as the FHT ...
    Just for clarity/Layman's for others reading this. "Unless you specifically state it, it will be misconstrued."
    Does the server still arbitrate (authenticate) hits regardless player latency?
  • VBALL_MVP
    2442 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member
    stuwooster wrote: »
    VBALL_MVP wrote: »
    stuwooster wrote: »
    As an interesting side note, my skill level seems to have risen 40-50 points in the past week along with an increase in SPM, could this be related?

    Skill is 60% calculated from SPM.

    I was more meaning related to things feeling better for me performance wise

    Sorry...my bad
  • mischkag
    135 postsMember, Developer
    @KingTolapsium: What do u mean with ''peaking advantage"?
    @Rev0verDrive: There is ideally in fact NEVER extrapolation. The client does not try to guess where the player is at a very moment on the server and rather tries to stay timewise as clsoe as it the latency allows to the server and processes all entities within known spatial properties. I dont want to move any soldier where it has never been unless i am forced to guess due to missing inputs. The more fluctuating your own connnection, the more conservative i have to pad to ensure interpolation. Hence the NetGraph entry: Extrapolation offset. Of course it is faster to process always just one input, but you have to average that over all layer connections and it does not matter there in terms of raw performance if i update 2 inputs for one player and none for the other and the next frame vice versa or always 1 for each. But there is a clamping which i reduced to the max number of inputs you are allowed to not send until i insert dummy ones. So a very jittery player will perceive Rubberbanding caused by this. But this prevents even more teleporting on all other player screens.
    I dont quite understand your question at the end about "Does the server still arbitrate (authenticate) hits regardless player latency?"?!
  • Rev0verDrive
    3665 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    edited March 17
    mischkag wrote:
    @Rev0verDrive: There is ideally in fact NEVER extrapolation. The client does not try to guess where the player is at a very moment on the server and rather tries to stay timewise as clsoe as it the latency allows to the server and processes all entities within known spatial properties. I dont want to move any soldier where it has never been unless i am forced to guess due to missing inputs. The more fluctuating your own connnection, the more conservative i have to pad to ensure interpolation. Hence the NetGraph entry: Extrapolation offset. Of course it is faster to process always just one input, but you have to average that over all layer connections and it does not matter there in terms of raw performance if i update 2 inputs for one player and none for the other and the next frame vice versa or always 1 for each. But there is a clamping which i reduced to the max number of inputs you are allowed to not send until i insert dummy ones. So a very jittery player will perceive Rubberbanding caused by this. But this prevents even more teleporting on all other player screens.
    Thanks for clearing that up. If I'm reading/interpretting this correctly. If the server hasn't received inputs from Player X over the course of N ticks. There server submits "dummy" data. This dummy data is then used/considered as "authentic" data for subsequent calculations etc.
    mischkag wrote:
    I dont quite understand your question at the end about "Does the server still arbitrate (authenticate) hits regardless player latency?"?!

    Regardless if I have a ping of 10ms or 250ms, does the server validate my clients claims of hits?
  • mischkag
    135 postsMember, Developer
    Yes it does. But it does need to anymore over 100 as there is no client side hit detection anymore at all.
  • mischkag
    135 postsMember, Developer
    Does 'not' i meant
  • Rev0verDrive
    3665 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    Impressive and very good to hear. Thanks for all the info.
  • kniphtee
    57 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    NOT HIT REG NOTE - however on Verdun it is almost impossible to tell if you are suppressed, hurt or gassed - all the red which is fun makes sorting out the mix nearly impossible. Random point in match, I get revived into suppressed gun fire am on fire and the screen goes red pink and then I get a gas grenade which I could not see.
    Another random note - almost all of the games I've played on the DLC maps (oui, oui) have been lopsided - 1000-545, 1000-632, 1000-325, etc. and I've got some hours on all the maps - DICE is great at collecting data so hopefully they are seeing this trend as well as the nade spam on de Vaux and Verdun - it's pretty rough; there should be separate timers on different map situations as in CQ maps should have higher nade regens and more open maps the times at present.
    Planes on Rupture are insane - never hear them and then dead = repeated points for the enemy and even if I see them falling - I cannot get away - boom too fast.
    What is with the creaking gate noise letting you know the squad leader designated a new point of attack?
    back to hit reg - the Cho-Cho is a beast and it feels like the slow rate of fire makes every shot hit without issue - it might need nerfed - some time later.
  • KingTolapsium
    4525 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member
    mischkag wrote: »
    @KingTolapsium: What do u mean with ''peaking advantage"?

    When a player jumps around a corner at enemies, the jumper sees things slightly before the enemy players are informed of the jumpers movement. High ping exaggerates this greatly.

    I understand reaction plays into this significantly, but there is a seemingly gigantic advantage on console when you have high ping, you can jump around a corner and kill most players without getting shot back. (Same as bf4/bfhl)

    This is not how things play out with a low ping, things seem pretty correct, it's difficult to engage most anyone head on without receiving return fire (exception being high ping). That makes sense.

    I'm sure aim assist plays a part in this, the rotational assist having frame perfect target acquisition to an ideal target location really reduces the impact of individual bullets, as many situations where any average person would miss are now smoothed over, getting killed by lightning Rotationally Assisted Aim feels about the same as the bullets "catching up" for missed packets and hitting out of time (this drives me insane, timing is everything). It just feels robotic, like the game did it or the aim assist, not another player.
  • der_Metatron
    30 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    So with the improved hit detection wich you suggested the playercount for consoles are reduced? That means BF1 turns in some kind of Marathon-Simulator with Guns? Or am I missing something?
  • Rev0verDrive
    3665 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    So with the improved hit detection wich you suggested the playercount for consoles are reduced? That means BF1 turns in some kind of Marathon-Simulator with Guns? Or am I missing something?

    No. He was talking about tick rates. Consoles cannot handle 60Hz tickrate with 64 players. IF they did force 60Hz on to console, they would have to limit max player counts.
  • VBALL_MVP
    2442 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member
    edited March 17
    So with the improved hit detection wich you suggested the playercount for consoles are reduced? That means BF1 turns in some kind of Marathon-Simulator with Guns? Or am I missing something?

    No. He was talking about tick rates. Consoles cannot handle 60Hz tickrate with 64 players. IF they did force 60Hz on to console, they would have to limit max player counts.

    Yeah back to CQS again.

    It's a lot of stress, DICE was thinking of making a calvary only game mode but said that they can only do up to (I think) 12 players for very similar reasons.
  • jdbelcher1998
    252 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member
    I also loved the 44-person CQS servers that (still) run at 45Hz in BF4...don't know if that's pushing it, especially once vehicles are added in, but 60Hz CQS would be super.
  • 17th_Spike
    19 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member
    Just wanted to thank the devs for their efforts.

    Bottom line for us few here, is an improved feel yet still that frustrating experience where "fairness" evaporates after around 9pm in the UK. Whatever the reason we can't play as much as we'd like because there's clearly still ongoing balance issues.

    If they can be improved further in the future we look forward to coming back to it, but for now... once the new map novelty wears off, I sadly think we'll be hunting for an alternative or even returning to BF4 - for the anti-frustration gaming experience.

    Great work on the new maps too! ...such a shame on the Xbox for some of us in the UK at least... well we still just can't jump in as we'd like to.
  • mmarkweII
    2368 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    I also loved the 44-person CQS servers that (still) run at 45Hz in BF4...don't know if that's pushing it, especially once vehicles are added in, but 60Hz CQS would be super.

    Those 44 man servers are glitched servers, and not CQ Small servers. CQ Small servers run with 32 players. The 45hz tickrate is for 32 player game modes and under. It happens when the server is on a small game mode, usually TDM, and gets switched to CQL with players still on the server. The reason the server stays at 45hz is it takes a restart of the server for its tickrate to change. Since the server is never restarted, it stays at the 45hz tickrate instead of changing to the 30hz which is supposed to be what CQL runs at in BF4.

    Hope this clarifies what is happening with that situation involving BF4 servers.
  • jdbelcher1998
    252 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member
    edited March 17
    mmarkweII wrote: »
    I also loved the 44-person CQS servers that (still) run at 45Hz in BF4...don't know if that's pushing it, especially once vehicles are added in, but 60Hz CQS would be super.

    Those 44 man servers are glitched servers, and not CQ Small servers. CQ Small servers run with 32 players. The 45hz tickrate is for 32 player game modes and under. It happens when the server is on a small game mode, usually TDM, and gets switched to CQL with players still on the server. The reason the server stays at 45hz is it takes a restart of the server for its tickrate to change. Since the server is never restarted, it stays at the 45hz tickrate instead of changing to the 30hz which is supposed to be what CQL runs at in BF4.

    Hope this clarifies what is happening with that situation involving BF4 servers.

    oh strange, never knew that. Thanks for clarifying. How have I missed this? So are those running on CQL maps? Or still the smaller TDM maps when they switch over? I always thought they were smaller but I never paid much mind to be honest. Either way I'd love to see the return of CQS on 60Hz servers
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!