Forum » Hardware » PC aufrüsten für CS:GO » Threadansicht

Netcode/FPS:
Da die Source-Engine UDP und nicht TCP für die Übertragung der IP-Datenpakete verwendet und den Snapshot als Bit-Stream in einem IP-Paket versendet, kann man nicht von einem Datenstrom sprechen, vielmehr von einem sehr regelmäßigen "Bitstrom" oder "Datenimpuls".
Die Verbindung zwischen Client und Gameserver wird über die im UDP-Header eingetragene IP-Adresse und Portnummer hergestellt. Die Snapshots werden in einen Bitstrom umgewandelt und als Datensegment (UDP-OSI4) bei Tickrate 66 alle 15ms übertragen.
Da UDP zur Schonung der Latenz und Bandbreite keine Kontrollfunktionen enthält und die Datensegmente nicht Nummeriert werden, wird die Client-Frametime als Zeitstempel für die serverseitige Simulation genutzt.
Jedes einzelne Frame, das man als Client rendert, definiert die sogenannte Client-Frametime.
Nur so kann der Server durch seinen Algorithmus bestimmen, wie viel er predicten muss und vom Lag bzw. der Roundtrip-Time ausgleichen darf.
Mit cl_interp bestimmt man den Abstand zwischen dem eigentlichen "Zeitstempel" des Spielers und der Grafik, die man auf seinem Monitor sieht, in Millisekunden.
Die Client-Time abzüglich des interp ist der Wert für die Interpolation aller Objekte und Models, den sog. "World-Entities", auf der Map.
Daher sollte man die Framerate nicht nur durch fps_max möglichst gleichmäßig halten, sondern auch gerade Zahlen verwenden.
Die Urban-Legend, dass man als Ausgleich für die Anzeige im Netgraph bei fps_max immer +1 addieren soll, wurde schon mehrfach von Valve schriftlich widerlegt.
Da der Netgraph nicht auf- oder abrundet, sondern die Nachkommastellen abschneidet, entsteht dort ein Fehler in der Anzeige. (Nachprüfbar mit Consolenbefehl "Stats")


Der Server simuliert die Map bei Tickrate 66 kontinuierlich in Abständen von 15ms und erzeugt einen Tick (1000 ms : Tickrate 66 ≈ 15 ms).
Dabei werden die eingehenden Befehle durch den Spieler verarbeitet, simuliert und die neuen Informationen entsprechend auf alle Spieler, Tonnen, Waffen, usw. angewendet.
Basierend auf diesen Informationen, entscheidet der Server, ob er einen Snapshot überhaupt erst generiert und die Spieler über die Veränderungen auf der Map informiert werden.
Da ständig etwas "passiert", wird in der Regel zu jedem Tick ein Snapshot erzeugt und der Server sendet, limitiert durch die cl_updaterate, die Snapshots an den Spieler (z.B. cl_updaterate "47" = 47 von 66 Snapshots, die der Server an den Spieler schicken darf).
Durch die Tickrate bestimmt der Server, wie viele Client-Snapshots in der Sekunde von den Maus und Tastatureingaben der Spieler gemacht werden.
Als Spieler bestimmt man mit cl_cmdrate, wie viele der Client-Snapshots in der Sekunde an den Server übertragen werden (z.B. cl_cmdrate von 33 bei einer serverseitigen Tickrate von 66 = 2 Snapshots je Paket).
Durch die Latenz bzw. Roundtrip, die bei dem Senden und Empfangen der Snapshots entsteht, muss der Server immer mit "verspäteten" Daten des Spielers arbeiten.
Je grösser und je unterschiedlicher die Latenzen zwischen Spieler und Server sind, umso schwieriger wird es für die Engine, diese Unterschiede auszugleichen.
Mit jedem gerenderten Grafik-Frame wird zusammen mit dem zuletzt empfangenen Snapshot der "Zeitstempel" neu gesetzt.
Man hat zwar die Möglichkeit hohe "Rate" Werte zu setzen, diese ergeben aber im Fall von CS:S keinen Sinn. Die Rate wird in Byte die Sekunde angegeben. Der erste Wert bei in/out im Net Graph zeigt die Größe des zuletzt empfangenen Snapshots in Byte. Daneben ist die durchschnittliche Datenmenge die man in Kilobyte die Sekunde angezeigt bekommt.
In der Regel kommt man bei einem 5on5 insgesamt nicht über 25 Kilobyte die Sekunde. Selbst wenn man von 30kb/s ausgehen würde, kommt man nicht über eine Rate von 30720 hinaus.


Theoretisch ist cl_interp im Optimalfall gleich dem Zeitabstand zwischen den einzelnen Ticks.
Daher wird bei cl_interp "0" und cl_interp_ratio "1" immer durch die Engine der Wert mit 1000ms : Tickrate XX = cl_interp 0.0XX errechnet.
Praktisch hat man aber leider kein 5on5, in dem jeder Spieler den gleichen Ping, Netsettings oder eine konstante Framerate hat.
Die "Notwendigkeit" von cl_interp ist auch dafür verantwortlich, dass ein sich bewegender Spieler, einen stehenden Gegner etwas früher sehen kann.
Durch cl_predict wird eine "Wahrscheinlichkeit" der nächsten Eingabe des Spielers berechnet. Dies gleicht den Zeitverzug zwischen den Befehlen des Spielers und der grafischen Darstellung aus, die durch die Verbindung zwischen Spieler und Server entsteht.
Bei dem Thema Prediction hat der Server immer noch das letzte Wort und da man zu Gunsten der Bandbreite, immer nur über den auf dem Monitor zu sehenden Ausschnitt der Map einen Snapshot erhält, kann dies nicht auf Seiten des Spielers berechnet werden.
Dies verursacht unter anderem auch diese kurzzeitigen "Speedhack" Momente. (ka wie ich es sonst bezeichnen soll^^)
Die Wurzel allen Übels steckt jedoch in der serverseitigen Lag-Compensation.
Diese errechnet sich aus dem Zeitstempel des Spielers zwischen den zuletzt empfangenen Snapshots des Servers und der gerenderten Frames, abzüglich des angezeigten Pings in der Console.
Da der Ping durch die Paketumlaufzeit bestimmt wird, kann es besonders bei Gameservern, die weiter entfernt sind, zu einer asymmetrischen Übertragung der Datenpakete kommen.
Auf Deutsch weil die Honks östlich und westlich von Deutschland ohne Cisco-Live Support ihre Border- und Provider Gateway Protokolle nicht anständig hinbekommen, benötigt ein Datenpaket zum Server weniger Zeit, als vom Server zum Spieler zurück.
Dadurch kommt die Lag-Compensation ins "Schwitzen" und es kommt zu "Durchschüssen" und "um-die-Ecke-holen".
Jetzt stellen wir uns alle mal für einen Moment vor, wir wären ein Gameserver und könnten mit einer stromtypischen Lichtgeschwindigkeit, die Datenpakete betrachten. Da werden schon Differenzen von 10 Millisekunden, zu einer nicht zu unterschätzenden Problematik.
Ergo: Der Ping/Round-Trip-Time hat sehr wohl etwas mit der "Treffbarkeit" zu tun.

Grundsätzlich macht die Interpolation des Spiels nichts anderes, als die grafische Ausgabe der empfangenen Daten um Wert x zu verzögern und die Eingaben von Tastatur und Maus um Wert x zurückzurechnen, bevor die eigenen Daten gesendet werden.
Bei einer Tickrate von 66 berechnet der Server 66 mal pro Sekunde, was auf der Map passiert. Das heißt einmal alle ~ 15 ms.
Wenn man nun ein Vielfaches von 66 als fps_max Wert nimmt, spiegelt jedes vom Monitor dargestelle Vollbild einen Tick des Server wieder. Man erhält die Daten vom Server also wirklich zu dem Zeitpunkt, zu dem die Engine diese für die weitere Verarbeitung benötigt.
Nimmt man einen anderen Wert für fps_max, zeigt nur jedes zweite oder dritte Bild des Monitors einen echten Tick des Servers. Die grafische Darstellung der Models, die Eingaben von Maus und Tastatur usw. sind also nicht echt sondern müssen aus den Daten des vorherigen Ticks interpoliert werden.
Dabei können a) Fehler auftreten, da die errechneten Daten nicht mit den tatsächlichen Übereinstimmen oder b) Pakete zu spät oder in falscher Reihenfolge beim Server ankommen. gerade bei Gegner aus dem Ausland mit höherem Ping tritt letzteres gerne mal auf.
Wenn die Paketumlaufszeit asynchron ist (Server -> Client schneller als Client -> Server) oder der Pingunterschied zu groß wird (10 ms vs. 80 ms etc.) kommen die Pakete entweder in falscher Reihenfolge oder eben einfach nicht zur richtigen Zeit an.