Hit Detection

Comments

  • HillbillyJohn
    509 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, Battlefield V Member
    Is there something going on with the servers? I've seen the red server icon a few times at a minute or so into the game, playing tdm ps4.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    Is there something going on with the servers? I've seen the red server icon a few times at a minute or so into the game, playing tdm ps4.

    Apparently there is an issue that DICE has been looking into over the past few days. It's not widespread as far as I know/can tell.
  • HillbillyJohn
    509 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, Battlefield V Member
    Is there something going on with the servers? I've seen the red server icon a few times at a minute or so into the game, playing tdm ps4.

    Apparently there is an issue that DICE has been looking into over the past few days. It's not widespread as far as I know/can tell.

    Some of the servers I join I've also noticed that it feels like my character is running through knee deep water.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    Is there something going on with the servers? I've seen the red server icon a few times at a minute or so into the game, playing tdm ps4.

    Apparently there is an issue that DICE has been looking into over the past few days. It's not widespread as far as I know/can tell.

    Some of the servers I join I've also noticed that it feels like my character is running through knee deep water.

    could be a server issue. I haven't come across any issue other than delayed kill messages.
  • UrinDenialP
    144 postsMember, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member
    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.

    thats clears that up then.

    and explains why it shows no packet loss when we know there should be on udp.

    but its a badly flawed system.
    any packet loss is bad and we need to know how much we are getting exactly.

    why arent ea putting the exact figures up there?

    if they did we could at least go to our isps and say hey...your ******* us over.

    ive suspected for a while now since net neutrality laws came out netwroks and isps ahve been picking on udp because its "only a protocol".
    I suspect as its pointless picking on tcp , and picking on icmp would simply cause complaints , and of course you cant pick on a traffic type for fear of being fined ....it leaves only one target.

    udp.

    what i think networks and isps are doing is simply dropping udp uniformly.
    for example...a node gets close to it level where it needs to cap traffic it simply drops a certain amount fo udp.

    say one every 10 packets..

    proving this is not easy.

    if you compare that to what ea are doing its helping mask this potential/highly probable issue.

    i suggest ea produce a true figure.
  • UrinDenialP
    144 postsMember, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member
    Is there something going on with the servers? I've seen the red server icon a few times at a minute or so into the game, playing tdm ps4.

    Apparently there is an issue that DICE has been looking into over the past few days. It's not widespread as far as I know/can tell.

    Some of the servers I join I've also noticed that it feels like my character is running through knee deep water.

    sounds like fifas issue.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    edited September 2017
    thats clears that up then.

    and explains why it shows no packet loss when we know there should be on udp.

    but its a badly flawed system.
    any packet loss is bad and we need to know how much we are getting exactly.

    why arent ea putting the exact figures up there?

    if they did we could at least go to our isps and say hey...your ******* us over.

    ive suspected for a while now since net neutrality laws came out netwroks and isps ahve been picking on udp because its "only a protocol".
    I suspect as its pointless picking on tcp , and picking on icmp would simply cause complaints , and of course you cant pick on a traffic type for fear of being fined ....it leaves only one target.

    udp.

    what i think networks and isps are doing is simply dropping udp uniformly.
    for example...a node gets close to it level where it needs to cap traffic it simply drops a certain amount fo udp.

    say one every 10 packets..

    proving this is not easy.

    if you compare that to what ea are doing its helping mask this potential/highly probable issue.

    i suggest ea produce a true figure.

    I'm sorry but that just doesn't make any sense. You're talking about reliability in receival of time-sensitive data.

    If any conspiracy road is to be travelled it would be one in which DICE would be bloating loss vs concealing it. High loss stipulates the problem is outside their control and not a product design issue. Low loss and there's still an issue points directly at the product.

    I see no conspiracy, nor bloat/concealment of data.
  • KingTolapsium
    5491 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE, BF1IncursionsAlpha, Battlefield V Member
    thats clears that up then.

    and explains why it shows no packet loss when we know there should be on udp.

    but its a badly flawed system.
    any packet loss is bad and we need to know how much we are getting exactly.

    why arent ea putting the exact figures up there?

    if they did we could at least go to our isps and say hey...your ******* us over.

    ive suspected for a while now since net neutrality laws came out netwroks and isps ahve been picking on udp because its "only a protocol".
    I suspect as its pointless picking on tcp , and picking on icmp would simply cause complaints , and of course you cant pick on a traffic type for fear of being fined ....it leaves only one target.

    udp.

    what i think networks and isps are doing is simply dropping udp uniformly.
    for example...a node gets close to it level where it needs to cap traffic it simply drops a certain amount fo udp.

    say one every 10 packets..

    proving this is not easy.

    if you compare that to what ea are doing its helping mask this potential/highly probable issue.

    i suggest ea produce a true figure.

    I'm sorry but that just doesn't make any sense. You're talking about reliability in receival of time-sensitive data.

    If any conspiracy road is to be travelled it would be one in which DICE would be bloating loss vs concealing it. High loss stipulates the problem is outside their control and not a product design issue. Low loss and there's still an issue points directly at the product.

    I see no conspiracy, nor bloat/concealment of data.

    I see a focus on accessibility which is a market wide trend.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    thats clears that up then.

    and explains why it shows no packet loss when we know there should be on udp.

    but its a badly flawed system.
    any packet loss is bad and we need to know how much we are getting exactly.

    why arent ea putting the exact figures up there?

    if they did we could at least go to our isps and say hey...your ******* us over.

    ive suspected for a while now since net neutrality laws came out netwroks and isps ahve been picking on udp because its "only a protocol".
    I suspect as its pointless picking on tcp , and picking on icmp would simply cause complaints , and of course you cant pick on a traffic type for fear of being fined ....it leaves only one target.

    udp.

    what i think networks and isps are doing is simply dropping udp uniformly.
    for example...a node gets close to it level where it needs to cap traffic it simply drops a certain amount fo udp.

    say one every 10 packets..

    proving this is not easy.

    if you compare that to what ea are doing its helping mask this potential/highly probable issue.

    i suggest ea produce a true figure.

    I'm sorry but that just doesn't make any sense. You're talking about reliability in receival of time-sensitive data.

    If any conspiracy road is to be travelled it would be one in which DICE would be bloating loss vs concealing it. High loss stipulates the problem is outside their control and not a product design issue. Low loss and there's still an issue points directly at the product.

    I see no conspiracy, nor bloat/concealment of data.

    I see a focus on accessibility which is a market wide trend.

    Buffer scaling is a different topic all together. From what I remember from Mischkag's posts he did include a clamped time limit on late data. Specifically pertaining to shots fired. This beyond the limit of the ping threshold.
  • iSpyRecon
    770 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    Game seems to be playing well for me but I play Dom. Maybe small modes have less issue? In any event ... Still the best BF ever imo.
  • KingTolapsium
    5491 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE, BF1IncursionsAlpha, Battlefield V Member
    thats clears that up then.

    and explains why it shows no packet loss when we know there should be on udp.

    but its a badly flawed system.
    any packet loss is bad and we need to know how much we are getting exactly.

    why arent ea putting the exact figures up there?

    if they did we could at least go to our isps and say hey...your ******* us over.

    ive suspected for a while now since net neutrality laws came out netwroks and isps ahve been picking on udp because its "only a protocol".
    I suspect as its pointless picking on tcp , and picking on icmp would simply cause complaints , and of course you cant pick on a traffic type for fear of being fined ....it leaves only one target.

    udp.

    what i think networks and isps are doing is simply dropping udp uniformly.
    for example...a node gets close to it level where it needs to cap traffic it simply drops a certain amount fo udp.

    say one every 10 packets..

    proving this is not easy.

    if you compare that to what ea are doing its helping mask this potential/highly probable issue.

    i suggest ea produce a true figure.

    I'm sorry but that just doesn't make any sense. You're talking about reliability in receival of time-sensitive data.

    If any conspiracy road is to be travelled it would be one in which DICE would be bloating loss vs concealing it. High loss stipulates the problem is outside their control and not a product design issue. Low loss and there's still an issue points directly at the product.

    I see no conspiracy, nor bloat/concealment of data.

    I see a focus on accessibility which is a market wide trend.

    Buffer scaling is a different topic all together. From what I remember from Mischkag's posts he did include a clamped time limit on late data. Specifically pertaining to shots fired. This beyond the limit of the ping threshold.

    I was being general, nothing specific. (I don't know enough about packet handling to do that).
  • UrinDenialP
    144 postsMember, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE Member
    thats clears that up then.

    and explains why it shows no packet loss when we know there should be on udp.

    but its a badly flawed system.
    any packet loss is bad and we need to know how much we are getting exactly.

    why arent ea putting the exact figures up there?

    if they did we could at least go to our isps and say hey...your ******* us over.

    ive suspected for a while now since net neutrality laws came out netwroks and isps ahve been picking on udp because its "only a protocol".
    I suspect as its pointless picking on tcp , and picking on icmp would simply cause complaints , and of course you cant pick on a traffic type for fear of being fined ....it leaves only one target.

    udp.

    what i think networks and isps are doing is simply dropping udp uniformly.
    for example...a node gets close to it level where it needs to cap traffic it simply drops a certain amount fo udp.

    say one every 10 packets..

    proving this is not easy.

    if you compare that to what ea are doing its helping mask this potential/highly probable issue.

    i suggest ea produce a true figure.

    I'm sorry but that just doesn't make any sense. You're talking about reliability in receival of time-sensitive data.

    If any conspiracy road is to be travelled it would be one in which DICE would be bloating loss vs concealing it. High loss stipulates the problem is outside their control and not a product design issue. Low loss and there's still an issue points directly at the product.

    I see no conspiracy, nor bloat/concealment of data.

    i think theory is more apt.
    if you break down the protocols it makes no sense to delay or kick tcp...because it will resend.
    with icmp this will show up if you "hinder it"...they have other ways around this though by simply avoiding measuring it on hops en route...hence the blank nodes.(on a side not most of these show up with udp ping and the majority show issues)...i dont buy isp's explanations because when im playign and i see issues i also have problems with games....when there are no issues games pay well....
    back to icmp...if people can see problems they will complain...so why hinder it.

    that leaves good old udp.

    if a network is getting close to it level where it has to do something what do they do...just leave it and hope it doesnt happen?
    no they re route...but are they re routing all traffic?
    no imo


    im seeing differences in graphs between icmp and udp on certain parts of routes.
    the net result is a differnt latency for icmp compared to udp.

    this isnt conspiracy.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    i think theory is more apt.
    if you break down the protocols it makes no sense to delay or kick tcp...because it will resend.
    with icmp this will show up if you "hinder it"...they have other ways around this though by simply avoiding measuring it on hops en route...hence the blank nodes.(on a side not most of these show up with udp ping and the majority show issues)...i dont buy isp's explanations because when im playign and i see issues i also have problems with games....when there are no issues games pay well....
    back to icmp...if people can see problems they will complain...so why hinder it.

    that leaves good old udp.

    if a network is getting close to it level where it has to do something what do they do...just leave it and hope it doesnt happen?
    no they re route...but are they re routing all traffic?
    no imo


    im seeing differences in graphs between icmp and udp on certain parts of routes.
    the net result is a differnt latency for icmp compared to udp.

    this isnt conspiracy.

    You seem to be somewhat versed in TCP, but I recommend a refresher.

    TCP vs UDP
    TCP is a connection oriented stream over an IP network. It guarantees that all sent packets will reach the destination in the correct order. This implies the use of acknowledgement packets (ACKS) sent back to the sender, and automatic retransmission, causing additional delays and a general less efficient transmission than UDP.

    UDP is a connection-less protocol. Communication is datagram oriented. The integrity is guaranteed only on the single datagram. Datagrams reach destination and can arrive out of order or don't arrive at all. It is more efficient than TCP because it uses non ACK. It's generally used for real time communication, where a little percentage of packet loss rate is preferable to the overhead of a TCP connection.

    TCP requires a 3 packet exchange with ACK's to establish a connection before any application data is sent. When a packet is lost, the connection bottlenecks until the lost packet resend is received and acknowledged. This adds tremendous amounts of lag. During the retransmission of the lost packet, no other packets are sent. Any actions you take during the retransmission are backlogged for later transmission. The backlog is buffered based and can be only so large.

    If the packet loss spike is severe the connection will be severed. Resulting in a reconnection process of a 3 packet exchange with acknowledgements. AGAIN more LAG. If the packet loss exceeds a specific amount (system dependent) client server desync will happen. This will result in a complete disconnection from the game.

    Thus the reasoning for using UDP over TCP. With UDP security and reliability are added in at the Application layer.

    TCP protocol use: HTTP, HTTPs, FTP, SMTP, Telnet

    UDP protocol use: DNS, DHCP, TFTP, SNMP, RIP, VOIP

    References:
    https://en.wikibooks.org/wiki/Communication_Networks/TCP_and_UDP_Protocols
    https://en.wikipedia.org/wiki/User_Datagram_Protocol
    https://www.howtogeek.com/190014/htg-explains-what-is-the-difference-between-tcp-and-udp/


    Network Rerouting
    When a network is overloaded it will reroute a percentage of the traffic to alleviate the extra load. It is only this "extra" load that is clogging the route. Therefore for efficiency sake you only reroute the excess. Rerouting the entire load takes more time and resources then mitigating the excess.


    Ping vs Latency
    ICMP(type 8) does not process data. It is strictly used for PING. It is a very small request/response handshake. ZERO DATA is sent, nor processed.

    ICMP requests are routed to a specific box at the datacenter in which the game server resides. All pings (ICMP) for all clients regardless the application are done this way....at every datacenter.

    For clarity "Any request" using the ICMP protocol upon reaching the datacenter are routed to a Pingsite server. The Pingsite handles ALL ICMP requests irregardless if it's for a game server, web server, database etc. This is done to reduce the connection load and resource usage of the application server. Once data reaches the datacenter it's mere MICROseconds from DNS to Box.

    The TERM latency is generally synonymous with ping. But that is not the case when it comes to games.

    Latency (UDP) is not equal to PING (ICMP). It is the round trip of a datagram + server side processing time. client data is processed. Latency is affected by server load.

    So of course there are going to be differences when comparing 2 separate strings. Ping is ICMP, Latency is UDP (round trip and processing of a datagram).
  • Mearen1911
    115 postsMember, Battlefield 4, Battlefield, Battlefield 1, CTE, BF1IncursionsAlpha Member
    Mearen1911 wrote: »
    lizzard wrote: »
    lizzard wrote: »

    Please king.. Stop this nonsense...

    A hitreg bug, would be something specific to a given instance.

    Switching guns while reloading. And then have no hitreg.

    Enter vehicle as a class and then exit vehicle, and have no hitreg.

    Something like the previous hitreg bug that made some players unable to hit any one without restarting the game for example!

    General hitreg would be that you sometime doesn't get a hit on someone.
    Maybe one hit isn't counted out of 5 hits.

    Drop that "crazy hostility" you've got going..

    I'm not going to play semantics with you, and I'm not going to allow semantics to dismiss the feedback of myself and others, you're literally making nonsense claims. Bugs, issues, problems.... WHO CARES? These terms are not the point.

    I'm also not the one declaring that the dev has no reason to further interact.

    It seems you have dismissed the idea of legit hit-reg bugs and are now blaming supression and spread, I'm not going to follow a narrative simply out of ease.

    If you don't think the netcode, or legit bugs are to blame, thats totally fine, not a problem, what we don't need is you dismissing feedback.

    Im not dismissing feedback!
    I'm not saying there is no hitreg issues!

    I do doubt that mischkag can do much more, under the circumstances!

    Packet loss limit and ping limit would be an easy way to see if issues would remain.

    But since every thing he have done to make it more fair for lowpingers.
    Have resulted in hate from everyone with a bad connection.. What more is there that he can do!?

    He hasn't "done" anything. He doesn't even understand the problem. He claimed something that happens every single day here is impossible. He needs to be replaced. THAT is why this problem isn't getting fixed. THAT is why netcode issues have existed for at least 3 Battlefield games. You're giving software developers way more credit than they deserve here. They're not infallible but they do need to admit to their limitations. Dice also needs to recognize this.

    Lol, ignorance breeds ignorant opinions.

    Don't hate on the dude who is fighting for low ping.

    It's up to the leads, not the designer. That's how it works in every facet of game dev.

    Your insults prove you're not here to help so don't project. What you're claiming isn't mutually exclusive. You do know that right? Also I'm not hating anyone, I'm point out DICE's failures. If you comprehended what you read, you would know that.
  • Mearen1911
    115 postsMember, Battlefield 4, Battlefield, Battlefield 1, CTE, BF1IncursionsAlpha Member
    rock1obsta wrote: »
    Mearen1911 wrote: »
    lizzard wrote: »
    lizzard wrote: »

    Please king.. Stop this nonsense...

    A hitreg bug, would be something specific to a given instance.

    Switching guns while reloading. And then have no hitreg.

    Enter vehicle as a class and then exit vehicle, and have no hitreg.

    Something like the previous hitreg bug that made some players unable to hit any one without restarting the game for example!

    General hitreg would be that you sometime doesn't get a hit on someone.
    Maybe one hit isn't counted out of 5 hits.

    Drop that "crazy hostility" you've got going..

    I'm not going to play semantics with you, and I'm not going to allow semantics to dismiss the feedback of myself and others, you're literally making nonsense claims. Bugs, issues, problems.... WHO CARES? These terms are not the point.

    I'm also not the one declaring that the dev has no reason to further interact.

    It seems you have dismissed the idea of legit hit-reg bugs and are now blaming supression and spread, I'm not going to follow a narrative simply out of ease.

    If you don't think the netcode, or legit bugs are to blame, thats totally fine, not a problem, what we don't need is you dismissing feedback.

    Im not dismissing feedback!
    I'm not saying there is no hitreg issues!

    I do doubt that mischkag can do much more, under the circumstances!

    Packet loss limit and ping limit would be an easy way to see if issues would remain.

    But since every thing he have done to make it more fair for lowpingers.
    Have resulted in hate from everyone with a bad connection.. What more is there that he can do!?

    He hasn't "done" anything. He doesn't even understand the problem. He claimed something that happens every single day here is impossible. He needs to be replaced. THAT is why this problem isn't getting fixed. THAT is why netcode issues have existed for at least 3 Battlefield games. You're giving software developers way more credit than they deserve here. They're not infallible but they do need to admit to their limitations. Dice also needs to recognize this.

    What are you even talking about?

    Mischkag has stated several times in the past that high ping has an advantage.
    He's explained a few times what he wants to do to fix it, and it's leagues better than the last 2 BF games (at least on my end it is. I had zero wtf moments related to hit reg or whatever after that first killer patch went through). Even after they rolled it back from 100-160 limit I had no issues, & my ping was always 19-34.
    Where you got the notion that he's lying is beyond comprehension.

    I'm talking about him claiming something that happens every day never happens. Go back and read his posts. Your comprehension needs work.
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    Mearen1911 wrote:
    I'm talking about him claiming something that happens every day never happens. Go back and read his posts. Your comprehension needs work.

    What has he claimed doesn't happen, yet you see every day?

    Maybe an explanation cross up.
  • KingTolapsium
    5491 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1, CTE, BF1IncursionsAlpha, Battlefield V Member
    edited September 2017
    Mearen1911 wrote: »
    Mearen1911 wrote: »
    lizzard wrote: »
    lizzard wrote: »

    Please king.. Stop this nonsense...

    A hitreg bug, would be something specific to a given instance.

    Switching guns while reloading. And then have no hitreg.

    Enter vehicle as a class and then exit vehicle, and have no hitreg.

    Something like the previous hitreg bug that made some players unable to hit any one without restarting the game for example!

    General hitreg would be that you sometime doesn't get a hit on someone.
    Maybe one hit isn't counted out of 5 hits.

    Drop that "crazy hostility" you've got going..

    I'm not going to play semantics with you, and I'm not going to allow semantics to dismiss the feedback of myself and others, you're literally making nonsense claims. Bugs, issues, problems.... WHO CARES? These terms are not the point.

    I'm also not the one declaring that the dev has no reason to further interact.

    It seems you have dismissed the idea of legit hit-reg bugs and are now blaming supression and spread, I'm not going to follow a narrative simply out of ease.

    If you don't think the netcode, or legit bugs are to blame, thats totally fine, not a problem, what we don't need is you dismissing feedback.

    Im not dismissing feedback!
    I'm not saying there is no hitreg issues!

    I do doubt that mischkag can do much more, under the circumstances!

    Packet loss limit and ping limit would be an easy way to see if issues would remain.

    But since every thing he have done to make it more fair for lowpingers.
    Have resulted in hate from everyone with a bad connection.. What more is there that he can do!?

    He hasn't "done" anything. He doesn't even understand the problem. He claimed something that happens every single day here is impossible. He needs to be replaced. THAT is why this problem isn't getting fixed. THAT is why netcode issues have existed for at least 3 Battlefield games. You're giving software developers way more credit than they deserve here. They're not infallible but they do need to admit to their limitations. Dice also needs to recognize this.

    Lol, ignorance breeds ignorant opinions.

    Don't hate on the dude who is fighting for low ping.

    It's up to the leads, not the designer. That's how it works in every facet of game dev.

    Your insults prove you're not here to help so don't project. What you're claiming isn't mutually exclusive. You do know that right? Also I'm not hating anyone, I'm point out DICE's failures. If you comprehended what you read, you would know that.

    What did I state that is not mutually exclusive?

    Being ignorant isn't preferable, but to acknowledge ignorance is not necessarily an insult. I didn't mean to insult you, but you blaming the designer is not beneficial (there is a netcode team, and they answer to production leads, who answer to EA). Just trying to shed some light, as knowledge is power.

    You claim the dev that interacted here doesn't understand, that's not true.

    DICE recognizes that a large portion of the audience has poor connections, due to the backlash of the initial 100ms cap, there isn't much chance of DICE clamping down on poor connections again. This is unfortunate as there are tangible issues regarding player desync still in the live client, that doesn't mean things are being ignored.

    You blame all of the netcode problems of the last three games on one dev, I'd love to see the factual evidence you have to back up that opinion, from my perspective, it seems like a purely negative assumption.
  • iSpyRecon
    770 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1 Member
    Fast Questions:
    1. Is there still a cap?
    2. What is the ms level?
    3. What happens when a player(s) exceed this cap?

    Thank you,
  • Rev0verDrive
    6761 postsMember, Battlefield 3, Battlefield 4, Battlefield, Battlefield 1, CTE, Battlefield V Member
    edited September 2017
    iSpyRecon wrote: »
    Fast Questions:
    1. Is there still a cap?
    2. What is the ms level?
    3. What happens when a player(s) exceed this cap?

    Thank you,

    Yes, there is a ping threshold cap.

    US and Europe: 160ms
    All other Regions: 200ms

    Unlike below threshold where the client deems a hit and sends a claim to the server for server arbitration. Those that exceed the threshold have all shots fired arbitrated strictly by the server. Hit or miss every shot is scrutinized by the server.

    Additionally shots fired and lost via packet loss are not resent by the client...for those with high latency and/or variance (jitter). Also late arrival of shots and extremely delayed client -> server data are discarded... again for high latency players. Furthermore when a player's client data is not received in a timely manner or at all, the server will extrapolate positional information about the player and bind it to the gamestate history.

  • oJU5T1No
    901 postsMember, Battlefield 3, Battlefield 4, Battlefield Hardline, Battlefield, Battlefield 1 Member

    DICE recognizes that a large portion of the audience has poor connections, due to the backlash of the initial 100ms cap, there isn't much chance of DICE clamping down on poor connections again. This is unfortunate as there are tangible issues regarding player desync still in the live client, that doesn't mean things are being ignored.

    You blame all of the netcode problems of the last three games on one dev, I'd love to see the factual evidence you have to back up that opinion, from my perspective, it seems like a purely negative assumption.

    A large portion of the player who won't accept the physics of the internet and thinks its much fairer everyone else suffers the effects of there poor connection rather than them.

Sign In or Register to comment.