Ich bezweifel stark das es am Netcode liegt viel mehr vielleicht am Konzept.
Die bisher bekannten Probleme kennen wir schon seit CS, Quake und UT.
Wir wissen, laut Dice, dass die Hit-Detection auf dem Client erfolgt.
Angenommen:
- Client A hat einen Ping von 80ms
- Client B hat einen Ping von 40ms
jeweils zum Server
Client B weiß erst nach 80/2ms + 40/2ms 60ms + 20ms Serverbearbeitungszeit (geschätzt für Paket annehmen, auswerten, weiterleiten im nächsten Frame) also 80ms was Client A macht.
In der Zeitspanne ist ein Topsprinter schon fast 1m weiter in BF4 sicherlich nicht so viel aber in Deckung könnte er schon sein.
Das wir keine ruckelnde Bewegung sehen haben wir der Input-Prediction oder Client-Side-Prediction zu verdanken.
Zusammen mit Lag compensation hier gut erklärt.
Was vereinfacht nur bedeutet Client B weiß das Client A "W" gedrückt hat, darum läuft Client A die ganze Zeit geradeaus bis irgendwann wieder ein Paket kommt bei dem Client B aufgehört hat "W" zu drücken.
Zusätzlich wird mit jedem Paket vom Server die Position von Client A mitgeteilt wenn die nicht mit der von uns berechneten übereinstimmt gibt es Rubberbanding.
Da die Hit-Detection angeblich am Client erfolgt müsste immer der offensivere Spieler Vorteile haben, da er bestimmt ob ein Treffer gab oder nicht und nicht die Gegenseite welche gerade in Deckung gegangen ist.
Ich glaube es liegt auch nicht wirklich am NetCode sondern teilweise schlechten Hitboxen. Liegt man als Scharfschüze manchmal auf einen Felsen kommen die Schüsse gar nicht beim Ziel an weil sie an der Hitbox vom Felsen kleben bleiben obwohl der Lauf(nicht das Zielfernrohr) freie Bahn hat.
.. heult weiter oder lernt zielen 
