# Hit Detection **URL:** \ **Category:** Console\ **Created:** [November 14, 2016, 5:54pm UTC](https://battlefieldforum.co/t/hit-detection/104273 "2016-11-14T17:54:00Z")\ **Posts on this page:** 20\ **Page:** 64
**Author:** ![HillbillyJohn](https://battlefieldforum.co/user_avatar/battlefieldforum.co/hillbillyjohn/32/102209_2.png) [@HillbillyJohn](https://battlefieldforum.co/u/HillbillyJohn)\ **Post date:** [September 11, 2017, 9:51pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1261 "2017-09-11T21:51:00Z")
> [@Rev0verDrive](#): > > > [@HillbillyJohn](#): > > > > 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. ---
**Author:** ![Rev0verDrive](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/r/7993a0/32.png) [@Rev0verDrive](https://battlefieldforum.co/u/Rev0verDrive)\ **Post date:** [September 11, 2017, 10:06pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1262 "2017-09-11T22:06:00Z")
> [@HillbillyJohn](#): > > > [@Rev0verDrive](#): > > > > > [@HillbillyJohn](#): > > > > > > 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. ---
**Author:** ![UrinDenialP](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/u/bc8723/32.png) [@UrinDenialP](https://battlefieldforum.co/u/UrinDenialP)\ **Post date:** [September 11, 2017, 10:14pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1263 "2017-09-11T22:14:00Z")
Rev0verDrive wrote: [»](https://battlefieldforum.co/t/hit-detection/104273/1258) > [@UrinDenialP](#): > > 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. ---
**Author:** ![UrinDenialP](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/u/bc8723/32.png) [@UrinDenialP](https://battlefieldforum.co/u/UrinDenialP)\ **Post date:** [September 11, 2017, 10:16pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1264 "2017-09-11T22:16:00Z")
> [@HillbillyJohn](#): > > > [@Rev0verDrive](#): > > > > > [@HillbillyJohn](#): > > > > > > 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. ---
**Author:** ![Rev0verDrive](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/r/7993a0/32.png) [@Rev0verDrive](https://battlefieldforum.co/u/Rev0verDrive)\ **Post date:** [September 11, 2017, 10:41pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1265 "2017-09-11T22:41:00Z")
> [@UrinDenialP](#): > > 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. ---
**Author:** ![KingTolapsium](https://battlefieldforum.co/user_avatar/battlefieldforum.co/kingtolapsium/32/102530_2.png) [@KingTolapsium](https://battlefieldforum.co/u/KingTolapsium)\ **Post date:** [September 11, 2017, 11:00pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1266 "2017-09-11T23:00:00Z")
> [@Rev0verDrive](#): > > > [@UrinDenialP](#): > > > > 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. ---
**Author:** ![Rev0verDrive](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/r/7993a0/32.png) [@Rev0verDrive](https://battlefieldforum.co/u/Rev0verDrive)\ **Post date:** [September 11, 2017, 11:11pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1267 "2017-09-11T23:11:00Z")
> [@KingTolapsium](#): > > > [@Rev0verDrive](#): > > > > > [@UrinDenialP](#): > > > > > > 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. ---
**Author:** ![iSpyRecon](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/i/58f4c7/32.png) [@iSpyRecon](https://battlefieldforum.co/u/iSpyRecon)\ **Post date:** [September 12, 2017, 12:05am UTC](https://battlefieldforum.co/t/hit-detection/104273/1268 "2017-09-12T00:05:00Z")
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. ---
**Author:** ![KingTolapsium](https://battlefieldforum.co/user_avatar/battlefieldforum.co/kingtolapsium/32/102530_2.png) [@KingTolapsium](https://battlefieldforum.co/u/KingTolapsium)\ **Post date:** [September 12, 2017, 2:02am UTC](https://battlefieldforum.co/t/hit-detection/104273/1269 "2017-09-12T02:02:00Z")
> [@Rev0verDrive](#): > > > [@KingTolapsium](#): > > > > > [@Rev0verDrive](#): > > > > > > > [@UrinDenialP](#): > > > > > > > > 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). ---
**Author:** ![UrinDenialP](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/u/bc8723/32.png) [@UrinDenialP](https://battlefieldforum.co/u/UrinDenialP)\ **Post date:** [September 12, 2017, 8:32am UTC](https://battlefieldforum.co/t/hit-detection/104273/1270 "2017-09-12T08:32:00Z")
> [@Rev0verDrive](#): > > > [@UrinDenialP](#): > > > > 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. ---
**Author:** ![Rev0verDrive](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/r/7993a0/32.png) [@Rev0verDrive](https://battlefieldforum.co/u/Rev0verDrive)\ **Post date:** [September 12, 2017, 9:06pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1271 "2017-09-12T21:06:00Z")
> [@UrinDenialP](#): > > 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.wikibooks.org/wiki/Communication_Networks/TCP_and_UDP_Protocols) [https://en.wikipedia.org/wiki/User\_Datagram\_Protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol) [https://www.howtogeek.com/190014/htg-explains-what-is-the-difference-between-tcp-and-udp/](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). ---
**Author:** ![Mearen1911](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/m/d9b06d/32.png) [@Mearen1911](https://battlefieldforum.co/u/Mearen1911)\ **Post date:** [September 12, 2017, 10:39pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1272 "2017-09-12T22:39:00Z")
> [@KingTolapsium](#): > > > [@Mearen1911](#): > > > > > [@lizzard](#): > > > > > > > [@KingTolapsium](#): > > > > > > > > > [@lizzard](#): > > > > > > > > > > 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. ---
**Author:** ![Mearen1911](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/m/d9b06d/32.png) [@Mearen1911](https://battlefieldforum.co/u/Mearen1911)\ **Post date:** [September 12, 2017, 10:40pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1273 "2017-09-12T22:40:00Z")
> [@rock1obsta](#): > > > [@Mearen1911](#): > > > > > [@lizzard](#): > > > > > > > [@KingTolapsium](#): > > > > > > > > > [@lizzard](#): > > > > > > > > > > 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. ---
**Author:** ![Rev0verDrive](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/r/7993a0/32.png) [@Rev0verDrive](https://battlefieldforum.co/u/Rev0verDrive)\ **Post date:** [September 12, 2017, 10:50pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1274 "2017-09-12T22:50:00Z")
> [@Mearen1911](#): > > 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. ---
**Author:** ![KingTolapsium](https://battlefieldforum.co/user_avatar/battlefieldforum.co/kingtolapsium/32/102530_2.png) [@KingTolapsium](https://battlefieldforum.co/u/KingTolapsium)\ **Post date:** [September 12, 2017, 11:01pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1275 "2017-09-12T23:01:00Z")
> [@Mearen1911](#): > > > [@KingTolapsium](#): > > > > > [@Mearen1911](#): > > > > > > > [@lizzard](#): > > > > > > > > > [@KingTolapsium](#): > > > > > > > > > > > [@lizzard](#): > > > > > > > > > > > > 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. ---
**Author:** ![iSpyRecon](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/i/58f4c7/32.png) [@iSpyRecon](https://battlefieldforum.co/u/iSpyRecon)\ **Post date:** [September 13, 2017, 12:55am UTC](https://battlefieldforum.co/t/hit-detection/104273/1276 "2017-09-13T00:55:00Z")
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, ---
**Author:** ![Rev0verDrive](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/r/7993a0/32.png) [@Rev0verDrive](https://battlefieldforum.co/u/Rev0verDrive)\ **Post date:** [September 13, 2017, 1:20am UTC](https://battlefieldforum.co/t/hit-detection/104273/1277 "2017-09-13T01:20:00Z")
> [@iSpyRecon](#): > > 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. ---
**Author:** ![oJU5T1No](https://battlefieldforum.co/letter_avatar_proxy/v4/letter/o/a88e57/32.png) [@oJU5T1No](https://battlefieldforum.co/u/oJU5T1No)\ **Post date:** [September 13, 2017, 5:09pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1278 "2017-09-13T17:09:00Z")
> [@KingTolapsium](#): > > 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. ---
**Author:** ![mmarkweII](https://battlefieldforum.co/user_avatar/battlefieldforum.co/mmarkweii/32/102833_2.png) [@mmarkweII](https://battlefieldforum.co/u/mmarkweII)\ **Post date:** [September 13, 2017, 6:26pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1279 "2017-09-13T18:26:00Z")
> [@Rev0verDrive](#): > > > [@Mearen1911](#): > > > > 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. Or video. If it happens all of the time, it should be pretty easy to capture and post. ---
**Author:** ![KingTolapsium](https://battlefieldforum.co/user_avatar/battlefieldforum.co/kingtolapsium/32/102530_2.png) [@KingTolapsium](https://battlefieldforum.co/u/KingTolapsium)\ **Post date:** [September 13, 2017, 7:28pm UTC](https://battlefieldforum.co/t/hit-detection/104273/1280 "2017-09-13T19:28:00Z")
> [@oJU5T1No](#): > > > [@KingTolapsium](#): > > > > 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. It’s kinda messed up to give those players an awesome experience, then take it away. I hate it too, but it’s the reality. You can’t pull the rug out from people a year in, it’s unfortunate that the 100ms soft cap was bugged with no ping relevant extrapolation to even things out. Because of a bug, we are stuck with 160ms/200ms. It is what it is, I will be very harsh with my network feedback for the next game, and for incursions, but the public servers don’t seem like they will become any less high ping friendly, even with continued optimization and a main focus on low ping play. At least we are making progress, bf4 was revolting in this department, and DICE lied about things over and over, I haven’t forgotten. [Previous page](https://battlefieldforum.co/t/hit-detection/104273.md?page=63) [Next page](https://battlefieldforum.co/t/hit-detection/104273.md?page=65)