No anticheat in new patch-Im out

[Rev0verDrive]

@Mikhailovitch

@Mikhailovitch

1. Any idea of just how much beta testing that they’ve done to a change like that to (what amounts to) out-of-region hit-detection? My understanding is that, historically speaking, the combination of OOR pings and server-side detection almost invariably led to even more serious lag problems for those players.

Testing …Loads of testing. The changes are on the CTE servers. Although those are all PC. In the end there may indeed be two variations of the changes. One that is in sync with PC tick and its direct route to server, and one for console tick and it’s parent network (psn, Live). My understanding of console is that the data has to travel from client to the network (Psn/Live) and then to the server.

Historically, yes high pingers got the shorter end of the stick. The general experience was so bad for the high pinger that they simple didn’t play on those servers. Yet, Server-side detection does not increase lag. Your client already sends “supposed” hits to the server for arbitration. They just aren’t as scrutinized as much as what the new setup does. Plus the buffer has changed. You maybe thinking about peer-to-peer lockstep.

To clarify, server-side detection does not increase lag/latency. It does/can increase bandwidth consumption though. Bearing in mind you only need a “broadband” setup of 1 up and 1 down to play (actually it’s closer to 256Kb up/down). Send and receive rates simply dictate the amount of data you can send/receive at any given point. With a 200Mb down (which I have) I can stream movies/music, download large files, multiple files etc while playing and have zero issues. Think of it as small pipe vs big pipe.

200Mb down means you can download up to 200Mb/s, it does not mean your data travels 200x faster than a 1Mb connection. Broadband is broadband. Broadband data typically (unhindered) travels 62 miles per ms. The route it takes to get from A to B stipulates the travel distance, thus ping.

@Mikhailovitch

2. Further, it’s also been my understanding that the basic reason that EA/ Dice has never put into place the sensible option of region-locking the servers – i.e. if you are playing from Hong Kong you do not get access to US servers – is that EA is afraid that they will lose market share as those far overseas players become frustrated by their lack of access to many of the more popular western servers.

Region locking simply won’t work.
One, You can manually change your region to whatever you want.
And Two there’s VPN/Proxy. The cost to prevent region hopping in that aspect is too high. Internal ping capping (clamping) has been discussed. The problem is it would exclude MP access to a large part of the market. The player base would be really small. It is possible for the rsp to offer ping limiting in the future. But the next update should really limit the need for it.

Just imagine how many players would be excluded with a ping clamp of 100ms.

@Mikhailovitch

3. So, and as much as it would make sense from a relatively localized gaming standpoint – mandatory server-side detection for high pingers would do a heck of a lot in straightening out our currently hybridized detection system – is EA really serious about putting in what amounts to an even more severe lag penalty for far overseas players? Or, alternatively, have they come up with and fully tested some incredibly clever way of running a server-side system that does not severely lag out those OOR players when they join in on a western server?

They’re serious and there’s isn’t some weird approach/technique to it.

Here’s a few quotes from the DEV.

The next patch will lower the FHT for soldiers from 125ms to 100ms and above 100ms, server side hit detection is performed for High pingers which is way more powerful than clamping the frame history. With this recent patch i changed the server side arbitration so that hits on your client on extrapolated soldiers will still count unless you are a high pinger.

To clarify:
Soldier FHT is lowered to 0.01 from 0.0125. Latency higher than 100ms results in all hits to be handled strictly by the server. Latency lower than 100ms is handled the normal way…client detect, server authenticate.

Basically we have client side hit detection and server side arbitration.

So simplified: the server simulates a given bullet at the same time the client simulated a given bullet resulting in a certain damage hit. That very time is clamped. So a high pinger shooting at 150ms latency, gets its bullet simulated at clamped 100ms on the server. That means the world was already 50ms further ahead in terms of time, than the bullet was simulated with at the high pingers client. However, the server does a very coarse arbitration test which will see the clamping of FHT almost to no effect up until 300ms latency.

To counter this, i implemented full server side accurate hit detection for anything beyond 100ms. So instead of running client side hit detection, they run server side hit detection with whatever is currently the state of the world on the server. So they have to extrapolate in their head and lead the shot. That also eliminates shooting around corners as the shot will be blocked. It does not fully switch from 100ms to 0 latency and rather interpolate softly, but it should be a major milestone and discourage players over 100ms to deliberately play OOR.

Additionally on top of this he states later that: in the situation where the high pingers data is dropped (packet loss) consecutively due to a bad connection; the server inputs “dummy” data.

e.g.
If the server hasn’t received inputs from Player X over the course of N ticks. The server inputs “dummy” data. This dummy data is then used/considered as “authentic” data for subsequent calculations etc.

If you want a more technical walk through you can either DM me or check this post.
Hit Detection

Loads of technical insight from that point forward.