Hit Detection

CurvedTax769796 · November 20, 2017, 1:48pm

You people can’t see this but everyone’s help here puts a smile on my face when I read their helpful comments. Never much cared for going to school but I do like learning and I’m certainly learning. Thanks again everyone!

rock1obsta · November 21, 2017, 2:27am

There’s a few guys here who really know their stuff. If you have time, skim through the thread, & you’ll find some pretty easy to understand breakdowns of these terms you see regarding internet interactivity and how it works in BF1.

CurvedTax769796 · November 21, 2017, 3:11am

Certainly seems like it and it’s all very much appreciated. This week I’m in the Nashville TN area visiting my son and his family so I’ll have the opportunity to play in a completely different area from where I live. Should give me something to compare gameplay from where I live and where he lives and hopefully eliminate or verify some of my issues

Rev0verDrive · November 21, 2017, 7:21pm

This should help in some aspects, yet it could confuse or highlight other aspects that aren’t technically issues.

Battlefields “netcode” is very complex, as it should be. Most of the complexity boils down to Projectile Physics and variant latencies amongst players. BF uses Projectile physics for all weapons, which by its nature requires a lower latency of all parties for quality “fair/balanced” game play. This need for low latency is do to the time delays inherent to projectiles with applied physics.

When a shot is fired physics are applied. velocity, gravity, drag coefficient. These physics shape the path of the projectile down range in the 3D world space (simulation). Only when game logic determines there was a collision is arbitration run on the client side. If a hit is determined by the client arbitration a hit claim is sent to the server for validation.

The server validates the hit by running its own arbitration on the travelled path of the fired projectile. To do this it must buffer into memory the entire game simulation from time the shot was fired (trigger time) up to the time of the supposed hit (collision).

The buffer usually consists of the time frame from triggertime to datagram receival time. The length of the buffer varies based on latency of the hit claim.

e.g.
trigger time: 12:00:00:000
receival time: 12:00:00:081
Memory buffer length : 81ms

Once the memory is buffered the server simulates the shot and runs raycasts for collision.

The downside of projectile physics is the bullet travel time of the projectile. This BTT delay is a window of time that allows for more of the targets past (not known by the server at time of shot) inputs to be received and update the simulations game history.

An example of this is as follows.
You have a 30ms ping which equates to a 15ms Update Travel Time.
A UTT is how long it takes your data to reach the server one way and vice versa. Client → server (15ms UTT), Server → client (15ms UTT).

Your target John has a 200ms ping (100ms UTT). This means that every input command (WASD, jump, Fire etc) he enters takes 100ms to reach the server and update the simulation.

Every client sends its buffered input commands to the server every 16.66ms. Your’s reach the the server 15ms later, yet John’s takes 100ms.

You’re in a 1 tick offset, while John is in a 6 tick offset.
You’re input is only 1 frame ahead of the servers simulation, while john is 6 frames ahead of the servers simulation.
Your screens representation of John’s position is based on what the server knows.
So in this situation John’s “real world” position (as seen on his screen) is 6 inputs/frames ahead of where you see him.

So now you take a shot. It takes that bullet 65ms to reach John on your client simulation. Your client determines a hit and sends a hit claim to the server. The server receives it, buffers simulation history and runs the arbitration. The server determines a miss. Why?

((65ms BTT + 15ms UTT) / 16.66) = 4.801920768307323

Four of John’s old in route inputs were received by the server before your hit claim was received. These inputs updated his historical position in the servers simulation. Thus putting him in a different position than where you saw and shot.

Hitscan shot/hit reg arbitration is instantaneous, because the “bullet” collides instantly when the weapon is fired. When the user provides trigger input (fire button) the game logic (client side) immediately arbitrates the shot. The outcome of that arbitration is known client side before the frame is rendered at which point it sends a hit claim to the server for validation of the hit. The only major delay is the shooters update trave time (UTT) of the hit claim datagram.

The server would receive a 30ms shooters hit claim in 15ms. This isn’t enough time for the target to get latent historical inputs registered before arbitration. Thus where you saw the player is what is arbitrated against… A hit is ultimately the outcome.

edit for Clarification/Distinction: CoD, CSGO, Destiny, Seige are Hitscan based games. The above mention of HS is to highlight the differences and why hitreg isn’t an issue in those games or others that use hitscan.

Hopefully this all makes sense. If anything needs to be clarified please don’t hesitate to ask.

CurvedTax769796 · November 21, 2017, 9:53pm

Wow not only does it make sense it is extremely interesting and fascinating. It really explains a lot to help understand what actually takes place during game play. After reading this, If I’m correct, it explains to me when I get a message telling me my latency to the server is high and that I need to lead my shots more. Now I need to figure which direction to lead when facing a stationary target and I imagine, because of the time difference that is most likely minimal for something stationary. I’ll just have to guess and hope I guess the right direction to lead. Totally amazing information and I really appreciate the time you took to explain it. Now that I have some understanding of the process involved it will be far less frustrating. Thanks again.

mmarkweII · November 21, 2017, 10:19pm

Knowledge is power and knowing is half the battle.

VBALL_MVP · November 21, 2017, 10:36pm

You don’t have to lead a stationary target or one that is coming towards or away from you. Just the ones strafing.

Rev0verDrive · November 22, 2017, 7:41am

Your welcome.

That’s just the surface of it.

There’s Also…

High Frequency Update (HFU)
Frame History Time (FHT)
High Ping Threshold
Full Server side hit reg
Client receive rates (FPS dependent)
and various other nuances

CurvedTax769796 · November 22, 2017, 2:47pm

Definitely going to look into and research this. The more knowledge and understanding how it all works is always beneficial

lizzard · November 22, 2017, 4:01pm

Be careful.. It may affect your hopes, about battlefield games ever going to be enjoyable on consoles.

Having a flawless gameplay experience in games like this, with so many different connection grades bundled up on one server.
And with kind of a low performance hardware running the game.
It feels like it’s never going to be really enjoyable in the long run..

VBALL_MVP · November 22, 2017, 4:44pm

Don’t listen to the negativity over there. Just do some research, make sure you have done everything at home to ensure your network performance. Talk to your ISP as well, let them know what you are trying to do…they sometimes will “tweak” your line if you are nice.

Record your gameplay so you can watch and review…sometimes it’s hard to see what happened in the heat of the battle.

In the end just have fun…remember it’s a game. Having a 3 KD won’t land you that CEO position.

CurvedTax769796 · November 22, 2017, 5:50pm

I have noticed a difference between playing where I live in the Northwest and where my son lives in the South. I don’t worry to much about K/D as having an unlimited number of respawns prevents it from being an accurate indicator. When you know that you can respawn limitlessly you don’t worry about dying except for when an x amount of kills is required in one life. Now if respawn was limited to a certain number per round, skills levels would be more accurately determined. Those conditions would most likely cause a drop in players unless matchmaking was set to match those with the same level allowing for advancement as your skills improved. Above all, as you stated, the most important thing is to have fun

VBALL_MVP · November 22, 2017, 6:35pm

Yup. Having fun is the major part. Are there issues…sure. But I have logged over 200 hours of the game…absolutely got my money’s worth.

CurvedTax769796 · November 22, 2017, 7:04pm

And the nicest part, because of online play, I can enjoy participating with my son even though we live in different parts of the country. Just like when he was young and there were games you could play sitting next to each other.

LeonReed123 · November 24, 2017, 5:45pm

Rev0verDrive:

This should help in some aspects, yet it could confuse or highlight other aspects that aren’t technically issues.

Battlefields “netcode” is very complex, as it should be. Most of the complexity boils down to Projectile Physics and variant latencies amongst players. BF uses Projectile physics for all weapons, which by its nature requires a lower latency of all parties for quality “fair/balanced” game play. This need for low latency is do to the time delays inherent to projectiles with applied physics.

When a shot is fired physics are applied. velocity, gravity, drag coefficient. These physics shape the path of the projectile down range in the 3D world space (simulation). Only when game logic determines there was a collision is arbitration run on the client side. If a hit is determined by the client arbitration a hit claim is sent to the server for validation.

The server validates the hit by running its own arbitration on the travelled path of the fired projectile. To do this it must buffer into memory the entire game simulation from time the shot was fired (trigger time) up to the time of the supposed hit (collision).

The buffer usually consists of the time frame from triggertime to datagram receival time. The length of the buffer varies based on latency of the hit claim.

e.g.
trigger time: 12:00:00:000
receival time: 12:00:00:081
Memory buffer length : 81ms

Once the memory is buffered the server simulates the shot and runs raycasts for collision.

The downside of projectile physics is the bullet travel time of the projectile. This BTT delay is a window of time that allows for more of the targets past (not known by the server at time of shot) inputs to be received and update the simulations game history.

An example of this is as follows.
You have a 30ms ping which equates to a 15ms Update Travel Time.
A UTT is how long it takes your data to reach the server one way and vice versa. Client → server (15ms UTT), Server → client (15ms UTT).

Your target John has a 200ms ping (100ms UTT). This means that every input command (WASD, jump, Fire etc) he enters takes 100ms to reach the server and update the simulation.

Every client sends its buffered input commands to the server every 16.66ms. Your’s reach the the server 15ms later, yet John’s takes 100ms.

You’re in a 1 tick offset, while John is in a 6 tick offset.
You’re input is only 1 frame ahead of the servers simulation, while john is 6 frames ahead of the servers simulation.
Your screens representation of John’s position is based on what the server knows.
So in this situation John’s “real world” position (as seen on his screen) is 6 inputs/frames ahead of where you see him.

So now you take a shot. It takes that bullet 65ms to reach John on your client simulation. Your client determines a hit and sends a hit claim to the server. The server receives it, buffers simulation history and runs the arbitration. The server determines a miss. Why?

((65ms BTT + 15ms UTT) / 16.66) = 4.801920768307323

Four of John’s old in route inputs were received by the server before your hit claim was received. These inputs updated his historical position in the servers simulation. Thus putting him in a different position than where you saw and shot.

Hitscan shot/hit reg arbitration is instantaneous, because the “bullet” collides instantly when the weapon is fired. When the user provides trigger input (fire button) the game logic (client side) immediately arbitrates the shot. The outcome of that arbitration is known client side before the frame is rendered at which point it sends a hit claim to the server for validation of the hit. The only major delay is the shooters update trave time (UTT) of the hit claim datagram.

The server would receive a 30ms shooters hit claim in 15ms. This isn’t enough time for the target to get latent historical inputs registered before arbitration. Thus where you saw the player is what is arbitrated against… A hit is ultimately the outcome.

edit for Clarification/Distinction: CoD, CSGO, Destiny, Seige are Hitscan based games. The above mention of HS is to highlight the differences and why hitreg isn’t an issue in those games or others that use hitscan.

Hopefully this all makes sense. If anything needs to be clarified please don’t hesitate to ask.

Some really good info there and really interesting.

You obviously have a really good understanding of these issues and hopefully can give me an answer/explanation in regards a few questions I have ( you seem really unbiased which is a breath of fresh air ).

When I play on a server ( 24 person ), have the lowest latency ( usually at least 25 - 30 under the average ) and am getting no warning icons will in your opinion people with much higher latency have a detrimental effect on my game? Not necessarily an advantage but will it create strangeness in my game. I have a lot of times when I get what people call one shot now this could be from an LMG etc am not just talking snipers head shots etc. Its basically as if I have been spoted they fire on me but I am only getting it shown on my screen right before I die so no chance to take cover move etc. Also with regards various latencies what would you say is an optimal latency gap from lowest on server to highest? If someones say 30 and theres a few players 125+ would you say it will be a difference that can cause problems?

GyposEyelash · November 24, 2017, 7:08pm

For anyone in the UK having problems and is using a Homehub, I turned off extended uPnP Security and this game has been playing great ever since.

I have had problems with this game and Battlefield 4 for ages, turning this off seems to have sorted my problems with both games.

misisipiRivrRat · November 25, 2017, 1:07am

LeonReed123:

Rev0verDrive:

This should help in some aspects, yet it could confuse or highlight other aspects that aren’t technically issues.

Battlefields “netcode” is very complex, as it should be. Most of the complexity boils down to Projectile Physics and variant latencies amongst players. BF uses Projectile physics for all weapons, which by its nature requires a lower latency of all parties for quality “fair/balanced” game play. This need for low latency is do to the time delays inherent to projectiles with applied physics.

When a shot is fired physics are applied. velocity, gravity, drag coefficient. These physics shape the path of the projectile down range in the 3D world space (simulation). Only when game logic determines there was a collision is arbitration run on the client side. If a hit is determined by the client arbitration a hit claim is sent to the server for validation.

The server validates the hit by running its own arbitration on the travelled path of the fired projectile. To do this it must buffer into memory the entire game simulation from time the shot was fired (trigger time) up to the time of the supposed hit (collision).

The buffer usually consists of the time frame from triggertime to datagram receival time. The length of the buffer varies based on latency of the hit claim.

e.g.
trigger time: 12:00:00:000
receival time: 12:00:00:081
Memory buffer length : 81ms

Once the memory is buffered the server simulates the shot and runs raycasts for collision.

The downside of projectile physics is the bullet travel time of the projectile. This BTT delay is a window of time that allows for more of the targets past (not known by the server at time of shot) inputs to be received and update the simulations game history.

An example of this is as follows.
You have a 30ms ping which equates to a 15ms Update Travel Time.
A UTT is how long it takes your data to reach the server one way and vice versa. Client → server (15ms UTT), Server → client (15ms UTT).

Your target John has a 200ms ping (100ms UTT). This means that every input command (WASD, jump, Fire etc) he enters takes 100ms to reach the server and update the simulation.

Every client sends its buffered input commands to the server every 16.66ms. Your’s reach the the server 15ms later, yet John’s takes 100ms.

You’re in a 1 tick offset, while John is in a 6 tick offset.
You’re input is only 1 frame ahead of the servers simulation, while john is 6 frames ahead of the servers simulation.
Your screens representation of John’s position is based on what the server knows.
So in this situation John’s “real world” position (as seen on his screen) is 6 inputs/frames ahead of where you see him.

So now you take a shot. It takes that bullet 65ms to reach John on your client simulation. Your client determines a hit and sends a hit claim to the server. The server receives it, buffers simulation history and runs the arbitration. The server determines a miss. Why?

((65ms BTT + 15ms UTT) / 16.66) = 4.801920768307323

Four of John’s old in route inputs were received by the server before your hit claim was received. These inputs updated his historical position in the servers simulation. Thus putting him in a different position than where you saw and shot.

Hitscan shot/hit reg arbitration is instantaneous, because the “bullet” collides instantly when the weapon is fired. When the user provides trigger input (fire button) the game logic (client side) immediately arbitrates the shot. The outcome of that arbitration is known client side before the frame is rendered at which point it sends a hit claim to the server for validation of the hit. The only major delay is the shooters update trave time (UTT) of the hit claim datagram.

The server would receive a 30ms shooters hit claim in 15ms. This isn’t enough time for the target to get latent historical inputs registered before arbitration. Thus where you saw the player is what is arbitrated against… A hit is ultimately the outcome.

edit for Clarification/Distinction: CoD, CSGO, Destiny, Seige are Hitscan based games. The above mention of HS is to highlight the differences and why hitreg isn’t an issue in those games or others that use hitscan.

Hopefully this all makes sense. If anything needs to be clarified please don’t hesitate to ask.

Some really good info there and really interesting.

You obviously have a really good understanding of these issues and hopefully can give me an answer/explanation in regards a few questions I have ( you seem really unbiased which is a breath of fresh air ).

When I play on a server ( 24 person ), have the lowest latency ( usually at least 25 - 30 under the average ) and am getting no warning icons will in your opinion people with much higher latency have a detrimental effect on my game? Not necessarily an advantage but will it create strangeness in my game. I have a lot of times when I get what people call one shot now this could be from an LMG etc am not just talking snipers head shots etc. Its basically as if I have been spoted they fire on me but I am only getting it shown on my screen right before I die so no chance to take cover move etc. Also with regards various latencies what would you say is an optimal latency gap from lowest on server to highest? If someones say 30 and theres a few players 125+ would you say it will be a difference that can cause problems?

I hope you get a answer from him or someone knowledgeable. I’ve posed similar questions in this very thread only to get no response. In my opinion when there are more than a few very high pings in a server things get weird. But it’s only my opinion based only on my experience with the game.

VBALL_MVP · November 25, 2017, 1:17am

misisipiRivrRat:

LeonReed123:

Rev0verDrive:

This should help in some aspects, yet it could confuse or highlight other aspects that aren’t technically issues.

Battlefields “netcode” is very complex, as it should be. Most of the complexity boils down to Projectile Physics and variant latencies amongst players. BF uses Projectile physics for all weapons, which by its nature requires a lower latency of all parties for quality “fair/balanced” game play. This need for low latency is do to the time delays inherent to projectiles with applied physics.

When a shot is fired physics are applied. velocity, gravity, drag coefficient. These physics shape the path of the projectile down range in the 3D world space (simulation). Only when game logic determines there was a collision is arbitration run on the client side. If a hit is determined by the client arbitration a hit claim is sent to the server for validation.

The server validates the hit by running its own arbitration on the travelled path of the fired projectile. To do this it must buffer into memory the entire game simulation from time the shot was fired (trigger time) up to the time of the supposed hit (collision).

The buffer usually consists of the time frame from triggertime to datagram receival time. The length of the buffer varies based on latency of the hit claim.

e.g.
trigger time: 12:00:00:000
receival time: 12:00:00:081
Memory buffer length : 81ms

Once the memory is buffered the server simulates the shot and runs raycasts for collision.

The downside of projectile physics is the bullet travel time of the projectile. This BTT delay is a window of time that allows for more of the targets past (not known by the server at time of shot) inputs to be received and update the simulations game history.

An example of this is as follows.
You have a 30ms ping which equates to a 15ms Update Travel Time.
A UTT is how long it takes your data to reach the server one way and vice versa. Client → server (15ms UTT), Server → client (15ms UTT).

Your target John has a 200ms ping (100ms UTT). This means that every input command (WASD, jump, Fire etc) he enters takes 100ms to reach the server and update the simulation.

Every client sends its buffered input commands to the server every 16.66ms. Your’s reach the the server 15ms later, yet John’s takes 100ms.

You’re in a 1 tick offset, while John is in a 6 tick offset.
You’re input is only 1 frame ahead of the servers simulation, while john is 6 frames ahead of the servers simulation.
Your screens representation of John’s position is based on what the server knows.
So in this situation John’s “real world” position (as seen on his screen) is 6 inputs/frames ahead of where you see him.

So now you take a shot. It takes that bullet 65ms to reach John on your client simulation. Your client determines a hit and sends a hit claim to the server. The server receives it, buffers simulation history and runs the arbitration. The server determines a miss. Why?

((65ms BTT + 15ms UTT) / 16.66) = 4.801920768307323

Four of John’s old in route inputs were received by the server before your hit claim was received. These inputs updated his historical position in the servers simulation. Thus putting him in a different position than where you saw and shot.

Hitscan shot/hit reg arbitration is instantaneous, because the “bullet” collides instantly when the weapon is fired. When the user provides trigger input (fire button) the game logic (client side) immediately arbitrates the shot. The outcome of that arbitration is known client side before the frame is rendered at which point it sends a hit claim to the server for validation of the hit. The only major delay is the shooters update trave time (UTT) of the hit claim datagram.

The server would receive a 30ms shooters hit claim in 15ms. This isn’t enough time for the target to get latent historical inputs registered before arbitration. Thus where you saw the player is what is arbitrated against… A hit is ultimately the outcome.

edit for Clarification/Distinction: CoD, CSGO, Destiny, Seige are Hitscan based games. The above mention of HS is to highlight the differences and why hitreg isn’t an issue in those games or others that use hitscan.

Hopefully this all makes sense. If anything needs to be clarified please don’t hesitate to ask.

Some really good info there and really interesting.

You obviously have a really good understanding of these issues and hopefully can give me an answer/explanation in regards a few questions I have ( you seem really unbiased which is a breath of fresh air ).

When I play on a server ( 24 person ), have the lowest latency ( usually at least 25 - 30 under the average ) and am getting no warning icons will in your opinion people with much higher latency have a detrimental effect on my game? Not necessarily an advantage but will it create strangeness in my game. I have a lot of times when I get what people call one shot now this could be from an LMG etc am not just talking snipers head shots etc. Its basically as if I have been spoted they fire on me but I am only getting it shown on my screen right before I die so no chance to take cover move etc. Also with regards various latencies what would you say is an optimal latency gap from lowest on server to highest? If someones say 30 and theres a few players 125+ would you say it will be a difference that can cause problems?

I hope you get a answer from him or someone knowledgeable. I’ve posed similar questions in this very thread only to get no response. In my opinion when there are more than a few very high pings in a server things get weird. But it’s only my opinion based only on my experience with the game.

So a couple of days I thought of you. Was able to play in the morning since I have been off from work. I experienced four games in the morning and as you have stated in the past it was flooded with people over 100ms ping.

The thing I didn’t experience was anything screwy. It ran fine and was able to play and kill anyone with no issues. Based off of this I believe there is something else that is causing issues since I should have had horrible experiences based on all the high pingers in the game.

misisipiRivrRat · November 25, 2017, 12:00pm

VBALL_MVP:

misisipiRivrRat:

LeonReed123:

Rev0verDrive:

This should help in some aspects, yet it could confuse or highlight other aspects that aren’t technically issues.

Battlefields “netcode” is very complex, as it should be. Most of the complexity boils down to Projectile Physics and variant latencies amongst players. BF uses Projectile physics for all weapons, which by its nature requires a lower latency of all parties for quality “fair/balanced” game play. This need for low latency is do to the time delays inherent to projectiles with applied physics.

When a shot is fired physics are applied. velocity, gravity, drag coefficient. These physics shape the path of the projectile down range in the 3D world space (simulation). Only when game logic determines there was a collision is arbitration run on the client side. If a hit is determined by the client arbitration a hit claim is sent to the server for validation.

The server validates the hit by running its own arbitration on the travelled path of the fired projectile. To do this it must buffer into memory the entire game simulation from time the shot was fired (trigger time) up to the time of the supposed hit (collision).

The buffer usually consists of the time frame from triggertime to datagram receival time. The length of the buffer varies based on latency of the hit claim.

e.g.
trigger time: 12:00:00:000
receival time: 12:00:00:081
Memory buffer length : 81ms

Once the memory is buffered the server simulates the shot and runs raycasts for collision.

The downside of projectile physics is the bullet travel time of the projectile. This BTT delay is a window of time that allows for more of the targets past (not known by the server at time of shot) inputs to be received and update the simulations game history.

An example of this is as follows.
You have a 30ms ping which equates to a 15ms Update Travel Time.
A UTT is how long it takes your data to reach the server one way and vice versa. Client → server (15ms UTT), Server → client (15ms UTT).

Your target John has a 200ms ping (100ms UTT). This means that every input command (WASD, jump, Fire etc) he enters takes 100ms to reach the server and update the simulation.

Every client sends its buffered input commands to the server every 16.66ms. Your’s reach the the server 15ms later, yet John’s takes 100ms.

You’re in a 1 tick offset, while John is in a 6 tick offset.
You’re input is only 1 frame ahead of the servers simulation, while john is 6 frames ahead of the servers simulation.
Your screens representation of John’s position is based on what the server knows.
So in this situation John’s “real world” position (as seen on his screen) is 6 inputs/frames ahead of where you see him.

So now you take a shot. It takes that bullet 65ms to reach John on your client simulation. Your client determines a hit and sends a hit claim to the server. The server receives it, buffers simulation history and runs the arbitration. The server determines a miss. Why?

((65ms BTT + 15ms UTT) / 16.66) = 4.801920768307323

Four of John’s old in route inputs were received by the server before your hit claim was received. These inputs updated his historical position in the servers simulation. Thus putting him in a different position than where you saw and shot.

Hitscan shot/hit reg arbitration is instantaneous, because the “bullet” collides instantly when the weapon is fired. When the user provides trigger input (fire button) the game logic (client side) immediately arbitrates the shot. The outcome of that arbitration is known client side before the frame is rendered at which point it sends a hit claim to the server for validation of the hit. The only major delay is the shooters update trave time (UTT) of the hit claim datagram.

The server would receive a 30ms shooters hit claim in 15ms. This isn’t enough time for the target to get latent historical inputs registered before arbitration. Thus where you saw the player is what is arbitrated against… A hit is ultimately the outcome.

edit for Clarification/Distinction: CoD, CSGO, Destiny, Seige are Hitscan based games. The above mention of HS is to highlight the differences and why hitreg isn’t an issue in those games or others that use hitscan.

Hopefully this all makes sense. If anything needs to be clarified please don’t hesitate to ask.

Some really good info there and really interesting.

You obviously have a really good understanding of these issues and hopefully can give me an answer/explanation in regards a few questions I have ( you seem really unbiased which is a breath of fresh air ).

When I play on a server ( 24 person ), have the lowest latency ( usually at least 25 - 30 under the average ) and am getting no warning icons will in your opinion people with much higher latency have a detrimental effect on my game? Not necessarily an advantage but will it create strangeness in my game. I have a lot of times when I get what people call one shot now this could be from an LMG etc am not just talking snipers head shots etc. Its basically as if I have been spoted they fire on me but I am only getting it shown on my screen right before I die so no chance to take cover move etc. Also with regards various latencies what would you say is an optimal latency gap from lowest on server to highest? If someones say 30 and theres a few players 125+ would you say it will be a difference that can cause problems?

I hope you get a answer from him or someone knowledgeable. I’ve posed similar questions in this very thread only to get no response. In my opinion when there are more than a few very high pings in a server things get weird. But it’s only my opinion based only on my experience with the game.

So a couple of days I thought of you. Was able to play in the morning since I have been off from work. I experienced four games in the morning and as you have stated in the past it was flooded with people over 100ms ping.

The thing I didn’t experience was anything screwy. It ran fine and was able to play and kill anyone with no issues. Based off of this I believe there is something else that is causing issues since I should have had horrible experiences based on all the high pingers in the game.

Oh no, vball is thinking of me. Just kidding.
Here’s the thing, the game is optimized so that everybody is supposed to get a gameplay experience right? I just feel when there are too many high ping players all with different wildly different pings in a server, whatever does the optimizing then has a harder time to make things smooth. My experience then playing with high ping players is not good. I’m not saying there is any advantage because many times I feel they are just as easy to kill.
Do you remember once when I said to you that I don’t need to top the leaderboards to have a great time in Battlefield , and that holds true today. But what I do want from Battlefield is consistent , quality gameplay . Not this crap that the majority of us are getting. And when we complain I don’t think it’s every game we’re complaining about and that’s part of the problem. This game rocks when all is good. Good just doesn’t happen enough for me anymore.
This game was wonderful for me after that spring patch. My k/d and score didn’t go up mind you(cause I checked) but the gameplay was so smooth, I felt the difference instantly. But man has it went downhill from there. At least for me.
You know what else is frustrating ? It’s hearing that the game is fine for you and a handful of others. I’m not being a vball, but you poo poo away lots of what others are saying what is wrong with the game. Yes there are times when we are wrong about something , and you can see it when a video is looked at in slow motion. But lots of other times I don’t think issues are explained away.
Bottom line is I don’t want to argue with you about this. You’re knowledgeable about networking , I’m not. But I am a very observant person when it comes to visual and audio things. I can hear something or see something just a couple of times and then if something changes I’m pretty good at noticing this even if I can’t vocalize what has changed.
And that’s my point with Battlefield at least from my point of view. I’ve enough times to feel when things are good and when things are bad, even if I can’t actually pinpoint what exactly is off. Hope that makes sense. And most, not all times when gameplay is off, there are many high ping players in the server.
Shoot, sorry this got so long but thanks for listening.

lizzard · November 25, 2017, 1:24pm

misisipiRivrRat:

VBALL_MVP:

misisipiRivrRat:

LeonReed123:

Rev0verDrive:

This should help in some aspects, yet it could confuse or highlight other aspects that aren’t technically issues.

Battlefields “netcode” is very complex, as it should be. Most of the complexity boils down to Projectile Physics and variant latencies amongst players. BF uses Projectile physics for all weapons, which by its nature requires a lower latency of all parties for quality “fair/balanced” game play. This need for low latency is do to the time delays inherent to projectiles with applied physics.

When a shot is fired physics are applied. velocity, gravity, drag coefficient. These physics shape the path of the projectile down range in the 3D world space (simulation). Only when game logic determines there was a collision is arbitration run on the client side. If a hit is determined by the client arbitration a hit claim is sent to the server for validation.

The server validates the hit by running its own arbitration on the travelled path of the fired projectile. To do this it must buffer into memory the entire game simulation from time the shot was fired (trigger time) up to the time of the supposed hit (collision).

The buffer usually consists of the time frame from triggertime to datagram receival time. The length of the buffer varies based on latency of the hit claim.

e.g.
trigger time: 12:00:00:000
receival time: 12:00:00:081
Memory buffer length : 81ms

Once the memory is buffered the server simulates the shot and runs raycasts for collision.

The downside of projectile physics is the bullet travel time of the projectile. This BTT delay is a window of time that allows for more of the targets past (not known by the server at time of shot) inputs to be received and update the simulations game history.

An example of this is as follows.
You have a 30ms ping which equates to a 15ms Update Travel Time.
A UTT is how long it takes your data to reach the server one way and vice versa. Client → server (15ms UTT), Server → client (15ms UTT).

Your target John has a 200ms ping (100ms UTT). This means that every input command (WASD, jump, Fire etc) he enters takes 100ms to reach the server and update the simulation.

Every client sends its buffered input commands to the server every 16.66ms. Your’s reach the the server 15ms later, yet John’s takes 100ms.

You’re in a 1 tick offset, while John is in a 6 tick offset.
You’re input is only 1 frame ahead of the servers simulation, while john is 6 frames ahead of the servers simulation.
Your screens representation of John’s position is based on what the server knows.
So in this situation John’s “real world” position (as seen on his screen) is 6 inputs/frames ahead of where you see him.

So now you take a shot. It takes that bullet 65ms to reach John on your client simulation. Your client determines a hit and sends a hit claim to the server. The server receives it, buffers simulation history and runs the arbitration. The server determines a miss. Why?

((65ms BTT + 15ms UTT) / 16.66) = 4.801920768307323

Four of John’s old in route inputs were received by the server before your hit claim was received. These inputs updated his historical position in the servers simulation. Thus putting him in a different position than where you saw and shot.

Hitscan shot/hit reg arbitration is instantaneous, because the “bullet” collides instantly when the weapon is fired. When the user provides trigger input (fire button) the game logic (client side) immediately arbitrates the shot. The outcome of that arbitration is known client side before the frame is rendered at which point it sends a hit claim to the server for validation of the hit. The only major delay is the shooters update trave time (UTT) of the hit claim datagram.

The server would receive a 30ms shooters hit claim in 15ms. This isn’t enough time for the target to get latent historical inputs registered before arbitration. Thus where you saw the player is what is arbitrated against… A hit is ultimately the outcome.

edit for Clarification/Distinction: CoD, CSGO, Destiny, Seige are Hitscan based games. The above mention of HS is to highlight the differences and why hitreg isn’t an issue in those games or others that use hitscan.

Hopefully this all makes sense. If anything needs to be clarified please don’t hesitate to ask.

Some really good info there and really interesting.

You obviously have a really good understanding of these issues and hopefully can give me an answer/explanation in regards a few questions I have ( you seem really unbiased which is a breath of fresh air ).

When I play on a server ( 24 person ), have the lowest latency ( usually at least 25 - 30 under the average ) and am getting no warning icons will in your opinion people with much higher latency have a detrimental effect on my game? Not necessarily an advantage but will it create strangeness in my game. I have a lot of times when I get what people call one shot now this could be from an LMG etc am not just talking snipers head shots etc. Its basically as if I have been spoted they fire on me but I am only getting it shown on my screen right before I die so no chance to take cover move etc. Also with regards various latencies what would you say is an optimal latency gap from lowest on server to highest? If someones say 30 and theres a few players 125+ would you say it will be a difference that can cause problems?

I hope you get a answer from him or someone knowledgeable. I’ve posed similar questions in this very thread only to get no response. In my opinion when there are more than a few very high pings in a server things get weird. But it’s only my opinion based only on my experience with the game.

So a couple of days I thought of you. Was able to play in the morning since I have been off from work. I experienced four games in the morning and as you have stated in the past it was flooded with people over 100ms ping.

The thing I didn’t experience was anything screwy. It ran fine and was able to play and kill anyone with no issues. Based off of this I believe there is something else that is causing issues since I should have had horrible experiences based on all the high pingers in the game.

Oh no, vball is thinking of me. Just kidding.
Here’s the thing, the game is optimized so that everybody is supposed to get a gameplay experience right? I just feel when there are too many high ping players all with different wildly different pings in a server, whatever does the optimizing then has a harder time to make things smooth. My experience then playing with high ping players is not good. I’m not saying there is any advantage because many times I feel they are just as easy to kill.
Do you remember once when I said to you that I don’t need to top the leaderboards to have a great time in Battlefield , and that holds true today. But what I do want from Battlefield is consistent , quality gameplay . Not this crap that the majority of us are getting. And when we complain I don’t think it’s every game we’re complaining about and that’s part of the problem. This game rocks when all is good. Good just doesn’t happen enough for me anymore.
This game was wonderful for me after that spring patch. My k/d and score didn’t go up mind you(cause I checked) but the gameplay was so smooth, I felt the difference instantly. But man has it went downhill from there. At least for me.
You know what else is frustrating ? It’s hearing that the game is fine for you and a handful of others. I’m not being a vball, but you poo poo away lots of what others are saying what is wrong with the game. Yes there are times when we are wrong about something , and you can see it when a video is looked at in slow motion. But lots of other times I don’t think issues are explained away.
Bottom line is I don’t want to argue with you about this. You’re knowledgeable about networking , I’m not. But I am a very observant person when it comes to visual and audio things. I can hear something or see something just a couple of times and then if something changes I’m pretty good at noticing this even if I can’t vocalize what has changed.
And that’s my point with Battlefield at least from my point of view. I’ve enough times to feel when things are good and when things are bad, even if I can’t actually pinpoint what exactly is off. Hope that makes sense. And most, not all times when gameplay is off, there are many high ping players in the server.
Shoot, sorry this got so long but thanks for listening.

I did see a clear increase in my KD after the spring patch. And most importantly the numbers where much more consistent!

The 5-30 KD games was changed to 20-30.
And it felt like I was fairly outplayed in those games.

I can relate to your “feel of consistency” im like you in a way. Sounds, rhythm of impacts. Visual effects. It all gives us a feeling of what to expect. And when something is off, it feels inconsistent!