Hit Detection

Comments

  • oJU5T1No
    901 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member
    Its not that high ping has an advantage , more that it disadvantages and causes issues for everyone else.
  • KingTolapsium
    5491 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE, BF1IncursionsAlpha, Battlefield V Member
    oJU5T1No wrote: »
    Its not that high ping has an advantage , more that it disadvantages and causes issues for everyone else.

    So it's semantics. This does not ignore the issues.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    oJU5T1No wrote: »
    Its not that high ping has an advantage , more that it disadvantages and causes issues for everyone else.

    There use to be an advantage. It was a clear advantage. Not all knew how to use it, but none the less used or not it had a negative effect on the visual reality rendered on screen and could be exploited. High ping is still a negative that affects global game play. The big issue is trying to render the same reality in time at every interaction .. or at least within a few milliseconds of each others actions.

    I jump, you see it in 30ms. Thats pretty much the best possible outcome using the 60Hz tickrate. But that entirely relies on both players having below 10ms pings and the tick firing 1ms after receiving the data.

    That's what we all want. But you wont see that type of reality between a 30ms player and a 120ms player. Minimum that's 75ms difference or 4.5 frames. After real time rendering it's more along 6 frames.
  • KingTolapsium
    5491 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE, BF1IncursionsAlpha, Battlefield V Member
    oJU5T1No wrote: »
    Its not that high ping has an advantage , more that it disadvantages and causes issues for everyone else.

    There use to be an advantage. It was a clear advantage. Not all knew how to use it, but none the less used or not it had a negative effect on the visual reality rendered on screen and could be exploited. High ping is still a negative that affects global game play. The big issue is trying to render the same reality in time at every interaction .. or at least within a few milliseconds of each others actions.

    I jump, you see it in 30ms. Thats pretty much the best possible outcome using the 60Hz tickrate. But that entirely relies on both players having below 10ms pings and the tick firing 1ms after receiving the data.

    That's what we all want. But you wont see that type of reality between a 30ms player and a 120ms player. Minimum that's 75ms difference or 4.5 frames. After real time rendering it's more along 6 frames.

    And having a tickrate that is half of the framerate doesn't help this at all. :(
  • digga11
    770 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE, Battlefield V Member
    edited September 2017
    Bad hit detection amongst other things in the new maps plus quite shaky server performance in the smaller map modes. We're seem to be back to fire four shots 2 or 1 register again.
    This issue had almost cleared up before this update. Certain medic weapons are worst than others same with snipers.
    Suppression is bad also I seem to get suppressed a lot but can never suppress any one. I'm hoping it calms down but I won't hold my breath.
  • oJU5T1No
    901 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member
    oJU5T1No wrote: »
    Its not that high ping has an advantage , more that it disadvantages and causes issues for everyone else.

    There use to be an advantage. It was a clear advantage. Not all knew how to use it, but none the less used or not it had a negative effect on the visual reality rendered on screen and could be exploited. High ping is still a negative that affects global game play. The big issue is trying to render the same reality in time at every interaction .. or at least within a few milliseconds of each others actions.

    I jump, you see it in 30ms. Thats pretty much the best possible outcome using the 60Hz tickrate. But that entirely relies on both players having below 10ms pings and the tick firing 1ms after receiving the data.

    That's what we all want. But you wont see that type of reality between a 30ms player and a 120ms player. Minimum that's 75ms difference or 4.5 frames. After real time rendering it's more along 6 frames.

    Thats not even the worst off it, the worst of it is the compensation for the late and missing data that results in me getting repeatably frozen to the spot to await some death that is completely out-of-sync and doesn't make any sense.
  • lizzard
    985 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    edited September 2017
    @Rev0verDrive

    This is not about battlefield directly. But I would really like your opinion on this matter, since its related to the understanding of online fps gameplay.

    it feels like when mischkag made the 100ms patch. Witch got hotfixed to ruin the gameplay once again..

    Big patch in rainbow.
    Resulting in nearly flawless gameplay experience.
    No highpingers and no issues killing other players.

    Day after, a new patch just as big as the one the day before.
    Suddenly loads of highpingers.
    Players laging and jitters.
    90% of games is out of sync, even when only lowpingers are in the game.

    First part is a teammate with a horrible connection. How can that be allowed in online gameplay?

    Last part. Desync? Wtf is happening?

    What is your thoughts about this?

  • misisipiRivrRat
    1004 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    edited September 2017

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.
  • misisipiRivrRat
    1004 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    edited September 2017
    And then this. I came out of the entrance, threw the grenade and then tried to hip fire but I was stuck. Just couldn't move for a second, enough for the guy to kill me. I know it doesn't show up as me trying to fire so you'll need to take my word for it.
    Could this be that being held bug that kingtolapsium has talked about?
  • HillbillyJohn
    510 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, Battlefield V Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    Ummm?!? I have no words!
  • mmarkweII
    2919 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    Ummm?!? I have no words!

    That's because this video is showing the screen shake bug. It has happened to me a couple times recently. Haven't had it happen in awhile until the latest update. It corrects itself after a death. :neutral:
  • digga11
    770 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE, Battlefield V Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    Servers are full of oor players ATM in Europe.
    Always seems to be when Dlc drops, when they've done the weapon challenges etc it might calm down. Why we can't have a decent ping cap is crazy really.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    lizzard wrote: »
    @Rev0verDrive

    This is not about battlefield directly. But I would really like your opinion on this matter, since its related to the understanding of online fps gameplay.

    it feels like when mischkag made the 100ms patch. Witch got hotfixed to ruin the gameplay once again..

    Big patch in rainbow.
    Resulting in nearly flawless gameplay experience.
    No highpingers and no issues killing other players.

    Day after, a new patch just as big as the one the day before.
    Suddenly loads of highpingers.
    Players laging and jitters.
    90% of games is out of sync, even when only lowpingers are in the game.

    First part is a teammate with a horrible connection. How can that be allowed in online gameplay?

    Last part. Desync? Wtf is happening?

    What is your thoughts about this?


    Sorry mate, But I don't have enough knowledge on R6's setup to give any "valid" explanations. I could speculate until I'm blue in the face, but that's not going to help you.
  • UrinDenialP
    144 postsMember, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    the graph and the ping chart doesnt look out of the ordinary.
    i had a 700ms+ player on my team yesterday ....but in other games there wasnt .

    gameplay was near enough the same.

    i will how ever like to question the packet loss graph.
    i reckon its zero because they test with icmp or tcp....more likely icmp.

    either way if they arent testing with udp its pretty pointless having a packet loss graph there.
    the odds are you had very high packet loss or packets diverted which caused a lot to arrive out of order...rendered useless.

    what caused it?

    probably your isp treating icmp normally so they dont get complaints but other packet types ...more specifically udp....being re routed probably causing them to loop en route.

    ive seen this happen with dodgy gameplay btw.

    they wont do this with tcp as if you understand the net this would cause utter mayhem lol.

    easier to pick on a protocol which doesnt need a reply or resend.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    the graph and the ping chart doesnt look out of the ordinary.
    i had a 700ms+ player on my team yesterday ....but in other games there wasnt .

    gameplay was near enough the same.

    i will how ever like to question the packet loss graph.
    i reckon its zero because they test with icmp or tcp....more likely icmp.

    either way if they arent testing with udp its pretty pointless having a packet loss graph there.
    the odds are you had very high packet loss or packets diverted which caused a lot to arrive out of order...rendered useless.

    what caused it?

    probably your isp treating icmp normally so they dont get complaints but other packet types ...more specifically udp....being re routed probably causing them to loop en route.

    ive seen this happen with dodgy gameplay btw.

    they wont do this with tcp as if you understand the net this would cause utter mayhem lol.

    easier to pick on a protocol which doesnt need a reply or resend.

    Packet loss is determined by UDP datagram drops/fragmentation, just so you know. Also quite a few datagrams (hit claim, dmg receival etc) in BF requires an ack.

  • misisipiRivrRat
    1004 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    the graph and the ping chart doesnt look out of the ordinary.
    i had a 700ms+ player on my team yesterday ....but in other games there wasnt .

    gameplay was near enough the same.

    i will how ever like to question the packet loss graph.
    i reckon its zero because they test with icmp or tcp....more likely icmp.

    either way if they arent testing with udp its pretty pointless having a packet loss graph there.
    the odds are you had very high packet loss or packets diverted which caused a lot to arrive out of order...rendered useless.

    what caused it?

    probably your isp treating icmp normally so they dont get complaints but other packet types ...more specifically udp....being re routed probably causing them to loop en route.

    ive seen this happen with dodgy gameplay btw.

    they wont do this with tcp as if you understand the net this would cause utter mayhem lol.

    easier to pick on a protocol which doesnt need a reply or resend.

    If it was packet loss wouldn't my character keep right on moving like that even when I ADS? It would stop every time I'd aim down sights. I guess I just don't understand how it all works.
  • UrinDenialP
    144 postsMember, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    the graph and the ping chart doesnt look out of the ordinary.
    i had a 700ms+ player on my team yesterday ....but in other games there wasnt .

    gameplay was near enough the same.

    i will how ever like to question the packet loss graph.
    i reckon its zero because they test with icmp or tcp....more likely icmp.

    either way if they arent testing with udp its pretty pointless having a packet loss graph there.
    the odds are you had very high packet loss or packets diverted which caused a lot to arrive out of order...rendered useless.

    what caused it?

    probably your isp treating icmp normally so they dont get complaints but other packet types ...more specifically udp....being re routed probably causing them to loop en route.

    ive seen this happen with dodgy gameplay btw.

    they wont do this with tcp as if you understand the net this would cause utter mayhem lol.

    easier to pick on a protocol which doesnt need a reply or resend.

    Packet loss is determined by UDP datagram drops/fragmentation, just so you know. Also quite a few datagrams (hit claim, dmg receival etc) in BF requires an ack.

    still doesnt explain how a protocol well known for packet loss gets zero packet loss.
    i get they might use tcp for hits and damage...tcp might get delayed but is sure to get there.

    its possible then they may be measuring that tcp data for packet loss????
    which would make sense.

    its wrong if they do btw
  • UrinDenialP
    144 postsMember, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member

    Ok. This happened yesterday in two different games. I thought enough to stop and put the netgraph on to see if that showed anything. There were quite a few high ping connections in the match, but heck I don't know if that matters or not. Gameplay was of though for most of my sessions yesterday. I did well but it wasn't the best experience playing.

    the graph and the ping chart doesnt look out of the ordinary.
    i had a 700ms+ player on my team yesterday ....but in other games there wasnt .

    gameplay was near enough the same.

    i will how ever like to question the packet loss graph.
    i reckon its zero because they test with icmp or tcp....more likely icmp.

    either way if they arent testing with udp its pretty pointless having a packet loss graph there.
    the odds are you had very high packet loss or packets diverted which caused a lot to arrive out of order...rendered useless.

    what caused it?

    probably your isp treating icmp normally so they dont get complaints but other packet types ...more specifically udp....being re routed probably causing them to loop en route.

    ive seen this happen with dodgy gameplay btw.

    they wont do this with tcp as if you understand the net this would cause utter mayhem lol.

    easier to pick on a protocol which doesnt need a reply or resend.

    If it was packet loss wouldn't my character keep right on moving like that even when I ADS? It would stop every time I'd aim down sights. I guess I just don't understand how it all works.

    in laymans terms it looks like your internet had a spell where it wasnt as it should have been.

    it could have been the server though where your data got corrupted for some reason.....i tend to think though if the server was at fault all players will have a problem and you will see quite a few players leave that server.
  • mmarkweII
    2919 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE Member
    It's just the screen shake bug. Nothing more, nothing less. Haven't watched the second video yet.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    edited September 2017
    still doesnt explain how a protocol well known for packet loss gets zero packet loss.
    i get they might use tcp for hits and damage...tcp might get delayed but is sure to get there.

    its possible then they may be measuring that tcp data for packet loss????
    which would make sense.

    its wrong if they do btw

    TCP isn't used because the packets are time sensitive.
    The problem with TCP is that it abstracts data delivery as a reliable ordered stream. Because of this, if a packet is lost, TCP has to stop and wait for that packet to be resent. This interrupts the steady stream of packets because more recent packets must wait in a queue until the resent packet arrives, so packets are received in the same order they were sent. This adds to delay (LAG).

    Hence one of if not the main reasoning behind using UDP. For reliability a custom system is layered on top of UDP. The goal of a reliability system is to know which packets arrive at the other side of the connection. This is done by sequencing, yet unlike TCP it does not resend packets with a given sequence number. This helps avoid out of order receival.

    The game never stops and resends packet n if it was lost. Resends are left up to the application to compose a new packet containing the data that was lost, if necessary, and this packet gets sent with a new sequence number. Determining resend is based on non receival of an ack.


    Determining loss
    Because of the inherent holes in the reliability system, multiple acks must be included in each packet. Couple this with redundancy sends to ensure that both the client and the server receive acknowledgements for received packets.

    An ack is an acknowledgement of receival. Consider it a receipt for a packet's arrival and acceptance.

    Using an ack bitfield (4 bytes per ack) you send multiple acks per packet, multiple times, just in case one packet with the ack doesn’t get through. For a 60 tick server you would send 63 acks per packet.

    For clarity.......
    The server just received packet "1000" from the client. It in turn creates an ack for packet 1000. This ack will be the first ack in the ack bitfield, followed by the 62 previous acks. On the next receival it will generate an ack for the new packet, that ack will be the first ack in the bitfield, followed by the ack for packet 1000 and the previous 61 acks.

    This ensures that the client/server will receive the acknowledgement. If you don’t get an ack for a packet within 1 second of projected arrival time, then it is considered as lost.
    • Each time a packet is sent, we increase the local sequence number
    • When a packet is received, the sequence number of the packet is checked against the remote sequence number. If the packet sequence is more recent, update the remote sequence number.
    • When the packet headers are composed, the local sequence becomes the sequence number of the packet, and the remote sequence becomes the ack. The ack bitfield is calculated by looking into a queue of up to 63 packets, containing sequence numbers in the range [remote sequence - 62, remote sequence]. Set bit n (in [1,62]) in ack bits to 1 if the sequence number remote sequence - n is in the received queue.
    • Additionally, when a packet is received, ack bitfield is scanned and if bit n is set, then we acknowledge sequence number packet sequence - n, if it has not been acked already.

    This algorithm requires 100% packet loss for more than a second for an acknowledgement to be lost.

    You could simply look at the sequence numbers and count the holes as loss (1,2,loss,4,5,6,loss,loss,9). But it wouldn't be accurate 100% of the time. You'd need to consider out of order receival and late arrivals. Technically they aren't lost, they're simply discarded by the application beit the server or client.


    Hits and damage data uses UDP.
Sign In or Register to comment.